Bind Program To Computer

[InFected]

Well, since I distribute some of my autoit applications on a small scale for real $, my programs could be used on any computer. Therefore one person could buy it and then send to their friends or try to sell it themselves.. I researched a key code option but not only could I not find one, but I didn't need something so complicated. I then asked here how to bind an application to a computer and recieved no help... So, I found a simple way to do this. If there is a better solution, please tell me. But this works for my needs quite well..

What this does is... On first run it sets a .INI file hidden in your @AppData directory with your Computer Name on it. It then verifies that the file exists and the Computer Names match before it will run.

How I managed to make it only do this on first run is I created another autoit executable that writes the INI file, and once it is written that executable is deleted.

If the person who binded the program to their computer sends it to someone else, and they run it, it will give a MsgBox that says you need to buy the program. If they send it and somehow find the .INI file, then it would still not work due to differentiating Computer Names.

Since I have had trouble before when people post plain scripts without the info on how to use it I will tell you exactly what to do.

On the script you want paste this code at the beggining

$directory = @AppDataDir & "\tll315.mni" ; directory of the .ini file
If FileExists("ignore.exe") Then ; the file that writes the .ini file, can change to whatever you like
    RunWait ( "ignore.exe" ) ; run the 
sleep(100)
    FileDelete ( "ignore.exe" )  ; Deletes the file
EndIf

If Not FileExists ( $directory ) Then
    MsgBox ( 0, "Title", "You have not bought this script.")
Else
    Checkname()
EndIf


Func Checkname()
    $ininame = IniRead ( $directory, "section", "key", "default")
    $Compname = @ComputerName

    if $ininame = $Compname Then
        ; Nothing, continues on to your script
    Else
        MsgBox ( 0, "Faggot", "You are trying to redistribute my programs") ; Whatever you want, this only appears if there is an .ini file with wrong name.

    EndIf
EndFunc

; Your script here

And the ignore.exe should be this..

$PcName = @ComputerName ; gets computer name
$directory = @AppDataDir & "\tll315.mni" ;the directory you want .ini file in

FileSetAttrib($directory, "-hr") ; hides the .ini file

IniWrite($directory, "Section", "Key", $PcName); writes ini file to directory

exit 0 ; exits

I hope you enjoy. This is really simple. If you have a better idea for this please post.

Also, to make it look like there is some sort of license key on the program.. Add this to beggining of script.

$keycode = 01921820129 ; any code you want
$inputcode = InputBox ( "License Key", "What is the license key?")

if $inputcode = $keycode then
;nothing, continue script
else
MsgBox ( 0, "Error", "Incorrect License Key")
exit 0

[twitchyliquid64]

I would use the serial number of the main drive of the computer instead.

It's a lot harder to change or spoof, though the API call can be spoofed.

The only change you would need to make is

$compname = drivegetserial( @homedrive)

Or something like that.

[taietel]

What if a client makes a copy of the program before he runs it?

[edit] typo

Edited July 19, 2011 by taietel

[twitchyliquid64]

I agree. Online services and validation are probably more secure.

[haiishq]

What if a client makes a copy of the program before he runs it?

[edit] typo

i agree, i really think it does not secure the program at all, and if its not hardware serial based or only single registeration of generated serial for the program such as online detection then on the first run any one can check for the changes in files and registy and replicate the changes into another computer, very easy to fool this concept

what i have done in past it, have a keygen and a program,

program will generate computer id and they will have to get back with you for the serial and that serial will only be used on that computer based on the computer id

[InFected]

Yes, I know this isn't very secure and isn't for commercial use but for a small scale it should do fine, especiall when people don't know how the program binds itself to computer or even if it does. You can also hide the program in a fake 'addon' folder for your script. It is easy to fool the average computer user. Also this could be used in conjunction with serial keys etc.

This would be good for a small scale distribution, say to your friends or to a few people for a couple $. They run it once with no malicious content, use it.. Then one of their friends asks them for it, they give them the program, and when they try to run it it would not work. Just a very simple idea that works for me that I decided to post to help fellow users in need.

[BillLuvsU]

You should really encrypt the ini file contents... it's just one extra line and it would makea large difference. If your customer just had a common process watcher going he would instantly know what was going on and would just have to copy\paste another computer name in there.

[twitchyliquid64]

You should really encrypt the ini file contents... it's just one extra line and it would makea large difference. If your customer just had a common process watcher going he would instantly know what was going on and would just have to copy\paste another computer name in there.

Then what would you use as the key to the encryption?

[Chimaera]

what about a download server for the program that downloads it + a hidden ini file that it downloads as well and copies into the system.

Without the hidden .ini file then no go?

So basically if it hasn't come from your server then no way is it going to have the .ini

Just a thought

Chim

Edit

Or do a little prefetch thing like Microsoft do and hide the ini transfer in it

Admittedly it wont confuse a hardened cracker as he will be in a sandbox and be monitoring all the movements, but for day to day stuff should be ok

Edited July 20, 2011 by Chimaera

[LurchMan]

As a way for the small scale this might work a little better (in my mind I think it is anyways):

#include <string.au3>

$DS = _StringEncrypt(1, DriveGetSerial (@HomeDrive), "pass", 1)

$SN = _StringEncrypt (1, _StringReverse($DS), "pass", 1)
ConsoleWrite($SN & @CRLF)
ConsoleWrite($DS & @CRLF)
ConsoleWrite(@CRLF)

$SN_DEC = _StringReverse(_StringEncrypt (0, $SN, "pass", 1))
ConsoleWrite($SN_DEC & @CRLF)
ConsoleWrite($DS & @CRLF)

If $SN_DEC = $DS Then $bTest = True

ConsoleWrite(@CRLF)
ConsoleWrite("SN Test Results: " & $bTest & @CRLF)

You could use this and just write the $SN variable somewhere in the registry to check against. This way it kind of hides it and and is a little more complex.

Edit: Spelling

Edited July 21, 2011 by LurchMan

[twitchyliquid64]

Also, there is a unique identifier called the HWID in windows, and this is significantly harder to spoof.

Could you use this?

[Chimaera]

Xprotect from Valuater has this function within it i believe

#include <string.au3> 
MsgBox(64, "", _HWID())

Func _HWID()     
$osdrive = StringLeft(@SystemDir, 3)     
$original = "0"&@CPUArch & @KBLayout & DriveGetSerial("C:\") & StringUpper(DriveGetType($osdrive)) & DriveSpaceTotal ($osdrive)     
$string2 = StringMid($original, Round(StringLen($original)/2), Round(StringLen($original)/2))     
$string2_mod = _StringToHex(_StringReverse($string2))     
$original = _StringEncrypt(1, $original, $string2_mod, 4)     
Return $original
EndFunc

Or

I tried this and it creates a seriously long number

Chimaera

Edited July 23, 2011 by Chimaera

[Anteaus]

Also worth bearing in mind that this could make you very unpopular if a need arises to rename computers. It should also be borne in mind that renaming a computer is a permissible action; the site admin who does so is breaking no rules.

Protecting your work is one thing, losing a valued customer over what is seen as booby-trapping is another, though.

My advice would be to release under the GPL, or whatever free licence you prefer. Most sites want support on software, and will pay you for providing support anyway. If you make it clear that use on more than x computers at once is a usage violation which nullifies the support contract, then they will likely abide by that.

[nullschritt]

It would be wise to use the md5 hash function to hash the HWID after generated, to shorten it for comparison/storage. I am the original writer of this function, (i forgot my password to my old account lol), and as such I can say, this is not a perfect system, for example, if the user has more than one hard drive it can change the HWID, if they install their os on a different drive. This can be fixed by enumerating all drives for their info, if I decide to update it, I'll post the optimized function in example scripts.

Nice to see people use this though (:

Edited December 14, 2012 by nullschritt

[nullschritt]

Also worth bearing in mind that this could make you very unpopular if a need arises to rename computers. It should also be borne in mind that renaming a computer is a permissible action; the site admin who does so is breaking no rules.

Protecting your work is one thing, losing a valued customer over what is seen as booby-trapping is another, though.

My advice would be to release under the GPL, or whatever free licence you prefer. Most sites want support on software, and will pay you for providing support anyway. If you make it clear that use on more than x computers at once is a usage violation which nullifies the support contract, then they will likely abide by that.

This uses only hardware info, no OS config, so that it will generate the same HWID even if the pc is wiped/reset.

Edit:

(realized you were talking about OP, sorry lol) anyways:

Fixed and posted result here:

Edited December 14, 2012 by nullschritt

[PhoenixXL]

Could Try

Make an Installer of the program which would be distributed to the public,

The Installer would check the Manufacturer Id of the Computer and send it to the webserver

and

then download the Executable which runs only on that specific Computer

[The access to the web server would of course be password-protected]

Edited December 14, 2012 by PhoenixXL

[nullschritt]

Could Try

Make an Installer of the program which would be distributed to the public,

The Installer would check the Manufacturer Id of the Computer and send it to the webserver

and

then download the Executable which runs only on that specific Computer

[The access to the web server would of course be password-protected]

I use it with a php authentication that disables the product activation status if pirating/sharing is detected. (example more then 4 hwid changes, or more than 10 ip changes, or any lesser combination of both.)

[TheSaint]

Good of you all to resurrect this topic, but obviously you missed a more recent similar one

[nullschritt]

Good of you all to resurrect this topic, but obviously you missed a more recent similar one

Perhaps, but that thread does not initially display a requirement for such a function, originally it appears to just support locally locking a program with a serial key, rather than verifying the hardware against the central server. It did not show up when I searched "HWID" lol.

[TheSaint]

True, not initially ... though eventually the WinAPI call is mentioned, which certainly bears looking into and should give quite an acceptable solution.