Übereinstimmende Upsets in iOS Crash-Dump zu demontierten Binär

Question

Ich habe Probleme beim Abgleich der Offsets in den Stack-Spuren von iOS Crash-Dumps mit Offsets in der Disassemblierung der Binärdatei als Ausgabe von Otool.

Kann jemand bestätigen, wie im Prinzip ich diese zusammenbringen. wenn ich eine Zeile in dem Crash-Dump Zum Beispiel erhalten:

0 myapp 0x00005b0a 0x1000 + 19210 

würde ich erwarten, dass der Offset des betreffenden Befehls in der Binärdatei 0x5b0a, 0x4b0a .... oder etwas anderes zu sein?

In seiner Dekodierung der Header-Informationen, otool gibt zum Beispiel auch, diese Informationen (der eigentliche Code beginnt in der Datei bei Offset 0x0000224c):

Section 
    sectname __text 
    segname __TEXT 
     addr 0x0000224c 
     size 0x00063ad2 
    offset 4684 
    align 2^2 (4) 
    reloff 0 
    nreloc 0 
     type S_REGULAR 
attributes PURE_INSTRUCTIONS SOME_INSTRUCTIONS 
reserved1 0 
reserved2 0 

Also, ich nicht 100% sicher war Ich habe das richtig interpretiert, aber es scheint zu sein, dass der Code bei + 0x224c in der Datei bei Offset 0x124c im Speicher gelandet ist, aber dann war ich nicht genau sicher, wie das zum Beispiel in den Ort passte 0x1000. Das Problem, das ich habe, ist das gegeben, sagen wir, der Offset 0x5b0a, weder die Anweisung dort noch bei 0x4b0a noch bei 0x6b0a macht Sinn als die eigentliche Anweisung in Frage (einschließlich der Tatsache, dass zB Orte weiter unten im Stapel dann don nicht auf Verzweigungsanweisungen zeigen.

(Ich weiß, dass, zumindest auf früheren Verkörperungen ARM, eine Diskrepanz zwischen dem Wert des PC war und der entsprechenden Speicheradresse durch die Befehlspipeline. I vorausgesetzt war, daß ein solcher Unterschied berücksichtigt werden würde, Bei den Offsets, die im Crash Dump gemeldet wurden, oder jedenfalls würde ich die fragliche Verzweigungsanweisung ein paar Anweisungen auf der einen Seite sehen, auf die verwiesen wurde, wenn ein solcher Unterschied nicht berücksichtigt wurde ...)

Kann jemand Licht abgeben?

Answer 1

Vorausgesetzt, dass myapp keine Symbole entfernt haben, können Sie atos verwenden.

Sie können immer man atos für mehr Details, aber dies sollte für Ihr Problem ausreichend sein:

-o symbol_file # debugging information output by the compiler this may be a dSYM or the binary itself depending on who you saved symbol information 
-l load address # the base address in the process space at which your library is loaded into the springboard process (Looks like 0x1000) 
Also a list of addresses you wish to symbolicate 

Usage: 
    atos -o myapp -l 0x1000 0x00005b0a 0x0005bca ... etc 

Diese Ausgabe eine Liste von Symbolnamen an das Terminal sein sollte. Auch dies erfordert, dass die myapp Symbole nicht entfernt wurden.

Answer 2

Fügen Sie die virtuelle Adresse des __TEXT-Segments zur relativen Adresse hinzu, die im Crash-Dump angegeben ist. Das Ergebnis ist die Adresse, die in der Zerlegung nachgeschlagen werden soll. Hier sind die Schritte:

1. Verwenden otool -lv <application-binary> die Ladebefehle von die Anwendung binär dump. Suchen Sie nach dem Ladebefehl für das __TEXT Segment und den zugehörigen Wert für vmaddr, typischerweise 0x1000. Sie benötigen nicht die Informationen über __textAbschnitt, die oben gezeigt wird, nur die Informationen über das Segment.

2. Im Crash-Dump werden die Adressen in der Aufrufliste in der Form 0x00124ff4 0xf4000 + 200692 angegeben. Der letzte Teil ist ein Offset innerhalb der Binärzahl in Dezimal. Fügen Sie das zu dem in Schritt 1 erhaltenen Wert hinzu, und konvertieren Sie in hexadezimal. In diesem Beispiel würden wir 0x1000 + 200692 berechnen, was 0x31ff4 in Hex ist.

3. Verwenden Sie otool -tV <application-binary>, um die Disassemblierung für die binäre Anwendung abzulegen. Suchen Sie die in Schritt 2 erhaltene Adresse (0x31ff4 in diesem Beispiel). Für den obersten Frame des Aufruf-Stacks ist dies der Absturz der Anwendung. Für alle anderen Ebenen sollte an der berechneten Adresse ein Verzweigungsbefehl sein, der der nächsthöheren Ebene im Stapel entspricht.