Serials - programmers achilles heel

[Wayne Diamond]

Ive just spent the last 45 minutes reading threads regarding how to protect serials from being sniffed out and various other software protection schemes... i dont want to start any debates over anything, but I'd like to say this. My software has been cracked by teams such as Phrozen Crew and The Exterminators as well as various others - that was, while I was using SERIALS (aka. strings!) for registration purposes.
We switched to using encrypted keyfiles - that was over 6 months ago, and there have been no further cracks for my program yet. Serials can be sniffed out of memory, but keyfiles require a lot more work on the crackers behalf, and it appears to be working so far - 6 months uncracked seems to be proof that it slows things down a bit! (Although its naturally just a matter of time before a patient and dedicated cracker comes along and makes a memory patch of some sort - its also CRC32 'wrapped' , and packed using ASPack)
So that's my 2 cents - use keyfiles, not serials.


------------------

[Gregery D Engle]

Wayne,

I would dislike that method because how do you distribute the
key file?

You would have to send it via email or send a floppy disk or
even worse have them download an installation program (users hate
installing something again)

I think serial numbers have an advantage because the cost
of distribution is almost none.

Thanks,

------------------
-Greg

[Wayne Diamond]

Tell me how sending a 20-byte serial is different from sending a 200-byte keyfile? My favourite installer package (CreateInstall 2000) uses keyfiles, and ive seen several other commercial apps that do. Serials can be too easily sniffed from memory, but a keyfile can contain many different 'checks' , and the keyfile cannot be dumped from memory


------------------

[Gregery D Engle]

Wayne,

I'm not talking about impossible here. I'm talking about support
issues. Sending a file through email will cause many many
support issues for novice customers. Have them print out
an email with a 10 key serial number and have them type that in
is common sense. But to have them save a registration key file
and then do more steps will cause problems, and what if there
email client doesn't support MIME, or even worse you instruct
them to cut and paste.

Just a big hassle. It would work perfectly if you provided a
serial number and that serial number was used to connect to a
website that downloaded a key file (which will only be online for
48 hours or so) and it will install itself. Then it will work.

------------------
-Greg

[This message has been edited by Gregery D Engle (edited September 05, 2000).]

[Wayne Diamond]

I find that saying "Just put this file in your <name of program> directory and youll be registered" is easier than telling them to click Help | Register | type in their full name, type in their case-sensitive serial. We're using it successfully and haven't had any problems, and like I said - there are no cracks available for my program, as the latest crack (serial) is 6 months old and doesnt work with the latest versions... Proof enough to me that its just as easy to use keyfiles as it is to use serials, and that it makes things a lot harder for crackers Also, the user has the convenience of being able to make a backup of the keyfile and easily copy it back later if bad things happen. Youll also notice many "Serialz" websites that have lists of serials but not files - another keyfile advantage. But the bottom line is, if you use a serial, it is usually only a matter of minutes to hours before it can be cracked - and thats not even using debuggers, thats just using memory tools.



------------------

[Tim Wisseman]

I am using serial numbers and have had many hacker groups,
including some very skilled Russian and German groups trying
to break my serial number system for over a year now, nobody
has even come close to getting through my first line of
defense.

I use a system that tells the user that they are registered
if they enter in a serial number that check sum / hashes
correctly, but the program instead self destructs, slowly.

Over 50 points in the program that are in the heart of
important code depend on the serial number. If the serial number
is wrong the program will crash or mangle its own data at
random.

The serial number engine that made the serial number is not
fully included in the released program. Only part of the serial
code is checked. I can "turn on" a new part of the serial number
at any time with new releases of the program by un-rem'ing
one line of code that would cause all currently working
hacked serial number to fail.

I have used ideas that I found in Applied Cryptography plus
I have studied the information on hacking on the major hacking
web sites.

I have phoney strings that are labled "ValidSerialNum" that
do nothing. I use time delays of up to 5 minute before telling
the "user" something is wrong. My DLL's and EXE are checksumed.
There is a time delay of 5 seconds before the program accepts
the new serial number. There are 8 different validation checks,
the one used depends on the day of the month. I store some data
on my reg key system in the color index of a bmp file that is
part of the resource for the program. I have fake strings that
the user sees when they type in the reg code in functions that
look like they do something, but do not. The real reg strings
are encrypted. I have at least 150 decoys. If you hack a decoy
the program will tel you that you are registered, when you are
not really. I make bogus calls to encryption stuff that does
nothing at all.

My goal was not to make a perfect serial code system, it was
to drive any hacker that tries to crack the system crazy!

If you want to have a look at my program that uses an insane
serial code system it is the play by email game Planets 4 at:
http://www.vgaplanets.com/v4beta.htm

If you wish to take a few minutes to crack the serial code to
planets4.exe, be my guest.

Tim


------------------

[Mike Joseph]

Hi Tim,
First, i love VGAP 3.0. One of the first PC games i ever played
and its the first PC game i ever bought. Havent got into
v4 yet as i'd rather wait til its finished.

That said, what are your thoughts about people who wind up
obtaining a semi-hacked version of the program and then when
running into the other still active "self destruct" parts of the
anti-hacker code, write it off as a bug in the program which
then influences them to stop playing. I suppose it can be assumed
that they werent going to buy it anyway, so who cares if they
think its buggy. But there is the chance they might have if they
felt it wasnt unstable. Another potential problem is that they
bad mouth the game to other would be buyers, saying that its
very buggy and crashes with "strange" error codes all the time.
This could potentially drive some customers away.

I guess im playing devil's advocate at this point since its
evident that v3 of VGAP has been very successful (especially for
a shareware game) and I can only assume that if the game were
easily cracked, registrations would have been far less.

-Mike


------------------


[This message has been edited by Mike Joseph (edited September 05, 2000).]

[Tim Wisseman]

I use error messages like:

"The REG.KEY file has been hacked! Contact Tim Wisseman At
[email protected] at once to report this."

"The PLANETS4.EXE file has been damaged, please reinstall
program."

"SERIAL NUMBER ERROR, please enter your serial number again."

"I'm sorry, I can not do that. You are using a hacked serial
number."

When the error hits they know it was due to a reg problem and
not a program error. The "Self destrust" removes functions
from the program and replaces them with error messages like you
see above.

Because it is a game, random bad events begin taking place
in the game. Like "Evil hackers have stolen 100000 megacredits
from your bank account. . ."

I would never cause the program to become "buggy", hackers
and crackers know that they are running into the copy protect
part of the program.

So far it has never triggered as far as I know. Planets 4
beta remains uncracked.

You are right, making a program "go buggy" is a bad move,
it will get you bad word of mouth if the program gets cracked.

Tim


[This message has been edited by Tim Wisseman (edited September 05, 2000).]

[George Bleck]

One of the simplest methods I've used in protecting my programs from hackers relies in the string tables themselves.

Typically you just need to search for a few key words in memory and you can crack the keycodes, but what if you "encrypted" the words for each dialog themselves?

I don't mean to literally do a 128bit encryption, but a simple alphabetic replacement scheme works great.
How do you search for the word "registered" in memory when it's actually "tfqpzuftfy" ?

I would like to use internet aware applications, but I also hate them from other people on the same coin. Who knows WHAT they are sending over the link.

BTW Wayne, I guess you've never heard of OSCAR. It contains MANY keyfiles as well as serial numbers and key generators. I work very closely with the data security department in my company and I've seen it all, or a least most of it

------------------
George W. Bleck
Senior System Engineer
KeySpan Corporation

[This message has been edited by George Bleck (edited September 05, 2000).]

[Steve Hutchesson]

I am much of the view that there is no single best method of protecting
software from crackers or hackers. From what I have seen on the market,
its still a demand based situation where if the demand is high enough,
someone will break the protection system.

I have seen cracks of 512 bit encrypted keyfiles so the guys who are doing
this stuff are good at what they do. Probably the greatest protection is
to write stuff that no-one can be bothered cracking, you are at least safe
there but it may not do what you need if it does not sell.

From what I have seen, every version of Ian Mead's Ultra Edit has a crack
for it that is released very shortly after a new version is released. It
is effectively a situation where the demand is so high that it will keep
on being cracked.

Using a new technique every release makes life more difficult, not using
known techniques makes the cracker do more work to find out how the scheme
is done, forget serials, the kids practice on "crackme" examples that are
a lot harder than most serial protection schemes.

Don't give any warning if the keyfile or serial is incorrect, let it go
out with a bang, a binary file is a big bag of numbers that are critical
to the operation of the file, messing almost any of them up will crash the
file and it is no real joy to find where or why.

A mistake so many software authors make is not understanding the
difference in landscape between a high level language and what it looks
like after being compiled in assembler. Most of the so called smart tricks
in high level languages are trivial in an assembler dump or debugger.

Without knowing at least something about what a compiled file looks like
in binary leaves the software author dead in the water writing software
for someone else to make a profit from.

Probably the only reason why cracks and serials exist is because the
complete code exists in demo or unregistered form, if the complete code
was not there, it simply cannot be cracked. This is a formula for having 2
versions of any given program, a demo version and a release version that
only gets sent to paying customers with their name compiled into it.

This is not difficult to do with a conditional compile directive, what
is not there cannot be cracked.

It can still end up on a warez site but few want their name on hot
software on a warez site so the risk is not all that great.

Regards,

[email protected]

------------------

[Borje Hagsten]

Like Tim, I also use a technique that doesn't check the entire
reg. code at any given time, and like for Tim, there have been
no working cracks available for it.. yet.

I also use a multi-level system, with several different ways to
check the code. The first level, at start-up, only checks a few
characters, the next is activated when the user activates the
"Open file" dialog box, etc, etc.

This makes it real hard for any cracker, because even if they
manage to break the first level, test it by simply starting the
program and typing in their cracked serials, it will fail at a
later point, when some other function/checkpoint is activated.

A bit nasty, because if they release the crack that works for the
first or even second level, it will guaranteed fail at some later
checkpoint, and, even if someone would manage to break all levels,
I can easily change what parts of the code to be checked in my
next release..


------------------