Printable View
I have been advised to store a passcode in the registry of the computer to control use of my VB.NET project. Anybody know how to go about doing this?
My project is pretty simple: VB.NET 2010, Windows forms plus Access database. I was planning to use INNO Setup. I have devised an authorization scheme that won't work if the files can simply be copied and I have been warned by Shaggy Hiker that copying might be possible so I'm considering other approaches.
Hi,
If possible please elaborate a bit more on your end goals. For example, are you making a lock-down application which will require a password to gain access to the system, or just a password for your app before specific functionality becomes unlocked to the user?
- Malocchio :)
Thanks for responding.
My application will be available for a free trial period after which the user should be blocked from using it if he/she doesn't purchase it. That would be for the whole application. There's no dividing up of the functions. I figured I would give the user a pass code when he pays. I'm open to suggestions.
Oh, okay, I understand now. I thought you were referring to some sort of password lock-down utility, my bad.
There are many different approaches you can take with this, with different levels of security:
1. Hard-code the serial keys which are allowed by the software and if the user enters them in then change a flag value in My.Settings (or data stored in a local text file/the registry). The problem with this method is that someone who has experience with cracking (or anyone who knows you are using this method) can easily change the information in the local file/registry or change it from your My.Settings and then they have beaten your registration and will use your software for free, which is not good.
2. Store the serial keys online on your server and when the user enters one in to register the product, it will connect and look-up the serial key securely. If the serial key has not been used, then access will be granted. Still, we move back to the problem of the flag for the product to know if it's been registered or not... Even in this scenario, anyone can genuinely buy the product and then monitor I/O or registry usage to identify where the details are being stored, and then just deploy a crack application which re-implements the same functionality so others can get the product for free.
3. Store the serial keys online on your server securely, but make the program require an internet connection to work, since you will be looking up a personal identifier for the system online. The problem with this would be if the user uses a new system then it causes a problem. Although, you could make it dependent on user accounts (like Adobe does).
4. Have a registry key to store the information, do comparison checks within the program like you mentioned in your original post.
Anyway, regardless of what path you take with this, just remember that no method will be full-proof. If someone is determined enough, chances are they will succeed... Since instead of finding a serial key through reversing, they could always just patch the functions used to do the checks to make it return true always for example, and so on... There are many different ways of cracking software.
Since you are developing in VB.NET I feel like I should explain something. Usually, when a program is compiled (code being compiled to generate the Portable Executable for example), most of the human-useful information will already be stripped down, but with using languages like Java or managed ones such as VB.NET or C#.NET, it's not the same as native compiling. The .NET framework relies on a Just-In-Time compiler, and the CLR (Common Language Run-time) is responsible for translating the managed code into instructions that the CPU (Central Processing Unit) can understand. Therefore, VB.NET (or any managed languages) essentially creates what you can call "byte code", it's the MSIL (Microsoft Intermediate Language). The problem with MSIL executable's is relating to security; there are many widely and free available tools which will happily take in a MSIL executable, and then it will spit back out a reversing of the MSIL code. In other words, if you have a MSIL program (so one developed in the .NET framework), you can open it up in a program like ILSPY or .NET Reflector and it will show you generated source code based on the MSIL byte-code... Now there are precautions you can take to help fight against this, but all of them can be bypassed one way or another (I would say at least 60% of the time you would be wasting your time, since most people who would be targeting you to reverse your software is most likely far more experienced than yourself in this subject). An example of a precaution would be to obfuscate your code (although a cracker can work with deobfuscation techniques), or to use a packer like UPX (which for the record, can easily be defeated with debugging as an example).
Bear in mind that top enterprise companies, including AV vendors, still have working cracks against their software even today. As long as you have a loyal fan-base who are purchasing your product and being loyal which allows you to generate a profit, I really wouldn't worry about it TOO much because like I said, anyone determined enough is likely to succeed. There are pirates for just about every piece of useful software you can think of... If there was a bullet-proof solution then no one would be installing Photoshop, Camtasia, Avast Anti-Virus for free.
Sorry I delved into the topic of reversing, but I could see the topic coming up in the future in this thread regarding the security of pass-code usage from within VB.NET. Also, please do NOT be put off by the .NET Framework because of the information I have said, it is still great for development of most things. Maybe it helped anyway, or gave you ideas in the direction you should take... But if you only want one password for any user of the program to use, you may as well just use the registry. Just remember that someone will definitely defeat whatever mechanism you put in place eventually, somehow.
Thanks for your detailed post.
As for your comments referring to VB.NET specifically, are you saying that there are in fact languages in use that are better suited to security verification functionality? (I would think not, really, because if someone can reverse engineer any code then they can discern the coding scheme, if there is one, or better yet, change the line that does the actual branch in or out of the app.)
My app, if successful, will never be as widely popular as something like QuickBooks and will be used mostly by medium and large businesses. I guess I’m mainly concerned about making a really dumb-newbie type of mistake for my first app, which is, in fact a learning-trial run for me since I have another app that I’m working on as my main event. Still, I want to do the best I can with this one. And it would only take one reverse engineer to create an all-free version and start distributing it to do a lot of damage.
I used to be a mainframe Assembler programmer.
So I just keep resetting the date on my computer so the trial period never ends??Quote:
My application will be available for a free trial period
Would you do that? Have you ever done that?
Yep! - if it proves to work. Quite a while ago I used a start-up program which just kept resetting the date for just such a scenario with one program. This trick doesn't seem to work now with programs tried. Authors seem to have got wise to that trick! :)
Okay. So you're saying in the VB.NET code I should avoid using the Date() function in any validation process?
It depends upon how much you want the product to be blocked after the trial period and/or not cracked.
An improvement on this is to have a registry key which always must have a value. This value indicates whether it is trial period, paid for or any other info you want to store. The initial value set as part of the program installation means a trial version. When a licence is purchased, the user gets an unlock code. This unlock code is used to modify the stored value as appropriate. This registry value is encrypted. You can also hold computer specific info (eg info such as the Windows product key/computer name) as part of this value so that the stored value is only applicable to one computer. This stored value should have checks etc to make sure that the stored value is valid and should be checked to be valid every-time the program is used (even for trial version). The obtained unlock code should also be applicable only to one computer so the user would need to provide computer specific info when applying for one.Quote:
Have a registry key to store the information, do comparison checks within the program like you mentioned in your original post
Making this sort of thing not easy to bypass by a reasonable competent hacker is definitely non-trivial and will require quite a lot of effort.Quote:
And it would only take one reverse engineer to create an all-free version and start distributing it to do a lot of damage
What computer-specific info would that be?
Yes, I was leaning towards something like Malocchio's no. 4 above so the user wouldn't have to be connected to the web to use the program.
Has anybody written a book or anything on this subject?
My idea was to give the user a unique code when they download the trial. When they purchase they get another code derived from the first code.
I understand no method is going to be 100 percent. I want to avoid something that is way easy to crack.
IMO I wouldn't rely upon any info (eg date) that the user can easily change.Quote:
Originally Posted by projecttoday
eg computer name (if changed could be user trying to copy validation code to another computer), Windows product key (not product id), physical address of a network adapter (again if changed could be trying validation code on another computer), hard drive serial number installed on, computer SID etc etcQuote:
What computer-specific info would that be?
The first thing someone will do in attempting to defeat/bypass is to use something like Sysinternals Procmon to capture/monitor changes to the registry, file system, network etc and to use Wireshark to examine network traffic. Any data obtained from such data capture shouldn't enable anyone to use it easily to bypass/defeat the protection.Quote:
I want to avoid something that is way easy to crack.
Unless you are going to obtain details re the user when the trial is downloaded (then you're into the area of data protection), why not just have the program generate the trial code when installed? Then when they want the full activation code they need to provide the trial code to generate the full code. Is this process going to be automated via the internet or will the user have to eg ring a number and speak to someone to get a code - or via email or?? If automated or via email then remember that any data transmitted/received over the network can be captured and examined.Quote:
My idea was to give the user a unique code when they download the trial. When they purchase they get another code derived from the first code.
I think that is what I was planning. A 2-code approach would prevent users from simply passing a working code around. So my idea was to have the program generate a code the first time the program is used. This code-generation coding is in the VB.NET program itself. This code is a true random string of characters and would be stored either in the program’s database or in the computer’s registry. This string of characters maps to another string of characters according to a coding scheme which would take a lot of attempts to figure out (though it would not be impossible to figure out) due to the fact that each character uses a different method. Once the trial period ends, code no. 2 has to be entered and checked against code no. 1 using the aforementioned various schemes/methods to use the program. This checking code would be in the VB.NET program itself as is the earlier code. Code no. 2 is saved so the user doesn’t have to re-enter it every time.Quote:
why not just have the program generate the trial code when installed? Then when they want the full activation code they need to provide the trial code to generate the full code.
Storing at least one of the codes in the registry would prevent a simple copy of the executable modules to another computer. Of course someone could copy the codes from one registry to another should they go to the trouble. Reverse engineering the program to find out the coding methods would disable the process, should someone go to the trouble. Reverse engineering the program to disable the coding methods, if that’s possible, would disable the process, should someone go to the trouble. Changing the date of the computer would disable the process, should someone go to the trouble.
Your thoughts and suggestions ...
IMO, the registry code should only work with the computer for which it was meant - for both the initial trial code and the fully-working code. So that copying it (either trial or full) between computers won't work except on the original. So I won't recommend a truly random string of chars for the time-limited code but some algorithm based upon computer-specific info. Both versions of the code need to be able to be quickly verified that they are valid (eg checksum etc etc etc) for the computer using them.
You can also use obfuscation techniques for VB to thwart reverse engineering. Do an internet search - there's loads of examples.
Good suggestions. Thanks.