This section is a simple guide to engineering software that resists attempts to hack/crack it. This guide assumes you have chosen not to use the IronWrapping edition of SoftwareShield.  

Note that the best way - by far - to protect your software is to use IronWrapping.  If you own the IronWrap edition, and will be using IronWrapping in your software, this guide is unnecessary for you.  This is because, the protections that IronWrapping provides, when applied at maximum strength, are at least 1000 times more powerful than the techniques you could implement yourself from descriptions in this guide.

However, if you choose to not use IronWrapping, you can still achieve a modest level of protection by implementing some simple techniques inside your code along with the ClientProtector component.

The sub-section Anti-Hacker Standard Practices describes numerous standard techniques you should use to protect your software. You should be specifically aware of how to do CRC Checking since this is an important concept in protecting your software with SoftwareShield when you do not use IronWrapping. If you do not use IronWrapping, you should understand what disassemblers and debuggers do and how to resist them. The sections on Anti-Disassembling and Anti-Debugging, briefly describe various techniques you can use to accomplish this task.

The task of protecting your software from hackers is not easy. Put simply, complete and total protection - is not possible. If the hacker has access to your complete program, they can eventually break any and all protections you put in their way. This is not opinion - it is a fact. This is simply because they control the hardware at the most "intimate" level on which your program is running. As you know, a program is simply a set of instructions. Since the hacker controls the hardware on which those instructions are executed, eventually they will find the instructions in your program where your protections lie and simply change them.

Nonetheless, if we expect people and business to pay us to use our programs we must put at least some effort into protecting our programs from those who might steal from us. A simple analogy illustrates this point: You have a lock on the front-door to your home don't you? When you leave the house, do you lock it? Of course you do. Why? You lock it because you don't want people to steal your stuff. If the door was unlocked, they would walk in and rob you. But, ask yourself, if they really wanted to get in, could they? If they had a crowbar and a chain-saw of course they could, sometimes they could simply kick in the door. If you had a great deal of valuables, you might get an alarm-system or a stronger door, but again, if they really wanted to rob you - they could. Software that resists hackers is just like a home with a locked door. You must make a reasonable attempt to keep your software safe since that will "keep the honest people honest", but at the same time, do not delude yourself into a false sense of security.

Of course - all is not lost. We recommend that, in light of this knowledge and accepting the facts as they are, instead of playing "the game" of protection with the intent to "win" (to completely stop the hackers) - we play for an impasse. Since we know that a "win" is impossible, we play the "game" for the next best thing - a tie. What we mean by a "tie" is that you should engineer your protections in such a way that:

1. It is as difficult, tedious and time consuming as possible for a cracker to crack.
2. Is difficult to crack successfully or without breaking some key part of the program.
3. If cracked, can be quickly and easily changed so the crack no longer works with the current version of the software.

SoftwareShield will help you do this. When you play the game like this, you force the crackers to continually invest significant time in breaking into your software, only to find that once they have released their crack, the next day - you have made it useless. SoftwareShield is an excellent way to manage your risk exposure to crackers. However, to get the most out of the system, you have to be vigilant in your own code too. See the sections mentioned for several ideas how to effectively play the "game" in cooperation with the SoftwareShield System.