AquaticPrime is a “secure registration method for your shareware applications, released as free open-source software”.
AquaticPrime uses “RSA encryption to provide excellent security - the same that is used to protect government documents”. This makes it sound like AquaticPrime is a great solution for Software Developers wanting to prevent piracy by adopting a software licensing scheme. A lot of Macintosh Small Business developers are using or are considering using AquaticPrime.
Unfortunately for them, AquaticPrime is incredibly easy to crack. I am not a computer security expert and I am definitely not a software cracker, but I was able to crack an application that used AquaticPrime in less than thirty minutes with almost no preparation time. In fact, I am pretty sure that my crack will work with almost all applications that use AquaticPrime.
Aquatic Prime uses a technique similar to one discussed by Allan Odgaard on his blog. Public Key cryptography techniques are used to generate linked public and a private keys. The private key is kept by the software developer and the public key is shipped inside the application’s binary. When a user buys a copy of the software, a license file is signed using the private key. The software can then use its public key to verify that the license key was signed by the public key. Someone trying to steal a copy of the software would be unable to forge their own license files because the public key works with one and only one private key.
The technique I used to defeat AquaticPrime involved creating my own private and public keys (using the AquaticPrime utility itself) and then generating a fake license key (registered to a “John Doe”) using the new private key. The trick then was cracking the test application and convincing it to use my public key instead of the real key.
To track the application, I needed a way of writing code that could be executed by the targeted application. Fortunately, there are a plethora of methods to do that on Mac OS X: Application Enhancer, MachInject, InputManagers, and SIMBL plugins are just some of the many ways of forcing third-party applications to run foreign code. I chose to use a SIMBL plugin because I had never used SIMBL before and wanted to learn a little about it. Creating a SIMBL plug-in turned out to be incredibly easy and I had my code running inside the targeted application in just a few minutes. In a couple of minutes more, I had created an object that was masquerading as an AquaticPrime object. The final step was to make my masquerading object ignore the application’s public key and use my fake public key instead. Once this was achieved I loaded my (or rather John Doe’s) fake license key into the application and found that I had cracked the application.
It really was as simple as that. Of course there were a few WTF moments and application crashes, but nothing unusual during development (especially development of this kind). The code currently only works with AquaticPrime’s Objective-C interface, but the same principles can be used for the pure C interface too. I have tried this technique on two shareware applications and it worked fine with both. I am reasonably confident that it should work with most AquaticPrime using applications.
The method used to defeat AquaticPrime isn’t particularly obscure, and in fact is just one of many methods that could be used to defeat it. However this method is particularly nice in that you’re not really hacking the application using a more brute force method. You’re merely providing it with bad data, which it then uses to validate your bad license (kind of like Garbage In, Garbage out), in all other ways AquaticPrime is working as normal and is blissfully unaware that it has been cracked. This means that some of the techniques that developers can use to find out if their software has been cracked are impossible.
AquaticPrime is a well written, documented and marketed piece of software. But it suffers from this huge design flaw. AquaticPrime is exceptionally easy to crack, either with this method or with a variety of other, possibly cruder methods. Many of these methods are equally applicable to other registration schemes, so it is somewhat unfair to single AquaticPrime out. But because AquaticPrime provides all the source code and headers to anyone, it makes it really easy for anyone to crack. Although hiding the source code would have been a form of “security through obscurity“, this would have at least slowed me down considerable. As it was, I was handed everything I needed to crack this software on a plate. And if I can crack this software in less than 30 minutes, I am sure crackers who do this thing professionally would have had even less trouble.
Even more worrying, this technique doesn’t just work on a single application, it will work on all applications that use AquaticPrime. I don’t know how many applications out there use AquaticPrime, but each is vulnerable to the same crack and all would be cracked essentially “for free”. There are some things a developer could do to shore up this vulnerability, but in reality most solutions are probably just as easily cracked.
Add New Comment
Viewing 17 Comments
Thanks. Your comment is awaiting approval by a moderator.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
At a glance, I see an AquaticPrime object with methods
- (BOOL)verifyLicenseData:(NSData *)data;
- (BOOL)verifyLicenseFile:(NSString *)path;
So if I write AquaticPrime object that always returns YES for those two methods, is it game over?
Do you already have an account? Log in and claim this comment.
Also just returning YES for those two methods won't do anything if the application developer is being smart and also testing the reliability of those methods by calling them with bad licenses. Of course a cracker can get around that too.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
This has always been the case, and this "security vulnerability" exists for any and every class and function for any application. I never made the claim that AquaticPrime is uncrackable with regard to binary cracks. In fact, I have specifically mentioned on several mailing lists that this isn't the case at all. What it does do, and what it does very well, is prevent people from creating fake licenses files which can then be distributed as legitimate licenses. If a pirate is going to install an input manager or do a binary modification, you have already lost the sale. AquaticPrime exists solely to prevent the casual piracy that occurs when finding serial numbers and licenses files are trivial.
Discussions such as these have flared up many times on mailing lists such as the Mac Shareware Business group on Yahoo. I suggest you search for "AquaticPrime" and read over these discussions for more information on the topic.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
I'm a member of MacSB and have lurked during the previous discussions of AP. But thanks for your suggestion.
I don't think this is really a discussion of lost sales. A developer can put in a "I paid" checkbox into his app and then complain about lost sales all he likes but we are unlikely to have too much sympathy for him.
Crackers can and do jump through hoops to defeat software, I'm sure you've seen the tools that are used to defeat Adobe's software or the amusing Mac OS 9 cracks that involved using ResEdit to tweak some random resource in just the right way...
If a developer's application becomes popular it will become a target of cracks. And these patches will trickle down to end users who will become more and more accustomed to using them (see the Adobe cracks for example). AquaticPrime is terribly vulnerable to binary/runtime attacks, more so than any other scheme I have seen.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
Personally I am not of this belief. I have a popular product out there. and I see far more requests for cracks, than actual cracks, and that’s on forums such as torrentskickass, which although a popular forum, are really for the segment of Mac users
that you should not expect paying for your software.
That said, it might be a good idea if AquaticPrime stored the public key internally encrypted — as the poster of this blog noted, that is just a way of obfuscating things, and doesn’t affect the theoretic crackability of the program, but it would (to some degree) prevent a universal patch to affect all programs which use AquaticPrime, since the cracker would have to analyse the code, to figure out how to encrypt his replacement public key.
Do you already have an account? Log in and claim this comment.
Given the open nature of aquatic prime, and the nature in which Lucas has publicized how it works, it's really an uphill battle to secure any applications using it. It's still better (in my opinion) than things like Kagi's ZonicKRM, because if a small business developer is really that concerned with piracy, then AP is there to be modified on their side as well.
Let's be realistic though, if somebody's going to pirate your app, they're going to. Making it difficult is good, but nagging the usual user is a terrible idea (Omni does a good job of not being too intrusive).
The best way to stop piracy, is just to never release your code, and even then it's still kind of iffy ;) Regardless, keep the interesting stuff coming schwatoo :)
Do you already have an account? Log in and claim this comment.
It's fine to argue that Aquatic doesn't need to be secure against "binary attacks," but if that's the case, why bother with a long unwieldy public encryption license? Why not just encode the user's name or email in the license like most of the "naive yet unique" key generation algorithms do?
It seems like the work that went into making Aquatic secure is comical if you can stand back, flip a switch and watch doomsday unfold.
I was hoping that the result of this post would be that Aquatic's author would take to heart the idea that changes (perhaps simple ones) should be made to make it at least a bit harder for a "entire class of applications cracked" type hack to be distributed.
Do you already have an account? Log in and claim this comment.
So the damage of a faked/leaked serial is much much worse than a binary crack alone for this reason. If a user is willing to track down a new binary crack, each time the program is updated, and often wait months for the crack to be available, then surely, he would never have paid the registration price.
I sent this the following to the macsb list, but let me repeat it here:
The purpose of Aquatic Prime is NOT to prevent a particular version of your application from being cracked, or even make it difficult to crack it.
Why? Because to run your program, the user needs the entire code, and that allows him to read it and make changes to it [1].
Time spent making it difficult to crack is roughly proportional with time required to crack it, so playing this game is a waste of time [2].
What it DOES DO is ensure that a binary crack IS a requirement. So if you want to point out flaws in the architecture, you should demonstrate that you can unlock an application WITHOUT altering the code of that application.
[1] At least until trusted computing arrives
[2] Automated code obfuscation could alter this.
Do you already have an account? Log in and claim this comment.
The real problem with AquaticPrime is that one crack can crack all applications using AquaticPrime. Just like applications using the Kagi library. But unlike the Kagi library, AquaticPrime is trivial to crack with a runtime hack. And unfortunately the AquaticPrime documentation makes bold claims about "government level" security and other such nonsense. There is no small print mentioning the fact that the software is incredibly (more so than any other library) vulnerable to run-time hacks. It would be more open for the developer to make mention of runtime hacking and state AquaticPrimes vulnerabilities. While you and I can argue all day about the chances of casual pirates using Input Managers to crack apps it is really up to the developer to decide if this is a concern for his software. A naive software developer will look at AquaticPrime and think it is perfect and not be aware of all the facts.
Hopefully now that I've written this post the level of awareness across the board has been raised somewhat.
Do you already have an account? Log in and claim this comment.
FYI I do that in TM “just to be sure,†though I have seen several cracks of my application, but never have they targeted the public/private key system, as there is generally an easier way to get the application working as was it registered, in fact I would bet that many of the cracks done for TM took less than 30 minutes to produce, as the cracker just run the application in a debugger, and then figures out where to insert nop’s.
Do you already have an account? Log in and claim this comment.
Do you already have an account? Log in and claim this comment.
However, if this framework is not the best one, what are the alternative solutions I can use ?
Anybody can write a state-of-art ?
Add New Comment