CODEWITHSUNDEEP
c#unity-game-engine
aziz hajbaoui
aziz hajbaoui

Reputation: 37

Determine if game has been de-compiled/altered

I'm looking for Unity function to determine if my game has been de-compiled/ recompiled or modified in any way.

Upvotes: 2

Views: 2015

Answers (2)

Programmer
Programmer

Reputation: 125245

Yes, there is a Unity function for this but it can still be circumvented.

This can be done with Application.genuine which returns false when the application is altered in any way after it was built.

if (Application.genuineCheckAvailable)
{
    if (Application.genuine)
    {
        Debug.Log("Not tempered");
    }
}

The problem is that if the person is smart enough to de-compile, modify and compile the game, he/she can also remove the check above so the check above becomes useless. Any type of program genuinity or authenticity check can be removed as long as it is running on the player's machine.

EDIT

You can make it harder to be circumvented by doing the following:

1.Go to File --> Build Settings... then select your platform.

2.Click on Player Settings --> Other Settings and then change the Scripting Backend from Mono to IL2CPP(C++).

This will make it harder to circumvent that but it is still possible to be circumvented.

Upvotes: 4

CShark
CShark

Reputation: 1563

TL;DR: Thats frankly not possible.

You can never determine whether your program was decompiled, because there exists no measure to determine whether that happened. And every executable can be disassembled into at least assembler even if you scramble and screw up your data. You can make it hard to understand your source code though using obfuscating software. The ultimate obfuscator would be the M/o/Vuscator, which changes all assembler commands into mov instructions, which make it a pain in the butt to understand anything. But it also is slow as heck and probably not what you want (btw. this works because the mov-instruction is touring-complete in the x86 Instruction set. There is a great talk about it here). When you follow this trend further down the rabbit hole you can also use the exact same assembler code (around 10-20ish instructions) to create all programms possible which will make it impossible to get to your source code by simply disassembling your code.

Staying in the realm of the possible though: No, you are not able to prevent people from disassembling or decompiling your code. But you can make it harder (not impossible) to understand.

Detecting a change in the executable is on the possible side, though. Altough probably not feasible for you.

The main problem beeing that any code you build into the app to detect changes can be patched away. So you'll need to prevent that. But there is no practicall way of preventing that...

If you try to detect changes in your app by using a signature of the original and compare that to the actual signature for example, you can just exclude that check in the recompiled version. You can try to verify the signature against a server, but that can still be circumvented by removing the server check. You can force a server check for multiplayer games, but then we'll just use a fake signature. If you then want to calculate the signature on your server to prevent tampering, we'll just give you the original file and run the recompiled one.

There is one way (altough not feasible as mentioned above) to actually absolutely protect parts of your code against decompiling. The mechanism is called "BlurryBox" and was developed at KIT in germany. As I can't seem to find a proper document as a reference, here is what it does to archieve this.

The mechanism uses a stick with an encrypted storage and a microcontroller to do encryption. You put the parts of your code you want to protect (something that is called regularly, is necessary but not that time critical) into the encrypted storage. As it is impossible to retrieve the key [citation needed], you cannot access the code. The microcontroller then takes commands from your programm to call one of the encrypted functions in the storage with given parameters and to return the result. Because it is not possible to read the code you need to analyze its behaviour. Here comes the "Blurry" part of the box. Each function you store needs to have a small and well defined set of allowed parameters. Every other set of parameters leads into a trap that kills your device. As the attacker has no specs as to what the valid parameters are, this method gives you profable security against tampering with the code (as they state). There might be some mistakes on how this exactly works though as I'm writing this down from my memory.

You could try mimicking that behaviour with a server you control (code on the server and IP bans for trying to understand the code)

Upvotes: 0

Related Questions