Anti-Piracy - Does anything work?

[kurt6string]

I'd like to release an audio application in April and wondered if any of you had any experience with piracy, and defending against it. I'm releasing for windows first, followed later by mac. Windows solutions are what I'm interested in at the moment.

What are the rest of you doing (or not doing) to protect your commercial applications?

Your thoughts?
Thanks, Kurt

[jules]

My advice would be to spend just enough time to stop people casually giving their friends a copy, but not to bother wasting too much time trying to stop the really determined hackers, because you won't succeed!

When I did tracktion, I got a bit carried away in an arms-race of trying to out-smart the little sods each time they cracked it.. That was actually quite fun, but ultimately pointless, as they seemed to be super-intelligent psychic hackers with unlimited patience, and they managed to dodge every cunning anti-piracy trick I threw at them.

So the best thing to do is to assume it'll be hacked, and invest your time in adding new features and releasing new versions rather than trying to stop the pirates. And if possible, make it dull and time-consuming for them to crack each new release, in the hope that they'll get bored and go looking for a challenge elsewhere!

[gekkie100]

We had a proper hacker over this week to explain how he hacked our software and what you could about this.
So i strongly suggest to find a hacker and ask him/her over for coffee. It's very interesting to see how it works.
You can never beat them but to make it a little bit harder is not a bad thing. And with some simple modifications which should only takes a day or two you can improve it quite a lot.

Some info.
Tools he used:
GDB - windows debugger
OTX - OSX dissasembler
Hex Fiend - OSX hex editor

What he did is use the OTX dissambler tool to open the excutable and have a closer look at the machine code. He then tries to spots strings that give away some info about the function that actually check the registration key for instance.
When he finds the address of the function that checks the registration he then opens Hex Fiend (and opens the app with it) and starts looking for the function and magically replaces a part to make sure the function always returns true.

The trick is to make sure it's not obvious for hackers where to start looking to find what they are after.
You'll never outsmart them, they see it as a challenge when software proves hard to crack. So they will crack it in the end and maybe even sooner if it seems harder (which sounds a bit like a contradiction).

You can use tools so encrypt your executable to make it harder to use dissambler and hex tools.
Encrypt tools:
Aspack - windows
UPX - windows
Use Code Signing - osx

He also pointed out some other tricks:
- MD5 check on executable file - check after n=random minutes or so after startup, not directly because that is easy to spot
- make you isregister function do something else important (except for checking the serial) that is vital for your application to work, if the function is somehow bypassed the app becomes useless.
- change function names of regstration check so they don't seem too obvious
- encrypt registering related strings in app so they don't show up and make it too obvious where to start looking.
- pass in a variable in the register function and make sure it's filled with the correct value, so don't only check the return value
- make sure you hide the symbols of your app, so check the compiler settings and make sure it hides the symbols in release mode.

also check this interesting thread we started when we had the same questions as you:
viewtopic.php?f=2&t=1245&hilit=serial

[Wolfen]

Software using iLok2 protection has still not been cracked nowadays, but it is sometimes a pain to implement.

I think it's good to ask to uncracked software developers too...

[TheVinn]

From http://www.reaper.fm/purchase.php

We believe that technological enforcement of copy protection is not in the best interest of our customers.

We don't spend money and effort on marketing, complicated piracy protection, or other things that do not directly improve REAPER and the user experience.

[atom]

Jules could you (in a moment of spare time) tell us about your struggle with those hackers that cracked Traktion, i mean what were your methods and how did they crack them. Just in general it sound interesting.

[jules]

Jules could you (in a moment of spare time) tell us about your struggle with those hackers that cracked Traktion, i mean what were your methods and how did they crack them. Just in general it sound interesting.

It's a long time ago, I've forgotten most of the details!

But I do remember that I kept adding new and different ways to make it check the serial number, and did tricks like writing the result into the settings file, then reloading it later so they couldn't follow the memory location that held the result of the test. I also wrote a bunch of code that passed around strings of nonsense to represent values, rather than using primitive types, to make it harder to follow the program logic in the disassembly.

I added all sorts of traps using fake code-paths with fake serial number results.. I scattered the code with lots of differently timed serial number checkers, some of which would only get called once per month, hoping that the hackers would miss at least some of these, but no, they figured it all out!

[TheVinn]

What are the rest of you doing (or not doing) to protect your commercial applications?

My favorite solution is not to implement any copy protection measures. Give the product away for free, and rely on the honor system for users to register. For example "This product is free for non commercial use, but if you make money with it by doing performing live or selling recordings, then we ask that you pay for a license."

Free products have a larger user base since advertising ends up costing nothing. Total revenue for a free product is higher even though the percentage of registered users is less - you get a smaller piece of a much larger pie.

[X-Ryl669]

You can always use off-loaded registration like M$ does.
Basically, your code need to run some code that's directly downloaded from a server, and, in order to get such dynamic code, the software has to prove its genuine state to the server.
The checking code is now server based, and almost impossible to crack by hacker.
Obviously, the code sent by the server must be signed per-customer (and should do SHA256 checking of the software files / memory), so even if saved back by hacker while it reach his computer, it would be useless on a genuine copy.
This gives an additional advantage of knowing the size of your user base.
The *big* disavantage is that your server must be up 100% of the time (or you need to provide fallback in your software with missing functionnalities).

I even know people doing per-customer version of the software (that was generated while downloading the binary), so any crack would be useless.
I agree with Vincent however that if you intend to do something like this, you either have multi-month time to waste (and you should use that to improve your software) or already a very specific niche market and a glowing 6-digit bank account.

[jfitzpat]

No...

I've been in this arms race a few different times and, as Jules notes, it can be fun, but the long range outcome is pretty much a foregone conclussion. In the very early days of MIDI, piracy was clobbering Hybrid Arts on their first few products. I did a couple of instrument editors for them, and they implemented Paul Rother's protection schemes (and Paul was/is no dummy), and I'd find bootleg copies at stores within weeks. 3 decades later, pirate/hacking culture is way more sophisticated.

When Stephen Daystrom set out to write Hybrid Arts new flagship software MIDI sequencer for Atari ST, he asked me to do 'some sort of hardware key' (I was the system programmer at a vector graphics company across the street). After some back and forth discussion, I did a super low cost SMPTE interface, which was then, expensive and rare. We also worked out an interesting scheme for sub frame locking. Watching them get the prototype into production hardware was painful, but the combination worked well for quite a few years. The HW was providing a granularity of clock/IRQ control on a handshaking line that was very difficult to properly simulate in software, so you would have to build a clone box. And the price point was super competitive compared to prior solutions at that time. Eventually, the market moved on (and Hybrid Arts drove itself into the ground trying to get into direct to disk recording at the bleeding edge), but the combination of factors worked well for quite a few years.

Another model that has worked ok more recently is free software, but worthwhile paid online service, or worthwhile paid support services. Think of the early days of Quicken. The software was dirt cheap, but the preprinted checks were relatively expensive... But that's not practical for every situation.

Something I did in the Fortune 500 world is that new engineers would get a fun, no risk, learning project to start. If the results didn't suck, we'd release them as "Careware". Just a periodic nag screen asking you to make a charitable donation to one of a long list of charities via a web portal. My employer got good publicity, and contact information (the unlock nag was emailed to you), and my engineers got a moral boost. The charitable dollar amounts raised convinced me that shareware and adware models can work, but they do not automatically do so.

Look at the compaints of Android developers, stuff like 2.1 million hits equals $25 in ad revenue. The same thing with micro commerce. Yes, if you keep the price very low the incentive to pirate goes down. But volume then also has to be high for total revenue to be significant.

Instead of getting discouraged, think of it as a postive. If you create something that people want badly enough to bother pirating, then you have demand. Once you have demand, you can try different ways to monetize it (ads, simple donation appeals, better copy protection, whatever).

[chkn]

In the future the integrated code-signed app-stores in OSX/Windows will be much more importent. (If this is a good thing, is another story)

[TheVinn]

In the future the integrated code-signed app-stores in OSX/Windows will be much more importent. (If this is a good thing, is another story)

That only helps if the operating system and hardware do not allow unsigned apps to run, or else we are back to the original scenario. Except, instead of hacking a specific application, hackers will target the code-verification portion of the operating system - thus jailbreaking all apps at once.

[Daven]

You can always use off-loaded registration like M$ does.
Basically, your code need to run some code that's directly downloaded from a server, and, in order to get such dynamic code, the software has to prove its genuine state to the server.
The checking code is now server based, and almost impossible to crack by hacker.
Obviously, the code sent by the server must be signed per-customer (and should do SHA256 checking of the software files / memory), so even if saved back by hacker while it reach his computer, it would be useless on a genuine copy.
This gives an additional advantage of knowing the size of your user base.
The *big* disavantage is that your server must be up 100% of the time (or you need to provide fallback in your software with missing functionnalities).

I even know people doing per-customer version of the software (that was generated while downloading the binary), so any crack would be useless.
I agree with Vincent however that if you intend to do something like this, you either have multi-month time to waste (and you should use that to improve your software) or already a very specific niche market and a glowing 6-digit bank account.

So a hacker can buy a legit copy, gets the server code, does a memory dump, then what?
From my understanding, as long as there's a complete set of code that reaches a client system, and is runnable (i.e. decrypted), a cracker can repackage it removing the phone-home code and release a working standalone crack.

Also, per-customer binaries don't offer protection - the cracker would just release the whole cracked executable rather than a patch or keygen - they'll just let you track the source of the crack, so you might be able to litigate.

[Xavi]

Try to complicate it as much as possible but keep in mind that with debuggers like OllyDbg your code will be crystal clear once the OS loader loads your program in memory. For example, you can use UPX as a sort of piracy protection (masking its marks in the file to avoid uncompression) but as soon as it's executed the original code is displayed in memory uncompressed and it can be traced easily. In brief, if your software is good and popular will be cracked for sure.
I think a good suggestion is to avoid the use of confirmation windows about the registration process, do not show any message to confirm if the registration was correct or incorrect. Ask the user to enter the serial, save it redundantly in hundreds of variables in different sections of code. Randomly access to several of the variables with the serial along the code and make copies of copies of them in the heap and stack. Delay and spread (very important) the computation and get the serial accessing randomly to one or more of the variables (directly or reconstructing the serial by steps accesing to different variables).
Of course this not avoid the cracking but the tracing would be a nightmare.

I'd recommend you these books, very good ones:
http://www.amazon.com/Linkers-Kaufmann- ... 1558604960
http://www.amazon.com/Reversing-Secrets ... 0764574817

[X-Ryl669]

So a hacker can buy a legit copy, gets the server code, does a memory dump, then what?
From my understanding, as long as there's a complete set of code that reaches a client system, and is runnable (i.e. decrypted), a cracker can repackage it removing the phone-home code and release a working standalone crack.

It's not entirely true. First you know the source of the leak, so you can start legal actions.
Also, since the code you're sending is server generated, it's not fixed (as you're supposing). So you can add whatever verification in there, the hacker might get one version, but it doesn't mean he'll have all of them.
I assume that no hacker can break classical cryptography scheme (if any one did, he would worth billions $), and coupled with user-generated identification (like a MAC address, or whatever unique ID in your computer), the hacker will probably get a code that's perfect for his own computer, but useless on other, unless he rewrote most of the application.

Most protection using cryptography today use CPU specific exception to decode ciphered code on-the-fly in a page by page basis, trashing the decoded page once it's no more used.
So unless a hacker goes over each page of code (and tracking where it comes from is hard when it's crypted/coming from a server generated code), he's twisted.
The amount of work required to reassemble thousands of pages (and being able to identify which is which) is probably in the same order of complexity as rewriting the software from scratch.

Also, per-customer binaries don't offer protection - the cracker would just release the whole cracked executable rather than a patch or keygen - they'll just let you track the source of the crack, so you might be able to litigate.

You're right, you can identify the source.
But, and it's the most important part, you'll also be able to have custom behaviour per user.
So, if a hacker-dump executable is in the wild that doesn't phone home, the resulting software will have the hacker's limited set of features.
With the system from the above paragraph, you'll end up with a software that's having only the features that the hacker bother to uncrack/dump until he get bored.

For example, take a software like Chief Architect. They maintain a library of architecture object on their servers. This library is per customer / per version.
The hacked version doesn't have access to this library because it's blacklisted on their server, and the "phone home" stuff is disabled in this version too (so you can't update the software).
You end up with an inferior product, and no hacker will spare all his time to "import" all the library from the server, since, I guess, each item in the library requires decrypting + dumping.