+ +
+
+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. +
+ +