Ich frage mich wie man vorgeht um die Firmware einer unbekannten Plattform zu disassemblieren. IDA Pro wäre vorhanden, sowie ein paar Grundkenntnisse zum Thema. Als Übungsobjekt habe ich ein Firmware-Update meiner Dashcam (Nextbase 212G) angehangen. Ich habe das Gerät, da neu, noch nicht geöffnet, weiss also nicht was drin werkelt. Wie würdet ihr vorgehen? Erfahrungswerte nutzen? Das Image nach Signaturen durchkämmen? Analysetools nutzen?
Erstmal mehere Geräte anschaffen, damit man Verlustmaterial hat. Gerät öffnen und auslesen Im Binary nach Strings und Signaturen suchen. Auf nen Skandal warten, der die Firma zum Update zwingt. Im Update ist dann meist der Grund vermerkt. Update machen und ein Diff des alten Binarys mit dem neuen. Dann kennt man schon die sicherheitsrelevanten Stellen. Job in der Entwicklungsabteilung der Firma erstreben. Sich an den Entwicklungsingenieur ranmachen. Quelltext kopieren. Sich freuen. Jetzt kann man auch sehen, was IDA denn so aus dem Binary/Quellcode gemacht hat. ;--) Fazit: Ida hilft erst nach langer Zeit, ein bissel "Gegenspionage" macht eher Spaß!!! ;--))))) mfg
Ich suche immer gern nach der FCC-ID, da findet man auch interne Fotos und mit etwas Glück erkennt man den Prozessortyp... Strings untersuchen, ja, das ist auch eine Idee, aber was sucht man da?
Olli Z. schrieb: > unbekannten > Plattform zu disassemblieren. Tja.
Olli meinte: > Strings untersuchen, ja, das ist auch eine Idee, > aber was sucht man da? Nach Referenzen ins internet, wie URL's zum Beispiel, nach Standard Passwörtern. Da sollte man denn auch mal ROT13 übers Binary laufen lassen. Vor allem ist es wichtig, den Compiler zu kennen. Dann kann man nämlich eigene Funktionen schreiben und sehen, was IDA draus macht, wo sind die Frames, wo die Datensegmente u.s.w. mfg
Gast
#6096345
Nunja, das Firmware.bin ist erst mal nur Codeblob mit einem Header. Keine Ahnung ob das noch weiter struckturiert ist. Ist aber scheinbar nicht verschlüsselt. Das Problem hier ist, unbekannte CPU und unbekannter Adressbereich, also wo das Ding hingeladen wird.
Gast
#6096355
Die Bezeichnung "IMX322LQJ" taucht im bin auf.
. . schrieb im Beitrag
#6096355:
> Die Bezeichnung "IMX322LQJ" taucht im bin auf.
Dann hätten wir schonmal den Bildsensor gefunden :-)
. . schrieb im Beitrag #6096345: > Das Problem hier ist, unbekannte CPU und unbekannter Adressbereich, also > wo das Ding hingeladen wird. Ganz genau, das ist die Challenge :-) Also bei Imageuntersuchung habe ich auch nach Compilernamen und ähnlichem gesucht. Also wäre eine Idee nach Strings zu googlen die nicht lesbarer Text sind in der Hoffnung das eine Chipbezeichnung passt? Ich bin mir auch nicht sicher ob das Update-Image wirklich die volle Firmware, oder wenigstens die vollständige Applikation enthält oder nur einen Patch.
Gast
#6096380
hmm, MIR3D? Ist dar ein Barcodesensor drin? Hat das Ding Wifi? Einige Strings deuten darauf hin. Das ist vielleicht ein "Universalupdate" für verschiedene Modelle, oder da ist Zeug drin, welches da nicht rein gehört.
Gast
#6096381
Und was mag "only_Thisan" bedeuten?
. . schrieb im Beitrag #6096380: > hmm, MIR3D? Ist dar ein Barcodesensor drin? Nope. > Hat das Ding Wifi? Einige Strings deuten darauf hin. Ebenfalls nicht. > Das ist vielleicht ein "Universalupdate" für verschiedene Modelle, oder > da ist Zeug drin, welches da nicht rein gehört. Definitiv. Der Hersteller hat so einige Modelle am Start und wird nicht jedesmal neue Firmware produzieren. Ganz am Anfang des Images steht "NT96650" und das ist zufällig ein "Novatek NT96650BG-ES" für den, wenn man einfach mal nach Googled, gleich ein Datenblatt findet :-) "High Performance 32-bit CPU, MIPS32 24Kec with ASE DSP extension". Dann würde ich mal tippen "MIPSB (Big Endian)". Leider findet er aber keinen Code.
Wer ein bisschen Literatur zum systematischen Vorgehen haben möchte, allerdings nicht speziell für Embedded https://www.amazon.com/Practical-Reverse-Engineering-Reversing-Obfuscation/dp/1118787315
Was ich auch immer gern mach ist die Dateigröße im Header eines Image zu suchen um sowas wie eine Struktur zu entdecken. Oft wird aber nicht der gesamte Teil sonder nur der Nutzdatenteil angegeben, also suche ich immer nach einem Wert <= der Gesamtlänge. Die Gesamtlänge ist 0x00230FCE und gleich in den ersten 16 Byte werde ich an 0x0000 000C fündig: 0x00230FBE:
1 | |
2 | |
3 | |
4 | |
Also 16 Bytes weniger als die Gesamtlänge. Damit startet für mich das Image ab Position 0x0000 0010. Der String "BCL1" ist sicher ein custom-magic filetype vom Hersteller, den ignoriere ich einfach mal. Dann wäre noch die Frage was die Bytesequenz: "9F CD 00 09" sowie "00 48 1A 6C" bedeuten? Auffällig ist auch, das die Binarylänge nicht 32-Bit aligned ist, da bleiben 2 Byte über. Hier denke ich immer gleich an eine CRC-16 Prüfsumme. Passt aber leider nicht. Was mir auch auffällt ist, das der restliche Bytecode auffälig oft "0xBB" enthält. Jetzt kenne ich aber die MIPS Assemblersyntax überhaupt nicht, vielleicht ist das ja normal.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
Gast
#6096591
yup. Hier ist die Häufigkeit der Werte. od -vtu1 -An -w1 FW212GB.bin | sort -n | uniq -c > d1.txt sort -k1 -n -k2 d1.txt -o d2.txt
Such mal nach Novatek FW unpacking script von "nutsey".
Supported Novatek firmware types:
2 BCL partitions in a row.
1 FullComp BCL partition.
1 PartComp BCL partition.
Paula Q. schrieb: > Such mal nach Novatek FW unpacking script von "nutsey". Das war ein sehr guter Hinweis! Habe dieses Tool herunterladen und ausführen können (hätte jetzt gern gewusst wie es arbeitet, aber Sourcen waren nicht zu finden):
1 | |
2 | |
3 | |
4 | |
Also offensichtlich ist das doch komprimiert, nur das der Text weitesgehend erhalten blieb... schlau ;-) Also ist der Algo eher kein RLE sondern was anderes. Naja... Diesen entpackten Code kann ich nun mit "MIPS (Big Endian)" laden und ab Adresse 0x400 sah es mir nach Code aus. Dort mal bei IDA "c" gedrückt und schon erhalte ich zahlreiche Subs! :-) Das Resultat scheint mir jetzt noch kein direktes Firmware-Image für den Prozessor zu sein, sondern noch ein Format aus dem u.a. die Firmware in das Flash geladen wird. Ganz sicher bin ich mir aber nicht.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
70 | |
71 | |
72 | |
73 | |
In der Datei findet sich auch sowas:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
Also wurde da Text, warum auch immer, in Words gepackt, also wohl nur das HIWORD genutzt. Ich gehe bislang noch von einer 32-Bit Architektur aus. Womöglich war aber Platz kein Problem und einfacher als aus einem Word zwei ASCII-Zeichen zu machen?!
Olli Z. schrieb: > Also wurde da Text, warum auch immer, in Words gepackt, UTF-16 macht sowas. Der BOM ist ja auch mit dabei (0xFEFF)
Um das Dunkle für euch noch ein wenig heller zu dimmen, noch einige Links http://git.p-mc.eu/ntk/bfc4ntk http://git.p-mc.eu/ntk-leaks
Dirk B. schrieb: > Olli Z. schrieb: >> Also wurde da Text, warum auch immer, in Words gepackt, > > UTF-16 macht sowas. > Der BOM ist ja auch mit dabei (0xFEFF) Ja, stimmt, daran hatte ich nicht mehr gedacht...! Vor jedem String steht das. Aber da es immer 0xFF 0xFE ist, würde das doch auf Little Endian deuten. Auch das das "Nutz"-Byte des Word zuerst kommt deutet stark auf LE. Diese Texte unterscheiden sich vom Rest da sie wohl am Display zu sehen sind und der überwiegende, ASCII-basierende Teil sind interne Meldungen von Libs und fürs Debugging. Komisch, bin bislang von Big Endian ausgegangen. Ok, the NT96650 kann laut Datenblatt beides. Womöglich kann er sogar während der Programmausführung umschalten? Ich hab von MIPS leider Null Peil, vielleicht gibt es da Initialisierungen, oder der Chip macht das aufgrund von Pins nach dem Reset?
Für mich sehen diese Datenblöcke irgendwie aus wie Bilder (vermutlich eher Icons), für Euch auch?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
Zumindest sieht das mit https://rawpixels.net/ ab Offset 0x88FEE mit einer Breite von 256 Pixeln dargestellte verdächtig nach einem Bild aus ;-)
Angehängte Dateien:
-
wifi_image_found.png
(15 KB)
Hallo, nachdem das ja beim ersten Mal gut geklappt hat, habe ich hier noch ein etwas komplizierteres Übungsobjekt :-) Es handelt sich um den Graphicprozessor eines Navigationssystems. Dieser wird mittels eines Cyclone-II (FPGA) erzeugt. Er lädt seine Firmware aus einem Flash-Speicher und auch einen externen SDRAM-Chip. Ein Dump des Flashs aus einem solchen System habe ich beigefügt (fx_graphicsboard_flash_S29GL...bin). Das ist von einer älteren Version der Firmware. Jetzt gibt es dazu eine Update-CD in der man u.a. die Datei "fgs.dnl" findet. Das Format dieser Datei habe ich wohl weitesgehend entschlüsselt. Im großen und ganzen verwendet der Updater diese um Paketweise die Daten an den Cyclone-II zu senden, welcher dann das Flash updated. Um aus der DNL wieder Einzeldateien zu erhalten habe ich mir ein kleines Programm in C geschrieben (dnl_unpack.exe). Die DNL besteht insgesamt aus 3 Dateien, flash_application_area_00070000.bin => Dies wird wohl die Hauptanwendung sein die ausgeführt wird. Laut DNL-Datei wird sie mit der Startadresse 0x70000 in den externen Flash geschrieben. flash_fds_area_00020000.bin => Enthält nur irgendwelche Konfigdaten flash_testmanager_area_00030000.bin => Keine Ahnung was das ist, vielleicht eine alternative Software für Funktionstests. Nun finde ich darin auch ein paar Strings, vor allem in der App sind zahlreiche, inkl. verschiedener Sprachen. Aber ich habe noch nicht raus welche Prozessorarchitektur mit dem FGPA emuliert wird. Ich vermute ARM, hab auch schon beides mal auf Gut Glück probiert, sowohl LE als auch BE, aber da bekomme ich nur Müll raus als Code. In der App findet man Hinweise zu einem uC/OS-II, was wohl das zugrundeliegende RTOS sein wird. Hier gibt es eine umfangreiche Doku dazu: https://doc.micrium.com/pages/viewpage.action?pageId=16879190 Gepackt oder verschlüsselt sehen mir die aus dem DNL extrahierten Dateien nicht aus. Einige Teile sind identisch mit dem Flash-Speicher Inhalt, obwohl es unterschiedliche FW-Versionen sind. So, ich bin erstmal ratlos... habt Ihr eine Idee wie man weiterkommt?
Angehängte Dateien:
-
navi-fx_displayboard_side1_expl.jpg
(220 KB)
-
navi-fx_displayboard_side2_expl.jpg
(190 KB)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.