File: manual.html

package info (click to toggle)
crack 5.0a-11
  • links: PTS, VCS
  • area: main
  • in suites: stretch
  • size: 9,012 kB
  • sloc: ansic: 7,444; perl: 1,375; sh: 1,062; makefile: 218
file content (1300 lines) | stat: -rw-r--r-- 33,251 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
<html>
<head>
<title>Crack Version v5.0</title>
</head>

<body>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>
<a href="doc/credits,v5.0.txt">Crack Version v5.0</a> User Manual
<br>
Alec Muffett (<a href="mailto:alecm@crypto.dircon.co.uk">alecm@crypto.dircon.co.uk</a>)
</h1>

The above address is correct as of December 1996 - if you are reading
this text significantly after that date, double-check the address
before sending e-mail.
<p>

Discussion of issues relating to running this version of Crack should
be directed to the newsgroup "<a
href="news:comp.security.unix">comp.security.unix</a>" - mention
"<i>Crack5</i>" in the subject line.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>What is Crack?</h1>
<p>

If you are unfamiliar with the concept, Crack is a password guessing
program that is designed to quickly locate insecurities in Unix (or
other) password files by scanning the contents of a password file,
looking for users who have misguidedly chosen a weak login password.
See the <a href="doc/appendix,v4.1.txt">appendix</a> from the previous
version for more details.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>New features.</h1>
<p>

<ul>
<li> Complete restructuring - uses less memory
<p>
<li> Ships with Eric Young's "libdes" as standard
<p>
<li> API for ease of integration with arbitrary <tt>crypt()</tt> functions
<p>
<li> API for ease of integration with arbitrary passwd file format
<p>
<li> Considerably better gecos-field checking
<p>
<li> More powerful rule sets
<p>
<li> Ability to read dictionaries generated by external commands
<p>
<li> Better recovery mechanisms for jobs interrupted by crashes
<p>
<li> Easier to control (eg: to put to sleep during working hours)
<p>
<li> Bundled with Crack6 (minimalist password cracker)
<p>
<li> Bundled with Crack7 (brute force password cracker)
<p>
<li> Tested on Solaris, Linux, FreeBSD, NetBSD, OSF and Ultrix
<p>
</ul>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Requirements.</h1>
<p>

<ul>
<li> Unix-like operating system.
<p>
<li> C Compiler.
<p>
<li> Moderate amount of disk space.
<p>
<li> Lots of CPU time.
<p>
<li> PERMISSION FROM YOUR SYSADMIN.
<p>
<li> Root-privileges, quite possibly.
<p>
<li> "gzip" is extremely desirable.
<p>
<li> "perl", if networking/multiprocessing.
<p>
</ul>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Configuring Crack.</h1>
<p>

<ul>

<li> Unpack the Crack distribution.
<p>

<li> Edit the "Crack" script, configuring the values of CRACK_PATH,
C5FLAGS, CC, CFLAGS and LIBS to suit your operating system
<p>

<li> Does your system use the traditional <tt>crypt()</tt> function to encipher
its passwords?
<p>

If not, then you should skip down a few sections to read "Formats and
other Password Systems"; this could be the case if you are using
NetBSD, FreeBSD, some versions of Digital Unix, Ultrix and OSF, etc.
<b>All</b> users should read this section, however it is most
pertinent to FreeBSD/NetBSD and OSF users, now.
<p>

<li> If you your system <b>does</b> use the traditional <tt>crypt()</tt>
algorithm, change directory into "src/libdes" and set about
configuring the "libdes" code so that it compiles on your system when
you simply type "make".
<p>

Libdes is <b>not</b> part of Crack - it is a fast and elegant
implementation of DES which includes a very fast version of the
traditional <tt>crypt()</tt> algorithm.  
<p>

Libdes is owned and maintained by Eric Young (of SSLeay fame) and I am
grateful for his permission to include a copy of it with the Crack
distribution, though I believe it has since been superseded by his
SSLeay package, for which support will be provided in a future
revision of Crack.
<p>

Crack users should spend some time trying to optimise "libdes" for
speed; read the "INSTALL" file, and work out the best flags for your
compiler to build "libdes".
<p>

Caveats:
<p>

<ul>

<li> The first thing you'll have to do is edit the libdes Makefiles in
order that they are using the correct C compiler and flags; for
instance this may or may not be "gcc".
<p>

<li> Users on 64-bit machines such as the DEC Alpha, may wish to make
use of the "DES_LONG" feature as documented in the "VERSION" file.
<p>

<li> FreeBSD and other strictly POSIX systems may need "-DTERMIOS"
instead of "-DTERMIO" in "src/libdes/Makefile"; it is not critical
functionality, but "libdes" will not compile cleanly without it.
<p>

<li> People using a recent revision of "gcc" (2.7.0 or above)
generally get the best results by specifying:
<p>

<pre>
    CFLAGS=-O4 -fomit-frame-pointer -funroll-loops
</pre>
<p>

...in the "Makefile" or "Makefile.uni" (for GNU "make") as
appropriate.
<p>
</ul>

<li> Change back to the "Crack" directory and do:
<p>

<li> Crack -makeonly
<p>

...which, if all is well, should build the binaries and store them in
the "run/bin" directory somewhere, after which you can move onto the
next stage.
<p>

If you are using Crack in network mode, in a mixed environment, I
strongly recommend your going around and manually building the
binaries on each machine, via "<tt>Crack -makeonly</tt>", so that
there are no surprises when actually running it, and also giving you
the chance to install different 
<tt>crypt()</tt> algorithms, tuned to your
machine architecture, if you are so inclined.
<p>



</ul>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Running Crack.</h1>

The general form to invoke Crack is:
<p>

<pre>
    Crack [options] [-fmt format] [file ...]
</pre>
<p>

Once Crack has been configured, you should be able to do:
<p>

<pre>
    Crack -makeonly
</pre>
<p>

...and then:
<p>

<pre>
    Crack -makedict
</pre>
<p>

Which should create and compress the dictionaries for you; if
something goes wrong during this process, see the troubleshooting
notes, below.
<p>

At this point, if you are a Crack v4.1 user, take a copy of your Crack
v4.1 "F.merged" file and place it in your "run" directory; this will
preserve the information that you have previously gleaned about
passwords on your network. Now, you are ready to try:
<p>

<pre>
    Crack [filename]
eg: Crack -nice 10 /etc/passwd
</pre>
<p>

...where "filename" is a file that stores password entries, eg:
"/etc/passwd".  If you run a shadowed password system or have NIS/YP,
see below.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Full list of Options.</h1>
<p>

<dl>

<dt> -debug
<dd> lets you see what the Crack script is doing.
<p>

<dt> -recover

<dd> used when restarting an abnormally-terminated run; suppresses
rebuild of the gecos-derived dictionaries.
<p>

<dt> -fgnd
<dd> runs the password cracker in the foreground, with stdin, stdout and
stderr attached to the usual places.
<p>

<dt> -fmt format
<dd> specifies the input file format.  See below.
<p>

<dt> -from N
<dd> Starts password cracking from rule number "N"; see below
<p>

<dt> -keep
<dd> Prevents deletion of the temporary file used to store the password cracker's input.
<p>

<dt> -mail
<dd> E-Mail a warning message to anyone whose password is cracked.  See "scripts/nastygram".
<p>

<dt> -network
<dd> Runs the password cracker in "network" mode.  See below.
<p>

<dt> -nice N
<dd> Runs the password cracker at a reduced priority, so that other jobs
can take priority over the CPU.
<p>

<dt> -makeonly
<dt> -makedict
<dd> Used for building Crack binaries and dictionaries.  See above.
<p>

<dt> -kill filename
<dt> -remote
<dd> Internal options used to support networking.

</dl>

<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Shadow Password Systems, NIS/YP and the like.</h1>
<p>

If you are running NIS, the simplest way to gather some data for
password cracking is to do:
<p>

<ul>
<li> ypcat passwd &gt; ypfile
<li> Crack [options] ypfile
</ul>
<p>

If your system uses "shadow" password files (SV, Solaris2, AIX, some
BSD-en), then your best bet is to merge the information from the main
and shadow password files back into one; two example scripts are
provided to do this:
<p>

<ul>
<li> shadmrg.aix
<li> shadmrg.sv
</ul>
<p>

...and it is expected that a user who can read a shadow password file
has enough expertise to modify these examples (if necessary) to suit
their local password system.
<p>

<!-- -------------------------------------------------- --> <hr>

<h1>
Formats and other Password Systems.
<br>
(FreeBSD, NetBSD, Ultrix, OSF)
</h1>
<p>

Crack v5.0 is a relatively smart program, which is pre-programmed to
expect a variety of <tt>crypt()</tt> algorithms to be available for cracking in
any particular environment.
<p>

Specifically, it supports "libdes" as shipped, Michael Glad's "UFC" in
either of its incarnations (as "ufc" and as GNU's stdlib crypt), and
it supports whatever <tt>crypt()</tt> algorithm is in your standard C library.
<p>

For people who wonder about how Crack picks up which algorithm to use:
the "Makefile" in the "src/util" directory calls the "mkcracker"
script, which then goes hunting for directories:
<p>

<ul>
<li> $CRACK_HOME/src/libdes          == eric young's libdes
<li> $CRACK_HOME/src/ufc_crypt       == ufc from USENET
<li> $CRACK_HOME/src/crypt           == ufc from GNU
</ul>
<p>

...and, lacking any of these, it assumes that it should use the
<tt>crypt()</tt> function from the standard C library.
<p>

The "mkcracker" script then calls "make" in that directory (if one
exists) and if "make" is happy (and exits without errors), "mkcracker"
then recurses a call to a target embedded in src/util/Makefile.
<p>

For traditional <tt>crypt()</tt> users, I ship with "libdes".  If this is not
what you need, remove it, and add something else.  This needs more
testing by me, don't be shocked if it is fragile.  Libdes is usually
the fastest.
<p>

FreeBSD and NetBSD users: if you're using the new passwd file format
but you are using the traditional <tt>crypt()</tt> algorithm, after configuring
"Crack" and "libdes", you should be able to get away with doing:
<p>

<pre>
     Crack [options] -fmt bsd /etc/master.passwd ...
</pre>
<p>

However, if you're using a MD5-based version of <tt>crypt()</tt>, you must
first do:
<p>

<pre>
    mv src/libdes src/libdes,orig
    cd src/util
    cp elcid.c,bsd elcid.c
</pre>
<p>

...before building the Crack binaries and dictionaries.
<p>

For <tt>crypt16()</tt> sufferers (such as some Ultrix, OSF and Digital
Unix machines) - you should do:
<p>

<pre>
    mv src/libdes src/libdes,orig
</pre>
<p>

...and then go pick up a copy of GNU libc-crypt from a GNU ftp site
(eg: prep.ai.mit.edu) - observing all cryptography export and import
restrictions as appropriate - and unpack it in "src" creating a
"crypt" subdirectory.
<p>

Then you should:
<p>

<ul>
<li> edit src/util/elcid.c to use <tt>crypt16()</tt> (change #undef to #define)
<li> edit same file to set the value of PLAINTEXTSIZE appropriately (16)
<li> continue to configure and run Crack as normal (I hope).
</ul>
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>
Weird Password Systems.
<br>
(Novell, Kerberos Tickets, LAN-Manager, VMS)
</h1>
<p>

Crack v5.0 does not (as distributed) support cracking these sorts of
systems, although I am aware that versions of Crack v4.1f were
modified to support one or more of the above.
<p>

Crack v5.0 takes a different approach; the word guesser sits between
two software interfaces:
<p>

<ul>
<li> SPF (aka: <i>spiff</i>) - standard password format
<li> ELCID - external library crypt interface definition
</ul>

...and when Crack is invoked, it first translates whatever password
file is presented to it into SPF; this is achieved by a program called
"xxx2spf" (the value of "xxx" is set through the "-fmt" option to
Crack, default "trad").
<p>

The SPF input is then filtered to remove data which has been cracked
previously, is sorted, and then passed to the cracker, which starts
generating guesses and tries them through the ELCID interface, which
contains a certain amount of flexibility to support salt collisions
(which are detected by the SPF translator) and parallel or vector
computation.
<p>

The interfaces are not well documented at the moment, but it should
not prove hard to write "kerb2spf" or "uaf2spf" translators or
similar, perhaps in "Perl", and then wire the appropriate hash
algorithm into a ELCID stub by examining the extant code.
<p>

People who seriously intend to try this are welcome to contact the
author for more details.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Recovering from crashes and cleaning up.</h1>
<p>

If a Crack session is killed accidentally, it can be restarted with
moderate efficiency by doing:
<p>

<pre>
    mv run/Dhostname.N run/tempfilename
    Crack -recover -fmt spf run/tempfilename
</pre>
<p>

However if all you wish to do is start cracking passwords from some
specific rule number, or to restart a run whilst skipping over a few
rulesets, try:
<p>

<pre>
    Crack [-recover] -from N filename ...
</pre>
<p>

...where N is the number of the rule to start working from.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Terminating a Crack run.</h1>
<p>

If you want to bring down a Crack run cleanly, the correct command is:
<p>

<pre>
    scripts/plaster
</pre>
<p>

...and then if you want to clean up, remove scratch files and merge
the feedback prior to starting a new Crack run, do:
<p>

<pre>
    make tidy
</pre>
<p>

...or variations thereof, as listed in the "Makefile".
<p>

Users who merely want to put Crack to sleep temporarily are encouraged
not to kill the process, but instead examine the "pauser" script,
which will temporarily put Crack to sleep if a file named
"<tt>GOTO-SLEEP</tt>" is created in the $CRACK_HOME directory.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Viewing Crack output.</h1>
<p>

Crack no longer generates human-readable output directly; instead, to
see the results of a Crack run, the user should do:
<p>

<pre>
    ./Reporter [-quiet] [-html]
</pre>
<p>

...every so often, to see what passwords have been cracked, as well as
view errors that have been detected in the source password files, etc.
<p>

Guesses are listed chronologically, so users who wish to see
incremental changes in the output as Crack continues to run over a
course of days or weeks, are encouraged to wrap invocations of
"Reporter" in a script with "diff".
<p>

The "-quiet" option suppresses the reporting of errors in the password
file (corrupt entries, etc), whilst "-html" produces output in a
fairly basic HTML-readable format.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Viewing Crack rulesets.</h1>
<p>

Crack rules are numbered 1 to N (where N is large) on the basis of the
mangling rule and which dictionary it applies to.  Users can view a
list of numbered rules (suitable for use with Crack's "-from" option)
by doing:
<p>

<pre>
    run/bin/ARCHITECTURE/kickdict -list
</pre>
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Configuring for out-of-hours running.</h1>
<p>

Users are encouraged to examine/tweak the contents of
"scripts/pauser", which can be modified to put Crack to sleep at
arbitrary times of day or upon arbitrary conditions, like the number
of users on a machine.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Getting Crack to mail users who have weak passwords.</h1>
<p>

I am still not convinced of the <a href="doc/humour.txt">wisdom</a> of
mailing the fact that a user has a weak password to the user herself;
after all, if it's a moribund account, this will achieve nothing, and
the security hole will remain.  I much prefer locking such accounts
in the first place.
<p>


Not to mention what happens if your mail logs are world-readable,
allowing your users to work out who got sent an e-mail by the password
cracker, and when...
<p>

However, as some people still desire the functionality, Crack supports
a "-mail" option which will invoke the "nastygram" script when a
user's password is broken; the user's name will be supplied as
argument to the script.
<p>

For those cracking passwords in a large, multi-network environment,
with password files from several hosts, I include two extra SPF
converters, "tradmail2spf" and "bsdmail2spf".
<p>

Choose whichever script is appropriate for your crypt algorithm, and
store your passwd files in a directory:
<p>

<pre>
    pw/hostname1 pw/hostname2 ...
</pre>
<p>

Then, by invoking Crack as (for example):
<p>

<pre>
    Crack -mail -fmt tradmail pw/*
</pre>
<p>

...users listed in the file "pw/hostname1" will have mails sent to
"username@hostname1"; users in "pw/hostname2" will be sent mail at
"username@hostname2", and so forth.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Configuration Files.</h1>
<p>

Apart from the contents of the "Crack" script itself, there are a
number of auxiliary configuration files in Crack which the user
should be aware of:
<p>

<ul>

<li> conf/dictgrps.conf
<p>

Crack 5.0 supports the notion of dictionary groups - collations of
words taken from a selection of raw text dictionaries (with words
given, one per line) permitting the user to group her dictionaries
into "most-likely", "less-likely" and "least-likely" to generate a
successful password guess.
<p>

Dictionary groups are named ("tagged") and specified by entries in the
"dictgrps.conf" file; as distributed, the groups are tagged by numbers
1 thru 3, and this file contains filename wildcards which specify the
raw dictionaries used to create each group.
<p>

For instance:
<p>

<pre>
    1:/usr/dict/*words* dict/1/*
</pre>
<p>

...specifies that dictionary group "1" is to be composed from all the
words held in filenames matching the pattern
<tt>/usr/dict/*words*</tt>, as well as the contents of the "dict/1"
subdirectory of $CRACK_HOME.  
<p>

Note that there need be no actual relationship between the specific
dictionary tag ("1") and the names of the files that comprise it
("dict/1/*").
<p>


<li> conf/dictrun.conf
<p>

This file contains a set of controls for the password cracker's
dictionary generation algorithm.
<p>

When "Crack" starts up, in addition to creating the dictionary groups
cited in "dictgrps.conf", two other dictionary groups are created:
"gecos" and "gcperm".  
<p>

The "gecos" group contains only words directly derived from the
information held in the password ("SPF") file; the "gcperm" group
holds words which are mechanically created by permuting and combining
parts of words held in the password file (eg: "Alec Muffett" becomes
"AMuffett", "AlecM", etc).
<p>

When the cracker is running, it reads the "dictrun.conf" file and
works its way through a set of commands which specify how to generate
guesses; entries in the configuration file look like one of:
<p>

<pre>
    dictionary-tag:rule-filename
    dictionary-tag:| command-line
    :| command-line
</pre>
<p>

In the first two examples, the cracker will read the tagged dictionary
group and from it will create a stream of guesses, either by taking
successive mangling rules from "rule-filename" and applying them to
the cited dictionary group, or by piping the dictionary group through
a Unix command given in "command-line".
<p>

In the third example, the cracker will read a list of guesses directly
from the output generated by "command-line", until the input source is
exhausted.  See the "dictrun.conf" file for examples.
<p>

The rule-filenames cited above are the names of files which contain
"mangling" rules.  These rules are macro commands, one per line, which
specify patterns and actions that are applied to words from a
dictionary in order to generate a series of guesses.
<p>

For instance, onesuch rule:
<p>

<pre>
    /ese3u
</pre>
<p>

...will select words which contain the letter "e", replace it with the
digit "3", and force the rest of the word to uppercase.  For more
detailed explanation and samples, see the files in the "conf"
directory, and the section on rule syntax, below.
<p>


<li> conf/globrule.conf
<p>

This file contains just two mangling rules; this first is applied to
all words as they are read into the dictionary generating program, and
the second applied to all words as they are about to leave the
dictionary program to be sorted and then used as guesses.
<p>

This permits users to hard-code restrictions on the minimum and
maximum length of guesses that Crack should generate, as well as any
other arbitrary restrictions that should be desired.
<p>

The default rule merely truncates guesses at the maximum useful size,
to prevent the cracker from doing un-necessary work attempting to uses
different words for guesses that are, from the computer's point of
view, identical.
<p>

<li> conf/network.conf
<p>

This is the file used to configure Crack for network running; this file
contains lines, each of which has several fields:
<p>


<pre>
    host:relpow:nfsbool:rshuser:crackdir
</pre>
<p>

Where:
<p>


<ul>

<li><tt>host</tt><br> 

This is the name of the host to which Crack should "rsh", in order to
despatch a job.  There can be several instances of the same hostname
in the file, if desired, in order to dispatch more than one job to a
given host (if it has more than one CPU, for instance).
<p>

<li><tt>relpow</tt><br>

This is a fairly arbitrary measure of the host's power, so that Crack
can divide the workload of cracking evenly according to ability.  
<p>

The traditional value for this field is the number of crypts/second
that the host's CPU can achieve (see the test suite bundled with
libdes), or some guesstimate of relative power based on your slowest
machine being "1", with a fudge-factor thrown in for machines that can
only do cracking out-of-hours.
<p>

<li><tt>nfsbool</tt> (default: "y")<br>
<p>

This should be a string, "y" or "n", specifying whether the remote
host shares the "Crack" filestore with the master server from which
"Crack -network" is being run. 
<p>

<li><tt>rshuser</tt> (optional)<br>
<p>

This specifies the username to invoke for the "rsh" command when
connecting to the host, if it is different from the user who is
running "Crack".
<p>

<li><tt>crackdir</tt> (required)<br>
<p>

This specifies the path to the directory in which the "Crack" script
resides, on the remote host.

</ul>
<p>

Once this file has been correctly configured, the user should be able
to invoke "Crack -network", as below.
<p>

<li> conf/rules.
<p>

These are the files containing mangle rules, one per line, as are
utilised in the "dictrun.conf" file, above; comments should be on a
line of their own and begin with a "<tt>#</tt>" character, and
trailing whitespace is ignored.
<p>


<li> scripts/nastygram
<li> scripts/pauser
<p>

There are the two scripts which will probably be most tweaked by the
user; "nastygram" is a script which dispatches notification of
passwords being cracked to the user concerned (see elsewhere in this
text for details) and will require configuration of the "mail" command
to be used, and of the message text.
<p>

"Pauser" is a script that the password cracker will execute
sporadically (at most once per minute) which can be written so as not
to exit if certain conditions exist in the operating system, eg: that
it is being executed in working hours, or that there are too many
users on the machine, or whatever.
<p>

The "cracker" will be suspended until the "pauser" script exits, and
therefore this permits the user a great deal of control over how/when
"Crack" operates.

<p>

</ul>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Troubleshooting common OS-related Problems:</h1>
<p>

<ul>

<li> The "sort" command barfs from lack of space
<p>

Crack can make quite heavy demands on space in "/tmp" when sorting
password data or dictionaries, which can (on occasion) lead to
overfull /tmp partitions, with all the pain which that usually causes.
<p>

To obviate this problem, crack always invokes "sort" using the
"crack-sort" wrapper, held in the "scripts" directory; this permits
the user to tweak options on the "sort" command to make it use a
different, larger area of spool space, by editing the script.
<p>

<li> HP/UX and networking (rsh, rcp)
<p>

Some operating systems (notably HP/UX) do (or did) rename the standard
Berkeley "rsh" executable to "remsh".  If you suffer thusly, you can
supply the name of your local "rsh" command as a variable in the
"Crack" script, so that Crack can dispatch networked jobs when running
in "-network" mode.
<p>

<li> Mail command in "nastygram"
<p>

Users who intend to use the "-mail" option for "Crack" are reminded
that they should take time to configure the "nastygram" script held in
the "scripts" directory for their site, especially the body of the
message that is sent, as well as the "mail" command (sometimes "Mail"
or "mailx") that is used to dispatch the message.
<p>

<li> smartcat: /usr/dict/*words*: No such file or directory
<p>

This message will appear on some systems (notably FreeBSD) which do
not have a "words" file, or similarly-named dictionaries, held in
"/usr/dict".
<p>

In the specific instance of FreeBSD I believe that the files are held
in /usr/share/dict or similar.  Edit the "conf/dictgrps.conf" file to
remedy this.
<p>

</ul>
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Multiprocessing and Networking.</h1>
<p>

Since early versions of Crack, it has been possible to distribute the
load of password cracking around hosts on a network (or among several
processors on a single machine) in a manner proportional to the power
of the machines at your disposal.
<p>

In Crack 5.0, this functionality requires the existence of a "perl"
binary on your master machine, but apart from that little has changed
in essence; the user should:
<p>

<ol>
<li> edit "conf/network.conf" (see above)
<li> run: <tt>Crack -network [other flags] filename ...</tt>
</ol>
<p>

...whereupon the input will be divided into parts and distributed to
the machines via "rsh", and the crackers will be invoked.
<p>

If the machines are not connected via NFS (or other shared filestore)
there will be a certain loss of flexibility in gathering report
output, but it is still possible to do effective cracking in such a
setup, so long as the flags are set in the "network.conf" file to copy
the gecos-derived dictionaries to the remote host before starting the
cracker; there will merely be a little more manual work required.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>Dictionary Generation (Mangling) Rules</h1>
<p>
<ul>

<li> <i>noop:</i> [space] or : (colon)<p>

The presence of a colon or space in a rule affects nothing in the
output from the rule; they are permitted for reasons of clarity.
<p>

<li> <i>restart:</i> <tt>*</tt>
<p>

The 'restart' command - an asterisk - resets the buffer to an initial
starting state; this is not actually very useful for Crack, but may
be used in other applications
<p>

<li> <i>prepend:</i> <tt>^X</tt>
<p>

The prepend rule affixes the character X to the beginning of the word
in the buffer.
<p>

<li> <i>append:</i> <tt>$X</tt>
<p>

The append rule affixes the character X to the end of the word in the
buffer.
<p>

<li> <i>dfirst:</i> <tt>[</tt>
<p>

Deletes the first character from the word in the buffer.
<p>

<li> <i>dlast:</i> <tt>]</tt>
<p>

Deletes the last character from the word in the buffer.
<p>

<li> <i>reverse:</i> <tt>r</tt>
<p>

Takes the word in the buffer and turns it back to front.
<p>

<li> <i>duplicate:</i> <tt>d</tt>
<p>

Takes the word in the buffer and appends a copy of itself.
<p>

<li> <i>reflect:</i> <tt>f</tt>
<p>

Takes the word in the buffer and appends a reversed copy of itself.
<p>

<li> <i>uppercase:</i> <tt>u</tt>
<p>

Takes the word in the buffer and forces any letters to uppercase.
<p>

<li> <i>lowercase:</i> <tt>l</tt>
<p>

Takes the word in the buffer and forces any letters to lowercase.
<p>

<li> <i>capitalise:</i> <tt>c</tt>
<p>

Takes the word in the buffer, capitalises the first character and
forces any other letters to lowercase.
<p>

<li> <i>ncapital:</i> <tt>C</tt>
<p>

Takes the word in the buffer, lowercases the first character and
forces any other letters to uppercase.
<p>

<li> <i>pluralise:</i> <tt>p</tt>
<p>

Takes the word in the buffer and pluralises it according to English
dictionary rules.
<p>

<li> <i>togcase:</i> <tt>t</tt>
<p>

Swaps upper for lower-case in the word, and vice versa.
<p>

<li> <i>lt:</i> <tt>&lt;N</tt>
<p>

Rejects the word unless it is less-than N characters long (see
Numbering, below).
<p>

<li> <i>gt:</i> <tt>&gt;N</tt>
<p>

Rejects the word unless it is greater-than N characters long (see
Numbering, below).
<p>

<li> <i>match:</i> <tt>/X</tt> or <tt>/?C</tt>
<p>

Rejects the word unless it contains character X, or a character which
is a member of class C.
<p>

<li> <i>not:</i> <tt>!X</tt> or <tt>!?C</tt>
<p>

Rejects the word if it contains character X, or a character which is a
member of class C.
<p>

<li> <i>mfirst:</i> <tt>(X</tt> or <tt>(?C</tt>
<p>

Rejects the word unless the first character is X, or is a member of
class C.
<p>

<li> <i>mlast:</i> <tt>)X</tt> or <tt>)?C</tt>
<p>

Rejects the word unless the last character is X, or is a member of
class C.
<p>

<li> <i>equals:</i> <tt>=NX</tt> or <tt>=N?C</tt>
<p>

Rejects the word unless character number N (see Numbering, below) is
X, or is a member of class C.
<p>

<li> <i>atleast:</i> <tt>%NX</tt> or <tt>%X?C</tt>
<p>

Rejects the word unless it contains at least N instances of character
X, or of members of class C.
<p>

<li> <i>substitute:</i> <tt>sXY</tt> or <tt>s?CY</tt>
<p>

Replaces all instances of X, or of members of class C, with character Y.
<p>

<li> <i>extract:</i> <tt>xNM</tt>
<p>

Extracts the substring of length M (see Numbering, below), starting
from position N, from the word, and discards the rest.
<p>

<li> <i>overstrike:</i> <tt>oNX</tt>
<p>

Overwrites the character at position N with X; no bounds checking is
done other than to ensure you won't stomp on a NUL terminator, so
judicious use of <tt>&gt;</tt> and <tt>&lt;</tt> is advised.
<p>

<li> <i>insert:</i> <tt>iNX</tt>
<p>

Inserts character X at position N, shuffling all other letters rightwards.
<p>

<li> <i>purge:</i> <tt>@X</tt> or <tt>@?C</tt>
<p>

Remove all instances of X (or characters of class C) from the word.
<p>

<li> <i>snip:</i> <tt>'N</tt>
<p>

Truncate word at length N.
<p>

</ul>
<p>

<h1>Character Classes</h1>
<p>

These are shorthands for convenient batches of characters, which might
be used in rules above.
<p>

<ul>
<li> <i>vowels:</i> <tt>?v</tt>
<li> <i>consonants:</i> <tt>?c</tt>
<li> <i>whitespace:</i> <tt>?w</tt>
<li> <i>punctuation:</i> <tt>?p</tt>
<li> <i>symbols:</i> <tt>?s</tt>
<li> <i>lowercase:</i> <tt>?l</tt>
<li> <i>uppercase:</i> <tt>?u</tt>
<li> <i>digits:</i> <tt>?d</tt>
<li> <i>alphabetics:</i> <tt>?a</tt>
<li> <i>alphanumerics:</i> <tt>?x</tt>
</ul>

<h1>Numbering</h1>
<p>

In all circumstances where a numeric argument to a rule can be
applied, numbers 0..36 can be specified by using the characters
"<tt>0</tt>" thru "<tt>9</tt>" and "<tt>A</tt>" thru "<tt>Z</tt>".
<p>

Users may also specify lengths relative to the maximum plaintext
password length as specified by their ELCID library; in this case,
where "<i>x</i>" is the maximum plaintext length, the length <i>x</i>
is represented by an asterisk "<tt>*</tt>", the length (<i>x</i> - 1)
by a hyphen "<tt>-</tt>", and (<i>x</i> - 1) by a plus, "<tt>+</tt>".
<p>

All characters in a word are numbered starting from zero, so to
overstrike the first character of a word with X, you would use:
<p>

<pre>
    o0X
</pre>
<p>

...as a rule.
<p>

<!-- -------------------------------------------------- --> <hr>

<h1>What is a weak password?</h1>
<p>

See <a href="doc/faq.txt">doc/faq.txt</a>, <a
href="doc/appendix,v4.1.txt">doc/appendix,v4.1.txt</a>, and <a
href="doc/fips181.txt">doc/fips181.txt</a>.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>How do I make Crack run multi-threaded?</h1>
<p>

See <a href="doc/threading.txt">doc/threading.txt</a> and <a
href="doc/usenet-article.txt">doc/usenet-article.txt</a>.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>How do I run Crack under a GUI?</h1>
<p>

See <a href="doc/gui.txt">doc/gui.txt</a>.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>How do I run Crack under DOS/Win95?</h1>
<p>

Reformat your hard-drive and install Linux, then try again.
<b>CAUTION</b>: this process may lose data.
<p>

<!-- -------------------------------------------------- --> <hr>
<p>

<h1>How do I run Crack under WinNT?</h1>
<p>

I have no idea, though I suspect there must be some password paradigm
in use under NT to make it worthwhile; if you have enough unixy stuff
on your NT machine, you might be able to hack something up, else look
into installing Perl for NT and use Crack6.
<p>

<!-- -------------------------------------------------- --> <hr>

</body>
</html>