No announcement yet.

Serials - programmers achilles heel

  • Filter
  • Time
  • Show
Clear All
new posts

  • Serials - programmers achilles heel

    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.


  • #2

    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.


    [email protected]


    • #3
      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



      • #4

        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.


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


        • #5
          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.



          • #6
            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

            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

            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:

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




            • #7
              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.



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


              • #8
                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

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

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

                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.


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


                • #9
                  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).]
                  <b>George W. Bleck</b>
                  <img src=''>


                  • #10
                    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.


                    [email protected]

                    hutch at movsd dot com
                    The MASM Forum



                    • #11
                      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..