> 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.

Yes. 100% super duper sure.

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.

Okay. That sounds reasonable. Well thought out system.

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...

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)