Comments on: AquaticPrime Aftermath http://toxicsoftware.com/aquaticprime-aftermath/ RANDOMIZE USR 0 Thu, 17 Dec 2009 15:12:52 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Mark Grimes http://toxicsoftware.com/aquaticprime-aftermath/comment-page-1/#comment-22059 Mark Grimes Fri, 09 Jun 2006 17:54:50 +0000 http://toxicsoftware.com/blog/aquaticprime-aftermath/#comment-22059 <p>"Any scheme accessed via Cocoa calls is vulnerable to attack via an InputManager" and<br>Public-key encryption systems may be especially vulnerable to replacement of the public key,<br>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.<br><br>I'm quite surprised you are getting such a reaction. While you've taking the time to 'prove it'<br>and point at a specific product, none of this is new. I suppose this is hush flame as we already know<br>but if you blog about it people will discover these deep dark secrets that already sit on other public<br>websites :/<br><br>I'm not watching your thread, but I'm sure it is the implementors that have banked on this scheme<br>that are seeing red as it COULD affect their financials. However I'm sure we all know that if someone<br>is going to go to the trouble to write a SIMBL/InputManager plugin to runtime circumvent your registration<br>scheme, they probably won't be ponying up for a license anyway. Most pirates take the use it for free<br>or don't use it at all mentality.<br><br>Otherwise MethodSwizzling is cool and fun :)</p> “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 :)

]]> By: Mark Grimes http://toxicsoftware.com/aquaticprime-aftermath/comment-page-1/#comment-175 Mark Grimes Fri, 09 Jun 2006 16:54:50 +0000 http://toxicsoftware.com/blog/aquaticprime-aftermath/#comment-175 <p>"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.</p> <p>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 :/</p> <p>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.</p> <p>Otherwise MethodSwizzling is cool and fun :)</p> “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 :)

]]> By: schwa http://toxicsoftware.com/aquaticprime-aftermath/comment-page-1/#comment-22058 schwa Fri, 09 Jun 2006 14:20:46 +0000 http://toxicsoftware.com/blog/aquaticprime-aftermath/#comment-22058 <p>Because after pointing out a bug in an existing system it is now obviously my responsible to create a replacement for that system.</p> Because after pointing out a bug in an existing system it is now obviously my responsible to create a replacement for that system.

]]> By: schwa http://toxicsoftware.com/aquaticprime-aftermath/comment-page-1/#comment-173 schwa Fri, 09 Jun 2006 13:20:46 +0000 http://toxicsoftware.com/blog/aquaticprime-aftermath/#comment-173 <p>Because after pointing out a bug in an existing system it is now obviously my responsible to create a replacement for that system.</p> Because after pointing out a bug in an existing system it is now obviously my responsible to create a replacement for that system.

]]> By: Some Guy http://toxicsoftware.com/aquaticprime-aftermath/comment-page-1/#comment-22057 Some Guy Fri, 09 Jun 2006 13:02:33 +0000 http://toxicsoftware.com/blog/aquaticprime-aftermath/#comment-22057 <p>Jonathon,<br><br>We all look forward to your contribution of a usable, bullet-proof, uncrackable licensing scheme <br>(with source) for shareware developers to use. After your critical analysis of Aquatic Prime, you<br>now know of at least one way that it shouldn't be done. Good luck and godspeed.</p> 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.

]]> By: Some Guy http://toxicsoftware.com/aquaticprime-aftermath/comment-page-1/#comment-172 Some Guy Fri, 09 Jun 2006 12:02:33 +0000 http://toxicsoftware.com/blog/aquaticprime-aftermath/#comment-172 <p>Jonathon,</p> <p>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.</p> 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.

]]>