Domanda:
Quali sono i metodi migliori per documentare la ricerca sull'ingegneria inversa di un formato di file?
Ross Spencer
2013-04-05 05:21:52 UTC
view on stackexchange narkive permalink

Conduco ricerche che richiedono i formati di file di reverse engineering e attualmente sto cercando modi per documentare questo lavoro.

Sul web troverai risorse che utilizzano diagrammi a riquadri e testo libero. Ad esempio, questo tentativo di esaminare Microsoft Access: https://github.com/brianb/mdbtools/blob/master/HACKING

Questo è abbastanza coerente con l'approccio adottato nelle specifiche ISO per i formati.

Questo tipo di lavoro fa parte di ciò che faccio professionalmente, ma non ho trovato nulla che mi aiuti a memorizzare le mie informazioni in modo coerente e utile per chiunque altro - mesi dopo la linea potrebbe anche non essermi utile.

Esiste una best practice della "comunità" (metodi, strumenti, strumenti di creazione ecc.) per aiutare a documentare la ricerca in un formato di file?

Non ho sentito niente del genere; nessun modo standardizzato per documentare i formati di file e nessuna applicazione specializzata per assistervi.
Quattro risposte:
#1
+7
Runium
2013-04-05 06:40:12 UTC
view on stackexchange narkive permalink

Concordo con V e tirando fuori solo alcuni pensieri.

In generale, direi che uno, (ovviamente), deve chiaramente indicare i buchi come neri o grigi. Come in "nessuna idea" o "diverse possibilità" .

Oltre alle specifiche del formato dei file distribuite apertamente, trovo che lo stile utilizzato dalle RFC sia quello che adeguo frequentemente. Tutto dipende dal contesto usando cose come Augmented Backus – Naur Form come mostrato qui.

Usa tabelle di verità ed espressioni logiche per affermare la non ambiguità.

Altrimenti c'è ad es 3GPP e simili da cui si può anche imparare.

Se vuoi optare per il buon stile ASCII usa strumenti come asciiflow per i diagrammi di flusso ecc. Mi sono accorto che usare ASCII spesso mi aiuta a scrivere documenti più chiari e dividere diagrammi in strati di forma più comprensibile. Forse si può imparare qualcosa anche da phrack.

Se non è testo semplice, allora LaTeX è molto utile per organizzare i documenti. Separa ogni sezione nei file che uno include. Mescolare le sezioni diventa facile così come l'indicizzazione, ecc. E il prodotto sembra fantastico sulla carta. - Questo può ovviamente essere fatto in qualche modo con il testo in chiaro.

Come con qualsiasi approccio (io) usa sempre Git e commetti molto frequentemente con brevi commenti concisi.

+1 per `asciiflow`, molto utile e Augmented BNF
Un'alternativa offline ad asciiflow è l'editor JavE, http://jave.de/ (un'applicazione Java standalone).
@hlovdal:Great. Quello riporta ricordi :). Lunga vita al Re btw;)
#2
+4
0xC0000022L
2013-04-05 08:00:14 UTC
view on stackexchange narkive permalink

In passato i miei sforzi di reverse engineering dei formati di file erano documentati nel codice sorgente , cioè 010 modelli binari dell'editor. Se conosci il C, questo è piuttosto descrittivo, ma ha i suoi limiti ea volte può diventare un po 'complicato quando si cerca di esprimere certi concetti più esotici. Un altro problema con lo strumento in quanto tale è la lentezza con script più grandi su file più grandi e la mancanza di un meccanismo di estensione oltre agli script e ai modelli binari (come i plugin).

Un'alternativa ampiamente utilizzata, al menzionato Augmented BNF, è ASN.1 ( permalink). Preferisco la codifica BER (vedi il collegamento precedente all'articolo di Wikipedia), ma il tuo chilometraggio può variare.

Per le rappresentazioni grafiche ho usato LaTeX (con bytefield , PDF) e Visio.

#3
+4
Ange
2013-04-10 23:59:38 UTC
view on stackexchange narkive permalink

Come @ 0xC0000022L, tendo a documentare prima nel codice sorgente, o in qualcosa che può essere immediatamente riutilizzato in uno strumento (a differenza di una semplice documentazione di testo).

Un approccio generico è usare un editor esadecimale che ha alcune capacità di annotare o descrivere strutture

con capacità di colorazione

con modelli

con strutture

  • IDA: può sembrare strano usare IDA come editor esadecimale, ma puoi creare strutture (o importarle da un file .H), quindi applicarle, creare uno script per concatenarle - e alla fine hai uno script IDAPython già pronto e le strutture pronte per l'uso per la prossima volta incontri quel formato: costruisci gli strumenti futuri progressivamente e salti la parte del testo della documentazione;)
    • ancora meglio, ti consente di ricreare il file da zero con queste strutture definite, il che è buono per sperimentare / in seguito fuzzing.
Neo sembra promettente.
Grazie per le informazioni. Disassemblatore IDA? https://www.hex-rays.com/products/ida/index.shtml
ovviamente - ha aggiunto il collegamento
ok, forse non così ovvio allora - sono ufficialmente strano ora;)
#4
+2
RobotHumans
2013-04-05 05:48:20 UTC
view on stackexchange narkive permalink

Non riesco a pensare a niente di più "standard" dei diagrammi a blocchi, un'implementazione di pseudo-codice e possibilmente un'implementazione di riferimento.

Prendiamo ad esempio lo standard FIPS qui o il documento standard LUKS. Forniscono una descrizione di base della funzionalità, pseudo-codice e, nel caso di OGG / OGV, anche un'implementazione di riferimento completa. Uno standard che hai smontato, secondo me, dovrebbe essere documentato nello stesso modo in cui viene documentato uno standard che hai progettato. Alcuni campi possono essere "sconosciuti" o "sembra essere magico, lascialo".

Non credo che troverai niente di più standard di quello che è. Se non ti dispiace pubblicare un documento e un parser, github / bitbucket / ecc sono fantastici. Alcune delle altre domande sul formato dei file puntano a Wotsit.org (guardo lì), quindi inviare un collegamento potrebbe essere una buona cosa.



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...