Hunting for the mysterious anti-debug.

Well, it's probably not that mysterious. But let me point you to my last post, where I mentioned the problem briefly in the last paragraph.

I mentioned there were two threads, one is 3939EF70 and the other is 3939F9C0. Since the game utilizes no ASLR, and SecuROM expects most addresses to be the same on any system(hardcoded), there is no need to recompute them for each system.

The first thread to be started is 3939EF70, the thread is extremely obfuscated, here is but a sample of it

lea esp,[esp-4]
mov dword ptr ss:[esp],ebp
mov ebp,esp
sub esp,4
mov dword ptr ss:[esp],32E
xor dword ptr ss:[esp],00000326
sub esp,dword ptr ss:[esp]
lea esp,[esp-4]
mov dword ptr ss:[esp],esi
mov eax,-1D9
mov eax,dword ptr ds:[eax+3C04C67D]
xor eax,0000911A
mov dword ptr ds:[3C04C4A4],eax
mov eax,-0E7
mov eax,dword ptr ds:[eax+3C04C58F]
xor eax,00009A12
mov dword ptr ds:[3C04C4A8],eax
mov eax,-55
mov eax,dword ptr ds:[eax+3C04C4F9]
add eax,dword ptr ds:[3C04C4A8]
mov dword ptr ds:[3C04C4AC],eax
call 3939EFE5
add dword ptr ss:[esp],3E
push dword ptr ss:[esp]
sub dword ptr ss:[esp],3B
push ebx
mov ebx,dword ptr ss:[esp+4]
xchg dword ptr ss:[esp],ebx
xchg dword ptr ss:[esp],ebp
mov ebp,dword ptr ss:[ebp]
sub ebp,13
xchg dword ptr ss:[esp],ebp
mov dword ptr ss:[esp+4],A60004C2
jmp short 3939F00F
retn 4

This is from the tracer, in reality some of these instructions are overlapped. This thread seems to, initially, just loop over, checking for a value if it is bigger or smaller than another at particular hardcoded addresses, and jumps to different piece of code, but they all ultimately end at the same place initially, GetTickCount,+120 seconds to the value returned by GetTickCount, and then Sleep(120 seconds).

It repeats the aforementioned Sleep infinitely, until the other thread 3939F9C0 signals it, by writing different values to these hardcoded addresses, thereby making that thread 3939EF70 take different branches. At some point, 3939EF70 starts another thread with CreateRemoteThread that executes the VM. Interestingly, there is no synchronization between the threads, both threads rely on the fact that the either of them will Sleep when one is modifying the same addresses.

I mentioned an anti-debug, that's right. The game runs under a debugger for as long as thread 3939F9C0 allows it to, then randomly between 5-30 minutes(rarely longer) the thread calls NtTerminateProcess.
I've been speculating this is a timing anti-debug, that there is some 'avg' value that goes up as the debugger handles various events and generally slows down the game by 20-30%. As soon as this value crosses some threshold, it calls NtTerminateProcess. This seems to be further reinforced by the fact, that if I were to start the game under a debugger, detach, the game would never terminate. If that is not the case, then I am being detected by a different method.

Oh yes, I managed to manually patch the exe to disable code verification. Now I can tamper with some of the code(except the packed code which I can only modify at runtime).