2016-12-25 1 views
0

Ich habe dieses Stück x86-Assembler-Code:Verständnis x86 r/m32 Anweisung

mov edx, off_984C400 
mov eax, [edx+1E0h] 
call eax 

Die OpenSecurityTraining-Videos teached mich, dass [something] meants, dass der Prozessorspeicher an der Position something zuzugreifen versucht.
Das würde move 0x984C400 into edx, add 0x1E0 to it and call whatever address there is in memory bedeuten.

Mein Problem ist jetzt, dass ich nur statische Analyse über IDA zur Verfügung habe und nicht weiß, wie ich herausfinden kann, welche Adresse bei [0x984C400 + 0x1E0] ist. Gibt es eine Möglichkeit, die statische Adresse der Funktion zu erhalten?

+1

Der Titel eine andere Frage aus dem Körper stellen. Was können Sie über den indirekten Adressierungsmodus nicht verstehen? IDA ist normalerweise sehr gut darin, die indirekten Ziele zu finden, wenn sie nichts vorschlagen, dann hängt das Ziel wahrscheinlich von den Programmzuständen ab und der leichtere Weg zu wissen, was es ist, bricht kurz vor dem Aufruf. Sie können alle Querverweise auf * off_984c400 * sehen und hoffen, dass einige Ergebnisse hilfreich sind. –

+0

'0x1E0' ist 480 ... das ist ein gewisser Versatz von' off_984C400', so dass Querverweise auf 'off_984C400' den Code möglicherweise nicht aufdecken welches die Adresse vorbereitet (wenn es dynamisch in den Speicher bei '0x984C5E0' von einem anderen Code geschrieben wird). Wenn Sie in der Lage wären, den Code zu debuggen, wäre es wahrscheinlich einfacher, dort einen Speicher-Schreib-Breakpoint zu setzen, um zu sehen, wie die Adresse gesetzt ist (wenn es nicht statisch ist, dann genügt ein Breakpoint vor dem Aufruf, um alles aufzudecken, wie Margaret es vorschlägt)). – Ped7g

+0

'Gibt es eine Möglichkeit, die statische Adresse der Funktion zu erhalten? 'Unwahrscheinlich. Wenn es nur ein mögliches Ziel gäbe, würde der Code wahrscheinlich keinen indirekten "Aufruf" verwenden. Die Ausnahme dazu wäre für Bibliotheksfunktionsaufrufe, bei denen das dynamische Verknüpfen mit einer Ebene der Indirektion statt mit dem Umschreiben von "Call-rel32" -Codierungen in der ausführbaren Datei auf typischen Betriebssystemen erfolgt. –

Antwort

0

Die wahrscheinlichste Erklärung wäre, dass die Adresse in Frage ist entweder struct, die einen virtuellen Funktionszeiger (an anderer Stelle gesetzt), oder dass es ein (wenn es C++ ist). Der Zeiger ist wahrscheinlich im Datensegment (überprüfen, dass sich selbst)

Wenn es eine struct mit virtuellen Funktionen ist, die xref s Adresse überprüfen (und vielleicht der Adressen um ihn herum)

vtable s in ctor s initialisiert , so in diesem Fall xref die Adresse sollte Sie auf die ctor bekommen.

Beachten Sie, dass dieser Aufruf in mehr als eine mögliche Funktion übersetzt werden kann.