/
DYNAMIC
2992 lines (2872 loc) · 137 KB
/
DYNAMIC
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
How to use the 'dynamic' format within john.
John has been enhanced to be able to handle MANY MD5/SHA1 and other cipher
variants easily.
'variants' are things like:
md5($p) (Note, $p is the password, $s will be the salt, etc)
md5(md5($p)) (Note, this is md5 of the 32 byte result of a prior md5)
md5($p.$s) (Note, . is the concatenate operator, so $p.$s is
password with salt appended)
sha1($p) (Note, $p is password, and sha1 is the cipher).
sha1(md5($p)) Here we first run md5 on password, then sha1 on the
resultant 'hex' string.
sha512($s.sha512($p.$s).$p) This uses a couple of calls to sha512.
The intermedidate results are possible to be in
base-16 (or base-16 uppercase), base-64 (MIME), or
raw 64 bytes.
...
Most of the above rules are php 'style' rules, but I think in php,
$pass is used, and $salt is used. In this document, they have been
simplified to $p and $s.
This is done by using a new file format string: dynamic_# where
the # is a number. John reserves numbers from dynamic_0 up to
dynamic_999 for 'built-in' formats. Not all are defined at this
time, but those have been reserved.
The format of the input file lines will be:
userID:$dynamic_#$base_16_hash[$salt]
Salts can contain some problematic characters. Some of these would be
characters such as: : \r \n \ NULL, etc. The : (colon) char is used
by JtR as a field separator. If it exists in the salt, it will split
the salt into multiple fields (i.e. wrong). A carriage return or line
feed, will cause the line to split, and JtR to not read it right.
NULL bytes are a problem in any C file, using normal 'string' functions.
The \ char, is used as a quoting char within dynamic, and can cause issues.
One other recently found issue, is if the salt ends in ' ' or '\t' (space
or tab), then if the dyna hash is placed on a line by itself (i.e. without
a user: prepended), then jtr will trim the whitespace off. This is a known
issue, and this is just a bad side effect of a known wanted behavior where
the raw hash files are cleaned up during processing.
DUE to all of these problems, dynamic has been expanded to take this as
the salt: $dynamic_#$base_16_hash$HEX$hex_bytes_of_salt. In this
format, if the salt was 1234, then $HEX$31323334 would be the equivalent
value. This allows salts such as $\x0:\r\nBadSalt to actually be encoded.
This salt CAN be used, if you use the representation:
$HEX$003a0a0d42616453616c74.
There is an application in ./run which can 'help' This is ./run/raw2dyna
This process will convert files in the format of hashCsalt (c can be any char),
into the proper $dynamic_#$hash$salt It can also handle saltChash (if
salt is a fixed size). It also properly handle the problematic characters,
and uses the $HEX$hex_salt method, if there are bad characters in the salt.
There may be a 2nd salt added in the near future, but not sure how it
will be implemented.
Here is an 'example' of the format required:
userID:$dynamic_0$28fc2782ea7ef51c1104ccf7b9bea13d
which is 'raw' md5, with a password of 1402
userID:$dynamic_6$8d8cac84f234f42e32daeb94e7cd49e8$*.*
which is in the vBulletin format: md5(md5($p).$s), and which has a
fixed 3 byte salt (the $*.* above is the salt signature, and the
salt is *.*), solomon1 is the password for the above hash. NOTE
vBulletin is actually dynamic_7. It is the expression format, but
puts to additional constraints on input. dynamic_7 forces a 3 byte
salt, and it will NOT allow ':' character to be used as a separator,
since vBulletin salts can contain that character. However, the
above dynamic_6 works for this document, since *.* salt does not
have a ':'
Expressions can be added to john.conf (john.ini), dynamic.conf
(included by john.conf) or john.local.conf to allow an end user
to add a new format type, without having to do ANY coding at all.
The end user would have to learn the $dynamic_n$
primitives, and how the data is used (input data, key data,
encryption data, etc). Also, the user would have to build
properly formatted SAMPLE test values (john requires this).
For the full 'HOW TO USE' documentation, see the dynamic.conf.
How to build the 'test' value is beyond the scope of this readme,
but a trivial example might help.
Expression format: md5(md5($p).md5($p))
Password test1
md5(test1) == 5a105e8b9d40e1329780d62ea2265d8a
so we want to md5 that result concatenated
so md5(md5(test1).md5(test1)) is the same as
md5(5a105e8b9d40e1329780d62ea2265d8a5a105e8b9d40e1329780d62ea2265d8a)
which equals 478b10974f15e7295883224fd286ccba
so a proper 'test' line is:
Test=$dynamic_1003$478b10974f15e7295883224fd286ccba:test1
( as can be seen in dynamic.conf for dynamic_1003 )
To get a list of all dynamic formats, you can use
./john --list=subformats
This command will create output like this:
Format = dynamic_0 type = dynamic_0: md5($p) (raw-md5)
Format = dynamic_1 type = dynamic_1: md5($p.$s) (joomla)
Format = dynamic_2 type = dynamic_2: md5(md5($p)) (e107)
...
Format = dynamic_32 type = dynamic_32: md4($p.$s)
Format = dynamic_33 type = dynamic_33: md4(unicode($p))
Format = dynamic_34 type = dynamic_34: md5(md4($p))
UserFormat = dynamic_1001 type = dynamic_1001 md5(md5(md5(md5($p))))
UserFormat = dynamic_1002 type = dynamic_1002 md5(md5(md5(md5(md5($p)))))
UserFormat = dynamic_1003 type = dynamic_1003 md5(md5($p).md5($p))
The "Format = ..." lines list builtin formats, the lines "UserFormat = ..."
list user formats (or sample formats).
The builtiin formats that john has right now are:
------------+-------------------------+-------+------------------
Signature | expression | Salt | notes
------------+-------------------------+-------+------------------
dynamic_0 | md5($p) | No | raw-md5
dynamic_1 | md5($p.$s) | Yes | (joomla)
dynamic_2 | md5(md5($p)) | No | double md5 (e107)
dynamic_3 | md5(md5(md5($p))) | No | triple md5
dynamic_4 | md5($s.$p) | Yes | (OS Commerce)
dynamic_5 | md5($s.$p.$s) | Yes |
dynamic_6 | md5(md5($p).$s) | Yes |
dynamic_7 | md5(md5($p).$s) | Yes | vBulletin. 3 byte salt, salt uses ':' char
dynamic_8 | md5(md5($s).$p) | Yes |
dynamic_9 | md5($s.md5($p)) | Yes |
dynamic_10 | md5($s.md5($s.$p)) | Yes |
dynamic_11 | md5($s.md5($p.$s)) | Yes |
dynamic_12 | md5(md5($s).md5($p)) | Yes | (IPB)
dynamic_13 | md5(md5($p).md5($s)) | Yes |
dynamic_14 | md5($s.md5($p).$s) | Yes |
dynamic_15 | md5($u.md5($p).$s) | Yes |
dynamic_16 | md5(md5(md5($p).$s).$s2)| Yes |
dynamic_17 | phpass ($H$ and $P$) | Yes | phpass and PHPbb-v3 hashes
dynamic_18 | PostOffice MD5 (PO) | Yes | md5($s.Y.$p.\xF7.$s) (Post.Office MD5)
dynamic_19 | Cisco PIX | No |
dynamic_20 | Cisco PIX (salted) | Yes |
dynamic_21 | HTTP Digest Access Auth | Yes | Contains a 'special' salt function.
dynamic_22 | md5(sha1($p)) | No | Use sha1 internally, but sill md5 hash (32 byte hex number)
dynamic_23 | sha1(md5($p)) | No | Requires a 40 byte hex number (valid sha1 input)
dynamic_24 | sha1($p.$s) | Yes | Requires a 40 byte hex number (valid sha1 input)
dynamic_25 | sha1($s.$p) | Yes | Requires a 40 byte hex number (valid sha1 input)
dynamic_26 | sha1($p) (raw-sha1) | No | Requires a 40 byte hex number (valid sha1 input)
dynamic_27 | FreeBSD md5 | Yes |
dynamic_28 | Apache MD5 | Yes |
dynamic_29 | md5(unicode($p)) | No |
dynamic_30 | md4($p) (raw-md4) | No |
dynamic_31 | md4($s.$p) | Yes |
dynamic_32 | md4($p.$s) | Yes |
dynamic_33 | md4(unicode($p)) | No |
dynamic_34 | md5(md4($p)) | No |
dynamic_35 | sha1(uc($u).:.$p) | Yes | ManGOS
dynamic_36 | sha1($u.:.$p) | Yes | ManGOS2
dynamic_37 | sha1(lc($u).$p) | Yes | SMF
dynamic_38 | sha1($s.sha1($s.sha1($p)))| Yes | Wolt3BB, OpenCart
dynamic_39 | md5($s.pad_16($p)) | Yes | Net-md5. Long salt, passwords are 16 bytes, null padded for under 16 bytes
dynamic_40 | sha1($s.pad_16($p)) | Yes | Net-sha1. Long salt, passwords are 16 bytes, null padded for under 16 bytes
dynamic_50 | sha224($p) | No |
dynamic_51 | sha224($s.$p) | Yes |
dynamic_52 | sha224($p.$s) | Yes |
dynamic_53 | sha224(sha224($p)) | No |
dynamic_54 | sha224(sha224_raw($p)) | No |
dynamic_55 | sha224(sha224($p).$s) | Yes |
dynamic_56 | sha224($s.sha224($p)) | Yes |
dynamic_57 | sha224(sha224($s).sha224($p)) | Yes |
dynamic_58 | sha224(sha224($p).sha224($p)) | No |
dynamic_60 | sha256($p) | No |
dynamic_61 | sha256($s.$p) | Yes |
dynamic_62 | sha256($p.$s) | Yes |
dynamic_63 | sha256(sha256($p)) | No |
dynamic_64 | sha256(sha256_raw($p)) | No |
dynamic_65 | sha256(sha256($p).$s) | Yes |
dynamic_66 | sha256($s.sha256($p)) | Yes |
dynamic_67 | sha256(sha256($s).sha256($p)) | Yes |
dynamic_68 | sha256(sha256($p).sha256($p)) | No |
dynamic_70 | sha384($p) | No |
dynamic_71 | sha384($s.$p) | Yes |
dynamic_72 | sha384($p.$s) | Yes |
dynamic_73 | sha384(sha384($p)) | No |
dynamic_74 | sha384(sha384_raw($p)) | No |
dynamic_75 | sha384(sha384($p).$s) | Yes |
dynamic_76 | sha384($s.sha384($p)) | Yes |
dynamic_77 | sha384(sha384($s).sha384($p)) | Yes |
dynamic_78 | sha384(sha384($p).sha384($p)) | No |
dynamic_80 | sha512($p) | No |
dynamic_81 | sha512($s.$p) | Yes |
dynamic_82 | sha512($p.$s) | Yes |
dynamic_83 | sha512(sha512($p)) | No |
dynamic_84 | sha512(sha512_raw($p)) | No |
dynamic_85 | sha512(sha512($p).$s) | Yes |
dynamic_86 | sha512($s.sha512($p)) | Yes |
dynamic_87 | sha512(sha512($s).sha512($p)) | Yes |
dynamic_88 | sha512(sha512($p).sha512($p)) | No |
dynamic_90 | GOST($p) | No |
dynamic_91 | GOST($s.$p) | Yes |
dynamic_92 | GOST($p.$s) | Yes |
dynamic_93 | GOST(GOST($p)) | No |
dynamic_94 | GOST(GOST_raw($p)) | No |
dynamic_95 | GOST(GOST($p).$s) | Yes |
dynamic_96 | GOST($s.GOST($p)) | Yes |
dynamic_97 | GOST(GOST($s).GOST($p)) | Yes |
dynamic_98 | GOST(GOST($p).GOST($p)) | No |
dynamic_100 | WHIRLPOOL($p) | No |
dynamic_101 | WHIRLPOOL($s.$p) | Yes |
dynamic_102 | WHIRLPOOL($p.$s) | Yes |
dynamic_103 | WHIRLPOOL(WHIRLPOOL($p)) | No |
dynamic_104 | WHIRLPOOL(WHIRLPOOL_raw($p)) | No |
dynamic_105 | WHIRLPOOL(WHIRLPOOL($p).$s) | Yes |
dynamic_106 | WHIRLPOOL($s.WHIRLPOOL($p)) | Yes |
dynamic_107 | WHIRLPOOL(WHIRLPOOL($s).WHIRLPOOL($p)) | Yes |
dynamic_108 | WHIRLPOOL(WHIRLPOOL($p).WHIRLPOOL($p)) | No |
dynamic_110 | Tiger($p) | No |
dynamic_111 | Tiger($s.$p) | Yes |
dynamic_112 | Tiger($p.$s) | Yes |
dynamic_113 | Tiger(Tiger($p)) | No |
dynamic_114 | Tiger(Tiger_raw($p)) | No |
dynamic_115 | Tiger(Tiger($p).$s) | Yes |
dynamic_116 | Tiger($s.Tiger($p)) | Yes |
dynamic_117 | Tiger(Tiger($s).Tiger($p)) | Yes |
dynamic_118 | Tiger(Tiger($p).Tiger($p)) | No |
dynamic_120 | RIPEMD128($p) | No |
dynamic_121 | RIPEMD128($s.$p) | Yes |
dynamic_122 | RIPEMD128($p.$s) | Yes |
dynamic_123 | RIPEMD128(RIPEMD128($p)) | No |
dynamic_124 | RIPEMD128(RIPEMD128_raw($p)) | No |
dynamic_125 | RIPEMD128(RIPEMD128($p).$s) | Yes |
dynamic_126 | RIPEMD128($s.RIPEMD128($p)) | Yes |
dynamic_127 | RIPEMD128(RIPEMD128($s).RIPEMD128($p)) | Yes |
dynamic_128 | RIPEMD128(RIPEMD128($p).RIPEMD128($p)) | No |
dynamic_130 | RIPEMD160($p) | No |
dynamic_131 | RIPEMD160($s.$p) | Yes |
dynamic_132 | RIPEMD160($p.$s) | Yes |
dynamic_133 | RIPEMD160(RIPEMD160($p)) | No |
dynamic_134 | RIPEMD160(RIPEMD160_raw($p)) | No |
dynamic_135 | RIPEMD160(RIPEMD160($p).$s) | Yes |
dynamic_136 | RIPEMD160($s.RIPEMD160($p)) | Yes |
dynamic_137 | RIPEMD160(RIPEMD160($s).RIPEMD160($p)) | Yes |
dynamic_138 | RIPEMD160(RIPEMD160($p).RIPEMD160($p)) | No |
dynamic_140 | RIPEMD256($p) | No |
dynamic_141 | RIPEMD256($s.$p) | Yes |
dynamic_142 | RIPEMD256($p.$s) | Yes |
dynamic_143 | RIPEMD256(RIPEMD256($p)) | No |
dynamic_144 | RIPEMD256(RIPEMD256_raw($p)) | No |
dynamic_145 | RIPEMD256(RIPEMD256($p).$s) | Yes |
dynamic_146 | RIPEMD256($s.RIPEMD256($p)) | Yes |
dynamic_147 | RIPEMD256(RIPEMD256($s).RIPEMD256($p)) | Yes |
dynamic_148 | RIPEMD256(RIPEMD256($p).RIPEMD256($p)) | No |
dynamic_150 | RIPEMD320($p) | No |
dynamic_151 | RIPEMD320($s.$p) | Yes |
dynamic_152 | RIPEMD320($p.$s) | Yes |
dynamic_153 | RIPEMD320(RIPEMD320($p)) | No |
dynamic_154 | RIPEMD320(RIPEMD320_raw($p)) | No |
dynamic_155 | RIPEMD320(RIPEMD320($p).$s) | Yes |
dynamic_156 | RIPEMD320($s.RIPEMD320($p)) | Yes |
dynamic_157 | RIPEMD320(RIPEMD320($s).RIPEMD320($p)) | Yes |
dynamic_158 | RIPEMD320(RIPEMD320($p).RIPEMD320($p)) | No |
........ | RESERVED | UNK |
dynamic_999 | RESERVED | UNK |
The 'samples' stored in dynamic.conf (to be used as is, or as examples) are:
dynamic_1001 md5(md5(md5(md5($p))))
dynamic_1002 md5(md5(md5(md5(md5($p)))))
dynamic_1003 md5(md5($p).md5($p))
dynamic_1004 md5(md5(md5(md5(md5(md5($p))))))
dynamic_1005 md5(md5(md5(md5(md5(md5(md5($p)))))))
dynamic_1006 md5(md5(md5(md5(md5(md5(md5(md5($p))))))))
dynamic_1007 md5(md5($p).$s) (vBulletin)
dynamic_1008 md5($p.$s) (joomla)
# and many other newer items, added from user requests.
dynamic_1010 md5($p null_padded_to_len_100) RAdmin v2.x MD5
dynamic_1011 md5($p.md5($s)) (webEdition CMS)
dynamic_1012 md5($p.md5($s)) (webEdition CMS) (much faster)
dynamic_1013 md5($p.PMD5(username)) (webEdition CMS) (fast speed, but user name is stored in md5 hash format)
dynamic_1014 md5($p.$s) (long salt)
dynamic_1015 md5(md5($p.$u).$s)
dynamic_1018 md5(sha1(sha1($pass)))
dynamic_1019 md5(sha1(sha1(md5($pass))))
dynamic_1020 md5(sha1(md5($pass)))
dynamic_1021 md5(sha1(md5(sha1($pass))))
dynamic_1022 md5(sha1(md5(sha1(md5($pass)))))
dynamic_1023 sha1($pass) (hash truncated to length 32)
dynamic_1024 sha1(md5($pass)) (hash truncated to length 32)
dynamic_1025 sha1(md5(md5($pass))) (hash truncated to length 32)
dynamic_1026 sha1(sha1($pass))) (hash truncated to length 32)
dynamic_1027 sha1(sha1(sha1($pass)))) (hash truncated to length 32)
dynamic_1028 sha1(sha1_raw($pass)) (hash truncated to length 32)
dynamic_1029 sha256($pass) (hash truncated to length 32)
dynamic_1030 Whirlpool($pass) (hash truncated to length 32)
dynamic_1031 GOST($pass) (hash truncated to length 32)
dynamic_1300 md5(md5_raw($pass))
dynamic_1350 md5(md5($s.$p):$s)
NOTE the documentation section of dynamic.conf is listed here. It shows
how to setup dynamiceric functions (above 1000). All of the primitives
are defined, the data structures are defined, the expression, flags,
saltlen, etc. Following the 'howto use' section, are some working
examples (this whole list is also found in dynamic.conf).
####################################################################
####################################################################
# here are some examples of DYNAMIC formats
####################################################################
####################################################################
####################################################################
# Documenation of how to 'setup' DYNAMIC formats
####################################################################
#
# Variables / workspaces:
#
# keys[] - Array Used to stored keys (optionally used, we 'may' be able to use input field 1 array)
# input1[] - Array used for encryption, key appending, salt appending, etc happens to/from these
# NOTE if DynamicFunc__InitialLoadKeysToInput then this is used to store the keys
# and MUST NOT be damaged, since any later key retrieval will come from this buffer.
# This is done as an optimization. Thus input2 is required for additional scratch buffer work.
# output1[] - Array encryption happens and output is put here.
# NOTE final result MUST be put here. This is what the 'hash' array is checked against.
# salt - the salt is put here
# salt2 - 2nd salt ($$2)
# input2[] - Array same as input 1, but a totally different array
# output2[] - Array same as output 2, but totally different array (can not be used as 'final' result)
# userid - User name (fld1). Can be done normal, upper or lower case
# fld0 to fld9 - data from fld1 to fld9 of the input file.
#
# NOTE within the scratch work spaces (input1[] and input2[] arrays), we can only do things like append_keys
# append_salt or other things. Thus, each work space keeps track of each array element (knowing its contents),
# and keeps track of the length. In the way the scripting works, we can clear them (sets lengths of all
# elements to 0, and 'might' clear out the actual memory). We can append to them (keys, output conversions,
# salt, etc) or we can force set their length to 32 ('special' optimization used in conjunction with
# DynamicFunc__InitialLoadKeys_md5crypt_ToOutput2_Base16_to_Input1).
#
# NOTE there is NO length validation done, other than input keys are reduced to the max allowable length.
# Thus, if building, and you attempt something like: clear_keys append_keys append_keys append_keys append_keys
# append_keys append_keys and the keys are too long, then they will overflow. The maximal sizes of the
# input arrays are 95 bytes for x86 and 54 bytes for SSE/MMX. Above this will simply give invalid results
# (garbage in, garbage out).
#
#####################################################################################
#
# Flags= values. These flags are 'special' loader flags. They are optional. If used,
# then only ONE of them can be used.
#
#################
#
# Special input flags (all flags listed later). They have certain 'side-effects', and some have special
# rules that MUST be maintained within the script, and thus may not be usable for all scripts.
# These are here mostly for optimization. They do NOT have to be used. If not used, then when
# john adds keys one at a time, they are placed into the array of keys. Then, when loading keys
# the keys are copied from the keys array, into the input1 (2) as needed.
#
# MGF_KEYS_INPUT
# It will not use the keys[] array, but put the keys right
# into the input1[] array. This buffer must not be destroyed. john will NOT use the keys[]
# array, and later retrieval of the key will happen from here (if there are any hashes broken).
# For this to be able to be used.
# $pass must be at the START of the expression. expressions like md5($s.$p) would not work, since
# $pass is not the 'start' of the expression.
# the $pass expression 'may' have to be all by itself. Thus md5($p.$s) would not work (such as joomla)
# but md5(md5($p).$s) can be made to work.
# The input1[] array must NOT be touched (after it is loaded). Thus the below set of functions can NOT
# be used in the script.
# DynamicFunc__append_keys
# DynamicFunc__append_keys2
# DynamicFunc__clean_input
# DynamicFunc__append_salt
# DynamicFunc__append_from_last_output2_to_input1_as_base16
# DynamicFunc__overwrite_from_last_output2_to_input1_as_base16_no_size_fix
# DynamicFunc__append_from_last_output_as_base16
# DynamicFunc__overwrite_from_last_output_as_base16_no_size_fix
# DynamicFunc__append_2nd_salt DynamicFunc__append_userid
# DynamicFunc__append_2nd_salt
# DynamicFunc__set_input_len_32
# DynamicFunc__set_input_len_64
# DynamicFunc__overwrite_salt_to_input1_no_size_fix
# DynamicFunc__append_input_from_input2
# and the flag MGF_KEYS_UNICODE_B4_CRYPT
#
# MGF_KEYS_CRYPT_IN2
# This will load keys into the keys[] array. It will then perform a md5() and put the ouput
# into output2. This was done a signficant enhancement for forms like md5(md5($p).$s) so that we
# load ALL of the inner md5($p) only once, then re-used them over and over again for each new salt.
#
# MGF_KEYS_BASE16_IN1
# This is like the above flag, but it takes the extra step of storing the base16 conversion
# of the md5 into input1[] array. Due to this function, we have md5(md5($p).$s) actually working
# FASTER than simple md5($p) (if there are many salts). This is a significant optimization if it can
# be used properly.
# MGF_KEYS_BASE16_X86_IN1
# same as MGF_KEYS_BASE16_IN1, however, if running in SSE mode, the loader will switch to X86 mode,
# prior to outputting the base-16 back to input1. NOTE, the initial crypt IS done in SSE mode.
#
# MGF_KEYS_BASE16_IN1_Offset32
# This flag is a not valid for SSE2 (will build a 64 byte password, and 54 bytes is max SSE2 size)
# Psudo function that does the same work as DynamicFunc__InitialLoadKeys_md5crypt_ToOutput2_Base16_to_Input1
# however, it loaded the hext to offset 32 (instead of the 'start' of the buffer). When done, the
# input1[] buffers will have 64 byte passwords. The first 32 bytes are null, and the last
# 32 bytes are the hex values. This function is for md5(md5($s).md5($p)) (but certainly could
# be used for other formats.
# MGF_KEYS_BASE16_X86_IN1_Offset32
# Same as MGF_KEYS_BASE16_IN1_Offset32, but the output is in x86. NOTE, if running in SSE mode, then
# both MGF_KEYS_BASE16_IN1_Offset32 and MGF_KEYS_BASE16_X86_IN1_Offset32 perform exactly the same. Neither
# one of them 'work' in SSE mode, since we will end up with a 64 byte input string (not SSE valid).
#
# MGF_KEYS_UNICODE_B4_CRYPT
# Switch into 'unicode' converstion mode, prior to doing the 'early' MGF_KEYS* flags. The flags which
# can be used with this are: MGF_KEYS_CRYPT_IN2, MGF_KEYS_BASE16_IN1, MGF_KEYS_BASE16_X86_IN1,
# MGF_KEYS_BASE16_IN1_Offset32 (and the x86 versions). Note, that MGF_KEYS_INPUT can NOT be used
# with this flag.
#
# MGF_phpassSetup
# Special flag used to link the salt, set_salt and set_hash members of the format object to the 'special'
# functions for phpass encryption.
#
# MGF_POSetup
# Special flag used for the special "Post Office" Crypt function.
#
# Depricated 'pseudo' functions (must be first function). These functions still work, but have been depricated.
# dynamic simply 'transforms' them into the current flag, at script loading time. It is best to NOT use
# these functions in any new scripts, and to remove any usage of them. Since these are depricated, they have
# KEPT the already depricated MD5GenBaseFunc__ 'signatures', and have not been 'updated' to the new 'dynamic'
# format signature. These SHOULD NOT be used.
# MD5GenBaseFunc__phpassSetup == MGF_phpassSetup
# MD5GenBaseFunc__InitialLoadKeysToInput == MGF_KEYS_INPUT
# MD5GenBaseFunc__InitialLoadKeys_md5crypt_ToOutput2 == MGF_KEYS_CRYPT_IN2
# MD5GenBaseFunc__InitialLoadKeys_md5crypt_ToOutput2_Base16_to_Input1 == MGF_KEYS_BASE16_IN1
# MD5GenBaseFunc__InitialLoadKeys_md5crypt_ToOutput2_Base16_to_Input1_offset32 == MGF_KEYS_BASE16_IN1_Offset32
#
####################################################################
#
# Flag= line(s) Optional, but required IF the format needs them.
# Multiple flags ARE allowed.
#
#################
#
# Flags are just that, switches that tell the dynamic parser that
# certain things need to be handled. One common used flag is MGF_SALTED
# If the format is a salted hash, then this flag must be present.
# Here is the list of flags, and what they mean, and when you should
# use them
#
# Flag=MGF_SALTED
# Use this for any salted format
#
# Flag=MGF_SALTED2
# If there are 2 salts in the format, use this flag. NOTE 2 salts
# is defined, but has not be implemented yet in john.
#
# Flag=MGF_ColonNOTValid
# If there is some reason why the : char should not be used by john
# (such as the : is a valid character in the salt. If this is
# set, then the character to be used should be put into the Test=
# lines, AND the user should use that on the command line
#
# Flag=MGF_NOTSSE2Safe
# The max encryption the SSE2 code can handle is 54 bytes. The max
# size encryption for the 'generic' is 125 bytes. So, if it is
# OBVIOUS that sse2 can not be used, due to encryption lengths,
# then set this flag. An example is md5(md5($p).md5($s)) In this
# case, will be 3 md5's. 2 of them will be over the salt, and
# one over the password. Thus, if the password and salt are each
# under 54 bytes, then sse2 could be used. HOWEVER, the 3rd md5
# (the final one), is done against the concatenation of 2 32 byte
# strings (the md5 results of the first 2 encryptions). THUS we
# KNOW this is a 64 byte string. That will not work in the current
# SSE2 (or mmx) code, and thus, the SSE2/MMX builds can NOT be used
# to test that format.
#
# Flag=MGF_FLAT_BUFFERS
# This is similar to MGF_NOTSSE2Safe in 'some' ways. It will cause
# dynamic to only use the flat buffers. However, it is used for
# large formats which HAVE SSE2 code. These formats will use the
# the data from the flat buffers directly (even nulling them out
# and placing the # of bits into the right locations, and the 0x80
# trailing byte also). So this tells dyna to store the data and
# intermediate flat, but use the special SSE2 code for this format
# that loads from flat. Currently, all formats which has SIMD code
# have flat buffer behavior. NOTE most (all except md5/md4 and some
# for sha1), ONLY have the flat buffer code. These other 3 formats
# do have custom 'mixed' coding.
# One really nice thing about doing SIMD this way is the single limb
# limit has been removed. The SIMD code is currently in MD4/5, SHA1,
# and 32 bit SHA2 (SHA224/SHA256). The SIMD code has not been done
# for the flat SHA384/SHA512 code yet.
#
# Flag=MGF_INPBASE64
# If the hashes are in base-64 (such as phpass), then use this
# flag. Note, the base 64 'format' used is that of phpass. If there
# are other orderings, then this will not work. I know of no formats
# in use, other than phpass (phpbb, wordpress, etc) which use base-64
# for md5. This is actually the same format as CryptBS in base64conv
# utility. This has been improved now. It should work for any standard
# length hash (from 16 bytes up to 64 bytes). The only part of the
# hash that is base-64 decoded is within the binary hash value itself.
# dynamic does not handle base-64 decoding within any part of the salt.
#
# Flag=MGF_INPBASE64b
# This is like the MGF_INPBASE64 flag, BUT the encoding is in BE format
# crypt. This is the same as Crypt encoding in base64conv utility
#
# Flag=MGF_INPBASE64m
# This is like the MGF_INPBASE64 flag, BUT the encoding is in MIME.
# This is the same as MIME encoding in base64conv utility. NOTE, the
# hash can end with optional '=' place holding characters. These will
# be stripped off, in the prepare/split functions, to canonicalize the
# value of the hash to be NON-equal padded. But an input file can have
# the '=' padding or not (or even mixed) and still process properly.
#
# Flag=MGF_INPBASE64_4x6
# If this flag is set, then the input will be base-64, where 4 bytes are
# loaded 6 bits at a time (i.e. 16 bytes of hash). Used in Cisco PIX-MD5
# Thus, only the lowest 24 bits of each part of the MD5 hash are used.
# This has to happen on the binary loader and comparison functions.
#
# Flag=MGF_USERNAME
# If there is a Username used in the format, use this flag.
#
# Flag=MGF_USERNAME_UPCASE User name, but it is forced to uppercase
# Flag=MGF_USERNAME_LOCASE User name, but it is forced to lowercase
#
# Flag=MGF_SALT_AS_HEX
# This flag is for formats such as md5(md5($p).md5($s)) What this
# does, is to return the md5($s) to john as the salt, and not simply
# return the 'original' salt. Thus, we run md5's for the salt at
# initialization, and never MD5 them again. DO NOT use this for a
# format like md5($s.md5($p).md5($s)) In that format, you NEED
# the salt (along with the md5 of that salt). This flag can not
# be used in that instance.
#
# Flag=MGF_SALT_AS_HEX_TO_SALT2
# This is 'similar' to MGF_SALT_AS_HEX. It will perform the
# base16 crypt of the salt. However, it stores both the original
# salt, and creates a 'salt2' which is the base16 This is so a
# format like, md5($p.$s.md5($s)) could have both the salt
# and still have the base-16 of the salt. So in this case
# using append_salt would append the original salt, and
# append_2nd_salt would append the base-16 hash of the salt.
#
# Flag=MGF_StartInX86Mode
# This flag will case the format to 'start' in X86 mode, so that
# any initial key loading will also be done to the X86 buffers.
#
# Flag=MGF_SALT_UNICODE_B4_CRYPT
# This flag will case the format to 'start' in Unicode conversion
# mode, so that any initial key loading will also be done to the
# using unicode conversions.
#
# Flag=MGF_BASE_16_OUTPUT_UPCASE
# This flag will case the format to 'start' in uppercase base-16
# conversion mode, so that any initial key loading will also be
# done to the using unicode conversions.
#
# MGF_FLD0, MGF_FLD1, MGF_FLD2, ... ,MGF_FLD9
# If any of the fields of the file are part of the format (and
# used within the script), then they either must be part of
# the hash value, or the field must be present on the line.
# If a field IS used, then you also MUST have the proper
# flag set, or the prepare function will NOT load it.
#
# MGF_INPUT_20_BYTE
# Tell $dynamic$ that the 'final' crypt is an SHA1 (still experimental
# code, so 'caveat emptor' ). What this will do, is cause john to only load
# hashes that are 20 binary bytes of input (40 hex digits md5 is 32 hex
# digits). NOTE, when the 'final' crypt is done (in SHA1), it will only
# have the first 16 bytes compared against (vs the full 20 bytes which
# sha1 generates). This 'should' be more than adequate to know
# you have cracked the hash.
# MGF_INPUT_24_BYTE
# MGF_INPUT_28_BYTE
# MGF_INPUT_32_BYTE
# MGF_INPUT_40_BYTE
# MGF_INPUT_48_BYTE
# MGF_INPUT_64_BYTE
# These are similar to the 20 byte flag for the SHA1. NOTE, this
# means that dynamic will only look for valid input strings which
# are the appropriate length, based upon that final hash size.
# One off these flags MUST be used, on a format that is longer than
# the 16 byte MD5 (or md4) hash.
#
# MGF_INPBASE64a
# The binary input hash data format of the FreeBSD_MD5 and Apache_MD5.
#
# MGF_UTF8
# This format 'allows' the --encoding=utf-8 switch, and will perform
# full UTF conversions, if the DynamicFunc__setmode_unicode()
# function has been issued (or one of the user name or preload
# password unicode flags were used).
#
#
########################################################
#
# Function primitives, and what they do (REQUIRED in each format section)
#
#################
# DynamicFunc__clean_input
# Sets lengths of all input1[] array to ZERO, and sets the memory null (memory only set in SSE2, since it does
# not matter in x86 builds)
#
# DynamicFunc__clean_input2
# Same as DynamicFunc__clean_input but this one works on input2[] array.
#
# DynamicFunc__clean_input_kwik
# Sets lengths of all input1[] array to ZERO. Memory not cleared. Optimization that can be used when you KNOW
# that the length of any of the input1 strings will never be less than they once were. So if you load keys,
# crypt, clean_input, then repeatedly append_base16 to input and crypt, then during that repeated set of work
# you can call clean_kwik since ALL things being crypted, would be 32 bytes, and the single 'deep' clean would
# get the buffers read to go, and they would not need fully cleaning again.
#
# DynamicFunc__clean_input2_kwik
# Same as DynamicFunc__clean_input_kwik but this one works on input2[] array.
#
# DynamicFunc__clean_input_full
# This makes sure that the entire keys are set with NULL's prior to running. This is a full 'deep' clean.
# In x86 builds, it will fully null out the entire input buffer. In SSE mode, it nulls out both the
# x86 and SSE input buffers (fully).
#
# DynamicFunc__clean_input2_full
# Same as DynamicFunc__clean_input_kwik but this one works on input2[] array.
#
# DynamicFunc__append_keys
# append the array of keys to the array input1[]
#
# DynamicFunc__append_keys_pad16
# append the array of keys to the array input1[], padding with nulls to 16 bytes, if input shorter.
# Needed for net-md5 and net-sha1 formats.
#
# DynamicFunc__append_keys2
# append the array of keys to the array input2[]
#
# DynamicFunc__append_salt
# Appends the salt to each element of input1[], and adjusts the length of each element.
# NOTE, the MGF_SALT flag must be used in the format.
#
# DynamicFunc__append_salt2
# Appends the salt to each element of input2[], and adjusts the length of each element.
#
# DynamicFunc__append_2nd_salt
# append the salt2 (second salt value) to the array input1[]
# NOTE, the MGF_SALT2 flag must be used in the format.
#
# DynamicFunc__append_2nd_salt2
# append the salt2 to the array input2[]
#
# DynamicFunc__append_userid
# DynamicFunc__append_userid2
# appends the username into either input1 or input2 fields.
#
# DynamicFunc__crypt_md5
# performs a md5 on all elements of input1[] and places the results into output1[] The output will be the
# 16 byte BINARY blob of the 'raw' md5.
#
# DynamicFunc__crypt_md4
# same as DynamicFunc__crypt_md5, but uses the MD4 hash instead of md5.
#
# DynamicFunc__crypt2_md5
# Same as DynamicFunc__crypt_md5 but this one works on input2[] -> output2[] arrays.
#
# DynamicFunc__crypt2_md4
# Same as DynamicFunc__crypt2_md4 but uses the MD4 hash instead of md5.
#
# DynamicFunc__crypt_md5_in1_to_out2
# Takes the data from input1, performs the MD5 crypts, and stores this data into Output2
#
# DynamicFunc__crypt_md4_in1_to_out2
# Takes the data from input1, performs the MD4 crypts, and stores this data into Output2
#
# DynamicFunc__crypt_md5_in2_to_out1
# Takes the data from input2, performs the MD5 crypts, and stores this data into Output1
#
# DynamicFunc__crypt_md4_in2_to_out1
# Takes the data from input2, performs the MD4 crypts, and stores this data into Output1
#
# DynamicFunc__append_from_last_output_as_base16
# Takes the 16 byte binary values from each output1[] array, and does a base-16 conversion, appending the
# results to the same 'index' of the input1[] array. ALL of the lengths of the array1[] elements will be
# 32 bytes more than they were (the base-16 of each 16 byte binary value is 32 bytes long).
#
# DynamicFunc__append_from_last_output2_as_base16
# Same as DynamicFunc__append_from_last_output_as_base16 but this one works on output2[] -> input2[] arrays.
#
# DynamicFunc__append_from_last_output_to_input2_as_base16
# output1[] append -> input2[] arrays. (note, output #1 appending to input #2, base-16)
#
# DynamicFunc__append_from_last_output2_to_input1_as_base16
# output2[] append -> input1[] arrays. (note, output #2 appending to input #1, base-16)
#
# DynamicFunc__append_input_from_input2
# Appends input2 to input input += input2. Note, the inputX -> inputY copying in SSE2 is slower than
# doing output -> input.
#
# DynamicFunc__append_input2_from_input
# Appends input1 to input2 input2 += input
#
# DynamicFunc__append_input_from_input
# Appends input1 to input1 input1 += input2
#
# DynamicFunc__append_input2_from_input2
# Appends input2 to input2 input2 += input2
#
# DynamicFunc__append_from_last_output2_as_raw
# Appends the 'raw' output data from output2 to input1. Length of input1 grows by 16 bytes.
#
# DynamicFunc__overwrite_from_last_output_as_base16_no_size_fix
# NOT IMPLEMENTED:
# Takes the 16 byte binary values from the output1[] array, and overwrites from byte 0 to byte 31 of each
# element of the input1[] array. This is used as an optimizations for formats such as: md5(md5($s).$p)
# in this format, we can place the keys into input1[] at 32 bytes past the start of the buffer, and set
# the lengths to be the length of each key + 32, and then simply call this function for each salt, to
# drop the 32 bytes of md5 data to the start of the strings, without touching the passwords that were
# already stored, or the lengths of the strings.
#
# DynamicFunc__overwrite_from_last_output2_as_base16_no_size_fix
# NOT IMPLEMENTED:
# Same as DynamicFunc__overwrite_from_last_output_as_base16_no_size_fix but this one works on output2[] -> input2[] arrays.
#
# DynamicFunc__overwrite_from_last_output_to_input2_as_base16_no_size_fix
# NOT IMPLEMENTED:
# output1[] overwrite start of input2[] arrays. (note, output #1 going to start of input #2, base-16, no size 'fix')
# like DynamicFunc__overwrite_from_last_output_as_base16_no_size_fix but different input output vars.
#
# DynamicFunc__overwrite_from_last_output2_to_input1_as_base16_no_size_fix
# NOT IMPLEMENTED:
# output2[] overwrite start of input1[] arrays. (note, output #2 going to start of input #1, base-16, no size 'fix')
# like DynamicFunc__overwrite_from_last_output_as_base16_no_size_fix but different input output vars.
#
# DynamicFunc__overwrite_salt_to_input1_no_size_fix
# Inserts the salt to the start of the first input buffer. DOES NOT append null bytes, nor does it
# adjust the length of the strings. Used if the 'top' part of input buffer 1 stays constant, and
# the salt gets inserted to the start of input buffer (but lengths never change).
#
# DynamicFunc__overwrite_salt_to_input2_no_size_fix
# Same as DynamicFunc__overwrite_salt_to_input1_no_size_fix but this one works on salt -> input2[] arrays.
#
# DynamicFunc__append2_from_last_output2_as_raw
# NOT IMPLEMENTED
# DynamicFunc__append_from_last_output1_as_raw
# NOT IMPLEMENTED
# DynamicFunc__append2_from_last_output1_as_raw
# NOT IMPLEMENTED
#
# DynamicFunc__set_input_len_16
# Sets the length of each element of input1[] to 16. In SSE2 mode, if the length of the input buffer
# was less than 16, then that 0x80 end of marker is removed, and a new one is 'added' at offset 16.
#
# DynamicFunc__set_input_len_20
# Sets the length of each element of input1[] to 20. In SSE2 mode, if the length of the input buffer
# was less than 20, then that 0x80 end of marker is removed, and a new one is 'added' at offset 20.
#
# DynamicFunc__set_input2_len_16
# Sets the length of each element of input2[] to 16.
#
# DynamicFunc__set_input2_len_20
# Sets the length of each element of input2[] to 20.
#
# DynamicFunc__set_input_len_32
# Sets the length of each element of input1[] to 32. This was designed as is used in conjunction with
# the funtion overwrite_from_last_output_as_base16_no_size_fix in mind, but would not
# be the 'only' reason to use it (but is the only reason I have at this time). This function does NOT
# clean the input[] items prior to this. Usually a call to clean_input would be required prior to
# calling this function, to make sure the buffer is 'clean'. A 0x80 is placed into offset 32
#
# DynamicFunc__set_input2_len_32
# Same as DynamicFunc__set_input_len_32 but this one works on input2[] array.
#
# DynamicFunc__set_input_len_40
# Sets the length of each element of input1[] to 30. A 0x80 is placed into offset 40. This would be
# the companion function to DynamicFunc__set_input_len_32, but useful for SHA1 hashes which would
# themselves output 40 bytes of hex.
#
# DynamicFunc__set_input2_len_40
# Same as DynamicFunc__set_input_len_40 but this one works on input2[] array.
#
# DynamicFunc__set_input_len_64
# Like the above function, but sets lengths to 64 bytes. NOTE valid to use in SSE2 mode.
#
# DynamicFunc__set_input2_len_64
# Same as DynamicFunc__set_input2_len_64 but this one works on input2[] array.
#
# DynamicFunc__set_input_len_100
# Like the above function, but sets lengths to 100 bytes. NOTE valid to use in SSE2 mode.
# This is a 'specialized' function for the RAdmin hash, and simply nulls out the buffer
# up to 100 bytes.
#
# SSE 'switching' functions. SSE is only valid for 54 byte or less input strings.
# This is due to optimizations which place a 'single' md5 limb restriction on the
# crypts. Thus, for some formats, we have to be in x86 mode only, but for others,
# we can jump in and out of SSE mode. However, to do this, we likely will have
# to convert a buffer (or more). The input buffers, and output buffers are NOT
# compatible between x86 and SSE2. If possible, convert the output buffers, they
# are smaller, and faster (usually).
#
# NOTE, proper usage of these functions CAN improve performance of some SHA1 processing
# putting the data into or out of 'flat' model. The SHA1 hash does have SSE code, however
# since it also requires BE layout for the data (vs LE for md5), a design choice was made
# to not store the BE sse buffers long term. All crypting will determin IF sse sha1 code
# should be used, and if so, the crypt function will convert from flat into sse format.
# however, if the data already is in sse format, it has to be transformed into a format
# valid for ShA1. Look at formats 1022 to 1031 for insite on how to best use these
# data conversion functions with SHA1.
#
# DynamicFunc__SSEtoX86_switch_input1
# Copies the SSE Input1 buffer to x86 Input1. Changes 'mode' to non-SSE for any
# functions that are done after this call.
# DynamicFunc__SSEtoX86_switch_input2
# Copies the SSE Input2 buffer to x86 Input2. and changes to non-SSE mode.
# DynamicFunc__SSEtoX86_switch_output1
# Copies the SSE Output1 buffer to x86 Output1. and changes to non-SSE mode.
# DynamicFunc__SSEtoX86_switch_output2
# Copies the SSE Output2 buffer to x86 Output2. and changes to non-SSE mode.
#
# DynamicFunc__X86toSSE_switch_input1
# Copies the x86 Input1 buffer to SSE Input1. Changes 'mode' to SSE for any
# functions that are done after this call.
# DynamicFunc__X86toSSE_switch_input2
# Copies the x86 Input2 buffer to SSE Input2. and changes to SSE mode.
# DynamicFunc__X86toSSE_switch_output1
# Copies the x86 Output1 buffer to SSE Output1. and changes to SSE mode.
# DynamicFunc__X86toSSE_switch_output2
# Copies the x86 Output2 buffer to SSE Output2. and changes to SSE mode.
#
# DynamicFunc__ToSSE
# Simply switches mode to SSE. No data buffers copied. Usually, used as first
# or last command in a script
# DynamicFunc__ToX86
# Simply switches mode to x86. No data buffers copied. Usually, used as first
# or last command in a script
#
#
# Unicode mode. This allows $dynamic$ to do unicode coversion when doing string
# append (overwrite) operations. Thus, a format such as md5(unicode($p).$s) can
# be generated.
#
# DynamicFunc__setmode_unicode
# All string ops do Unicode conversions. These are DynamicFunc__append_keys,
# append_keys2, append_salt, append_salt2, overwrite_salt_to_input1_no_size_fix,
# overwrite_salt_to_input2_no_size_fix, append_2nd_salt, append_2nd_salt2,
# append_userid, append_userid2, append_input1_from_CONST1 (and ALL other const
# append functions) If --encoding=utf-8 switch is set, then a utf-8 to unicode
# conversion is done. If that switch was not used on the command line, then a
# simple ascii to unicode (which is simply appending a null byte after each byte
# of string). The --encoding=utf-8 conversion is considerably slower, but is required
# for many Unicode or UTF-8 systems. NOTE, to honor the --encoding=utf-8 switch, the
# format MUST use the MGF_UTF8 flag.
#
# DynamicFunc__setmode_normal
# This is the 'normal' run for john. Back to ascii (or utf-8, if --encoding=utf-8
# command line switch was used). But there will be NO Unicode conversions done.
#
#
# Upper/Lowercase of md5 - base16 conversions. Normally, this is done to lower
# case. However, there may be systems which do md5 to base 16 in upper case.
# thus, if a hash is md5(upper(md5($p)) this is different than md5(md5($p))
# These functions turn on or off the upper/lower case conversions.
#
# DynamicFunc__base16_convert_locase
# This is the 'normal' lowercase. Thus, md5(md5($p)) is assumed to have the
# base-16 done in lower case.
#
# DynamicFunc__base16_convert_upcase
# Perform base-16 converts in upper case base-16.
#
# DynamicFunc__append_input1_from_CONST1
# This will append the first constant value to the input1[] array
# DynamicFunc__append_input1_from_CONST2
# DynamicFunc__append_input1_from_CONST3
# DynamicFunc__append_input1_from_CONST4
# DynamicFunc__append_input1_from_CONST5
# DynamicFunc__append_input1_from_CONST6
# DynamicFunc__append_input1_from_CONST7
# DynamicFunc__append_input1_from_CONST8
# Same as DynamicFunc__append_input1_from_CONST1 but they load the other constant
# values into input1.
#
# DynamicFunc__append_input2_from_CONST1
# This loads the first constant value into the input2[] array
# DynamicFunc__append_input2_from_CONST2
# DynamicFunc__append_input2_from_CONST3
# DynamicFunc__append_input2_from_CONST4
# DynamicFunc__append_input2_from_CONST5
# DynamicFunc__append_input2_from_CONST6
# DynamicFunc__append_input2_from_CONST7
# DynamicFunc__append_input2_from_CONST8
# Same as DynamicFunc__append_input2_from_CONST1 but they load the other constant
# values into input2.
#
# DynamicFunc__append_fld0
# This will append the data from $$F0 (field 0 of the line, or 'username', to input 1.
# DynamicFunc__append_fld1
# DynamicFunc__append_fld2
# ....
# DynamicFunc__append_fld9
# Will append data from the other fields (from 1 to 9). NOTE, 1 is the 'hash' line, and
# almost certainly should NOT be used.
#
# DynamicFunc__append2_fld0 -- to -- DynamicFunc__append2_fld9
# Loads data from $$F0 to $$F9 (field 0 to field 9) into input buffer 2.
#
# DynamicFunc__SHA1_crypt_input1_append_input2_base16 **
# DynamicFunc__SHA1_crypt_input2_append_input1_base16 **
# DynamicFunc__SHA1_crypt_input1_overwrite_input1_base16 **
# DynamicFunc__SHA1_crypt_input2_overwrite_input2_base16 **
# DynamicFunc__SHA1_crypt_input1_overwrite_input2_base16 **
# DynamicFunc__SHA1_crypt_input2_overwrite_input1_base16 **
# DynamicFunc__SHA1_crypt_input1_to_output1_FINAL
# DynamicFunc__SHA1_crypt_input2_to_output1_FINAL
# Currently 'experimental' addition of SHA1 into the md5() syntax. Still much work to
# do. Not for general use (yet). Hopefully, will be able to get things like
# md5(sha1(md5($p))) working (sort of works now, but again, still experimental).
# The 2 '_FINAL' functions should ONLY be used as the last call. This allows
# for support of sha1(sha1(m5($p).$s)) type hashes. NOTE, if you use on of the
# *_FINAL calls, then you have to use the MGF_INPUT_20_BYTE flag, and notes
# that only the first 16 bytes of the final hash are evaluated. Also, only 40 bytes
# long hex string hashes will be loaded (base-64? needed?).
# At this time, ALL sha1 is done in non-SSE code (x86, OpenSSL). Also note, that
# ALL output from the SHA1 functions is directly appended or overwritten, right into
# an input buffer.
#
# ** NOTE, these functions are depricated. They should not be used any more.
# The proper usage would be to set the output format (no setting is needed
# IF base-16 is wanted, as that will be default), and then to call the same
# named function primate, but that function name is minus the _base16 part.
# so DynamicFunc__SHA1_crypt_input1_append_input2 would be the proper function,
# instead of the depricated DynamicFunc__SHA1_crypt_input1_append_input2_base16
#
####################
#
# OTHER large hash functions (SHA2 hashes, GOST, WHIRLPOOL, Tiger, RIPEMD(128/160/256/512) currently)
#
####################
#
# These other large hash types, have been built like the SHA1 (listed above). They will have
# the same 8 function primitives, and be named exactly the same as the SHA1, except they
# will have the crypt in the function name. The current hashes supported are:
# SHA224, SHA256, SHA384, SHA512, GOST, WHIRLPOOL.
# NOTE Whirlpool is ONLY supported in new versions of OpenSSL, so if the version of oSSL
# is not new enough, the whirlpool part of dynamic will NOT be compiled into JtR.
#
# Here is an example. Listed will be the functions for SHA256. NOTE all of the other types
# will be exactly the same, just using different crypt values in the function names.
#
# DynamicFunc__SHA256_crypt_input1_append_input2
# DynamicFunc__SHA256_crypt_input2_append_input1
# DynamicFunc__SHA256_crypt_input1_overwrite_input1
# DynamicFunc__SHA256_crypt_input2_overwrite_input2
# DynamicFunc__SHA256_crypt_input1_overwrite_input2
# DynamicFunc__SHA256_crypt_input2_overwrite_input1
# DynamicFunc__SHA256_crypt_input1_to_output1_FINAL
# DynamicFunc__SHA256_crypt_input2_to_output1_FINAL
#
# All of these 'large' hash functions, when used MUST end with either an MD5 or MD4 into
# output1, OR by using one of the *_to_output1_FINAL calls. The ONLY call actaully
# has to be one of the *_to_output1_FINAL calls (if the format is a simple single
# hash, such as SHA512($s.$p.$u) In this case, we would simply load one of the input
# variables with the salt, the password, and the userid, and then call a single
# DynamicFunc__SHA256_crypt_input1_to_output1_FINAL to perform the crypt.
#
####################
# Controlling the output of 'large' crypts.
####################
#
# All of the 'large' crypts, have simple function primitives. These will perform the
# crypt, and then write output to one of the 2 buffers. The output can be appeneded,
# or overwritten. The format this output is done in CAN be controlled. The output
# formats are: base-16 (0-9 and a-f), base-16 upcase (0-9 and A-F), base-64 (MIME)
# base-64 with no 'trailing' '=' characters (the '=' is normally inserted for strings
# that are not evenly divisible by 3). Also, 'RAW' hash value can be output.
#
# These are the 'helper' functions that affect large hash output. Every call to crypt_all
# will set base-16 to be the default output format. These helper functions change this,
# and once an output format it set, it 'stays' in that format, until set by another
# helper, or at the next call to crypt_all (i.e. the format starts over again)
#
# DynamicFunc__LargeHash_OUTMode_base16
# DynamicFunc__LargeHash_OUTMode_base16u
# DynamicFunc__LargeHash_OUTMode_base64
# DynamicFunc__LargeHash_OUTMode_base64_nte
# DynamicFunc__LargeHash_OUTMode_raw
#
####################
# These are special functions written SPECIFCALLY for usage by phpass code, in builtin
# function dynamic_17. These are likely NOT useful. However, they 'are' open to be used.
####################
#
# DynamicFunc__crypt_md5_to_input_raw
# Used as 'first' step of phpass crypt. it will put 16 binary bytes of md5 encryption
# into array1[]. It will write this to the beginning of the arrays (does not append), and
# when done, sets ALL lengths of array1[] to 16. Once this function is called, the keys