For PC: no good recommendations. I get cracked on the Win side a few days after each update. I suppose I could get into some sort of cat & mouse game with the crackers, but I’d rather spend my time coming up with cool new algorithms.
For OSX: STRIP. YOUR. SYMBOLS.
Use the strip function in Terminal. cd to the directory that your plugins are in prior to release, and use something like the following command:
strip -x PluginName.vst/Contents/MacOs/PluginName
The strip commands in Xcode are kinda worthless. I looked at some of my plugins in otx (and some other plugins), and it is terrifying how much information is in there, even when you use separate strip in Xcode. A good cracker will probably be able to break code with strpped commands, but being able to run otx, and see a line like PluginName::copyProtectionCheck(), makes their job that much easier. So STRIP YOUR SYMBOLS.
Overall, I look at copy protection as a necessary evil. It won’t stop crackers from cracking your code, and it won’t make people that use cracks use your code - they’ll either wait as long as it takes for it to be cracked, or use something else that is cracked. But it helps keep honest users honest. Which is why it is probably a good idea to keep the copy protection on the easy friendly side for your paying customers.
[quote]-i learned assembly i was 14 (i’m 33 now) and i reversed for maybe 8-10 years
-i’m probably below average as a reverser
-still, i can reverse 90% of actual “commercial grade” protections, the difference with a good reverser being the time it takes to me[/quote]
I also learned assembly when I was about 14 (back on the Sinclair QL and Amiga), but that was only because I didn’t have a C compiler! The moment I could use a higher-level language, I was glad to get the hell away from assembly language!
Stripping symbol will not help at all, reverser are not used to read asssembly with debugs symbols anyway,
but yeah of course , if you leave the symbols here, it makes thing kinda easy .
damn !
i read so much assembly in the past, it feels kinda natural now i guess
but i don’t use it anymore if it’s unnecessary, i ended my assembly fanatic era
Still , it’s unpossible to do advanced software protection without a deep knowledge of assembly.
I went from assembly to a high level language by implementing fig-forth on a 6502. And while difficult to grok at first it’s still the only language I might trust in certain situations, as long as we’re talking ‘all forth’ with no other operating system that is. Some code I wrote to control a bank of 200kw generators is still running 30 years later and never-ever bugged out.
Back to the topic however, keep it coming folks, I’m learning a lot. Thanks.
The dongle solution seems to supply a good level of protection, it took them more than a year to crack Cubase 5
and I don’t think they cracked Cubase 6 yet.
Steinberg bought the ‘eLicenser’ technology from Syncrosoft a few years ago so I guess they really like it.
But still, it’s an annoying solution (you can’t even run a demo version without it) and also an expensive one.
In a recent former life, I spent a great deal of time focused on security. When the original iLok was cracked (exposing a number of my company’s plugins), I rolled an anti-tampering solution into the next release, using steganography. It still took advantage of the presence of the iLok. Sorry but I don’t think it’s wise for me to go any farther into that.
When the iLok2 came out, I implemented their solution out of the book. It worked well, but the license callbacks happened in whatever thread context was running (a DAW-specific thing). When one of those callbacks came in an audio thread, it was usually enough to cause a glitch. Since it was infrequent (perhaps every half-hour or so) it was hard to put your finger on the problem. The computer was just acting a bit ‘funny’.
You can get a workable solution, if you’re willing to go up a very steep learning curve. You have to figure out a way to get the license callbacks into a thread that isn’t crucial to performance and then you have to make sure the callbacks don’t happen anywhere else. Once you’re up the curve it’s not hard to implement the solution for new plugs, but you can’t underestimate what it takes to get there in the first place. You have to make the determination about whether the lost sales vs. effort is worth it.
By the way, the old iLok wrapper solution isn’t yet available for 64-bit plugs. It’s not strictly necessary for security, but it provides a nice front-end for cases in which the license hasn’t been purchased or the iLok isn’t inserted. Pace (the iLok company) is a relatively small company. I have found them very willing to work with me in a technical sense, but any suggested changes aren’t likely to be rolled into fixes right away.
Thanks for posting such valuable information in this thread. I have also kind of given up the fight because it’s pointless, but it was very useful to understand how it works on the “other side”.
One thing that I haven’t seen discussed in these posts is about the sharing of registration keys. Obviously, unless you take to hardware locking, there will be a digital file or code that will be transferred to valid users to unlock their copy. So even if the protection code in the software is extremely complex, crackers can always either share valid keys or reproduce the algorhythm in keygens, isn’t it? Unless the reg key only serves as an identifier to a server-based protection that then locks the software to a specific machine. I have been using such third-party solution on some software, and it seems quite good, even though expensive.
