I love this approach. If you can detect a crack and block it, it will get worked around. Injecting easter eggs is much more subtle. There was another game that made an otherwise easy jump between two platforms impossible, so the players who had cracked the game went on forums and unwittingly revealed themselves by asking how to complete that level.
> "I've got a problem when it's time to use Batman's glide in the game," said user Cheshirec_The_Cat, whose appalling spelling we felt we needed to clean up. "When I hold [the button], like it says, to jump from one platform to another, Batman tries to open his wings again and again instead of gliding. So he falls down in the poison gas. Can somebody could tell me, what I should do there?"
We have implemented something similar.
The most obvious way to crack our software will trigger certain bug.
Whenever people report that bug I feel a little joy
> Whenever people report that bug I feel a little joy
I hope you are super duper 100% sure the bug can’t happen otherwise. I would hate to be your paying costumer and ignored because your drm system is buggy.
It's something along the lines of:
Pi+=2 in one place of the code.
And Pi += 1.1415 somewhere else. And both are guaranteed to run at the start of the program so that Pi=3.1415
However one of those lines is hidden in a part of the code that the most obvious crack is going to remove.
It's a good way to do it! The less obvious it is that there is a remaining check hidden, the better. Some games would become impossible to win, but only halfway through or worse. Sometimes with multiple layers hidden in different places that fail at different moment.
I cracked an expensive FPGA simulation program (for which I had the license, but the FlexLM scheme based on the MAC address of the adapter was just too annoying to get working on Linux).
What they would do is have a sort of unit test of their license verification function at runtime. There was a check hidden somewhere that I never found, and if the license verification was changed to always return true, the unit test would fail. The simulator would continue working within a single module, but as soon as you tried simulating a larger project, it would return undefined values between all the modules, rendering the simulation unusable for any real project =)
(I solved the unit test by having the license check return true only for my hardcoded serial number, which is definitely easier than hunting for the different places where a check might be hidden)
The hilarious thing about this is that this might have different behaviors across architectures or optimization levels if you do a bad floating point compare...
