Serial Number Politics
Volume Number: 20 (2004)
Issue Number: 11
Column Tag: Programming
Software Marketing
Serial Number Politics
by Dave Wooldridge
This month, we'll investigate the mystical world of serial numbers. If the only way for customers
to unlock your trialware is by purchasing a serial number, then crafting a secure and reliable
registration/activation system is an important step that needs to be addressed before software
licenses can be sold.
Protecting Your Software Products from Piracy
In the January issue, we explored various ways to package and protect your software for
distribution, weighing the pros and cons of demoware, trialware, installers, and disk images. In the
February and June issues, we discussed various purchase incentives and upgrade strategies. Now that
we have a defined game plan for distributing and selling our fictional software product, CodeQuiver,
we need to build the infrastructure for "unlocking" registered software.
Streamlining the Registration Process
There was a time when most Mac shareware developers simply included their own variations of the
common "Register" application with their software. This stand-alone utility would usually display a
simple order form interface, customized with the product's price and sales info. Users would fill
out the form and then choose to either submit the order electronically or print it out for mailing
or faxing. Once the order was received, the vendor would then either mail out the registered product
on floppy disk or CD, or e-mail a serial number to the customer. The Internet has come a long way
since then, allowing developers to utilize sophisticated e-commerce web applications for quickly
processing secure electronic orders, activating licenses, and issuing serial numbers. The current
generation of e-commerce solutions has empowered developers with new streamlined ways of
incorporating the purchase process directly within their software without the need for a separate
stand-alone utility. Some software products simply include a menu item for visiting their web
store's online order form, while others utilize eSellerate's Integrated eSeller technology, enabling
customers to purchase and register the software from within the application itself! Regardless of
the purchase method, consumers have come to expect quick results. Customers used to be content with
waiting 24 to 48 hours before receiving a serial number via e-mail, but in today's fast-paced world,
expectations have changed. Users assume your software can be unlocked/registered immediately upon
purchase.
If you're still generating and e-mailing individual serial numbers by hand (and you'd be
surprised how many of you are still out there), you're not only wasting your valuable time, but
you're preventing your business from growing. Manually e-mailing a serial number to a customer when
notified of their payment may not seem like much of a burden if you only receive a few orders each
day. Most of us keep our e-mail programs running on our desktop all day, so responding to a handful
of customers each week in a timely fashion seems easy enough to manage, but what happens when orders
increase to several dozen each week or even each day? If you're a single person operation, running
your shareware business out of your home, an overwhelming avalanche of sales is the kind of problem
you dream of having. But now you find yourself spending most of your days generating serial numbers
and sending e-mails, leaving little time to actually develop software and maintain the other aspects
of your business. And what if you decide to go on vacation? You can't leave your customers hanging,
waiting impatiently for two weeks for a serial number. That's just bad business. You may return from
your vacation to find a horde of angry customers demanding refunds and threatening to report you as
a fraudulent company.
It's worth the time and investment to develop your own in-house tools for generating large
volumes of serial numbers and linking individual numbers to customers. Being able to track the
serial numbers assigned to each customer will enable you to trace the origins of pirated serial
numbers as well as authenticate customers who request technical support. Having the ability to
quickly generate large quantities of unique serial numbers is also crucial when dealing with
third-party e-commerce companies and international distributors. You'll want to provide blocks of
serial numbers to these kinds of vendors, so that they can easily resell and register your product
to their customers. The importance of this will be explained throughout this article.
If you host your company site on your own web server, then you have the flexibility to build your
own custom web applications for delivering, activating, and validating serial numbers. This kind of
automated system allows your customers to place orders and immediately unlock their software around
the clock. Since your online web store caters to an international market of various time zones,
having an automated system is not only a convenience that your customers expect, it also allows you,
the developer, to finally get some sleep and take vacations without perpetually worrying about
serial numbers.
If you utilize a third-party e-commerce solution such as eSellerate, then most (if not all) of
this automated functionality is already built into their provided service. eSellerate, for example,
assigns a serial number set to each product that you add to your online catalog. This serial number
set can either be eSellerate's serial number generator, your own custom algorithm, or a block of
your own unique serial numbers that you upload to their system. eSellerate will even notify you via
e-mail when your list of serial numbers runs low, so that you can replenish the inventory with more.
With your serial number set assigned, eSellerate automatically e-mails a unique serial number to
each customer after payment has been received. And if you use eSellerate's Integrated eSeller
technology within your application, after a customer submits their billing information and the
payment is processed, a serial number is instantly sent back to the application. With very little
code, you can program your application to insert the transmitted serial number directly into the
serial number field of the registration window (see Figure 1). This integrated solution turns
software purchasing into a powerful, streamlined process. With only a few button clicks, customers
can purchase and register your software without having to leave the application. We've released a
few of our Electric Butterfly products with eSellerate's Integrated eSeller and now approximately
40% of our sales come from the Integrated eSeller (with the other 60% of orders coming from our web
store), so it is definitely a convenience our customers appreciate.
Figure 1. The registration
window for our fictional CodeQuiver product.
When designing your registration window, there are some vital components you'll want to include.
In the registration window of our fictional CodeQuiver product (see Figure 1), the "Purchase" button
is set as the default, informing the user that this is the first step. As previously described, you
may choose to program the "Purchase" button to either launch an Integrated eSeller for purchasing
the software directly within the application (if you use eSellerate) or to simply direct the user to
your web store's online order form (via the default web browser). If using an Integrated eSeller, a
successful payment returns a unique serial number which your application can intelligently display
in the serial number field and then assign the "Register" button as the default. Whether the serial
number is dynamically inserted into the registration window or the customer manually copies and
pastes it from a confirmation e-mail, it's a good idea to require customers to submit their full
name with the serial number in order to complete the registration process. Many software companies
require an online connection in order to register, so that the user's name and serial number can be
authenticated by an online server application. By "phoning home" during the registration process, it
gives software companies the opportunity to check new registrations for pirated serial numbers
(using their own "blacklists" for comparison). There are some developers who object to this
strategy, so whether your software actually "phones home" or not, requiring users to submit their
full name with the serial number will still make some casual pirates think twice before clicking the
"Register" button.
For shareware and trialware products, the registration window usually appears every time the
unregistered application is launched, so you'll want the window to include some brief information
about how the trial is crippled or time-limited and how purchasing a license removes the demo mode.
Since your goal is to inspire them to buy the product, take the time to design an elegant
registration window. Figure 1 includes CodeQuiver's logo and key art in an effort to "beautify" the
window with a little extra polish.
Creating Your Own Algorithm
Even though some e-commerce solutions such as eSellerate provide their own services for
generating and activating serial numbers, there are drawbacks to using third-party serial numbers.
One disadvantage is that some third-party serial number generators do not allow you to add your own
reference keys to differentiate between product names and version numbers. Including special
identifiers in your serial numbers can be helpful when processing customer service requests. The
most serious drawback is that in many cases, it ties your sales to a single e-commerce vendor. For
example, eSellerate needs to process the sale in order to generate and activate an eSellerate serial
number. For shareware developers and hobbyists who do not plan to ever localize their software in
other languages, this may not be an issue. But if you eventually want to localize your software and
utilize international distributors to sell your software in other countries, then you'll definitely
want to use your own serial number system. The reason is that you'll need to provide a block of
serial numbers to each international distributor because they usually handle not only the sale, but
also registration and customer support for your product in their native language - a turn-key
service you will greatly appreciate (unless you speak eight different languages and require no
sleep). By utilizing your own serial number system, you can easily generate unique blocks of serial
numbers for your third-party e-commerce vendor (such as eSellerate), regional resellers, and
international distributors.
So you've spent hours slaving over your serial number algorithm, adding enough complexity to
stump even the most dedicated cracker? Before you pat yourself on the back, make sure your
programming code accounts for the following issues:
- Do not hard-code serial numbers into your application. Crackers and even a decent
handful of casual pirates know how to scan your application's binary executable for serial number
strings. Simply open the application in a resource editor or text editor (like BBEdit) and all of
your application's string resources are viewable, embedded within the garbled byte code. Instead,
include an algorithm in your application that can "decode" and validate serial numbers.
- Obfuscate or "Munge" decoder key strings. Like the old-fashioned decoder rings, many serial
number algorithms utilize a defined string of alphanumeric characters as a key that is used in the
algorithm to encode and decode the numeric sequences used in the serial numbers. If a cracker can
find your decoder key string by scanning your application's binary executable with a resource or
text editor, then he/she may be able to crack your algorithm if the key is compared with three or
more pirated serial numbers. It's bad enough when you have to blacklist a few stolen serial numbers,
but the worst case scenario is when crackers figure out how to emulate your serial number algorithm.
This would enable them to generate their own endless supply of illegal serial numbers, leaving your
current software version completely vulnerable to misuse. Do what you can to avoid this problem by
obfuscating your decoder key or any other related strings that might expose your algorithm. Scramble
and reassemble the strings in code or use an encoder such as Base64 that will "hide" the string from
prying eyes without requiring too much extra programming effort for your algorithm to then decode
the strings at runtime.
- Every serial number should be unique. Think long-term and design a format that allows you to
generate at least one million unique serial numbers. While this number may seem wildly optimistic,
don't limit the rationale to only sales. Between blacklisting pirated serial numbers and generating
large blocks of serials for resellers and international distributors, you'll go through serial
numbers faster than you think. Remember, running out of serial numbers may force you to release a
new version of your software with a revised serial number algorithm, which is extremely inconvenient
for both you and your customers.
- Think like a hacker. When designing your serial number format, examine your scheme from a
cracker's point of view. If it seems like a format that might be easy to crack, then it probably is.
When comparing three or more serial numbers, do any patterns easily emerge? Is your algorithm doing
nothing more than using a common encoder to "hide" the real values in your serial numbers? For
example, some developers generate serial numbers by converting the real values into ASCII character
codes. While this may produce an interesting number-based serial, don't think that won't be one of
the first things crackers try. ASCII character codes are commonly used in serial number tutorials,
so to employ such a simplistic approach is like putting a red target on your back. Be creative.
- Integrating customer data into serial numbers. In an attempt to curb piracy, many software
companies infuse the customer's name, e-mail address or last four credit card digits into the serial
number. The theory is if customers' personal data are embedded in the serial numbers, they will be
less likely to share the serial numbers with others for fear of it being traced back to them. If you
choose to employ such a tactic, do not use the customer's name (unless you encrypt in some way).
Your web store is a global business, so your customers' names may include accentuated Unicode
characters that may not be easily deciphered by your serial number algorithm. And even if your
algorithm can handle Unicode characters, customers may accidentally corrupt the string when copying
and pasting it from their confirmation e-mail to your application's registration window. Stick with
ASCII-based characters. E-mail addresses are unique and safe to use. The last four digits of the
customer's credit card are easy enough to embed into the serial number, but without the rest of the
card number, the four digits would not be unique or useful as an identifier. And even though it is
only the last four digits, you would surely encounter complaints from customers who are
uncomfortable with your unorthodox use of their credit card number.
- Avoid using dates or decimals. By making your software available to the global community,
you cannot depend on dates or decimals to be represented the same way. In the U.S. the month comes
before the day, but in many countries, the day comes before the month. March 30, 2004 is often
displayed as 30 March 2004. More importantly, decimals are not always represented with a period.
Some countries use commas. So your software version number in integer form may display as 1.5 in the
U.S. and 1,5 in Germany. You can certainly integrate dates and version numbers into your serial
numbers as long as your code properly manipulates the month, day, year, and version properties with
these pitfalls in mind.
- Some letters can be confusing for customers. There are good reasons to include letters in
your serial numbers, but be aware that certain letters may cause problems for customers. An upper
case "I" and a lower case "l" are often mistaken as the number one. And depending on the display
font, an upper case "O" looks just like a zero (see Figure 2, Item 6). If customers type a number
instead of the right letter, your software will continue to tell them that the submitted serial
number is incorrect and you'll be forced to deal with unnecessary customer support requests.
- Using special identifiers. You may have noticed that many software companies use identifier
letters in the beginning or end of their serial numbers. These letter codes are helpful when
receiving customer support requests and when tracking piracy origins. Figure 2 shows an example of
some reference keys that are commonly used: (1) company initials, (2) product initials, (3) version
number without decimals, (4) operating system platform identifier M/W/L/P, and (5) international
distributor initials such as DE for Germany, JP for Japan, US for United States, etc. There is no
standard for these identifiers, so design a format that works for your specific needs, but be sure
to anticipate long-term goals. For example, you may not utilize international distributors now, but
using a regional identifier may prove handy when your operation expands in the future.
Figure 2. Using identifiers
in your serial numbers will help you track piracy origins as well as where specific product versions
were purchased.
Battling Piracy
While you should do what you can to make your serial number format and algorithm as difficult to
crack as possible, the unfortunate truth is that most of your piracy issues will stem not from
cracked code, but from stolen serial numbers that are posted online. With so many illegal warz sites
and newsgroups available, it's all too easy for users to find pirated serial numbers. The irony is
that many of the users who find pirated serials online would probably buy your software otherwise,
but the opportunity to save money often outweighs the moral conflict in their mind. Sure, you could
send "cease and desist" letters to those warz sites and their ISPs, but how do you stop the
consumers who are already using the pirated serials with your software? Many software companies have
found the answer in blacklists.
If you're unfamiliar with the term, a blacklist is usually a database of known pirated serial
numbers. If you find your software is prone to piracy, then it may be in your best interest to
maintain your own blacklist for each product you release. Every time you find a pirated serial
number on the various warz sites (and you should check them often) or receive a tech support request
or registration activation with a pirated serial, you should add it to your blacklist.
A blacklist database is most effective when you actively use it to authenticate submitted
registrations and customer support requests. Earlier, we discussed applications that "phone home" to
a web server during the registration process. This method is effective in stopping most casual
pirates since it checks to see if the submitted serial number is currently in the blacklist
database. If there's no match and the serial number is valid, then registration is successfully
completed. If the server app reports a blacklist match, then your software can cancel the
registration process, informing the user that the serial number is invalid and to contact customer
service for assistance. The message should not indicate that the serial is pirated, since there's a
slim possibility that the user accidentally mistyped the serial number and it coincidentally matches
a pirated one. Granted, the odds of this happening are probably miniscule, but all customers should
be treated as innocent until proven guilty. Instead of condemning them, give them the opportunity to
do the right thing and purchase a legitimate license.
Authenticating the serial number online is completely acceptable during the registration process,
but since consumers are usually wary of information being sent online, be sure to inform them with a
message that tells them why the application needs to establish an online connection and exactly what
data is being transmitted. Do not perform this kind of check every time the user runs your software
- it will only make your honest customers feel like criminals.
It's a good practice to require customers to submit their serial number and full name with all
customer support requests. This way you can check the serial numbers against your blacklist database
for possible matches. No sense wasting your time fielding tech support queries of illegal users. And
if you haven't experienced it already, you'll be surprised at just how many pirates have the gall to
demand tech support help.
If you're primarily worried about inter-office use of the same serial number among multiple
employees, it can be beneficial to make your software network-aware. Upon start-up, your application
can silently poll the network for other copies of itself and check for duplicate serial numbers. If
matches are found, the application can politely inform the user that the registered serial number is
already in use by another copy on the network and present a choice of two buttons: a "Quit" button
and a convenient "Purchase" button to order additional licenses.
Some software companies go a step further by limiting the number of times a particular
application can be activated. While this can help curb the sharing of serial numbers among
co-workers and friends, it can be extremely annoying for those customers who continually upgrade
their computers and operating systems. They are still using the same product on only one computer,
but upgrading to the next operating system release every six months often requires software to be
reinstalled (especially since many users opt for a clean install of each new OS release). So if an
honest customer upgraded to OS X Jaguar and then soon after, upgraded to OS X Panther, your imposed
three-time limit on product activations is quickly exceeded and the customer is now forced to waste
precious time contacting customer service for help.
The same consumer frustration occurs with other anti-piracy methods like expiring serial numbers
that need to be renewed once or twice a year. Whatever copy-protection scheme you employ with your
software, try to imagine how it will affect your customer relationships. You want to protect your
software without annoying your honest customers who have rewarded you with their license payments
and continued loyalty. Your customers' experience should never suffer due to a handful of
unscrupulous pirates, so try to keep a conscious balance between defensive programming and
ease-of-use.
Dave Wooldridge is the founder of Electric Butterfly (www.ebutterfly.com), the web design and software company
responsible for HelpLogic, Stimulus, UniHelp, and the popular developer site, RBGarage.com.