Binwalk funziona normalmente in WSL, è inutile che installi un momento una vera Ubuntu.
Riguardo la firma, c'è sicuramente una chain di chiavi, il tale che ha creato
questa repo tempo fa se la era studiata tutta per bene, scaricati quegli strumenti e giocaci un momento per capire meglio quello che sto per dirti.
Sintetizzando quello che credo di sapere con discreta certezza, il payload dei firmware RBI, una volta estratto e decrittato, consiste in una tripletta [kernel, squashfs, firma(kernel+squashfs)] che viene presa e copiata pari pari in una delle due partizioni bank_1/2, che quindi non puoi toccare, ma non dovrebbe essere un problema fintanto che vogliamo far avviare quel firmware così com'è. (NB: anche l'RBI in toto è firmato, ma questa è un altra storia, non confondere le due cose, quest'ultima è irrilevante per quello che stai cercando di fare ora)
il bootloader è fatto in due parti stage1 e 2. Il primo sostanzialmente ha come payload il secondo, lo spacchetta (sempre visto compresso in LZMA su qualsiasi modello) lo decritta (visto criptato solo su vant-f, dimmi tu se ti risulta una cosa del genere anche sul vant6, i vecchi modelli non ce l'hanno criptato, i nuovi nemmeno, solo qualcuno nel mezzo), forse lo controlla e poi lo avvia. A te lo stage-2 sta palesemente funzionando. Quindi l'unpacking e l'eventuale decrypt e controllo è andato a buon fine. Ripassando lo stage1 con binwalk, nel caso in cui sia criptato binwalk rileva solo degli IV per AES (ma a questo punto grazie alle tue prove sappiamo per certo che dentro ci sono anche le chiavi), nel caso in cui invece non lo sia binwalk rileva il payload LZMA, e lo spacchetta correttamente.
Le chiavi che il dispositivo usa per i vari controlli che fa sono sparpagliate secondo ragionevoli logiche: alcune sono nella partizione eripv2 (ECK, EIK, OSCK, OSIK - le prime criptano e firmano le seconde), le altre che mancano all'appello, BEK (cripta ECK) ed MCV (firma EIK) sono chissà dove da qualche parte tra il bootloader e l'hardware (in quest'ultima eventualità sarebbe quella manciata di byte dell'OTP del SoC). Per ricavare le altre infatti di solito ci andiamo a prendere ECK già decriptata direttamente dalla ram.
Pragmaticamente, se come ipotizzo quel "chip id" è fuso nell'OTP del SoC, leggendo quello del Sercomm, e mettendolo nell'eripv2 al posto di quello del tuo vant6 (si da il caso che quel tag non sia né firmato né criptato, ma magari esiste un check sulla eripv2 intera di cui non sono a conoscenza) dovresti ottenere qualcosa di buono. Per verificare o confutare queste mie ipotesi puoi:
- andare a cambiare di poco il valore del campo FACTORY_RELEASE_DATE (è il primo che ho visto per il quale una volta modificato non vedo palesi incoerenze con gli altri campi) nell'eripv2 del vant6 e rimettere al suo posto la nand. se carica correttamente e legge correttamente il nuovo valore di quel campo allora l'intera eripv2 non viene passata sotto verifica integrità
- rifai la stessa cosa ma stavolta cambia il valore di Chip ID, se ottieni sul vant6 lo stesso errore che hai sul sercomm abbiamo capito tutto, se invece continua a funzionare, allora non ho capito niente
Se hai intenzione di portare avanti il progetto Cerbero, secondo me ti conviene prima tentare ed eventualmente risolvere lo swap tra due vant6, chiamalo come preferisci. Ad ogni modo per entrambi ti conviene creare un thread separato. Provvederò a spostare da qui questi ultimi miei messaggi se riporti una sintesi di quanto detto riguardo cerbero nel nuovo thread.
