19 comments

• 

  tony

  3 years ago

  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?
  reply
• 

  schwa

  3 years ago

  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.
  reply
• 

  Blake Seely

  3 years ago

  Dude, all those weeks and months of silence on toxicsoftware.com were worth it...
  reply
• 

  Lucas Newman

  3 years ago

  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.
  reply
• 

  Greg

  3 years ago

  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.
  reply
• 

  Zac White

  3 years ago

  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.
  reply
• 

  schwa

  3 years ago

  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.
  reply
• 

  schwa

  3 years ago

  Zac: Pirates already have a Application Enhancer haxie whose sole purpose is patching copy protection systems...
  reply
• 

  Lucas Newman

  3 years ago

  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.
  reply
• 

  Allan Odgaard

  3 years ago

  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.
  reply
• 

  R. Tyler Ballance

  3 years ago

  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 :)
  reply
• 

  Daniel Jalkut

  3 years ago

  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.
  reply
• 

  Allan Odgaard

  3 years ago

  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.
  reply
• 

  schwa

  3 years ago

  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.
  reply
• 

  Allan Odgaard

  3 years ago

  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.
  reply
• 

  Lucas Newman

  3 years ago

  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.
  reply
• 

  Justin

  3 months ago

  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.
  reply
• 

  Justin

  3 months ago

  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.
  reply
• 

  Amaury

  2 years ago

  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 ?
  reply