Near the end of the article, the author mentions that storing a digest of the binary is an effective means of protection. I've heard this before, but I've never understood how it works. There's two ways I can think of: One is it just builds the binary, runs it through SHA1 (or whatever), and stores that digest somewhere in the installation directory. But what's stopping attackers from just changing the digest? They h…
The first rule of software engineering is you never let the shareware stuff do it all. Test version should not save? Rip it out. Shouldn't print? Remove printing. Chop it out wholesale.
If you do an unlocking scheme, then make it subtle. Take a hint from Unix development: dont tell the user that the code worked or not. Just take the code or whatever. Tomorrow, then tell the user if it's a bad code.
And if it's in the blacklist, don't tell the user at all, and instead start introducing subtle errors everywhere. "What, you saved it yesterday and now it doesn't open? Whoops (snicker)." Or, misalign printing so anything looks good for a draft but not 'professional' use. Or you could go the obvious route of slapping a banner on it, but that is usually easily removable.
The idea here is to be subtly annoying up to the point of just doing nasty shit to the data worked with in your program. And of course, give error codes in a form of a md5sum that tells the company if you're a pirate or not.
But as I said earlier, put the time you would protect the program instead as improvement to make your program do its task better and easier. Crackers find these to be challenges. They just crack to keep their chops up.