getthreadcontext verständnisfrage

[smc]

Hallo an alle, ich bins mal wieder

ich bin zuletzt über die windows api getthreadcontext gestolpert und habe da so meine Probleme diese API zu verstehen.
So wie ich das im moment verstehe kann man mit dieser API die register eines opcode offsets auslesen lassen.

Für mich bedeutet das das man in dieser Funktion das Handle, das Betreffende Offset und ein Pointer auf TContext (ablagestelle für eax, ecx etc.) angeben muss.

Nun habe ich mir das ganze auf msdn angesehen um muss zu meinem erstaunen feststellen das das ganz anders aussieht.

Code:

BOOL GetThreadContext(
  HANDLE hThread,
  LPCONTEXT lpContext
);

Handle to the thread whose context is to be retrieved. <- Hä? O_o eigentlich habe ich ein HANDLE hProcess erwartet, aber wie zeige ich auf einen hThread? *verwirrt*

[in, out] Pointer to the CONTEXT structure that receives the appropriate context of the specified thread. <- wieso Context struktur? muss ich hier das Offset angeben aus dem ich die register lesen will? oder betrifft dies das TContext? wenn TContext damit angesprochen wird verstehe ich nicht auf welches Offset die funktion zugreifen soll.

Mit dieser Funktion will ich ereichen das mein Programm aus einem anderen laufenden Prozess von einem opcode offset ein bestimmtes register ausliest (eax).

Ist das damit überhaupt möglich?

Im moment verstehe ich das nicht wirklich, eventuell kann mir jemand von euch weiterhelfen, würde mich freuen!

grüße

[NicoDE]

function GetThreadContext(hThread: THandle; var lpContext: TContext): BOOL; stdcall; external kernel32; hThread - Handle auf ein Thread-Objekt (siehe: CreateThread, OpenThread, ...)
lpContext - Struktur die durch die Funktion gefüllt wird (platformspezifische Struktur, die den 'Zustand' eines Threads wiederspiegelt - unter x86 sind das einige Prozessor-Register)

[smc]

ok, danke.

lpContext verstehe ich nun.
Habe jetzt nur noch meine Probleme mit hThread.

Ich will ein Statistik Programm für ein spiel schreiben, dieses Programm muss Werte aus verschiedenen offsets auslesen.
Da die offsets durch DMA sich bei jedem neustart des Spiels ändern will ich mit getthreadcontext das register eines opcode auslesen welche die position des neuen offsets beinhaltet.

Ich verstehe einfach nicht wieso die api's keine pointer zu dem prozess von dem ich eigentl. was will beinhalten, woher soll den mein programm wissen worauf es zugreifen soll wenn ich nur threadspezifische infos bereitstellen kann?

In etwa so hab ich mir das anfangs gedacht:
1. Handle suchen und finden
2. api zum register lesen benutzen
->>> (handle, opcodeoffset, register(z.b. EAX), pointer wo der inhalt von eax übermittelt wird)
3. readprocessmemory von dem eaxpointer wert
4. ergebniss von readprocessmemory (nach floattostr) in einem lable anzeigen

scheint so aber nicht zu funktionieren, hm?

p.s. vll. machts bei mir bei diesem thema doch noch "klick"

[Robert Marquardt]

Also so wie du mit unpassenden Begriffen um dich wirfst, hast du keine Ahnung, aber davon recht viel.

DMA hat nur im Kernel irgendeine Bedeutung. Im Userspace ist es voellig unbekannt.
Wie kommst du eigentlich auf die Idee das das Thread API etwas zur Loesung deines Problems beitragen kann?
Speziell GetThreadContext ist praktisch nur fuer einen Debugger interessant.

Es waere auch mal praktisch zu erklaeren was du wirklich machen willst.
Bestimmte Speicherzellen aus dem virtuellen Adressraum eines anderen Prozesses auszulesen ist durchaus moeglich.
Die Funktion dazu heisst ReadProcessMemory.

[smc]

Zitat von Robert Marquardt:

Also so wie du mit unpassenden Begriffen um dich wirfst, hast du keine Ahnung, aber davon recht viel.

danke ich bin leider noch Anfänger.

Zitat:

DMA hat nur im Kernel irgendeine Bedeutung. Im Userspace ist es voellig unbekannt.
Wie kommst du eigentlich auf die Idee das das Thread API etwas zur Loesung deines Problems beitragen kann?

habe ich daraus so verstanden: hThread - Handle auf ein Thread-Objekt (siehe: CreateThread, OpenThread, ...)

Zitat:

Speziell GetThreadContext ist praktisch nur fuer einen Debugger interessant.

Das ist im grunde der springende punkt, debugger wie ollydbg können ja register von opcodes lesen, genau das will ich meinem Programm beibringen.

Zitat:

Es waere auch mal praktisch zu erklaeren was du wirklich machen willst.

hab ich doch
### Ich will ein Statistik Programm für ein spiel schreiben, dieses Programm muss Werte aus verschiedenen offsets auslesen.
Da die offsets durch DMA sich bei jedem neustart des Spiels ändern will ich mit getthreadcontext das register eines opcode auslesen welche die position des neuen offsets beinhaltet. ###

Zitat:

Bestimmte Speicherzellen aus dem virtuellen Adressraum eines anderen Prozesses auszulesen ist durchaus moeglich.
Die Funktion dazu heisst ReadProcessMemory.

ReadProcessMemory bringt mir leider erst dann etwas sobald ich das Zieloffset weiss, und genau das wechselt immer bei einem Prozessneustart!
Das Zieloffset will ich eben aus dem opcode welcher das Zieloffset (für rpm) übermittelt mit einer api bekommen.

Sorry wenn ich mit meiner Fragerei nerve.

[Robert Marquardt]

Bevor du nicht verstehst wie ein Windows-Programm/Prozess ueberhaupt funktioniert kannst du keinen Erfolg haben.
Ein Prozess hat einen virtuellen Adressraum ganz fuer sich allein. Dort wird er normalerweise immer an die gleiche Adresse geladen.
DLLs landen im gleichen Adressraum, aber sie muessen moeglicherweise reloziert werden, falls schon eine andere DLL an der gewuenschten Basisadresse steht.

Du willst vermutlich globale Variablen des Programms auslesen.
Dazu dient ReadProcessMemory. Die Besonderheit bei dieser Funktion ist das die Leseadresse aus dem Adressraum des zu lesenden Prozesses und die Adresse des Zielpuffers aus dem Adressraum des lesenden Prozesses ist.

Was du ermitteln ist die Leseadresse.

[smc]

Nennen wir es halt Leseadresse, fakt ist das ich mit ReadProcessMemory nicht allzuweit komme da ich keinen Static Pointer finden kann der zu der Adresse zeigt welche den Wert welchen ich dem User übermitteln will hält.

Das Offset welches z.B. die Anzahl von Holz beinhaltet wechselt bei jedem Spielneustart.

Für mich gibt es nun 3 möglichkeiten:
1. DMA Stealing - will ich nicht machen weil das mit codeinjections verbunden ist welche das jetzige offset in ein codecave kopiert.
2. Static Pointer finden - ist normalerweise der beste weg, kann man bei manchen programmen auch recht einfach finden, nur bei diesem nicht (sind sicher über 5 lvl *würg*).
3. getthreadcontext - habe ich bisher noch nie angewand, sollte aber funktionieren, die debugger können es ja auch.

Irgendwie reden wir aneinander vorbei...

Mal ein Beispiel:

0056ac15 - mov eax,[eax+10]

in eax befindet sich das offset von holz

Ich will nun 0056ac15 auslesen und den wert von EAX einsehen

danach addiere ich 0x10 zu dem gewonnen wert, der wert sollte dann meine _Leseadresse_ sein.

Die Leseadresse lese ich mit ReadProcessMemory.

[NicoDE]

Zitat von smc:

Mal ein Beispiel:
0056ac15 - mov eax,[eax+10]
in eax befindet sich das offset von holz
Ich will nun 0056ac15 auslesen und den wert von EAX einsehen

An Adresse 0x0056ac15 steht nur die Prozessoranweisung für "mov eax,[eax+10]" - du müsstest genau in dem Moment den Context auslesen, in welchem ein/der Thread diesen Code ausführt -> womit wir wieder beim Debugger wären...

ps@robert: mit 'DMA stealing' meint er wahrscheinlich das Überwachen von 'Dynamic Memory Allocations' (hoch leben die unverstandenen Abkürzungen )

[smc]

genau das will ich nur wie stell ich das an?
Ich weiss das die Anweisung sehr oft aufgerufen wird, daher ist das kein Problem!


DMA Stealing würde wie folgt aussehen:

0056ac15 - mov eax,[eax+10] ändern wir in einen JMP zu einem CodeCave um.

das CodeCave beinhaltet dann den original opcode und ein lea eax+mov eax opcode welcher den wert von eax läd und in ein weiteres CodeCave schiebt.
In dem letzten CodeCave findet man dann immer das aktuelle Offset (auch nach einem neustart)

Dachte eigentlich das "DMA Stealing" so bekannt ist, da ich es schon öfters gelesen habe, naja so kann man sich irren.

[NicoDE]

Zitat von smc:

0056ac15 - mov eax,[eax+10] ändern wir in einen JMP

Das sind nur drei Bytes ($8B $40 $0A)...
- das reicht nur für einen short jump (127 Bytes)
- du müsstest also das Code-Segment patchen (Erfahrung mit Assembler unter Windows x86 scheinen ja zu fehlen...)

Zitat von smc:

zu einem CodeCave um.

Ein was?

Zitat von smc:

Dachte eigentlich das "DMA Stealing" so bekannt ist, da ich es schon öfters gelesen habe, naja so kann man sich irren.

Ich kenne mich damit nicht so sehr aus...