A stock Delphi TToolBar will paint with a flat color or with a gradient. This is how a plain TToolBar appears in Windows Vista and Windows 7:

It looks okay, but Windows Vista has been around for a long time now, and this toolbar looks a bit dated. It doesn’t scream "old," but it certainly doesn’t pop out as "shiny."

What we want to do is have the toolbar paint its background with the current operating system theme. This will give us a nice toolbar look that conforms to the current them, looks modern, and is backwards-compatible with Windows XP. Delphi (2007 and 2009) doesn’t offer us a property to do this, so we need to add some code to the toolbar’s OnCustomDraw event.

First, we add Themes to the form’s uses clause. The Themes unit contains Delphi routines for accessing the Windows XP and Vista Theme API.

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, ComCtrls, ImgList, ToolWin, StdCtrls, Menus, Themes;

Next, add the TToolBar’s OnCustomDraw event handler (double-click it under Events in the Object Inspector). And add the code to paint the background:

procedure TForm1.ToolBar1CustomDraw(Sender: TToolBar; const ARect: TRect;
  var DefaultDraw: Boolean);
var
  ElementDetails: TThemedElementDetails;
begin
  if ThemeServices.ThemesEnabled then
  begin
    ElementDetails := ThemeServices.GetElementDetails(trRebarRoot);
    ThemeServices.DrawElement(Sender.Canvas.Handle, ElementDetails, Sender.ClientRect);
  end;
end;

A little explanation:

ThemeServices.ThemesEnabled lets us know Themes are actually being used, so we don’t try to paint a theme element on a system that isn’t using themes.

The record variable ElementDetails is used to tell Windows what kind of theme object we want painted. In this case, we are using the rebar background, specified with a call to ThemeServices.GetElementDetails(trRebarRoot). We use ThemeServices.DrawElement to paint the rebar background on the TToolBar’s canvas.

This is how our Toolbar looks now:

With just a few lines of code, our application looks like it has had a major face lift.

There is still something left that can be done to improve the appearance of the form a little more. Ideally, the toolbar should be blended a bit with the menu above it. You only need to do this if you are using a standard TMainMenu on the form’s Menu property to display your menu.

Change the OnCustomDraw event handler for the TToolBar so it looks like this:

procedure TForm1.ToolBar1CustomDraw(Sender: TToolBar; const ARect: TRect;
  var DefaultDraw: Boolean);
var
  ElementDetails: TThemedElementDetails;
  NewRect : TRect;
begin
  if ThemeServices.ThemesEnabled then
  begin
    NewRect := Sender.ClientRect;
    NewRect.Top := NewRect.Top - GetSystemMetrics(SM_CYMENU);
    ElementDetails := ThemeServices.GetElementDetails(trRebarRoot);
    ThemeServices.DrawElement(Sender.Canvas.Handle, ElementDetails, NewRect);
  end;
end;

What we’ve done is introduced a new TRect so we can modify where the background painting starts. NewRect is initialized to the toolbar’s client rect coordinates. Then we use a call to GetSystemMetrics to get the height of a menu bar, and subtract that from the top of NewRect, and pass NewRect as the drawing rectangle to DrawElement. This starts the rebar background at the same position of the menu, giving us a more blended look for the toolbar:

Now the toolbar looks more "attached" to the menu bar.

Note that the toolbar paints well under Windows XP, too:

Giving a stock TToolBar a modern-looking background only takes a few lines of code and is an easy way to improve the appearance of your application. Once you’ve done this, you’ll want to start poking around in Themes.pas to see what else you can add some theme magic to.

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.

To wit, I’ve just used Delphi 2007 Update 1 to compile what I hope to be the next release of Daily Bible and Prayer — version 2.1, a small update. I was able to do all of the .1 development in D2007 without anything holding me back, and the finished product works as it should. If all goes well, DBAP 2.1 will be released (as a free update) later this week.

Dave Nottage, always a helpful poster in the Delphi newsgroups, has succinct workarounds.

Earlier this month I blogged about my enthusiasm about Delphi 2007 and CodeGear. I did so before D2007 was shipping based on what I saw in the betas. I meant every word of it.

But.

Hold on a bit. D2007 has shipped, but there exist a couple of serious problems. Suffice it to say I can’t build a production-level application with D2007 due to some nagging open issues — issues that should never have made it into the final release. It appears that CodeGear was so in need of revenue in 1Q 2007 that they simply had to get it out the door this month. Unfortunately, this means that it’s not good for releasing applications until they release a hotfix or two to address two major issues:

1. Task bar button stuff. Applications compiled with D2007 just don’t work right in this respect.

2. Applications compiled with D2007 don’t show up on the Windows task list. Ouch!

Of course, there are workarounds, but this is pretty disappointing. I’m not disclosing anything that comes from beta testing — this is stuff from the released version of D2007.

Why am I writing this? I opened my mouth (er, typed my keys) and said how great D2007 is. I owe it to anyone reading my blog to update them on it just in case it matters to them. D2007 is great, to be sure, but it’s just not done!

This isn’t really new, of course. D2005 wasn’t done when it was released either, and eventually became usable. D2007 is way better than D2005 — it’s just frustrating that some very visible issues still need to be fixed before it can actually be used in a production environment.

Back when Borland tried to sell off the developer tools group of their company, I received a few emails from people who know I use Delphi warning me that I need to switch to something else. I wasn’t too worried then, and I am not worried at all about it now. Borland couldn’t find a buyer, so they spun off the tools group into CodeGear, and CodeGear is different.

For the past month I’ve been beta testing the next release of Delphi — Delphi 2007 for Win32. Though I had to sign a nondisclosure agreement to participate in the beta testing, CodeGear has given me permission to talk about it now.

Delphi 2007 for Win32 is great — it’s exactly what I was hoping for in the next Delphi. I don’t have a lot to add that hasn’t already been blogged about by others, but I do want to give my kudos to Nick Hodges and the rest of the CodeGear team. They listened! Lots of us were screaming at Borland that their focus needed to be changed to get a Windows Vista development tool out sooner rather than later — rather than focusing on .Net first. And so they are. Delphi 2007 for Win32 is just what I need, as a Windows application developer who is not yet interested in .Net. This is Delphi’s strength, and I am glad to see CodeGear getting this taken cared of first.

I’ve been a loyal Borland tools user for as long as I have been seriously programming. I cut my teeth on Turbo Pascal. I taught myself C with Borland C++ when it was still a DOS-only tool. I programmed SwordSearcher 2.0 with Borland C++ 4, SwordSearcher 3.0 with Borland C++ 5, and SwordSearcher 4 with Delphi 5, 6, 7, 2005, and 2006.

Borland’s early strength, in my view, was its affordable and powerful tools targeted at students and independent developers. They’ve been spending a lot of time, research, and money developing for the “enterprise sector,” which I know has a lot of money in it –- but they’ve lost sight the early developer who wants a platform to code for fun, or as a hobby, or as an independent software vendor. As a result of this, they’ve lost a lot of “new blood” with people going for the free (but not very good) tools, or for the inexpensive Microsoft “lite” platforms.

This is just my opinion, of course. I’ve not looked to research to back up this particular gut estimation of the current state of development tools. But it is where I bring home my bacon, so I think I have some grasp of the situation.

Finally, Borland (or, more likely, the Developer Tools guys at Borland) is doing something to make an effort to get new developers into their camp. Good! I’ve been using Delphi for years. Delphi Developer Studio 2006 is the best Win32 development platform available, period. I want Delphi to prosper so that I can continue using it!

Hopefully this will make Borland’s divestiture of the Devloper Tools group more successful. My read on the DevCo guys (as they are calling themselves) is that they can’t wait to get out from under Borland, which is more focused on management buzzword-ware “application lifecycle management” stuff –- whatever -– than it is on making good development tools. I am looking forward to an unhindered Delphi development team churning out the best IDE for Windows programmers for years to come.

Really, it is. Borland has fully redeemed themselves for the less-than-stellar Delphi 2005. After the third update and some unofficial patches, Delphi 2005 was okay (and indeed I was using it regularly and enjoyed it)… but

Delphi 2006 is wonderful!

It’s stable and has lots of great features to make a programmer more productive. There’s not much more I can say about it — I just like it!

I’m working on the next version of Daily Bible and Prayer and my usual semi-annual update of SwordSearcher, and I am just as happy as I can be using Delphi 2006 for the work.

One great bonus for users of my software: Delphi 2006 has a more efficient memory manager, so compiled applications actually run faster. I’m looking forward to the new releases.

(Oh, and I haven’t blogged much recently because I’ve been busy programming!)