asm code aus anderen prozessen lesen

[wadimwadim]

Hallo,
ich möchte den asm code aus einem laufendem prozess auslesen. nicht den ganzen, sondern nur stellen aus bestimmten adressen.
z. B. ist auf

00X12345 push ebp

könnte ich jetzt den asmteil von 00X12345 sehen? also ohne einen debugger.
kann man so etwas in delphi umsetzen? und welche funktionen müsste ich dafür benutzen?

[xaromz]

Hallo,

mit der Funktion ReadProcessMemory kannst Du Speicher aus fremden Prozesse lesen.

Gruß
xaromz

[wadimwadim]

ich möchte nicht die werte der adresse haben, sondern den asm code...

[xaromz]

Hallo,

Zitat:

Zitat von wadimwadim

ich möchte nicht die werte der adresse haben, sondern den asm code...

was meinst Du? Die Werte im Speicher sind doch der Code.
Oder willst Du den Maschinencode in Mnemonics umwandeln? Dann musst Du Dir einen Disassembler bauen.

Gruß
xaromz

[wadimwadim]

also...
nehmen wir an, dass es so aussieht:

00123456 push ebp
00234567 mov ecx
00345678 xxx

ich möchte aus diesen adressen (00123456,...) den asm code bekommen, also push ebp. wie stelle ich das an?

[FAlter]

Hi,

indem du den Maschinencode einliest (s. o.) und dann deassemblierst (s. o.)

Mfg
FAlter

[Neutral General]

Zitat:

Zitat von wadimwadim

also...
nehmen wir an, dass es so aussieht:

00123456 push ebp
00234567 mov ecx
00345678 xxx

ich möchte aus diesen adressen (00123456,...) den asm code bekommen, also push ebp. wie stelle ich das an?

Du liest einfach mit ReadProcessMemory den Speicher des Process von (im Bsp) 00123456 bis 00345678 aus.
Dann hast du eben die Bytes dieser Adressen. Das ist quasi der Assemblercode. Man muss diese Bytes nur eben richtig interpretieren.

Ach ja

Zitat:

mov ecx

ergibt keinen Sinn :P

[Cyf]

Kleines Beispiel: 90 (hexadezimal) entspricht z.B. NOP
Genaueres kannst du entsprechenden Tabellen dazu entnehmen, übersetzen musst du das dann schon selbst.
Die erste Tabelle, die ich eben auf die schnelle gefunden hab, ist z.B. diese: ftp://download.intel.com/design/Pent...s/24319102.PDF
Man beachte, dass das Gnze unter Umständen aber vom Prozessor abhängig ist.

[Remko]

The package "madDisAsm" features a full x86 disassembler including MMX, 3dNow enhanced, SSE and SSE2 support. The disassembler can examine a single x86 instruction (see ParseCode) or a full function (see ParseFunction) and either return a short analysis or a full text disassembly. Register contents are watched/followed if possible, this improves the analyses for jump/call targets. Case/switch jump tables are automatically detected and handled correctly.

http://help.madshi.net/madDisAsm.htm

[p80286]

Hallo zusammen,

so einfach ist das aber nicht. Im Prinzip steht im Speicher OpCode,Daten,OpCode,Daten....
NOP z.B. hat keine zugehörigen Daten. Aber was ist wenn 90 kein OpCode sodern Daten ist?
Dann läuft die Interpretation ganz schön vor die Wand.
Wenn der Code von fremden Anwendungen interessant ist, würde ich die entsprechende exe durch einen Disassembler jagen, dann hat man die Chance was halbwegs vernünftiges zu bekommen.

Zu DOS-Zeiten konnte DEBUG auch direkt auf den Haupspeicher zugreifen, wenn der's heute noch kann, warum in Delphi nochmal neu schreiben?

Gruß
K-H

[Medium]

Zitat:

Zitat von p80286

Aber was ist wenn 90 kein OpCode sodern Daten ist?

Du musst natürlich schon sicher stellen, dass du den Speicher ab einer Stelle bekommst, wo du genau weisst dass als nächstes ein Opcode folgen muss, z.B. einen Prozedureinsprung. Wenn man einfach so mal mitten hinein grabscht kann auch ein Disassembler nicht viel damit anfangen, da man ja z.B. auch mitten in ein als "db" hinterlegtes Stringliteral fummeln könnte, wo alles mögliche drin sein kann.
Ansonsten könnte man eventuell noch versuchen das was man hat semantisch zu analysieren, und schauen ob zum Beispiel ein vermeindlicher Jump zu einer gültigen Adresse führen würde, und ob andere Interpretationen in dem Block sinnvoll erscheinen, so dass man eine Vermutung anstellen kann, wo ein Befehl stehen könnte ab dem man dann interpretieren kann. Das ist aber schon reichlich knifflig möchte ich vermuten.

[Cyf]

Natürlich muss sichergestellt sein, dass man sich auch in gültigen Code befindet, aber das war ja nicht die Frage. :wink:
Zudem befinden sich Konstanten (wie z.B. die genannten Strings) in der Regel am selben Platz (gemeint ist Anfang, Ende usw., natürlich nicht Adresse) in der .exe und so auch im RAM.

Zitat:

Zitat von p80286

Zu DOS-Zeiten konnte DEBUG auch direkt auf den Hauptspeicher zugreifen, wenn der's heute noch kann, warum in Delphi nochmal neu schreiben?

Dann könnte man auch einfach einen vernünftigen Debuger benutzen, nahezu jeder gute sollte das können. Aber es geht ja um die Umsetzung.