Log in

View Full Version : interesting time based debugger detection


LiSa
April 1st, 2005, 04:28
hello,

I found an interesting debugger detection wich use the pseudo random generator of
irvinelib : random32(seed). It is looking like :

time1 := keGetSystemTime()
/ / little stuff
time2 := keGetSystemTime()

value1 := random32(time2) xor random32(time2) mod 5 * time1
/ /
later

number = complexfunction (value1) mod 3

if number =0 ou 1 -> BAD
if number =2 OK

I ripped part of code and make a small prg to test this,the results are the following :

If time 2 - time1 < 5 ms will return 2
If time 2 - time1 > 5 ms will return 0 or 1

So this program is indeed monitoring iteself the performance of a pseudonumber generation,
if debugged this is somewhat altered and you are detected.

I fake this by patching time1 and constraining time2=time1+2 (very fast computer...

Have someone already seen such a stuff and what is the mathematical backgound behind that?

Thanks.

naides
April 1st, 2005, 08:08
I have a question: If you call random32 two times WITH THE SAME SEED, would not it return the same number both times? then



Quote:
[Originally Posted by LiSa]
value1 := random32(time2) xor random32(time2) mod 5 * time1

equals

value1 := 32bitconst xor 32bitconst mod 5 * time1

value1 := 0 mod 5 * time1

value 1:= 0 Always (??)


/ /
l


Or am I wrong?

LiSa
April 1st, 2005, 10:13
I made a little mistake,

value1 := random32(time2) xor (time1 mod 5 * time1)

thank you

nikolatesla20
April 1st, 2005, 11:16
I know SoftDefender uses this trick, as well as a host of other nice ones.

-nt20

naides
April 1st, 2005, 11:44
Quote:
[Originally Posted by LiSa]
value1 := random32(time2) xor (time1 mod 5 * time1)
thank you


OK now I understand a little better.

What you have determined so far using a black-box/experimental approach (which is perfectly valid, by the way)
is that the program is using a convoluted and obfuscated way to evaluate a simple question: What is the lapse time difference between time2 and time1?

The program brackets a critical stretch of code with the two keGetSystemTime() calls and later figures out how apart they were, effectively detecting realtime tracing.

They obscure the comparison with the random32 function but once you learn the inner workings of random32 generation, is not more difficult to detect and neutralize than seeing code directly compare time1 and time2 and generating a badboy call if the difference is more than five miliseconds.

I think you did a great job locating and dissecting this tracing detection device.