Log in

View Full Version : DR7.GD bit and DRX access exception problem

0rp
August 25th, 2004, 04:59
hi,

i wrote a driver, which enables the GD (general detection) bit in the DR7 reg. if this bit is set, any access to one of the debugregs (like mov eax, dr2) results in an int 1 exception.

i also hook int 1 to catch these exceptions, and handle them my own way (i never write to the DR regs or return fake values from them).

this idea isn't new, it is based on yates' DRxLOG.

everything seems to work, a doom3 start looks like this (safedisc debug checks):
code=mov dr6, ebx, image=winlogon.exe, addr=804DDD26, fake=yes
code=mov dr7, ecx, image=winlogon.exe, addr=804DDD29, fake=yes
code=mov eax, dr1, image=Doom3.org.exe, addr=B29E88A4, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E88BA, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E892B, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E892B, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E892B, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E892B, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E892B, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E892B, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E892B, fake=yes
code=mov eax, dr7, image=Doom3.org.exe, addr=B29E892B, fake=yes
code=mov dr7, ebx, image=winlogon.exe, addr=804DE049, fake=yes
code=mov dr0, esi, image=winlogon.exe, addr=804DE04C, fake=yes
code=mov dr1, edi, image=winlogon.exe, addr=804DE052, fake=yes



but i have a little problem (yates' driver too): if i start a random app (notepad) from ollly, no new exceptions are thrown.

it seems, that olly is able to set the DR7.GD bit to 0 and disables the GD exception.

but how? any access to DR7 should be faked through my handler ?!

the code of this driver is attached
bilbo
August 25th, 2004, 10:33
Hi, 0rp,

nice toy you are playing with...
I do not understand anyway why WINLOGON address space is involved... the same happens on my XP machine...

Quote:
it seems that olly is able to set the DR7.GD bit to 0 and disables the GD exception.

It's not Olly, but processor architecture... Look at Intel manual...
Quote:
The processor clears the GD flag upon entering to the debug exception handler, to allow the handler access to the debug registers.

Now, in your INT 1 handler, if DR6 does not say you that a debug register access has been detected, you jump directly to label executeOldHandler, forgetting to set again GD bit in DR7! From that moment, your handler will no more be called when debug registers are accessed.

By the way, why are you forcing six calls to your handler inside
unHook()?
Code:
 __asm {

     mov eax, dr7

     mov eax, dr7

     mov eax, dr7

     mov eax, dr7

     mov eax, dr7

     mov eax, dr7

     }

I cannot see the need of them!

Regards, bilbo
0rp
August 25th, 2004, 14:04
Quote:
[Originally Posted by bilbo]forgetting to set again GD bit in DR7! From that moment, your handler will no more be called when debug registers are accessed.


thxalot, that is the problem

i do now
Code:


executeOldHandler:

		//re-enable GD

		mov eax, dr7

		or eax, 2000h

		mov dr7, eax



		popad

		jmp oldint1


which works more robust. it would be nice, to re-enable this bit after the old int1 code, but this should be impossible (?)

or i could try to modify the pushed returnaddr, that is used by the corresponding IRET and let it point to my code




Quote:
[Originally Posted by bilbo]By the way, why are you forcing six calls to your handler inside
unHook()?


you are right, there is no need for six movs. one mov is enough to trigger the handler
Opcode
August 26th, 2004, 14:42
Hi,

take a look in
http://www.woodmann.net/forum/showthread.php?t=5595

Maybe this thread help in something...

Regards,
Opcode