I'm sure many authors who stumble across my site regard it as little more than a 'crack' repository, and with software piracy costing most authors a significant proportion of their potential revenue, I do sympathise with this point of view (in fact I am a software author myself). In the real world there is probably very little you as an author can do to prevent the really determined pirate from breaking your protection, visit http://www.dupecheck.com and you'll probably be able to find a released crack for your software (whether or not you can locate the file on the web is of course another matter).
Below you'll find a collection of protection tips, if you want more details regarding implementation drop me an e-mail. Most high level language compilers provide in-line ASM facilities.
1. Virtually all serious crackers will use SoftICE to break your protection, use the undocumented INT 3 interface between SoftICE and BoundsChecker to detect its presence (or other routines) thus halting the system, better still detect and issue a HBOOT to SoftICE. Use a parity checking routine to ensure that this detection is not tampered with and maybe set a discrete flag each time the parity routine is required, don't tell the cracker what you are doing with helpful message boxes.
2. When writing your protections functions try to avoid using very obvious names like - (Auth_Check, FindDK47). Instead frustrate crackers by using less intuitive names, further minor irritation can be achieved by using very long names with @ symbols, and never place your entire protection inside a single dll.
3. Avoid issuing helpful message boxes period, and avoid "Thanks for registering" ones as well, most legitimate users will type their serial numbers correctly first time, as an example, I give you the latest version of 3D Studio Max, very expensive software, and reverse engineered by me in under 5 minutes because of a message box.
4. Kick programs such as File Monitor and Registry Monitor, and track registered status using several registry keys (use encryption to decode them). If you decide to use a file based protection, avoid using *.ini and *.reg, use something like *.sys and *.vxd and make sure they are of credible length and name.
5. Avoid commercial *wrapper* protection schemes e.g. PreviewSoftware's TimeLock, VBox, ZipLock, Release Software Corporation's SalesAgent, Ken Nesbitt's ShareLock like the proverbial plague. All of these protections have been generically cracked, you might as well give your software away.
6. Forget about protecting using runtime-limits or 30 day trials, these are
too easy to crack, cmp eax, 1E - jg times_up. If you must
use this means have the program disable itself completely perhaps by deleting
critical files.
7. Many crackers struggle with applications written in Visual Basic and Delphi, primarily because the run-time dll's are a mass of spaghetti code which makes isolating your protection more difficult, in some cases it can make patching virtually impossible. If you must use these languages, make several checks and don't use __VbaStrCmp, hyphenated serial numbers like xxx-xxx-xxx-xxx-xxx make for painful reversing. FPU maths (FCOS, FSIN) are also effective.
8. Bore potential crackers to death with fake routines using lots of maths and fake checks. Force them to work back through your mass of SAHF's, SHL's and XOR's (all to no avail). Mix your flags, in function 1 use return 1 for good and then in function 2 use return 0 as good, this will prevent crackers from heuristically reversing jumps.
9. Save disabling your target?, don't just grey the menu item, take out the code completely and don't provide helpful documents detailing the precise specification of the file format.
10. Use encryption of any description, even just simple sliding XOR can add hours to a crackers progress. Consider using shifting tables of random characters for code calculation routines.
11. Use CRC checks to ensure that key sections of your program have not been modified, its not a good idea to CRC the entire file for performance and vulnerability reasons.
12. ...And finally, invest the money and buy a copy of SoftICE, then attempt to reverse engineer your own software. Make changes at ASM level if necessary and strengthen your protection. The longer it takes you to protect, the longer it will take a cracker to de-protect.
Whilst no protection will ever be completely cracker proof, treat software protecting like you treat your car (or any other prized possession), if you can implement enough deterrents most thieves will find an easier target.