Securing my app with serial number

  • Thread starter Thread starter andrew
  • Start date Start date
A

andrew

Hi there,

I am pretty new to VB.net so excuse me if this sounds simple.

I have an application which i want to distribute over the internet -
now i know it probably wont be possible to completely secure it from
people copying and distributing but i would like secure it as much as
possible.

I would like for when the user buys the software for them to be sent
some sort of activation key that will unlock the software. What would
be the best way of doing this? Interfacing some sort of online
database? I would like to avoid this if possible since i have a PDA
version of the software....

Would it be feasable to create some sort of hash - that encompasses
some user information that is then sent to them as a serial number....

I really dont know guys i am clutching at straws here. Any help woudl
be much appreciated.
 
Hi there,

I am pretty new to VB.net so excuse me if this sounds simple.

I have an application which i want to distribute over the internet -
now i know it probably wont be possible to completely secure it from
people copying and distributing but i would like secure it as much as
possible.

I would like for when the user buys the software for them to be sent
some sort of activation key that will unlock the software. What would
be the best way of doing this? Interfacing some sort of online
database? I would like to avoid this if possible since i have a PDA
version of the software....

Would it be feasable to create some sort of hash - that encompasses
some user information that is then sent to them as a serial number....

I really dont know guys i am clutching at straws here. Any help woudl
be much appreciated.
Click to expand...

Andrew, this isn't what you want to hear, but it's one viewpoint.

IF your program is one in which the pirates are going to be interested then
there is practically no amount of 'protection' you can provide, there's one
of you and <probably> millions of them - you spend two moonths 'protecting'
your program and as a group they can crack it in a couple of days (at
worst).

I've seen keygens appear within minutes of some program being updated with
the newest anthi-theft device. If you provide 'John' with the key to his
program - and 'Frank' wants a copy then John just gives him a copy with his
key ... no win. If you tie it to some system configuration then you're
going to have some unhappy customers when they, oh add a new hard drive or
RAM, for example.

MultiMedia Australia has taken the approach that everytime they issue an
update the require the authorized use to request a new key. That probably
slows down the copying, but it also gets irritating (for me as a legit
user) since I have to install the update and then go to their website to
request a new key which is sent in a day or two - irritating.

Now for the professionals responses. //al
 
I dont mind tieing the software down in this way - especially since the
software is sold in combination with a monthly subscription.

It is a niche product - and really as much as i can tie it down the
better, just need a feasble solution for doing this.
 
Hi there,

I am pretty new to VB.net so excuse me if this sounds simple.

I have an application which i want to distribute over the internet -
now i know it probably wont be possible to completely secure it from
people copying and distributing but i would like secure it as much as
possible.

I would like for when the user buys the software for them to be sent
some sort of activation key that will unlock the software. What would
be the best way of doing this? Interfacing some sort of online
database? I would like to avoid this if possible since i have a PDA
version of the software....

Would it be feasable to create some sort of hash - that encompasses
some user information that is then sent to them as a serial number....

I really dont know guys i am clutching at straws here. Any help woudl
be much appreciated.
Click to expand...

There are 3rd party tools out there that can help with this sort of thing.
Another issue you need to worry about is people decompiling your code and
removing any copy protection routines (there are also tools for decompiling.)
 
What tools are we talking about here? I am after a solution that will
stop the casuals passing the software on. Im not expecting to stop the
people who are really determined.
 
Hi Andrew,

Here's (approximately) how I do it, with some pseudo-code.

The app has two passwords hard-coded into it, we'll call them A and B.
When the program is installed, it generates a string:

Right(CDriveSerialNo() & "|" & Rnd(1) & "12345678901234567890", 20)

It then encrypts that string with password A, converts it to a hex
string, and stores it in the registry as a challenge code. When the
user wants to register, the software displays that code, which has to
be sent to me.

I then de-hex and decrypt the string, re-encrypt with password B and
re-hex, and send that string as an unlock code to the user. The
program stores that string in the registry as well. At any time, it
can de-hex and decrypt the strings with the appropriate passwords and
compare; if the strings match, the program is registered.

I can also insert some extra data into the beginning of unlock code
prior to re-encrypting it, which the program can use as flags on what
features to unlock:

If DecryptedChallenge = Right(DecryptedUnlock, 20) Then
Registered = True
UnlockFlags = Left(DecryptedUnlock, Len(DecryptedUnlock) - 20)
End If

If the user later contacts me saying they need to reinstall the
software, they have to tell me why. I keep their last keycode on file
so I can determine the drive serial number, which gives me at least a
little information to verify their story and determine whether this is
a legitimate reinstallation or not.

This isn't the most secure method in the world, but it works for me. I
have a small userbase of technically-challenged people, and little
demand for this application outside a tiny niche.

One obvious step in improving the security of this is to obfuscate the
hard-coded passwords A and B, so they do not appear in plain-text in
your program when viewed in a hex editor.

Beyond that, there are many methods to foil a cracker, and many methods
crackers have to foil you. Google is your friend for techniques, as
well as commercial protection packages that implement these techniques
for you. I'm afraid I don't have links/names handy, or experience with
any of these packages.

Hope this helps!
 
Hi Andrew,

Here's (approximately) how I do it, with some pseudo-code.

The app has two passwords hard-coded into it, we'll call them A and B.
When the program is installed, it generates a string:

Right(CDriveSerialNo() & "|" & Rnd(1) & "12345678901234567890", 20)

It then encrypts that string with password A, converts it to a hex
string, and stores it in the registry as a challenge code. When the
user wants to register, the software displays that code, which has to
be sent to me.

I then de-hex and decrypt the string, re-encrypt with password B and
re-hex, and send that string as an unlock code to the user. The
program stores that string in the registry as well. At any time, it
can de-hex and decrypt the strings with the appropriate passwords and
compare; if the strings match, the program is registered.

I can also insert some extra data into the beginning of unlock code
prior to re-encrypting it, which the program can use as flags on what
features to unlock:

If DecryptedChallenge = Right(DecryptedUnlock, 20) Then
Registered = True
UnlockFlags = Left(DecryptedUnlock, Len(DecryptedUnlock) - 20)
End If

If the user later contacts me saying they need to reinstall the
software, they have to tell me why. I keep their last keycode on file
so I can determine the drive serial number, which gives me at least a
little information to verify their story and determine whether this is
a legitimate reinstallation or not.

This isn't the most secure method in the world, but it works for me. I
have a small userbase of technically-challenged people, and little
demand for this application outside a tiny niche.

One obvious step in improving the security of this is to obfuscate the
hard-coded passwords A and B, so they do not appear in plain-text in
your program when viewed in a hex editor.

Beyond that, there are many methods to foil a cracker, and many methods
crackers have to foil you. Google is your friend for techniques, as
well as commercial protection packages that implement these techniques
for you. I'm afraid I don't have links/names handy, or experience with
any of these packages.

Hope this helps!
 
Hi Andrew,

Here's (approximately) how I do it, with some pseudo-code.

The app has two passwords hard-coded into it, we'll call them A and B.
When the program is installed, it generates a string:

Right(CDriveSerialNo() & "|" & Rnd(1) & "12345678901234567890", 20)

It then encrypts that string with password A, converts it to a hex
string, and stores it in the registry as a challenge code. When the
user wants to register, the software displays that code, which has to
be sent to me.

I then de-hex and decrypt the string, re-encrypt with password B and
re-hex, and send that string as an unlock code to the user. The
program stores that string in the registry as well. At any time, it
can de-hex and decrypt the strings with the appropriate passwords and
compare; if the strings match, the program is registered.

I can also insert some extra data into the beginning of unlock code
prior to re-encrypting it, which the program can use as flags on what
features to unlock:

If DecryptedChallenge = Right(DecryptedUnlock, 20) Then
Registered = True
UnlockFlags = Left(DecryptedUnlock, Len(DecryptedUnlock) - 20)
End If

If the user later contacts me saying they need to reinstall the
software, they have to tell me why. I keep their last keycode on file
so I can determine the drive serial number, which gives me at least a
little information to verify their story and determine whether this is
a legitimate reinstallation or not.

This isn't the most secure method in the world, but it works for me. I
have a small userbase of technically-challenged people, and little
demand for this application outside a tiny niche.

One obvious step in improving the security of this is to obfuscate the
hard-coded passwords A and B, so they do not appear in plain-text in
your program when viewed in a hex editor.

Beyond that, there are many methods to foil a cracker, and many methods
crackers have to foil you. Google is your friend for techniques, as
well as commercial protection packages that implement these techniques
for you. I'm afraid I don't have links/names handy, or experience with
any of these packages.

Hope this helps!
Click to expand...

What's to stop the registered user copying both registry entries and
importing them onto another PC though? The app will presumably still check
these quite happily and say it's registered. Or does it re-generate the key
each time it runs by checking the disk serial number again?
James
 
james said:
What's to stop the registered user copying both registry entries and
importing them onto another PC though? The app will presumably still check
these quite happily and say it's registered. Or does it re-generate the key
each time it runs by checking the disk serial number again?
James
Click to expand...

Good catch. I forgot to include that detail, it decrypts the stored
key on startup and compares the drive serial number.

Actually, I don't store this stuff in the registry at all; I hide it
somewhere else. Like I said, this is "approximately" how I do it. I
gave enough info to make a working system, but I'm not giving away
*all* my secrets. :)
 
Good catch. I forgot to include that detail, it decrypts the stored
key on startup and compares the drive serial number.

Actually, I don't store this stuff in the registry at all; I hide it
somewhere else. Like I said, this is "approximately" how I do it. I
gave enough info to make a working system, but I'm not giving away
*all* my secrets. :)
Click to expand...

Don't blame you!
 
Back
Top