Secretly tracking number of uses
Secretly tracking number of uses
I want to release an app as trial that expires after 50 uses. However,
secretly storing the number of uses has me stumped. It's too hard to
find a way to do it. Using RegShot, I can spot any changes in the Registry
or hard drive files with no effort.
What's the best way to do it? I know a crack will appear for my app, but
I still believe that "some protection is better than none at all" -- and I also
know that anyone with RegShot will defeat my trial with no crack needed.
Sometimes I wonder if a career in programming is actually worth it...
secretly storing the number of uses has me stumped. It's too hard to
find a way to do it. Using RegShot, I can spot any changes in the Registry
or hard drive files with no effort.
What's the best way to do it? I know a crack will appear for my app, but
I still believe that "some protection is better than none at all" -- and I also
know that anyone with RegShot will defeat my trial with no crack needed.
Sometimes I wonder if a career in programming is actually worth it...
-
- Enthusiast
- Posts: 499
- Joined: Wed Sep 17, 2003 9:17 pm
- Location: Southern California
- Contact:
I got a few tips... no perfect solution tho'
1) Make sure the file or registry entry that stores the number of uses is not the first one checked or the last one checked before the program decides the trial is up... That makes it easy to spot... read/write it at some random point durring the program...
2) If your program is simple and doesn't really store many settings, you may consider adding many fake settings to throw the cracker off... It's a dead giveaway if your program stores 2 numbers and one is how many uses
3) Disguise the number as something else... One way is to put it in a place where important settings are stored for the computer and the cracker might be afraid of changing them...
4) Never leave the number decrypted... it's easy to edit if it's stored as "3" or something obvious... at the very least perform some math equasion on it to make it seem more random....
5) Store the number in a secondary place/way for verification... If the cracker does figure out how to change the first number you'll know with a single conditional statement
6) Once the program determines that the maximum number of uses has been reached, It should create a file w/ random data in it... This file should be checked for BEFORE checking the number of uses each time the program starts... The cracker will have to delete this file before even attempting to crack the counter... and if it's in a system directory, the cracker will be afraid to delete it
That's all I can think of off the top of my head... I hope it helps you out a little...
1) Make sure the file or registry entry that stores the number of uses is not the first one checked or the last one checked before the program decides the trial is up... That makes it easy to spot... read/write it at some random point durring the program...
2) If your program is simple and doesn't really store many settings, you may consider adding many fake settings to throw the cracker off... It's a dead giveaway if your program stores 2 numbers and one is how many uses
3) Disguise the number as something else... One way is to put it in a place where important settings are stored for the computer and the cracker might be afraid of changing them...
4) Never leave the number decrypted... it's easy to edit if it's stored as "3" or something obvious... at the very least perform some math equasion on it to make it seem more random....
5) Store the number in a secondary place/way for verification... If the cracker does figure out how to change the first number you'll know with a single conditional statement
6) Once the program determines that the maximum number of uses has been reached, It should create a file w/ random data in it... This file should be checked for BEFORE checking the number of uses each time the program starts... The cracker will have to delete this file before even attempting to crack the counter... and if it's in a system directory, the cracker will be afraid to delete it
That's all I can think of off the top of my head... I hope it helps you out a little...
Your protection will never stop a cracker. What it can do is to make it hard for regular users to use after it has expired. Some people still don't know about cracking, keygens and such. Like my grandmother.
The most important thing, in my opinion, is to NEVER give any message when the program expires. Also, let the program fool around a while after it has decided to quit. If not, the cracker will just see what set the message or program termination message off. Some false checks may confuse a novice cracker.
In the long run I think you will just have to settle for stopping my grandmother.
Regards,
Storck
The most important thing, in my opinion, is to NEVER give any message when the program expires. Also, let the program fool around a while after it has decided to quit. If not, the cracker will just see what set the message or program termination message off. Some false checks may confuse a novice cracker.
In the long run I think you will just have to settle for stopping my grandmother.
Regards,
Storck
> Your protection will never stop a cracker.
I know.
> What it can do is to make it hard for regular users to use after it has
> expired. Some people still don't know about cracking, keygens and
> such.
That's who I want to stop, but if they use RegShot they can track which
Registry entries/files are being added/modified -- with no need for a
crack or keygen at all.
Thanks to both of you for your comments above. I've started by checking
for any windows containing "registry", "regshot", etc in the title and simply
ending my app immediately if found -- so newbies and non-crackers can't
start my app if those apps are already running. Naturally the text for these
keywords will be encrypted in my exe so they can't be changed with a hex
editor (but anyone smart can change the window titles in those apps instead).
It's going to be a challenge -- one I know that I'll lose, but I have hopes
that at least some honest users will register due to my app's timeout.
I know.
> What it can do is to make it hard for regular users to use after it has
> expired. Some people still don't know about cracking, keygens and
> such.
That's who I want to stop, but if they use RegShot they can track which
Registry entries/files are being added/modified -- with no need for a
crack or keygen at all.
Thanks to both of you for your comments above. I've started by checking
for any windows containing "registry", "regshot", etc in the title and simply
ending my app immediately if found -- so newbies and non-crackers can't
start my app if those apps are already running. Naturally the text for these
keywords will be encrypted in my exe so they can't be changed with a hex
editor (but anyone smart can change the window titles in those apps instead).
It's going to be a challenge -- one I know that I'll lose, but I have hopes
that at least some honest users will register due to my app's timeout.
-
- Enthusiast
- Posts: 499
- Joined: Wed Sep 17, 2003 9:17 pm
- Location: Southern California
- Contact:
Also look for RegMon... Titlebar = "Registry Monitor - Sysinternals: www.sysinternals.com"
it's a popular one...
or how about looking for anything with "Registry" in the title?
J/K
it's a popular one...
or how about looking for anything with "Registry" in the title?
J/K
-
- Enthusiast
- Posts: 499
- Joined: Wed Sep 17, 2003 9:17 pm
- Location: Southern California
- Contact:
-
- PureBasic Expert
- Posts: 2810
- Joined: Fri Apr 25, 2003 4:51 pm
- Location: Portugal, Lisbon
- Contact:
Yes, the less obvious way would be to read and write a pixel in an image, it would give more work to the hacker...MadMax wrote:Dunno much about these kind of things, but how about hiding this data in one of the sprites, surely this would make it quite dificult for any cracker.
Also make a dll with some functions and one of them also makes checks the CRC of the exe (Getright does this)...
Launch the read/write function has a thread, hackers hate threads, cause they make their life a real pain ...
don't give explicit names to the check variables and procedures
Checkcrc() or CRC.b, or If numberoftimes=50 ...
People in certain countries will buy your app if the like it, no matter if there are cracks.
I think that changin your app on weekly basis* (with a different algo every time) stop crackers, nobody has the patiente to build a new crack/keygen weekly.
At least it works with my applications and (Thanks God) i live from selling them.
*However you will need to release a new version weekly if you want to be on the top of the indexes on shareware sites
I think that changin your app on weekly basis* (with a different algo every time) stop crackers, nobody has the patiente to build a new crack/keygen weekly.
At least it works with my applications and (Thanks God) i live from selling them.
*However you will need to release a new version weekly if you want to be on the top of the indexes on shareware sites
ARGENTINA WORLD CHAMPION
> changin your app on weekly basis* (with a different algo every time)
> stop crackers, nobody has the patiente to build a new crack/keygen
> weekly
Yeah, I remember you said this before, and I intended to do so.
It's a good way to do it, as any existing keygens become obsolete.
You just have to remember to keep changing/uploading your app.
I was also thinking today, what would happen if the rego check was
done with ANOTHER exe, that was embedded and extracted during
runtime of the main app? It could extract to the temp folder, do the
check, and delete itself again before the cracker knew it. Sounds
like an interesting approach to me, because the actual code to be
cracked is not available in the main exe to be examined.
> stop crackers, nobody has the patiente to build a new crack/keygen
> weekly
Yeah, I remember you said this before, and I intended to do so.
It's a good way to do it, as any existing keygens become obsolete.
You just have to remember to keep changing/uploading your app.
I was also thinking today, what would happen if the rego check was
done with ANOTHER exe, that was embedded and extracted during
runtime of the main app? It could extract to the temp folder, do the
check, and delete itself again before the cracker knew it. Sounds
like an interesting approach to me, because the actual code to be
cracked is not available in the main exe to be examined.
First you would have to make sure that a program like filemon wasn't running or else it would be very obvious that a file was created.I was also thinking today, what would happen if the rego check was done with ANOTHER exe, that was embedded and extracted during
runtime of the main app?
Second, using a debugger like SoftIce or OllyDbg it would also be obvious that the code was running in another exe. It would be easy to break and copy the exe and examine it later using IDA or any other disassembler.
/ Storck