Firmware disassemblieren

Was soll ich jetzt damit anstellen? Eine Möglichkeit, um mehr über das System herauszufinden, ist es, die Firmware zu disassemblieren. Dabei wird der binäre Maschinencode mit Hilfe eines Disassemblers in eine symbolische Assemblersprache umgewandelt, die ein Mensch versteht. Einfachere Varianten übersetzen den Maschinencode rein mechanisch in symbolische Instruktionen, bessere können den Programmablauf analysieren und auch die Struktur des Codes ermitteln. Manche Disassembler-Programme ermöglichen auch ein interaktives Vorgehen, so können Anmerkungen eingefügt oder die Übersetzung beeinflusst werden. Sogenannte Decompiler können sogar Maschinencode in höhere Sprachen übersetzen, wie zum Beispiel C oder Go.

Programme zum Disassemblieren

Stellenmarkt
  1. Trainee Finance & Controlling (m/w/d)
    AOK PLUS - Die Gesundheitskasse für Sachsen und Thüringen, Dresden, Erfurt
  2. (Senior) Android Software Engineer*
    IAV GmbH, Berlin, Gifhorn
Detailsuche

Ich benötige ein Werkzeug, mit dem ich auf einen Codebereich schauen und Anmerkungen einfügen kann, während ich lerne, den Code zu verstehen. Deswegen schaute ich mir verschiedene Disassembler an.

IDA ist eines der besten kommerziellen Programme. Ich habe es schon vor zehn Jahren benutzt, und auch wenn es etwas schrullig war, hat es gut funktioniert und sollte heute sogar noch besser sein. Aber für die Analyse von ARM-Code ist es recht teuer und ich will für ein Hobbyprojekt nicht soviel Geld ausgeben.

Ich probiere auch einige Online-Disassembler, aber sie kommen mit meinem Speicherabbild nicht zurecht. Also probiere ich auch einige Open-Source-Programme aus. Manche sehen sehr provisorisch aus oder sind lange Zeit nicht aktualisiert worden. Trotzdem schaue ich mir einige genauer an.

Golem Akademie
  1. Jira für Anwender: virtueller Ein-Tages-Workshop
    10. November 2021, virtuell
  2. Ansible Fundamentals: Systemdeployment & -management: virtueller Drei-Tage-Workshop
    6.–8. Dezember 2021, Virtuell
Weitere IT-Trainings

Ich probiere Radare. Es scheint tauglich für meine Ansprüche, aber es wirkt, als ob die Programmierer an das Motto glauben: "Es war schwer zu schreiben, also sollte es auch schwer zu nutzen sein". Ich verstehe die Dokumentation nicht, sie wirkt wie eine Übersicht für Leute, die es bereits kennen. Und ich komme nicht mit der Benutzeroberfläche zurecht.

Capstone sieht vielversprechender aus. Es ist ein Fork von Bestandteilen in LLVM, die mit Maschinencode arbeiten. Mir gefällt die Idee, auf LLVM zurückzugreifen, denn es unterstützt viele Prozessoren und das würde auch für den Disassembler gelten. Aber Capstone bietet nur eine Infrastruktur und keine interaktiven Werkzeuge, die mir gefallen, und mir fehlt die Zeit, selber etwas zu schreiben.

Valgrind dient eigentlich zum Speichercheck. Es dekodiert den Maschinencode im Speicher und übersetzt ihn in eine Zwischensprache, fügt dann Code zur Speicherüberprüfung hinzu und übersetzt es wieder in Maschinencode zurück. Valgrind unterstützt ARM und die Zwischensprache sieht nutzbar aus. Aber auch hier handelt es sich eher um Infrastruktur ohne Benutzeroberfläche.

Schließlich stoße ich auf Medusa. Das Programm ist längst noch nicht fertig, es kann nicht alle Instruktionen übersetzen, läuft nicht immer stabil und hat noch einige Bugs. Allerdings kann ich aufgrund des offenen Quellcodes einige Fehler umgehen und die fehlenden Instruktionen ergänzen. Ich entscheide mich schließlich für das Programm.

Ich lade meine Datei in Medusa und beschäftige mich damit, wie das Programm funktioniert. Praktisch an Medusa ist dessen Datenbankformat. Es handelt sich um eine Textdatei in einem leicht verständlichen Format. Ich füge darin einige Bezeichner für diejenigen Speicherbereiche ein, die SoC-Registeradressen entsprechen. So kann ich das Resultat des Disassemblers leichter lesen und verstehen.

Der First-Stage-Bootloader wird analysiert

Ich fange wieder mit dem First-Stage-Bootloader an, er ist klein und hat keinerlei Abhängigkeiten. Perfekt, um mich auch mit Medusa vertraut zu machen. Ich finde zuerst Code, der auf die GPIO-Register zugreift und mit dem DDR-Speicher-Controller kommuniziert. Einen Teil des Codes, der anscheinend mit dem Koprozessor zu tun hat, kann Medusa nicht korrekt übersetzen. Der Code des Bootladers kommuniziert mit dem Flash-Speicher-Controller.

  • Diasembler-Ausgabe (Bild: Christer Weinigel)
  • Diasembler-Ausgabe  (Bild: Christer Weinigel)
  • Diasembler-Ausgabe (Bild: Christer Weinigel)
  • FPGA-Quellcode (Bild: Christer Weinigel)
  • Owon-Bootscreen (Bild: Christer Weinigel)
Diasembler-Ausgabe (Bild: Christer Weinigel)

Ich untersuche den Code nicht allzu genau. Ich weiß ungefähr, was vor sich geht, und die Details sind nicht so wichtig. Was mich interessiert, ist der Code, der den Second-Stage-Bootloader in den DDR-RAM lädt, und ab wo er ausgeführt wird.

  • Diasembler-Ausgabe (Bild: Christer Weinigel)
  • Diasembler-Ausgabe  (Bild: Christer Weinigel)
  • Diasembler-Ausgabe (Bild: Christer Weinigel)
  • FPGA-Quellcode (Bild: Christer Weinigel)
  • Owon-Bootscreen (Bild: Christer Weinigel)
Diasembler-Ausgabe (Bild: Christer Weinigel)

Ich finde Code-Anweisungen, die die ersten 128 KByte vom Flash-Speicher an die Adresse 0x30000000 laden, die Startadresse des DDR-RAMs. Dann werden vom Offset 0xac4 an 70 KByte zur Adresse 0x33c00000 kopiert - die letzten 512 KByte des DDR-RAMs - und dann führt die CPU ab dort den Code aus.

Bitte aktivieren Sie Javascript.
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
  • ohne Werbung
  • mit ausgeschaltetem Javascript
  • mit RSS-Volltext-Feed
 Reverse Engineering: Wie das Oszilloskop bootetDer Second-Stage-Bootloader ist als Nächstes dran 
  1.  
  2. 1
  3. 2
  4. 3
  5. 4
  6. 5
  7. 6
  8. 7
  9. 8
  10.  


mifish 24. Nov 2016

+1 interessanter artikel

muhviehstah 23. Nov 2016

wäre binwalk hierbei nicht hilfreich gewesen?

muhviehstah 23. Nov 2016

kt

Elchinator 22. Nov 2016

Das wesentlichste Teil - die Hardware - scheint ja ab Werk durchaus brauchbar zu sein...

derdiedas 22. Nov 2016

Danke Golem - und nun bin ich doch wieder motiviert - zwar kein Linux zu installieren...



Aktuell auf der Startseite von Golem.de
Resident Evil (1996)
Grauenhaft gut

Resident Evil zeigte vor 25 Jahren, wie Horror im Videospiel auszusehen hat. Wir schauen uns den Klassiker im Golem retro_ an.

Resident Evil (1996): Grauenhaft gut
Artikel
  1. Amazon: Alexa wacht über Waschmaschinen und laufenden Wasserhahn
    Amazon
    Alexa wacht über Waschmaschinen und laufenden Wasserhahn

    Alexa kann hierzulande eine Waschmaschine oder einen Wasserhahn belauschen und Bescheid geben, wenn etwa die Wäsche fertig ist.

  2. Kanadische Polizei: Diebe nutzen Apples Airtags zum Tracking von Luxuswagen
    Kanadische Polizei
    Diebe nutzen Apples Airtags zum Tracking von Luxuswagen

    Autodiebe in Kanada nutzen offenbar Apples Airtags, um Fahrzeuge heimlich zu orten.

  3. Studie: Kinder erhalten Smartphone meist zwischen 6 und 11 Jahren
    Studie
    Kinder erhalten Smartphone meist zwischen 6 und 11 Jahren

    Nur eine sehr geringe Minderheit der Eltern will ihrem Kind erst mit 15 Jahren ein Smartphone zur Verfügung stellen.

Du willst dich mit Golem.de beruflich verändern oder weiterbilden?
Zum Stellenmarkt
Zur Akademie
Zum Coaching
  • Schnäppchen, Rabatte und Top-Angebote
    Die besten Deals des Tages
    Daily Deals • Saturn-Advent: Samsung Portable SSD T5 1 TB 84€ • ViewSonic VX2718-2KPC-MHD (WQHD, 165 Hz) 229€ • EPOS Sennheiser GSP 670 199€ • EK Water Blocks Elite Aurum 360 D-RGB All in One 205,89€ • KFA2 Geforce RTX 3070 OC 8 GB 1.019€ • Alternate (u. a. AKRacing Core SX 269,98€) [Werbung]
    •  /