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.

Well, nothing has changed with regard to development — I won’t be resuming work on the Mac version of SwordSearcher in the foreseeable future as all of the reasons I suspended work on that project still stand – but I received an email from a long-time SwordSearcher user who wanted to share his success at using SwordSearcher on his Mac with Crossover.  Here’s an excerpt:

“And I’m pleased to announce it WORKS! And it actually integrates so well, I wouldn’t even know I was using a mixed setup of Windows and Apple, they BOTH seem native mode in operation, and I use them at the same time.”

Complete details have been posted on the SwordSearcher Mac website.

Additional thought: do software compatibility layers like Crossover for Mac and WINE for Linux make native development irrelevant?

Well, certainly not irrelevant in every case.  But in my case, it certainly reduces the need to expend development energy targeting multiple platforms when Linux and Mac already have excellent “emulation” alternatives. (And yes, I know WINE is not an emulator!)  A single developer like myself, on a project as complex as SwordSearcher, is better off focusing on doing the best on Windows — where almost all the customers are — rather than trying to spend time writing multiple versions of the software, or worse, using cross-platform development tools that invariably result in a “lowest common denominator” feel for the application. And with WINE and Crossover Mac, a viable solution already exists that allows me to continue to focus my efforts on one platform.

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.