AutoHotkey Community

You can change the registry key to your secret choice, so hacking will be harder, but with a registry change tracker it is still not difficult. But you don’t have to hide this information. You can even store the expiration date in the registration file. If it (or the date in the registry key) is encrypted together with the PC fingerprint, an attacker cannot play with it. If it is missing or decrypts something invalid, your program quits. The expiration time cannot even be copied over from another PC, because the PC fingerprints are different.

The issue is to determine the current time, when the program runs. If the registration code you send to the user has the encrypted expiration date, your program will be responsible to compare it to the system date/time. There are many things you can do to combat a date resetting attack. One is to check the date of Windows system files, which change often, and if your program detects an inconsistency, quit. If you can assume a live Internet connection, you can query a time server, instead of the system time. An attacker can catch and manipulate the time, though, so you have to use an authenticated time server, or create your own, which sends the time encrypted with a secret key.

I think the problem with that is that you have to send the user the code for the trial and in my opinion that is going to impact on sales dramatically. I've been getting a date off the net and that has been going well, but it restricts me to running trials intermittently, ie, I can't just run them all the time. I know people who run a 7 day trial once per month for example and this has obvious drawbacks. But the security is good.

I thought the following would be a possible solution. To make an exe that works as a trial with the option to license during or after the trial, only lasting two or three days to make it annoying and less appealing to try and cheat- when the user removes the Software it leaves a registry entry stopping (most of) them from using your trial again. So when they start it the first time it connects to the net and get's the date as the start point, if there is no internet connection it shuts down. Can this script be used to make that method any safer? If someone works out how to run it over and over then that's why I think the compromise of a short trial is worth it, genuine people get a reasonable look at the Software but it is too annoying to endure for people trying to and use the system clock method etc, they are going to have to do it every three days. The ones who will put up with that, well they aren't ever buying it anyway. I think the negative of the short trial is insignificant compared to the increased benefit from more people trying your Software.

With trial periods of unregistered SW the issue is permanently storing data in the client machine. A registry key change can be found by a registry tracker, a hidden file - with a disk monitor. You can play with slack areas of certain, rarely changing files, but these can be cleaned by some utilities, too, so there seems to be no secure way to enforce a trial period without Internet connection. There are also fast incremental backup programs or secure disk drives, which restore the disk to an earlier snapshot, undoing any data hiding attempts.

Over the network we could offer a personalized version of the program to be protected. The user downloads and runs a small installer file, which sends the PC fingerprint to our server, and downloads the actual program which our server modifies to include an encrypted expiration date, and saves the PC fingerprint in a database on the server. (We need some automatically run server scripts for that.) If the user tries to re-install the program, our server finds the PC fingerprint in the database, and does not provide another trial version.

Btw, the number of runs is not easier to control than a trial time period: Each time our program starts it needs to change itself, a registration file or the registry, but all these can be easily restored to an earlier saved state. Controlling the trial time period only needs a trusted system time.

I guess the time trial is better than the number of uses anyway, I was more thinking from the point of view of security if it made it better but as you say, it all comes back to the date anyhow one way or the other. But the Website option you propose there is a beauty.

I have the script up and running and have successfully registered some users by the way. Thanks so much to both of you.

As RC4 has to be ideally converted to Hex beforehand for always a true result but i notice the script does txt2Hex so the number first has to be decimal or characters. How would it possible to accept a Hex code and output as Hex. Basically input hex > RC4 > output hex.

It is not hard, but what is the point? The binary or built-in encryption is faster, safer and handles binary data.

I have read up on TEA encryption and there is several weaknesses. THe original TEA maybe more than adequate for this protection neverless in the name of completeness and being a encryption expert concerned with security very much i thought you would of gone for the stronger XXTEA to correct the weaknesses in the original TEA.

The included function is XTEA. Still, for higher speed and security, use the Windows' built in AES.

I've gone through the thread and installed two libraries.
--SWProtect-GUI.ahk
--SWProtect-Internal.ahk

from here: link


added this code to my script:



and get this error message:


________
Hotels In Mexico

I think you are mixing the two methods.

You either #include, or put it in the library.

So, your script may work if you do ONE of these two options:
1. Remove the #include directive.
2. Put the TWO SW*.ahk files in the same folder as your script.

I never worked with the library option - I am always including.

HTH

_________________
Sector-Seven - Freeware tools built with AutoHotkey

I moved things around - I now have this:

these two files are in the includes folder

--SWProtect-GUI.ahk
--SWProtect-Internal.ahk



when I run the script now, it yields:

________
Toyota ad engine

There is a message, you are not using it right.

Notice that there is a test code inside the library itself.
As a general rule, I would suggest that when there is such a code, use it before you go on with deeper implementations - take it one step at a time.

Another general rule, includes are usually to be used after your Return statement unless specified otherwise.

That said, please do the following:
1. Make sure that both SW files are in the same folder
2. Create a new script and copy the below code into it
3. Make sure that folder does not contain any INI or any other file for that matter (just to make sure we have a clean testing environment)

The code for the test script:


If you have done this correctly you should see a window popping, telling you that the application is not registered.

_________________
Sector-Seven - Freeware tools built with AutoHotkey

thanks, it was a path problem in the SWProtect-GUI.ahk file and a problem of when I included SWProtect-GUI.ahk in my file.


I have it all sorted out now.
________
Gs400e

Is there a problem when the user does a Windows re-format with this script or will the same code still be ok?

If COMPUTERNAME, HOMEPATH or USERNAME changes, the user has to re-register. You can always change the PC data tracked in the SW, if you want more or less protection.