getthreadcontext verständnisfrage

[smc]

Zitat:

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

ist mir klar, war ja auch nur ein Beispiel :)

Zitat:

Ein was?

Ein CodeCave ist normalerweise eine größere Sektion voller nops oder 0x00 Bytes in einem Modul in dem man eigene Codes injecten kann.

Zitat:

Ich kenne mich damit nicht so sehr aus...

muss man auch nicht wirklich

p.s. ich will hier kein was ist richtig, was ist falsch, spiel spielen.
Ich weiss auch das ich kein Profi in den ganzen sachen bin, allerdings will ich lernen wie das was wir oben schon teilweise angesprochen haben zu realisieren ist.

[NicoDE]

Zitat:

Zitat von smc

allerdings will ich lernen wie das was wir oben schon teilweise angesprochen haben zu realisieren ist.

Wurde doch schon erwähnt: a) Schreibe einen Debugger, setze einen Haltepunkt und hole dir den Thread-Context b) Patche den Remote-Code
Ist beides genauso aufwändig; spielt also IMHO keine Rolle wofür du dich entscheidest.

[brechi]

smc, das was du vorhast kann mit GetThreadContext / WriteProcessMemory nicht sauber (ohne Hänger) lösen.

Willst du keine Injection / Hooking machen musst du folgendermaßen vorgehen:

Du überschreibst die Stelle mit Hilfe von WriteProcessMemory in dem du einen "jmp -2" dort hinschreibst. (EB FE)
Dadurch bleibt der Zielprozess beim nächsten Aufruf dort stehen (das Programm wird hängen). Wenn du aber dauerhaft immer GetThreadContext in deinem Programm auf den richtigen Thread (Haupthread des Spiels) aufrufst bis der EIP von dem zurückgelieferten Context = der Stelle ist wo du den short jump hingeschrieben hast, dann steht die richtige Adresse in lpContext.EAX. Danach kannst du den richtigen Opcode wieder hinschreiben, das Spiel wird dann weiterlaufen. Nun hast du den EAX Wert den du weiter benutzen kannst.

Codeinjection / Hooking wäre auch kein Problem ist aber für den Fall nicht direkt nötig, da du EAX bzw globale Adressen ja nicht verändern musst.

hierzu: http://cvs.sourceforge.net/viewcvs.p...uallCollection

btw
0056ac15 - mov eax,[eax+10]
ist nicht $8B $40 $0A sondern $8B $40 $10 da Ollydbg des immer in hex anzeigt *grossmaul*

[brechi]

Delphi-Quellcode:

const DEINE_ADDR = $00441234;
var dwProcessID: DWord;
    dwThreadID: DWord;
    wBuf: Word;
    dwRead: DWord;
    wJmp: Word;
    Context: TContext;
    bFound: Boolean;
begin
  dwProcessID := uallProcess.FindProcess('solitär.exe');
  wJmp := $FEEB;

  if dwProcessID <> 0 then
  begin
    dwThreadID := uallProcess.GetThread(dwProcessID);
    dwProcessID := OpenProcess(PROCESS_ALL_ACCESS,false,dwProcessID);
    if ReadProcessMemory(dwProcessID,pointer(DEINE_ADDR),@wbuf,SizeOf(wBuf),dwRead) and
      (dwRead = SizeOf(wBuf)) then
    if WriteProcessMemory(dwProcessID,pointer(DEINE_ADDR),@wJmp,SizeOf(wJmp),dwRead) and
      (dwRead = SizeOf(wJmp)) then
    begin
      bFound := false;
      repeat
        if GetThreadContext(dwThreadID,Context) then
        begin
          if (Context.Eip = DEINE_ADDR) then
          begin
            WriteProcessMemory(dwProcessID,pointer(DEINE_ADDR),@wBuf,SizeOf(wBuf),dwRead);
            bFound := true;
            // Context.Eax hat den Wert
          end;
        end;
        Sleep(100);
      until bFound;
    end;

    CloseHandle(dwProcessID);
  end;
end;

Sollte als Beispiel genügen.

[smc]

Hi brechi,

vielen dank für deine antwort, das hilft mir schon um einiges weiter!

Noch eine kleine Frage, könnte man nicht auch den thread mit SuspendThread anhalten anstatt mit einem EB FE?
Der opcode von dem ich den wert haben will wird so gut wie durchgängig ausgeführt, bin auch sicher das meine Adresse da durchgehend übermittelt wird.

Auf die uall sachen hätte ich früher stoßen sollen, ziemlich praktisch die funktionen. :)

[brechi]

Mit Suspendthread stoppst du den Thread. WO der allerdings stehen bleibt kannst du nicht festlegen. Im schlechtesten Fall wird der nie genau an der Stelle stehen bleiben.

Suspendthread sollte man jedoch immer vor GetThreadContext aufrufen. Auch in meinem Beispiel. Wird zwar keine große Auswirkung haben, aber sicher ist sicher.

[NicoDE]

Zitat:

Zitat von brechi

Du überschreibst die Stelle mit Hilfe von WriteProcessMemory in dem du einen "jmp -2" dort hinschreibst. (EB FE)
Dadurch bleibt der Zielprozess beim nächsten Aufruf dort stehen (das Programm wird hängen).

Bleibt nur zu hoffen, dass die Zielanwendung keinen WatchDog-Thread hat...
(juhu, mein erstes Schlagwort in diesem Thread *g*)

[smc]

okay ich werd dann mal ein bisschen rumtesten sobald ich dazu komme, melde mich dann nochmal :)

Das einzigste was mich jetzt noch stört ist die CodeInjection von EB FE, aber ohne wird es wahrscheinlich nur mit Static Pointern gehen (hab ich schon erwähnt das ich Static Pointer suchen hasse?).

Gefällt mir so aber schon um einiges besser als dma stealing!

Zitat:

Bleibt nur zu hoffen, dass die Zielanwendung keinen WatchDog-Thread hat...
(juhu, mein erstes Schlagwort in diesem Thread *g*)

:thumb:

[brechi]

Das Finden einer statischen Adresse, dauert (wenn man das Programm debuggen kann) nicht mal 5 Minuten. Das ist das beste/sicherste was du für deinen Einsatz benutzen kannst.

falls es einen "WatchDog-Thread" bekommst das das schnell mt Hilfe von den HW-BP raus
generell benutzen die neuen Cheats eben diese HW-BP kombiniert mit PAGE_GUARD um Funktionen abzufangen usw. was relativ schwer entdeckt werden kann

[smc]

dann mache ich eindeutig was falsch, kennst du vielleicht ein gutes tutorial welches erklärt wie man Static-Pointer findet? habe bisher nur im cheatengine forum etwas darüber gefunden

und wie genau funktioniert ein hardware breakpoint mithilfe PAGE_GUARD? (höre ich jetzt zum ersten mal)