toxicsoftware.com

RANDOMIZE USR 0

toxicsoftware.com header image 2

AquaticPrime Aftermath

June 8th, 2006 · Comments · Default

Well it turned out that my posting yesterday caused quite a storm in a teacup. The macsb mailing list has probably seen more activity in a day that it does in a month.

I’ve learnt quite a few things from this:

AquaticPrime works just as intended. The flaw I highlighted yesterday isn’t a flaw because AquaticPrime wasn’t designed to defeat attacks of the kind described. Although nowhere on the AquaticPrime website or inside the documentation will you find any of this discussed. We can generously put this down to an innocent omission.

Even though this isn’t a flaw it seems great efforts are made in people’s code to prevent runtime attacks. Remember, it isn’t a flaw, it is a design decision.

Paradoxically, even though my posting failed to identify a flaw in AquaticPrime (so no harm done right?), several people are rather quite angry that I have discussed it in the open. Apparently openly criticising open source software is not allowed. In fact I have been called some very nasty names from one particular AquaticPrime supporter over this.

It seems that some developers have given up the fight with pirates over runtime/binary attacks. Granted this is a really tough fight to fight, but i find it very interesting that the recommended tactic is to just give up. I think this is wildly underestimating pirates and especially the more casual pirates. The argument seems to be that the casual pirates will not bother finding/installing/running runtime cracks. And that spending effort trying to defeat the hardcore pirate is a waste of time.

However, with all the file sharing sites/software available to anyone today, casual pirates will be able to find cracks rather easily. And casual pirates probably won’t have any problems running these cracks on their machines (after all they’re probably already running keygens for their stolen Adobe software). Giving this fight up seems to be giving up a little too easily.

So finally be really careful when claiming that the “emperor has no clothes”. Such claims will never be received in a positive manner, regardless of whether the emperor is indeed stark naked or in fact wearing the latest, most advanced, invisible wardrobe.

Tags: ···

  • Some Guy
    Jonathon,

    We all look forward to your contribution of a usable, bullet-proof, uncrackable licensing scheme
    (with source) for shareware developers to use. After your critical analysis of Aquatic Prime, you
    now know of at least one way that it shouldn't be done. Good luck and godspeed.
  • Because after pointing out a bug in an existing system it is now obviously my responsible to create a replacement for that system.
  • Mark Grimes
    "Any scheme accessed via Cocoa calls is vulnerable to attack via an InputManager" and
    Public-key encryption systems may be especially vulnerable to replacement of the public key,
    unless it is obfuscated throughout the entire app" which are clearly documented in discussion on CocoaDev:MakingSecureRegistrationCodes shouldn't be the first time these guys have heard this.

    I'm quite surprised you are getting such a reaction. While you've taking the time to 'prove it'
    and point at a specific product, none of this is new. I suppose this is hush flame as we already know
    but if you blog about it people will discover these deep dark secrets that already sit on other public
    websites :/

    I'm not watching your thread, but I'm sure it is the implementors that have banked on this scheme
    that are seeing red as it COULD affect their financials. However I'm sure we all know that if someone
    is going to go to the trouble to write a SIMBL/InputManager plugin to runtime circumvent your registration
    scheme, they probably won't be ponying up for a license anyway. Most pirates take the use it for free
    or don't use it at all mentality.

    Otherwise MethodSwizzling is cool and fun :)
blog comments powered by Disqus