Ich versuche gerade mit IDA ein Programm welches auf einem ARM Prozessor läuft und mal in C geschrieben wurde zu analysieren. Das Programm befindet sich in einem Flash-Speicher und ich habe das Image davon als Datei vorliegen. Ich habe keinen Quellcode, muss also disassemblieren. In diesem Image finde ich am Ende jede Menge C-Strings. Diese müssen ja im Programm irgendwie "verwendet" werden, sprich irgendwo und irgendwann wird eine Routine einen Zeiger auf einen dieser Strings setzen und eine Unterroutine zum anzeigen bzw. ausgeben dieses Textes aufrufen. Meine Frage wäre nun, mit welchen Methoden ich das rausbekommen kann wo im Programmcode dies geschieht. Grundsätzlich hätte ich auch die Möglichkeit das Gerät mit einem Segger-JTAG Debugger laufen zu lassen, aber ein Breakpoint wird mir da wohl nicht helfen, da dort ja kein Code ausgeführt wird, sondern nur über Speicherbefehle drauf zugegriffen. Die Idee die ich damit verfolge ist, einen Einstiegspunkt für die Analyse des Programmcodes zu haben um von einer Meldung welche ich am Bildschirm des Gerätes sehe, rückwärts zum Aufrufstack und damit der Funktionsweise des Programms zu kommen.
Brain v1.0 sollte dafür reichen, auch ohne Patches.
Schreib doch einfach mal Code der sowas macht und schau Dir das Kompilat an, dann siehst Du wie er üblicherweise 32-Bit Konstanten in Register lädt und wonach Du dann suchen musst.
:
Bearbeitet durch User
Hast du Flirt Tabellen für die diversen Arm Compiler? Wenn ja lass die einfach mal darüber laufen. Mit etwas Glück kannst du dann Runtime Module des Compilers identifizieren. Der Low Level Weg: Hexsuche mit den Adressen der Strings. Danach Zurückarbeiten bis du die Ausgabe Funktion gefunden hast. Falls du den Decompiler besitzt ist der auch einen Versuch wert. Letztendlich ist aber Brain angesagt. Am Anfang ist das ja eine reine Codewüste. Gut geeignet wäre auch wenn die Ausgabe auf einer ser. Schnittstelle erfolgt erst mal dort mit der Suche zu beginnen. Thomas
Was bitte sind "Flirt Tabellen" und wo findet man die? Ja, das mit der Codewüste stimmt wohl. Mein erster Ansatz da durchzusteigen war einen Entrypoint zu finden. Ich weiss ja zumindest was für eine ARM Architektur in welcher Endianess das ausführt. So kann man wenigstens einen guten Teil der Bytematsche als Programmcode identifizieren. Aber selbst wenn man weiss das dort Daten liegen ist es deren Struktur auch mit viel "Brain" nicht immer ermittelbar. Es ist ja nicht immer so einfach wie bei C-Strings. Aufschluß darüber würde nur eine "Sichtung" des Programmcodes der diese Strukturen behandelt liefern. Aber da wären wir wieder beim Einstiegsproblem "wie finde ich den behandelnden Code?" Die Daten folgen ganz sicher immer irgendwelchen Struct-Anweisungen des Quellcodes, oder eben vorgegebenen, Datentypspezifischen Aufbauten. Da gilt es dann auch den Startpunkt der Daten zu finden. Mutmaßlich wird irgendwo eine Mappingtabelle liegen welche aus Zeigern auf die einzelnen Datensätze besteht. Mit viel Glück liegt diese Tabelle direkt vor den Datensätzen, muss aber nicht. Mein Versuch war nun das an gaaanz einfachen Datentypen, wie z.b, dem C-String zu untersuchen. Also einen String finden und dessen Startadresse dann als Bytewert suchen. Hat aber nichts gebracht. Die Frage die ich mir stelle ist ob man überhaupt absolute Zeiger erwarten sollte? Oder ob da nicht eher mit Offsets gearbeitet wird, denn mit absoluten Zeigern wäre der Code nicht realloziierbar. Ok, muss er vielleicht auch nicht... schwierig.
ARM Architektur benutzt normalerweise Offsets für Konstanten... auch für strings... Guck doch mal ob dein Debugmodul im ARM Watchpoints unterstützt... welcher µC oder Prozessor oder SOC ist es denn?
Olli Z. schrieb: > Die > Frage die ich mir stelle ist ob man überhaupt absolute Zeiger erwarten > sollte? Da gibt es viel zu viele Adressiermöglichkeiten. Z.B. kann die Basisadresse der Daten in irgendeinem Register stehen und der Offset zum String woanders - nur eine von vielen Möglichkeiten. Man kann Binärwerte suchen aber nicht alle möglichen Summen von Binärwerten. Ein erfahrener Programmierer (Assembler UND C) kann natürlich alles disassemblieren und dann zu verstehen versuchen, das ist aber sehr mühsam. Eine realistische Möglichkeit: mit einem Logikanalysator (einem richtigen, nicht ein USB-Modul aus China) auf die Stringadresse triggern und die gespeicherten 1000 zuvor ausgeführten Befehle zu untersuchen. Habe ich vor Jahren genacht, also Trigger auf Datenadresse und vorher ausgeführtes Programm aufzeichnen. Georg
Olli Z. schrieb: > Grundsätzlich hätte ich auch die > Möglichkeit das Gerät mit einem Segger-JTAG Debugger laufen zu lassen, > aber ein Breakpoint wird mir da wohl nicht helfen, da dort ja kein Code > ausgeführt wird, sondern nur über Speicherbefehle drauf zugegriffen. Manche CPUs können per Hardware einen Breakpoint auf Daten setzen (Data Watchpoint and Trace Unit); Segger sollte das unterstützen.
Welche IDA Version hast du den? Flirt Tabellen sind Pattern Listen um Runtime Bibliotheken im binary zu erkennen. Es sind Tools bei IDA dabei womit man diese erstellen kann, IDA liefert auch ein paar gängige mit. Das funktioniert mehr oder weniger gut. Wie man startet hängt sehr von den Infos ab die du hast generell ist es z.b eine gute Idee als erstes alle Hardware Register mit sinnvollen Namen zu ersetzen. Danach startup und Main identifizieren. Ein weiterer Schritt ist dann die Interrupt Funktionen anzusehen. Flirt funktioniert bei x86 exe Files ganz gut. Wie das bei ARM ist kann ich nicht sagen. Für Keil C51 hab ich mir die Flirt Tabellen selbst gebaut. Besitzt du das Decompiler Modul um Psydo C zu generieren? Literaturhinweis falls du sowas öfters machst: The IDA Pro book von Chris Eagle gibt's in Online-Bibliotheken und bei Amazon. Thomas
Wenn es ARM und evtl. Thumb2 Befehlssatz ist, ist die Wahrscheinlichkeit groß, dass es relativ oder über irgendeine Adresstabelle adressiert wird. Falls relativ adressiert müsste der Disassembler ja dafür ein Label anlegen nach dem Du dann auch suchen kannst. Voruassetzung ist natürlich, das Du schon den ganzen Code als solchen identifiziert hast und keine undefinierten "Blobs" mehr im Disassembler Output hast. Falls Adresstabelle, müsstest Du dann nach der Adresse in den Daten suchen. Also nehmen wir an der Text steht an Adresse 0x00123456, müsstest Du mal den ganzen Dump nach eben 0x00123456 durchsuchen, evtl. noch swappen wg. little/big endian. Kenne mich aber mit ARM auf ASM Ebene nicht wirklich gut aus...
:
Bearbeitet durch User
Wenn Du das Ding mit IDA disassembiert bekommen hast, dann suchst Du im Fenster "IDA-View" den String. Wenn Du Glück hast, und IDA das Zeug korrekt zugeordnet hat, dann ist vor dem String ein Label (symbolischer Name einer Adresse). Geh mit der Maus drauf, drück x-Taste (oder rechte Maustaste und "Jump to xref to operant..." wählen) und es wird sich ein Fenstern mit den Adressen im Code öffnen, die dieses Label verwenden.
Angehängte Dateien:
-
lookup_string.png
5,1 KB -
label.png
13 KB -
xrefto.png
7,7 KB -
usage.png
42 KB
Danke erstmal für die vielen tollen Tipps und Hinweise! Ich kann mich garnicht bei allen einzeln bedanken, daher seht mir nach das ich es "global" mache :-) Ich habe das Image nochmal durchforstet und noch etliche Stellen, die ich anfangs für Daten hielt in Programmcode umgewandelt. Nun hatte der String, welchen ich gesucht habe (siehe "lookup_string.png") plötzlich wie beschrieben von IDA Pro ein Label erhalten! (siehe "label.png") Darauf konnte ich jetzt ein xrefto (X) machen (siehe "xrefto.png") und diesem zur Codestelle (siehe "usage.png") folgen: Dort lese ich (als ARM Assembler Anfänger) heraus (habs unter der Zeile mit Hash kommentiert):
1 | ROM:0026A72E loc_26A72E ; CODE XREF: ROM:0026A722↑j |
2 | ROM:0026A72E LDR R0, [SP,#0x44] |
3 | # Lade den aktuellen Wert des Stackpointers + 0x44 in das Register R0 |
4 | |
5 | ROM:0026A730 ADR R1, aFgsDnl ; "/fgs.dnl" |
6 | # Lade Register R1 mit dem relativen Offset zum Label 'aFgsDnl' |
7 | # Da das nächste Kommando nur zwei Byte entfernt ist, muss es sich hier also um einen 16-Bit Thumb-Code handeln. Daher kann der Offset auf das Label maximal 1020 Byte entfernt von dieser Adresse sein. |
8 | # Und in der Tat liegt das Label auf 0x0026A8D4 und das sind 420 Byte weiter :-) |
9 | |
10 | ROM:0026A732 BL sub_22D484 |
11 | # Aufruf einer Subroutine, die am Ende mit BX LR wieder hier hin zurückkehrt. LR wurde for dem Branch dahin mit der Adresse des nächsten Kommandos geladen (weil ARM ja sowas wie ein RET nicht kennt...) |
12 | |
13 | ROM:0026A736 ADDS R7, #1 |
14 | # Addiere dem Register R7 den Wert 1 hinzu und aktualisiere die Flags |
15 | |
16 | ROM:0026A738 BNE loc_26A73C |
17 | # Ist das Ergebnis der obigen Addition ungerade (NE) dann springe hier hin... |
18 | |
19 | ROM:0026A73A B loc_26A5A4 |
20 | # Ansonsten geht es hier weiter... |
P.S. Ich wollte nur mal etwas mehr in IDA reinschnüffeln, aber ich sehe schon das man sich damit deutlich mehr beschäftigen muss... daher werde ich mir mal o.g. Buch zulegen (als Kindle Download) und versuchen damit etwas schlauer und versierter im Umgang mit dem Tool zu werden.
Hello Olli z. I need source code in C+from FW files Ford convers+ I have IDA Can you help me please? Thenx Tom
Du kannst dir auch mal Ghidra angucken: https://ghidra-sre.org/ https://www.heise.de/newsticker/meldung/Ghidra-NSA-stellt-quelloffenes-Software-Analyse-Tool-vor-4327737.html Wiki: https://blog.because-security.com/t/ghidra-wiki/431
Kaj schrieb: > Du kannst dir auch mal Ghidra angucken: > https://ghidra-sre.org/ Unter welchem Stein habe ich nur die letzte Zeit gelebt daß mir das entgangen ist? Dieses Tool ist ja der Hammer! Danke für den Tipp!
:
Bearbeitet durch User
Bernd K. schrieb: > Unter welchem Stein habe ich nur die letzte Zeit gelebt daß mir das > entgangen ist? Wenn man nicht gerade 24/7 zig Security-Ticker suchtet, kann einem das schon entgehen. :D
In der Tat ist das ein richtig interessantes Tool und eine echte Alternative zum recht hochpreisigen IDA. Muss ich mir bei Gelegenheit mal anschauen.
Ob der Name "Ghidra" (und auch das Logo) wohl etwas mit dem 3-köpfigen Drachen und Übermonster King Ghidorah (Ghidrah, Ghidora, Greater Hydra, etc...) der elektromagnetische Entladungen speit (hier Einsen und Nullen) und dem abgeschlagene Köpfe nachwachsen(!), bekannt aus Godzilla und anderer Fantasy-Nerd-Literatur (D&D?) zu tun hat? Ist es generell in der NSA gepflegte Symbolik sich mit der archaischen Übermacht von unverwundbaren martialischen Übergöttern zu umgeben, sich derer zu bedienen oder gar sich mit ihnen gleichzusetzen? Immerhin verkörpert speziell dieses Fabelwesen das Böse in seiner reinsten und mächtigsten Form!
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.