gmane.comp.security.openwall.john.user

Core 2 Duo benchmarks JtR 1.7.3.1

Dhirendra Singh Kholia — 2008-07-20T13:17:05

Hi, CONFIGURATION: John-1.7.3.1, Kernel 2.6.26, GCC 4.2.3 on Core 2 Duo 6750 < at >3.4GHz [32-bit] Benchmarking: BSDI DES (x725) [128/128 BS SSE2]... DONE Many salts:94515 c/s real, 94515 c/s virtual Only one salt:91673 c/s real, 92041 c/s virtual Benchmarking: FreeBSD MD5 [32/32]... DONE Raw:9370 c/s real, 9370 c/s virtual Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE Raw:574 c/s real, 574 c/s virtual Benchmarking: LM DES [128/128 BS SSE2]... DONE Raw:15534K c/s real, 15565K c/s virtual Regards, dsk PS: Is there any work going on in utilizing GPUs (using CUDA, CTM) in JtR for password cracking?

benchmarks on the wiki

Solar Designer — 2008-07-19T19:22:10

Hi, I've added many new benchmarks to the wiki, including the current winner entry and many non-x86 entries. Also, Erik contributed a curious entry - the very last one. http://openwall.info/wiki/john/benchmarks The fastest system in the table is currently based on a Q6700 CPU running a 64-bit Linux distribution. This one achieves an equivalent of just over 2.5 million of traditional DES-based crypt(3) checks per second per core, but since this CPU is quad-core, this translates to over 10 million of checks per second per CPU chip, with proper parallelization. The slowest is an iPod, which does around one thousand of traditional crypt(3)'s per second. If you have a system substantially different from those listed, please submit your results. Thanks, Alexander

JtR Pro 1.7.3+ for Linux and Mac OS X

Solar Designer — 2008-07-18T12:52:40

Hi, This is likely the last announcement posting for today, and maybe for this month. It is to announce availability of John the Ripper 1.7.3 Pro for Linux (stable release) and 1.7.3.1 Pro for Mac OS X (currently in public beta). The corresponding URLs are: http://www.openwall.com/john/pro/linux/ http://www.openwall.com/john/pro/macosx/ I've included more detail on each of these two versions below: 1. Besides the update to 1.7.3 (and thus including all of the improvements of that version in an extensively tested native package), new with John the Ripper 1.7.3 Pro for Linux is official support for Windows NTLM (MD4-based) and Mac OS X 10.4+ salted SHA-1 hashes. Also included for the first time is a pre-built RPM package for 64-bit capable systems, which makes use of 64-bit mode extended SSE2. This is a free upgrade for everyone who has purchased the product in the past (the new packages are found in the existing download directories). As usual, new copies/licenses may be purchased at: http://www.openwall.com/john/pro/linux/ I'd like to thank Alain Espinosa for the optimized NTLM code, and for kindly placing it in the public domain. This release of JtR Pro includes Alain's code with slight modifications, as well as replacement code for the password file loader; I am going to roll these into the next revision of the jumbo patch. 2. There's a beta version of John the Ripper Pro 1.7.3.1 for Mac OS X included with every new purchase, and free for everyone who has purchased the product in the past (it is found in the beta/ subdirectory in the existing download directories). As usual, new copies/licenses may be purchased at: http://www.openwall.com/john/pro/macosx/ Similarly to JtR Pro for Linux, besides the update to 1.7.3+, this version adds official support for Windows NTLM (MD4-based) and Mac OS X 10.4+ salted SHA-1 hashes, and it includes native support for 64-bit capable Intel CPUs on Mac OS X 10.5+ (Leopard) within the Universal binary, which makes use of 64-bit mode extended SSE2. Also included is the brand new XPWDUMP tool, which dumps password hashes from Mac OS X systems for subsequent auditing/cracking. As a bonus, the full source code is also provided (it was not provided with 1.7.2 Pro for Mac OS X, the focus of which was on packaging, but with so many exciting new features, we're also being generous and we do share the revised and enhanced source code this time, including several added source files). A "final" (non-beta) release of 1.7.3.1 Pro (or newer) for Mac OS X is coming soon. This will be a free upgrade for everyone who has purchased the product. I'd like to thank Jen Linkova aka Furry for her research into proper packaging for Mac OS X, and for XPWDUMP. Alexander Peslyak GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments

JtR 1.7.3.1

Solar Designer — 2008-07-18T12:08:40

Hi, This is to announce availability of John the Ripper 1.7.3.1, which is a "development" version, from the usual location: http://www.openwall.com/john/ John the Ripper 1.7.3 and 1.7.3.1 focus on better x86-64 support. Most notably, two Blowfish-based crypt(3) hashes may now be computed in parallel for much better performance on x86-64 CPUs (on Intel Core 2 and AMD CPUs tested, the speedup was 50% to 65%), and new make targets have been added for Mac OS X 10.5+ (Leopard) and recent versions of Solaris on 64-bit capable x86 processors, producing 64-bit builds that make use of the 64-bit mode extended SSE2 for DES-based hashes. Previously, such "fully native" builds were only supported on Linux and *BSDs. This addition has required making the assembly source files more portable, including conversion to instruction pointer relative addressing on x86-64 as it is required for Mac OS X and avoiding constructs not supported by Sun's assembler. Hopefully, this has not made things any worse for any other systems - and some testing has been done to confirm this, but further testing is desired. A number of other make targets have been added as well, including for 32-bit with SSE2 and 32-bit with MMX builds on Solaris (with Sun Studio C compiler or gcc), for Linux/IA64 (Itanium), and for building three-architecture Universal binaries with Xcode 3.0 on Mac OS X. I'd like to thank Anatoly Pugachev for his assistance with testing the Solaris builds. As a bonus, "DumbForce" and "KnownForce" external mode samples have been added to the default john.conf. DumbForce is a generic implementation of "dumb" exhaustive search, given a range of lengths and an arbitrary charset. The sample is pre-configured for trying 8-bit characters (except for known terminal controls) against LM hashes, but this can be changed easily. KnownForce is a generic implementation of exhaustive search for a partially-known password - arbitrary character sets or even fixed characters may be specified for each position separately. Wanted: native make target vs. "make generic" benchmarks on Itanium and on newer RISC processors (those capable of issuing more than 2 integer instructions per clock cycle), with gcc and with other compilers. Right now, the "dual Blowfish" code is only enabled for x86-64 (where it is known to work well) and IA64 (where it is expected to work well), but not for any other architectures (where at least some versions of gcc are known to produce poor code at least for some dual-issue RISC processors). Please post any follow-ups to this message to the john-users mailing list (be sure to join the list first if you're not on it already). I will post another message on JtR Pro updates. Thanks, Alexander Peslyak GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15 http://www.openwall.com - bringing security into open computing environments

cracking md5 passwords not working

ram — 2008-07-09T13:46:50

I have got john 1.7.2 installed with the raw-MD5 patch (Linux 64 bit ) My passwords are created using Digest::MD5::md5_base64() perl function (http://search.cpan.org/~gaas/Digest-MD5-2.36/MD5.pm ) But whenever I run john I get a error No password hashes loaded The document says the passwords must match "openssl md5" passwords , that doesnt work too ---------- echo help:$(echo -n help | openssl md5) > /tmp/weak ./john --format=raw-MD5 /tmp/weak No password hashes loaded ---------- How do I get john working Thanks Ram

Problems with Netscape LDAP SSHA [salted SHA1]

Markus Friedel — 2008-07-08T19:58:13

Hi, i am using John from http://btb.banquise.net/bin/myjohn.tgz and using passwords dumped from openldap. No the problem: some passwords were loaded but john did not start. there is no log entry at all. 2 samples where passwords were loaded but no computation starts: datkommadr:{SSHA}f4VgVNep4cz7Vy1BgPbmelC/N6+rYdWw7WGuLA== dabob:{SSHA}sa0QU3f7p7CPpMSA3st/N9Hjjlq1in7MiIbAWw== the commandline shows: me< at >algorithmix:~/john/run$ ./john --session=ldap ldap Loaded 2 password hashes with 2 different salts (Netscape LDAP SSHA [salted SHA1]) me< at >algorithmix:~/john/run$ i have tried these passwords on different computers with the same result. could someone reproduce this? best regards Markus Friedel

Password encryption question

John — 2008-06-30T11:01:50

Hello all, We would like to find out the password encryption/mangling routine for a legacy Windows app for which we would like to port the users to Linux. The application is VopMail (a mail server, now abandonware). We want to migrate all user accounts/passwords to Linux Postfix/Courier. We're a small ISP and these are all our customers for which we also keep FTP passwords etc. We could use a proxy and sniff POP3/IMAP sessions. Alternatively, we could inform all users that they have a new password which is less customer-friendly I believe. Ideal solution would be to find out the encryption or mangling routine. Below I have included a sample of some records I created where VopMail has created the Password1 and Password2 fields. It seems quite weak to me and there are clear patterns in the Password1/Password2 fields. Similar plaintexts generate similar encrypted passwords. However, this is how far I got :-) I am not asking for the final solution, just some pointers into the right direction so I can try to reverse engineer the existing passwords and migrate them to our new platform. Thanks a lot! Cheers, John # Account name, Plaintext, Password1, Password2 a0000000001,as,aeg=,0wca0 a0000000002,aaa,aWpq,0wca3vg== a0000000003,aaerially,b2pO4SFqD4+x,0wca3/mJtHm6Vig== a0000000004,aam,aWoG,0wca39g== a0000000005,aarogramme,aGrhlF/haoYFTg==,0wsW2jmcAYmOS3ao= a0000000006,aaron,aGrhlB4=,0wsW2jmcJ a0000000007,aaronic,aGrhlB4ieA==,0wsW2jmcJ+ts= a0000000008,aarp,bmrh8w==,0wsW2jvA= a0000000009,abacate,bnFq+GnXTg==,0wsWkodbRt/4= a0000000010,abacaxi,bnFq+Gm7Ig==,0wsWkodbRMzo= a0000000011,abacay,bnFq+Gmy,0wsWkodbRIw== a0000000012,abacinate,bnFq+CQdatdN,0wsWkodbZPDlZHg== a0000000013,abacination,bnFq+CQdatchFB0=,0wsWkodbZPDlZVqHN a0000000014,abacisci,bnFq+CPoeKI=,0wsWkodbZqYx/ a0000000015,abaciscus,bnFq+CToeN7r,0wsWkodbZqYz6zQ== a0000000016,abaciscuss,bnFq+CToeN7r6A==,0w8SnrsPMvuefqNo= a0000000017,abacli,bnFq+Awi,0w8SnrsONfg== a0000000018,abacot,bnFq+BfX,0w8SnrsOsyA== a0000000019,abaction,bnFq+NUiFB0=,0w8SnrsOVZgfs a0000000020,abaculi,bnFq+N0PIg==,0w8SnrsOUcXw= a0000000021,abaculus,bnFq+NsP3ug=,0w8SnrsOUcSRU a0000000022,abaculuss,bnFq+NsP3ujr,0w8SnrsOUcSRUYw== a0000000023,abada,bXFqx2k=,0w8SnrtXS a0000000024,abaddon,bXFqx0QUHQ==,0w8SnrtWTYgo= a0000000025,abadejo,bXFqx005FA==,0w8SnrtWScRw= a0000000026,abadengo,bXFqx0wdXJQ=,0xMOmr9aRdBHi a0000000027,abadia,bXFqxyFq,0xMOmr9bZqg== a0000000028,abaff,bHFq1VY=,0xMOmr9Sy a0000000029,abaisance,a3FqouxqHfhN,0xMOmr0J1BmYbXA== a0000000030,abaised,a3FqoutORw==,0xMOmr0J1AkI= a0000000031,abaiser,a3FqoutO4Q==,0xMOmr0J1AjI= a0000000032,abaisse,a3FqouvoTg==,0xMOmr0J1BUA= a0000000033,abaissed,a3Fqou/oTsc=,0xMOmr0J1BUAn : : :

patch for SAP-passwords (BCODE & PASSCODE)

sap friend — 2008-06-25T23:48:50

Hello everyone, finally, here's a patch for auditing SAP-passwords. There's one module for the old (BCODE or CODVN B) and one for the new (PASSCODE or CODVN G) SAP passwords which can be obtained from the table USR02 or USH02. This patch was tested on linux/x86 only and we're quite sure it won't work on any other architecture w/o modifications. Sorry for that ;-) But: feel free to adjust/port/modify the code! Hints about adjustments to be made are welcome :-) There's an issue with cases, too. Maybe Solar Designer can give a hint here... BTW: SD, if there was more documentation for the plugins, the quality would be far better... SAP password hashes are salted only with the username (the system-ID is NOT involved!). So a special preparation of the username-password-table is nesessary (see attached .pl-script). SAP allows special characters in usernames (e.g. * $ etc.). Whitespaces at the end of the username will be stripped. Due to the fact that the salt (remember: the username) varies in legth, we came up with the great idea to fix the salt-length to the max username legth (40, btw) and padd the rest w/ spaces, which will be stripped by the plugin. Ugly, but has proven to work :-) So basically, the format for our input-files looks like this (true for G and B): username$HASHCODE e.g. DDIC:DDIC $C94E2F7DD0178374 SPA*:SAP* $60A0F7E06D95BC9FB45F605BDF1F7B660E5D5D4E A small perl script is contributed as attachment of this posting. It parses the content of a tab separeted file (SAP calls those 'XLS files' - they contain the SAP table USR02 or USH02) and generates two output files: BCODE and PASSCODE which can be fed into john. If you have access to both password types (BCODE and G) you should start cracking the BCODE first 'cause it's a lot faster. Note that newer SAP-Systems (at least the ones we've seen) generate B and G! So let's talk about the algorithms... The BCODE (sapB) algorithm is pretty old and looks weak: - the length of passwords is maximum 8 chars - the password and username(=salt) are UPPER case - passwords and usernames lose entropy (non-ascii chars get replaced by 0xff) - at least, MD5 is applied twice (some magic in between), but - the result is OR'd, so we will have only 8 bytes The PASSCODE algorithm (sapG) is a bit more complex, but IDA and Olly were able to reveal it's inner working (with a little support of our brains): - the max. length of passwords is 48 - some pseudo-codepage-translation for passwords (>7bit ascii) is applied - only the username(=salt) is always UPPERcase - the hash is generated with two times SHA1 and some magic between both runs. Feel free to check the details and comments in the patch. The patch itself is public domain. The patch is generated according to the infos from the wiki, so there should be no trouble patching. (please note: the patch contains the raw-MD5 and raw-SHA1 patch, too). $ wget http://www.openwall.com/john/f/john-1.7.2.tar.gz $ tar xfz john-1.7.2.tar.gz $ cd john-1.7.2/ $ patch -p1 <../john-1.7.2-SAPLover-1.diff $ cd src $ make linux-x86-mmx $ cd ../run $ ./john --test --format=sapB Benchmarking: SAP BCODE [sapb]... DONE Raw: 815536 c/s real, 815536 c/s virtual $ ./john --test --format=sapG Benchmarking: SAP CODVN G (PASSCODE) [sapg]... DONE Many salts: 643218 c/s real, 643218 c/s virtual Only one salt: 626108 c/s real, 626108 c/s virtual cheers, sap loverz

Mac OS X 10.5.3 Leopard password hashes

55 89 e5 — 2008-06-24T03:57:56

I recently set up a user account on my Mac OS X 10.5.3 Leopard machine with a password of "apple" and the corresponding has in a file in /var/db/shadow/hash is: 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000001295B67659E95F32931CEDB3BA50289E2826AF3D5A1422F000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000 It appears to me that the salted SHA-1 hash is: 1295B67659E95F32931CEDB3BA50289E2826AF3D5A1422F I create a file with the following contents: username:1295B67659E95F32931CEDB3BA50289E2826AF3D5A1422F::::::: and when I try to crack it with John using the --format=ssha option, John keeps saying that "No password hashes loaded." Could somebody clue me in on what I'm doing incorrect? Thank you.

John & aircrack length=26

Radikal No Copyright — 2008-06-23T11:52:34

Bonjour, Je voudrais cracker ma clé wpa avec aicrack-ng 0.9 et john 1.7.2. J'utilise Backtrack 2, le fichier de capture est ok. J'utilise cette ligne de commande: john -incremental:alpha --stdout | aircrack-ng -a 2 -b XX:XX:XX:XX:XX:XX -w - /mnt/cle/temp/*.cap Mais il ne trouve pas ma clé car elle a 26 caractères comprenant des 0123456789ABCDEF J'aimerai donc faire une régle d'incrémentation avec min lenght= 26 max lenght= 26 avec en utilisant juste 0123456789ABCDEF comme caractères... Si quelqu'un peut m'aider... Merci --------------------- Hello, I want to crack my wpa key with aircrack-ng 0.9. I made my capture, i use john 1.7.2 in Backtrack 2 john -incremental:alpha --stdout | aircrack-ng -a 2 -b XX:XX:XX:XX:XX:XX -w - /mnt/cle/temp/*.cap My key have exactly 26 chars only with 0123456789ABCDEF I want to make a incremental...but i don't understand how to do... Please help me thank you... Sorry for my bad english, i'm french I saw the FAQ, Subject: Re: Incremental mode limited to 8 character words? But i don't understand, exactly how to do...I'm a new in linux http://www.openwall.com/lists/john-users/2007/07/04/6

macosx-x86-64

Solar Designer — 2008-06-21T16:00:42

Hi, Mac OS X 10.5+ (Leopard) and Xcode 3.0+ support 64-bit applications not only on PowerPC, but also on Intel (x86) CPUs - and I've just added the support into JtR as well. If you want to try this out and/or help test and benchmark it, please download the latest revisions of Makefile and x86-64.S (as of this writing) from here: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/john/john/src/ These work as drop-in replacements for the files in JtR 1.7.2. The new make target is "macosx-x86-64". On my MacBook (Core 2 Duo 2.0 GHz), this achieves the expected speedup for DES-based crypt(3) hashes (+11%) and for MD5-based crypt(3) hashes (+47%), does not significantly affect performance of LM and Kerberos AFS hashes, but slows Blowfish-based crypt(3) hashes down (-17%). All of this was in comparison to the older 32-bit "macosx-x86-sse2" target. While at it, I've also converted the code in x86-64.S to use instruction pointer relative addressing - this was required for Mac OS X, but I applied the change for all operating systems. This helps reduce code size, and performance should either remain the same or maybe become slightly better (because of the reduced code size and thus having more space in the L1 instruction cache available for other needs). Testing on Athlon64 and Core 2 confirms this so far (no easily measurable change), but I would not mind more benchmarks/reports confirming that there is indeed no slowdown because of this change on any common CPU. Thanks, Alexander

wiki page on parallelization

Solar Designer — 2008-06-20T20:33:30

Hi, RB has contributed this wiki page on existing efforts to introduce parallel processing and distributed processing into JtR: http://openwall.info/wiki/john/parallelization and I've just added links to the above page from: http://openwall.info/wiki/john http://openwall.info/wiki/john/patches RB - Thank You! A possible improvement could be to mention trivial/manual approaches as well - as many of you know, I've been advocating those for simple cases (say, for up to 4 CPUs/cores) until we have official parallelization support in JtR. Maybe there should be a "parallelization" DokuWiki namespace (in addition to the wiki page), such that relevant patches would be uploaded to under that namespace and such that we could have a sub-page on the manual approaches. Please keep these contributions coming. Thanks again, Alexander

NetscreenOS passwords

Samuel Moñux — 2008-06-20T10:59:34

diff -urpN john-1.7.2-orig/src/john.c john-1.7.2/src/john.c --- john-1.7.2-orig/src/john.c2006-05-08 14:48:48.000000000 +0000 +++ john-1.7.2/src/john.c2008-06-19 12:01:26.000000000 +0000 < at >< at > -36,7 +36,7 < at >< at > extern int CPU_detect(void); #endif -extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF; +extern struct fmt_main fmt_DES, fmt_BSDI, fmt_MD5, fmt_BF, fmt_NS; extern struct fmt_main fmt_AFS, fmt_LM; extern int unshadow(int argc, char **argv); < at >< at > -64,6 +64,7 < at >< at > static void john_register_all(void) john_register_one(&fmt_BF); john_register_one(&fmt_AFS); john_register_one(&fmt_LM); +john_register_one(&fmt_NS); if (!fmt_list) { fprintf(stderr, "Unknown ciphertext format name requested\n"); diff -urpN john-1.7.2-orig/src/Makefile john-1.7.2/src/Makefile --- john-1.7.2-orig/src/Makefile2006-05-15 16:38:00.000000000 +0000 +++ john-1.7.2/src/Makefile2008-06-20 10:31:12.000000000 +0000 < at >< at > -17,7 +17,7 < at >< at > NULL = /dev/null CPPFLAGS = -E CFLAGS = -c -Wall -O2 -fomit-frame-pointer ASFLAGS = -c -LDFLAGS = -s +LDFLAGS = -s OPT_NORMAL = -funroll-loops OPT_INLINE = -finline-functions < at >< at > -34,7 +34,9 < at >< at > JOHN_OBJS_MINIMAL = \ recovery.o rpp.o rules.o signals.o single.o status.o tty.o wordlist.o \ unshadow.o \ unafs.o \ -unique.o +unique.o \ +md5.o \ +NS_fmt.o JOHN_OBJS_ORIG = \ $(JOHN_OBJS_MINIMAL) \ < at >< at > -60,7 +62,7 < at >< at > BENCH_BF_OBJS_DEPEND = \ BENCH_OBJS = \ $(BENCH_DES_OBJS_DEPEND) \ -DES_bs.o $(BENCH_DES_BS_OBJS_DEPEND) \ +DES_bs.o $(BENCH_DES_BS_OBJS_DEPEND) NS_fmt.o \ $(BENCH_MD5_OBJS_DEPEND) \ BF_fmt.o $(BENCH_BF_OBJS_DEPEND) \ bench.o best.o common.o config.o formats.o math.o memory.o miscnl.o \ diff -urpN john-1.7.2-orig/src/md5.c john-1.7.2/src/md5.c --- john-1.7.2-orig/src/md5.c1970-01-01 00:00:00.000000000 +0000 +++ john-1.7.2/src/md5.c2008-06-19 11:59:52.000000000 +0000 < at >< at > -0,0 +1,274 < at >< at > +/* + * This is an OpenSSL-compatible implementation of the RSA Data Security, + * Inc. MD5 Message-Digest Algorithm. + * + * Written by Solar Designer openwall.com> in 2001, and placed in + * the public domain. There's absolutely no warranty. + * + * This differs from Colin Plumb's older public domain implementation in + * that no 32-bit integer data type is required, there's no compile-time + * endianness configuration, and the function prototypes match OpenSSL's. + * The primary goals are portability and ease of use. + * + * This implementation is meant to be fast, but not as fast as possible. + * Some known optimizations are not included to reduce source code size + * and avoid compile-time configuration. + */ + +#ifndef HAVE_OPENSSL + +#include +#include "common.h" +#include "md5.h" + +/* + * The basic MD5 functions. + * + * F is optimized compared to its RFC 1321 definition just like in Colin + * Plumb's implementation. + */ +#define F(x, y, z)((z) ^ ((x) & ((y) ^ (z)))) +#define G(x, y, z)((y) ^ ((z) & ((x) ^ (y)))) +#define H(x, y, z)((x) ^ (y) ^ (z)) +#define I(x, y, z)((y) ^ ((x) | ~(z))) + +/* + * The MD5 transformation for all four rounds. + */ +#define STEP(f, a, b, c, d, x, t, s) \ +(a) += f((b), (c), (d)) + (x) + (t); \ +(a) = (((a) << (s)) | (((a) & 0xffffffff) >> (32 - (s)))); \ +(a) += (b); + +/* + * SET reads 4 input bytes in little-endian byte order and stores them + * in a properly aligned word in host byte order. + * + * The check for little-endian architectures which tolerate unaligned + * memory accesses is just an optimization. Nothing will break if it + * doesn't work. + */ +#if defined(__i386__) || defined(__vax__) +#define SET(n) \ +(*(MD5_u32plus *)&ptr[(n) * 4]) +#define GET(n) \ +SET(n) +#else +#define SET(n) \ +(ctx->block[(n)] = \ +(MD5_u32plus)ptr[(n) * 4] | \ +((MD5_u32plus)ptr[(n) * 4 + 1] << 8) | \ +((MD5_u32plus)ptr[(n) * 4 + 2] << 16) | \ +((MD5_u32plus)ptr[(n) * 4 + 3] << 24)) +#define GET(n) \ +(ctx->block[(n)]) +#endif + +/* + * This processes one or more 64-byte data blocks, but does NOT update + * the bit counters. There're no alignment requirements. + */ +static void *body(MD5_CTX *ctx, void *data, unsigned long size) +{ +unsigned char *ptr; +MD5_u32plus a, b, c, d; +MD5_u32plus saved_a, saved_b, saved_c, saved_d; + +ptr = data; + +a = ctx->a; +b = ctx->b; +c = ctx->c; +d = ctx->d; + +do { +saved_a = a; +saved_b = b; +saved_c = c; +saved_d = d; + +/* Round 1 */ +STEP(F, a, b, c, d, SET(0), 0xd76aa478, 7) +STEP(F, d, a, b, c, SET(1), 0xe8c7b756, 12) +STEP(F, c, d, a, b, SET(2), 0x242070db, 17) +STEP(F, b, c, d, a, SET(3), 0xc1bdceee, 22) +STEP(F, a, b, c, d, SET(4), 0xf57c0faf, 7) +STEP(F, d, a, b, c, SET(5), 0x4787c62a, 12) +STEP(F, c, d, a, b, SET(6), 0xa8304613, 17) +STEP(F, b, c, d, a, SET(7), 0xfd469501, 22) +STEP(F, a, b, c, d, SET(8), 0x698098d8, 7) +STEP(F, d, a, b, c, SET(9), 0x8b44f7af, 12) +STEP(F, c, d, a, b, SET(10), 0xffff5bb1, 17) +STEP(F, b, c, d, a, SET(11), 0x895cd7be, 22) +STEP(F, a, b, c, d, SET(12), 0x6b901122, 7) +STEP(F, d, a, b, c, SET(13), 0xfd987193, 12) +STEP(F, c, d, a, b, SET(14), 0xa679438e, 17) +STEP(F, b, c, d, a, SET(15), 0x49b40821, 22) + +/* Round 2 */ +STEP(G, a, b, c, d, GET(1), 0xf61e2562, 5) +STEP(G, d, a, b, c, GET(6), 0xc040b340, 9) +STEP(G, c, d, a, b, GET(11), 0x265e5a51, 14) +STEP(G, b, c, d, a, GET(0), 0xe9b6c7aa, 20) +STEP(G, a, b, c, d, GET(5), 0xd62f105d, 5) +STEP(G, d, a, b, c, GET(10), 0x02441453, 9) +STEP(G, c, d, a, b, GET(15), 0xd8a1e681, 14) +STEP(G, b, c, d, a, GET(4), 0xe7d3fbc8, 20) +STEP(G, a, b, c, d, GET(9), 0x21e1cde6, 5) +STEP(G, d, a, b, c, GET(14), 0xc33707d6, 9) +STEP(G, c, d, a, b, GET(3), 0xf4d50d87, 14) +STEP(G, b, c, d, a, GET(8), 0x455a14ed, 20) +STEP(G, a, b, c, d, GET(13), 0xa9e3e905, 5) +STEP(G, d, a, b, c, GET(2), 0xfcefa3f8, 9) +STEP(G, c, d, a, b, GET(7), 0x676f02d9, 14) +STEP(G, b, c, d, a, GET(12), 0x8d2a4c8a, 20) + +/* Round 3 */ +STEP(H, a, b, c, d, GET(5), 0xfffa3942, 4) +STEP(H, d, a, b, c, GET(8), 0x8771f681, 11) +STEP(H, c, d, a, b, GET(11), 0x6d9d6122, 16) +STEP(H, b, c, d, a, GET(14), 0xfde5380c, 23) +STEP(H, a, b, c, d, GET(1), 0xa4beea44, 4) +STEP(H, d, a, b, c, GET(4), 0x4bdecfa9, 11) +STEP(H, c, d, a, b, GET(7), 0xf6bb4b60, 16) +STEP(H, b, c, d, a, GET(10), 0xbebfbc70, 23) +STEP(H, a, b, c, d, GET(13), 0x289b7ec6, 4) +STEP(H, d, a, b, c, GET(0), 0xeaa127fa, 11) +STEP(H, c, d, a, b, GET(3), 0xd4ef3085, 16) +STEP(H, b, c, d, a, GET(6), 0x04881d05, 23) +STEP(H, a, b, c, d, GET(9), 0xd9d4d039, 4) +STEP(H, d, a, b, c, GET(12), 0xe6db99e5, 11) +STEP(H, c, d, a, b, GET(15), 0x1fa27cf8, 16) +STEP(H, b, c, d, a, GET(2), 0xc4ac5665, 23) + +/* Round 4 */ +STEP(I, a, b, c, d, GET(0), 0xf4292244, 6) +STEP(I, d, a, b, c, GET(7), 0x432aff97, 10) +STEP(I, c, d, a, b, GET(14), 0xab9423a7, 15) +STEP(I, b, c, d, a, GET(5), 0xfc93a039, 21) +STEP(I, a, b, c, d, GET(12), 0x655b59c3, 6) +STEP(I, d, a, b, c, GET(3), 0x8f0ccc92, 10) +STEP(I, c, d, a, b, GET(10), 0xffeff47d, 15) +STEP(I, b, c, d, a, GET(1), 0x85845dd1, 21) +STEP(I, a, b, c, d, GET(8), 0x6fa87e4f, 6) +STEP(I, d, a, b, c, GET(15), 0xfe2ce6e0, 10) +STEP(I, c, d, a, b, GET(6), 0xa3014314, 15) +STEP(I, b, c, d, a, GET(13), 0x4e0811a1, 21) +STEP(I, a, b, c, d, GET(4), 0xf7537e82, 6) +STEP(I, d, a, b, c, GET(11), 0xbd3af235, 10) +STEP(I, c, d, a, b, GET(2), 0x2ad7d2bb, 15) +STEP(I, b, c, d, a, GET(9), 0xeb86d391, 21) + +a += saved_a; +b += saved_b; +c += saved_c; +d += saved_d; + +ptr += 64; +} while (size -= 64); + +ctx->a = a; +ctx->b = b; +ctx->c = c; +ctx->d = d; + +return ptr; +} + +void MD5_Init(MD5_CTX *ctx) +{ +ctx->a = 0x67452301; +ctx->b = 0xefcdab89; +ctx->c = 0x98badcfe; +ctx->d = 0x10325476; + +ctx->lo = 0; +ctx->hi = 0; +} + +void MD5_Update(MD5_CTX *ctx, void *data, unsigned long size) +{ +MD5_u32plus saved_lo; +unsigned long used, free; + +saved_lo = ctx->lo; +if ((ctx->lo = (saved_lo + size) & 0x1fffffff) < saved_lo) +ctx->hi++; +ctx->hi += size >> 29; + +used = saved_lo & 0x3f; + +if (used) { +free = 64 - used; + +if (size < free) { +memcpy(&ctx->buffer[used], data, size); +return; +} + +memcpy(&ctx->buffer[used], data, free); +data = (unsigned char *)data + free; +size -= free; +body(ctx, ctx->buffer, 64); +} + +if (size >= 64) { +data = body(ctx, data, size & ~(unsigned long)0x3f); +size &= 0x3f; +} + +memcpy(ctx->buffer, data, size); +} + +void MD5_Final(unsigned char *result, MD5_CTX *ctx) +{ +unsigned long used, free; + +used = ctx->lo & 0x3f; + +ctx->buffer[used++] = 0x80; + +free = 64 - used; + +if (free < 8) { +memset(&ctx->buffer[used], 0, free); +body(ctx, ctx->buffer, 64); +used = 0; +free = 64; +} + +memset(&ctx->buffer[used], 0, free - 8); + +ctx->lo <<= 3; +ctx->buffer[56] = ctx->lo; +ctx->buffer[57] = ctx->lo >> 8; +ctx->buffer[58] = ctx->lo >> 16; +ctx->buffer[59] = ctx->lo >> 24; +ctx->buffer[60] = ctx->hi; +ctx->buffer[61] = ctx->hi >> 8; +ctx->buffer[62] = ctx->hi >> 16; +ctx->buffer[63] = ctx->hi >> 24; + +body(ctx, ctx->buffer, 64); + +result[0] = ctx->a; +result[1] = ctx->a >> 8; +result[2] = ctx->a >> 16; +result[3] = ctx->a >> 24; +result[4] = ctx->b; +result[5] = ctx->b >> 8; +result[6] = ctx->b >> 16; +result[7] = ctx->b >> 24; +result[8] = ctx->c; +result[9] = ctx->c >> 8; +result[10] = ctx->c >> 16; +result[11] = ctx->c >> 24; +result[12] = ctx->d; +result[13] = ctx->d >> 8; +result[14] = ctx->d >> 16; +result[15] = ctx->d >> 24; + +memset(ctx, 0, sizeof(*ctx)); +} + +#endif diff -urpN john-1.7.2-orig/src/md5.h john-1.7.2/src/md5.h --- john-1.7.2-orig/src/md5.h1970-01-01 00:00:00.000000000 +0000 +++ john-1.7.2/src/md5.h2008-06-19 11:59:52.000000000 +0000 < at >< at > -0,0 +1,35 < at >< at > +/* + * This is an OpenSSL-compatible implementation of the RSA Data Security, + * Inc. MD5 Message-Digest Algorithm. + * + * Written by Solar Designer openwall.com> in 2001, and placed in + * the public domain. See md5.c for more information. + */ + +#ifdef HAVE_OPENSSL +#include +#elif !defined(_MD5_H) +#define _MD5_H + +/* Any 32-bit or wider unsigned integer data type will do */ +typedef unsigned long MD5_u32plus; + +typedef struct { +MD5_u32plus lo, hi; +MD5_u32plus a, b, c, d; +unsigned char buffer[64]; +MD5_u32plus block[16]; +} MD5_CTX; + +extern void MD5_Init(MD5_CTX *ctx); +extern void MD5_Update(MD5_CTX *ctx, void *data, unsigned long size); +extern void MD5_Final(unsigned char *result, MD5_CTX *ctx); + +#ifdef MMX_COEF +extern int mdfivemmx(unsigned char *out, unsigned char *in, int n) __attribute__((regparm(3))); +extern int mdfivemmx_nosizeupdate(unsigned char *out, unsigned char *in, int n) __attribute__((regparm(3))); +extern int mdfivemmx_noinit_sizeupdate(unsigned char *out, unsigned char *in, int n) __attribute__((regparm(3))); +extern int mdfivemmx_noinit_uniformsizeupdate(unsigned char *out, unsigned char *in, int n) __attribute__((regparm(3))); +#endif + +#endif diff -urpN john-1.7.2-orig/src/NS_fmt.c john-1.7.2/src/NS_fmt.c --- john-1.7.2-orig/src/NS_fmt.c1970-01-01 00:00:00.000000000 +0000 +++ john-1.7.2/src/NS_fmt.c2008-06-20 10:17:02.000000000 +0000 < at >< at > -0,0 +1,229 < at >< at > +/* + */ + +#include + +#include "arch.h" +#include "misc.h" +#include "md5.h" +#include "common.h" +#include "formats.h" + +#define FORMAT_LABEL"md5ns" +#define FORMAT_NAME"Netscreen MD5" +#define NS_ALGORITHM_NAME "NS MD5" + +#define BENCHMARK_COMMENT"" +#define BENCHMARK_LENGTH-1 + +#define PLAINTEXT_LENGTH15 +#define CIPHERTEXT_LENGTH50 + +#define BINARY_SIZE16 +#define SALT_SIZE32 + +#define MIN_KEYS_PER_CRYPT1 +#define MAX_KEYS_PER_CRYPT1 + + +static struct fmt_tests tests[] = { +{"admin$nMjFM0rdC9iOc+xIFsGEm3LtAeGZhn", "password"}, +{"a$nMf9FkrCIgHGccRAxsBAwxBtDtPHfn", "netscreen"}, +{NULL} +}; + +static unsigned short e64toshort[256]; + +#define ADM_LEN 22 +static int salt_len, key_len; +static char cipher_salt[ SALT_SIZE ]; +static char cipher_key[ PLAINTEXT_LENGTH + 1 ]; +static char *adm = ":Administration Tools:"; +static char tocipher[ SALT_SIZE + ADM_LEN + PLAINTEXT_LENGTH ]; +static MD5_u32plus crypted[4]; + + +static void NS_init() +{ +int i; +static char *b64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/"; +char *pos; +for (pos = b64, i = 0 ; *pos != 0 ; pos++, i++) +e64toshort[(int)*pos] = i; +} + +static int NS_valid(char *ciphertext) +{ +char *password; +static char *netscreen = "nrcstn" ; + static int p[] = { 0, 6, 12, 17, 23, 29 }; +int i; + + password = ciphertext; + + while ((*password != '$') && (*password != '\0' )) + password++; + if (*password == '\0') return 0; + password++; + +if (strlen(password) != 30) return 0; +for (i = 0; i < 6 ; i++) +if (netscreen[i] != password[p[i]]) return 0; + +for (i = 0; i < 30 ; i++) { +char c = password[i]; +if (((c >= 'A') && ( c <= 'Z')) || + ((c >= 'a') && ( c <= 'z')) || + ((c >= '0') && ( c <= '9')) || + (c == '+') || ( c == '/')) +continue; +return 0; +} +return 1; +} + +static MD5_u32plus *NS_std_get_binary(char *ciphertext) +{ +static union { +MD5_u32plus w[4]; +char b[16]; +} out; +char unscrambled[24]; +int i; + MD5_u32plus a, b, c; + MD5_u32plus d, e, f; +char *pos; +#if ARCH_LITTLE_ENDIAN + MD5_u32plus temp; +#endif + + pos = ciphertext; +while (*pos++ != '$'); + +memcpy(unscrambled, pos + 1, 6 ); +memcpy(unscrambled + 5, pos + 7, 6 ); +memcpy(unscrambled + 10, pos + 13, 5 ); +memcpy(unscrambled + 14, pos + 18, 6 ); +memcpy(unscrambled + 19, pos + 24, 5 ); + +for ( i = 0 ; i < 4 ; i++ ) { + a = e64toshort[ARCH_INDEX(unscrambled[6*i])]; + b = e64toshort[ARCH_INDEX(unscrambled[6*i + 1 ])]; + c = e64toshort[ARCH_INDEX(unscrambled[6*i + 2 ])]; + d = e64toshort[ARCH_INDEX(unscrambled[6*i + 3 ])]; + e = e64toshort[ARCH_INDEX(unscrambled[6*i + 4 ])]; + f = e64toshort[ARCH_INDEX(unscrambled[6*i + 5 ])]; +#if ARCH_LITTLE_ENDIAN + temp = (((a << 12) | (b << 6) | (c)) << 16) | + ((d << 12) | (e << 6) | (f)); +out.w[i] = ((temp << 24) & 0xff000000 ) | + ((temp << 8) & 0x00ff0000 ) | + ((temp >> 8) & 0x0000ff00 ) | + ((temp >> 24) & 0x000000ff ); +#else + out.w[i] = (((a << 12) | (b << 6) | (c)) << 16) | + ((d << 12) | (e << 6) | (f)); +#endif +} + +return out.w; +} + +char *NS_std_get_salt(char *ciphertext) +{ +static char out[SALT_SIZE + 1]; +char *ipos, *opos; + +ipos = ciphertext; +opos = out; +while (*ipos != '$') *opos++ = *ipos++; +*opos = '\0'; + +return out; +} + +void NS_std_set_salt (void *salt) +{ + salt_len = strlen((char *) salt); + memcpy(cipher_salt, salt , salt_len); +} + +static void NS_set_key(char *key, int index) +{ + key_len = strlen((char *) key); + memcpy(cipher_key, key, strlen(key) + 1 ); +} + +static char *NS_get_key() +{ + return cipher_key; +} + +static void NS_std_crypt() +{ +MD5_CTX ctx; +MD5_Init(&ctx); +memcpy(tocipher, cipher_salt, salt_len); +memcpy(tocipher + salt_len, adm, ADM_LEN); +memcpy(tocipher + salt_len + ADM_LEN, cipher_key, key_len); +MD5_Update(&ctx , tocipher, salt_len + ADM_LEN + key_len); +MD5_Final((void*)crypted, &ctx); +} + +static int NS_cmp_all(void *binary, int index) +{ +int i; +for ( i = 0 ; i < 4 ; i++ ) { +if(((MD5_u32plus *)binary)[i]!=((MD5_u32plus*)crypted)[i]) { +return 0; +} +} +return 1; +} + +static int NS_cmp_exact(char *source, int index) +{ +return 1; +} + +struct fmt_main fmt_NS = { +{ +FORMAT_LABEL, +FORMAT_NAME, +NS_ALGORITHM_NAME, +BENCHMARK_COMMENT, +BENCHMARK_LENGTH, +PLAINTEXT_LENGTH, +BINARY_SIZE, +SALT_SIZE, +MIN_KEYS_PER_CRYPT, +MAX_KEYS_PER_CRYPT, +FMT_CASE | FMT_8_BIT, +tests +}, { +NS_init, +NS_valid, +fmt_default_split, +(void *(*)(char *))NS_std_get_binary, +(void *(*)(char *))NS_std_get_salt, +{ + fmt_default_binary_hash, + fmt_default_binary_hash, + fmt_default_binary_hash +}, +fmt_default_salt_hash, +NS_std_set_salt, +NS_set_key, +NS_get_key, +fmt_default_clear_keys, +NS_std_crypt, +{ +fmt_default_get_hash, +fmt_default_get_hash, +fmt_default_get_hash +}, +NS_cmp_all, +NS_cmp_all, +NS_cmp_exact +} +};

Password generating tool

Markus Friedel — 2008-06-18T13:27:00

Hi, on my way to get John working with BOINC i have to do some tests. So i need some passwords. actually i get them by using pwgen an mkpasswd this way: pwgen -A -0 $PWLENGTH 1 | mkpasswd -H MD5 -s >> mypassword The problem with mkpasswd is, i can only generate md5 and des. But i want to have more algorithms to test on. Can somebody show me a tool who does this with more algorithms and still works with john? I have tested mcrypt, but didnt get it work with john. best regards Markus Friedel

interpretation of results

Russell Fulton — 2008-06-17T21:00:01

I have been running a bunch of UNIX DES hashes and have one cracked: [rful011< at >bojan-desktop .jtr]$ john --show unix.pass root::14007::56:::: I don't think the password is null (there is a hash for it) or is there a distinction between no password and a null one (which makes sense)? No I can't just test it since the box is behind a firewall which I don't have (immediate) access through. It was cracked at the start of the incremental run so it is clearly something short ? Russell

search path for config file

Russell Fulton — 2008-06-16T00:32:55

I need some clarification about this. The CONFIG file says: This file is searched for in private John's "home directory" and, if not found in the private directory and John is installed system-wide, also in John's system-wide shared data files directory. but I find this confusing. I have found that john will find config files in the current directory. I have tried setting the environment variable JOHN but this does not seem to have any effect. I have also looked in the INSTALL instructions but failed to find any reference to "home". Enlightenment welcome. On a side issue I am about to get my grubby mitts on an "IronKey Enterprise" encrypted flash drive and intend to install john on the secured portion of the drive and keep the password files and pot etc. on the normal file section. That way I should have all the sensitive stuff in one very secure place. https://www.ironkey.com/ If anyone is interested in how this goes drop me a note Russell

raw-md5 module improvement

Bucsay Balázs — 2008-06-12T17:41:27

Hello! I had some time, so i took a look at the john's raw-md5 module and made some improvements. I sent it to my friends to test it, and makes some reports. It was everywhere faster than the old one. I hope so, it hasnt any bugs, i didnt found anyone of it, so please try it. (the patch is only for the pure 1.7.2, if you use anything else in that, you might have to patch the patch :) ) URL: http://www.rycon.hu/tools/john-1.7.2_rawMD5_fast.patch My results: --test: new module: Benchmarking: Raw MD5 [raw-md5]... DONE Raw: 4408K c/s real, 4408K c/s virtual old module: Benchmarking: Raw MD5 [raw-md5]... DONE Raw: 3771K c/s real, 3801K c/s virtual 1hash: the same as the test. 1000hash: new module: guesses: 382 time: 0:00:00:34 79% (1) c/s: 98645K trying: ... old module: guesses: 382 time: 0:00:01:09 83% (1) c/s: 52946K trying: ... at 200.000hash the c/s is ~half of this result. Balázs Bucsay http://rycon.hu/

FileVault?

Matt Durden — 2008-06-02T18:42:27

Has anyone ever used JTR for FileVault? I've not had any luck finding any info on it.

CUDA the Ripper

Alex V. Breger — 2008-06-01T20:32:45

Hello Are there any attempts to use GPU computing for John the Ripper? There are some examples, which get 70 millions per second of raw MD5 calculations on Geforce 8800 GS (cuda md5 project) and 34 millions per second of raw SHA1 (without downloading and uploading data to graphic card) I'm doing some experiments, but only get 25 million/sec for raw MD5 and 7 million/sec for raw SHA1. There was some problems with bench.c and incremental cracker. Benchmark can't get a full speed, which measured by real hash cracking after a some time. How does john calculate a speed of hash generation? I've noticed some inertness - speed is slowly growing with time. How fast is incremental cracker? What a maximum rate of password generation can it get? For CUDA I use a big sets of password (from tens of hundreds to several millions) to transfer to GPU for processing. I think, that bottleneck for now is incremental cracker or my _set_key() function. Transferring data to GPU also can be a bottleneck. Thanks you for JtR

change johns default directories

Markus Friedel — 2008-05-27T20:33:52

Hi, i am searching for a way to change johns default directory location. The current location is "$HOME/.john/" . Because i run john without an installation it should be possible for me to can change this location to the current folder from which i start john. Thank you in advance best regards Markus Friedel

15 characters

bofh — 2008-05-27T13:54:28

Hi, Simple question. I have a password file, and I want to run JtR on it. My needs are simple. I want to search through: A-Z a-z 0-9 !< at >#$%^&*()-=_+[]\;',./{}|:"<>? basically all the printed characters. The password lengths are up to 15 chars. What's the most efficient (cpu/running time) way to do this?