Local License Key Verification
matradomski.com
matradomski.com
Back in the 90s our product--and many of our competitors in EDA--integrated with FlexLM (then Globetrotter, then Macrovision, then I lost track). It was clever and flexible, especially when talking about seats and site licenses and combining different vendors onto one license server, all before Internet was serious.
In reality, it was painful for users and they lost so much time fighting it: someone forgot to "check in" a license before using it, or the site license server was down, or you had the wrong feature line, or dozens of other failure modes.
Of course, the obvious issue with the public key approach listed as being "best" in the article is that all it takes for an attacker to overcome the scheme is to replace your private keys with theirs -- or to patch a JMP for every do_license_check() call in the binary. It's fundamentally an approach that is always hackable.
That might be true in theory, but is non-trivial in practice. The code responsible for license verification is often obfuscated and tied to critical functionality, so you can't do a simple find and replace.
I never enjoy seeing FlexLM, but I absolutely dread seeing the homebrew license servers from companies that choose not to use it.
The application does the same thing, asks for their name and license key, and then confirms that the generated key matches what they entered.
It's trivial to crack, but I just decided that you can never stop the really determined crackers, and a trivial scheme would be enough to incentivize honest users to pay up. Displaying the user's name prominently on the splash screen acts as a guilt-inducer for those sharing keys.
I was hired as computer assembly tech at a local computer store when young. There was a customer that was frequently delinquent. The boss asked me to write a program to encrypt the hard drive if the customer hadn't paid. This customer had a business so I was very nervous about my lack of confidence in being certain their data was not lost. To compromise, only filenames and extensions were changed. IIRC, the bill was receive a payment weekly. Once the money was received, a code was given to the customer. This code would update a file on their system. If, after two weeks, no payment was received, the code would recurse through the directories and rename data files with a simple XOR. This would allow files to be recovered manually if needed. I'm not certain, but I think this was done in dbase 2000. It was the only compiler we had access to at the time.
I just don't care at all about someone's "lost potential revenue". I consider it to be the same as skipping commercials with watching TV, or adblocking the web today.
> I just don't care at all
I stand by what I said, I guess.
An argument could be made that inflicting drm on everyone who is not a theif, and all posterity long after any legal or moral copyright has expired yet the thing is still encrypted or broken, is hopelessly immoral.
That comment did not prove you right.
This is currently working well for Netflix.
This is imo an absolute genius insight, whoever came up with it first. It’s psychologically meaningful, not just for guilt, but the feeling of ownership.
In many ways, I miss these days of software being complete and local. Today, there are few interactions where I get that nice feeling, and for good reason – whenever the feudal lords decide my account is no bueno, the fun stops.
You can use the product without the key indefinitely. But every 10 times you save, it shows a prompt for buying the software.
Not even intrusive, you can discard it easily, and be productive for months.
But after months of reading that you don't pay, the guilt sets in. After all, you have been enjoying the product, since you have been using it for months.
Examples: https://www.youredm.com/2015/02/24/avicii-martin-garrix-othe...
Without signed executables, and if someone is willing to spend the time to look for the exact spots in a disassembler in non-verified executables, they can either negate the condition or skip over the license check. This assumes it only happens in 1 location. Every upgrade of that particular file would likely need to be re-patched each time.
The least work semi-automated way to find it is through tracing a initial failure run and then binary search inverting logic of branch instructions.
That can only happen if Treacherous Computing wins. If you actually have control over the things you own, you'd be able to tell your device to lie about the first stage's signature.
It has already happened.
Until they make it so we need corporation or government signatures to run software on "our" machines. Until they finally destroy our computing freedom.
This has been the case for over a decade on smartphones, and corporations like Microsoft are currently hard at work bringing it to traditional computers.
Only now is hardware remote attestation putting an end to all that.
> Only now is hardware remote attestation putting an end to all that.
And then hackers will graduate to side-channel attacks... it's a game of cat and mouse. The best bet, IMHO, is to make the cost of cracking exceed the value of what's being cracked.
Hardware remote attestation means your local physical device is as accessible as a distant server. Dumping RAM does not work, tapping the bus does not work, writing your own firmware does not work. It is exactly like an ISP performing a machine-in-the-middle attack on a TLS connection; impossible unless without some way of obtaining the certificate private key.
Probably, but I'm not the type who likes to rule anything out completely.
IMO best way to implement license check is: using asymmetric crypto (so it's impossible to write keygen) and online activation (so it's impossible to share key).
I believe from my experiences downloading CLASS and MYTH game rips from sketchy IRC channels on DALnet that even this method can be subverted by simply patching out the online activation check.
The only feasible way to combat this that I'm aware of is to have some required code/data live on the company's server and thus force always-online to use the software.
It’s not perfect but it does make a significant difference.
The fellow working on the project with me had a lot of specialized domain experience in such things, and told me the actual cracking teams would never put malware in their own cracks, because it would ruin their reputation in the scene.
I'm sure some cracks have had malware added after release by other people, of course, but I wonder how much of it was fearmongering by software companies.
The higher risk thing tends to be downloading cracks from torrents or usenet where there's 3rd parties between you and a scene group.
The problem is, the scene usually isn't about making piracy mainstream. Many release groups only released their cracks within closed circles to show off that they managed to crack a game. The cracks that made it out to the web often came through leaks, hosted on a shady site or distributed through torrents. For an outsider, these cracked files weren't all that trustworthy.
That, together with antivirus software being made completely unreliable because of false positives, made it very hard to trust the .exes/.dlls that I used. Piracy is still a major infection vector today, and I imagine it will always be because of all the fake cracks on SEO hacked websites and shady operations necessary for the original crackers to distribute a crack without copyright lawyers sending you very scary letters.
Most local software cracking doesn't involve fixing the license key check or the crypto code at all. You just remove the conditional jump that exits the program if the check fails.
Otherwise I found this a nice writeup.
> https://sigpipe.macromates.com/2004/using-openssl-for-licens...