hi,

instead of using 0xCC and windows' debug api, use E9s that executes injected code that tells the debugcontrol process that a corresponding 'breakpoint' was reached and suspend the debugee with WaitFor api. even read/write access breakpoints should be possible (using PAGE_GUARD and an own KiUserExceptionDispatcher)

so what do you think, is this possible and does it work well?

Hello,

First of all, I'm really interested about what was the main goal of your idea when you were thinking about it. An anti-anti-debug technic ? (no cristicism, knowing the main goal could help, at least me, to know what to reach)

Nice feature indeed, I was trying to think about problems arised by this method (ie: where to inject the WaitForxxx code, but a simple virtualAllocEx is solving it). I found it very interesting.

As far as I could seen, this idea is just avoiding us to put INT3, and therefor checks for 0xCC will be fooled, but are there any other advantages ? (I'm really trying but couldn't see them... ). Even CRCs will then be wrong.

I don't really know if any of the synch. functions is really "freezing" the debuggee like when a BP occurs. I don't think some of the API will then work (for example GetThreadContext which requires the thread to be suspended, therefore you can't run any code nor enter a waiting state). Ok that's a little problem if compared with some benefits while using your method.

Moreover the INT3 feature is giving a total control of the debuggee to the debugger, which your method cannot (i.e: reading the DEBUG_EVENT struct for example).

Anyway, I do not see currently any "big" problems, but I'm waiting for other answers.

Indeed, talking about new possibilities/ideas in the R.E filed is always a pleasure, you get my thumb up

when the process is not beeing debugged with windows api, many detections are fooled. so its not only to prevent 0xcc.

and i was also thinking about doing this stuff for ring0 code.

crc checks will be an issue.

for ring3, this could be solved with PAGE_GUARD. when the process read its mem, it will violate the guard and this way a fake value could be returned (or something like this)

*HINT* If you write your own debugger, you can use breakpoints other than int3. Think to yourself, what other kinds of instructions will cause an exception which my debugger can catch?

Then it's a simple matter to hide your debugger on top of that (hide isdebug flags, hook ntqueryinformationprocess, etc), and you will have uber non-detectable debugger.

Also, add more power. For example, in unpackers instead of BPX on API calls, put in a disam engine (taken from olly sources) and scan the API until a RETN, and put the bpx there. Detector code cannot find it since there may be 0xCC bytes inside the API routine that would screw it. (For example, a mov eax, [0x66CC]). Once you are on the RETN the stack will look the same as when you were at the entry to the function, so you can modify values, etc. Also you can modify the return values then as well.

Just more ideas for u.

-nt20

Hi

Interesting ideas. Could the injected code also be used to *set* breakpoints, say on the return address or a few instructions ahead? This would be sort of a "runtime" insertion of a 0xCC or manual setting of the debug registers. In this way one could avoid any code which might check the state of the debug registers. The debugger would then clean up the injected bytes if desired and clear DRx until the next time. Traditional CRC checks could be avoided by limiting the detour functions to API's and not patching program code.

Kayaker