Loggind addresses without debugger

[GoJonnyGo]

Hi!

I am thinking off a tool, which can log all addresses that are executed but not by beeing a debugger. Is this possible? If yes, how can i implement this? I thought about hook EP and then set again hook at every line but that would never work I think because of timing.

The reason why this would be useful, is to counterpart custom anti debug. I think in the future will be more and more well hidden custom anti debug, which shows its results about 1000 lines later and you cant find them. So if this would work we could see the flow of the program without using a debugger or olly at least and see at which line the flow of olly and the flow of this program would be different. So is there any chance to implement such a tool, which can logg all addresses which are executed, something like tracing in olly but only with addresses.

[metr0]

Well, shouldn't it be doable then to locate the crash and backtrace all the variables involved in the process using a disassembler? Not sure if there's a trend towards anti debug (I'd say developers are better off using them rarely due to the impact on compatibility).

How would it be hidden then? Obfuscation, VM code? This would mean a bit more work for the reverser but is far from unachievable.

[GoJonnyGo]

well if the antidebug crashes the pc suddenly you can't analize what is going on

and also if it would ned crash the pc... just refering to an crackme from lena151...

a good hidden anti debug and noone could solve it.

Edited April 15, 2010 by GoJonnyGo

[Killboy]

Bear in mind obfuscation that can go several ways to end up at the same place, Execryptor has lots of this code:

test edi, edi

jz meh

jmp hax

meh:

push offs hax

retn

....

hax:

// both go here

Now, imagine 1000s of these, good luck finding the antidebug in there.

But in general, it's perfectly possible to build a tracer w/o using the Windows debug API. You can install a vectored exception handler and patch the current instruction to a 1-byte instruction that just raises an exception. In your exception handler, log the instruction, restore the byte and patch the next instruction. Might need some code flow logic to find out what the next instruction is going to be (conditional jumps, calls, ret, etc.)

Edited April 15, 2010 by Killboy