One of the reasons all of these applications have cracks is that the method of implementation is factored. As programmers, we like to factor our code so it's nice and neat - one or two calls provides whatever functionality we would like. The down side to this is that the crack has to modify one or two areas of the application in order to defeat the protection.
If you want decent protection, you pretty much have to write your own scheme and then de-factor it (I use includes in Delphi but macros work for C). Since most of my applications are business related, I store some of my registration information physically in the database that I am creating (which no business would willing share) and some in the EXE itself. Finally, you must have multiple calls to the defactored code spread throughout the application. For instance, if you put the defactored code in every forms OnCreate event, that is potentially hundreds of places in the code that would have to be discovered and cracked around. That leaves the only real method of cracks to be discovery of the key data. By spreading the data throughout the EXE and the data (and possibly the registry, although I personally never use the registry for anything) and having a variety of different tests, it becomes very difficult to make sure that the application is truly cracked. If you pay attention to what the crackers are really doing, they are jumping AROUND the protection or returning success. Mostly they do this by altering the EXE. A CRC is an excellent way to ensure that no one alters your EXE and that your protection scheme is in place. BTW, as far as dates go, I always use an alternative date scheme based on julian or some other arbitrary scheme that is not commonly used or known. It basically makes the dates look like any other int32. HTH, m
__________________________________________________ Delphi-Talk mailing list -> Delphi-Talk@elists.org http://www.elists.org/mailman/listinfo/delphi-talk
