Frage:
Was sind die Best-Practice-Methoden zur Dokumentation der Forschung zum Reverse Engineering eines Dateiformats?
Ross Spencer
2013-04-05 05:21:52 UTC
view on stackexchange narkive permalink

Ich führe eine Recherche durch, die die Reverse Engineering-Dateiformate erfordert, und suche derzeit nach Möglichkeiten, diese Arbeit zu dokumentieren.

Im Web finden Sie Ressourcen, die Boxdiagramme und freien Text verwenden. Beispiel: Dieser Versuch, Microsoft Access zu betrachten: https://github.com/brianb/mdbtools/blob/master/HACKING

Dies steht im Einklang mit dem gewählten Ansatz in ISO-Spezifikationen für Formate.

Diese Art von Arbeit ist Teil meiner beruflichen Tätigkeit, aber ich habe nichts gefunden, was mir helfen könnte, meine Informationen auf konsistente und nützliche Weise für andere zu speichern - Monate später die Linie könnte es nicht einmal für mich nützlich sein.

Gibt es eine bewährte Community-Methode (Methoden, Tools, Authoring-Tools usw.), mit deren Hilfe die Recherche in einem Dateiformat dokumentiert werden kann?

Ich habe von nichts in dieser Richtung gehört; Keine standardisierte Methode zum Dokumentieren von Dateiformaten und keine spezielle Anwendung, die Sie unterstützt.
Vier antworten:
#1
+7
Runium
2013-04-05 06:40:12 UTC
view on stackexchange narkive permalink

Stimmen Sie mit V überein und werfen Sie nur einige Gedanken aus.

Im Allgemeinen würde man sagen, dass man (natürlich) Löcher eindeutig als schwarz oder grau bezeichnen muss. Wie in "keine Ahnung" oder "mehrere Möglichkeiten" .

Neben offen verteilten Dateiformatspezifikationen finde ich den von RFCs verwendeten Stil einen, den ich anpasse häufig. Alles abhängig vom Kontext, in dem Dinge wie Augmented Backus-Naur Form verwendet werden, wie hier gezeigt.

Verwenden Sie Wahrheitstabellen und logische Ausdrücke, um Eindeutigkeit zu behaupten. P. >

Sonst gibt es zB 3GPP und dergleichen, von dem man auch lernen kann.

Wenn Sie sich für den guten ASCII-Stil entscheiden möchten, verwenden Sie Tools wie asciiflow für Flussdiagramme usw. Ich habe festgestellt, dass die Verwendung von ASCIIoften mir hilft, klarere Dokumente und aufgeteilte Diagramme in Schichten mit verständlicherer Form zu schreiben. Vielleicht kann man auch etwas von phrack lernen.

Wenn es kein einfacher Text ist, dann LaTeX, da es sehr gut zum Organisieren von Dokumenten geeignet ist. Teilen Sie jeden Abschnitt in eigene Dateien auf, die Sie enthalten. Das Mischen in Abschnitten wird ebenso einfach wie das Indizieren usw. Und das Produkt sieht auf dem Papier großartig aus. - Dies kann natürlich auch auf irgendeine Weise mit Klartext erfolgen.

Wie bei jedem Ansatz (I) verwenden Sie immer Git und legen Sie sehr häufig mit kurzen, prägnanten Kommentaren fest.

+1 für `asciiflow`, sehr nützlich und Augmented BNF
Eine Offline-Alternative zu asciiflow ist der Editor JavE, http://jave.de/ (eine eigenständige Java-Anwendung).
@hlovdal:Great. Das bringt Erinnerungen zurück :). Es lebe der König übrigens;)
#2
+4
0xC0000022L
2013-04-05 08:00:14 UTC
view on stackexchange narkive permalink

In der Vergangenheit wurden meine Reverse Engineering-Bemühungen für Dateiformate in der Quelle dokumentiert, d. h. 010 Editor-Binärvorlagen. Wenn Sie C kennen, ist dies ziemlich beschreibend, aber es hat seine Grenzen und manchmal kann es etwas verworren sein, wenn Sie versuchen, bestimmte exotischere Konzepte auszudrücken. Ein weiteres Problem mit dem Tool als solchem ​​ist die Langsamkeit bei größeren Skripten für größere Dateien und das Fehlen eines Erweiterungsmechanismus über die Skripte und Binärvorlagen (wie Plugins) hinaus.

Eine weit verbreitete Alternative zu Augmented BNF ist ASN.1 ( Permalink). Ich bevorzuge die BER-Codierung (siehe vorherigen Link zum Wikipedia-Artikel), aber Ihr Kilometerstand kann variieren.

Für grafische Darstellungen habe ich LaTeX verwendet (mit Bytefeld , PDF) und Visio.

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

Wie @ 0xC0000022L neige ich dazu, zuerst in der Quelle oder in etwas zu dokumentieren, das sofort in einem Tool wiederverwendet werden kann (im Gegensatz zu einer reinen Textdokumentation).

Ein generischer Ansatz ist die Verwendung von a Hex-Editor mit einigen Fähigkeiten zum Kommentieren oder Beschreiben von Strukturen

mit Farbfähigkeiten

mit Vorlagen

  • 010-Editor Viele Vorlagen verfügbar, nicht einfach manuelle Färbung, aber empfohlen
  • Hex-Workshop netter Konkurrent, begrenzte Skripterstellung und Verfügbarkeit
  • Hex-Editor Neo interessante Funktionen (Mehrfachauswahl ) aber schwer

mit Strukturen

  • IDA: Es kann seltsam klingen, IDA als Hex-Editor zu verwenden, aber Sie können Erstellen Sie Strukturen (oder importieren Sie sie aus einer .H-Datei), wenden Sie sie dann an, erstellen Sie ein Skript, um sie zu verketten - und am Ende haben Sie ein vorgefertigtes IDAPython-Skript und die Strukturen, die für das nächste Mal verwendet werden können Sie stoßen auf dieses Format: Sie erstellen die zukünftigen Tools schrittweise und überspringen den Dokumentationstextteil;)
    • noch besser, es ermöglicht Ihnen, die Datei mit diesen definierten Strukturen von Grund auf neu zu erstellen, was gut zum Experimentieren ist / Fuzzing danach.
Neo sieht vielversprechend aus.
Danke für die Information. IDA Disassembler? https://www.hex-rays.com/products/ida/index.shtml
offensichtlich - fügte den Link hinzu
ok, dann vielleicht nicht so offensichtlich - ich bin jetzt offiziell komisch;)
#4
+2
RobotHumans
2013-04-05 05:48:20 UTC
view on stackexchange narkive permalink

Ich kann mir nichts "Standard "es als Blockdiagramme, eine Pseudocode-Implementierung und möglicherweise eine Referenzimplementierung vorstellen.

Nehmen Sie zum Beispiel den FIPS-Standard hier oder das LUKS-Standarddokument. Sie bieten eine grundlegende Beschreibung der Funktionalität, des Pseudocodes und im Fall von OGG / OGV sogar eine vollständige Referenzimplementierung. Ein Standard, den Sie auseinander genommen haben, sollte meiner Meinung nach genauso dokumentiert werden, wie ein von Ihnen entworfener Standard dokumentiert ist. Einige Felder sind möglicherweise "unbekannt" oder "scheinen magisch zu sein, lassen Sie es einfach".

Ich glaube nicht, dass Sie mehr Standard finden werden. Wenn es Ihnen nichts ausmacht, ein Dokument und einen Parser zu veröffentlichen, sind github / bitbucket / etc großartig. Einige der anderen Fragen zum Dateiformat verweisen auf Wotsit.org (ich sehe dort nach), daher könnte es auch eine gute Sache sein, dort einen Link zu senden.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...