Topic created on: September 10, 2008 02:56 CDT by kcynice.
if i want to do some anti-debug trick in a driver, when the GUI client is debugged the driver can find it. should i do it as a normal user-mode program?
> Soul12: you wanna defeat a anti-dbg trick on a driver ? or make a anti-debugging driver ?
>
> if you wanna make a Driver for Anti-debugging purpose , the same methods as for ring3 applies ..with i guess the normal limitlessness of ring0.
In fact, i wanna defeat a anti-debug trick on a driver.
A software has its own driver, if i insert any breakpoints anywhere, it will encounter a fatal error and abort running.
So, i think there must be any anti-debug tricks embedded in it. I want to know how it completement such job. Any ideas? Thanks.
if you used hardware breakpoints, it might check for DRx registers. try to find manipulations on DR0 - DR3 regs as well as a kernel debugger detection via DR7.
you might also try to set a software breakpoint by using 0xcc mnem or just jmp in loop using 0xeb + 0xfe.
if this also gets detected, the driver might use a self-defense technique, by testing for a checksum of its own code somewhere.
another solution:
PAGE_NOACCESS. in this case ACCESS_VIOLATION exception will be generated, so you have a chance to fool your driver. OllyDbg supports this kind of breakpoint. Context Menu -> BreakPoint -> Memory, On Access (none: Memory, On Access means: read or execute)
there is more complicated technique:
unload the page off the memory and break on #PF (0Eh). Soft-Ice can do this, or you can do it manually with any kernel debugger (just know the page table format).
if it doesn't work. well. try this: a lot of protection control .text section integrity, but... who controls .data? nobody! so, just find the nearest pointer, stored into global/static variable and turn it to zero to cause an exception. this is not a breakpoint, but... kind of.
I think i got the resolution now. Fortunately, i get rewarded. Just so so.
Yes, the program does use driver anti-debug. I don't think that's a bad choice. The driver just move the user level anti-debug tricks into kernel mode. In fact, the main program has been encrypted. so, if we insert any breakpoint(int3), the decrypted codes will be wrong. The main program will send specified io request(via DeviceIoControl) to ask the driver to decrypted some specified code block at special phase. Inaddition, the driver will also do some other anti-debug job to defend itself. I got it after i had learn some basic information about driver debugging.
> nezumi: another solution:
> PAGE_NOACCESS. in this case ......
Yes, its a little complex for me, a newbie for reversing. But I will do my best to digest what you advised, thanks.
Note: Registration is required to post to the forums.