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
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.
+ shift + [ -d ../libdes ] + cd ../libdes + make cc -Ae -O -DRAND -DTERMIOS -c cbc3_enc.c ... (Bundled) cc: warning 480: The -A option is available only with the C/ANSI C product; ignored. ... /usr/bin/cc: optional software package not installed error: ...
...or similar; so what is happening?
I get this question quite a lot, and it has finally reached the sort of threshold where it deserves to go in the FAQ.
There are actually two issues at hand here, one or both of which may be applicable, but they both have the same root cause.
THE LIBDES LIBRARY IN CRACK IS NOT ACTUALLY PART OF CRACK; strictly it is what usually gets called bundled software, stuff that is written by a different author and shipped in association with other software in order to make the latter, work.
As such - as I believe is explained somewhere in the Crack manuals, the libdes code requires separate configuration and tuning to fit the needs of your platform.
So: if you are seeing Crack crash-out with messages that seem to indicate that it was trying to compile libdes at the time, change directory into the src/libdes directory and take time to read the README and INSTALL files that are there, and modify the Makefile in order to match your system configuration.
This may require, for instance, changing the value of the CC variable to match your compiler - on systems which use GNU gcc rather than some other system-provided compiler as-above.
Further, by experimenting with:
make des_opts
...and executing the resulting binary, you may determine which of the various compilation flags (things you can tweak in the Makefile) are optimal for use on your system.
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.