A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
I'm in the process of evaluating what anti-piracy protections I'll implement in a niche productivity type application I'm currently building.
There are plenty ways to make life harder for the hacker trying to crack the app, but Data Mangling with de-obfuscation keys seems to be the strongest one for my specific situation, and probably for some of you too, but almost no one ever uses it.
There's very little information about it online, it's only mentioned in some tutorials and some anti-piracy books, but nothing in detail.
In case you're not familiar with this method, I'll explain what it is (or better said how I understand it) and how I intend to implement it, sorry if I get a bit technical in the following few paragraphs, but this method brings about some business implications (specifically some of the customers will be slightly inconvenienced), and I'd like to hear your thoughts on the business implications.
First a reminder of what we already know:
1) The best way to protect an app from cracking is to make it a SAAS app.
2) If the app has to be a desktop app, then the next best way to protect it is to make it dependent on your servers for some critical calculation at run time. This implies that the app must be able to access the internet whenever it's used.
3) The hardest way to protect it from cracking is if it has to work offline all the time.
Now my protection method for a desktop app is a type of a hybrid between 2) and 3).
The idea is that some critical client data will be mangled (encrypted or obfuscated) by the app, and then the app will need a demangling license key from my server to be able to operate on the mangled data.
The demangling key from my server will be dependent on a hash value of the client data, so the key will work only on the client for whom it was generated, i.e. in case it's shared it won't work on another client's data.
If a cracker wants to crack it, he won't be able to simply skip the mangling and demangling steps, because the app won't contain code that operates on plain data. Instead it will contain some PInvoked C++ code which will operate only on mangled data.
For example if the app needs to calculate 45 + 81 = 126, it won't contain the code to add the two numbers, instead it will first convert 45-->3A87BB and 81-->9CC240 and then calculate something like 3A87BB ! 9CC240 = 1F4FF2, where the (!) is an operation equivalent to addition, but works only on mangled data. Only when the result needs to be shown to the screen, the app will demangle 1F4FF2 into the number 126.
And the (!) operation will additionally be convoluted on a few levels in C++, which I believe will make it a nightmare even for a skilled hacker trying to understand it.
So this is on a very high level what I intend to do, there are many more details and nuances in the implementation I have in mind, but I'll spare you the details, unless someone wants to know more about it.
Now the negative business implication: The client will have to update every once in a while the license key he has bought, this update will be free of charge but it might annoy him.
Specifically in my case the program will generate a license-request file once a year, and this file will have to be submitted to my website so that a new licence key will be generated for the client.
Additionally I'll force the clients to have to update the app at least once a year (free of charge again), this means that each version I release will expire in 12 months.
Why I'll have to force the update of the license key and update of the app yearly is dependent on the nuances of my implementation, like I said I'll spare you from those details, so this is the best scheme I could come up with that should be very hard to crack.
Now I believe most of my clients won't be concerned because they'll either have the settings set to "Auto Update" or will be able to click an "Update Now" button when the update nag screen starts to appear, and everything will happen in the background.
But some of my clients will be in corporate networks disconnected from the internet, and they'll have to manually update both the program and the license key when the nag screen starts appearing.
I expect these clients might be a bit annoyed by this, but that's the trade off for this type of anti cracking protection.
I probably need to note, the price I intend to charge for the my app will be above $100, maybe even above $200, and I speculate that around half my clients will be individual professionals, and the other half companies.
So for a price of $200+ I think most individuals will be willing to use a cracked version and most companies will try to either download a cracked version or just buy one license and use it on many computers, that's why I'm considering this elaborate scheme against cracking.
So what do you guys think about it, I'd very much like to hear your criticism of my plan.
I haven't mangled license keys, but I used to sell a command-line screen capture program that had every string literal mangled in the EXE ( I used a preprocessor to do this. )
I didn't want anyone changing copyright notices or finding the text from the nag message very easily.
The use of the mangled strings was labeled suspicious by a number of Anti-Virus products and I ended up removing the mechanism.
Saturday, July 04, 2015
The biggest risk to your niche productivity app is not piracy, but rather that there is no market for it and nobody wants it. You should aim to "validate" your product ASAP as mentioned by Andy Brice, Eric Sink, Bob Walsh, YCombinator etc. Your version 1.0 should ship without any "(!)" network code at all so you dont waste your time on that feature, you should ship the first version without any servers at all apart from some basic static web pages and an option to buy the product. Getting distributed computing and server code working reliably can take ALOT of time, servers can also cost alot of money and you dont want to risk losing money until you know that a significant number of customers are willing to pay for your product.
If you can, move your design more towards 2) above, so that its just not the licence stuff thats on the server, but rather templates, fonts, graphics, cool plugins etc, which helps with user acceptance of the need to be connected to the internet and dynamic content makes it harder to crack.
Your design of forcing clients to update the app and generating new licence keys occasionally is way too complex. You just give the client an 'n' digit licence key when they pay you money. Then when the app tries to access the server you check:
if (key is in list of valid keys)
serve "not authorized"
if (key is being used by too many ip# or connections)
Thanks @Billy, I understand the importance of validation, and even then there's still a risk that it won't pan out. But I've already decided it would be worthwhile building it even if it's just for the skills I'd get from it, so I will push it till the end.
Btw from your reply it seems to me you slightly misunderstood how it will work.
The (!) operation won't be accessing the network, it's the operation that replaces addition, and it works only in mangled space using the demangling key.
Also the app and its protection scheme are not distributed in any way.
And I've decided that I don't want to make the app as 1) or 2) above for a few reasons:
- I want the users to be able to run the app offline, so it can't depend on accessing the internet every time it's launched.
- There will be a lot of personal information stored in the database, and I want the users to have the ease of mind with regards to privacy and know that all their data is on their local hard disk.
- Performance: The internet latency which can be 2-3 or even more seconds sometimes is not acceptable in my case.
So the best scheme that I could work out is that the app will be able to work completely offline, but the users will be forced to update their executable and their licence key once a year, and this step will be the equivalent of the "critical calculation at run time" mentioned in design type 2) above.
The licensing key scheme you suggest is a very basic one, the problem I have with it is that it's too easy to crack, the hacker only needs to find the conditional jumps in the disassembled version and he can easily patch them.
My scheme uses elaborate mangling on a small subset of the user data so that the only possible ways to crack it will be:
- To understand how mangled data is manipulated by some very obfuscated code, and the whole code will have to be understood, not just a few critical points.
- Or rewrite in a patch the whole portion of the app that works on mangled data.
> The use of the mangled strings was labeled suspicious by a number of Anti-Virus products and I ended up removing the mechanism
My experience is the opposite. My apps all have encoded strings for the same reasons you mentioned (so nobody can hex-edit the exe and change URLs, names, etc) but I've never had any alerts from VirusTotal.com, Avast or Avira for doing it; even to this day.
> Btw from your reply it seems to me you slightly
> misunderstood how it will work.
I am so sorry about this, I am in Mexico and this is the second time I have recently misunderstood a post and have replied incorrectly. I will again blame it on switching from Spanish to English and also a lack of coffee and will think twice before posting in the future :-(
Please pardon me BOS, but I read "Now my protection method for a desktop app is a type of a hybrid between 2) and 3)" which to me meant a hybrid app with an internet connection, virtually pirate-proof like eg Quake3 from id software was.
Surely what you are proposing then is just a variety of interpretive protection scheme, doing the protection at a higher level which rasies the barrier to cracking it, but history shows will slow down the crackers but not stop them?
> a hybrid app with an internet connection, virtually pirate-proof like eg Quake3 from id software was
I was big into the Quake scene all those years ago and Q3 was not pirate-proof at all... there were plenty of pirated servers running where you could play without paying for the game, and even tonnes of CD key generators for the game. Q3 was touted as pirate-proof but I think most of that was just marketing BS.
That's the problem with server-side protection: it sounds good, but people just set up pirated servers instead. I recall seeing a cracked app once that needed server-side authentication, but the crack's readme file even explained how to set up a fake server to fool it, using nothing more than local files and HTTP redirects to point to it.
> I'm no expert but if it's rarely used, then surely that's for a reason?
I wouldn't jump hastily to such conclusions. Here's what one cracker said once in an interview: "I was surprised how little programmers know about that subject and one thing I am wondering about is why programmers don't put more effort in protecting programs in which they have put lots of hours in programming.".
A strong protection will save you lost sales from piracy only while your app is not very popular yet, and this is the period when you're shortest on money and each sale means a lot to you.
No worries for misunderstandings Billy, we can easily clarify anything, and I appreciate your efforts to help.
I guess I didn't clearly specify that my hybrid between designs 2) and 3) is not a hybrid on a technical level but on a conceptual level. And I probably should not have called it a 'hybrid' at all, but no better word came to my mind.
And what do you mean by "interpretive protection scheme"? I don't see anything on the net about it, if that is something that could help me then please send me links, I don't want to reinvent the wheel unless I have to.
And you're right that nothing is uncrackable, but raising the barrier to cracking does bring you more money in the end. By raising the barrier, beginner hackers won't be able to crack your app and you won't be losing any sales due to piracy until your app has become so popular that a very skilled cracker has taken upon him to crack it no matter what.
Pissing your first customers off before they become confident they will get enough value out of your app down the road is not a very smart business tactic IMO.
Vendors dominating their niches, such as Adobe or Autodesk, can get away with very annoying license enforcement techniques for that very reason - their apps are de facto industry standards, and the costs of coping with those techniques are negligible compared to the value. But if you are a new entrant, and there are mature alternatives that use one-time activation or good old license keys, you must be much, much better than those established players on all other fronts to offset those costs and annoyance.
Dmitry Leskov @Home
Sunday, July 05, 2015
IMHO it would be a lot better for your sales if you spent all the energy you are proposing to spend on anti-cracking measures on improving your product and improving your marketing.
*If* there is a demand for your product and piracy becomes an issue THEN you can start to think seriously about DRM.
Note also that the harder your app is to crack, the more attractive it becomes to crackers (more bragging rights if they crack it).
Sunday, July 05, 2015
> And what do you mean by "interpretive protection scheme"?
> I don't see anything on the net about it, if that is something
> that could help me then please send me links, I don't want
> to reinvent the wheel unless I have to.
Here is an article that contains info about 3 x protection schemes that are 25+ years old, instead of C# calling to C++ they are an interpreter calling to obsfuscated 68000 assembly (Magnetic Scrolls), or VMs calling to x86 assembly or even another VM (games from Electronic Arts).
Unfortunately interviews with "sceners" and "crackers" tend to disappear from the internet and I cannot find anything better at the moment, but obsfuscating the arguments/parameters when calling into protection routines is common
> Note also that the harder your app is to crack, the more attractive it becomes to crackers (more bragging rights if they crack it).
Do you know if this applies to new and coming apps, or only to already established apps that everyone knows?
I speculate the skilled crackers who want to brag will rather choose a famous uncracked app, than bother with a strongly protected one that no one has heard of yet.
If you think this is not the case please tell us more.
> But if you are a new entrant, and there are mature alternatives that use one-time activation or good old license keys, you must be much, much better than those established players on all other fronts to offset those costs and annoyance.
Yup I've got some unique features that are my main selling point and that none of my competitors have, so I count on this to allow me to charge much more than my competitors and inconvenience my customers with impunity >:-)
Thanks Billy, so this "interpretive protection scheme" is actually a mini virtual machine whose role is to strictly obfuscate a few operations.
I already had that in my plan, only a much better solution.
I see they built a virtual machine that simulates 18 instructions (add, subtract, increment, load, store, arithmetic shift left, move, branch if equal, branch if not equal, call, return, jump, decrypt, and execute native code).
I find that still too easy to reverse engineer.
Wanna give a real headache to the cracker?
Build your virtual machine as a single tape Turing Machine to do your critical operation. So instead of the 18 commands above which are still quite decipherable, with a Turing Machine all the cracker will have is two commands: Move Left and Move Right.
And if you really wanna explode his brain, you can build a Turing Machine that simulates another Turing Machine.
Only care must be taken that the slowdown will be multiple orders of magnitude, so you don't wanna make your user wait for more than a second when he clicks on something.
>Do you know if this applies to new and coming apps, or only to already established apps that everyone knows?
No doubt famous apps carry more bragging rights that niche apps. But most 'successful' apps (including more niche ones) seem to be cracked at some point.
>Yup I've got some unique features that are my main selling point and that none of my competitors have
Maybe your competitors don't have these features, because nobody wants them? Its hard to know until you start asking for money.
>so I count on this to allow me to charge much more than my competitors and inconvenience my customers with impunity >:-)
Good luck with that!
Sunday, July 05, 2015
> Yup I've got some unique features that are my main selling point and that none of my competitors have
...and that are hard to replicate (or patented and you can afford litigation)?
Monday, July 06, 2015
>> Yup I've got some unique features that are my main selling point and that none of my competitors have
> ...and that are hard to replicate (or patented and you can afford litigation)?
They require the whole app to be designed differently from the grounds up, and they also make it an order of magnitude harder and more work to build it than my competitors' apps.
But the benefit they bring is immense.
I'm inclined to go along with the "don't waste your effort" school of thought. $200 is not a lot of money for a professional application at all, and the vast majority of serious users would much rather pay that, get support, updates etc and not run the risk of running a compromised executable on their system - or going to the effort of ensuring that a compromised executable can be run relatively safely.
I also got the rage about piracy in the earlier days of my product (also $100+) and, although it still p!sses me off (of course) I now realise that there is no cure.
Over the life of my product I have had forums publicising how to circumvent the trial period (which is now feature limited, but wasn't then), and crackers openly selling versions for about $40 in Russia. Now a cracked version of my product is available on megadownload but my sales are stronger than ever, even from territories with a high piracy association. I just try not to think about it too much and spend my energies elsewhere.
The technique you use is called homomorphic encryption. Look there, and you will find tons of useful information.
Monday, July 06, 2015
There will always be companies no one has heard of with no track record and no funding producing draconian software that treats the paying users like criminals, holds their data hostage, and destroys years of work when the company goes under or gets acquired and the license server dies.
Products from said companies must be avoided at all costs if one values their data.
Yup Scott that's great advice and should be observed as much as possible.
But when you don't have an alternative available on the market, if it really brings you value then you just suck it up and live with it.
I wonder do you have any idea how many people are as cautious as you and I, and would refrain from even trying it out because of its draconian licensing procedure?
> The technique you use is called homomorphic encryption. Look there, and you will find tons of useful information.
I examined this a bit and I must admit it's really great stuff.
Will definitely use some of these functions, and Karel you just saved me from reinventing a large wheel for my app :-)
Scott's comment is precisely why my apps are DRM-free and don't need the internet to run. My users buy my apps knowing that the version they bought will work forever, regardless of which PC they have or if I go out of business. Sadly, this mindset is a rarity these days for most devs.
I see many of you adopt this mindset, but do you have an estimate (even a vague one) of how many sales you're losing because a crack of your app exists?
I have the impression that you adopt this mindset mostly because it gives you the least headache and is the least painful.
I want my decision to be calculated and hopefully optimal.
If for example I'm losing only 10% sales because of the crack then I shouldn't add more than 10% to my development time to improve the protection, and my time is probably better spent elsewhere, like marketing or something.
But if I'm losing something like 50%, then I'm justified spending a lot of time on the protection.
And considering that one of my competitors offers his app as a SAAS app and many customers are still willing to use it, I don't see myself any worse than my competitors, if nothing else it won't cost me anything to release my app as open source in case I decide to abandon it one day.
How are you going to know what % of sales you are losing due to a crack? Many (most?) of the people that use cracks would never buy the software if there wasn't a crack.
Wednesday, July 08, 2015
In the early days of a product I am focussed on:
-who wants my product
-how can I make it better for them
-how can I get their attention cost effectively
Piracy is waaaaaaaaaaaaay down the list.
Wednesday, July 08, 2015
> How are you going to know what % of sales you are losing due to a crack? Many (most?) of the people that use cracks would never buy the software if there wasn't a crack.
I'm talking strictly about the people who would buy your software ONLY if they couldn't find a crack. The others are not relevant.
And it's probably not easy to find out, I suppose the big guys have some methods to get an idea about it, but for the little guys it's probably much harder.
You mentioned on your blog you have a honeypot for your app, has this given you a clue how many of your buyers searched for a crack before they bought?
> In the early days of a product I am focussed on:
> -who wants my product
> -how can I make it better for them
> -how can I get their attention cost effectively
> Piracy is waaaaaaaaaaaaay down the list.
A cursory search for your app shows you've got many competitors out there. This profoundly affects your approach to protection. Even if you could make it totally uncrackable without any downside whatsoever, you still have a problem with your competitor's apps which are cracked or open source. Hence you get very little benefit from a strong protection. If I were in your place I'd probably do as you do.
But if you offer something new for which there's no alternative yet, then I believe a crack will have a much stronger effect on your sales, at least until alternatives appear on the market.
"I see many of you adopt this mindset, but do you have an estimate (even a vague one) of how many sales you're losing because a crack of your app exists?"
I track things and I know exactly. None.
There's no cracks. No point. My licensing system is quite trivial to defeat, so despite my programs being quite popular, no one's bothered to release a crack.
Oh there's a few downloads here and there with names of my programs called cracks. They are all malware that roots or otherwise compromises your computer and has nothing to do with my software.
When the program is unlicensed, it's still 80% functional, including the most important functions, so that even if a customer has a disaster and the key entry is damaged or deleted, they can keep working temporarily.
The other 20% of functions are still there and can be reactivated using a trivial edit that technical people can easily figure out.
Most of the illicit use of my software is people using it outside the scope of the license, and sharing keys with their friends. Less than 5% of users share keys, and most of these with only one or two others. A considerable number of key sharers eventually buy the program. This usually happens around the time they ask for user support.
The real cost is when pirates use customer support. That is costly. This is handled easily, I note their license is not valid and customer support and updates are only available to current customers. Purchases often come after that.
Sometimes a key gets loose and a bunch of people try to use it. These go on black lists and the original purchaser loses their license unless they can show it was an accident - like they say someone in particular broke into their house and stole their license, in which case they are willing to forward me a police report. That never happens.
Casual piracy is a very effective form of advertising when managed correctly.
But that's only an inadvertent and surprising side effect of fair and reasonable treatment of paying customers.
New major versions get new license keys and old versions stop working when people upgrade their computers because new computers often drop support for various old APIs.
I don't intentionally use the oldest APIs around that are long deprecated and at imminent risk of being removed entirely, but doing this just because I have old code around in there works pretty well to keep people upgrading.
Having customers lose their data or worry about being able to keep it working because of license servers is a common concern in production applications used to do real work. Their knowing that a down license server won't kill them certainly hasn't worked against us, and there's plenty of indication it has led to great success over the long term.
I strongly encourage all my competitors to use the most extreme licensing possible, and to treat all their customers as possible criminals.
Ok Scott, your situation seems similar to Andy's so investing in a stronger protection is probably unnecessary in your situation too.
To me Dmitry's advice above seems the most reasonable one: How much you can annoy your customers and whether it's worth it is dependent on how irreplaceable your program is to them.
I've been seeking an answer to the question: How many sales do we lose due to cracks, and here's the best answer I could come up with.
First I researched the general piracy rates of business applications (emphasis - business applications ONLY) and here are the numbers I got:
40% - piracy rate in 2002 worldwide
25% - piracy rate in 2002 in North America
43% - piracy rate in 1996 worldwide
28% - piracy rate in 1996 in North America
There was a trend of slow decline of piracy rates in the 90s, but it seems it has stabilised, so we'll assume a 40% average piracy rate of business application.
Now if the average is 40%, the majority of apps will probably be somewhere between 20% and 60%, depending on which industry, how expensive is the app, whether there are open source alternatives, etc.
Let's take it as 40%. Now we wonder how much of those 40% is recoverable???
Easiest case: Let's say there are no alternatives to your app, in this case it might be possible to recover all 40% if you prevent a crack from appearing. It will basically boil down to the question: How many of those businesses find your app more valuable than the cost to purchase it. If it's more valuable to all of them, then you can probably recover all 40%.
A much harder case is if you've got competitors or there are open source alternatives. In that case when your users can't find a crack of your app they'll simply find a crack of your competitor's app or use an open source alternative, so you aren't getting their money anyway. I'd roughly guess that in this case you can't recover even 10% of these lost sales, so there's not much sense to bother with the protection. And since you aren't getting their money, it might be even better that these non-paying users use your app instead of your competitor's, this might be helpful for spreading the word, recommending it to real buyers, etc.
Based on this conclusion I'd say each case warrants a different strategy. Both of you are right to use a weak protection for your apps, and Adobe and Autodesk are also right to use a draconian protection for their product.
The piracy rate numbers from the BSA are either right or a bit low from what I see around me every day, so I didn't study them further. They probably do have some methodology how they obtained them, so look at the sources in more detail if you care.
As for the conclusions we draw here, they are highly speculative in nature, but since all we've got is some scant and incomplete data to work with, it's the best we can do.
>> "Where's Wyatt these days? :)"
Mostly just watching from the sidelines and occasionally interjecting when the mood strikes. So much bad advice has been given in this thread that I can't help but laugh. I'll address some of the more absurd nuggets shortly.
But first, I'll start with the elephant in the room: nothing can stop cracking. Not obfuscation. Not data mangling. Not in-memory encryption. Not in memory virtual machines. Nothing. You're at best adding minutes to the time it takes to crack your app. And if you're buying a solution that claims they're uncrackable, then run fast -- they're lying to you (either because they themselves are ignorant, or they're assuming their customers are ignorant): http://wyday.com/limelm/features/why/#snake-oil
So, yes, you can create all these fancy methods to "protect" your app from cracking, but you're really just wasting your time (unless you enjoy the tinkering, in which case more power to you). Your time and effort is better spent creating or buying a properly designed hardware-locked licensing solution: http://wyday.com/limelm/features/why/#hardware-locked
With *properly designed* hardware locked licensing you can prevent casual piracy and increase your revenue. Plus you have control over situations you wouldn't with serial-only licensing (purchase orders, returns, chargebacks, actually limiting how many computers your app can run on, etc., etc. )
Obviously I'm biased about which product you should choose if you choose to buy a hardware-locked licensing solution (LimeLM!), but there are a couple of other 3rd party licensing companies to choose from who actually designed their systems correctly.
Now I'll address some of the more absurd nuggets (I'll paraphrase):
1. "Cracked versions of your app are a form of advertising."
This is an oldie but a goodie. But the short answer is this: nope, that's stupid.
Long answer: Well, I mean, sure, if writing your company's web address on the walls of the bathroom stalls in the middle of Idaho are also a form of advertising for your company, then yes cracked versions of your app are a good form of advertising.
Or, you know, you can advertise to customers who are actually in the market for your app and have cash to spend.
Then to get rid of cracked versions of your app from search results (Google / Bing / Yahoo / etc.), use the DMCA. This way legitimate customers won't see the inevitable cracked versions of your app, and you won't be competing against free versions of your own app.
2. "You should focus on other stuff."
I can't entirely disagree with this. You *should* focus on other stuff like advertising, market, support, product design, product-market fit. But focusing on these very important things shouldn't be to the exclusion of other very important things: properly designed licensing (i.e. getting paid for your software), taxes, utilities, payment processing, invoice handling, purchase order handling, office space, forming a corporation, trademarks, copyrights, etc., etc., etc.
Starting a business is hard and there are a lot of moving parts. But that doesn't mean you should ignore some of the moving parts or wrongly assume they don't matter.
There are other absurd things said in this thread, but those were probably the top 2 most absurd.
Friday, July 10, 2015
I just found an example of someone who answers my question "How many sales do we lose due to cracks" and his number is up to 70% for an app less than $20:
It's an anecdotal piece of data, and we don't know what kind of app he sold and for what kind of customer, but from this and other places I read on the net it seems the loss is even higher than what I estimated in my previous post.
And this and other posts elsewhere all seem to confirm Wyatt's assessment that whatever "advertising" you're getting from your cracks, it's negligible compared to the hard sales you lose because of them.
So I'd say a solid overall anti-piracy strategy is a must for pretty much every software seller out there who's serious about money.
I've worked with icsbusinessbox for some time and find their advice to be most helpful on matters of security.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz