Making my program have a 15 day trial, any ideas?

[penagate]

That's completely correct. It is up to the OS to ensure people cannot do that, and Windows does nothing to prevent people from examining the intricacies of applications. However hard you try, if someone tries hard enough they will crack it.

[anguswalker]

Truth of the matter is, you're going to find it very difficult to make your program completely uncrackable. A quick search of the web will result in hundreds of sites hosting cracked software from all sorts of professional companies.....At home, I work with a lot of audio software like Cubase SX, they've all gone back to USB dongles.....I hate them, but the developers at Steinberg couldn't think of a better way!

How about this. It's a bit restrictive, but is it uncrackable?:
When you launch your installer it has to connect to the internet to register the demo (or it terminates). It then writes a record to a database on a remote server, which contains a unique identifier of the machine (say the windows serial number) and the date of registration. The app can then only run if it can locate its record in the database (by connecting to the remote server) and confirm the date.

[penagate]

How about this. It's a bit restrictive, but is it uncrackable?:
When you launch your installer it has to connect to the internet to register the demo (or it terminates). It then writes a record to a database on a remote server, which contains a unique identifier of the machine (say the windows serial number) and the date of registration. The app can then only run if it can locate its record in the database (by connecting to the remote server) and confirm the date.

Could use a packet sniffer to get the response from the server and then fake it in the future, or find a check for that response in the app and zero it.

[David.Poundall]

This needs a web link though which in some circumstances wold be restrictive.

The best idea I saw in the forums once was to switch the app to demo mode if the registry authorisation was compromised. This gives the user unlimited evaluation time but they will only really be able to use the prog when it is properly licenced to the machine.

When they try to copy the ap to another machine - no problem - it kicks back in to demo mode on the new machine because you key the registry activation code to the machine.

[stilekid007]

Yea another thing I could do is just make my program and then make a seperate evaluation with restrictions on it.
Ecample:
Have some of the command buttons disabled until the registration code is entered into the textbox, and have other things disabled but still have it so they can get the idea.

It would work anyway and wouldn't be hackable. (I don't think?) lol

[Pasvorto]

I used to sell a program on Prodigy & Compuserve (how old??). Anyway, once a month I would recompile it with an expiration date that was 60 days in the future. Of course, all the user had to do was change their system date. You just have to make it enough of a nuisance that they will just pay the registreatiuon fee (in my case $15) and get a "full" version with out the cripple code. Just like locks on your door. If someone wants in bad enough, they will get in. The locks keep the honest and borderline people at bay.

[dglienna]

I'm making a avi movie to send to let them decide if they want it. They have to buy it to use it at all. That way, I hope to eliminate pirate copies.

[anguswalker]

Another idea. This is completely theoretical as I'm not a programmer and wouldn't know how to do it, but it seems reasonable:
When you get a request for the programme you send an installer which is conditionally compiled to hardcode in the date of compilation. The installer checks with its date of compilation and will not install say more than 10 days after its own compilation. The app is then similarly conditionally compiled to include its date of compilation and will only run for a set number of days after. Would that work?
The app might also have to create and check against registry keys to avoid the user changing the system date, but to be honest if someone had to change the system date every time to use the app they'd soon get fed up, wouldn't they?

[BrailleSchool]

I'm making a avi movie to send to let them decide if they want it. They have to buy it to use it at all. That way, I hope to eliminate pirate copies.

Even if people purchase the app, whats to stop them from redistributing the app to their friends, and their friends to their friends? before you know it, youll have a billion illegal copies out there

[Bruce Fox]

Another suggestion:
Instead of limiting the amount of time the app can run (eg 15 days), which as you can tell can be 'tricked'.
Publish 'trial' versions that are limited/crippled in some way. Then if the user wants all the functions/features of the app they need to purchase (the full edition).




Bruce.

[dglienna]

Even if people purchase the app, whats to stop them from redistributing the app to their friends, and their friends to their friends? before you know it, youll have a billion illegal copies out there

An emailed registration code tied to their machine

[wildcat_2000]

Could use a packet sniffer to get the response from the server and then fake it in the future, or find a check for that response in the app and zero it.

packet sniffing? naaaaaaaaa easier to just reset the check

[wildcat_2000]

few suggestions here.

1. i wouldn't recommend anything related to dates. i would, instead, limit the 'use' of it: you can start it up 50 times, for ex.

2. do not give any 'pointers' to crackers: do not have a message box stating 'hey, program unregistered!' or things like that. instead, disable buttons or hide the main screen, showing another one with this information on it.

3. cripple your messages: a text containing 'program expired' is the best way for a cracker to identify in your lines of code which part is to target.

4. cross-check multiple keys in the registry, and save some into common key locations: a key like 'My program/Key' is easily findeable and resettable.

5. pack your program: ASPack.

6. add CRC checks on file, i posted something for this here.

7. fake registration routines, it makes crackers a living hell to trace them down (i.e. put some complicated computation routines that have no scope at all).

8. do not compute your serial and compare to it directly. devide it into pieces. otherwise, a correct serial will be easily visible in memory.

9. if you feel like entering in your code with a disassembler, use a simple technique (my post here) to protect against 'live memory' patching.

10. add anti-softice tricks (even though a basic cracker can beat these in 22 seconds).

have fun

cheers,

wc.

[David.Poundall]

Wildcat, can you expand on number 9. What is anti-softice?

[wildcat_2000]

Wildcat, can you expand on number 9. What is anti-softice?

softice is a debugger, one of the main tools used by crackers to unprotect software.

it is possible to know if this tool is running in the windows environment, though letting the program defend itself. however, again, afaik these anti-softice tricks are mostly easily beateable.

for some code on anti-softice tricks you can check on Planet Source Code (site is down right now, can't give you a direct link). do not expect too much out of these. you can easily google around to find the most common softice methods and build your own trying to improve them.

[David.Poundall]

Thanks for that Wildcat

[wildcat_2000]

you're welcome!

[stilekid007]

Hey Wildcat. I appreciate all the 10 points you gave - very helpull!

Thanks buddy!

Stilekid007

[wildcat_2000]

Hey Wildcat. I appreciate all the 10 points you gave - very helpull!

Thanks buddy!

Stilekid007

you're most welcome. if you need help on implementation do not hesitate.

cheers,

wc.