Have I found the mysterious anti-debug?

In my previous post I mentioned that running the game under a debugger, would, after a while, force terminate the game.
I speculated either the debugger was being found by an API directly, or indirectly via a timing anti-debug.

I did some experiments. And the evidence points to a timing anti-debug. The time it takes to terminate the game is variable, and it turns out, it only happens if the performance of the game is rather bad. In this case, it was Olly 2's fault. There seems to be some kind of bug in Ollydbg 2.01 whereby all threads of a running application are suspended and resumed constantly, the game runs although with a 30-35% penalty. The timing anti-debug sees this, sees that more ticks are being expended than normal and with careful communication between two threads, it calls NtTerminateProcess by spawning several threads that point to a VM program(only of the thread has a different VM program than the rest)..
In most cases, what Olly is doing is normal behaviour, it's how it's usually done, but not in my case, I've observed olly idling and not doing this suspend/resume thing. The bug seems to disappear if I(at least in my case) I hit a memory breakpoint. Then olly is acting normal, and the game does not terminate, or at least not as fast as before, if the avg grows as time passes, because of small slowdowns, then it will terminate eventually.

I looked at my trace log of one of the obfuscated threads, lo and behold, RDTSC on address 3955DEA9(quick reminder there is no ASLR). The result of RDTSC is stored in EDX:EAX, these values are later used in a loop and are encrypted and stored in a table.
Now that I know what is what, I can better understand the underlying algorithm. One thing is certain, the mystery is solved.

Quick reminder that timing anti-debugs are in my opinion, the most difficult to handle, it isn't as easy returning 0 on GetTickCount.

Success, defeated the antidebug of Crysis 3.

Well after a month I finally made progress. Turns out the error code 2001 I was getting was caused by GetTickCount returning 0 or a unreasonable value. After fixing this I got an error code value of 8011, then I patched the ProcessDebugFlags check(0x1f on NtQueryProcessInformation) and the game now runs under a debugger.

Obviously this is good news, but far from the expected result. Where is the VM? What does it do? What kind of anti-dumping techniques are used? Many more questions to be answered.

This is what SecuROM v8.10.008 packs so far.

I've identified the following anti-debug techniques.

ZwQueryInformationProcess, the parent process PID is stored in the InheritedFromUniqueProcessId field of the _PROCESS_BASIC_INFORMATION structure, which is then used in an OpenProcess call, which opens the parent process. No idea what happens when the call is made.
CreateFileA on the parent process, afterwards call to ReadFile, SecuROM tries to read the PE header supposedly.
Then we have various calls to CreateFileA on various files like ntice,sice,jcdspy etc.
FindWindow searching for various applications's windows, some of which are at or over 10 years old.
A call to EnumWindows with a custom callback function.
NtQueryObject call to check for the DebugObject.
ZwQuerySystemInformation with the SystemKernelDebuggerInformation class(0x23) which doesn't seem to indicate a debugger under Windows 7 x64.
And obviously, calls to IsDebuggerPresent,CheckRemoteDebuggerPresent,GetTickCount,QueryPerformanceCounter,GetSystemTime.

This is by far an exhaustive list. I've barely scratched the surface.

On a sidenote, GetTickCount is proving to be much more difficult to beat. Because if GetTickCount is patched to return 0, I end up getting an error code value of 2001 meaning Win95 not supported, oddly, GetTickCount was introduced in Windows 2000.