Analyzing the SecuROM 8.10.X VM.

I want to thank ARTeam for providing the docs on SecuROM 7.30 VM they really helped and are mostly still relevant today.

That said, I have not worked on SecuROM 7.30 ever, but I believe the VM has changed since then.

Here is an overview of the VM initialization.

When entering the VM, an argument is pushed to the stack. It's a pointer to a pointer to the VM opcodes. I call this argument a "program".
The dummy call after pushfd is used to get the address of the VM.

In the picture above several things happen. A spinlock is created by the thread which enters the VM and will initialize the context, all other threads, if any, will wait till the first thread has finished the initialization.

Then SecuROM uses the loop x86 construct to loop over all 100 possible VM thread contexts, and finds the first free one. The busy flag 0x66666666 indicates if a thread is busy or not. I should note that SecuROM 7.30 only supported up to 10 threads, SC 8.10 supports 100.

After the first free context is found, SecuROM jumps to the following code which sets the busy flag.

lea edx,[ebx+24]
mov dword ptr ds:[edx],66666666

then the VM context is zeroed out, but care is taken not to zero out the busy flag. Afterwards the lock is removed and the jump "je short 38D702FE" takes us to the last step of the initialization.

pop ebx loads the VM context for this thread in ebx.

sub dword ptr ss:[esp],7 subtracts 7 bytes from the VM function address which I mentioned above that it is pushed to the stack with a dummy call so it ends up as 38D70280 in this exe.

This part fills the VM context struct. I've taken the liberty of adding captions next to the instructions which are self-explanatory.

Next is this obfuscated code.

In a nutshell, it fetches the delta to the pointer to the opcodes, adds the VM entry point, and fetches 2 DWORDs(aka 8 bytes).

CPU Disasm
Address   Hex dump                 Command                                                      Comments
38D7035A    8B70 04              mov esi,dword ptr ds:[eax+4]
38D7035D    8B00                   mov eax,dword ptr ds:[eax]

The first 4 bytes of the opcode is the modifier, the next 4 bytes is the obfuscated address of the handler.
The modifier is used to calculate the next handler address. The one in the VM context is updated with this new one, after some xor and shifts are performed.

The "encrypted" address of the first handler is decrypted with a XOR.

xor esi,48371826

 It's then copied to eax.

Finally

CPU Disasm
Address   Hex dump                 Command                                                      Comments
38D70396    B9 19000000       mov ecx,19
38D7039B    83F1 1D              xor ecx,0000001D
38D7039E    01D9                   add ecx,ebx
38D703A0    8301 08              add dword ptr ds:[ecx],8 <-- Add 8 bytes to VM EIP
38D703A3    FFE0                  jmp eax

The VM EIP(program counter) is incremented by 8 bytes, and we jump to the address of the first handler.

Here comes the juicy part. The jump to first handler goes to this code

Step 1.

First, ebx+20 is updated with the address of the next pseudo handler, for a lack of a better word. And if we follow the jump we end up where the actual first instruction is executed in this particular handler.

Step 2.

and if we follow the jump we end up at what I call the "dispatcher". 

Step 3.

The dispatcher adds the VM entry point to the value added in ebx+20 to form the address of the next pseudo handler.

Basically, from what I understood, a single handler which is usually a sequence of instructions has been split into several small pseudo handlers each reached in three steps. In my opinion this is just obfuscation to slow down reverse engineering.

Sometimes in Step 1 there is an additional instruction that moves a value in ebx+400, which is usually used to substract 4 bytes from the stack pointer.

Now, if we follow the each jump and where it leads to, remove all jumps and dispatcher code, the first handler's code is basically this.

mov esi,dword ptr ds:[ebx+4]
add esi,dword ptr ds:[ebx+0C]
add esi,4
push dword ptr ds:[esi]
pop edi
mov dword ptr ds:[ebx+400],4
sub esi,dword ptr ds:[ebx+400]
push dword ptr ds:[esi]
pop esi
mov cl,byte ptr ds:[ebx+10]
push eax
xor eax,esi
xor eax,dword ptr ss:[esp]
add esp,4
shl eax,10
shr eax,18
xor al,2A
add byte ptr ds:[ebx+10],al
mov eax,3BF7C894
push edi
push eax
mov eax,esi
shl eax,18
shr eax,18
ror al,cl
xor al,78
shl eax,2
add eax,ebx
mov edi,eax
pop eax
push eax
pop dword ptr ds:[edi]
pop edi
push edi
pop eax
sub al,cl
xor eax,00B42D00
add dword ptr ds:[ebx+4],8 <-- Update VM EIP with 8 bytes.

In my case, this handler basically calculated the address of another handler.

This isn't an exhaustive analysis of the Securom 8 VM, it's but a scratch of the surface. Furthermore, I have not identified the VM exit procedure.

Denuvo and VMProtect are the same?

Recently I've been reading on Denuvo, and how certain code seems not similar but identical to that of VMProtect. Russian websites are also saying that Denuvo<=>VMProtect indicating that perhaps the two companies are sharing the same code base. That certain features in VMProtect appear in Denuvo and disappear in VMProtect, and vice-versa.

Here is the article in question (Russian).

Just Cause 3 and Denuvo

So apparently the same thing is happening with JC3 that happened with FIFA15 and DAI.

The founder of notorious Chinese cracking forum 3DM is warning that given the current state of anti-piracy technology, in two years there might be no more pirate games to play. The claims come after attempts to breach the Denuvo security protecting Just Cause 3 pushed the group's cracking expert to breaking point.

Do you know what drives technological innovation? Competition! Right now anti-tamper/DRM solutions are being sought because of piracy, and get broken, which forces the authors to come up with new and interesting ways to prevent their solution from being broken.

The same cannot be said from "our" side, us reverse engineers. Most people keep their tools private and we have a stagnation of publicly available tools to help us combat these new solutions and techniques.
Do you know why? Money, Denuvo is paid, cracking is something people do for free of charge, there is little incentive to release their internal tools or to release docs or even bother .

Until then, this "prediction" of 3DM might have some merit.

mmap equivalent in Windows or How To Map Physical Memory to Userspace.

Windows unfortunately has no equivalent of mmap that can access physical memory e.g by mapping /dev/mem to some userspace address, however this can be achieved by a simple(not really) kernel-mode driver that I've personally used in Windows 7 x64, though there should be no reason why it wouldn't work in Windows 8/8.1/10

I found it in this article on CodeProject.

Now, even if you compile the driver, on x64 Windows systems the driver needs to be signed, this for development purposes can be disabled, follow the article on MSDN on how to do that.

But beware, fiddling with physical memory can lead to some very dangerous results if you aren't careful, e.g permanent hardware failure or data loss.

The scary Virtual Machine

Sorry for the cheesy thread title, but I had no idea what to put there.

But anyway, I recently came across more virtual machines, and honestly, when you get to the jist of it, they aren't all that difficult to understand nor implement.

For instance, this guy here wrote his own C compiler for the C89 standard, and made it work for his own custom virtual CPU, for which he wrote several "emulators"(emulator;virtual machine it's all the same in this context) in C, Java and finally, Javascript. This actually gave me an idea to implement some VMs in Javascript as well, I mean you can run the thing in your browser.

Now, Virtual Machines like VirtualBox, VMWare and QEMU are different, they try to emulate a whole computer with the peripherals and also takes advantage of a CPU's special virtualization options for HW virtualization, they are indeed harder to write and understand and I myself couldn't even begin to comprehend VirtualBox's code.

But we aren't interested in those(or at least I am not) right now, we just want to emulate a CPU, or even create our own, the sky is the limit.

Back to the Roots.

Initially this blog was about compiling stuff for Windows, then I turned it into a RE blog, but today I plan to go back to the roots and post some stuff about compilation.

The goal was to cross-compile MySQL from Linux x86_64 to Android, ARM-v7a. But there are a few problems here.
1.) Google's NDK offers a very slimmed-down version of GCC and they provide their own standard C library called Bionic which is missing a ton of stuff, widechar support being one of them among many missing headers.
2.) The Crystax NDK does not add these missing headers, so the only option left was to compile my own GCC with GLIBC. I did that nearly 2 years ago with crosstool-ng and have successfully compiled php like that(but not with all features).
3.) Some targets built by the CMake system have to be run, this isn't possible when cross-compiling, so you need to first build MySQL for the host, and then gather the tools you need further increasing the complexity of the task of compiling MySQL for Android.
4.) Static linking of GLIBC, this is the most important part, as it needs to be set  in the CMAKE_C_FLAGS before you build(and it takes a while)

Needless to say I managed to compile it, with default features, but I forgot to statically link GLIBC, and mysql did not run.

I have managed to figure out the Crysis 3 PAK file decryption process

The reason I was absent from the blog was because I was working on decrypting the PAK files, I am more or less nearly done. Working on them taught me some things, the ZIP file format, working with Intel's PIN, working with libtomcrypt and slightly less about crypto.

Now, a little bit about the encrypted PAK files. They are essentially zip files, however their Central Directory is encrypted, while the End of central directory left intact in order to locate the CDR. The local file headers which also describe the files are broken, and some fields from ZIP file structure have been either reused or obfuscated on purpose, for instance the compression field in the Central Directory entry(one CDR means one structure describing a file) was set to either 13 or 14(which have specific meaning for the pak files), but they are not correct, the files are compressed with DEFLATE, this is method 8, not 13 or 14. The CDR also has a field, the relative offset to the Local File Header structure, this structure, or rather, after it, is where the compressed file resides, only that it too is encrypted, so it must be decrypted before decompressed.
The CDR is encrypted with a Blowfish cipher, the blowfish keys as well as the IVs(Initialization Vector) are encrypted with an RSA key available on the internet, but while I took advantage of this, I also found out where the key is stored, address 0x3B9ADFD4.

A member of the Xentax forum who had previously decrypted the files, has helped me with some snippets of code, however much of the decryption process I have figured out myself by digging into the ASM for days and then writing my (ugly) code. I just wanted to lay this out, I have taken what help he has offered, but this doesn't mean I did nothing.

Now, after writing the decryption code for the CDR, rebuilding the local file headers, appending the EOCD, I have a (mostly) working archive, all that is left to decrypt the compressed file.
And finished. I have officially written a decrypter for the Crysis 3 PAK files. Source code will be published once I clean it up.

Denuvo cracked?

According to this article http://www.dsogaming.com/news/report-denuvo-drm-system-has-been-cracked/, some part of Denuvo has been cracked.

Well done 3DM. However, there is still no official crack released, I expect fake torrents to be appearing pretending to be a crack from 3DM, they will likely not be, what they will be is malicious.

But while at it, I do want to mention that when it comes to 64-bit practical RE, the tools are just now being developed. It is only in IDA 6.6 that an x64 decompiler was added, but for us mortals, we can never buy this. Personally, I am a fan of Ollydbg, but I admit it has faults and limitations, one of them being no support for x64 RE, x64dbg is trying to fix that, but it will take a long time before it is truly useful for that.

More games to use the new Denuvo DRM

Dragon Age Inquisition.

Lords of the Fallen.

And as a reminder, no there is no crack yet for FIFA15, thus there will be no crack for either of these games, till Denuvo has been researched and defeated, if at all.

Also, I have no ETA on cracks, I am not affiliated with scene groups, I am just a guy that likes RE as a hobby, but I find this protection a pain in the ass already, even though I've never worked with it.

FIFA15 and the new DRM Denuvo

So at first I speculated it had SecuROM, just like FIFA14, but then we(when I say "we" I do mean the internet) find out it has a new DRM called Denuvo and this is why there is no crack yet, it's new and it will take time for it to be studied and bypassed, and maybe the rather low chance of there being no crack at all.
It took me 30 days just to run SecuROM under a debugger, so it's not unlikely the same thing to happen with a new DRM.

I've no idea what Denuvo employs, frankly I do not care, but if it gains traction and remains uncracked, things will get "interesting".

To say this in simple words, there is no crack yet, any crack you do find googling will likely turn out to be a virus.

Addendum: The upcoming GTA V game will also use this DRM. Seems like GTA V will not use Denuvo afterall, http://www.incgamers.com/2014/11/grand-theft-auto-v-will-not-use-denuvo-drm-says-company-co-owner