3 ms·
For me, trivially crackable here refers to having someone who has read a basic text picking the license key out of the registry and going "hmm, that looks like
by philbarr 14y ago
For me, trivially crackable here refers to having someone who has read a basic text picking the license key out of the registry and going "hmm, that looks like a such-and-such key, I wonder what happens when I run it through this program here. Oh look it works, I think I'll just extend the date of the license to forever and tell all my friends."
If someone wants to go and disassemble the app and read all that machine code to find the bit to flip then there's not much I can do about that I think.
- jerf 14y agoStep 1: Define what attack you are trying to prevent. Are you just trying to keep honest people honest? Then just about anything will work. Are you trying to prevent hard-core hackers from cracking your work? A whole bunch of very good people have been working on that problem for a long time and failed. It is likely that the most dangerous licensing system you can produce is one that routinely false-positives a real user as a pirate. They will cease to be real users in the future. In general, pirates weren't going to be real users anyhow. (There are some exceptions, mostly in the games world, but in general it seems to be true.) If you can swing it, the most bang-for-the-buck you can get for protecting your work is to not actually ship all of it; provide some sort of critical element that lives on a server somewhere under your control. This can be tricky in some cases, because you really ought to be able to say with a straight face that there's some sort of value-add resulting from that. And that has availability and growth consequences as well. But it works, it's simple (relatively speaking), easy-to-understand, and extremely difficult to bypass. (Still technically not impossible, in some sense, but you've raised the bar beyond what all but the most dedicated attacker will bother with. Cracking is fun; reimplementing a backend service by examining only the data going in and out, well... I can't say that's not fun, but it's fun for a much more select group of people, most of whom are probably using those skills to make real money somewhere.)
- MichaelGG 14y ago"Read all that machine code" - I think you highly overestimate the difficulty of that. Take a simple checking function. Check the code, if it is wrong, show a message box saying "wrong code". Well, in that case, all you gotta do is set a breakpoint and go back. Programs like OllyDbg or IDA Pro make this kind of reverse engineering absolutely trivial, and something you can accomplish after "reading a basic text". Most likely if someone's going to "run a program", they can run a crack, too. If you can get away with a license file, then you can do RSA properly. Otherwise, end up with short RSA and hope no one really looks. It's almost certainly the case that you're far better off improving some other aspect of your application than investing any time trying to defend against pirates.
- philbarr 14y agoThanks for the pointers to OllyDbg and IDA Pro - I'd never heard of them. Embarassingly, it's been quite a few years since I tried actually hacking a program; especially since I'm posting on "Hacker News".
- MichaelGG 14y agoHere's a tutorial I wrote in 2004 which is still a decent start these days. If anything, it's easier these days, because IDA Pro has HexRays which can decompile code into C and makes it very easy to navigate a compiled module. http://www.atrevido.net/blog/PermaLink.aspx?guid=ec99e239-8917-48e3-bd4f-af866b730150 http://www.atrevido.net/blog/PermaLink.aspx?guid=ec99e239-89...