Results 1 to 4 of 4

Thread: DR7.GD bit and DRX access exception problem

  1. #1

    DR7.GD bit and DRX access exception problem

    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
    Attached Files Attached Files

  2. #2
    son of Bungo & Belladonna bilbo's Avatar
    Join Date
    Mar 2004
    Location
    Rivendell
    Posts
    310
    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...

    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...
    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
    Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt.[Seneca, Epistulae Morales 104, 26]

  3. #3
    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

  4. #4
    Hi,

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

    Maybe this thread help in something...

    Regards,
    Opcode

Similar Threads

  1. Replies: 1
    Last Post: June 25th, 2010, 19:27
  2. vectored exception handling
    By AttonRand in forum Advanced Reversing and Programming
    Replies: 6
    Last Post: February 22nd, 2010, 15:08
  3. Non-continuable exception trick
    By OpenRCE_omega_red in forum Blogs Forum
    Replies: 1
    Last Post: March 16th, 2008, 00:14
  4. 0EEDFADE exception
    By tonyxxy in forum OllyDbg Support Forums
    Replies: 6
    Last Post: March 9th, 2004, 10:29
  5. bug exception handler
    By Anonymous in forum Bugs
    Replies: 4
    Last Post: November 22nd, 2002, 00:19

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •