Fog Creek Software
Discussion Board




Good Serial Codes

Have someone read an article explaining serial code usage in shareware apps?
I have written a routine which does very good code generation/validation. The problem is that it is one-way.
I want to have one code that validates and one that generates the code.
I have read a lot of software protection articles and I know that Serial Generators are created by crackers by just extracting your validation function out of your code. Simple.
So I need it to be like PGP with the secret and public key.

Anyone know where can I find the math or theory behind this, preferably directly related to the serial number generation?
Thanks.

Boris Yankov
Tuesday, January 07, 2003

See the topic below -Protecting shareware.

Slava
Tuesday, January 07, 2003

I have read it already.
It has nothing to do with the generating of good serial numbers.

Boris Yankov
Tuesday, January 07, 2003

Public keys don't work with shareware. Here's everything you ever wanted to know about encryption but were afraid to ask:

http://www.faqs.org/faqs/cryptography-faq/

Jan Derk
Tuesday, January 07, 2003

If someone wants to steal your software badly enough, he will. You can't stop that. My advice: Make a simple serial number scheme to help you keep records and to help honest people use your software easily. Then spend your time and creativity making a great program that people will want to buy.

Harvey Motulsky
Tuesday, January 07, 2003

Public keys do work with shareware. They enable you to include a registration key validator in your program that can validate codes but not generate them. This way, a hacker cannot create a registration key generator by reverse engineering the program. They can still, of course, patch the program to circumvent the validator. In the end, it's not worth it.

Frederik Slijkerman
Wednesday, January 08, 2003

You're right. Let me rephrase that. Public key algoritms are a very good way to prevent key generators, but they are impractical, because of the length of the registration codes which will annoy your legitimate customers. But some might not find this a big issue at all. In addition, RSA used to be patented, but I think it has been expired by now?

The main problem is that asymmetric encryption does not prevent crackers from circumventing the validation routine in your shareware application. If you are really worried about an application being cracked it's better to compile separate trial and registered versions. Code that doesn't exist is hard to crack. Personally, I would not do this either, because you force your customers to download the application again when registering.

In the end you'll make more money by putting the hard work in improving your application and not annoying legitimate users.

Jan Derk
Wednesday, January 08, 2003

I have put some thought in that matter so I continue to discuss...

This is important. I do not intend to make it harder for my clients. And I really meant something like a prettty short key which will not be very effective in a cryptoanalysis way but it will keep the crackers from creating serial generator.
Because I am from a country where the piracy is wide spread I know how it works. I do not think that I will rise my sells in my country - people has very little money and it is unlikely that they spend $30 for a good product, not because they want to steal it, but beacuse their salary is $150 and it is not enough even for simple things.
So my concern are the people which has the money but do not want to give them. It is VERY easy to get a crack/serial. You may look at www.cracks.am there is crack for everything.
Then you may ask why do I have to protect something that will be cracked eventually? Well it will not be :)
I really think that when I finish my app it will WORTH cracking and it will be popular.

Here is my strategy for everyone to use:
1. Make good serial key validation so no serial generator can be made (this thread's topic).
2. Release often small updates, like 1.01, 1.03, 1.1 and do not keep the old for download. This way if a cracker makes a crack it will be outdated very soon. And if the user don't find an old version to apply the crack - voila!
3. Make a Black List. Store all serial numbers which circulate in Internet and DO NOT ACCEPT them in the future versions.

So these 3 points may lower the piracy drastically without making any difference for the registered users.
 
I think you see now why the "Good Serial Numbers" are important.

Boris Yankov
Wednesday, January 08, 2003

Right, if frequent updates are valuable to your customers then binary patches won't keep up easily...

It's not really worth employing a sophisticated cryptographic scheme - you'll always have some code like

if(key_is_valid_using_awesome_crypto_scheme()) {}

and crackers will just hack the 'if' to take the other branch.

Schemes that encrypt the binary itself with a key are more resistant to this kind of attack, but that's a lot of effort to implement...

Dan Maas
Wednesday, January 08, 2003

Serial codes are hard for user to type.

If your ID is, e.g., a 128 bit, you could use mnemonic encoding to encode it as 12 readable  international words - see [ http://tothink.com/mnemonic/ ].

For example, the 64 bit number  "8f9240688685a1e9" (pronounced eight-eff-nine-two-four-zero-six-eight-eight-six-eight-five-aey-one-ee-nine" is encoded into the 6 word mnemonic "magic-slang-crimson--inch-calypso-ibiza".

Faster to type, easier to remember, easier to read out to someone through the phone, has some built in error resilience (the words are different enough that if you type 'itch' instead of 'inch', the decoder will still recognize you meant 'inch' because 'itch' is not part of the mnemonic vocabulary, and 'inch' is closest to 'itch').

Ori Berger
Wednesday, January 08, 2003

" easier to read out to someone through the phone"

Presuming you're only going to be dealing with the UK (how may people in the US have heard of Ibiza - and for that matter how many people in the UK know how you pronounce the "z", or that you pronounce it different in Peninsular Spanish than you do in American Spanish, or that the actual name of the island is Eivissa which is a Catalan word and pronounced differantly anyway!).

It's normally quicker to send a word to another country by surface mail than it is to read out over the phone (Arabs don't distinguish between b and p, Japanese between r and l)

Stephen Jones
Thursday, January 09, 2003

Again it's much better to add features to your product that to waste time on anti-cracking code, but if you're bored you can have so much fun with crackers. Fighting them is where spaghetti code and fuzzy naming really help out. They have to reverse engineer your validation routine, so making your code really complex is a good way to get them frustrated.

Like Dan indicates if your code looks like this

if RegistrationCodeValid then ...

the bad guys will need about 2 minutes to hack it. One trick to prevent this is by setting a magic number deep inside the validation code (e.g. MagicNumer := 7;). Now if somewhere else in your application Registered is true and MagicNumber is not 7, you know that you have been hacked.

The problem is what to do with this knowledge.

At one point in time we used to raise an obscure "Fatal exception 362" message. That was not very smart, or more honestly really stupid, for a couple of reasons. First, we got contacted by potential customers that said "It's a great application but sometimes I get this weird Fatal exception 362". Being told that meant they used a crack, was a very efficient way to scare the hell out of them and more importantly get their wallet as far away from our order form as possible. Other users would just think our software was buggy, because after all it did raise weird exceptions for no reason.

Obviously, we stopped doing that real soon. However, there are still a couple of bad cracks available that partly corrupt our application and causes weird errors. If we get contacted now, we tell the customer that this error is generally caused by an corrupted download, but that we've occasionally seen this happen because of a bad crack. Generally, they respond telling us that yes it was a corrupted download. Yeah right. As if our software would install in the first place if there was 1 bit wrong... Offering them a graceful way out does improve sales though.

So what should you do when you notice that the application is cracked? I recommend to reset the application into being unregistered again. But don't do it immediately or the cracker will notice it and start hacking your MagicNumber protection.

It's much more fun to let him think he cracked your application while in fact he didn't. When noticing that the application is cracked, store the crack date in your database. Now wait 3 weeks and 10 application starts. Then reset the application to being unregistered again. Self healing code is so frustrating for the bad guys.

And the customer using the crack will this time blame the crack and after having spend 3 weeks and 10 application starts chances are that he needs to get work done with your software and will register immediately.

Jan Derk
Thursday, January 09, 2003

>So what should you do when you notice that the application is cracked? I recommend to reset the application into being unregistered again. But don't do it immediately or the cracker will notice it and start hacking your MagicNumber protection.
>It's much more fun to let him think he cracked your application while in fact he didn't.

My friend (I wrote about his protection module in Protecting shareware topic) did the following thing - in the same situation (when the hacker hacks the software) the program will look like registered, but some functions will become locked. The idea behind this is that hacker will not test all the functions after hacking the software, he is too busy hacking:), and then the user (after applying the hack)will decide that this hack actually "broke" the software! These functions worked before hack! And now they don`t! Oh, this crappy hack, my copy is now broken! I`ll not use these hacks again!...
Yes, be a good boy and buy this software:)

Slava
Thursday, January 09, 2003

<<< It's normally quicker to send a word to another country by surface mail than it is to read out over the phone (Arabs don't distinguish between b and p, Japanese between r and l)  >>>

:)

The word list has been selected with phonetic distance in mind; "ipiza", "ibissa", "evisa"  and many other words are equivalent to ibiza as far as the decoder is concerned.

Really, it's an error correcting code designed with human perception in mind, much like modems use error correcting code designed for phone lines. It ain't perfect, but it's hell of a lot better for anything requiring a human in the loop than other alternatives.

If you ever tried to read an IPV6 address to someone over the phone, or memorize it, you'd appreciate mnemonic encodings a lot more. And activiation keys are no different.

Ori Berger
Saturday, January 11, 2003

"The word list has been selected with phonetic distance in mind; "ipiza", "ibissa", "evisa"  and many other words are equivalent to ibiza as far as the decoder is concerned. "

So, if I type Ibeethuh (which is a fair English transliteration of the Spanish pronunciation) your program will still accept the serial code as valid?

Also Karipso and Kalibsoh?

And if you're only using just over a thousand words can't the serial be cracked by brute force?

Stephen Jones
Saturday, January 18, 2003

No software that IS the full version (as in, uses a key to unlock the time constraint/extra features) can ever be secured.

And using a 'blocked list' is also just as impossible, as a truly reverse engineered key-maker can create every possible code the program will accept.

Also, dont try anything under 12 characters for a key, it would just be brute forced.

Quite frankly, its not that hard to just uncompile, edit, and recompile someone elses programs, ive done it on many times, just to add more features to certain progranms.
(and knowing the internet, that new edited program would be quickly distrubuted.)

Bah, back to my point, its physically impossible to secure a program when you give the user all of the program to start with.

The only hope at security is to make users use a 'demo' version then download a new program after they register.
(despite the inconvenience, even then some people will distribute that registered product, and im not sure how one might stop that.)

bill
Sunday, June 13, 2004

*  Recent Topics

*  Fog Creek Home