Comment by jmillikin | Hacker News Reader

Comment by jmillikin | Hacker News Reader

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 have access to the application, so they can know exactly how to generate the digest; all they have to do is run the bundled digest function in gdb, copy the output, and then search for it in the installation. Even if the author tried some sort of obfustication (xor, deflate, reverse, etc), such attempts would show up in the binary and could be trivially duplicated.

A second is that the digest is somehow pre-computed for a binary before it's built, then included in the binary itself. But I don't see how this is possible with secure digests. And if the method is simple enough that it's worth using for typical iOS applications, what prevents an attacker from pre-computing a digest for the cracked version?

They have access to the application, so they can know exactly how to generate the digest

Traditionally, the way of doing this is by making that 'can know' step very difficult. Techniques to accomplish that include refusing to run under a debugger, multiple layers of protection, self-modifying code, loading the digest code from disk block checksums, from between tracks on a floppy disk or from blocks marked bad (back in the day when there weren't that many layers between application code and hardware), etc.

A lock does not have to be unbreakable; it just has to make breaking it costly enough to discourage even attempting breaking it.

With hackers, though, that does not quite work. They see even attempting to break the lock as enough of a reward in itself.

When Mac OS X updates the signature on a binary (for instance, when you configure a firewall rule for a previously unsigned binary), the actual Mach-O file will be changed -- and your digest will be incorrect.

Skype (which has notoriously complex obfuscation) had this problem for a short time when Mac OS X 10.5 was released:

http://securosis.com/blog/leopard-firewall-code-signing-brea...

You can work around this by validating only the important subset of the Mach-O contents, but it's probably not worth it. Cracked applications (rather than, say, reverse engineered serial number generators) are an annoying thing to use -- you'll have to refrain from applying updates until you get a new crack, trust the person distributing the crack, etc.

It's not something I (or, afaik, most other small Mac developers) really worry about.

If you have access to enough computing power maybe you can store a digest of the binary while including the digest in that same binary. That would make it a LOT harder to just change, but would also slow down things like security patches.

If you have enough computing power to do it, so do the crackers (but usually even moreso)

I was under the impression that hashes were there to protect against download/disk errors, or generic viruses/trojans etc.

No. Effective means of protection are when you "roach motel" the data.

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.

There was a rumour going around the EE department that if you tried to crack Eagle or use a keygen'ed license, the software would slowly start corrupting the circuits you were working on. After a month it would tell you that you had pirated the software, but not before you'd created a fair number of non-working PCBs. Devious!

I'm not sure if this is true or not, but it kept us all on the straight and narrow. :)

From what I remember, the copy protection on Eagle was conceptually simple and seemingly effective. Basically it put the license ID into all saved files. Updates to the software would include an updated blacklist which prevented loading of files from old pirated versions. Crackers wouldn't bother with fixing the load functionality as everything would work fine for the current iteration.

There were of course ways to work around it (load then save with the same version under the free license, or export the entire design as text using a ULP and then import in the new version). But on the whole, it struck me as frustrating the process just enough to encourage users who would possibly pay, to pay. (I wonder if Cadsoft made even more from unlocking design files. "You are having trouble opening that design because your fly-by-night consultant used a pirated version of Eagle. We'll happily unlock it for the cost of a deluxe license.")

And then all the people who pirated your app deride it as "buggy" and you lose your paying customers, because who would buy such a buggy piece of crap?

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

"Gee, I'm sure glad I decided to pirate [program], it's buggy as hell. Better warn my friends..."

Spyro: Year of the Dragon used a similar technique to great avail. Don't be so quick to dismiss this method of deterring crackers. It just needs to be done right. There are arguments going both ways on this issue so it's simply not black and white. Perhaps it works better for games than applications, but again, you'll find arguments going both ways for games and apps alike.

Reply on news.ycombinator.com