Introduction

At the time of installation most software asks for a product key or a serial number; this is to prevent software piracy, but how is this done? In this article, I'll try to cover one basic idea to achieve this. It is advised not to use this in professional software as someone can easily break it.

In each Windows portable executable (PE image file) we can add some certificate (some sort of data) using the image integrity functions (Platform SDK's ImageHlp APIs). The certificate data can be generated using a combination of product keys and some unique IDs for the desktop where the user is installing the software. These unique IDs can be CPU ID, primary volume ID, network card ID etc. To increase the security we can do some encryptions on the certificate data. Writing certificate data in the executable should be done only once, i.e. at the time of installation. At the time of the application startup we can again generate the certificate data using the local machine (where the user is executing the application) unique IDs and compare it with the certificate data which is present in the executable. If there is any mismatch, stop the execution.

In the above approach there is a problem, what if the user changes some hardware component (for e.g. graphics card) and what if that component's unique ID was used to generate the certificate data? Certainly now our application will stop execution because of the mismatch in certificate data. But we do not want this to happen. To avoid this we can use 4-5 unique IDs to generate the certificate data. At application startup, we can make a rule; if any two IDs are matching go ahead otherwise show error for unauthorized copy.

In the demo application, to generate the certificate data, I am using the primary volume ID without any encryption. At the time of application startup, I'll check if there is any certificates present in Sample.dll, if no certificate is present, add a certificate to Sample.dll (actually this task should be done through the installation script) and only the certificate verification code should be present in the executable.

Using the Code

To integrate the certificate manager in your application you need to do the following:

Include "CertificateMgr.h", and imagehlp.lib in your project's additional libraries.

Create an object of CertificateMgr.

Call the Init() method with a portable executable (PE) image file name in which you want to manage the certificate.

Call SignDLL() to add a signed certificate (only inhouse job) so that later at the time of adding an actual client machine certificate it can be verified that we are adding certificate to right DLL. It will be better if you make a command line utility do this. Ofcourse you will not ship this with your actual application.

Call IsValidCopy() to check if the application has a valid certificate or not.

Certificate Manager Class

In this class, I am using ImageAddCertificate and ImageGetCertificateData Win32 SDK APIs.

GetUniqueData() method generates unique data to be put in the PE certificate. While adding a certificate using AddCertificate(), I am keeping the last modified time, and after adding the certificate, the executable is maintained with the previous modified time to simulate an impression of no changes. For the sake of simplicity, I first check if there is any certificate added, if no certificate is found, add it. From the next execution onwards, verify the PE certificate data with the data returned from GetUniqueData(). In real applications, AddCertificate() should be called at the time of application installation before executing the application.

I could not find any good documentation on image integrity functions (Platform SDK's ImageHlp APIs). If you know about any good URL/book for ImageHlp APIs, please add a comment. Discuss more on this at Activation code.

History

27th November, 2005: Initial revision.

21st August, 2008: Now a simple ImageRemoveCertificate will not break the copy protection, yes one can write something to copy certificate data. Thank you Daienl for pointing this.

Share

About the Author

Working with Oracle. Using C/C++, VC++, MFC, STL, C#, Java etc. on various platform like Windows, Unix, Macintosh etc. from last 13+ years to convert various type of requirements into running software components. My core expertise is multithreaded desktop product and large scale enterprises software development.

Comments and Discussions

The word "Protecting" is misleading. You are demonstrating some kind of a licensing scheme. Licensing must be enforced before you can claim a software is protected. Enforcing licensing is done by hiding the scheme and making it very hard to bypass it. Your DLL can be simply replaced with another DLL with the same name and exported functions.

The idea of locking a given piece of code to the hardware running it has been around for years and the various types of approach (NIC MAC address, CPU serial number, HD serial, more...) have all been tried over and over ... to no luck; the point is that once your code is running on someone's machine, there is nothing which forbids the legit machine owner from running your code through a debugger, carefully examine it, patch it and totally bypass whatever protection you put in place. So, while your approach has indeed some value, since it shows what can be used to somewhat "identify a machine", I won't go on and title it "protect from copy" since... well, it won't work

I've been put in charge of similar projects over the years, mostly in a panic mode from some manager who doesn't understand the bigger picture.

If someone really wants to get around copy protection, they will. You can't get around that. There's nothing a decompiler, debugger, and other tracing tools can't find. This is why all of these sophisticated "schemes" fail miserably.

At one company my previous boss worked at, their code was split up among three developers who didn't know the other parts of the code, with all of this fancy security and what not, and within weeks it was cracked. Just comical.

Quite possible, this is just a concept for hiding the license info, especially for desktop applications. Most of the developer hides this info some where in hidden registry entries or in hidden file. I think, certificate also a good and easy place for hiding license info.