home *** CD-ROM | disk | FTP | other *** search
/ Aminet 18 / aminetcdnumber181997.iso / Aminet / comm / tcp / Crak.lha / README < prev    next >
Encoding:
Text File  |  1997-02-27  |  11.0 KB  |  276 lines
  1. These files are provided as is..  and no support nor technical
  2. updates, nor information regarding their compilation or use shall be
  3. answered with anything but a redirection to /dev/null.
  4.  
  5. However, if you still want to ask me some questions, feel free! My
  6. email is bj371@cleveland.freenet.edu 
  7.  
  8. What's in this archive:
  9.  
  10.  Length    Date    Time    Name ("^" ==> case
  11.  ------    ----    ----    ----   conversion)
  12.     323  02-27-97  11:52   docr.c
  13.   22326  02-27-97  11:49   crypt_util.c
  14.    3197  02-27-97  11:49   crypt.c
  15.    1507  02-27-97  11:49   ufc.c
  16.   12029  02-27-97  11:49   craksort2.c
  17.    8250  02-27-97  11:49   crak.c
  18.    2183  02-27-97  11:49   ufc-crypt.h
  19.     959  02-27-97  11:49   patchlevel.h
  20.     592  02-27-97  13:02   sudog.asc
  21.  ------                    -------
  22.       9                    1005   
  23.  
  24. Description:
  25. ============
  26.  
  27. docr.c  : This file is provided as a quick and dirty way of converting
  28. a single word using a single salt value into a unix-crypt() output
  29. key. This is useful for debugging.. creating a passwd file to test
  30. your compilation with, etc etc.
  31.  
  32. crypt_util.c  : Contain the actual ufc-crypt routines. Trust me, these
  33. crypt.c         are the fastest there are without turning to another
  34.                 language or taking up megabytes of memory for salt
  35.                 tables.
  36.  
  37. ufc.c  :  This file contains a quick routine to show you just exactly
  38.           how fast the ufc-crypt routines really are. IE: VERY VERY
  39.           god-awesome fast. Try it out with about 1000 iterations and
  40.           see what I mean. Try it against regular crypt routines.
  41.  
  42. craksort2.c  :  My baby. The main() routines for my crak
  43.                 implementation. Online help available with argv[0] ?
  44.                 See further down for actual manual and usage and
  45.                 The Other Crap and Stuff.
  46.  
  47. crak.c  :  An older version which did not sort the passwd field
  48.            entries, nor did it try the entire dictionary on one passwd
  49.            structure before moving onto the next one. It's exponentially
  50.            slower to demonstrate to the clueless ones the values of
  51.            program efficiencies. Not saying craksort2 is efficient
  52.            or anything--far from it. I just programmed it to be
  53.            functional and bullet-proof. Efficiency comes with the next
  54.            release. See notes below.
  55.  
  56. #?.h  :  The header files for the crypt() routines. Just regular stuff
  57.          like what sort of types to use for 32-bit and 64-bit capable
  58.          machines. ufc-crypt just KICKS BUTT on 64-bit longlong
  59.          capable machines. VERY cool and EXTREMELY FAST.
  60.  
  61. sudog.asc  :  My humble self's pgp public key.
  62.  
  63.  
  64. craksort2 README manual
  65. =======================
  66.  
  67. Intro and SoapBox
  68. =================
  69.  
  70. Cracking UNIX passwords. Fun fun fun. There is a legitimate use for
  71. this program, along with a non-legitimate use. Quite frankly, I don't
  72. care what your purpose is in downloading this program. If you can
  73. break into a system using this code, send me an anonymous note
  74. describing your exploits, will ya? Just a brief description; I don't
  75. want to know any site IPs and security holes, I just want to know
  76. things like "I snagged a passwd file from the clueless admin--your
  77. program helped me show them the.. error.. of their ways."
  78.  
  79. Personally, if a system can be broken into with a cracker proggy like
  80. this, the dorkus doing the hacking should take care not to break
  81. things. That's the way of the lemur. The way of the left-field lemur
  82. who is too stoned to realize that rm -rf * is a bad thing. If
  83. something gets broken, the user deserves to get nailed to the wall by
  84. a SuperClue. (Play Netrek, you'll understand..  you'll understand
  85. everything... *smile*)
  86.  
  87. This program was designed to be as ANSI-C compatible as possible,
  88. unlike the mammoth crappy junk I've seen out there. I'm fed up about
  89. dorky programmers, intent on making themselves look clever, designing
  90. a program which needs another program just to filter its goddamned
  91. output. Morons code like that. If they think they're saving time,
  92. they're dinks. Users don't want to be bothered to do another
  93. search--the cpu time is going to be used anyway, so why not simplify
  94. the process?
  95.  
  96. I've been able to compile this on IRIX, UNIX, Linux, Amiga, Pentiums,
  97. and just about everything else out there. I've used compilers from
  98. GCC, Lattice, SAS/C, CC, and everything in between. It's portable. The
  99. Amiga flavours are in there for other Amiga users such as myself to be
  100. able to break it without screwing up and leaving a crapload of memory
  101. sitting there in limbo. (The #ifdef AMIGA sections I'm talking about.)
  102.  
  103. Requirements:
  104. ============
  105.  
  106. 300k of free memory. Yes, I said 300k. It's mostly for the tables
  107. in the ufc-crypt routines, since a passwd file of 500 entries only
  108. takes up about 20k or space in the linked list. The struct passwd is
  109. only 42 bytes on my 32-bit Amiga 3000...  I wonder if this means
  110. something.....?
  111.  
  112. A C-Compiler. ANSI-C compliance is a good thing. I'm a great advocator
  113. of portability. It's im-port-ant. ha ha.
  114.  
  115. Usage:
  116. ======
  117.  
  118. Use #1
  119. ------
  120.  
  121. % craksort2 <passwdfile> -<password> [outputfile]
  122.  
  123. The outputfile is optional. Things get printed to stdout no matter
  124. what, so a redirection here might be used instead if you don't want to
  125. be bothered with the results until things are DONE.
  126.  
  127. The '-' tells the program that the following word is to be the one
  128. checked. Sort of like a one-word dictionary file. Cute huh?
  129.  
  130. Use #2
  131. ------
  132.  
  133. %craksort2 <passwdfile> <dictionary> [outputfile]
  134.  
  135. Again, the output file is optional, as things get printed to stdout.
  136.  
  137.  
  138. The Dictionary File
  139. ===================
  140.  
  141. The dictionary file is a list of words, separated by non-printables.
  142. What does this mean? This means that this program will check spaces
  143. and ANY other printable characters in the passwords, unlike yet
  144. another unmentionable which DOESN'T.
  145.  
  146. The passwd File
  147. ===============
  148.  
  149. If you don't know what a passwd file is, you shouldn't be reading
  150. this. This isn't a program for Jimbob the farmer with the new 'puter
  151. from Anytown, Canada.
  152.  
  153. This program reads in the following from <passwdfile>:
  154.  
  155. {userid}{separator}{passwd}{separator}
  156.  
  157. These elements MUST be included on each entry in the file or things
  158. get messy. (Don't worry my program cleans up after itself.) The
  159. separator is a #define at the beginning of the craksort2.c file.
  160. Sometimes it is necessary to change things--if, for instance, you are
  161. cracking a passwd file used on an amiga, where the ':' is a device
  162. denoter. Ie: "mine:" is a device.. here the colon would screw things
  163. up.
  164.  
  165. The first two characters in the passwd field are what is known as a
  166. salt. The crypt() implementation uses this to encrypt the plaintext
  167. password from the dictionary file.
  168.  
  169. Here's a better description of crypt(3);
  170.  
  171. (Thanks daemon9..  I didn't get your permission to reprint this, but
  172. at least I'm crediting you.)
  173.  
  174. Unix Password Encryption [crypt(3)]
  175. -----------------------------------------------------------------------------
  176. Unix passwd encryption is based on a modified version of DES.  The user 
  177. enters her login and password at the prompts.  The user entered password 
  178. is used as a key to encrypt a 64-bit block of NULLs.  The first seven 
  179. bits of each character are extracted to form a 56-bit key.  (The other 
  180. eight are used for parity.) This implies that only eight characters are 
  181. significant to a password.  The E-table is then modified using the salt, 
  182. which is a 12-bit value, coerced into the first two chars of the stored 
  183. passwd.  The salt's purpose is to make precompiled passwd lists and DES 
  184. hardware chips ineffectual (or more difficult to use).  Then, DES is 
  185. invoked for 25 iterations on the block of zeros.  The output is 64-bits 
  186. long, and is then coerced into a 64 character alphabet (0-9,A-Z,a-z,".","/").
  187. This involves translations in which several different values are represented 
  188. by the same character.  Unix passwd crypts are the product of a one-way hash. 
  189. Information about the key is dropped in every iteration.  Bits are LOST in the
  190. process.  crypt(3), therefore, CANNOT be decrypted, reversed, or otherwise
  191. subverted from any type of scrutiny of it's output.  
  192. 1/5/95 (9/25/95)
  193. ----------------------------------------------------------------------
  194.  
  195. So there.
  196.  
  197.  
  198. Why Not Brute Force?
  199. ====================
  200.  
  201. Someone told me to add brute force to the program, and I wanted to
  202. comment briefly on this. Brute force in the truest sense of the word
  203. (since reversing the output it nearly impossible) means that we are
  204. taking every possible combination of letters, numbers, and printable
  205. characters and trying every single one of them..  crypt() ing every
  206. single one of them. It's rather difficult to accomplish anything
  207. worthwhile, and it would be pure chance if something made a
  208. hit--personally I deliberately use a password in the upper quadrant of
  209. keyspace, since most brute force algorithms either go from the middle
  210. out, or from the beginning upwards. Ie: No one's ever hacked my unix
  211. passwd through crack methods.
  212.  
  213. I decided NOT to add brute force to this program, since there are so
  214. very few passwords out there which are relatively random. Why try to
  215. hit on a random password when the chances are so mind-bogglingly
  216. small? Instead, use logically-related words, letters, or numbers. This
  217. is much simpler. Many people even actually use parts of their names in
  218. their unix password!! Hilarious huh? Hence, no brute force; Hence,
  219. only dictionary files and single words.
  220.  
  221. (Sorry SpEc..  even the IRIX machine is far too slow to do anything
  222. useful with a brute force attack.)
  223.  
  224. Copyrights
  225. ==========
  226.  
  227. This program is hereby donated to the public good. The ufc-crypt
  228. routines are covered under the GNU Licence, and their copyrights are
  229. listed in the source codes. But the rest of it is purely public
  230. domain. Do you want to try making money off my chunks of source? Go
  231. for it. I couldn't care less. I hardly spent any time on it
  232. anyway--maybe two days of off-and-on, tops, including research and
  233. writing this README.
  234.  
  235. Contacting ME
  236. =============
  237.  
  238. bj371@cleveland.freenet.edu
  239.  
  240. Don't ask me for my SnailMail unless you want to send something cool,
  241. like software or a new car.
  242.  
  243. PLEASE please use my PGP public key to encrypt messages to me.
  244. Sysadmin on every system I've ever been in or around are ALL snoopy.
  245. They say they aren't, but I'll bet you a hundred dollars they're
  246. grep'ing the whole damned mail spool regularly. Haven't you read
  247. Bastard Operator From Hell?
  248.  
  249. Future:
  250. ======
  251.  
  252. I dislike writing Future sections because I know how annoying it is to
  253. read them in other peoples' documentations, but I finally gave in,
  254. because it's kind of exciting.
  255.  
  256. I intend to implement the following sometime maybe:
  257.  
  258. - multiple dictionary support
  259.  
  260. - brute force (okay okay if you really want it)
  261.  
  262. - efficient algorithms for once
  263.  
  264. - power-out/time-out/break recovery -- ie: continuing a job
  265. from the last searched position..  this means batch file at startup
  266. support. This is a Good Thing, and means people can do this stuff in
  267. the background and let it simply notify the user upon a crack. This
  268. also means that the resources can be freed up for a while if they are
  269. needed, then things can start up again where they left off.
  270.  
  271. - Coffee-maker startup support. No, really..  I'm serious here!
  272.  
  273. - A better ANSI animation for the working prompt.
  274.  
  275. -sudog, Feb 27, 1997
  276.