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).

Found the input code in Crysis 3

Because there are things I needed to do, I decided to search for the input loop, that fetches input from the mouse, I found it through a lot of effort, it was hard because the DirectInput class exposes an interface, which as you know would be virtual methods implementing the interface, so there would be a vtable with pointers, and there was no way to know for sure which function was CreateDevice,GetDeviceState, so I had to code my own DirectInput samples to find this out.

After quite a lot of while

[Image Deleted].

Obviously, a lot is left to explore, as there is something I want to achieve by finding this piece of code.

Spotcheck/Triggers in SecuROM.

Spotcheck/Triggers are what the developer of SecuROM, Robert Yates, calls the piece of code which is responsible for altering the game if tampering of any kind is detected.

Altering like making the final boss in Crysis 3 invincible, or making the ball in Fifa 14 unusually large. These are not bugs/glitches, they are intentional. They are, however not always caused by tampering with the game, but sometimes because of an installation gone wrong with the game, and usually a reinstall should resolve this. Worst case scenario, it's because of some piece of malware running on the system.

Once I was able to run the game under a debugger, it would suddenly get terminated after a while. I identified two threads that were responsible for this and brutally killed them, this didn't affect the game and it was no longer being terminated.

Regarding EADRM in general.

So while I was writing my Crysis 2 articles, I found out something, the OEP for what I can assume is every game released in the past few years via Origin, is stored in the actual .exe, near the end of the file, just after the four characters IREW(all capital), as in the 4 bytes after IREW is the OEP. So writing those down, adding to them the image base(and working out any relocation that might happen), you are at OEP, you put a HW breakpoint for instance on execution on the OEP, once you break you can just dump, all that's left is to fix imports.

That said, Crysis 2 was easy as pie to unpack, but Crysis 3 after unpacking has another layer of protection, this time much more advanced for the average joe(aka me) to unpack. Robert Yates, the guy who cracked SecuROM a while back told me that Crysis 3 uses an older version of SecuROM, obviously not that old, probably 8.X.
For now, SecuROM is beyond me.

Addendum: Fixed typo, it was IREW and not IWER.

Update 8d/2m/2016. The information above is no longer relevant, Origin have updated their DRM.