--- crack-5.0a.orig/Crack.make +++ crack-5.0a/Crack.make @@ -0,0 +1,210 @@ +#!/bin/sh +### +# This program was written by and is copyright Alec Muffett 1991, +# 1992, 1993, 1994, 1995, and 1996, and is provided as part of the +# Crack v5.0 Password Cracking package. +# +# The copyright holder disclaims all responsibility or liability with +# respect to its usage or its effect upon hardware or computer +# systems, and maintains copyright as set out in the "LICENCE" +# document which accompanies distributions of Crack v5.0 and upwards. +# +# This is the Crack.makeonly version which *only* compiles the utilities +# under run/dir used for Crack +# +# This program was made based on Crack by Javir Fernandez-Sanguino +# for the Debian GNU/Linux distribution + +### +# User-configurable junk for Crack +### + +# nice, generic path (RedHat Linux, Solaris1, Solaris2) +CRACK_PATH=/usr/local/bin:/usr/ccs/bin:/usr/sbin:/sbin:/usr/bin:/bin:/usr/ucb:/usr/etc:$PATH + +# compiler options for crack 5.0 +# +# -DUSE_BZERO /* add this to C5FLAGS if you don't have memset() */ +# -DUSE_MALLOC_H +# -DUSE_PWD_H +# -DUSE_SIGNAL_H +# -DUSE_STDLIB_H +# -DUSE_STRINGS_H +# -DUSE_STRING_H +# -DUSE_SYS_TYPES_H +# -DUSE_UNISTD_H +# -DMAXWORDLEN= /* ignore if you don't read the code */ +# -DNUMWORDS= /* ignore if you don't read the code */ +# -DSTRINGSIZE= /* ignore if you don't read the code */ + +# this set tested on: +# - solaris 2.5 +# - redhat linux 4.0 +# - digital unix v4.0 + +C5FLAGS="-DUSE_STRING_H -DUSE_STDLIB_H -DUSE_SIGNAL_H -DUSE_SYS_TYPES_H -DUSE_UNISTD_H -DUSE_PWD_H" + +# +# now pick your compiler +# + +# vanilla unix cc +#CC=cc +#CFLAGS="-g -O $C5FLAGS" +#LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD MD5 + +# gcc 2.7.2 +CC=gcc +CFLAGS="-g -O2 -Wall $C5FLAGS" +LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD MD5 + +# digital unix v4.0, CFLAGS for ev4/ev5 chipsets (pick one) +#CC=cc +#CFLAGS="-O4 -fast -tune ev4 $C5FLAGS" +#CFLAGS="-O4 -fast -tune ev5 $C5FLAGS" +#LIBS= + +# Uncomment the next two lines if a) you are running Crack in +# networking mode, and b) your environment's operating system will not +# necessarily run binaries compiled on other revs of the same +# operating system which have the same architecture and the same +# *MAJOR* revision number. +# +# eg: if you have Foonix 2.0 boxes as well as Foonix 2.1 boxes; in +# this example, the major revision number is "2". If the Foonix 2.1 +# O/S will not run Foonix 2.0 binaries for some reason, or vice-versa, +# then uncomment these lines. + +#STRICT_OSREV=yes +#export STRICT_OSREV + +# Uncomment and/or modify on HP/UX or similar where the UCB "rsh" +# command has been renamed. See scripts/crack-rsh also +#CRACK_RSH=remsh +#CRACK_RCP=rcp + +########################################################### +########################################################### +#################### THAT'S ALL, FOLKS #################### +#### NOW GO CONFIGURE YOUR CRYPT ALGORITHM, EG: LIBDES #### +########################################################### +########################################################### + +### +# security +### + +umask 077 +export CRACK_PATH # So it can be picked up later +PATH=$CRACK_PATH # For temporary use... +export PATH + +### +# Defaults +### + +usage="Usage: Crack [options] [bindir] [[-fmt format] files]..." + +version="5.0a" # version string +deffmt=trad # for default trad2spf +dodie="" # for verbose usage/die +debug="false" # ...guess... +node=`uname -n` # more portable then `hostname` + +### +# home base +### + +CRACK_HOME=. + +if cd $CRACK_HOME +then + CRACK_HOME=`pwd` +else + echo "Fatal Error: $CRACK_HOME: cannot chdir" 1>&2 + exit 1 +fi + +export CRACK_HOME + +### +# sanity check +### + +if [ ! -f "$CRACK_HOME/Crack" ] +then + echo "Fatal Error: $CRACK_HOME: something weird going down" 1>&2 + exit 1 +fi + +### +# Hierarchy +### + +for dir in lib lib/bin +do + test -d $dir || mkdir $dir || exit 1 +done + +### +# Flagwaving +### + +echo "Crack $version: The Password Cracker." +echo "(c) Alec Muffett, 1991, 1992, 1993, 1994, 1995, 1996" +echo "System:" `uname -a 2>/dev/null` +echo "Home: $CRACK_HOME" +echo "Invoked: $0 $*" + + +### +# Sanity test bindir - written in gruntscript for clarity. +### + +bdname=`scripts/binstamp 2>/dev/null` + +if [ "x$bdname" = "x" ] +then + echo "Crack: error: cannot continue as binstamp returned empty string" 1>&2 + exit 0 +fi + +echo "Stamp: $bdname" +echo "" + +bindir=lib/bin/$bdname + + +### +# Reset PATH in advance +### + +PATH=$CRACK_HOME/scripts:$CRACK_HOME/$bindir:$PATH +export PATH + +### +# Make the binaries +### + +echo "Crack: making utilities in $bindir" + +if [ ! -d $bindir ] # small redundancy, big benefit +then + mkdir $bindir || exit 1 +fi + +make clean || exit 1 + +make ARGS="\"XDIR=../../$bindir\" \"XCFLAGS=$CFLAGS\" \"XCC=$CC\" \"XLIBS=$LIBS\"" utils || exit 1 + +### +# Make Only ? +### + +if [ "x$makeonlyflag" != "x" ] +then + echo "Crack: makeonly done" + exit 0 +fi + +exit 0 --- crack-5.0a.orig/c50-faq.txt +++ crack-5.0a/c50-faq.txt @@ -0,0 +1,303 @@ + + _________________________________________________________________ + + 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 --- crack-5.0a.orig/Makefile +++ crack-5.0a/Makefile @@ -39,17 +39,17 @@ tidy: clean -scripts/plaster -scripts/fbmerge - -rm -f run/[DIEGTKM]* - -rm -f run/dict/gecos.* - -rm -f run/dict/gcperm.* + -rm -f lib/[DIEGTKM]* + -rm -f lib/dict/gecos.* + -rm -f lib/dict/gcperm.* spotless: tidy - -rm -rf run/bin + -rm -rf lib/bin rmdict: - -rm -rf run/dict + -rm -rf lib/dict clobber: spotless rmdict - -cat run/F-merged >> F-merged.save - -rm -rf run + -cat lib/F-merged >> F-merged.save + -rm -rf lib ( cd extra ; make clean ) --- crack-5.0a.orig/Crack +++ crack-5.0a/Crack @@ -15,74 +15,6 @@ # nice, generic path (RedHat Linux, Solaris1, Solaris2) CRACK_PATH=/usr/local/bin:/usr/ccs/bin:/usr/sbin:/sbin:/usr/bin:/bin:/usr/ucb:/usr/etc:$PATH -# compiler options for crack 5.0 -# -# -DUSE_BZERO /* add this to C5FLAGS if you don't have memset() */ -# -DUSE_MALLOC_H -# -DUSE_PWD_H -# -DUSE_SIGNAL_H -# -DUSE_STDLIB_H -# -DUSE_STRINGS_H -# -DUSE_STRING_H -# -DUSE_SYS_TYPES_H -# -DUSE_UNISTD_H -# -DMAXWORDLEN= /* ignore if you don't read the code */ -# -DNUMWORDS= /* ignore if you don't read the code */ -# -DSTRINGSIZE= /* ignore if you don't read the code */ - -# this set tested on: -# - solaris 2.5 -# - redhat linux 4.0 -# - digital unix v4.0 - -C5FLAGS="-DUSE_STRING_H -DUSE_STDLIB_H -DUSE_SIGNAL_H -DUSE_SYS_TYPES_H -DUSE_UNISTD_H -DUSE_PWD_H" - -# -# now pick your compiler -# - -# vanilla unix cc -CC=cc -CFLAGS="-g -O $C5FLAGS" -#LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD MD5 - -# gcc 2.7.2 -#CC=gcc -#CFLAGS="-g -O2 -Wall $C5FLAGS" -#LIBS=-lcrypt # uncomment only if necessary to use stdlib crypt(), eg: NetBSD MD5 - -# digital unix v4.0, CFLAGS for ev4/ev5 chipsets (pick one) -#CC=cc -#CFLAGS="-O4 -fast -tune ev4 $C5FLAGS" -#CFLAGS="-O4 -fast -tune ev5 $C5FLAGS" -#LIBS= - -# Uncomment the next two lines if a) you are running Crack in -# networking mode, and b) your environment's operating system will not -# necessarily run binaries compiled on other revs of the same -# operating system which have the same architecture and the same -# *MAJOR* revision number. -# -# eg: if you have Foonix 2.0 boxes as well as Foonix 2.1 boxes; in -# this example, the major revision number is "2". If the Foonix 2.1 -# O/S will not run Foonix 2.0 binaries for some reason, or vice-versa, -# then uncomment these lines. - -#STRICT_OSREV=yes -#export STRICT_OSREV - -# Uncomment and/or modify on HP/UX or similar where the UCB "rsh" -# command has been renamed. See scripts/crack-rsh also -#CRACK_RSH=remsh -#CRACK_RCP=rcp - -########################################################### -########################################################### -#################### THAT'S ALL, FOLKS #################### -#### NOW GO CONFIGURE YOUR CRYPT ALGORITHM, EG: LIBDES #### -########################################################### -########################################################### - ### # security ### @@ -330,32 +262,8 @@ ### PATH=$CRACK_HOME/scripts:$CRACK_HOME/$bindir:$PATH -export PATH - -### -# Make the binaries -### - -echo "Crack: making utilities in $bindir" - -if [ ! -d $bindir ] # small redundancy, big benefit -then - mkdir $bindir || exit 1 -fi +export PATH -make clean || exit 1 - -make ARGS="\"XDIR=../../$bindir\" \"XCFLAGS=$CFLAGS\" \"XCC=$CC\" \"XLIBS=$LIBS\"" utils || exit 1 - -### -# Make Only ? -### - -if [ "x$makeonlyflag" != "x" ] -then - echo "Crack: makeonly done" - exit 0 -fi ### # Make the dictionary passes @@ -460,7 +368,7 @@ shift done | - crack-sort -t: +1 + crack-sort -t: -k 1 ) 3>&1 | fbfilt $crackfb $crackmf > $crackin # remove feedback-guessable users --- crack-5.0a.orig/c50-faq.html +++ crack-5.0a/c50-faq.html @@ -0,0 +1,582 @@ + + +
++ +
+
+Last time I checked: (12 June 2000)
+
+ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack
+ftp://ftp.cert.dfn.de/pub/tools/password/Crack/
+
+
+With more dictionaries/wordlists available at:
+
+ftp://ftp.cerias.purdue.edu/pub/dict
+ftp://ftp.ox.ac.uk/pub/wordlists
+
+ +A PGP signature to validate the contents of any download you might find, is +available here. My key is on the keyservers. + +
+ +
+ +Better yet, there's a copy of it right here. Read it yourself. + +
+ +
+ +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) + +
+ +
+ +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. + +
+ +
+ +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... + +
+ +
+ +Oh, go away and get a life, you horrible little oik. + +
+ + +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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. + +
+ +
+ +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. + +
+ +
+
+Last time I checked:
+
+ftp://ftp.ox.ac.uk/pub/wordlists/
+
+
+ +
+ +
+ ../../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 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. + +
+ +
+ +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. + +
+ +
+ +Documentation on the rulesets is a bit scanty, but this +file should be of help. + +
+ +
+ +Yes, however you ought to be looking at my CrackLib software +which does this, and not Crack itself. + +
+ +
+ +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. +
+ +
+ +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. + +
+ +
+ +Probably. If it isn't, I am sure I'll find out eventually. + +
+ +
+ +Please ensure that you have read the software LICENSE file, and +double-check with me via e-mail if necessary. + +
+ +
+ +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. + +
+ + + +
+ +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-) +
+ + +
+ +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. +
+ + +
+ +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: +
+ +
+ +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. +
+ +