Require a Serial

[JohnOne]

This is a very very basic example of how to make your program require a serial number.
Your serial number can be most anything you like within reason, it will be encrypted.
The crypted serial for this basic example will be inside your program.

if you want to use this examples serial it is "my serial"
It works like this.

1. Your program looks at a registry key value.
2. if the value does not exist or is wrong, the user will be asked for a serial.
3. if serial is correct, the regkey and value will be written to the registry and user will not be asked again because the next time they run it, the key and value will be there.
4. if serial is wrong, the program simply exits with a message.

This is a simple example and not intended to protect your program from attack/hack or anything else.
You should always be aware that the registry is used by your operating system, and is not to be played with.

Example using registry method

 

First you can make a serial for your program
 

#include <Crypt.au3>

$_InputBox = InputBox("Serial Maker", "Enter a Serial Number")

$AG5InputBox = _Crypt_HashData($_InputBox, $CALG_MD5)

Run("Notepad")
WinWaitActive("Untitled - Notepad")

Do
    ClipPut($AG5InputBox)
Until ClipGet() = $AG5InputBox

ControlSend("Untitled - Notepad", "", "[CLASS:Edit; INSTANCE:1]", "here is what your crypted serial looks like to AutoIt: " & $AG5InputBox & @CRLF)
ControlSend("Untitled - Notepad", "", "[CLASS:Edit; INSTANCE:1]", "And this is the serial you made: " & $_InputBox & @CRLF & _
        " your crypted serial is now in your clipboard, you can paste it wherever you like")

Now use your crypted serial in your program
 

#include <Crypt.au3>

Global  $MyCompanyName = "My Company"
Global  $MyProgramName = "My Program"

$_InputBox = InputBox($MyCompanyName, "Please Enter Serial Number")

$AG5InputBox = _Crypt_HashData($_InputBox, $CALG_MD5) ; this makes the crypt of the serial entered

If $AG5InputBox <> "0x01E9FC1C4E5C0E769F24A89AA3586251" Then ; your crypted serial will replace this, it's where the entered crypt is compared to your crypt
    ; If the wrong serial was entered, this message box will display and your program will exit
    Exit MsgBox(0,0,"Sorry Incorrect Serial")
EndIf

;your program starts here

_StartOfProject()

Func _StartOfProject()
    ; If the correct serial was entered, this message box will display
    MsgBox(0,$MyCompanyName, $MyProgramName)
EndFunc

So now your program will not run unless the user entered the correct serial.
But you don't want your user to have to put a serial in everytime they use your program.
So lets deal with that now.
Your program should first look at a registry entry to see if a correct serial was already entered.
 

#include <Crypt.au3>

Global $MyCompanyName = "My Company"
Global $MyProgramName = "My Program"

Global $_HasUserAlreadyEnteredCorrectSerial = RegRead("HKCU\software\" & $MyCompanyName, $MyProgramName)

If @error Or $_HasUserAlreadyEnteredCorrectSerial <> 1 Then ; you only ask for serial if one was not already entered, else start your program immediately
    $_InputBox = InputBox($MyCompanyName, "Please Enter Serial Number")

    ;;http://www.autoitscript.com/autoit3/docs/libfunctions/_Crypt_HashData.htm
    $AG5InputBox = _Crypt_HashData($_InputBox, $CALG_MD5) ; this makes the crypt of the serial entered

    If $AG5InputBox <> "0x01E9FC1C4E5C0E769F24A89AA3586251" Then ; your crypted serial will replace this, it's where the entered crypt is compared to your crypt
        ; If the wrong serial was entered, this message box will display and your program will exit
        Exit MsgBox(0, 0, "Sorry Incorrect Serial")
    Else
        ;If correct serial is entered you will write 1 to the registry key HKEY_CURRENT_USER\Software\My CompanyMy Program
        ;and the user will not be asked again
        RegWrite("HKCU\software\" & $MyCompanyName, $MyProgramName, "REG_DWORD", 1)
    EndIf

EndIf

;your program starts here

_StartOfProject()

Func _StartOfProject()
    ; If the correct serial was entered, this message box will display
    MsgBox(0, $MyCompanyName, $MyProgramName)
EndFunc   ;==>_StartOfProject

Testing your program and need to delete registry key?
 

$MyCompanyName = "My Company"

RegDelete("HKCU\software\" & $MyCompanyName)

 

Here is an even more basic example using a folder existence method.

 

Example using just a directory to determine if the user has the serial.

It works much like the first but without using the registry.
You should be able to follow it easily having looked at the first.

It checks to see if a folder exists with the same name as your crypted serial, if it does not
it askes for serial, if the serial is correct it creates the folde so the user is not asked again
If user enters incorrect serial, the program exits.
 

expandcollapse popup

#include <Crypt.au3>

Global $MyCompanyName = "My Company"
Global $MyProgramName = "My Program"
Global $MyCryptedSerial = "0x01E9FC1C4E5C0E769F24A89AA3586251"

;http://www.autoitscript.com/autoit3/docs/functions/RegRead.htm
Global $_HasUserAlreadyEnteredCorrectSerial = FileExists (@AppDataCommonDir & "\" & $MyCryptedSerial); Your crypted serial will replace this , it is checking if the folder exists

If Not $_HasUserAlreadyEnteredCorrectSerial Then
    _AskToEnterSerial($MyCryptedSerial) ;Pass crypted serial to function
EndIf

If @error Then
    ; If the wrong serial was entered, this message box will display and your program will exit
    Exit MsgBox(0, 0, "Sorry Incorrect Serial")
EndIf

;your program starts here

_StartOfProject()

Func _StartOfProject()
    ; If the correct serial was entered, this message box will display
    MsgBox(0, $MyCompanyName, $MyProgramName)
EndFunc   ;==>_StartOfProject

Func _AskToEnterSerial($crypt)
    $_InputBox = InputBox($MyCompanyName, "Please Enter Serial Number")
    $AG5InputBox = _Crypt_HashData($_InputBox, $CALG_MD5) ; this makes the crypt of the serial entered
    If $AG5InputBox <> $crypt Then
        ;Set @error and return
        Return SetError(1)
    EndIf
    ;If correct serial is entered you will create the folder
    ;and the user will not be asked again
    Do
        DirCreate(@AppDataCommonDir & "\" & $crypt)
    Until FileExists (@AppDataCommonDir & "\" & $crypt)
EndFunc

Need to delete folder for testing?

DirRemove(@AppDataCommonDir & "\" & $crypt)

 

 

Edited August 13, 2015 by JohnOne

[TheSaint]

@JohnOne - Good attempt, but it could be improved greatly (quite simply), by adding in elements that work with a drive serial number for instance or processor detail, username, etc. That way, the encrypted registry info couldn't just be swapped around from PC to PC.

[JohnOne]

Indeed, that would be the very basic version.

The above is the very very basic version.

I'm going to add a few more including the very very very basic version.

[TheSaint]

That's very very very very good of you! muttley

[JohnOne]

Added the very * 3 basic version to first post.

[SmOke_N]

@JohnOne - Good attempt, but it could be improved greatly (quite simply), by adding in elements that work with a drive serial number for instance or processor detail, username, etc. That way, the encrypted registry info couldn't just be swapped around from PC to PC.

IMO... Using a single method is going to create more of a headache than it's worth even applying only one of those ( been there, done that ).

My suggestion is to have 5 to 7 items like you suggest.

In the "single" method, if it's correct, great!

However, if the user replaced the hard drive/motherboard/changed bios, whatever you're using, to upgrade their system, now you have to take the time to prove he did ( if you're extreme ), re-issue a valid working serial, log it yourself, etc

Using multiple, you can set your own rules, eg.. if 5 out of 7 are ok, great, probably not sent to VM to be distributed, probably not on another PC, and you've lessened your headache(s) exponentially.

Edited December 11, 2012 by SmOke_N

[TheSaint]

@SmOke_N - Can only agree, and that's how I would do it, but I was trying to keep it in line with JohnOne's simple theme.

In his scenario, it sounds like the user knows the serial anyway, so all he is doing is saving them a little trouble. If they modify their PC, then they just need to re-enter the serial just once again, so no biggie really. The simplest way of course, is to use the USER name (which is unlikely to change) and the 'C' drive serial number (if that latter changes, then a re-install may be on the cards anyway). I'd then encrypt them along with the serial, separating each element with a pipe. Pretty simple and not ideal against a determined hacker without including some randomness, but should be fine for what he seems to be aiming for ... and certainly a lot more secure than the present state.

[JohnOne]

I'd probably just use _WinApi_UniquehardwareID for something like that.

[guinness]

I'd probably just use _WinApi_UniquehardwareID for something like that.

I would as well, with all options.

[TheSaint]

Didn't know that one, but it sounds the way to go.

With that, I'm presuming you can make one or two hardware changes and not affect things.

[JohnOne]

You can choose what hardware you want to use in the gathering of an ID, from one particular to all supported.

[guinness]

The only downside to _WinAPI_UniqueHardwareID, is it requires WMI to be running.

#include <APIConstants.au3>
#include <WinAPIEx.au3>

MsgBox(4096, '',  'My UniqueID: ' & _WinAPI_UniqueHardwareID(BitOR($UHID_MB, $UHID_BIOS, $UHID_HDD))) ; $UHID_MB is used regardless.

[SmOke_N]

The only downside to _WinAPI_UniqueHardwareID, is it requires WMI to be running.

Which is a reason it's not an option for my deployments. Would be nice to "require" specific things to run "your" software on "their" systems. But the truth is, we're slaves to the client side system setup.

[nullschritt]

Look here for a non winapi HWID code, that is promised to be 100% the same across any operating system, windows, or emulated on linux, as long as the hardware doesn't change.

You can use this along with a serial key system based on a regexp + php/mysql verification to make sure they key actually exists and is active, in addition to matching the pattern.

Edited December 15, 2012 by nullschritt

[guinness]

Which is a reason it's not an option for my deployments. Would be nice to "require" specific things to run "your" software on "their" systems. But the truth is, we're slaves to the client side system setup.

I tried to create a similar function to Yashied's >>

[Masush]

I Just created with HWID KEY

HEHEHE

THank You MAN

Edited February 19, 2013 by Masush

[Werty]

I'm wondering why serials are still used, sure for physical media they are still usefull, but for Internet downloads one could have unique downloads for each user.

Example:

1. User goes to website and click the download button.

2. Webserver checks users PC for some hardware ID

3. Webserver compiles a unique EXE with the hardware ID hardcoded into it (so no need for registry entries).

4. Profit

[JohnOne]

I'd be interested in seeing the code for that.

But what about when your user changes hardware?

In my opinion it is neither big nor clever to inconvenience your clients, and that is one reason for a serial.

[BrewManNH]

How long would that compilation take? How much would it affect the program download time if you had 1000 people downloading it at the same time and each one had to be compiled first?

[Werty]

I'd be interested in seeing the code for that.

But what about when your user changes hardware?

In my opinion it is neither big nor clever to inconvenience your clients, and that is one reason for a serial.

I assume we talk paid software, so the user would have an account where he could download a fresh exe if he changes hardware.

How long would that compilation take? How much would it affect the program download time if you had 1000 people downloading it at the same time and each one had to be compiled first?

It would take lesser time than going to the store and buy a CD with the software

If it's a small program it, obviously, wouldnt take too long, if it's a big program, you could split the download up in two or more parts/files, dowloading all the media like sounds and graphics first, and the exe last, so while he downloads all the media, the server compiles the exe and have it ready.

Again assuming it's paid software, as there would be no reason to include security on free software, having 1000 simultanous users buying and downloading the software, then you would also have enough cash to have some beefy servers that could get the job done fast.