Ask HN: We found a cracked version of our software on the web, now what?

We never took it too serious. You don't have to lose sleep over it but you also shouldn't completely ignore it. Just refactoring the copy protection ever few release cycles. Most of the cracks were using Windows APIs to access entrypoints to flip variables. Simply renaming, moving them, or adding removing properties was enough to throw them off for a while.

We figured out some of our customers were using cracked editions without paying for more seats. The support calls were interesting because we told them the bug was fixed but they were super reluctant to update. We'd pass the message off to the accounts managers and let them wrangle with it. This was more prevalent in developing countries where pirating for business use wasn't considered a big deal.

I tried to bring up a low cost edition at our company meeting but it was shot down. The numbers wouldn't work. Business users get training provided; casual users would swamp our helpdesk in lieu of actual training.

The plan should always be to get those pirated users into actual users, unless the country they're in is embargoed, funny story. From reading the piracy forum thread I found many were using our software for job training in hopes of gaining foothold in the field. Similar to how Photoshop was everywhere in the early web design days.

Turns out, the pirated copy had a special feature where the player would feel immense economic pressure from piracy, so a bunch of players asked how to win against this, it was pretty hard and really fun for people who knew what was going on.

Point is, you could hide an Easter Egg for pirated versions (can you detect the lack of signatures?)

1) Typically obfuscation is not used, but even when it is used, it's easy to find what you're looking for. They're going to be using JCE or BouncyCastle for encryption. Look for the relevant classes.

2) The key is nearly always hard coded as a string constant that is not unique to the installation or customer. Super easy, and often discoverable with just the 'strings' command line utility. I would find your concats of chars and other silly schemes if you did that, but it would slow me down a bit.

3) IV is never used correctly with AES. It's always a static value, usually 0.

4) License keys are usually encrypted with the same scheme, but their format of entitlements takes some extra effort to discover. I occasionally must reverse engineer this as well to understand the limitations. For example, stupid licenses lock to IP address or a BIOS uuid, complicating a disaster recovery plan.

My favorite encounter was a class file, in the spirit of OOP, dedicated to licenses (ie License.class). It was not obfuscated in any way and had both the load() and save() methods included. All one must do is write your own Java class (or use Groovy interpreter), include the vendor jar in your classpath, set your license entitles and call save().

A real WTF is that SAP will encrypt the contents of _your_ database with simple substitution ciphers. If you want to query it for insight, you're going to need their simple character shifting/replacing scheme.

https://www.wired.com/story/empress-drm-cracking-denuvo-vide... https://www.pcgamer.com/denuvo-cracks-2019/