[Forensics-changes] [crack] 27/40: Drop file-creating patches and put the files under debian/ instead
Giovani Augusto Ferreira
giovani-guest at moszumanska.debian.org
Wed Dec 28 02:47:54 UTC 2016
This is an automated email from the git hooks/post-receive script.
giovani-guest pushed a commit to branch debian
in repository crack.
commit 848e3df56ae921d3f6823d33317f2cbfa4d73977
Author: Axel Beckert <abe at deuxchevaux.org>
Date: Mon Oct 10 01:45:26 2016 +0200
Drop file-creating patches and put the files under debian/ instead
---
debian/changelog | 1 +
debian/crack-common.docs | 4 +-
debian/patches/c50-faq.html.patch | 585 --------------------------------------
debian/patches/c50-faq.txt.patch | 306 --------------------
debian/patches/series | 2 -
debian/upstream-docs/c50-faq.html | 582 +++++++++++++++++++++++++++++++++++++
debian/upstream-docs/c50-faq.txt | 303 ++++++++++++++++++++
7 files changed, 888 insertions(+), 895 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index e3b3b13..146ff50 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,7 @@ crack (5.0a-10) UNRELEASED; urgency=medium
* Switch to source format "3.0 (quilt)" using diff2patches.
+ Add minimal DEP3-style patch headers.
+ Merge debian-specific build script Crack.make into Crack.
+ + Drop file-creating patches and put the files under debian/ instead.
* Add Homepage header and update upstream website in debian/copyright.
* Recode debian/copyright from ISO-8859-1 to UTF-8.
* Apply "wrap-and-sort -a".
diff --git a/debian/crack-common.docs b/debian/crack-common.docs
index 89146b2..53b636b 100644
--- a/debian/crack-common.docs
+++ b/debian/crack-common.docs
@@ -1,5 +1,5 @@
-c50-faq.html
-c50-faq.txt
+debian/upstream-docs/c50-faq.html
+debian/upstream-docs/c50-faq.txt
doc/*
manual.html
manual.txt
diff --git a/debian/patches/c50-faq.html.patch b/debian/patches/c50-faq.html.patch
deleted file mode 100644
index 843f956..0000000
--- a/debian/patches/c50-faq.html.patch
+++ /dev/null
@@ -1,585 +0,0 @@
---- crack-5.0a.orig/c50-faq.html
-+++ crack-5.0a/c50-faq.html
-@@ -0,0 +1,582 @@
-+<HTML>
-+
-+<HEAD>
-+<TITLE>Crack Password Cracker FAQ</TITLE>
-+</HEAD>
-+
-+<BODY BGCOLOR=#FFFFFF>
-+
-+<HR>
-+<H1>FAQ for Crack v5.0a</H1>
-+<I>
-+Copyright (c) Alec Muffett, 1999, 2000, 2001 <BR>
-+Revised: Wed Mar 21 02:38:38 GMT 2001
-+</I>
-+
-+<P>
-+
-+<HR>
-+<H1>Download</H1>
-+
-+<UL>
-+<LI><I>Where can I go to download Crack?</I>
-+<P>
-+
-+Last time I checked: (12 June 2000) <BR>
-+
-+<A HREF="ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack">ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack</A><BR>
-+<A HREF="ftp://ftp.cert.dfn.de/pub/tools/password/Crack/">ftp://ftp.cert.dfn.de/pub/tools/password/Crack/</A>
-+<P>
-+
-+With more dictionaries/wordlists available at: <BR>
-+
-+<A HREF="ftp://ftp.cerias.purdue.edu/pub/dict">ftp://ftp.cerias.purdue.edu/pub/dict</A><BR>
-+<A HREF="ftp://ftp.ox.ac.uk/pub/wordlists">ftp://ftp.ox.ac.uk/pub/wordlists</A>
-+<P>
-+
-+A PGP signature to validate the contents of any download you might find, is
-+<A HREF="c50a.tgz.asc">available here</A>. My key is on the keyservers.
-+
-+<P>
-+
-+<LI><I>Can you send me the README for Crack?</I>
-+
-+<P>
-+
-+Better yet, there's a copy of it <A HREF="c50a.txt">right here</A>. Read it yourself.
-+
-+<P>
-+
-+<LI><I>I can't download Crack! Will you please e-mail it to me?</I>
-+
-+<P>
-+
-+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)
-+
-+<P>
-+
-+</UL>
-+
-+<HR>
-+<H1>Trolls <A HREF="crack-users.txt">[MORE]</A></H1>
-+
-+<UL>
-+<LI><I>How can I run Crack on a Win98/WinNT/MS-DOS system?</I>
-+
-+<P>
-+
-+You can't. Crack is Unix software, written for Unix systems and
-+running primarily <b>on</b> Unix systems, and if you don't know what
-+Unix is, then you don't need to know about Crack.
-+
-+<P>
-+
-+<LI><I>Can you hack this guy's account/password/computer for me?</I>
-+
-+<P>
-+
-+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...
-+
-+<P>
-+
-+<LI><I>Can you give me a Crack for TombRaider/Carmageddon/FinalFantasy?</I>
-+
-+<P>
-+
-+Oh, go away and get a life, you horrible little oik.
-+
-+<P>
-+
-+
-+<LI><I>H3Y D00D - WAr3 KaN 1 BuY CRACK?!?!!</I>
-+
-+<P>
-+
-+I am reliably informed that the answer to this is <I>"any
-+street-corner in Oakland"</I> - but being based in the UK I cannot
-+vouch for the accuracy of this statement.
-+
-+<P>
-+
-+</UL>
-+
-+<HR>
-+<H1>Technical</H1>
-+
-+<UL>
-+
-+<LI><I>When I run Crack, it says "Done." and exits immediately, and
-+there are no results when I run the Reporter script; why is
-+this?</I>
-+
-+<P>
-+
-+<TT>Crack</TT> is an unusual Unix program - it runs the actual cracking process
-+in the "background"; when you type:
-+
-+<P>
-+
-+<PRE>
-+ Crack passwd.txt
-+</PRE>
-+
-+<P>
-+
-+...or whatever, the <TT>Crack</TT> wrapper-script launches a
-+background process called <TT>crack-pwc</TT>, and it is <I>this</I>
-+which guesses passwords.
-+
-+<P>
-+
-+It is <TT>crack-pwc</TT> that will run for a long time, and if you do:
-+
-+<P>
-+
-+<PRE>
-+ ps -auxww <I>...or...</I>
-+ ps -ef
-+</PRE>
-+
-+<P>
-+
-+...after running <TT>Crack</TT>, then you should see a copy of
-+<TT>crack-pwc</TT> running merrily in the background; ideally you
-+should only have 1 copy of <TT>crack-pwc</TT> running, for each CPU in
-+your machine.
-+
-+<P>
-+
-+<LI><I>How long does crack-pwc run for?</I>
-+
-+<P>
-+
-+Hard to say, since this will depend upon the number of passwords that
-+are being cracked, and the speed of your machines.
-+
-+<P>
-+
-+The short answer is: <I>at least hours, probably days, possibly weeks.</I>
-+
-+<P>
-+
-+The longest single continuous <TT>Crack</TT> 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.
-+
-+<P>
-+
-+<LI><I>How do I add a list of my own words to the Crack dictionaries?</I>
-+
-+<P>
-+
-+Move the file containing the list of words into the <TT>dicts/1</TT>
-+directory and do <TT>make rmdict</TT> in the <TT>Crack</TT> home
-+directory; the words will be merged, the next time you run
-+<TT>Crack</TT>.
-+
-+<P>
-+
-+That's all you have to do; you may choose to <I>compress</I> or
-+<I>gzip</I> your wordlist file, if you like - <TT>Crack</TT> will
-+automatically unpack it when it needs it - but it is not essential.
-+
-+<P>
-+
-+<LI><I>What are all the ".dwg" extensions on the Crack dictionary
-+files for?</I>
-+
-+<P>
-+
-+<TT>Crack</TT> 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 <I>gzip</I>
-+more effective.
-+
-+<P>
-+
-+Don't worry about it - it's not something that's likely to ever be
-+needed by you in normal <TT>Crack</TT> usage.
-+
-+<P>
-+
-+<LI><I>Where can I get more wordlists?</I>
-+
-+<P>
-+
-+Last time I checked: <BR>
-+
-+<A href="ftp://ftp.ox.ac.uk/pub/wordlists/">ftp://ftp.ox.ac.uk/pub/wordlists/</A>
-+
-+<P>
-+
-+<LI><I>On RedHat-based Linux distributions, Crack doesn't run, and I
-+get messages like this:</I>
-+
-+<P>
-+
-+<PRE>
-+ ../../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
-+</PRE>
-+
-+<P>
-+
-+It's a known problem: unfortunately the crypt() routine has now been
-+unbundled from <i>libc</i> in many operating systems, and linkers tend
-+to be more strict (or perhaps boneheaded?) than they used to be.
-+
-+<P>
-+
-+Here is a <A HREF="c50-linux-util-makefile.txt">replacement</A> for
-+<tt>src/util/Makefile</tt> which <i>should</i> alleviate the problem.
-+Like all Makefiles, it requires preservation of its TAB structure to
-+work properly, so if your "make" program complains about:
-+
-+<P>
-+
-+<tt> *** missing separator. Stop.</tt>
-+
-+<P>
-+
-+...or similar, please try <b>saving the file properly using your
-+browser function</b>, and not just cutting and pasting out of the
-+browser window.
-+
-+<P>
-+
-+<LI><I>I want to produce reports of crackable passwords which do not
-+actually contain the plaintext password itself. How do I do
-+this?</I>
-+
-+<P>
-+
-+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.
-+
-+<P>
-+
-+<LI><I>I want to compose my own rulesets; where can I find documentation?</I>
-+
-+<P>
-+
-+Documentation on the rulesets is a bit scanty, but this
-+<A href="c50-rules.txt">file</A> should be of help.
-+
-+<P>
-+
-+<LI><I>I want to use Crack to check users' passwords when they are
-+changing them; can I do this?</I>
-+
-+<P>
-+
-+Yes, however you ought to be looking at my <TT>CrackLib</TT> software
-+which does this, and not <TT>Crack</TT> itself.
-+
-+<P>
-+
-+<LI> <I>Crack 4.x used to have this really neat feature where it would
-+store passwords that it had <B>not</B> 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>
-+
-+<P>
-+
-+I removed this functionality because many Crack users were not
-+bothering to clear out the history of so-called <I>"unguessable"</I>
-+passwords every few months; the point was that a password that was
-+<I>unguessable</I> one month, might become <I>guessable</I> the next
-+month, when other updates/additions might have been added to the
-+password map, providing more guessing material for Crack.
-+
-+<P>
-+
-+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 <TT>sort</TT>
-+and <TT>comm</TT>, which can enable equivalent functionality in a
-+matter of seconds.
-+
-+<P>
-+
-+Keeping a <TT>sort</TT>ed copy of the last password file you cracked,
-+and running <TT>comm</TT> against it and a <TT>sort</TT>ed copy of the
-+new password file, will print any differences. Save these, and run
-+Crack on that data.
-+
-+<P>
-+
-+Users are still recommended to try Cracking the whole password file,
-+in one big chunk, changed or unchanged, at least occasionally.
-+<P>
-+
-+</UL>
-+
-+<HR>
-+<H1>Miscellany</H1>
-+
-+<UL>
-+
-+<LI><I>Is Crack supported?</I>
-+
-+<P>
-+
-+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.
-+
-+<P>
-+
-+<LI><I>Is Crack Y2K Compliant?</I>
-+
-+<P>
-+
-+Probably. If it isn't, I am sure I'll find out eventually.
-+
-+<P>
-+
-+<LI><I>We'd like to use Crack for inclusion in a commercial product or
-+software distribution; is that OK?</I>
-+
-+<P>
-+
-+Please ensure that you have read the software LICENSE file, and
-+double-check with me via e-mail if necessary.
-+
-+<P>
-+
-+<LI><I>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.</I>
-+
-+<P>
-+
-+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.
-+
-+<P>
-+
-+
-+
-+<LI> <I>Would you consider enhancing Crack to run {on a cluster, in an
-+SMP or threaded environment, using MPI, PVM, POSIX threads, or alike}?</I>
-+<P>
-+
-+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.
-+<P>
-+
-+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.
-+<P>
-+
-+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.
-+<P>
-+
-+<B>ie:</b> to do several billion computationally *distinct* things.
-+<P>
-+
-+It is (regrettably) in the nature of cryptography that generation of
-+each password hash (ie: call to <TT>crypt()</TT>) 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-<TT>crypt()</TT> implementation, which
-+is not economically viable to create when compared to equivalent
-+serial password-cracking programs.
-+<P>
-+
-+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.
-+<P>
-+
-+instead: nine women make nine babies in nine months, and all of those
-+nine babies arrive simultaneously at the *end* of the nine months.
-+<P>
-+
-+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-)
-+<P>
-+
-+
-+<LI> <I>Oh go on - surely there must be some way to parallelise
-+cracking operations? </I>
-+<P>
-+
-+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
-+<TT>crypt()</TT> 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.
-+<P>
-+
-+The only overhead here is (of course) in tuning your algorithm for
-+your specific CPU architecture, to most closely resemble a Porsche 911.
-+<P>
-+
-+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.
-+<P>
-+
-+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.
-+<P>
-+
-+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.
-+<P>
-+
-+<I>(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...)</I>
-+</I>
-+<P>
-+
-+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.
-+<P>
-+
-+
-+<LI><I>How does the DAWG dictionary-compression algorithm work?</I>
-+<P>
-+
-+Essentially it is a preprocessor for <TT>gzip</TT> that removes
-+redundancy from a sorted list of words, and typically shrinks an input
-+wordlist by some 50% without negatively impacting <TT>gzip</TT>'s
-+ability to further compress the file.
-+<P>
-+
-+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:
-+<P>
-+
-+<OL>
-+<LI> sort the wordlist into normal Unix order. (beware localization!)
-+<LI> for each word that the DAWG preprocessor reads...
-+<LI> count how many leading characters it shares with the previous word that was read...
-+<LI> encode that number as a character from the set <TT>[0-9A-Za-z]</TT> for values 0..61
-+ (if the value is >61 then stop there)
-+<LI> print said character (the encoded number) and the remaining stem of the word
-+<LI> end-for-loop
-+</OL>
-+<P>
-+
-+eg:
-+<P>
-+
-+<TABLE BORDER=1> <!-- cols=1 rows=6 -->
-+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 1 -->
-+<TD> <TT>foo</TT> </TD>
-+</TR>
-+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 2 -->
-+<TD> <TT>foot</TT> </TD>
-+</TR>
-+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 3 -->
-+<TD> <TT>footle</TT> </TD>
-+</TR>
-+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 4 -->
-+<TD> <TT>fubar</TT> </TD>
-+</TR>
-+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 5 -->
-+<TD> <TT>fub</TT> </TD>
-+</TR>
-+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 6 -->
-+<TD> <TT>grunt</TT> </TD>
-+</TR>
-+</TABLE>
-+<P>
-+
-+compresses to:
-+<P>
-+
-+<TABLE BORDER=1> <!-- cols=2 rows=7 -->
-+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 1 -->
-+<TD ALIGN=LEFT> <TT>#!xdawg</TT> </TD>
-+<TD> <i>magic header</i> </TD>
-+</TR>
-+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 2 -->
-+<TD ALIGN=LEFT> <TT>0foo</TT> </TD>
-+<TD> <i>first word has no letters in common with anything</i> </TD>
-+</TR>
-+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 3 -->
-+<TD ALIGN=LEFT> <TT>3t</TT> </TD>
-+<TD> <i>next has three letters in common, and a 't'</i> </TD>
-+</TR>
-+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 4 -->
-+<TD ALIGN=LEFT> <TT>4le</TT> </TD>
-+<TD> <i>"foot" + "le"</i> </TD>
-+</TR>
-+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 5 -->
-+<TD ALIGN=LEFT> <TT>1ubar</TT> </TD>
-+<TD> <i>"f" + "ubar"</i> </TD>
-+</TR>
-+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 6 -->
-+<TD ALIGN=LEFT> <TT>3</TT> </TD>
-+<TD> <i>"fub" + "" => truncation</i> </TD>
-+</TR>
-+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 7 -->
-+<TD ALIGN=LEFT> <TT>0grunt</TT> </TD>
-+<TD> <i>back to nothing in common</i> </TD>
-+</TR>
-+</TABLE>
-+<P>
-+
-+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: <TT>gzip</TT>); a
-+gzipped-DAWG file is <I>also</I> typically about 50% of the size of
-+the gzipped non-DAWGed file.
-+<P>
-+
-+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.
-+<P>
-+
-+</UL>
-+<HR>
-+<IMG SRC="/cgi-bin/webcount?length=6">
-+</BODY>
-+</HTML>
diff --git a/debian/patches/c50-faq.txt.patch b/debian/patches/c50-faq.txt.patch
deleted file mode 100644
index 310abc8..0000000
--- a/debian/patches/c50-faq.txt.patch
+++ /dev/null
@@ -1,306 +0,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
diff --git a/debian/patches/series b/debian/patches/series
index d006c8e..2ceedf3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,7 +1,5 @@
Crack.patch
Makefile.patch
-c50-faq.html.patch
-c50-faq.txt.patch
conf___dictgrps.conf.patch
extra___Dictstats.pl.patch
scripts___binstamp.patch
diff --git a/debian/upstream-docs/c50-faq.html b/debian/upstream-docs/c50-faq.html
new file mode 100644
index 0000000..60dc7c5
--- /dev/null
+++ b/debian/upstream-docs/c50-faq.html
@@ -0,0 +1,582 @@
+<HTML>
+
+<HEAD>
+<TITLE>Crack Password Cracker FAQ</TITLE>
+</HEAD>
+
+<BODY BGCOLOR=#FFFFFF>
+
+<HR>
+<H1>FAQ for Crack v5.0a</H1>
+<I>
+Copyright (c) Alec Muffett, 1999, 2000, 2001 <BR>
+Revised: Wed Mar 21 02:38:38 GMT 2001
+</I>
+
+<P>
+
+<HR>
+<H1>Download</H1>
+
+<UL>
+<LI><I>Where can I go to download Crack?</I>
+<P>
+
+Last time I checked: (12 June 2000) <BR>
+
+<A HREF="ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack">ftp://ftp.cerias.purdue.edu/pub/tools/unix/pwdutils/crack</A><BR>
+<A HREF="ftp://ftp.cert.dfn.de/pub/tools/password/Crack/">ftp://ftp.cert.dfn.de/pub/tools/password/Crack/</A>
+<P>
+
+With more dictionaries/wordlists available at: <BR>
+
+<A HREF="ftp://ftp.cerias.purdue.edu/pub/dict">ftp://ftp.cerias.purdue.edu/pub/dict</A><BR>
+<A HREF="ftp://ftp.ox.ac.uk/pub/wordlists">ftp://ftp.ox.ac.uk/pub/wordlists</A>
+<P>
+
+A PGP signature to validate the contents of any download you might find, is
+<A HREF="c50a.tgz.asc">available here</A>. My key is on the keyservers.
+
+<P>
+
+<LI><I>Can you send me the README for Crack?</I>
+
+<P>
+
+Better yet, there's a copy of it <A HREF="c50a.txt">right here</A>. Read it yourself.
+
+<P>
+
+<LI><I>I can't download Crack! Will you please e-mail it to me?</I>
+
+<P>
+
+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)
+
+<P>
+
+</UL>
+
+<HR>
+<H1>Trolls <A HREF="crack-users.txt">[MORE]</A></H1>
+
+<UL>
+<LI><I>How can I run Crack on a Win98/WinNT/MS-DOS system?</I>
+
+<P>
+
+You can't. Crack is Unix software, written for Unix systems and
+running primarily <b>on</b> Unix systems, and if you don't know what
+Unix is, then you don't need to know about Crack.
+
+<P>
+
+<LI><I>Can you hack this guy's account/password/computer for me?</I>
+
+<P>
+
+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...
+
+<P>
+
+<LI><I>Can you give me a Crack for TombRaider/Carmageddon/FinalFantasy?</I>
+
+<P>
+
+Oh, go away and get a life, you horrible little oik.
+
+<P>
+
+
+<LI><I>H3Y D00D - WAr3 KaN 1 BuY CRACK?!?!!</I>
+
+<P>
+
+I am reliably informed that the answer to this is <I>"any
+street-corner in Oakland"</I> - but being based in the UK I cannot
+vouch for the accuracy of this statement.
+
+<P>
+
+</UL>
+
+<HR>
+<H1>Technical</H1>
+
+<UL>
+
+<LI><I>When I run Crack, it says "Done." and exits immediately, and
+there are no results when I run the Reporter script; why is
+this?</I>
+
+<P>
+
+<TT>Crack</TT> is an unusual Unix program - it runs the actual cracking process
+in the "background"; when you type:
+
+<P>
+
+<PRE>
+ Crack passwd.txt
+</PRE>
+
+<P>
+
+...or whatever, the <TT>Crack</TT> wrapper-script launches a
+background process called <TT>crack-pwc</TT>, and it is <I>this</I>
+which guesses passwords.
+
+<P>
+
+It is <TT>crack-pwc</TT> that will run for a long time, and if you do:
+
+<P>
+
+<PRE>
+ ps -auxww <I>...or...</I>
+ ps -ef
+</PRE>
+
+<P>
+
+...after running <TT>Crack</TT>, then you should see a copy of
+<TT>crack-pwc</TT> running merrily in the background; ideally you
+should only have 1 copy of <TT>crack-pwc</TT> running, for each CPU in
+your machine.
+
+<P>
+
+<LI><I>How long does crack-pwc run for?</I>
+
+<P>
+
+Hard to say, since this will depend upon the number of passwords that
+are being cracked, and the speed of your machines.
+
+<P>
+
+The short answer is: <I>at least hours, probably days, possibly weeks.</I>
+
+<P>
+
+The longest single continuous <TT>Crack</TT> 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.
+
+<P>
+
+<LI><I>How do I add a list of my own words to the Crack dictionaries?</I>
+
+<P>
+
+Move the file containing the list of words into the <TT>dicts/1</TT>
+directory and do <TT>make rmdict</TT> in the <TT>Crack</TT> home
+directory; the words will be merged, the next time you run
+<TT>Crack</TT>.
+
+<P>
+
+That's all you have to do; you may choose to <I>compress</I> or
+<I>gzip</I> your wordlist file, if you like - <TT>Crack</TT> will
+automatically unpack it when it needs it - but it is not essential.
+
+<P>
+
+<LI><I>What are all the ".dwg" extensions on the Crack dictionary
+files for?</I>
+
+<P>
+
+<TT>Crack</TT> 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 <I>gzip</I>
+more effective.
+
+<P>
+
+Don't worry about it - it's not something that's likely to ever be
+needed by you in normal <TT>Crack</TT> usage.
+
+<P>
+
+<LI><I>Where can I get more wordlists?</I>
+
+<P>
+
+Last time I checked: <BR>
+
+<A href="ftp://ftp.ox.ac.uk/pub/wordlists/">ftp://ftp.ox.ac.uk/pub/wordlists/</A>
+
+<P>
+
+<LI><I>On RedHat-based Linux distributions, Crack doesn't run, and I
+get messages like this:</I>
+
+<P>
+
+<PRE>
+ ../../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
+</PRE>
+
+<P>
+
+It's a known problem: unfortunately the crypt() routine has now been
+unbundled from <i>libc</i> in many operating systems, and linkers tend
+to be more strict (or perhaps boneheaded?) than they used to be.
+
+<P>
+
+Here is a <A HREF="c50-linux-util-makefile.txt">replacement</A> for
+<tt>src/util/Makefile</tt> which <i>should</i> alleviate the problem.
+Like all Makefiles, it requires preservation of its TAB structure to
+work properly, so if your "make" program complains about:
+
+<P>
+
+<tt> *** missing separator. Stop.</tt>
+
+<P>
+
+...or similar, please try <b>saving the file properly using your
+browser function</b>, and not just cutting and pasting out of the
+browser window.
+
+<P>
+
+<LI><I>I want to produce reports of crackable passwords which do not
+actually contain the plaintext password itself. How do I do
+this?</I>
+
+<P>
+
+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.
+
+<P>
+
+<LI><I>I want to compose my own rulesets; where can I find documentation?</I>
+
+<P>
+
+Documentation on the rulesets is a bit scanty, but this
+<A href="c50-rules.txt">file</A> should be of help.
+
+<P>
+
+<LI><I>I want to use Crack to check users' passwords when they are
+changing them; can I do this?</I>
+
+<P>
+
+Yes, however you ought to be looking at my <TT>CrackLib</TT> software
+which does this, and not <TT>Crack</TT> itself.
+
+<P>
+
+<LI> <I>Crack 4.x used to have this really neat feature where it would
+store passwords that it had <B>not</B> 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>
+
+<P>
+
+I removed this functionality because many Crack users were not
+bothering to clear out the history of so-called <I>"unguessable"</I>
+passwords every few months; the point was that a password that was
+<I>unguessable</I> one month, might become <I>guessable</I> the next
+month, when other updates/additions might have been added to the
+password map, providing more guessing material for Crack.
+
+<P>
+
+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 <TT>sort</TT>
+and <TT>comm</TT>, which can enable equivalent functionality in a
+matter of seconds.
+
+<P>
+
+Keeping a <TT>sort</TT>ed copy of the last password file you cracked,
+and running <TT>comm</TT> against it and a <TT>sort</TT>ed copy of the
+new password file, will print any differences. Save these, and run
+Crack on that data.
+
+<P>
+
+Users are still recommended to try Cracking the whole password file,
+in one big chunk, changed or unchanged, at least occasionally.
+<P>
+
+</UL>
+
+<HR>
+<H1>Miscellany</H1>
+
+<UL>
+
+<LI><I>Is Crack supported?</I>
+
+<P>
+
+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.
+
+<P>
+
+<LI><I>Is Crack Y2K Compliant?</I>
+
+<P>
+
+Probably. If it isn't, I am sure I'll find out eventually.
+
+<P>
+
+<LI><I>We'd like to use Crack for inclusion in a commercial product or
+software distribution; is that OK?</I>
+
+<P>
+
+Please ensure that you have read the software LICENSE file, and
+double-check with me via e-mail if necessary.
+
+<P>
+
+<LI><I>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.</I>
+
+<P>
+
+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.
+
+<P>
+
+
+
+<LI> <I>Would you consider enhancing Crack to run {on a cluster, in an
+SMP or threaded environment, using MPI, PVM, POSIX threads, or alike}?</I>
+<P>
+
+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.
+<P>
+
+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.
+<P>
+
+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.
+<P>
+
+<B>ie:</b> to do several billion computationally *distinct* things.
+<P>
+
+It is (regrettably) in the nature of cryptography that generation of
+each password hash (ie: call to <TT>crypt()</TT>) 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-<TT>crypt()</TT> implementation, which
+is not economically viable to create when compared to equivalent
+serial password-cracking programs.
+<P>
+
+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.
+<P>
+
+instead: nine women make nine babies in nine months, and all of those
+nine babies arrive simultaneously at the *end* of the nine months.
+<P>
+
+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-)
+<P>
+
+
+<LI> <I>Oh go on - surely there must be some way to parallelise
+cracking operations? </I>
+<P>
+
+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
+<TT>crypt()</TT> 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.
+<P>
+
+The only overhead here is (of course) in tuning your algorithm for
+your specific CPU architecture, to most closely resemble a Porsche 911.
+<P>
+
+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.
+<P>
+
+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.
+<P>
+
+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.
+<P>
+
+<I>(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...)</I>
+</I>
+<P>
+
+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.
+<P>
+
+
+<LI><I>How does the DAWG dictionary-compression algorithm work?</I>
+<P>
+
+Essentially it is a preprocessor for <TT>gzip</TT> that removes
+redundancy from a sorted list of words, and typically shrinks an input
+wordlist by some 50% without negatively impacting <TT>gzip</TT>'s
+ability to further compress the file.
+<P>
+
+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:
+<P>
+
+<OL>
+<LI> sort the wordlist into normal Unix order. (beware localization!)
+<LI> for each word that the DAWG preprocessor reads...
+<LI> count how many leading characters it shares with the previous word that was read...
+<LI> encode that number as a character from the set <TT>[0-9A-Za-z]</TT> for values 0..61
+ (if the value is >61 then stop there)
+<LI> print said character (the encoded number) and the remaining stem of the word
+<LI> end-for-loop
+</OL>
+<P>
+
+eg:
+<P>
+
+<TABLE BORDER=1> <!-- cols=1 rows=6 -->
+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 1 -->
+<TD> <TT>foo</TT> </TD>
+</TR>
+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 2 -->
+<TD> <TT>foot</TT> </TD>
+</TR>
+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 3 -->
+<TD> <TT>footle</TT> </TD>
+</TR>
+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 4 -->
+<TD> <TT>fubar</TT> </TD>
+</TR>
+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 5 -->
+<TD> <TT>fub</TT> </TD>
+</TR>
+<TR ALIGN=LEFT VALIGN=MIDDLE> <!-- row 6 -->
+<TD> <TT>grunt</TT> </TD>
+</TR>
+</TABLE>
+<P>
+
+compresses to:
+<P>
+
+<TABLE BORDER=1> <!-- cols=2 rows=7 -->
+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 1 -->
+<TD ALIGN=LEFT> <TT>#!xdawg</TT> </TD>
+<TD> <i>magic header</i> </TD>
+</TR>
+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 2 -->
+<TD ALIGN=LEFT> <TT>0foo</TT> </TD>
+<TD> <i>first word has no letters in common with anything</i> </TD>
+</TR>
+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 3 -->
+<TD ALIGN=LEFT> <TT>3t</TT> </TD>
+<TD> <i>next has three letters in common, and a 't'</i> </TD>
+</TR>
+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 4 -->
+<TD ALIGN=LEFT> <TT>4le</TT> </TD>
+<TD> <i>"foot" + "le"</i> </TD>
+</TR>
+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 5 -->
+<TD ALIGN=LEFT> <TT>1ubar</TT> </TD>
+<TD> <i>"f" + "ubar"</i> </TD>
+</TR>
+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 6 -->
+<TD ALIGN=LEFT> <TT>3</TT> </TD>
+<TD> <i>"fub" + "" => truncation</i> </TD>
+</TR>
+<TR ALIGN=CENTER VALIGN=MIDDLE> <!-- row 7 -->
+<TD ALIGN=LEFT> <TT>0grunt</TT> </TD>
+<TD> <i>back to nothing in common</i> </TD>
+</TR>
+</TABLE>
+<P>
+
+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: <TT>gzip</TT>); a
+gzipped-DAWG file is <I>also</I> typically about 50% of the size of
+the gzipped non-DAWGed file.
+<P>
+
+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.
+<P>
+
+</UL>
+<HR>
+<IMG SRC="/cgi-bin/webcount?length=6">
+</BODY>
+</HTML>
diff --git a/debian/upstream-docs/c50-faq.txt b/debian/upstream-docs/c50-faq.txt
new file mode 100644
index 0000000..a0a1d09
--- /dev/null
+++ b/debian/upstream-docs/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
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/forensics/crack.git
More information about the forensics-changes
mailing list