Time-limited programs try to ensure that a program will not be used once the trial period has expired. This is not usually a very effective method of protection, though, because once the time limit is cracked, the entire program is available to the cracker. It is much better to disable some functions in a program's unregistered version, thus forcing the user to buy the registered version if they want to use all of the program's features. Time-limits are implemented in various ways. The various possibilities are: • The time limit is removed once the correct registration number is entered. Time Limit Is Removed Once the Correct Registration Number Is Entered This approach has the same problem as registration-number techniques. The only difference is that if the correct registration number isn't entered, the program will not be registered, and it will refuse to run after a certain period of time. When adopting this approach, the quality of the registration number must be high, since crackers do not focus on the time limit when removing this protection. Your program should use only a simple check when testing to see how long the program will be allowed to run. The program might, for example, detect a date during its first use and write that date into registers or a file. The program could then check after each start to see whether the time limit has been exceeded and, if so, refuse to run. Time Limit Is Removed Once a Registration Key File (.REG) Is Entered This is a wonderful type of protection that isn't used very often. When using this protection, you might consider sending the registration file via the Internet. The registration file could, for example, contain a substantial part of the program code, which would unblock the time limit. But beware: Crackers will focus on the routine that tests whether the time limit has already expired, so you must secure this routine against an attack. A cracker will rarely create a correct registration file to counter this protection because it is rather difficult to do so; it's much easier for him to cancel the time limit right in the program. Do not use a checking method that tests to see whether a registration file is in the program directory and whether it contains correct data. It is much more effective to place the protected application's code right into the registration file. Of course, this isn't easy to do, and it's a method reserved for good programmers only. Should you decide to use this type of protection, take the time to carefully test the result and make sure that the time limit test is as inconspicuous as possible. Consider using several separate tests together that will cause errors if the protection is not removed correctly . (Many antivirus programs use this kind of protection) And, as is often the case, it is a good idea to combine this protection with other types. Time Limit Cannot Be Removed; User Must Buy the Full Program Program demos often use this type of protection, which prevents the program from being starting once the time limit expires. There is no registration code to be entered. Crackers who encounter this type of protection will probably focus on the routine that checks to see whether the time limit has expired, and they may make a direct change to that program code. As such, it is a good idea to add a protective program that checks the file's checksum; it is important to protect the routine that tests the time limit. One approach is to use several separate tests together that will cause errors once the protection has been removed, and to combine them with other types of protection. Time Limit Is Contained in a Visual Basic Program This kind of protection isn't widely used, and it's also not popular among crackers because it is difficult to remove. As was mentioned earlier in the discussion of registration numbers, a VB program is hard to trace (or nearly impossible if it's a VB4 program) and it is hard to understand. Note If your program prints a message once the time limit expires, you will make the cracker's job easier. The more experienced crackers will overcome this type of protection easily, since the method used doesn't vary much. As with other methods, it's a good idea to use several separate, interwoven tests. For example, if the first test is removed, the program might use a hidden test after, say, ten minutes to check whether the time limit has expired, and, if so, close without warning. It is extremely difficult to locate this kind of protection—if the protection has been made well, it is a very time-consuming job. As always, it's a good idea to combine this method with other protection methods. Time Limit Applies to a Certain Number of Starts This is basically the same as other time-limit methods, except that it limits the number of starts rather than a number of days. This can create many problems for a cracker, since the program doesn't have to detect a date but just has to save the actual number of runs somewhere (in registers or a file). Otherwise, the issues are generally the same as those for other time limits.
|
|||||||||||||
Disclaimer
1) E-articles is not responsible for the information contained by this article as well for any and all copyright infringements by authors and writers. E-articles is a free information resource. If you suspect this article for any copyright infringement, please read the terms of service and contact us or use the "Report this article" button on this page to investigate the problem.
2) E-articles is not responsible for inaccuracies, falsehoods, or any other types of misinformation this article may contain and will not be liable for any loss or damage suffered by a user through the user's reliance on the information gained here. |
|||||||||||||