These files are provided as is..  and no support nor technical
updates, nor information regarding their compilation or use shall be
answered with anything but a redirection to /dev/null.

However, if you still want to ask me some questions, feel free! My
email is bj371@cleveland.freenet.edu 

What's in this archive:

 Length    Date    Time    Name ("^" ==> case
 ------    ----    ----    ----   conversion)
    323  02-27-97  11:52   docr.c
  22326  02-27-97  11:49   crypt_util.c
   3197  02-27-97  11:49   crypt.c
   1507  02-27-97  11:49   ufc.c
  12029  02-27-97  11:49   craksort2.c
   8250  02-27-97  11:49   crak.c
   2183  02-27-97  11:49   ufc-crypt.h
    959  02-27-97  11:49   patchlevel.h
    592  02-27-97  13:02   sudog.asc
 ------                    -------
      9                    1005   

Description:
============

docr.c  : This file is provided as a quick and dirty way of converting
a single word using a single salt value into a unix-crypt() output
key. This is useful for debugging.. creating a passwd file to test
your compilation with, etc etc.

crypt_util.c  : Contain the actual ufc-crypt routines. Trust me, these
crypt.c         are the fastest there are without turning to another
                language or taking up megabytes of memory for salt
                tables.

ufc.c  :  This file contains a quick routine to show you just exactly
          how fast the ufc-crypt routines really are. IE: VERY VERY
          god-awesome fast. Try it out with about 1000 iterations and
          see what I mean. Try it against regular crypt routines.

craksort2.c  :  My baby. The main() routines for my crak
                implementation. Online help available with argv[0] ?
                See further down for actual manual and usage and
                The Other Crap and Stuff.

crak.c  :  An older version which did not sort the passwd field
           entries, nor did it try the entire dictionary on one passwd
           structure before moving onto the next one. It's exponentially
           slower to demonstrate to the clueless ones the values of
           program efficiencies. Not saying craksort2 is efficient
           or anything--far from it. I just programmed it to be
           functional and bullet-proof. Efficiency comes with the next
           release. See notes below.

#?.h  :  The header files for the crypt() routines. Just regular stuff
         like what sort of types to use for 32-bit and 64-bit capable
         machines. ufc-crypt just KICKS BUTT on 64-bit longlong
         capable machines. VERY cool and EXTREMELY FAST.

sudog.asc  :  My humble self's pgp public key.


craksort2 README manual
=======================

Intro and SoapBox
=================

Cracking UNIX passwords. Fun fun fun. There is a legitimate use for
this program, along with a non-legitimate use. Quite frankly, I don't
care what your purpose is in downloading this program. If you can
break into a system using this code, send me an anonymous note
describing your exploits, will ya? Just a brief description; I don't
want to know any site IPs and security holes, I just want to know
things like "I snagged a passwd file from the clueless admin--your
program helped me show them the.. error.. of their ways."

Personally, if a system can be broken into with a cracker proggy like
this, the dorkus doing the hacking should take care not to break
things. That's the way of the lemur. The way of the left-field lemur
who is too stoned to realize that rm -rf * is a bad thing. If
something gets broken, the user deserves to get nailed to the wall by
a SuperClue. (Play Netrek, you'll understand..  you'll understand
everything... *smile*)

This program was designed to be as ANSI-C compatible as possible,
unlike the mammoth crappy junk I've seen out there. I'm fed up about
dorky programmers, intent on making themselves look clever, designing
a program which needs another program just to filter its goddamned
output. Morons code like that. If they think they're saving time,
they're dinks. Users don't want to be bothered to do another
search--the cpu time is going to be used anyway, so why not simplify
the process?

I've been able to compile this on IRIX, UNIX, Linux, Amiga, Pentiums,
and just about everything else out there. I've used compilers from
GCC, Lattice, SAS/C, CC, and everything in between. It's portable. The
Amiga flavours are in there for other Amiga users such as myself to be
able to break it without screwing up and leaving a crapload of memory
sitting there in limbo. (The #ifdef AMIGA sections I'm talking about.)

Requirements:
============

300k of free memory. Yes, I said 300k. It's mostly for the tables
in the ufc-crypt routines, since a passwd file of 500 entries only
takes up about 20k or space in the linked list. The struct passwd is
only 42 bytes on my 32-bit Amiga 3000...  I wonder if this means
something.....?

A C-Compiler. ANSI-C compliance is a good thing. I'm a great advocator
of portability. It's im-port-ant. ha ha.

Usage:
======

Use #1
------

% craksort2 <passwdfile> -<password> [outputfile]

The outputfile is optional. Things get printed to stdout no matter
what, so a redirection here might be used instead if you don't want to
be bothered with the results until things are DONE.

The '-' tells the program that the following word is to be the one
checked. Sort of like a one-word dictionary file. Cute huh?

Use #2
------

%craksort2 <passwdfile> <dictionary> [outputfile]

Again, the output file is optional, as things get printed to stdout.


The Dictionary File
===================

The dictionary file is a list of words, separated by non-printables.
What does this mean? This means that this program will check spaces
and ANY other printable characters in the passwords, unlike yet
another unmentionable which DOESN'T.

The passwd File
===============

If you don't know what a passwd file is, you shouldn't be reading
this. This isn't a program for Jimbob the farmer with the new 'puter
from Anytown, Canada.

This program reads in the following from <passwdfile>:

{userid}{separator}{passwd}{separator}

These elements MUST be included on each entry in the file or things
get messy. (Don't worry my program cleans up after itself.) The
separator is a #define at the beginning of the craksort2.c file.
Sometimes it is necessary to change things--if, for instance, you are
cracking a passwd file used on an amiga, where the ':' is a device
denoter. Ie: "mine:" is a device.. here the colon would screw things
up.

The first two characters in the passwd field are what is known as a
salt. The crypt() implementation uses this to encrypt the plaintext
password from the dictionary file.

Here's a better description of crypt(3);

(Thanks daemon9..  I didn't get your permission to reprint this, but
at least I'm crediting you.)

Unix Password Encryption [crypt(3)]
-----------------------------------------------------------------------------
Unix passwd encryption is based on a modified version of DES.  The user 
enters her login and password at the prompts.  The user entered password 
is used as a key to encrypt a 64-bit block of NULLs.  The first seven 
bits of each character are extracted to form a 56-bit key.  (The other 
eight are used for parity.) This implies that only eight characters are 
significant to a password.  The E-table is then modified using the salt, 
which is a 12-bit value, coerced into the first two chars of the stored 
passwd.  The salt's purpose is to make precompiled passwd lists and DES 
hardware chips ineffectual (or more difficult to use).  Then, DES is 
invoked for 25 iterations on the block of zeros.  The output is 64-bits 
long, and is then coerced into a 64 character alphabet (0-9,A-Z,a-z,".","/").
This involves translations in which several different values are represented 
by the same character.  Unix passwd crypts are the product of a one-way hash. 
Information about the key is dropped in every iteration.  Bits are LOST in the
process.  crypt(3), therefore, CANNOT be decrypted, reversed, or otherwise
subverted from any type of scrutiny of it's output.  
1/5/95 (9/25/95)
----------------------------------------------------------------------

So there.


Why Not Brute Force?
====================

Someone told me to add brute force to the program, and I wanted to
comment briefly on this. Brute force in the truest sense of the word
(since reversing the output it nearly impossible) means that we are
taking every possible combination of letters, numbers, and printable
characters and trying every single one of them..  crypt() ing every
single one of them. It's rather difficult to accomplish anything
worthwhile, and it would be pure chance if something made a
hit--personally I deliberately use a password in the upper quadrant of
keyspace, since most brute force algorithms either go from the middle
out, or from the beginning upwards. Ie: No one's ever hacked my unix
passwd through crack methods.

I decided NOT to add brute force to this program, since there are so
very few passwords out there which are relatively random. Why try to
hit on a random password when the chances are so mind-bogglingly
small? Instead, use logically-related words, letters, or numbers. This
is much simpler. Many people even actually use parts of their names in
their unix password!! Hilarious huh? Hence, no brute force; Hence,
only dictionary files and single words.

(Sorry SpEc..  even the IRIX machine is far too slow to do anything
useful with a brute force attack.)

Copyrights
==========

This program is hereby donated to the public good. The ufc-crypt
routines are covered under the GNU Licence, and their copyrights are
listed in the source codes. But the rest of it is purely public
domain. Do you want to try making money off my chunks of source? Go
for it. I couldn't care less. I hardly spent any time on it
anyway--maybe two days of off-and-on, tops, including research and
writing this README.

Contacting ME
=============

bj371@cleveland.freenet.edu

Don't ask me for my SnailMail unless you want to send something cool,
like software or a new car.

PLEASE please use my PGP public key to encrypt messages to me.
Sysadmin on every system I've ever been in or around are ALL snoopy.
They say they aren't, but I'll bet you a hundred dollars they're
grep'ing the whole damned mail spool regularly. Haven't you read
Bastard Operator From Hell?

Future:
======

I dislike writing Future sections because I know how annoying it is to
read them in other peoples' documentations, but I finally gave in,
because it's kind of exciting.

I intend to implement the following sometime maybe:

- multiple dictionary support

- brute force (okay okay if you really want it)

- efficient algorithms for once

- power-out/time-out/break recovery -- ie: continuing a job
from the last searched position..  this means batch file at startup
support. This is a Good Thing, and means people can do this stuff in
the background and let it simply notify the user upon a crack. This
also means that the resources can be freed up for a while if they are
needed, then things can start up again where they left off.

- Coffee-maker startup support. No, really..  I'm serious here!

- A better ANSI animation for the working prompt.

-sudog, Feb 27, 1997
