Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

Das sieht schwer nach OllyDbg aus.

Und?

Tobi@loggedoff schrieb:

+gjm+ das ist denke ich nicht richtig. Wieso soll ich im Prozessspeicher der Anwendung suchen?? Die Codes sind doch in der .exe also muss ich die irgendwie aus der exe bekommen

Es ist richtig, hol dir ein handle auf den Prozess, und benutz ReadMemory wie gjm schon gesagt hat.

Allerdings habe ich mich immer gefragt, wie unter der selben Adresse Code und gleichzeitig Speicherwerte sein können. Also unter Adresse X steht OP-Code, aber im Memory-Browser ist under derselben Adresse auch eine Variable abgespeichert.

Oder gibt es für die Sections (Code, Data, kA..) jeweils eigene Addressräume?

greetz KN4CK3R

Allerdings habe ich mich immer gefragt, wie unter der selben Adresse Code und gleichzeitig Speicherwerte sein können. Also unter Adresse X steht OP-Code, aber im Memory-Browser ist under derselben Adresse auch eine Variable abgespeichert.

Das ist nicht gleichzeitig, sondern nur eine Interpretationsfrage.

Hängt immer davon ab, wo es gespeichert ist. .CODE, .DATA,...

z.B. 0x49 kann sowohl als DEC ECX als auch als das ASCII-Zeichen 'I' intepretiert werden.

... oder als REX-Prefix.

Hängt immer davon ab, wo es gespeichert ist. .CODE, .DATA,...

Aha, und die haben jeweils einen eigenen Adressraum?

EOP schrieb:

Hängt immer davon ab, wo es gespeichert ist. .CODE, .DATA,...

Aha, und die haben jeweils einen eigenen Adressraum?

Im Prinzip ja (Segmente).

Öffne mit OllyDbg irgendein Programm, dann [Windows]+[Memory Map]: section ist das, was du meinst.

so ein blödsinn, wie sage ich dann ReadProcessMemory, dass es aus der Code section ließt und nicht aus der Data section ??

Das liegt in deiner Verantwortung.

ReadProcessMemory kopiert nur die binären Daten einer Adresse.

Ansonsten:
http://en.wikipedia.org/wiki/Portable_Executable#Layout
http://webster.cs.ucr.edu/AoA/index.html

+gjm+ das ist denke ich nicht richtig. Wieso soll ich im Prozessspeicher der Anwendung suchen?? Die Codes sind doch in der .exe also muss ich die irgendwie aus der exe bekommen

Möglicherweise zeigt ja der Stan+OllyDbg die RVA (0x00401474) auf Wunsch auch als relativen Offset in der EXE an ?

fricky-Fake schrieb:

Ich weiß noch von einer Situation, da hatte ich einen Speicherwert gesucht und gefunden. Definitiv eine Programmvariable. Und unter genau dieser Adresse war auch ein OP-Code.

Möglicherweise ist das Problem nur, ob (und wie) man "OP-Codes" von "Speicherwerten" unterscheiden kann. Poste mal die genaue Vorgehensweise.

[...]aber da irre ich mich wohl).

tust du, ganz sicher
Je nach Form der da abgelegten Variablen kann Olly da durchaus mehr oder weniger sinnvollen Code interpretieren.

greetz KN4CK3R

TCHAR buff[6];
	HANDLE hproc = OpenProcess(PROCESS_ALL_ACCESS, FALSE, 15); 
	ReadProcessMemory(hproc, address, buff, 6, 0);
	MessageBox(0, buff, buff, 0);

warum bekomme ich dadurch nur seltsame zeichen?

Wenn ich es statt mit char, int mache klappt es. Dann kann ich die ersten 4 bytes auslesen. Aber ich brauche die ersten 6 bytes also geht es mit int nicht.
Also warum klappt dieser code oben nicht?

Aber wie interpretiere ich es richtig

Das hängt nun davon ab, was die eingelesenen Bytes darstellen sollen. Einmal angenommen, es soll sich um einen "OP-Code" handeln. Dann geht es in etwa weiter wie folgt:

if (buff[0] == 0x68) { // dann Opcode "PUSH"
// buff[1] bis buff[4] könnten interessant sein
 }

Eine vollständige Referenz gibt es irgendwo im Assemberforum oder gleich bei Intel (oder AMD)(oder x86-SelfBurned-CPU).

Tobi@loggedoff schrieb:

ich kann ja char nicht als hex interpretieren...

Aber eventuell als "hex" ausgeben lassen. In etwa wie folgt:

TCHAR buff2[40];
wsprintf (buff2,"%02X %02X%02X%02X%02X",buff[0],buff[1],buff[2],buff[3],buff[4]);
MessageBox(0,buff2,buff2,0);