NtQueryVirtualMemoryHook-Keine Calls möglich

MrSm!th · 03/25/2010, 20:58

oh das glaub mir mal

90% meiner crashes beim hooken kamen durch die falsche callingconvention und wie gesagt, bei NtQueryInformationProcess ist es mir heute auch passiert.
also ist es einen Versuch wert, es mal mit WINAPI zu probieren.

wo sollte der unterschied bei ner proxy dll sein? warum sollte es da nicht crashen?

hm aber NTAPI ist ja genau das gleiche wie WINAPI.... :/
Komisch nur, dass es einmal mit NtQueryInformationProcess ging und einmal nicht (letzteres mit NTAPI)
Bei NtQueryVirtualMemory ists beides das gleiche

hier übrigens mal mein source (wow den hab ich nicht geposted o.O)

Code:

typedef /*NTSYSCALLAPI*/ NTSTATUS (NTAPI *NtQueryType)(HANDLE,PVOID,MEMORY_INFORMATION_CLASS,PVOID,ULONG,PULONG);

NtQueryType NtQueryVirtualMemory_orig = NULL;

NTSTATUS NTAPI NtQueryVirtualMemoryHook(HANDLE ProcHandle,PVOID Addr,MEMORY_INFORMATION_CLASS MemInfo,PVOID Buf,ULONG Len,PULONG ResLen)
{
	return NtQueryVirtualMemory_orig(ProcHandle,Addr,MemInfo,Buf,Len,ResLen);
}
BOOL APIENTRY DllMain(_In_ HANDLE _HDllHandle, _In_ DWORD _Reason, _In_opt_ LPVOID _Reserved)
{
	if(_Reason == DLL_PROCESS_ATTACH)
	{
		NtQueryVirtualMemory_orig = (NtQueryType)DetourFunction((PBYTE)NtQueryVirtualMemory,(PBYTE)NtQueryVirtualMemoryHook);
	}
	return TRUE;
}

edit: Es muss was mit dem Stack (/den Parametern) zutun haben....
Wenn ich die originale Funktion calle -> Crash
wenn ich MessageBox calle -> Crash
Wenn ich Sleep calle -> alles ok

edit:

EnumProcesses hat aber wiederum 3 Parameter und führt nicht zum Crash.
MessageBox oder die Originalfunktion aber schon.
Ich bin total verwirrt <.<

Tyrar · 03/26/2010, 10:29

Quote:
Originally Posted by MrSm!th
oh das glaub mir mal
90% meiner crashes beim hooken kamen durch die falsche callingconvention und wie gesagt, bei NtQueryInformationProcess ist es mir heute auch passiert.
also ist es einen Versuch wert, es mal mit WINAPI zu probieren.

wo sollte der unterschied bei ner proxy dll sein? warum sollte es da nicht crashen?

hm aber NTAPI ist ja genau das gleiche wie WINAPI.... :/
Komisch nur, dass es einmal mit NtQueryInformationProcess ging und einmal nicht (letzteres mit NTAPI)
Bei NtQueryVirtualMemory ists beides das gleiche

hier übrigens mal mein source (wow den hab ich nicht geposted o.O)
Code:
typedef /*NTSYSCALLAPI*/ NTSTATUS (NTAPI *NtQueryType)(HANDLE,PVOID,MEMORY_INFORMATION_CLASS,PVOID,ULONG,PULONG);

NtQueryType NtQueryVirtualMemory_orig = NULL;

NTSTATUS NTAPI NtQueryVirtualMemoryHook(HANDLE ProcHandle,PVOID Addr,MEMORY_INFORMATION_CLASS MemInfo,PVOID Buf,ULONG Len,PULONG ResLen)
{
	return NtQueryVirtualMemory_orig(ProcHandle,Addr,MemInfo,Buf,Len,ResLen);
}
BOOL APIENTRY DllMain(_In_ HANDLE _HDllHandle, _In_ DWORD _Reason, _In_opt_ LPVOID _Reserved)
{
	if(_Reason == DLL_PROCESS_ATTACH)
	{
		NtQueryVirtualMemory_orig = (NtQueryType)DetourFunction((PBYTE)NtQueryVirtualMemory,(PBYTE)NtQueryVirtualMemoryHook);
	}
	return TRUE;
}
edit: Es muss was mit dem Stack (/den Parametern) zutun haben....
Wenn ich die originale Funktion calle -> Crash
wenn ich MessageBox calle -> Crash
Wenn ich Sleep calle -> alles ok

edit:

EnumProcesses hat aber wiederum 3 Parameter und führt nicht zum Crash.
MessageBox oder die Originalfunktion aber schon.
Ich bin total verwirrt <.<

versuch mal das hier:

Code:

__asm
{
mov esp, ebp
pop ebp
mov eax, NtQueryVirtualMemory_orig
jmp eax
}

vorher würde ich allerdings noch nen register backup machen

evtl würde ich auch mit __declspec(naked) arbeiten, aber das würde ich auch erst versuchen wenn du dir 100% sicher bist dass es am stack liegt, und du es nicht anders hin bekommst.

edit: ich würd das ding auch einfach mal debuggen!
oder zumindest register loggen!

MrSm!th · 03/26/2010, 15:09

Quote:
Originally Posted by HeavyHacker
versuch mal das hier:
Code:
__asm
{
mov esp, ebp
pop ebp
mov eax, NtQueryVirtualMemory_orig
jmp eax
}
vorher würde ich allerdings noch nen register backup machen

eigentlich schon probiert zu jumpen, und auch genau so.
aber noch nie mit basepointer sicherung davor...stimmt...
was genau bewirkt das pop ebp genau? wird da nicht dann der basepointer auf die rücksprungadresse gesetzt?

Quote:

evtl würde ich auch mit __declspec(naked) arbeiten, aber das würde ich auch erst versuchen wenn du dir 100% sicher bist dass es am stack liegt, und du es nicht anders hin bekommst.

Würde es nicht auch bei MessageBox passieren, würde ich denken, es liegt am Trampolin.
Denn bei NtProtectVirtualMemory ist mir das gleiche passiert, bis ich dann mal

Code:

if(NtProtectVirtualMemory_orig != 0)

eingebaut hatte.
Also war wohl der Pointer ungültig; allerdings passiert es ja hier auch bei anderen Calls.
Das Verwirrende nur: Es gibt keinen Zusammenhang!
calls mit keinen Parametern crashen nicht, manche Calls mit Parametern schon, manche nicht.
Ich verzweifle hier noch....
Übrigens bei ProtectVirtualMemory gehts auch eben dann ohne callen der original Funktion (passiert ja da NtProtectVirtualMemory_orig == 0 ist) ohne Access Violation oder Crash o.O

Quote:

edit: ich würd das ding auch einfach mal debuggen!
oder zumindest register loggen!

Tjaja, da bin ich auch schon drauf gekommen, aber wie loggen?
Kann keine Calls machen, zumindest die meisten nicht -> Filewriting unmöglich.
Themida -> schlecht fürs Debuggen.

Ich habe jetzt übrigens eine neue Möglichkeit gefunden.
Nämlich Hardware BPs auf EnumProcesses, anstatt normalen Detours und hooken von NtQueryVirtualMemory.
Allerdings sind die ja nur Threadintern; kein Problem dachte ich und habe eine andere Funktion (NtProtectVirtualMemory) gehookt und dann von ihr die Exceptionhandler und die BPs setzen lassen.
Klappt nun ENDLICH auch ohne Crash und ohne Fehlermeldung, nur leider wird nicht gehookt.
Ein Code sagt mehr als 1000 Worte:

Code:

typedef	BOOL (WINAPI *EnumProcType) (DWORD * lpidProcess,DWORD cb,LPDWORD lpcbNeeded);

typedef	NTSYSCALLAPI NTSTATUS (NTAPI *NtProtectType) (HANDLE,PVOID*,PSIZE_T,ULONG,PULONG);

EnumProcType EnumProcs_orig = NULL;

NtProtectType NtProtectVirtualMemory_orig = NULL;


void SetHooks();
LONG WINAPI Exceptions(_EXCEPTION_POINTERS* ExceptionInfo);


BOOL WINAPI EnumProcsHook(DWORD * pids,DWORD cb,LPDWORD Needed)
{
	pids = NULL;
	Needed = NULL;
	return TRUE;
}


NTSTATUS NTAPI NtProtectHook(HANDLE h,PVOID *p,PSIZE_T s,ULONG u,PULONG pu)
{
	NTSTATUS ret = 1;
	if(NtProtectVirtualMemory_orig != 0)
		ret = NtProtectVirtualMemory_orig(h,p,s,u,pu);
	SetHooks();
	return ret;
}


BOOL APIENTRY DllMain(_In_ HANDLE _HDllHandle, _In_ DWORD _Reason, _In_opt_ LPVOID _Reserved)
{
	if(_Reason == DLL_PROCESS_ATTACH)
	{
		NtProtectVirtualMemory_orig = (NtProtectType)DetourFunction((PBYTE)NtProtectVirtualMemory,(PBYTE)NtProtectHook);
		MessageBoxA(NULL,"Injected Successful!","The BeatUpXCrap.dll",MB_OK);
	}
	return TRUE;
}


void SetHooks()
{
	MessageBox(NULL,L"NtProtect called",NULL,MB_OK);
	SetUnhandledExceptionFilter(Exceptions);
	CONTEXT ctx;
	ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;
	ctx.Dr6 = 0x00000000;
	ctx.Dr0 = (DWORD)EnumProcesses;
	ctx.Dr7 = 0x00000001;
	SetThreadContext(GetCurrentThread(),&ctx);
}


LONG WINAPI Exceptions(_EXCEPTION_POINTERS* ExceptionInfo)
{
	MessageBox(NULL,L"EnumProcesses called",NULL,MB_OK);
	if(ExceptionInfo->ExceptionRecord->ExceptionCode==EXCEPTION_SINGLE_STEP )
	{
		if ((DWORD)ExceptionInfo->ExceptionRecord->ExceptionAddress==(DWORD)EnumProcesses)
		{
			ExceptionInfo->ContextRecord->Eip=(DWORD)EnumProcsHook;
			return EXCEPTION_CONTINUE_EXECUTION;
		}
	}
	return EXCEPTION_CONTINUE_EXECUTION;
}

"NtProtect called" kommt, aber "EnumProcesses called" nicht, komischerweise kommt letztere aber, wenn ich Cheat Engine öffne und sich das Spiel schließt.
Dann kommt die MessageBox plötzlich...

Naja danke für deinen Tipp, ich werde es mal damit probieren.

Tyrar · 03/26/2010, 16:29

Quote:

Originally Posted by MrSm!th

eigentlich schon probiert zu jumpen, und auch genau so.
aber noch nie mit basepointer sicherung davor...stimmt...
was genau bewirkt das pop ebp genau? wird da nicht dann der basepointer auf die rücksprungadresse gesetzt?

das ding sichert dir den stack (deswegen wenn du VORHER irgendwas callen willst register backup)!

Quote:
Würde es nicht auch bei MessageBox passieren, würde ich denken, es liegt am Trampolin.
Denn bei NtProtectVirtualMemory ist mir das gleiche passiert, bis ich dann mal
Code:
if(NtProtectVirtualMemory_orig != 0)
eingebaut hatte.
Also war wohl der Pointer ungültig; allerdings passiert es ja hier auch bei anderen Calls.
Das Verwirrende nur: Es gibt keinen Zusammenhang!
calls mit keinen Parametern crashen nicht, manche Calls mit Parametern schon, manche nicht.
Ich verzweifle hier noch....
Übrigens bei ProtectVirtualMemory gehts auch eben dann ohne callen der original Funktion (passiert ja da NtProtectVirtualMemory_orig == 0 ist) ohne Access Violation oder Crash o.O

das kann schon an den calling conventions liegen, ja.
aber auch daran dass du an den registern was änderst, was nicht geändert werden darf!
deswegen auch hier vorher nen backup machen!
daran kann es auch liegen dass du keinen zusammenhang siehst, den es auch garnicht gibt

wenn du nicht an die originale funktion zurück springst, kann die auch wohl schlecht crashen

Quote:

Tjaja, da bin ich auch schon drauf gekommen, aber wie loggen?
Kann keine Calls machen, zumindest die meisten nicht -> Filewriting unmöglich.
Themida -> schlecht fürs Debuggen.

ja stimmt, wie oben schon gesagt: backups!
ansonsten schieb einfach jedes register auf ne variable, und call dann OutputDebugString! solltest du allerdings vorher mit stringstream zu nem string konvertieren.
wober themida debuggen schon geht

soweit ich das mitbekommen habe, hat themida nen thread am laufen der die ganze zeit ne abart von IsDebuggerPresent laufen lässt. den thread solltest du mit SuspenThread anhalten.

Quote:

Ich habe jetzt übrigens eine neue Möglichkeit gefunden.
Nämlich Hardware BPs auf EnumProcesses, anstatt normalen Detours und hooken von NtQueryVirtualMemory.
Allerdings sind die ja nur Threadintern; kein Problem dachte ich und habe eine andere Funktion (NtProtectVirtualMemory) gehookt und dann von ihr die Exceptionhandler und die BPs setzen lassen.
Klappt nun ENDLICH auch ohne Crash und ohne Fehlermeldung, nur leider wird nicht gehookt.

gut, von hardware breakpoints halte ich nicht viel

allerdings zum debuggen oder what ever benutz ich die auch gerne!

Quote:

Ein Code sagt mehr als 1000 Worte:

Code:

typedef	BOOL (WINAPI *EnumProcType) (DWORD * lpidProcess,DWORD cb,LPDWORD lpcbNeeded);

typedef	NTSYSCALLAPI NTSTATUS (NTAPI *NtProtectType) (HANDLE,PVOID*,PSIZE_T,ULONG,PULONG);

EnumProcType EnumProcs_orig = NULL;

NtProtectType NtProtectVirtualMemory_orig = NULL;


void SetHooks();
LONG WINAPI Exceptions(_EXCEPTION_POINTERS* ExceptionInfo);


BOOL WINAPI EnumProcsHook(DWORD * pids,DWORD cb,LPDWORD Needed)
{
	pids = NULL;
	Needed = NULL;
	return TRUE;
}


NTSTATUS NTAPI NtProtectHook(HANDLE h,PVOID *p,PSIZE_T s,ULONG u,PULONG pu)
{
	NTSTATUS ret = 1;
	if(NtProtectVirtualMemory_orig != 0)
		ret = NtProtectVirtualMemory_orig(h,p,s,u,pu);
	SetHooks();
	return ret;
}


BOOL APIENTRY DllMain(_In_ HANDLE _HDllHandle, _In_ DWORD _Reason, _In_opt_ LPVOID _Reserved)
{
	if(_Reason == DLL_PROCESS_ATTACH)
	{
		NtProtectVirtualMemory_orig = (NtProtectType)DetourFunction((PBYTE)NtProtectVirtualMemory,(PBYTE)NtProtectHook);
		MessageBoxA(NULL,"Injected Successful!","The BeatUpXCrap.dll",MB_OK);
	}
	return TRUE;
}


void SetHooks()
{
	MessageBox(NULL,L"NtProtect called",NULL,MB_OK);
	SetUnhandledExceptionFilter(Exceptions);
	CONTEXT ctx;
	ctx.ContextFlags = CONTEXT_DEBUG_REGISTERS;
	ctx.Dr6 = 0x00000000;
	ctx.Dr0 = (DWORD)EnumProcesses;
	ctx.Dr7 = 0x00000001;
	SetThreadContext(GetCurrentThread(),&ctx);
}


LONG WINAPI Exceptions(_EXCEPTION_POINTERS* ExceptionInfo)
{
	MessageBox(NULL,L"EnumProcesses called",NULL,MB_OK);
	if(ExceptionInfo->ExceptionRecord->ExceptionCode==EXCEPTION_SINGLE_STEP )
	{
		if ((DWORD)ExceptionInfo->ExceptionRecord->ExceptionAddress==(DWORD)EnumProcesses)
		{
			ExceptionInfo->ContextRecord->Eip=(DWORD)EnumProcsHook;
			return EXCEPTION_CONTINUE_EXECUTION;
		}
	}
	return EXCEPTION_CONTINUE_EXECUTION;
}

"NtProtect called" kommt, aber "EnumProcesses called" nicht, komischerweise kommt letztere aber, wenn ich Cheat Engine öffne und sich das Spiel schließt.
Dann kommt die MessageBox plötzlich...

Naja danke für deinen Tipp, ich werde es mal damit probieren.

naja.... mit den nt funktionen kenne ich mich garnicht aus

allerdings DENKE ich mal, dass Exceptions nen callback is?!

MrSm!th · 03/26/2010, 16:57

ok werds mal testen

Quote:

Originally Posted by HeavyHacker

daran kann es auch liegen dass du keinen zusammenhang siehst, den es auch garnicht gibt
wenn du nicht an die originale funktion zurück springst, kann die auch wohl schlecht crashen

Nein, ich meinte das Spiel selbst. Wenn der Speicher Read-Only ist und VirtualProtect das auch nicht ändert, müsste es ne Exception geben, wenn darauf zugegriffen wird...
obwohl...es wird ja nur gelesen^^
[quote]

ja stimmt, wie oben schon gesagt: backups!
ansonsten schieb einfach jedes register auf ne variable, und call dann OutputDebugString! solltest du allerdings vorher mit stringstream zu nem string konvertieren.
wober themida debuggen schon geht

soweit ich das mitbekommen habe, hat themida nen thread am laufen der die ganze zeit ne abart von IsDebuggerPresent laufen lässt. den thread solltest du mit SuspenThread anhalten.[/quote
dafür muss ich ihn erstmal finden.
aber du hast recht, sowas ist mir auch schon aufgefallen.
Mit NtQueryInformationProcess Hooken (was mir vorher überall empfohlen wurde bei Themida) und auch allem anderen, was mir eingefallen ist, konnte ich das detected werden nicht verhindern, aber mir wurde ein plugin geschickt, das werde ich mal testen...

Quote:

gut, von hardware breakpoints halte ich nicht viel
allerdings zum debuggen oder what ever benutz ich die auch gerne!

find es auch unpraktisch, sind aber schwer zu detecten

Quote:

naja.... mit den nt funktionen kenne ich mich garnicht aus
allerdings DENKE ich mal, dass Exceptions nen callback is?!

musst du ja nicht, hier gehts ja um die Exception handler chain
und ja, sie ist ein callback für Exceptions

Tyrar · 03/26/2010, 17:32

[quote=MrSm!th;4641678]ok werds mal testen
Nein, ich meinte das Spiel selbst. Wenn der Speicher Read-Only ist und VirtualProtect das auch nicht ändert, müsste es ne Exception geben, wenn darauf zugegriffen wird...
obwohl...es wird ja nur gelesen^^

Quote:

ja stimmt, wie oben schon gesagt: backups!
ansonsten schieb einfach jedes register auf ne variable, und call dann OutputDebugString! solltest du allerdings vorher mit stringstream zu nem string konvertieren.
wober themida debuggen schon geht
soweit ich das mitbekommen habe, hat themida nen thread am laufen der die ganze zeit ne abart von IsDebuggerPresent laufen lässt. den thread solltest du mit SuspenThread anhalten.[/quote
dafür muss ich ihn erstmal finden.
aber du hast recht, sowas ist mir auch schon aufgefallen.
Mit NtQueryInformationProcess Hooken (was mir vorher überall empfohlen wurde bei Themida) und auch allem anderen, was mir eingefallen ist, konnte ich das detected werden nicht verhindern, aber mir wurde ein plugin geschickt, das werde ich mal testen...

find es auch unpraktisch, sind aber schwer zu detecten

musst du ja nicht, hier gehts ja um die Exception handler chain
und ja, sie ist ein callback für Exceptions

da es nen callback ist, is wohl klar dass es erst bei nem crash aufgerufen wird <.<

nochmal zu themida: ich wette dass themida nach nem debugger über

Code:

__asm
{
mov eax, fs:[30h]
mov al, [eax+2h]
}

prüft. wenn al = 0 wird der prozess nicht debugged!
versuch mal da durch nen thread ständig 0 rein zu schreiben

MrSm!th · 03/26/2010, 17:36

Quote:

Originally Posted by HeavyHacker

Quote:

Originally Posted by MrSm!th

ok werds mal testen
Nein, ich meinte das Spiel selbst. Wenn der Speicher Read-Only ist und VirtualProtect das auch nicht ändert, müsste es ne Exception geben, wenn darauf zugegriffen wird...
obwohl...es wird ja nur gelesen^^

da es nen callback ist, is wohl klar dass es erst bei nem crash aufgerufen wird <.<

eben nicht.
dafür sind exceptionhandler da, dass sie bei einer exception aufgerufen werden.
was glaubst du sonst, warum deine breakpoints auch nicht erst am ende des programms wirken ;P <.<
wie kommst du darauf, dass ein callback erst dann aufgerufen wird?
was ist denn mit der windows nachrichtenschleife? ;P

Quote:
nochmal zu themida: ich wette dass themida nach nem debugger über
Code:
__asm
{
mov eax, fs:[30h]
mov al, [eax+2h]
}
prüft. wenn al = 0 wird der prozess nicht debugged!
versuch mal da durch nen thread ständig 0 rein zu schreiben

soweit ich weiß, macht themida nicht nur einen check und schon gar nicht mit sowas billigem wie der überprüfung dieses flags.
da sind noch ein paar sachen mehr.

Tyrar · 03/26/2010, 17:46

Quote:

Originally Posted by MrSm!th

eben nicht.
dafür sind exceptionhandler da, dass sie bei einer exception aufgerufen werden.
was glaubst du sonst, warum deine breakpoints auch nicht erst am ende des programms wirken ;P <.<
wie kommst du darauf, dass ein callback erst dann aufgerufen wird?
was ist denn mit der windows nachrichtenschleife? ;P

soweit ich weiß, macht themida nicht nur einen check und schon gar nicht mit sowas billigem wie der überprüfung dieses flags.
da sind noch ein paar sachen mehr.

der callback sollte erst bei nem error aufgerufen werden, so meinte ich das!

1 flag is doch nen anfang XD

MrSm!th · 03/26/2010, 21:20

Quote:

Originally Posted by HeavyHacker

der callback sollte erst bei nem error aufgerufen werden, so meinte ich das!

1 flag is doch nen anfang XD

ja das ist es doch

ich denk du kennst Hardware BPs?
Sie lösen eine Exception aus.
Dann wird der erste Exceptionhandler aufgerufen, welcher meiner sein müsste und es wird verarbeitet; wenn er nichts macht, wird die Exception an den nächsten weitergegeben...
Mein Handler ändert einfach den EIP auf die Adresse von meiner Hookfunktion um BAM gehookt ;P
Nur leider wird ja nichtmal der Handler aufgerufen, obwohl die Adresse, die es betrifft, passiert wird.
Ist irgendwas an den BPs falsch?

Tyrar · 03/27/2010, 13:27

Quote:

Originally Posted by MrSm!th

ja das ist es doch
ich denk du kennst Hardware BPs?
Sie lösen eine Exception aus.
Dann wird der erste Exceptionhandler aufgerufen, welcher meiner sein müsste und es wird verarbeitet; wenn er nichts macht, wird die Exception an den nächsten weitergegeben...
Mein Handler ändert einfach den EIP auf die Adresse von meiner Hookfunktion um BAM gehookt ;P
Nur leider wird ja nichtmal der Handler aufgerufen, obwohl die Adresse, die es betrifft, passiert wird.
Ist irgendwas an den BPs falsch?

also das is eigendlich ne gute hooking methode

ich glaub das werd ich auch mal versuchen XD

naja könnte sein dass die bp falsch gesetzt sind?

MrSm!th · 03/27/2010, 13:59

Naja geht so.
Hardware BPs und Exceptionhandler sind Threadintern.
D.h. du musst irgendeine Funktion hooken, von der du weißt, dass sie im richtigen Thread gecalled wird und die nicht gecheckt wird.
Dann lässt du sie den Handler und die BPs setzen.
Das ist in meinem Falle NtProtectVritualMemory, trotzdem klappt es nicht >.<

Falls du dich darüber informieren willst, das nennt sich Structured Exception Handling kurz SEH; einfach mal in Verbindung mit Hook googlen.
Oder bei Game Deception gucken

edit:

So die HWBPs gehen nun, hatte sie tatsächlich falsch gesetzt, mein Rechner stürtzt zwar leider ab, aber es geht

Aber die eigentliche Frage steht immernoch

MrSm!th · 03/29/2010, 12:10

Also hat nun jemand eine Lösung für Hardware Breakpoints?
Entschuldigung für den Push, aber es verwundert mich, dass ich sie mit Olly setzen kann, aber von Hand einen Systemfreeze bekomme.
Das mit NtQueryVirtualMemory steht auch noch offen, ist aber nun von geringer Priorität, da ich einen anderen Weg gefunden habe, EnumProcesses zu hooken, sodass es undetected bleibt.

Tyrar · 03/31/2010, 11:44

wie setzt du die bp? mit

Code:

int 3

oder was anderem?

MrSm!th · 03/31/2010, 14:46

Quote:
Originally Posted by HeavyHacker
wie setzt du die bp? mit
Code:
int 3
oder was anderem?

nein, hardware breakpoints
mit den debug registern und SetThreadContext
(der code ist doch auf seite 2 o.O)

Tyrar · 03/31/2010, 15:00

Quote:

Originally Posted by MrSm!th

nein, hardware breakpoints
mit den debug registern und SetThreadContext
(der code ist doch auf seite 2 o.O)

könnte es sein dass in der SetHooks funktion GetThreadContext fehlt