To Ghisler. Registration keys

English support forum

Moderators: white, Hacker, petermad, Stefan2

User avatar
Blight
Junior Member
Junior Member
Posts: 55
Joined: 2003-03-22, 23:04 UTC

To Ghisler. Registration keys

Post by *Blight »

Hi,
I'm not sure if you remember, but we've talked about this a while back.

This is a bit off topic...

I'm trying to add registration keys for my program (Zoom Player) and I'm wondering if you can provide a few pointers as to good reference information for making some rather secure keys.
User avatar
JackFoo
Senior Member
Senior Member
Posts: 373
Joined: 2003-02-05, 19:53 UTC
Location: ERROR

Post by *JackFoo »

Well I'm not Christian but then again this isn't email but rather a message board... I'm not certain what algo. Christian uses with TC but it would be along the lines of PK (private key, public key); Diffie Hellman or El-Gamal etc. . In usual implementation it goes like this: private key is used for decryption of content and public key is used for encryption. If you know the private key -> you know public key but not the other way around. In this case however Public Key is inside TC (client) and it is used to decrypt while Private Key is for encryption, Christian has it I presume; So it's a backwards implementation, but this is all guesswork.

Check out openssl for some references or beecrypt which is pretty common crypto library (open):
http://www.virtualunlimited.com/products/beecrypt/.

Cheers.
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

Yes, try Elgamal or now even RSA, both patents have expired now! You may also have a look at Elliptic Curves, they create MUCH smaller keys, which users could even type in by hand.

Of course secure keys wouldn't prevent cr*cks, but they will prevent keygens, so users would have to search for a new cr*ck for each new version.
Author of Total Commander
https://www.ghisler.com
User avatar
André Martin
Senior Member
Senior Member
Posts: 245
Joined: 2003-02-05, 15:46 UTC
Location: Dresden, Germany

Post by *André Martin »

A CRC check (TC does it) makes cr*cking much more complicated otherwise malicious users need to change only a couple of bytes (via hex editor) to use it as registered version...
Browse the web with the HTTP SmartBrowserPlugin
Check your mails with the POP3/SMTP EmailPlugin!
User avatar
Black Dog
Power Member
Power Member
Posts: 1024
Joined: 2003-02-05, 22:17 UTC
Location: Odessa
Contact:

Post by *Black Dog »

[face=courier]Well - well, what a subject you, guys, are discussing here... :mrgreen: [/face]
User avatar
Maxwish
Senior Member
Senior Member
Posts: 370
Joined: 2003-02-05, 19:13 UTC
Location: .NL

Post by *Maxwish »

Keep in mind that even if a key is secure, this doesn't mean your registration process is safe, as keys always seem to end up spread all over the web.
My advice about that would be (as seen with TC): to add as much personal information as (legaly) possible to the key, so people will try to keep their key safe and won't share it with others. And make sure people don't order keys with fake names/identities.

As for cr*cks: I haven't seen anything that hasn't been beat. Remember microsoft claiming XP would never been pirated ? I'm afraid to say that the only thing that would help is to release crippeld demo's and sell watermarked complete versions. But that would only be feasible when selling low quantities. You could try to scare people from using them by claiming your software is booby trapped when tampered with, but that might also scare away customers... Another methode: if you added a bit of code (example using TC: the ftp procedure) and also encrypt it the key, then a working trial version could be released, only missing that function. When somebody registers, then that function is added to the program thru the key. Cr*cking the program won't get you the function, unless you have a valid key.
...BRB...
User avatar
Blight
Junior Member
Junior Member
Posts: 55
Joined: 2003-03-22, 23:04 UTC

Post by *Blight »

Well, I've wrote a semi-sneaky CRC32 code already.

As far as nothing that can't be cracked... that's not entirely true. The idea is to demoralize the cracker. Include time bombs that only show up days or even months later. So while your initial code may be cracked, a secondary code may only be tested say 3-4 weeks later. In the meanwhile the bad cracks are all over the web and the users would have a hard time knowing what actually works. And most crackers are loath to go back to previous "projects".

As far as public key goes. I don't think you can do that in a shared executable. You see, the whole point of public key (as far as I see it) is that two people obtain the private key in a secure mannor and then the data is sent over a public key. So the public key is insecure, but the private is always secured. But that can't really be done as the end-user isn't reliable to keep his key secure in this case.

Maxwish:
Keeping actual code in the key may be useful for TC, but it can be a headache when dealing with frequent version updates.

I'll look into RSA.
Yaron Gur
Zoom Player . Lead Developer
User avatar
JackFoo
Senior Member
Senior Member
Posts: 373
Joined: 2003-02-05, 19:53 UTC
Location: ERROR

Post by *JackFoo »

Your interpretation of Private/Public key scheme isn't correct, it can be used for many kinds of configurations. What you describe:

->As far as public key goes. I don't think you can do that in a shared
->executable. You see, the whole point of public key (as far as I see it)
->is that two people obtain the private key in a secure manner and then the ...[removed]

This is the SSL/RSA implementation, in SSL PK scheme is used to generate a symmetric key, which is then used for the rest of the session. This is done because symmetric algorithms are much faster (their keys are smaller).

In your case (the same as TC) this is what you should do:
1. You have the Private Key (secret).
2. The SOFTWARE includes the Public Key (non secret), the user doesn't have to remember or keep it.

Method:
1. You take user info and encrypt it while generating [thisuser.key] an encrypted file.
2. The user takes the [thisuser.key] and puts it inside the prog. dir.
3. The _program_ opens [thisuser.key] by using the Public Key, and tries to decrypt/validate it -> success -> all is good.

There are a bunch of things to think about (someway to update the public key perhaps etc.). You can learn more on the subject:
1. Google
2. sci.crypt (news g.) you'll have to learn a bit more before posting q's there.
3. Books: Applied Cryptography by Bruce Schneier is quite famous.

Cheers.
User avatar
Hacker
Moderator
Moderator
Posts: 13052
Joined: 2003-02-06, 14:56 UTC
Location: Bratislava, Slovakia

Post by *Hacker »

Blight,
The idea is to demoralize the cracker. Include time bombs that only show up days or even months later. So while your initial code may be cracked, a secondary code may only be tested say 3-4 weeks later.

Anyone remember Settlers? ;)

Roman
Mal angenommen, du drückst Strg+F, wählst die FTP-Verbindung (mit gespeichertem Passwort), klickst aber nicht auf Verbinden, sondern fällst tot um.
User avatar
Blight
Junior Member
Junior Member
Posts: 55
Joined: 2003-03-22, 23:04 UTC

Post by *Blight »

I believe one of the early X-Com games had a secondary security check on the very last mission of the game... how is that for causing grief :twisted:

I've created a massively over-encrypted key-gen system for my program. Need to check if it works properly, but making a ****** for the systems used would be completely impractical for a cracker.

It could still be cracked in an instant, but I'll be using some sneaky code against that as well.

Thanks for the pointers.
User avatar
soreno
Junior Member
Junior Member
Posts: 87
Joined: 2003-02-13, 13:04 UTC
Location: Denmark

Post by *soreno »

Another thing to consider is time.

Is it worth spending 20% of development time on a copy protection scheme.. Perhaps if the time was spend on extra features to the program it would result in more paying user than an effective copy protection.

Will the extra time spend give me extra paying users - or will they choose another product because the program is not as advanced as possible ?
User avatar
atomix
Junior Member
Junior Member
Posts: 33
Joined: 2003-02-05, 13:35 UTC
Location: TotalCmd Planet

Post by *atomix »

@Blight: If I'm not mistaken you are talking about implementing registration algorithm in Zoom Player. While you are free to do what you want with your program I would like to share with you my viewpoint.
I'm using Zoom Player since v2.80 and last year I donated $12 for your program: http://order.kagi.com/cgi-bin/store.cgi?storeID=47D&&
Now it wouldn't be fair to people who donated already to pay a new fee in order to be able to use the next version (I think you want to do this with the new v3.0). What do you think about it? :)

I feel somehow sorry that the donationware system used by you did not work out. As you said: "For several years I have been developing free (for non-commercial use) programs for the general public. I don't really believe in charging for software, especially since software is often highly overpriced and inaccessible to people with lower income or students who needs every dime they've got." What made you change your mind?

Finally I'd like to point out a favourite example of C.Ghisler, a program with a very weak protection - WinZIP. Despite <insert here whatever you want to say bad about it> WinZIP is the most popular program. (I personally do not use it nor like it; I am a Total Commander user after all :D) Spend your time adding more features, make your program great and people will buy it. Just my $0.02 ;)
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 48021
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

Yes, TC is also quite weakly protected. However, the fact that there are no keygens are a big plus:
- Many people fear to use cracks because they could include a backdoor or install a virus
- Companies usually don't allow cracked software

Remember that your goal isn't to minimize unregistered users - your goal should be to maximize registered users! That's the reason why TC doesn't stop working after 30 days like many other shareware tools do. If it did, people would simply delete it and install some other software...
Author of Total Commander
https://www.ghisler.com
User avatar
Blight
Junior Member
Junior Member
Posts: 55
Joined: 2003-03-22, 23:04 UTC

Post by *Blight »

soreno:
I haven't spent more than 2 days of serous work (stretched out over 7 days) implementing this. I didn't re-invent the wheel, just made it rounder where I could.

atomix:
Donationware may work for a small-time hobbiest, but if you want to make a living out of it, it's simply not enough. And trust me, I've tried several different schemes.

In the end, I'm taking a gamble and splitting the software into Zoom Player and Zoom Player Professional. The difference being that the Pro version has the DVD Support (which is a more lucrative market). The media playback capabilities will remain free for non-commercial use and the application itself won't have any of the protection the Pro version does.

ghisler:
I've actually pretty much emulated your pop-up dialog on the unregistered version. However, as far as I understand it from a previous post, the FTP code doesn't work in the unregistered version? This amounts to a crippled version that doesn't allow for full testing of the product. Right now I'm thinking giving a trial for 30 work days (not 30 days) and after that reverting the program to it's non-pro equiv. feature-set.

It's a fine line to walk for me.
User avatar
Maxwish
Senior Member
Senior Member
Posts: 370
Joined: 2003-02-05, 19:13 UTC
Location: .NL

Post by *Maxwish »

Blight wrote:However, as far as I understand it from a previous post, the FTP code doesn't work in the unregistered version? This amounts to a crippled version that doesn't allow for full testing of the product. Right now I'm thinking giving a trial for 30 work days (not 30 days) and after that reverting the program to it's non-pro equiv. feature-set.
Let me correct this misunderstanding I created:
TC is not crippled in any way.
I just used the program TC and a random function of TC (in this case the FTP) as an example on how you could use a key as extra protection for a program.
...BRB...
Post Reply