http://toxicsoftware.com/aquaticprime-warning/ RANDOMIZE USR 0 Thu, 17 Dec 2009 15:12:52 +0000 http://wordpress.org/?v=2.9.2 hourly 1 http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-22303 Justin Wed, 18 Mar 2009 03:07:09 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-22303 <p>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.</p> 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.

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-22302 Justin Wed, 18 Mar 2009 03:05:24 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-22302 <p>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.</p> 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.

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-22252 Justin Tue, 17 Mar 2009 23:07:09 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-22252 <p>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.</p> 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.

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-22251 Justin Tue, 17 Mar 2009 23:05:24 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-22251 <p>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.</p> 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.

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-21871 Amaury Mon, 21 Aug 2006 17:36:52 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-21871 <p>Thank you for your work, Lucas. AquaticPrime is very clear and well documented.<br>However, if this framework is not the best one, what are the alternative solutions I can use ?<br>Anybody can write a state-of-art ?</p> 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 ?

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-934 Amaury Mon, 21 Aug 2006 16:36:52 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-934 <p>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 ?</p> 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 ?

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-192 Red Sweater Links » Blog Archive » Cracking AquaticPrime Wed, 14 Jun 2006 13:53:26 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-192 <p>[...] Link. [...]</p> [...] Link. [...]

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-21870 Lucas Newman Thu, 08 Jun 2006 23:06:57 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-21870 <p>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.</p> 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.

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-170 Lucas Newman Thu, 08 Jun 2006 22:06:57 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-170 <p>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.</p> 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.

]]> http://toxicsoftware.com/aquaticprime-warning/comment-page-1/#comment-21869 Allan Odgaard Thu, 08 Jun 2006 17:10:12 +0000 http://toxicsoftware.com/blog/aquaticprime-warning/#comment-21869 <p>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.<br><br>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.</p> 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.

]]>