Reverse engineering a binary code modification of an Unity3D game

This happened a while ago, but found the time to write about this only now(no surprises there).

* * *

So, during a casual conversation it came up that a single player FPS game I used to play on Android also had an official PC version. This made me quite happy, though my joy was crushed soon after: 60 degree field of view is the recipe for instant headaches. disorientation and general discomfort.

But I won’t let that stop me! No way. Although I’m quite a noob, I’ve still had some success reverse engineering various games. The game uses Unity3d web player, so I’ll just unpack that and find some strings referencing fov, and then take a look at the code and modify that pesky 60 to a more manageable number. Not that easy. And yeah, it’s not C, but C#. That’s a whole different kind of beast with it’s execution model.

But hey, there actually seems to be a CheatEngine table on Google with fov mod! Piecing it together I was finally able to modify the fov with it. Great, I just downloaded some stuff and pressed a button. l33t hax.

* * *

So, how does that thing work? Well, I also found out that the game’s code was not obsfucated. Running the game dll through a decompiler produced lovely human readable code. And look! A camera class! And it has that pesky 60 fov hardcoded in to several places! Maybe the CE script searches for it and replaces the entries? Converting 60.0f to hex and doing some manual comparisons verified that to be the likely scenario.

Then some more reading about C# IL code etc. and comparing the bytes in the script with the IL code of the relevant camera methods. Perfect match! Indeed the CE script was searching for the camera code and replacing it with one where the hardcoded fov value was different. This also explains why the script didn’t work if a level was already loaded. The IL code was already JIT compiled to another form.

* * *

This discovery means that I can look for arbitrary code in the game, parse the IL dump with my Python script and then make the relevant changes. Then use that same CE script to replace those parts of the game’s code.

Using this new ability, I also found that pesky code that was responsible for aim assist. A few NOPs and welcome full manual aiming! Though, some time later the game received an update, breaking the aim assist disabling. I’d like to revisit that section of the code some day and see what needs to be done to fix it.

Some thoughts about the new desktop – part II

So, a new desktop and life is wonderful? Sure, maybe for a month. Then the random BSODs started to happen. Then some more BSODs, at worst daily. Long hours of analyzing minidumps, tracking possibly bad drivers, upgrading and disabling them. Reading message boards. Adjusting power settings. Adjusting voltages. Running memtests. Nothing seems to be helping and nothing helpful emerges. I’m beginning to suspect the BSODs have something to do with sleep or hibernate, but nothing conclusive as the BSODs take too long a time to get certainty about the causality. Might just as well try upgrading to Windows 8.1 now that all hope is lost.

Of course setting up a fresh OS install brings daily restarts, so the BSODs seem to be gone for a moment. But then, again, they start happening. Checking drivers once again, nothing. Well, it was as if removing Gigabyte's chipset drivers somewhat reduced the BDOSs, but they were not gone completely. Then, with heavy heart, I disabled the sleep-mode just to test it. No more BSODs.

* * *

Now, according to dump files, it’s been almost four months without a single BSODs. A hardware problem with sleep-mode RAM voltage regulation? Software issue? No idea…