_________________________________________________________________

                              FAQ for Crack v5.0a

   Copyright (c) Alec Muffett, 1999, 2000, 2001
   Revised: Wed Mar 21 02:38:38 GMT 2001 
     _________________________________________________________________

                                   Download

     * Where can I go to download Crack?
       Last time I checked: (12 June 2000)
       [1]ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack
       [2]ftp://ftp.cert.dfn.de/pub/tools/password/Crack/
       With more dictionaries/wordlists available at:
       [3]ftp://ftp.cerias.purdue.edu/pub/dict
       [4]ftp://ftp.ox.ac.uk/pub/wordlists
       A PGP signature to validate the contents of any download you might
       find, is [5]available here. My key is on the keyservers.
     * Can you send me the README for Crack?
       Better yet, there's a copy of it [6]right here. Read it yourself.
     * I can't download Crack! Will you please e-mail it to me?
       Sorry, but no. It's too big for me to be mailing it to people who
       invariably then tell me that it's in the wrong format for them
       anyway, or who want to use it on Microsoft Windows. (see below)
     _________________________________________________________________

                               Trolls [7][MORE]

     * How can I run Crack on a Win98/WinNT/MS-DOS system?
       You can't. Crack is Unix software, written for Unix systems and
       running primarily on Unix systems, and if you don't know what Unix
       is, then you don't need to know about Crack.
     * Can you hack this guy's account/password/computer for me?
       Probably, but I am not going to; now be a good little trog and run
       along and report yourself to your local police authorities,
       please...
     * Can you give me a Crack for TombRaider/Carmageddon/FinalFantasy?
       Oh, go away and get a life, you horrible little oik.
     * H3Y D00D - WAr3 KaN 1 BuY CRACK?!?!!
       I am reliably informed that the answer to this is "any
       street-corner in Oakland" - but being based in the UK I cannot
       vouch for the accuracy of this statement.
     _________________________________________________________________

                                   Technical

     * When I run Crack, it says "Done." and exits immediately, and there
       are no results when I run the Reporter script; why is this?
       Crack is an unusual Unix program - it runs the actual cracking
       process in the "background"; when you type:
 Crack passwd.txt
       ...or whatever, the Crack wrapper-script launches a background
       process called crack-pwc, and it is this which guesses passwords.
       It is crack-pwc that will run for a long time, and if you do:
 ps -auxww ...or...
 ps -ef
       ...after running Crack, then you should see a copy of crack-pwc
       running merrily in the background; ideally you should only have 1
       copy of crack-pwc running, for each CPU in your machine.
     * How long does crack-pwc run for?
       Hard to say, since this will depend upon the number of passwords
       that are being cracked, and the speed of your machines.
       The short answer is: at least hours, probably days, possibly
       weeks.
       The longest single continuous Crack run I have ever done, lasted a
       little under seven months non-stop on a little-used Sun 4/330,
       back in 1991. With faster CPUs available nowadays, things are
       less-bad.
     * How do I add a list of my own words to the Crack dictionaries?
       Move the file containing the list of words into the dicts/1
       directory and do make rmdict in the Crack home directory; the
       words will be merged, the next time you run Crack.
       That's all you have to do; you may choose to compress or gzip your
       wordlist file, if you like - Crack will automatically unpack it
       when it needs it - but it is not essential.
     * What are all the ".dwg" extensions on the Crack dictionary files
       for?
       Crack has a custom, built-in dictionary compression tool called
       DAWG (Directed Acyclic Word Graph) which preprocesses sorted lists
       of words to remove redundancy and make tools like gzip more
       effective.
       Don't worry about it - it's not something that's likely to ever be
       needed by you in normal Crack usage.
     * Where can I get more wordlists?
       Last time I checked:
       [8]ftp://ftp.ox.ac.uk/pub/wordlists/
     * On RedHat-based Linux distributions, Crack doesn't run, and I get
       messages like this:
 ../../run/bin/linux-2-unknown/dictfilt dictfilt.c elcid.o
 .../../run/bin/linux-2-unknown/libc5.a
 cc: elcid.o : No such file or directory
 make[1]:***[../../run/bin/linux-2-unknown/dictfilt] Error 1
 make[1]: Leaving directory `/crack/c50a/src/util'
 make[1]:*** [utils] Error 1
       It's a known problem: unfortunately the crypt() routine has now
       been unbundled from libc in many operating systems, and linkers
       tend to be more strict (or perhaps boneheaded?) than they used to
       be.
       Here is a [9]replacement for src/util/Makefile which should
       alleviate the problem. Like all Makefiles, it requires
       preservation of its TAB structure to work properly, so if your
       "make" program complains about:
       *** missing separator. Stop.
       ...or similar, please try saving the file properly using your
       browser function, and not just cutting and pasting out of the
       browser window.
     * I want to produce reports of crackable passwords which do not
       actually contain the plaintext password itself. How do I do this?
       This is easily achieved by tweaking the "Reporter" script in
       Crack5.0; a little examination of the code, and it should be
       obvious what to do.
     * I want to compose my own rulesets; where can I find documentation?
       Documentation on the rulesets is a bit scanty, but this [10]file
       should be of help.
     * I want to use Crack to check users' passwords when they are
       changing them; can I do this?
       Yes, however you ought to be looking at my CrackLib software which
       does this, and not Crack itself.
     * Crack 4.x used to have this really neat feature where it would
       store passwords that it had not managed to guess, and it would not
       bother to attack them again next time. Why doesn't 5.x do this? I
       want this functionality back! 
       I removed this functionality because many Crack users were not
       bothering to clear out the history of so-called "unguessable"
       passwords every few months; the point was that a password that was
       unguessable one month, might become guessable the next month, when
       other updates/additions might have been added to the password map,
       providing more guessing material for Crack.
       People who want to reduce Crack runtime by only running it against
       new additions and changes to the password file, are encouraged to
       explore the opportunities that are afforded by the Unix commands
       sort and comm, which can enable equivalent functionality in a
       matter of seconds.
       Keeping a sorted copy of the last password file you cracked, and
       running comm against it and a sorted copy of the new password
       file, will print any differences. Save these, and run Crack on
       that data.
       Users are still recommended to try Cracking the whole password
       file, in one big chunk, changed or unchanged, at least
       occasionally.
     _________________________________________________________________

                                  Miscellany

     * Is Crack supported?
       I fix bugs as/when I may, and occasonally post new revs to the
       net. Given how stupid people generally are regarding computer
       security, I can forsee doing this until the day I die. I can
       usually be persuaded to answer questions for beer.
     * Is Crack Y2K Compliant?
       Probably. If it isn't, I am sure I'll find out eventually.
     * We'd like to use Crack for inclusion in a commercial product or
       software distribution; is that OK?
       Please ensure that you have read the software LICENSE file, and
       double-check with me via e-mail if necessary.
     * We'd like to license Crack for inclusion in a commercial product;
       we'd like you to sign this disclaimer and contract and mail/fax it
       back trans-atlantic to our legal department in California, because
       it's obviously to your benefit that you do so.
       Thank you for the contract documents. I shall frame them and put
       them on the wall with the others in the toilet. Now kindly go read
       the LICENSE file, and e-mail me if you have any questions,
       although be aware that your response may be delayed by my rolling
       on the floor in hysterical laughter.
     * Would you consider enhancing Crack to run {on a cluster, in an SMP
       or threaded environment, using MPI, PVM, POSIX threads, or alike}?
       Ah, this old chestnut; there is a note in the Crack5 distribution
       about this. Basically: because of the nature of the data being
       cracked, there is no real advantage in threading the code. It's
       easiest as one-process-per-CPU.
       Consider: most of the point of threading and/or vector operations
       and/or parallelisation is to take advantage of many/optimised CPUs
       to do the same computational task in parallel/simultaneously/in
       one operation.
       The function of Crack is to try as efficiently as possible (ie:
       once only) each of several million possible password guesses
       against the distinct ciphertexts of several thousand users.
       ie: to do several billion computationally *distinct* things.
       It is (regrettably) in the nature of cryptography that generation
       of each password hash (ie: call to crypt()) is of a
       mostly-computationally-distinct nature, and that the only way to
       use parallelization to speed this up would involve writing a
       highly architecture-specific parallel-crypt() implementation,
       which is not economically viable to create when compared to
       equivalent serial password-cracking programs.
       in short: if a one woman can make a baby in nine months, this does
       *not* mean that nine women can make one baby in one month.
       instead: nine women make nine babies in nine months, and all of
       those nine babies arrive simultaneously at the *end* of the nine
       months.
       of course, if we *could* parallelise baby-creation, we would get
       one baby per month for nine months, but the problems of locking,
       surgery, gene-splicing and baby-fragment-reassembly would drag
       down the time, raise overheads and costs, and in the end yield
       exactly the same end-result as the serial-baby-creation-method.
       8-)
     * Oh go on - surely there must be some way to parallelise cracking
       operations? 
       Well, it depends on what I/you mean by "making it parallel"; if by
       that you mean "creating a password hashing algorithm that makes
       effective use of multiple CPUs to speed the essentially linear
       crypt() mechanism" - then no, I don't believe it'd be viable
       (without specialist hardware) because the process of getting a
       password from an un-hashed state (say: Utah) to a hashed one (say:
       California) is most quickly achieved by dropping the data onto a
       single CPU (say: a Porsche 911) and driving non-stop.
       The only overhead here is (of course) in tuning your algorithm for
       your specific CPU architecture, to most closely resemble a Porsche
       911.
       Nowadays, with locking overhead and synchronisation, using
       traditional multi-cpu parallelisation and threading would be more
       akin to hitch-hiking the length of the trip.
       That said: there exists a technique called "bitslicing" which alas
       is complicated to do unless you're a crypto geek, but which
       basically involves packing as many people as feasible into your
       Porsche and occasionally stopping in order to rotate their
       positions.
       In other words: on a 32-bit architecture you use bit-1 of your
       datapath to do encryption operations that are pertinent to one
       encryption, and you use bit-2 in order to do a second, bit-3 in
       order to do a third, and so forth, achieving parallelism of up to
       32 crypt-calls this way... on a 64-bit architecture, of course you
       do 64 at once.
       (This technique was first written up by Biham several years ago,
       but I may have thought of the idea first, though I never managed
       to finish implementing it. I called the idea "polycrypt",
       conceived on a bus trip returning from a bash in London with Paul
       Leyland, and it was the main reason that I introduced the ELCID
       interface into Crack5; the date on my code is mid-1994 but i don't
       know when the bitslicing paper was conceived. Either way, I never
       did anything with it - I got swamped by what to do with S-boxes -
       so what the hell...)
       You may realise now why I got out of the business of binding a
       specific crypt() algorithm into Crack as early as possible.
       In-between this sort of bit manipulation and/or issues of
       pipelining, branch-delay slots, and use/avoidance of bizzare
       multimedia CPU instructions to do the hard work for you in
       hardware, I came to conclude that hacking crypt() routines was a
       game for masochists.
     * How does the DAWG dictionary-compression algorithm work?
       Essentially it is a preprocessor for gzip that removes redundancy
       from a sorted list of words, and typically shrinks an input
       wordlist by some 50% without negatively impacting gzip's ability
       to further compress the file.
       In the new version of the DAWG code - slightly improved over the
       version that ships with Crack v5.0, but fundamentally the same -
       all you need do is:
         1. sort the wordlist into normal Unix order. (beware
            localization!)
         2. for each word that the DAWG preprocessor reads...
         3. count how many leading characters it shares with the previous
            word that was read...
         4. encode that number as a character from the set [0-9A-Za-z]
            for values 0..61 (if the value is >61 then stop there)
         5. print said character (the encoded number) and the remaining
            stem of the word
         6. end-for-loop
       eg:

       foo
       foot
       footle
       fubar
       fub
       grunt
       compresses to:

       #!xdawg magic header
       0foo    first word has no letters in common with anything
       3t         next has three letters in common, and a 't'
       4le                       "foot" + "le"
       1ubar                     "f" + "ubar"
       3                   "fub" + "" => truncation
       0grunt              back to nothing in common
       Inspiration for using DAWG in Crack came from Paul Leyland back in
       the early 1990s, who mentioned something similar being used to
       encode dictionaries for crossword-puzzle solving programs; we
       continue to be astonished at how effective DAWG is on sorted
       inputs without materially impacting subsequent compression (ie:
       gzip); a gzipped-DAWG file is also typically about 50% of the size
       of the gzipped non-DAWGed file.
       Just goes to prove that knowledge of the sort of input you'll be
       dealing with, can beat a general-purpose program hands-down; there
       are also interesting conclusions that can be drawn regarding the
       entropy of human languages after sorting.
     _________________________________________________________________

   [INLINE]

References

   1. ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack
   2. ftp://ftp.cert.dfn.de/pub/tools/password/Crack/
   3. ftp://ftp.cerias.purdue.edu/pub/dict
   4. ftp://ftp.ox.ac.uk/pub/wordlists
   5. file://localhost/extra/desarrollo/jfs/debian/security/DO/crack/crack-5.0a/c50a.tgz.asc
   6. file://localhost/extra/desarrollo/jfs/debian/security/DO/crack/crack-5.0a/c50a.txt
   7. file://localhost/extra/desarrollo/jfs/debian/security/DO/crack/crack-5.0a/crack-users.txt
   8. ftp://ftp.ox.ac.uk/pub/wordlists/
   9. file://localhost/extra/desarrollo/jfs/debian/security/DO/crack/crack-5.0a/c50-linux-util-makefile.txt
  10. file://localhost/extra/desarrollo/jfs/debian/security/DO/crack/crack-5.0a/c50-rules.txt