Creating a software Lock

I recommend putting your software lock in a hidden location in the registry.

That is a good suggestion.
But Waht will happen if user installs Windows again?
Do you have any experince about making locks?

>>Do you have any experince about making locks?
Yes, I had a program call GameMenu95.
I had people trying to hack it all the time.  I sold it for about 3 years, and know one was ever able to hack into it.

I use to see a post in the hack newsgroups all the time.  Have different people asking if anyone could make a hack for GameMenu.
No, one ever replied with any type of success.

I used the registry to hide the lock.
If you ever tried looking for something in the registery, even when you know the address of the key, it's still almost like looking for a needle in a hey stack.
If you put it in the registery, make sure to give it a name that has nothing to do with your program, and has no key words, that can be searched for.
Make the registry key look like a system function.

Also, a good idea, to put some decoys.  I put a fake registry key for my GameMenu program in an obvious location in the registry.

how abt using Visual SourceSafe

Mahesh

> I sold it for about 3 years, and know one was ever able
to hack into it.

A simple registry key and no one did patch it ?
Amazing.
A good registry tracker and it's patched in 2 passes ...

except you implement some further security levels ... ; )

> I sold it for about 3 years, and know one was ever able
to hack into it.

<g>

>>except you implement some further security levels ... ; )

I had 5 different types of lockout keys.  And each type had a couple of decoys.
1. Registry Key
2. System.ini Variable key
3. An INI variable key in the game that was controlled.
4. Custom file with a hidden Variable key
5. (Traded Secret) shhh!

The keys had the time the program was first installed.  And the program would stop working after 4-weeks.
If anyone of the keys failed to match, the program would stop working.

The program also compared the system date with certain system file dates.
So if a user tried to change the system date, the program could still pick it up.
If the system date had an earlier date then the system files, the program would stop working.
There were more security features, but I don?t remember them all.

You would not believe the email I would get.   It was pretty hilarious.

One user complained to me and said that he did not like the fact that there was some hidden data in his computer locking out this program.  He said that he didn?t like it because this hidden data was taking up space in his computer.  He demanded that I tell him were this data was at so he could remove it from his computer.

I also got a few HATE mails.  I also had some users begging me to give them the program for free.

By the way, the main reason I went through all this trouble to lock out my program was because the first program I create (Dos Ver of GameMenu95), I had a simple lockout feature.  And I had a user email me, bragging the he had figured out a way to by pass my lockout feature.  He then posted his method on the web, and in the newsgroups.
Well as you can imagine, that piss me off to no end.  So when I made the Windows version of the program, I made sure it was going to happen that easy again.

I still expected that someone was going to eventually hack into it.  But to my surprise, it never happened.  Or if someone did hack into it, they never advertised it.

Axter
  you have a good experince in windows registery.
but ,What do GameMenu95 users do if they have to install Windows again or format
their H.D.D?

If they reinstalled windows again, the information was also stored int the system.ini, Program.ini, and program directory.
Even if you reinstalled windows again, it would not erase the program.ini directory, nor the information in the program's directory.

If the user reformted the drive, yes, this would be a way to bypass the security.

Of cource, since my program would always install an new timeout lock when none was detected, that would mean that the user would have to reformat the entire drive every 4 weeks.

If a user wants the program that bad, he's welcome to it.

FYI,
My program also check to make sure all five locations had the timeout lock date.  If one was missing, it would reinstall it.

If you make modifications to the system.ini, program.ini, or any other file that you want to keep your lock in, make sure you keep the file date as it was before you modified it.
So first check the file date, then make changes, then change the file date to what it was.

Axter
  Can you explain more about timeout lock and why user
has to reformat his drive every 4 weeks?

I had five keys in the following locations:
1. Registry Key
2. System.ini Variable key
3. An INI variable key in the game that was controlled.
4. Custom file with a hidden Variable key
5. (???????)

All five keys contained the same date, which would be the date the user first used my program.
The date was in a simple encryted format, so the user couldn't use the startup date for a simple keyword search.

When my program started up, the first thing it would do is look at all five keys.  
1. If it did not find any keys, it would create a NEW with the current date (in all five locations).
2. If any key was different, it would pick the key with the oldest date, and then change all the other keys to match the oldest key.
3. It would create any missing key with the date of the oldest key.

If the date of the oldest key, was older then 4-weeks, my program would then lock-out.  It would send the following message:
"I'm sorry, but you have used this program pass the trial period, and you're now required to register this program in order to continue."
After the user press OK, the program would end.


So with the above in mind, if the user formated the drive, and then ran my program, my program would create new keys with the current date.  This means the user had 4-weeks to use my program before it would lock him/her again.

So if the user really wanted to bypass my lockout, he/she could do so my formatting the drive every four weeks.  I don't think too many (if any) users would do that.

By the way, I did not use any of the standard methods for registering the program.
Most shareware programs use one of the following methods to provide a register version of the program.

1. Have a registered version of the program, and a shareware version of the program.
2. Have the shareware program automatically convert to a registered version when the user enter a Register-Key-Number.  This method had the following sub-methods:
  2a. The key number was the same for all users.
  2b. The key number would be different from user to user.
  2c. The key number would be different from computer to computer, and only work on one computer.

I did not use any of the above methods.  

If I used method (1), hackers could buy one program, and then distribute my registerd version on the hack sites.  Not only that, but then I would have to maintain two versions of the program.  Double the possibility of bugs.

If I used method 2a or 2b, hackers could publish the key throughout the web.

If I used method 2c, when ever my users upgraded their computer, the key would no longer work.

Because of the above limitations, I went with a different registration method.
My program used a registered-key file.  The file was 1024-bytes in length.
The first 256 bytes of the file contain the user information in simple text format.
It contained the user's name, phone, email-address, and mailing-address.
Hidden inside the remaining 768 bytes, was a unique register-key number.
The remaining 768 bytes also had encrypted numbers that coincided with the first 256 bytes.
If the user changed any part of the first 256 bytes, it would make the register-key-file invalid.

So if the user distributed the register-key-file, he/she would have to distribute their personal information.

Since almost all of my purchases were done via credit card, they could not give false information for their name and zip code.
And since all the credit-card purchases were delivered via email, they could not give a false email address.  My web-site form, which took the credit card purchases, did not accept an email address that was associated with any of the common FREE email-address web sites.

I never did find anyone distributing the register-key-file, but I had a backup plan if they did.
Since each registered-key-file had a unique ID, I had my program setup to reject a list of ID's.  This list was programmed into the code.
If I had found a register-key-file distributed in the hack sites, I was planning to downloaded it, and pull the ID out.
Then add the ID to my current CODE, so that the register-key-file would be rejected.

The result was that any upgraded version of my program would not work on the pirated register-key-file.

When a user purchased my program, I emailed them the register-key-file.  In the email I also sent a warning message, which would inform them of the consequence of distributing the register-key-file.
I also told them that the register-key-file contained their credit card number in encrypted format.  And I put a disclaimer stating that I was not responsible if their credit card was acquired as a result of illegal distribution of the register-key-file.
This was just a scare tactic, because the credit card number was NOT in the register-key-file.

Axter
  Thanks for your describtion.