> Plus this way if a hacker really wants to crack my app he will have to
> look at the assembly code and then distribute the crack, but this is
> definetly going to take more time than -any- user using a preference
> editor. And wait until word circulates in the newsgroups that your app
> leaves stuff behind... it's going to be a bad reputation for you.
A good app will be cracked, guaranteed. So, it's no work for someone
to just wait for the crack.
But here is what I did. I had an app that was cracked. However, I
could detect that a crack code was entered (just lucky). I also had
a database in my app. So, what I did was to design my code to detect
the crack. I made several releases with this code, that did nothing
initially.
I saved that 'detected' information in my apps database (header).
Now, sometime much later, I announced to the user that the "crack was
detected". By this time the user had a lot of data in his database.
He could delete the app and the database but now he had to reenter
all his data all over again. If he just installed the app over
again, the 'crack detected' information was still in the database.
If he then just deleted everything and reinstalled the program and
reentered the data; then registered again with the crack key, the
whole process started over. After some time passed, the crack was
detected again.
So my solution is to have a registration system that allows multiple
valid keys. Only one of which, is the one you know came from your
algorithm.
--
-----------------------------------------------------------------
Discussion Group: http://www.halcyon.com/ipscone/wwwboard/
Protect your constitutional rights. Your favorite one may be next!
-----------------------------------------------------------------
