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

Sorry, could not think of a title for this post. You probably noticed it's been over a month since my last post, truth be told I took a break from RE to focus on some other things, and now doing very light reverse engineering.

My current goal is, and you've probably noticed I switch it quite often, is to decrypt the Crysis 3 PAK files, which are just Twofish encrypted ZIP files. Thankfully, I was provided with the RSA (private?)key and some code snippets to get me started, but by themselves they are not helpful, so I am stepping in and out of the crysis 3 code which decrypts and caches the pak files.

My knowledge of cryptography is comparable to my knowledge of Chinese and C++, and even then I know C++ a lot better than crypto, and trust me, I don't know that much about C++ and literally nothing about Chinese.

Alice Madness Returns, disappointed...

Well, I am shocked, in all my time I have never seen such a sloppy job.

I downloaded the RELOADED release of the game, expecting the game to work, waited for a while for the game to install, only to be greeted by the message "Failed to find default engine .ini file" upon launching the game. I said to myself, its ok , it happens. I tried desperately to fix the issue for half an hour, to no avail.

Then I deemed the release of RELOADED just plain bad, but the madness returns!!
I downloaded the skidrow release, surprise surprise, all missing files were there, I launch the game, greeted by the skidrow logo, then...a crash in kernelbase.dll.

But the madness did not end there, I then started to search for a working crack, I tried a RELOADED crackfix, so far so good, until I actually try to launch it, this time the game did not crash, instead I am greeted with a box saying "The game has been modified or tampered with".
Ridiculous, simply madness, but hey it didn't end there, I downloaded the Theta crackfix, I launch it, bam, crash in kernelbase.DLL.

After wasting over an hour trying to make the game run, I finally gave up.
I have never ever seen such a sloppy attempt to crack a game. It isn't even a crack, but "crac", as its incomplete.

I have not posted in a few days. The reason is because I was preoccupied by SecuROM, for two days straight since my last post I had been working on my dumped exe, figuring out why it crashed beyond a certain point. It took me 2 days, almost sleepless and not eating at all to figure out the problem.

It was difficult as my trace was inconclusive, it showed the main thread simply continuing execution to some invalid address. After working on it for days, I found out that my trace was being b0rked by OllyExt, a plugin for Ollydbg 2.01, so I disabled that and found my problem.

The offending code was a huge jump table, I guess at some point execution jumped to that location, but the jump table itself had unfilled addresses to pointers to the FMOD Sound System.

From then on because of my poor pointer arithmetic skills and almost no knowledge of the PE format, it was a whole day before I wrote a small tool to identify the pointers in the original exe to those in the FMOD Sound system DLL(s). This was further delayed by some unknown bug where the index of an exported function did not match the index of the name array, if it was a C unmangled exported function. All C++ mangled/decorated functions's indexes into the name array were correct.

Then I generated my own table of GetProcAddress-es to include in my stub. After that execution of the exe continued, till I stumbled on another problematic area, of some address not being correct, one that is filled by the SecuROM VM before OEP is reached.

So thats going to take some more days.

RtlUserThreadStart modification.

And back to SecuROM folks. Two days ago I stumbled on some stuff by accident. Turns out, SecuROM modifies the IAT of some modules(predetermined I believe) during runtime, and replaces pointers to various kernel routines such as CreateThread,LoadLibraryExA,LoadlibraryExW,LoadLibraryW to its own obfuscated routines, this in several modules.
I wrote my own tool to repatch back to the old routines. It worked fine after I patched back the old pointers, with the exception of RtlUserThreadStart, securom gets the address of this routine(via GetProcAddress, not in IAT of any module), and modifies this jump at RtlUserThreadStart+0x8, to point to a trampoline jump in a codecave in ntdll.dll, and then another jump back into securom code. If this code is not executed, securom cannot continue, it just waits.

SecuROM v8.10 might pack more than I thought.

Once you bypass the anti-debug APIs, you realise that bypassing those is the easy part, now I feel a bit ashamed that it took me 30 days just to bypass them. Oh well.

I've identified a few threads that are started before OEP which are essential, I've only just started to analyse them, they are obfuscated so reading the assembly will be difficult.

A small sidenote unrelated to all of this. There is a method on the internet for finding out the version of securom, searching for the string 'AddD' will show a version number next to it, for Securom v8, this method no longer works, there is a version displayed, but it's not correct.

Everybody trying to discourage me.

I've noticed that lately a lot of people are trying to discourage me from trying to crack SecuROM. One of the securom developers himself told me to give up. And a bunch of other people.

It's definitely a confidence breaker, but I will get over it. Meanwhile, give up on trying to make me give up ;)

Changing times.

Initially this blog was more about compiling various stuff under Windows that would give you a headache, hence the compile-tips in the name(and my two first blog posts which highlight this), but as time passed I gained a passion for reverse engineering, and instead of making a new blog, I decided to reuse this one.

I do plan to write about compilation and all that, but for the time being my focus is on reverse engineering.

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.

CarpVM, a Virtual Machine in C

Finally, somebody went and wrote it. Link to GitHub. This VM can be used as an obfuscation technique. I was building my own, but things got sidetracked. But this one is on another level.

Some insight about Process Virtual Machines.

So, I understood more about Process VMs, simply last night, I was all of a sudden aware out of the blue of how it works, roughly.

I also found a sample VM implementation, the one which is supposedly used in packers/protectors, albeit probably not as advanced, but still worth the read. Here's the link http://syprog.blogspot.com/2011/12/simple-virtual-machine.html

Anyway, I guess it's sort of a misconception that a VM executes anything, it does not, the VM instructions are simply "interpreted" i.e if  the instruction is MOV REG_DEST, REG_SRC, you are the one that must handle this operation.

I might write my own VM implementation, just to learn more.

IDA is too glorified for x86/x64 RE.

I only mentioned x86 and x64, because while Ollydbg is a better debugger for those(and it's free), it cannot debug other platforms, such as ARM. It also lacks a decompiler.

But anyway, I see people mentioning IDA like it's the go-to tool for RE, it's not. I've had more success in RE-ing SecuROM than IDA ever has let me.

Simply, when it comes to x86/x64 it's only good for static analysis of binaries that are not protected. Once we go into packing,antidebugging and obfuscation, it's useless not as good as Olly.

P.S
Ollydbg x64 is in development.

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.

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.

Process Virtual Machines.

Understanding SecuROM takes time, but even with time I still cannot understand the VM implementation it utilizes, no idea when it enters the vm, when it exits, or how to follow what it does. At this point I am unsure how to analyze SecuROM further.

If anybody has any tips about Process Virtual Machines, something that will be useful in unpacking this, comments are welcome.

And after asking a person, he told me the SecuROM version used in Crysis 3 is 8.10.008.

SecuROM is a tough beast.

I've been battling the protection of Crysis 3 for 3 days straight, no progress whatsoever. I have olly loaded up with many different anti anti-debug plugins and none of them seem to work against SecuROM.

[8/6/2014] A small edit to clarify if it wasn't clear, I removed the EADRM protection, it was easy as pie, but at the OEP where I would've expected Crysis 3's code to start I ended up with the SecuROM code.

RELOADED/SKiDROW, if you are reading this(and it's very likely that you aren't). Am I to understand that you never managed to beat SecuROM in Crysis 3? Because SecuROM is still there in your cracks and you only exploit the license manager to make the game work.
Sorry, my ego got the best of me.

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.

Reverse Engineering. Unpacking Crysis 2! The actual stuff.

Before I continue, I want to stress that I legally own both Crysis 2, and Crysis 3 on Origin.

Now, I want to first say that my experience with RE is very limited, I don't really know ASM as well I should, nor do I know anything about the PE(Portable Executable) format. Or anti-debugging techniques and how to bypass them.

The tools used by me:

• Ollydbg 1.10 with the following plugins: HideOD,StrongOD,phant0m,HideDebugger. Can't tell you which combo of options(anti anti-debug options) work, just try them all, until the executable does not crash, gives exceptions, exits etc.
• Ollydbg 2.01 with OllydumpEX for 2.x, no other plugins.
• Hex Editor

Much of our work will be done using Ollydbg 2.01, since Ollydbg 1.10 doesn't seem to like some patches that will be required. And much of our work will be done on the file called awc.dll, located in the Core folder, it's part of EADRM. It's responsible for unpacking and launching Crysis 2.

A few important abbreviations to remember before we begin:

• OEP - Original Entry Point.
• IAT - Import Address Table.
• EP - Entry Point.
• EIP - Extended Instruction Pointer.
• RVA - Relative Virtual Address.
• VA - Virtual Address.
• JMP - Jump Instruction.

When it comes to packing/unpacking, OEP refers to the entry point the way it was BEFORE the executable was packed. Most packers though, also destroy the Import Table and the executable does not know where to find say, the function Sleep, or say CreateProcess. So the unpacker stub basically does a few calls to LoadLibrary and GetProcAddress and rebuilds it, this doesn't mean it's as simple as using Import Reconstructor to fix things. In our case, it might require manual work to fix this.

I highly recommend reading this short article http://dreamofareverseengineer.blogspot.com/2011/10/unpacking-custom-packers.html

[Deleted]

[18/9/2014]
The article was "useless", please read this instead, Regarding EADRM in general.

Reverse Engineering. Unpacking Crysis 2!

It has been a long time since I wrote anything in the blog, thought it might be time to share some experience.

So, what is so special about Crysis 2? Isn't it a really old 2011 game? It's special in my heart, it all started in February of 2011, Crytek had released the DEMO Multiplayer of Crysis 2 and after having tried it for the first time, I fell in love immediately with the multiplayer component. Here came March 21st and March 22nd, the game came out, but I couldn't buy it then, so I patiently waited for a cracked version to appear, astonishingly, it took 2-3 days for somebody to release a crack, meanwhile there was a non-cracked version available.

So, what did I do? Well, I tried to crack it myself, of course! Did I succeed? Absolutely not! I didn't know a thing about RE(Reverse Engineering) or ASM(Assembly), but I still tried for a while.

I played the Singleplayer, after a cracked version was released, I loved how spooky and eerie the story felt, because it was saying the suit was alive and could think for itself. The story was all about the suit. Graphics were as always, pretty good. But the AI was dumb, really dumb.

After I finished the singleplayer, I kept wondering, how do I play the multiplayer? I couldn't. After a while(a month or two?), something amazing was released, something I didn't believe was even possible. A multiplayer crack! However strange as it may seem, it only worked in limited hours, between 16-21PM UTC. I never figured out how it worked.

Did I play? Yes, oh my god yes, the multiplayer was really competitive, it took skill to aim. After a while, I found a website that was selling Crysis 2 serial keys for just $16 dollars, even as low as $11. Should have noticed the signs. The key was legit, it worked fine up to the moment GameSpy shutdown in 2014 May. Yes, from the $11 dollar price of a game not even 2 months old, the sign was obvious, it was dying and sure enough, after about 3 months, Crytek stopped patching it, abruptly, and there was ZERO communication from them TILL the Crysis 3 announcement in the summer of 2012. I must stress the word ZERO.
The game was left unpatched, with various GAMEBREAKING bugs, such as the infamous Scar+Laser bug, which made you strafe faster and was abused a lot. And cheaters, that could bypass the votekick system easily, very easily.
Hint: Same thing happened to Crysis 3.

So, there you have it. Much of 2011 and 2012 was Bitcoin and Crysis 2, mine and play and play and mine. Those were the days!

Actual unpacking bits in next article.

Location of the ATI ATOMBIOS!

After having a chat with some guys developing the open source radeon driver on freenode, and with the reverse engineering of GPU-Z I found where the ATI ATOMBIOS is located.

Pretty simple actually, you take the BAR2(Base Address Register #2) and XOR it with 0x80000 afterwards you AND the result with 0xFFFE0000.

In practical terms

atombiosaddress = (BAR2 ^ 0x80000) & 0xFFFE0000.

Also, the VBIOS of the primary card can also be located at physical address 0xc0000 like radentool has specified.

EDIT: I did a binary comparison of my dump of my card vs the one from GPU-Z and mine seems to contain different data at certain locations. So not quite there yet.
Something interesting I discovered is that the location of the ATOMBIOS on the primary card is not always available at the address using the formula above, the address is valid, however the GPU-Z driver does something to make the card map the BIOS to that location, after it's done the address is valid, just doesn't contain anything. It works on non-primary cards though.