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.

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.

Found OEP of Crysis 3.

After a few assumptions, mainly from the code of Crysis 2, I've finally arrived at Crysis 3's OEP, the real one. It's exactly like Crysis 2's.

At this point I guess I have to try to rebuild IAT.

EDIT: For anyone wondering, the address to OEP is 0x3863F50A(0x01663F50A without base image), so far it has been static.

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.

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.