Software Distribution Part 2 by Erick Tejkowsi 04-11-02 Printer Version

So you've built the perfect utility, game, or widget using REALbasic and you want to unleash it on some victims. What do you do next? Today we continue our series about the process of releasing software. This time we will discuss some of the various ways you can protect your software, should you choose to sell it.

Introduction

Today's topic is software protection. If you decide that your application is good enough that other folks might actually want to use it, perhaps they'll even be willing to send you money to do so. Welcome to the wild and woolly world of shareware and commercial software! To get those customers to send you money, though, you can't just stick your creation out in the cold, cruel world. As you probably already know, companies use a variety of methods for preventing unauthorized users from using their software product. The common school of thought here is "Why would someone pay for a product that they can use for free?" We will look at some of the software protection methods in use today. We will also briefly discuss some steps you can take to make your software "safer" from cracks and hacks, which should result in more income for you.

Easy Things You Can Do

Before we get into the discussion adding protection to your code, you should know that there are some very useful tips you should follow when releasing software to the public (usually the web, but also on CD-ROM). These steps don't require any special effort from the programmer. Rather, they are some common sense ideas that you can easily implement on your own. Think of this as the "social engineering" part of the tutorial.

• Watch out for pirates...
• Release often!
• Keep good records.
• Be vigilant!
• Test, test, test...
• Be creative!

Watch out for pirates... If you've ever visited a Hotline server or stopped by an ftp site in Russia, you are probably familiar with the underground of software piracy on the Macintosh. These servers typically provide users access to a catalog of pirated software and serial numbers. To help protect your software, it's not a bad idea to occasionally venture into this netherworld in search of hacks or cracks for your application. If you find one, change your software immediately to reduce the number of users that can take advantage of the hack. Which leads us to our next topic...

Release often! Perhaps one of the best tools to protect your software from piracy is time. By releasing updates to your software regularly, you can help yourself in several ways. First, you can take measures to quickly thwart publicly available hacks and cracks for your software. Secondly, new features bring in new customers... including those who might have already pirated your software. New features will make their older pirated versions look tame in comparison. Thirdly, frequent updates to your software increases the amount of publicity your software receives. And, finally, by releasing regularly, you can thwart hacker's attempts in the first place. It usually takes some time for pirates to "crack" your software. If a new version is out before they've had the chance to break the previous version, you win!

Keep good records. As you sell your software, keep detailed records of the serial numbers you are giving out and who registered the software. This will help you track down any "leaks" (i.e. users who have given out there serial number to a public list) you have. It's up to you how you want to handle unscrupulous users of your software, but only good record keeping can help you catch them.

Test, test, test... If you are worried about the security of your application, test it thoroughly. What might seem like the best protection scheme might have fatal flaws that cause it to be easily bypassed. The only way to catch these is to test, so do it a lot and do it often. Software is often complex with many twists and turns. Testing is your best defense for avoiding dumb mistakes. Dumb mistakes can give crackers easy access to your software, much like leaving the keys in your car door.

Be creative! Although good programming skills are helpful when creating "protected" software, often creativity will take you further. By using your creativity to protect your software, you decrease the chances that someone will be able to crack it. Pirates are no different than programmers... they're lazy. If they have to try too hard, they will often go elsewhere in search of easier victims. Creativity gives you the ability to throw in some twists that help thwart pirates. They are going to attempt to break into your software with a grab bag of standard trickery. If you do something that's not "standard", you just might trick the pirate.

Protection Schemes

As I've already mentioned, commercial and shareware products are protected with a myriad of schemes. Some of these include:

• Serial code registration
• Nagware
• Partial features
• Time-limited demo
• CD-ROM required

How you want to protect your software requires some thought. How much does the software cost? If it's inexpensive, perhaps a sophisticated protection scheme is a waste of time. What protection scheme yields the greatest number of purchases? Some people swear by so-called "nagware", whereby the user is "nagged" into buying the software, usually through a variety of friendly "reminders" (in the form of popup windows). Others find nagware offensive and prefer releasing software that has only a fraction of the features available in the full registered version. Often this is in the form of "save-disabled" applications, but other means are used. Yet others think that most customers want to try out all features of an application and thus offer time-limited demos. The application works as if it is registered, but after you've got the user "hooked", it shuts down and won't continue to work unless it is registered. If you are releasing software on CD-ROM, there are other tricks you can use. For example, you might require an authorized CD to be in the machine before your application will work. Given that most users who visit ResExcellence will distribute via the web, this is the least likely scenario you will encounter.

Conclusion

That's it for this week. As you can see, protecting software is no easy task. There are many options from which to choose, but only you can decide which is right for you. Next time we'll finally look at some source code examples that you can use to "protect" your software. I promised code this week, but plans for this tutorial changed slightly. Next week, we will look at some code. See you then!