Archive for September, 2008

Protecting Your Software – Authorisation and You

Tuesday, September 30th, 2008

Piracy is always a big issue in the software industry.  It’s a global epidemic and everyone is guilty of it.  You are too, and you know it.  That doesn’t make you evil, it just means you are as morally flexible as everyone.  So taken this as a given, as a SME developing custom software, how do you protect your investment and ensure the success of your product?

First, we need to address some universal truths.

  1. All software of any value will be pirated.
  2. All copy protection mechanisms will be worked around by someone of sufficient intelligence.
  3. If you have produced a good product for sale on the open market, it will be pirated.

Stealing software is VERY easy.  Once we, as professionals, are comfortable with the fact that our products WILL be stolen, we can start attempting to maximise the sales.  In order to sell just about anything, you need to know who your target audience is.  Who exactly are you selling to?  There are four types of user…

  1. The Legitimate Customer

    If you have the pleasure of having a legitimate customer, make sure nothing stands between them and using your software.  Help them out at every turn and never obstruct their usage.  They pay your bills, remember that.  These people will pay for your software and upgrade and maintenance.  They may well all be corporate entities who under threat of inspection need to remain 100% above board (tip: Develop software for the legal industry, they’re pretty much not allowed to steal).  Home users may fall into this category simply because they don’t know they can steal software easily.

  2. The Moral Pirate

    You probably fit into this category.  You pay for software, you like to think you’re a good software citizen.  You may occasionally go to the pirate bay to grab a cracked version of an application because the demo or cripple-ware version really gets in the way of you trying the software.  You probably wouldn’t think twice about installing one copy of Windows on two separate machines however.  People can end up accidentally becoming moral pirates simply due to a lack of understanding of (often confusing) software licenses.

  3. The Immoral Pirate

    Immoral pirates use file sharing networks, Usenet, peer to peer or private FTP as their default method of software delivery.  They don’t want to pay for software.  They may believe they’re stealing, they may believe they’re in the moral clear as your product endorses evil / closed source mentalities / kills kittens.  You’ll only ever get a sale from the camp if your software is so incredibly hard to steal or find that it’s much more convenient to pay for it.  And even if that’s the case, they’re more likely to investigate an alternative first.

  4. The Career Pirate

    You will never sell a copy to this person, except if they’re actively trying to produce a crack themselves.  Career pirates will produce cracks, publish 0-Day copies of your application, and they’ll do it for the challenge.  Intricate copy protection mechanisms act as encouragement to career pirates.  The harder the better.  It’s an arms race that they will *always* win.

Coming to Terms With Piracy

The first thing you have to realise is that software piracy isn’t actually a bad thing.  Software piracy often introduces people who will later become legitimate users of your software to your product.  If you find that a vast majority of your users are stealing your software, the first thing you need to do is find out why they’re stealing instead of paying…

  • Is your software too expensive?
  • Are you pricing for business but aiming at the individual user?
  • Is the cracked version of your application actually better than the paid for edition?
  • Is your “home” offering too basic and people prefer to steal an overpriced “Professional” edition?
  • Worst of all, is your software crippled by draconian DRM?

If the answer to any of the above questions is yes, then you’re not dealing with a technical problem, you’re dealing with a social engineering and marketing issue.  It’s YOUR FAULT that your software is being stolen because you’re not selling it properly.  You have to be prepared to take responsibility for a misjudged business decision.  It’s not about blaming anyone, it’s about fixing the problem.

Targeting Your Audience

Out of the four groups of users listed above, ignore the fact that the third and fourth group exist.  You will never sell software to those people, they will steal it.  Get over it and move on.  You’re not going to stop them, don’t waste valuable time and money trying to.  Yes?  Good.

You need to protect your software in a way that it actively encourages the first and second groups of users to pay you for your hard work.  The legitimate customer is easy.  They’re going to pay.  Don’t make it hard for them.

The second group is slightly harder.  They’re probably going to pay you, but if they can steal your software really easily, they probably won’t bother.

What you need is some kind of authentication system that is reasonably simple, doesn’t hinder the users and offers some kind of advantage to the paying customer.  Now the funny thing is, this is a solved problem.  For the past decade companies have been experimenting in trying to squeeze the odd payment out of the immoral and career pirates who were not going to pay a penny to start with.  The answer is the serial number.

Serial numbers work.

If you take anything from reading this essay, please take this.

What Not To Do

The following authentication mechanisms are horrible ideas…

  • Online authentication

    Do not presume your clients have always on internet access.  If they don’t and you implement this, they WILL pirate your software or go to a competitor.

  • Products that Phone Home

    If you’ve been naive enough to saddle your software with online authentication and start thinking that products that phone home are a good idea, start thinking about what happens when that product no longer has internet access…

  • Commercial Root-kits 

    There is nothing more immoral than saddling your users machine with software they don’t know about and can’t remove, especially when it is recording their usage and using up CPU cycles.

But!  What if these authentication mechanisms can actually net me a few more sales!  Forget it.  They won’t.

The pirates will still steal, and most importantly…?

You’ll have just spent a small fortune in R&D, infrastructure and development creating a bypass-able authentication system that you then have to keep operational forever.  Unless you manage to con your users into what is essentially a software rental model, those servers of yours have to be available until the end of time, with databases of all your registered users, the level of access they’re allowed to your application and all manner of other data.

Running these oppressive registration mechanisms is expensive, and can potentially introduce defects into your pristine code.  What’s more, they can get in the way of legitimate users and paying customers, driving them to become moral pirates.  As was stated at the start of this piece, you must never put obstacles between legitimate users and paying for your software.  That is commercial suicide.

This is not to say that you should give your product away.

Protecting Your

Now that we’ve looked at what not to do, how on earth can we protect our software?  I really do believe in the serial number.  But a few sane coding practices can help you protect your software fairly easily.

At the simplest level, a serial key can be achieved using common Public-Private key encryption techniques.  Take some key data regarding your application (commonly something like registered user / organisation name, number of licenses granted, perhaps an email address) and encrypt it with a private key.  Your application has the public key embedded within it.  If that information decodes correctly, then the application is registered.  Simple.

But not fool proof.  I’d rather not mislead you by implying that that solution would just work perfectly.  If a cracker could isolate the portion of your code where you load the public key into memory, he could produce a cracked executable with a different public key encoded inside, and thus sign his own keys that would unlock the modified application.

The good news is that depending on your target audience, it’s almost certainly more work than your average user would bother with to steal your program (just don’t load a file from “approot\publicKey.key” and think you’re being diligent!)

The benefits of a simple solution?  Easy.

  1. It’s really really easy for users to register your software.  They pay you, they get a serial key.
  2. You need not store lots of user information for registered users, the key can be regenerated given the same inputs.  Therefore, low overhead on authentication servers as the user technically only need perform this operation once.
  3. Relatively secure, uses known cryptographic techniques.  Certainly beats some traditional “just multiply the username as bytes by some random number”.
  4. Low impact on the application as a whole.
  5. Authentication data can be changed between minor versions, breaking any key generators in the wild and making the software more inconvenient to crack a second time.

There are a few other tricks you can use.

  1. If your software is lucky enough to print out user data in some output, then you’re home free, people won’t share a serial number if their name is stamped on all the documents that the counterfeit copies produce.
  2. Don’t externalise your serial number checks in to an easily replaceable DLL / assembly.  It’s just too easy to isolate and replace.
  3. Don’t call the authentication method just once returning a boolean representing “is registered” or not, this is also easy to isolate and replace.
  4. If you use an interpreted language, user code obfuscating tools to stop simple decompilation.


Hopefully the above outlines have made the issue of small software piracy a little easier to understand along with explaining why obstructive software registration techniques won’t win you sales and instead often cost you both sales and development money.

Don’t fear software piracy, just attempt to give your legitimate users an experience that’ll make them want to act as your agents to their friends and associates.

You can’t pay for any marketing as effective as genuine goodwill.

Dear Google (Chrome)

Wednesday, September 3rd, 2008

What happened to “don’t be evil”? 

Why do you insist that people “posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any content which you submit, post or display on or through, the services”?

What made you think that the world needed another browser?

When you decided you wanted a browser, was the design brief “Opera, but use WebKit, and a new JavaScript implementation”?  That’s really all you produced.

JavaScript needs fixing, you’re right about that.  But if for a second you think the “correct” way to fix JavaScript is to ignore significant inroads made by other corporations and organisations in a massive “not invented here” haemorrhage then you’re very, very mistaken.

But most of all, what made you think that people won’t see this as the transparent attempt to force the hand of web standards that it is?  Seriously, let me get this straight;  When Microsoft do ActiveX and invent things like the XML RPC object, that’s evil and against standards and trying to lock everyone to Windows.  But when you create a browser and re-implement JavaScript in an attempt to force the other browsers to follow your lead in an further attempt to give Google Apps a stranglehold on the majority of “online applications” that’s just fine?

JavaScript really really needs fixing, and yes, a lot of people use GMail, but to try and suppose that the entire web is so dominated by Google Apps that a browser need be created to drive market share towards them is pure egotism, especially for a company with at most (and I’m being generous) four successful projects under it’s belt (Search, the killer app.  AdWords, the money.  Google Maps for a slick implementation and debatable GMail due to market share).  It’s lunacy to think that you’re fixing anything, rather just adding an extra layer of development and complexity on to the already arduous battle for web compatibility.

Your browser isn’t bad, it’s quite clean, it’s likely another eternal beta, but in the end, it’s just a stripped back version of Opera.  I’m sure you’ll do a good job of it, but in the end, will yet another minority browser really be worth it?  You need another hit, I really appreciate that, but try remember not to be evil on the way.

I just wish you’d put all this effort into existing technology.  One of Mozilla’s millions of prototypes (you are the sugardaddy after all) or even Opera (seeing as you like it so much) would be ideal, lets not repeat history again and again.

Geeking Out

Wednesday, September 3rd, 2008

There’s nothing more rewarding than programming on huge displays.  Say all you like about notebooks and pocket sized this and that, but if you really want to bed in and do some hardcore development, or graphics editing, or just a bit of browsing, whilst gaming, whilst listening to music, whilst watching videos, there’s nothing like masses of screen real estate.

For the past year and a half or so I’ve been enjoying two 19″ monitors (single monitor configurations feel very claustrophobic to me these days) and the experience has been “ok”.  However, finally the price points on reasonable 24″ monitors are right and I’ve invested in a little bit of an upgrade…


That’s 19″ (1280×1024) – 24″ (1920×1200) – 19″ (1280×1024).  I’ve not added the numbers together to get an accurate calculation of desktop real estate, nor have I attempted to work out how much more productive the lack of task switching and windowing has made me.  But I’ll tell you what… it’s incredibly cool.  And yes, it does take up the entire length of a dining room sized table.  And no I don’t have a problem with that.

The graphics card powering the configuration is pretty simple.  People rave about the Quadro FX cards but I went with a wholly more LO-FI setup of my current-ish generation 3d card 7900GT in PCI-E x16 mode powering the 24″ in “Single display” 3d rendering mode (for gaming), along with an old (as in, in a box somewhere) 7300GT in PCI-E 2x mode (same family, easy compatibility, same driver…) powering the two 19″ displays.  Works a treat.  Finally I found a use for the fact I needlessly bought an SLI motherboard.

I can’t begin to explain how much benefit you get from dual displays (and other people have explained it far better than I could), but the third is pure luxury.  The ability to have documentation, masses of source code and a running app a glance away is priceless.

The new display is a Benq 2400.  It’s a TN panel, so graphics “enthusiasts” will probably deride its colour reproduction (TN panels can’t quite produce the same depth of colour as other panel types), however it’s well reviewed, has decent contrast ratio and response times and no dead pixels.  Looks and feels fantastic to my heathen eyes and I’d definitely recommend it (257 inc vat.).