toxicsoftware.com

RANDOMIZE USR 0

toxicsoftware.com header image 2
← Internet Clippings to XBEL AquaticPrime Aftermath →

AquaticPrime Warning

June 7th, 2006 · Comments · Default

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.

Tags: ·····

  • tony
    Is there any protection against simply copying the AquaticPrime framework out of the app, and replacing it with a framework that implements the same public classes but doesn't actually check anything?

    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?
  • Well AquaticPrime can be compiled directly into an application using the static library. So there is no framework to swap out and crackers are stuck with the methods I mention in the posting.

    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.
  • Dude, all those weeks and months of silence on toxicsoftware.com were worth it...
  • I sent you this message in response to your email, but I will repost it here for others:

    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.
  • Greg
    I think it would be appropriate if something like that was added to the AP site. Having "AquaticPrime uses RSA encryption to provide excellent security - the same that is used to protect government documents" and "is a secure registration method" gives the impression that it is unbreakable. I am sure a lot of people took that at face value and decided to include it in their applications. Let's face it, crackers make it very easy these days for people to apply patches and what not to binaries, they could easily write a universal crack which affects how ever many applications that use it.
  • If everyone starts using AquaticPrime, then casual pirates might make the jump from a serial to an input manager if they are going to be able to crack 5 or so apps at once. Of course, that is something that comes along with having a framework that does everything for you. Perhaps something more powerful for developers would be a tutorial that tells you how to do this on your own, using your own scheme, and with several different options along the way. If I ever use AquaticPrime (which I probably will), I am definitely taking a hatchet to it and modding it up quite a bit.
  • Hi Lucas,

    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.
  • Zac: Pirates already have a Application Enhancer haxie whose sole purpose is patching copy protection systems...
  • schwa: It's true, AquaticPrime is not for everyone. Each developer needs to look at what licensing systems are available to them and decide what is best for their application.
  • This probably boils down to whether or not you believe that casual users can easily get hold of binary cracks, and if so, if they will use them.

    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.
  • Interesting post schwa, definitely did your research :P. But I don't see it as too great of a problem, especially given the usual habit of mac users to pay for their software. Regardless of the scenario, when you're using code injection attacks against any piece of software, the developer has already lost. While I'm certain you find means for which you can protect the runtime from things like this (how OpenBSD's handled the mmap problem by randomizing allocation addresses comes to mind, but given the structure in which the Objective-C runtime operates, i'm not sure something like this is doable, but it's still merely security through obscurity).

    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 :)
  • Greg points out that the "marketing" of AquaticPrime emphasizes security. I agree that given the language of the website, I would assume that there isn't a simple hack that can be installed that makes all such protected apps suddenly spring open.

    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.
  • Daniel: Using a simple / symmetric license key scheme has the problem that once cracked, all future versions of the program will be free for the user who obtained the faked/leaked serial number — unless either a) the author tracks down all “fake” serials and black-list them, or b) he (regularly) change his license scheme (which requires sending out new license keys to all existing users.)

    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.
  • Hi Allan,

    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.
  • schwa: this is why I suggested above that AP stores the public key encrypted — this should avoid the ability to blindly replace the key via some universal application.

    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.
  • Daniel: I personally am not going to make an changes to AquaticPrime interface at this point. I spend 60 hours a week programming full time for Delicious Monster, so the idea of taking my spare time to fight with crackers and bicker with other developers over the relative [in]security of my framework is not very appealing, to say the least, especially when dealing with an "unsolvable" problem like runtime patching and binary modifications. I made the entire framework open source, so if these changes are trivial, I would be happy to accept a patch from you, which I will roll into the distribution for future versions.
  • Wouldn't it be possible to embed an encrypted "test" key into the app? That way you could run the test key, make sure it shows as valid, then run the real key. If someone used the input manager crack, then the "test" key wouldn't be accepted. Then, in order to crack the app, the encryption on the "test" key would have to be broken too.
  • Forgot the other important part, there would also be a second invalid "test" key, so it would also check to make sure the invalid key was rejected. Doing this would also cover the scenario where it was modified to accept all keys.
  • Amaury
    Thank you for your work, Lucas. AquaticPrime is very clear and well documented.
    However, if this framework is not the best one, what are the alternative solutions I can use ?
    Anybody can write a state-of-art ?
blog comments powered by Disqus