For me, programming is usually a creative process. Unless I am fixing small bugs or making minor tweaks, writing software is no different from writing a story, a song, a poem, or drawing a picture. It is an abstract process by which I turn general ideas into something that doesn’t quite approach a true language. There is a purely creative process: coming up with ideas to implement. And there is a less creative, but often just as abstract a process: turning those ideas into little processes that a compiler can understand.

Since writing code is so much like writing anything else, a programmer is prone to “programmer’s block” just as an author of a novel can be afflicted with writer’s block.

Beating programmer’s block while simultaneously staying productive is something easily done as long as you keep these things in mind:

• When you’re stuck, do something else.
• It’s easy to do something else if you have more than one project.

It’s really that simple, at least for me. At any given time I have at least a half-dozen “things” I can do that constitute productive behavior.  If I experience programmer’s block when developing one application, I have several others I can go work on for a while. Or, I can write a blog entry or even read a business-related book.

The key is to have more than one thing to do at any given time, so that when project A gets stuck, you can go work on project B for a while.  It’s not hard. And for me, the goal is to take a break without becomming idle.  Sure, vacations and long-term breaks have their place, but with all those people on welfare counting on my taxes, I just can’t relax when I am truly doing nothing so I always have something else I can do when I hit a wall.

Frankly, I am amazed this doesn’t happen more often. This reminds me of a book I recently read called The Limits of Software. Anyone who is curious about why computers and software so frequently don’t work properly would benefit from reading it.

The Limits of Software is a sort of docu-drama in book form about the massive failed attempt at upgrading the Federal Aviation Administration’s ancient computer systems. The event is a case-study proving that all the money in the world can’t make the impossible happen. But since the government can just spend, spend, spend, they sure did give the impossible a try. I highly recommend this book for programmers or anyone who wants to understand what kind of problems programmers are always trying to solve.

What it all boils down to is that software is a means of describing abstract human thought for computers to understand and implement in reality. It will never be perfect.

No consolation for the 8,000 poor folks stranded in LAX, I know.

There are several possible solutions to this problem. You could license a system like Armadillo/Software Passport or ASProtect, or you could distribute a separate full version as a download for your paying customers. Each option has advantages and disadvantages. What I am going to show you is a way to keep “rolling your own” license key system while making working cracks harder for crackers to produce, and working keygens a thing of the past.

Aside: If you think it’s crazy to post this publicly where crackers can see it, don’t worry about that. I’m not posting anything they haven’t seen before. The entire point of partial key verification is that your code never includes enough information to reverse engineer a key generation algorithm. Also, I offer no warranty of any kind — this is for your information only! Now, on with things.

Our license key system must meet some basic requirements.

1. License keys must be easy enough to type in.
2. We must be able to blacklist (revoke) a license key in the case of chargebacks or purchases with stolen credit cards.
3. No “phoning home” to test keys.  Although this practice is becoming more and more prevalent, I still do not appreciate it as a user, so will not ask my users to put up with it.
4. It should not be possible for a cracker to disassemble our released application and produce a working “keygen” from it. This means that our application will not fully test a key for verification. Only some of the key is to be tested. Further, each release of the application should test a different portion of the key, so that a phony key based on an earlier release will not work on a later release of our software.
5. Important: it should not be possible for a legitimate user to accidentally type in an invalid key that will appear to work but fail on a future version due to a typographical error.

The solution is called a Partial Key Verification System because your software never tests the full key. Since your application does not include the code to test every portion of the key, it is impossible for a cracker to build a working valid key generator just by disassembling your executable code.

This system is not a way to prevent cracks entirely. It will still be possible for a cracker to edit your executable to jump over verification code. But such cracks only work on one specific release, and I’ll suggest a couple of tricks to make their job harder to complete successfully.

Let’s jump right in.  I’ll show you the system with Delphi code. (Given the readable nature of Delphi Pascal, you should be able to use these examples to build your own system in any language.)

An aside: if you think it’s crazy to post this publicly where crackers can see it, don’t worry! I’m not posting anything they don’t know. The whole point of this system is that your code never contains enough information for a cracker to reverse-engineer your key system. My blog post here doesn’t give them any information they don’t already have. Also, I’m not offering any kind of warranty with this information. This is for your information only, and all that. Now, on with things!

1. The Key Format

This example will create and test keys of 20 characters (with hyphens added for user convenience). A valid key will look like this:
A279-1717-7D7A-CA2E-7154

Once the hyphens are stripped, this is how the key breaks down:

This sample system only uses four bytes for key verification, but a real system should use many more and larger values, so keep that in mind if you begin implementing your own PKVS.

2. The Seed Value

This sample system uses a 64-bit integer as a “seed” to generate the “Key Bytes” from.  The example project just generates random values for seeds, but when you implement a system like this, you must ensure that the seeds are always unique, because the seed is used when blacklisting a key. The seed could itself be a hash of a user name and time of generation, or any number of things

3. Computing Key Bytes

Here is the heart of the PKVS. Each “byte” of the key is a result of an operation on the seed value.  Here is a simple “byte” value computation function. It performs some bit twiddling based on the supplied parameters:

function PKV_GetKeyByte(const Seed : Int64; a, b, c : Byte) : Byte;
begin
  a := a mod 25;
  b := b mod 3;

  if a mod 2 = 0 then
    result := ((Seed shr a) and $000000FF) xor ((Seed shr b) or c)
  else
    result := ((Seed shr a) and $000000FF) xor ((Seed shr b) and c);
end;

We’ll see in a moment how this function is used in the key generation and checking algorithms. Please keep in mind that this example function is very simplistic. A more effective function would use larger values than bytes and employ a more complex hashing system.

4. We need a checksum

Once we have our seed and bytes formed into a string of characters, we need to add a checksum to it. This way we can know when a user makes a mistake entering their key, without having to actually check each portion of the key for validity.

function PKV_GetChecksum(const s : String) : String;

var
  left, right, sum : Word;
  i : Integer;
begin
  left := $0056;
  right := $00AF;

  if Length(s) > 0 then
    for i := 1 to Length(s) do
    begin
      right := right + Byte(s[i]);
      if right > $00FF then
        Dec(right, $00FF);
      Inc(left, right);
      if left > $00FF then
        Dec(left, $00FF);
    end;

  sum := (left shl 8) + right;
  result := IntToHex(sum, 4);
end;

This function computes a simple 8-bit value from the supplied string and returns it as a hexidecimal string, which we tack on to the end of our key.

Note that because this routine is always used to check a key in your application, a would-be keygen coder will be able to generate keys that pass the checksum test.  That’s okay.  The point of the checksum is only to prevent your users from mistyping their own valid license keys, and it will aid in determining if a key was deliberately forged.

5. Putting it together: generating a valid key

For our key generation program, we’re going to need a single function we can call to get a license key string from a seed value. Here it is:

function PKV_MakeKey(const Seed : Int64) : String;
var
  KeyBytes : array[0..3] of Byte;
  i : Integer;
begin
  // Fill KeyBytes with values derived from Seed.
  // The parameters used here must be extactly the same
  // as the ones used in the PKV_CheckKey function.
  // A real key system should use more than four bytes.

  KeyBytes[0] := PKV_GetKeyByte(Seed, 24, 3, 200);
  KeyBytes[1] := PKV_GetKeyByte(Seed, 10, 0, 56);
  KeyBytes[2] := PKV_GetKeyByte(Seed, 1, 2, 91);
  KeyBytes[3] := PKV_GetKeyByte(Seed, 7, 1, 100);

   // the key string begins with a hexidecimal string of the seed
  result := IntToHex(Seed, 8); 

  // then is followed by hexidecimal strings of each byte in the key
  for i := 0 to 3 do
    result := result + IntToHex(KeyBytes[i], 2);

  // add checksum to key string
  result := result + PKV_GetChecksum(result);

  // Add some hyphens to make it easier to type
  i := Length(result) - 3;
  while (i > 1) do
  begin
    Insert('-', result, i);
    Dec(i, 4);
  end;
end;

Important: never compile this valid key generator function into your release application! It is only to be used on your end to generate valid keys. The success of a PKVS is based on keeping the parameters used in the PKV_GetKeyByte call secret and away from the prying eyes of crackers.  Remember: if it’s in your compiled executable, a cracker can see it!

6. Testing a key in your application

Your application needs two functions for testing a key.

The first is a function for testing only the checksum value.  You’ll use this to test the key when a user types it in.  To make it harder for a cracker, this is all you want to test at first. More on this later.

The second function actually verifies portions of the key to see if they are valid, and also checks against the blacklist to see if a key should be rejected based on its seed value.

First we need to define the constants:

const
  KEY_GOOD = 0;
  KEY_INVALID = 1;
  KEY_BLACKLISTED = 2;
  KEY_PHONY = 3; 

  BL : array[0..0] of String = (
                                '11111111'
                               );

Above, BL is an array of blacklist strings. Important: only include the seed portion. Remember: if you put it in your program, a cracker can see it.  So do not put an entire key in the blacklist. That just makes it easier for a cracker to see what a valid key should look like.

Here is the checksum check function:

function PKV_CheckKeyChecksum(const Key : String) : Boolean;
var
  s, c : String;
begin
  result := False;

  // remove cosmetic hypens and normalize case
  s := UpperCase(StringReplace(Key, '-', '', [rfReplaceAll]));
  if Length(s) <> 20 then
    exit; // Our keys are always 20 characters long

  // last four characters are the checksum
  c := Copy(s, 17, 4);
  SetLength(s, 16);

  // compare the supplied checksum against the real checksum for
  // the key string.
  result := c = PKV_GetChecksum(s);
end;

And finally, we come to the function that tests keys for validity. In the sample code, I am using conditional defines to allow me to easily exclude “key bytes” from the checking function, but you could just as easily comment them out.  My advice is to only include one or two checks in a release, and to change which ones are checked for each release. Again, our example only has four “check bytes” but you should use many more.

function PKV_CheckKey(const S : String) : Integer;
var
  Key, kb : String;
  Seed : Int64;
  i : Integer;
  b : Byte;
begin
  result := KEY_INVALID;
  if not PKV_CheckKeyChecksum(S) then
    exit; // bad checksum or wrong number of characters

  // remove cosmetic hypens and normalize case
  Key := UpperCase(StringReplace(S, '-', '', [rfReplaceAll]));

  // test against blacklist
  if Length(BL) > 0 then
    for i := Low(BL) to High(BL) do
      if StartsStr(BL[i], Key) then
      begin
        result := KEY_BLACKLISTED;
        exit;
      end;

  // At this point, the key is either valid or forged,
  // because a forged key can have a valid checksum.
  // We now test the "bytes" of the key to determine if it is
  // actually valid.

  // When building your release application, use conditional defines
  // or comment out most of the byte checks!  This is the heart
  // of the partial key verification system. By not compiling in
  // each check, there is no way for someone to build a keygen that
  // will produce valid keys.  If an invalid keygen is released, you
  // simply change which byte checks are compiled in, and any serial
  // number built with the fake keygen no longer works.

  // Note that the parameters used for PKV_GetKeyByte calls MUST
  // MATCH the values that PKV_MakeKey uses to make the key in the
  // first place!

  result := KEY_PHONY;

  // extract the Seed from the supplied key string
  if not TryStrToInt64('$' + Copy(Key, 1, 8), Seed) then
    exit; 

  {$IFDEF KEY00}
  kb := Copy(Key, 9, 2);
  b := PKV_GetKeyByte(Seed, 24, 3, 200);
  if kb <> IntToHex(b, 2) then
    exit;
  {$ENDIF}

  {$IFDEF KEY01}
  kb := Copy(Key, 11, 2);
  b := PKV_GetKeyByte(Seed, 10, 0, 56);
  if kb <> IntToHex(b, 2) then
    exit;

  {$ENDIF}

  {$IFDEF KEY02}
  kb := Copy(Key, 13, 2);
  b := PKV_GetKeyByte(Seed, 1, 2, 91);
  if kb <> IntToHex(b, 2) then
    exit;
  {$ENDIF} 

  {$IFDEF KEY03}
  kb := Copy(Key, 15, 2);
  b := PKV_GetKeyByte(Seed, 7, 1, 100);
  if kb <> IntToHex(b, 2) then
    exit;
  {$ENDIF} 

  // If we get this far, then it means the key is either good, or was made
  // with a keygen derived from "this" release.

  result := KEY_GOOD;
end;

6. Making it harder for crackers

So far you have the tools you need to make a license key system that is virtually impervious to being “keygenned,” as far as valid keys go.  It is still possible for a cracker to alter your executable to skip key verification, and a cracker will still be able to create a keygen that works for whatever version of your application he has.  So what else is there to do?

1. The first step I suggest is inlining the PKV_GetKeyByte, PKV_GetChecksum, PKV_CheckKeyChecksum, and PKV_CheckKey functions. Recent versions of Delphi support the inline compiler directive that forces the compiler to “unroll” the function in-place rather than actually make a function call. This results in larger code, but also gives the cracker that many more places to examine while he is dissecting your executable. It also prevents him from finding the single entry point for PKV_CheckKey and making it always return KEY_GOOD.
2. When your application tests the stored key at startup, and when the user enters the key, only check the checksum. If your program immediately goes into its “key byte” verification code when it starts up or when the key is entered by the user, it’s just asking the cracker to watch carefully and see how it’s done!Just verify the checksum first, and give a polite error message if it is invalid (remember, this is where your customer is putting in his key that he gave you money for!). Elsewhere in your code, sprinkle the real checks into various operations.  User clicks File>Save? There’s a good time to really check the key, instead of just the checksum. Perhaps set up a timer and check it a full minute after the code is entered.  The possibilities are endless, and any unique ideas you come up with will make your program that much more tedious for a cracker to work on.  Crackers have lots of programs to fool around with, and if yours gets to be too frustrating, they may get sloppy and release only a partially working crack, or skip your application altogether.
3. Keep on top of cracks, phony keygens, and leaked keys. Even though it isn’t possible for a cracker to create a fully valid key based on what you compiled into your program, he can (and probably will) release a keygen that works with whatever version he downloaded.  Set up a Google Alert for “Your_program keygen serial crack” and when one is released, immediately change which “key bytes” your program checks, or add the leaked key to the blacklist, and recompile. Suddenly none of the keys, keygens, and cracks released work anymore. Also, do a “silent” update of your download file when you are just recompiling for this reason. No need to announce to the cracker that their keygen suddenly doesn’t work any more.

7. Further development

This PKVS example is very simple in its implementation. There are several things that could be added to make it more powerful.

1. Replace PKV_GetKeyByte with a more robust version. There are many hashing algorithms available that can be used as a starting point for calculating the portions of your key used to determine if it is valid.  Using the sample function presented here would be a mistake as it could be reverse engineered with valid leaked keys and brute-force algorithms.
2. Instead of using hexidecimal, use the entire alphabet. This will let you pack a lot more data into the key string without making it too long. Note that the comparisons and byte generation checks in this example will have to be re-written to work with any other base numbering system.
3. The example implementation is a simple “serial number” system and does not tie the key to a user name or other information. However, it would be trivial to make the seed itself a checksum value of another string, such as the user’s name.
4. Anything could be added to the key string. You could add additional values to store activation or expiration dates, for example.
5. Your key generation system should maintain a database of issued keys. You should always test your key check function against every key you have issued.  Also, keep a database of blacklisted or leaked keys, and always test your check function against them to ensure it returns the expected results.

Concluding remarks

Whatever you do, don’t focus all of your energy on your licensing system.  It is important, but creating usable software that customers need is more important. A good license key system will certainly improve your sales, but you can’t hope to convert every one searching for “MyProgram Serialz” into a customer.  A system like the one described here can be implemented in a day or two, but constantly trying to outsmart crackers is a never-ending battle.

Here’s an interesting book if you’re curious about how successful technology companies get started: Founders at Work: Stories of Startups’ Early Days by Jessica Livingston.

Founders at Work is a collection of interviews with 32 people who started, or helped start, super-successful companies like Adobe, TiVo, Blogger, Yahoo!, and more. It also includes interviews with people who founded not-very-successful-but-made-the-founders-super-rich companies, like Hotmail and Lycos. (Yes, I know, some people will disagree with me about those companies not being successful. Hotmail has had serious problems, and I think Lycos’ domain name expired yesterday. Just be glad I didn’t put Apple on that list!)

These types of books always interest me, because I am one of those individualist entrepreneur types. I don’t ever expect to “hit it big,” because my focus is always on narrow niches, but it’s still fun to read about people who, often enough, created extremely successful businesses without really trying to.

For example, PayPal began as a PDA application and initially told customers they didn’t want it to be used to pay for auctions. They eventually abandoned the initial goals of PayPal and now everybody uses it to pay for auctions.

Then there are the companies that almost collapse under their own initial success, like Blogger. Prya Labs didn’t set out to create a new “sphere” (as in blogo-), but when it did, had lots of users and no way to make any money off them. They had to lay off practically the entire company and run on fumes until someone with lots of money (Google) came in and made the one guy who stuck around super wealthy.

There are, of course, several companies represented in the book who did exactly what they set out to do. But that’s boring.

And there’s the occasional founder who was so wrapped up in what was happening to him that he doesn’t know what was going on around him: like Steve Wozniak (aka the Woz) who is still convinced that the Apple II set all sorts of records that it didn’t, and thinks Commodore passed on acquiring Apple when in fact Steve Jobs tried to push Jack Tramiel too hard and lost the chance. But I digress.

I can certainly recommend reading this book. At the very least, you’ll learn that nobody ever got rich because of a book or blog post they read, and most of the ones who do get rich don’t stop working after their bank accounts overflow.

As usual, there were some very helpful sessions. Dave Collins and Thomas Wetzel convinced me to give Google AdWords yet another try with their insights. There were several sessions about blogging, newsletters, and podcasting as marketing vehicles, with Bob Walsh, Phil Schnyder, and Michael Lehman making several appearances on these topics. Nick Bradbury, author of the excellent TopStyle, had a great presentation on effective user interface design and the difficulties of keeping software simple while still satisfying the needs of power users.

David Intersimone of CodeGear had a session on native code development. I have to say I was a bit disappointed that he didn’t make more of a pitch for using Delphi. He showed off some of Delphi’s features, but his session seemed to be more of an overview of the development options for Windows, rather than one really driving home the benefits of native code development with Delphi. But it was great to see CodeGear at SIC, because it shows that they understand the importance of reaching out to independent developers rather than just focusing on enterprise customers like Borland has been doing for the last several years. Spending time talking with David was a highlight of the conference for me.

There are plenty of sessions I didn’t mention simply because there are too many for one person to attend.

SIC isn’t just about sessions, it’s also about networking and schmoozing.  It’s nice to have an opportunity to spend time with people in the same industry, as being an independent software developer often means spending your days behind a computer without “realspace” interaction with your colleagues. I had a great time meeting new people, and especially catching up with people I’ve met at previous conferences.

Industry Awards at SIC

The Shareware Industry Awards Foundation presents several awards each year at SIC during an awards banquet. Last year, my wife and I attended the banquet and decided that we could save some money by skipping it the next time and eating out at a restaurant instead. So this year, a group of us drove out to Ruth’s Chris Steakhouse where we enjoyed some good steak and excellent company.

Upon our return, I was informed that I missed my own award presentation! I didn’t believe it at first, because I assumed Bible Software was too much of a niche market to even put me in the running. But nobody was pulling my leg — SwordSearcher received the People’s Choice Award for the Hobby & Personal Interest category. I was stunned — I didn’t ask anyone to vote for me, I didn’t mention it in a single newsletter. I didn’t even vote for myself! The People’s Choice Awards are voted on by thousands of people across the internet on major websites like CNet, Tucows, and PC World. So that was exciting.

Here’s a picture of the award. It’s much heavier than it looks and takes up a good deal of space on a shelf. Always thinking about getting the word out, I promptly wrote a press release announcing the award.

A big thank-you to the folks who put on the conference. I hope to be able to attend again next year in Boston.