[Sammlung] Reversing fit-image Format

[hippie2000]

Hallo,

wie einige schon bemerkt haben gibt es bei einigen Geräten in der Firmware kein kernel.image / filesystem.image sondern ein fit-image in /var/tmp. Das betrifft bisher 3 Modelle, es werden aber sicherlich mehr:

fit-image - Firmware-Files - BoxMatrix

fit-image - [[FIT-Image]] of one or more [[rootfs]], kernel, device tree and config files. - BoxMatrix FRITZ!Box Research Wiki

boxmatrix.info

FIT steht für Flattened Image Tree und ist ein Binärformat das strukturiert auch mehrere Kernels, Filesystems, Device Trees und Configs enthalten kann. Das Format ist eine lineare Abbildung eines Datenbaums. FIT wird vom Uboot Bootloader unterstützt, aber ich finde da keine Includes die mir helfen es zu parsen. Möglicherweise weicht das AVM-Format vom Uboot-Format ab.

Ein grobes Verständnis über den Inhalt eines FIT bietet dieser Artikel ab Seite 14:

http://www.denx.de/wiki/pub/U-Boot/Documentation/multi_image_booting_scenarios.pdf

Die Blobs aus einem FIT-Image zu extrahieren ist kein Problem, aber um Freetz das Format beizubrigen muss man die Struktur komplett verstehen, da es ein FIT mit modifiziertem Inhalt generieren muss.

FIT enthält einen 128-bytes Header der eine 4-bytes Signatur enthält. Weitere Details über den Headers siehe den fit-test.txt unten. Im Header befinden sich 4 Pointer, die bei Modifikationen um die Differenz von Original und Mod geändert werden müssen. Etwas Sorge macht mir ein cryptisch erscheinender Teil des Headers. Wenn das kein Assembler ist ist das hoffentlich keine RSA Signatur oder Dergleichen, dann fällt Modden flach.

Nach dem Header kommt eine Hunkstruktur (eine linked List) die jeweils einen Hunk Header und die Payload des Hunks enthält. Jeder Hunk ist auf 32-bit mit Nullen gepaddet, ausser der letzte Hunk 'description', der sein Stringarray nicht paddet, wodurch Hunk End ODD ist. Alle Hunk-Strukturen sind immer Little Endian, auch wenn die Payload Big Endian ist.

Ich habe gerade einen Parser für das FIT-Format geschrieben, eine Art Hunkwalk für FIT und werde hier meine Erkenntnisse veröffentlichen damit nicht mehrere Leute an der selben Sache schaffen müssen. Ich kenne nun alle Hunkstrukturen, und werde den Hunktypen als Nächstes Namen geben.

Das oben genannte Stringarray enthält Namen für einige Hunktypen, auch einige von AVM hinzugefügte. Hier liegt wohl auch der Grund dass das 32-big Padding gebrochen ist, AVM hat's wohl vermurkst Leider lässt sich für die AVM Hunktypen keine modellübergreifende Zuordnung Hunktyp nach Hunkname festlegen, da diese sich änderten. Die wichtigen Non-AVM Hunks sind aber global benennbar.

Hier der Zwischenstand nach einem Tag, die Datei werde ich mit dem Fortschritt weiter aktualisieren:

Verbose:

http://boxmatrix.info/hosted/temp/fit-test.txt

Short:

http://boxmatrix.info/hosted/temp/fit-short.txt

Trotzdem suche ich auch Hilfe da ich nicht alles alleine Reversen kann bzw will.

Meine erste Frage um Mithilfe: Kann jemand der gut Dissassemblieren kann nachsehen ob im 128-bytes Header 0x08-0x4C der Images Assembler enthalten ist?

Meine zweite Frage um Mithilfe: Kann jemand der sich mit Uboot gut auskennt nachsehen ob im Quelltext da hilfreiche Information zur Headerstruktur zu finden ist? Das uboot-fit Verzeichnis hab ich gestöbert und die docs gelesen, fand aber nichts.

Ich kann jetzt ein FIT komplett zerlegen. Nun gehts um die Erforschung der enthalteten Metadaten wie Checksummen, Loadaddresses, Entrypoints usw.

Was sehr praktisch ist: Alle Hunks sind relokatibel, man kann also mit der Schere ein Set Hunks ausschneiden und austauschen und muss nur wenig anpassen. Man muss natürlich darauf achten dass die Loadadressen und die Blob Grösse nicht überlappen und dass die Checksums stimmen.

Hunktyp 65 ist immer der Blob der zu checksummen ist, verwendet wird der Standard CRC32 Algorithmus ohne spezielle Initvalue. Habe im fit-test.txt oben alle Checksummen nachgerechnet, es wird gottseidank der Blob wie er ist gehasht, nicht erst wenn er ausgepackt ist. Der Hash des Blobs wird dann in Hunktyp 111 geschrieben. Ein Austausch ist damit einfach.

Im Header fand ich keine globale Checksum, weder CRC32 noch MD5 noch SHA1 des Bodies.

Diesen Artikel werde ich mit der Zeit Editieren, wer einen Aufsatz erwartet (ich will ja keinen Namen nennen) muss sich gedulden

FIT-Manipulations Executable

Ich hab jetzt ein Programm geschrieben das ich heute releaste, und einen eigenen Thread dafür:

[Info] - Software: fitimg AVM fit-image Manipulator

Hallo, für alle Freetz-Forks und andere Modding-Projekte habe ich ein Programm namens fitimg zum Hantieren der neuen fit-image Dateien geschrieben. fitimg kann hier heruntergeladen werden (GPLv2+) : https://boxmatrix.info/wiki/FIT-Image fitimg ermöglicht es fit-images zu listen, testen, zu...

www.ip-phone-forum.de

 

[Joe_57]

Diesen Artikel werde ich mit der Zeit Editieren

Mach das doch bitte gleich.
Und entferne diese absolut überflüssigen Leerzeilen.
Vielleicht kann man dann durch passende Absätze auch dein Anliegen/dein Problem/deine Frage erkennen.

Danke!

 

[fda89]

Kann jemand der sich mit Uboot gut auskennt nachsehen ob im Quelltext da hilfreiche Information (Includes, Parser) zu finden ist?

Ich hab zu keinem der 3 Geräte Quelltext gefunden. Hast du AVM schon danach gefragt? Ansonsten wird es schwierig darin etwas nachzusehen

Was bedeutet deine Ausgabe oben und wie kommst du dazu? Oder ist das closed-source?

Nur entpacken ist doch kein Problem, im Gegensatz zum packen

tar xf FRITZ.Box_5530-07.24-83487-Inhaus.image

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
72            0x48            device tree image (dtb)
312           0x138           LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3854497 bytes
1191460       0x122E24        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 3366 bytes
1192776       0x123348        gzip compressed data, maximum compression, from Unix, last modified: 2020-11-12 17:20:53
2896436       0x2C3234        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 12220645 bytes
6190856       0x5E7708        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 39086 bytes
6199004       0x5E96DC        LZMA compressed data, properties: 0x5D, dictionary size: 8388608 bytes, uncompressed size: 38839 bytes
6207116       0x5EB68C        gzip compressed data, maximum compression, from Unix, last modified: 2020-11-12 17:22:46
41039221      0x2723575       Zlib compressed data, default compression
41040117      0x27238F5       Zlib compressed data, default compression
41041557      0x2723E95       Zlib compressed data, default compression
41070373      0x272AF25       Zlib compressed data, default compression

 

[hippie2000]

@fda89:

Natürlich hab ich Binwalk als erstes getestet, das findet aber nur Signaturen.

Meine Ausgabe ist keine Signatursuche sonden Analyse der Daten, um sie parsen und verstehen zu können. Schau sie mal erneut an, ich fahr den Parser seit eben über alle 3 FIT-Modelle.

Es gibt einen festen 128-byte Header mit 4-bytes Signatur ab der ein Hunkformat kommt. Das parse ich. Jeder Hunktyp hat seine eigene Berechnung wie gross er ist, und ich hangle mich so durch das Binary, komme fast bis zum Schluss durch.

Nach und nach werde ich den Hunktypen Namen geben bis wir irgendwann selbst ein FIT-Image mit dem recherchierten Wissen generieren können.

Ich mach das gerne OSS, aber das ist erst mal ein Quickie um das Format zu verstehen. Wenn jemand das - sobald es fertig ist - auf eine Sprache die in Freetz passt portieren will kriegt er gerne meinen Perl Quelltext - aber zum Releasen ist der zu dirty.

Ich fürchte der AVM Quelltext wird da wenig hilfreich sein, da ein FIT vom Kernel an alles enthält, also von einem Bootloader oder Flash Updater gelesen wird. Ersteres könnte natürlch Uboot sein, daher meine Frage nach Uboot Profis...

Gegen meine These im Quelltext wäre nix steht dass ich in Supportdata der 7530ax (von den anderen beiden Modellen hab ich leider keins) zwei Partitionen fit0 und fit1 fand:

fit0 - Linux-Partitions - BoxMatrix

fit0 - The first FIT-Image partition. - BoxMatrix FRITZ!Box Research Wiki

boxmatrix.info

Es kann natürlich sein dass der Flash-Updater die Partitionen braucht um das FIT zu flashen. Die inaktive Partition kann ja im Betrieb geschrieben werden.