More copy protection...

[Frantz]

I think the iLok guys are utterly incompetent. With that many f**k-ups ("iLokalypses") I'm surprised they're still in business.

Forget this synth emulation stuff. I think creating uhe-Lok would be more fun and profitable for you.

[Urs]

I think the iLok guys are utterly incompetent. With that many f**k-ups ("iLokalypses") I'm surprised they're still in business.

Forget this synth emulation stuff. I think creating uhe-Lok would be more fun and profitable for you.

You are probably right (asking money from developers *and* selling overpriced USB plugs to their customers... double milking certainly pays well). But then *I* understand that creating such an excessively large apparatus for obfuscation is something that not even the originator can control.

(which reminds me, just yesterday we had downtime on one of our build systems because something went wrong with the iLok. We couldn't revive it on that machine, we had to plug it into another, where it suddenly worked. It's so clever, it's over its own head)

[Urs]

"if a D#4 is played in bar 47 after at least 10 minutes of rendering".

That's evil

Side note: i had a very quick look at the code (5 min) and it's deceptively simple.
it's unusual to see non crypted / non protected code i think.
i can imagine the guy launching his disassembler, and saying himself "this will be easy".

Edit: that would be a interesting executable to crack if i had more time on my hand i think.

It's out of the box thinking. Everything seems simple. Serial number? - Simple! It's exactly based on the assumption that the cracker will say to himself "this will be easy".

[2ZrgE]

I think the iLok guys are utterly incompetent. With that many f**k-ups ("iLokalypses") I'm surprised they're still in business.

Forget this synth emulation stuff. I think creating uhe-Lok would be more fun and profitable for you.

You are probably right (asking money from developers *and* selling overpriced USB plugs to their customers... double milking certainly pays well). ...

Still there's a lot of people around here defending that crap, pretending to be rather happy with it, falling for the 'high price and iLok = must-be-quality' illusion.

I never understood why I would have to pay for that crappy USB-stick also when purchasing software - therefore I never bought and will never buy software protected in that stupid way. If they would give me that stick for free, maybe...

Must be rather annoying for you when a company like yours constantly produces high quality stuff and people think: "what man, no iLok and just a serial - cannot be that good soft..."

[Vertion]

Still there's a lot of people around here defending that crap, pretending to be rather happy with it, falling for the 'high price and iLok = must-be-quality' illusion.

I never understood why I would have to pay for that crappy USB-stick also when purchasing software - therefore I never bought and will never buy software protected in that stupid way. If they would give me that stick for free, maybe...

Must be rather annoying for you when a company like yours constantly produces high quality stuff and people think: "what man, no iLok and just a serial - cannot be that good soft..."

How about the U-he application process. No iLok, no fancy copy protection. Just an online form to fill out if you seek to purchase a U-he plugin, with one answer upon submission, either a yes or a no. This will drive the scarcity up through the roof. Towns will throw a parade for anyone in their town lucky enough to be accepted, it could even make the papers.

Also, you could send out 5 golden tickets to visit the U-he factory. For this option, a cane and top hat will be required.

[plusfer]

Imagine every malloc, free, open, read, write, close, getTime, strlen, sprintf look like this:

myGlobalOS->dispatch( k_OpcodeMalloc, 1000, &outPtr );

All of which you can create preprocessor makros for that let you code just like you normally do.

The result is "hey, I'll track file opens" - "Uh, oh, cool, there's only one! All fiel access goes through this code bit here..." - "Eeek, there are 397 references to this code bit..." - "lemme see what else I can crack beforehand..."

I am not clear on how to implement a dispatcher, is there some info to read? or is a simple big function with a switch/case/if?

[aciddose]

A switch is the most obvious solution. You can also use tables or even more complex constructs like trees. Although that is still very simple stuff.

A switch statement would be no problem as it's essentially just a list of integer offsets. Tracing back from "open file" to the switch is no problem at all and could be done by hand with little to no effort. Such a construct would be identical to directly calling the fopen or similar function as the cracker would just place a breakpoint or make modifications as needed.

In order for this to have any effect at all it would need to be used extensively throughout the code for almost everything. The action taken related to protection would need to be indistinguishable from ordinary and frequent actions.

Regardless of how deep you go it's still not "uncrackable" or even impractical to crack; otherwise the program wouldn't be running at all. It's just a matter of finding ways to apply leverage to your time such that the time required to crack it is significantly more; in combination with pushing that time requirement beyond what the cracker is willing to invest.

[Urs]

Imagine every malloc, free, open, read, write, close, getTime, strlen, sprintf look like this:

myGlobalOS->dispatch( k_OpcodeMalloc, 1000, &outPtr );

All of which you can create preprocessor makros for that let you code just like you normally do.

The result is "hey, I'll track file opens" - "Uh, oh, cool, there's only one! All fiel access goes through this code bit here..." - "Eeek, there are 397 references to this code bit..." - "lemme see what else I can crack beforehand..."

I am not clear on how to implement a dispatcher, is there some info to read? or is a simple big function with a switch/case/if?

Just think of it as a single (non inlining) function:

void doAllTheSystemCalls( int inWhich, void* userData )

The first argument says what you wanna do, like loading files, opening message boxes, reading the registry, saving a preset file. Also add in some other stuff you need, such as converting ms to number of samples. The second argument contains whatever data structure (without methods, unless they inline) the operation needs.

With this construct the cracker has to weed through dozens, if not hundreds of places to figure out where the calls come from, and he has to do some math to see what kind of call it is.

This is equivalent in principle to building a virtual machine. It is an initial, simple step which moves the process of cracking from code analysis to understanding of data manipulation.

[Urs]

Also, if the cracker is using a debugger instead of a code analysis tool, the breakpoints he sets will be called a gazillion times before anything happens that's interesting for him.

Anyhow, it's just a simple example really of how strengthening the protection is no voodoo. When I looked at IDA (youtube is good enough), I immediately knew my old protection was crap. Building a good protection starts with observing their methods and basic knowledge of their tools. Spend a weekend reading CrackMes and their solution. Try to find the Fravia website and archives (but disregard any fear mongering for SoftICE).

[plusfer]

Thanks guys!
Very useful all the tips of this thread as well as the Richey's "anti crack faq"
Anyway, I will have to play with IDA.

[Vertion]

Copy protection is a losing game. Using deception to try to trick a cracker is foolish, you are literally manifesting your own cracker when you make a better copy protection, as if pride created the cracker in the first place. I know a crack can lead to losses in sales, quite infuriating and humbling. A calamity upon such hard and humble work, all lost to some naive cracker with too much spare time and too much to prove to the world. Instead of fighting this natural reaction, embrace it. For some to reveal what is concealed, to bring light to mystery is their persona. incorporate it into your design and embrace it. Most processors only speak one machine language per, trying to encrypt the grammar and logic is just a crossword puzzle in the newspaper to solve for some. Any copy protection you make can be broken, as long as the user has access to all the data and code, in any form. Before you head down the primrose path of copy protection, keep that in mind. It's better to give the user full access so they use the software and get addicted, but leave imperfections that annoy the user unless they have the full version. The more the demo user uses it, and more they invest time into software usage, the more likely they buy and better it is for you. U-he has the right idea with the interruptions, but since I am sensitive to those frequencies I turned it off demo and just bought it out of annoyance and because I already knew it had high acclaim. But for a new name synth, only silence every 30 sec/ minute or so.. or perhaps 20-30 minutes usage before restart, that pulls me into investing everytime. I care about this industry. I own all my software, I hope this thought helps someone.

[Kylotan]

Imagine every malloc, free, open, read, write, close, getTime, strlen, sprintf look like this:

myGlobalOS->dispatch( k_OpcodeMalloc, 1000, &outPtr );

All of which you can create preprocessor makros for that let you code just like you normally do.

The result is "hey, I'll track file opens" - "Uh, oh, cool, there's only one! All fiel access goes through this code bit here..." - "Eeek, there are 397 references to this code bit..." - "lemme see what else I can crack beforehand..."

I am not clear on how to implement a dispatcher, is there some info to read? or is a simple big function with a switch/case/if?

Whatever you do, don't forget to switch optimisation off for those functions - a good compiler will be able to spot what you're doing and remove all that 'unnecessary' code

[Kylotan]

Copy protection is a losing game.

Not really. There are many people in the grey zone where they will use cracked software if possible, or they might buy it if not possible. Some might not pay full price, but if a sale comes along before a crack does, they may purchase. Some might have a fixed budget and will spend that on the uncrackable stuff. Some just steal software because it's convenient to just download every torrent that comes along but will happily pay for everything else.

The idea is not to write totally uncrackable software, but to do enough to help your business. (And to help your paying customers not feel like idiots.)

I work in the games industry and we have tons of data to show that anti-piracy and anti-cracking efforts make a massive difference to revenue, and revenue is what lets us improve products and support customers. Every so often some bullshit article comes out saying "pirates would never buy anything anyway", usually based on some flawed self-reporting study, but we have the actual sales data to tell us otherwise. Copy protection is useful.

[PurpleSunray]

I work in the games industry and we have tons of data to show that anti-piracy and anti-cracking efforts make a massive difference to revenue, and revenue is what lets us improve products and support customers. Every so often some bullshit article comes out saying "pirates would never buy anything anyway", usually based on some flawed self-reporting study, but we have the actual sales data to tell us otherwise. Copy protection is useful.

Really? I have read different. The article I have in mind puts gamers into 3 categories: the 'nerd' ones that want to have the game asap after release and does not even look for cracks, but has pre-ordered the game already. Then there are the ones that never paid for anything. If they don't find a cracked version of your game, they simply play another game - no way to get any $$$ from them.
The last category are causal gamers that are interested on exactly your game - this one is complex, because it will depend on price ect pp. if they are going to look for a crack or not.
But summary of that article was that copy protection is utterly overrated accross gaming instury. All that work is actually only done to stop a small percentage of the #3 group, which can also be captured differently with less effort (special offers for example).

Edit:
On a previos company I was working on we followed the exact vice versa model.
We had a kind of pseudo-protection to stop script kiddies, but our releases were all cracked withing 8h after going online and it was intended like that.
The market we were in was shared between 3 major companies.. and our strategy was a pretty simple one: one that uses our cracked software, does not buy from competitor.
It all based on the idea: "first step is to get onto a (potential) customer PC .. doesn't matter if it is cracked version or not". Then he knows your company, your procuct, can see your upsale-splashscreen, whatever. First it is about mass distribution / market share and when we are on a (potential) customer PC we start to try to convert him to a paying customer.

[Zaphod (giancarlo)]

Copy protection is a losing game.

I work in the games industry and we have tons of data to show that anti-piracy and anti-cracking efforts make a massive difference to revenue, and revenue is what lets us improve products and support customers. Every so often some bullshit article comes out saying "pirates would never buy anything anyway", usually based on some flawed self-reporting study, but we have the actual sales data to tell us otherwise. Copy protection is useful.

Agreed, every word.
I'm surprised there are few studies on the side effect, for example the effect of cracked titles on other incoming titles.
It happens in the audio dsp realm too, our sales drop consistently when a product belonging to the same segment from am other developer is cracked.
You could say they are temporarily stopped, which is not true, because you loose the initial hype. I'm surprised someone is not agreeing on those basic and obvious things.