Hex zahlen an Addresse auslesen

EOP schrieb:

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.

Nee, der Code wird doch in den RAM gemapped, sonst wären wir langsam unterwegs
Passt schon, das was du dort siehst, ist die Code-Section.

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?

KN4CK3R

an 0x40A978 steht kein OP Code sondern nur die Variable

greetz KN4CK3R

Meinst du mich? Das ist mir schon klar, das meinte ich nicht.

EOP

fricky-Fake schrieb:

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.

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.
Aber habe von Adressierung nicht so viel Ahnung. Vielleicht könnte das mal jemand kurz erläutern (Wie das zB. in OllyDbg ist, physikalische/virtuelle Adresse oder wie?).

EOP

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

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

EOP schrieb:

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

... oder als REX-Prefix.

EOP schrieb:

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

Aha, und die haben jeweils einen eigenen Adressraum?

EOP

fricky-Fake schrieb:

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 ??

Stimmt, jetzt kapier ich wieder nix

EOP

Tobi@loggedoff schrieb:

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

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

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.

Stimmt, ich irre mich wohl. Ich sehe an Adressen, wo Programmvariablen sind, in OllyDbg in der CPU-Ansicht OP-Code, allerdings ändert der sich, wenn sich der Variablenwert ändert. Also OllyDbg zeigt die Werte einfach als OP-Code an, reine Interpretationssache (Wobei ich mir immer noch einbilde, an selber Adresse wie einer Programmvariablen _gültigen_ OP-Code gesehen zu haben, aber da irre ich mich wohl).

KN4CK3R

fricky-Fake schrieb:

[...]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

hallo!

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?

- Stimmt die Prozess-ID (15) ?
- Was ergibt sizeof(buff) ?
- Lesen (und verstehen) was EOP geschrieben hat.

ja die pid stimmt sicherlich. (nehme sie immer neu ausm task manager)
Aber wie interpretiere ich es richtig als hex? ich kann ja char nicht als hex interpretieren...

Tobi@loggedoff schrieb:

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);