Domanda:
Quali tecniche vengono utilizzate nel firmware embedded di reverse engineering?
drewbug
2013-04-03 23:49:31 UTC
view on stackexchange narkive permalink

Questa domanda è correlata a un'altra domanda che ho pubblicato qui.

Sto lavorando con una piccola agenzia di trasporto pubblico per un progetto sorgente che ci aiuterà a offrire dati in tempo reale agli sviluppatori locali. Un dato fondamentale di cui abbiamo bisogno è l'attuale percorso di autobus su cui si trova un determinato veicolo. Attualmente, esiste un solo sistema elettronico che conosce queste informazioni: l'unità logica del veicolo (VLU) di cui è dotato ciascun veicolo.

Quando un conducente di autobus inizia un percorso, digita il suo numero ID nel tastierino sull'unità di controllo operatore (OCU). Questo numero ID viene inviato alla VLU, che quindi visualizza il testo appropriato sui segnali LED sul bus.

Sulla OCU sono presenti due porte DB9F. Nel manuale sono descritti come "PORTE J1708". Uno di questi è collegato alla VLU e l'altro è disponibile per il collegamento. Il collegamento ad esso mi fornisce alcuni dati di cui puoi leggere nella mia altra domanda.

Quello che vorrei fare è decodificare il firmware della VLU e vedere come funziona decide quali dati inviare o come interpretare i dati ricevuti. Da quello che posso dire, il firmware utilizza RTTarget-32 come base. Credo che questo sia il caso perché le seguenti stringhe possono essere trovate nel file del firmware:

  RTTarget-32 5.0 Codice di avvio a 16 bit (c) 1996,2006 On Time Informatik On Time RTOS-32 5.0 Disk Loader (c) 1996,2009 On Time  

Non ho postato un collegamento al file del firmware perché so che il collegamento a file esterni è generalmente disapprovato sui siti SE. Se dovessi caricarlo, tuttavia, quale host di file dovrei usare?

Quindi, come afferma il titolo della mia domanda, quali tecniche dovrei usare per iniziare il reverse engineering di questo file firmware?

Due risposte:
#1
+6
dyasta
2013-04-05 02:29:07 UTC
view on stackexchange narkive permalink

L'inversione del formato del firmware può comportare molte cose diverse, a seconda del livello di difficoltà.

Inizieresti con l'analisi manuale con un editor esadecimale.

Se i dati appaiono ben strutturati, ad eccezione dei blocchi che appaiono compressi (alcuni caratteri di testo in chiaro visibili qua e là), allora probabilmente non è offuscato.

Se sembra tutto senza senso con poca o nessuna struttura (ad esempio poche esecuzioni di 0), dovrai disassemblare il boot loader (scaricato dal dispositivo) per estrarre l'algoritmo di offuscamento, supponendo che tu possa Non indovinare.

Da lì, inizia a identificare i campi di intestazione e le parti componenti dell'immagine del firmware. La maggior parte avrà un kernel e un file system compresso. Spesso ci sono offset nell'intestazione, che puntano ai componenti del firmware.

Ti consigliamo di provare BinWalk, per vedere se identifica componenti comuni nel formato del file . È progettato esattamente per questo compito. In genere funziona meglio sui firmware Linux, che utilizzano comuni filesystem open source come squashfs o jffs2, ma vale la pena provare qui.

probabilmente dovresti menzionare anche il tuo: https://code.google.com/p/firmware-mod-kit/ ... in effetti sembra che `binwalk` si basi in parte su alcuni script di` firmware-mod- kit`. E vale anche il contrario, il tuo progetto * include * `binwalk` :) ... ho appena usato` extract-firmware.sh` pochi minuti fa, quindi non ho potuto fare a meno di commentare. +1
Mi sento sempre strano nel menzionare cose in cui sono coinvolto. Sì, gli script più recenti del Firmware Mod Kit si basano su Binwalk per identificare i segmenti del firmware, quindi agiscono in base alle identificazioni di Binwalk. Registrando il layout, potrà poi ricostruirli. Binwalk stesso può ora estrarre file system incorporati. Craig Heffner lavora su entrambi, quindi i crediti a lui.
#2
+3
cb88
2013-04-04 00:30:29 UTC
view on stackexchange narkive permalink

On Time ha un kit di valutazione qui che potrebbe aiutarti a saperne di più. Sembra che venga eseguito su hardware abbastanza standard. Nel peggiore dei casi potresti dover scaricare una eeprom e decompilarla con IDA o simili.

http://en.wikipedia.org/wiki/J1708

Il protocollo per queste porte è aperto. Quindi potresti persino comunicare con esso dal tuo codice. Strano che sia RS-485 piuttosto che RS-232 (è fondamentalmente una versione bus di RS-232 e probabilmente avresti bisogno di una scheda diversa per usarla). La pagina wiki lì elenca i possibili protocolli di livello superiore che potresti provare a indagare.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...