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.