gmane.comp.security.openwall.john.user

Re: patch for SAP-passwords (BCODE & PASSCODE)

madfran — 2008-07-04T06:42:18

Hi, I am trying to link the patch for SAP, but with no succes :-( My configuration is cygwin under Windows XP. Attached the relevant output when I try to link. Any idea? ************************************************************************* $ make clean win32-cygwin-x86-sse2 . . gcc -c -DUNDERSCORES x86.S gcc -c -DUNDERSCORES x86-sse.S gcc DES_fmt.o DES_std.o DES_bs.o BSDI_fmt.o MD5_fmt.o MD5_std.o BF_fmt.o BF_std. o AFS_fmt.o LM_fmt.o batch.o bench.o charset.o common.o compiler.o config.o crac ker.o crc32.o external.o formats.o getopt.o idle.o inc.o john.o list.o loader.o logger.o math.o memory.o misc.o options.o params.o path.o recovery.o rpp.o rules .o signals.o single.o status.o tty.o wordlist.o unshadow.o unafs.o unique.o rawS HA1_fmt.o rawMD5_fmt.o sapG_fmt.o sapB_fmt.o x86.o x86-sse.o -lkernel32 - o ../r un/john.exe rawSHA1_fmt.o:rawSHA1_fmt.c:(.text+0x20b): undefined reference to `_SHA1_Init' rawSHA1_fmt.o:rawSHA1_fmt.c:(.text+0x230): undefined reference to `_SHA1_Update' rawSHA1_fm

Re: Password encryption question

Solar Designer — 2008-07-02T02:30:15

This is mostly off-topic for this mailing list. It has nothing to do with John the Ripper, or even with its possible enhancements, because this is password mangling rather than password hashing. However, I've approved the posting this one time because it serves to illustrate how some server programs actually store users' passwords in an easily reversible form. ... These strings are a result of base64 encoding of some data, although in Password2 ones there's an extra character prepended to the encodings. I've tried decoding them, which produces N bytes for Password1 and N+1 bytes for Password2 (I've been omitting the leading "0" prior to the decoding), where N matches the plaintext password length. In order to figure out how to convert those decoded byte sequences back into the plaintext passwords, I suggest that you use one or both of the following approaches: 1. Use specially-crafted plaintext passwords to have the program reveal its obfuscation method more obviously. For example, you could set pass

Re: raw-md5 module improvement

Erik Winkler — 2008-07-01T20:19:51

On Jun 12, 2008, at 12:41 PM, Bucsay Balázs wrote: Fails to compile on big endian machines with the following error. Something to do with the endian swap I am guessing. md5_eq.c: In function ‘MD5_Go_eq’: md5_eq.c:306: error: invalid operands to binary << md5_eq.c:307: error: invalid operands to binary >> md5_eq.c:308: error: invalid operands to binary << md5_eq.c:309: error: invalid operands to binary >> Erik

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

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

Re: Password generating tool

2008-06-25T08:29:20

Hi, This page http://www.insidepro.com/hashes.php will give you a lot of different hash for the same (pass)word. Hope it's help. Regards, Vincent Malguy.

Re: John & aircrack length=26

Junty Mesmon — 2008-06-24T20:24:22

If you want incremental to output more than 8 characters, you will need to modify the source code of JtR (at least in my understanding). However, I doubt that aircrack-ng would be able to make enough calculations to reach more than 8 characters, extremely fast hardware ignored. On Mon, Jun 23, 2008 at 7:52 AM, Radikal No Copyright public.gmane.org> wrote:

Re: NetscreenOS passwords

Junty Mesmon — 2008-06-24T20:21:20

On the contrary, his patch has the same issues that solar mentioned existed in your first patch, and thus will be less efficient. Also, I see no harm in seeing how two people implement the same algorithm. I look forward to any further contributions you may have. On Mon, Jun 23, 2008 at 6:24 AM, Samuel Moñux public.gmane.org> wrote:

Re: Mac OS X 10.5.3 Leopard password hashes

Erik Winkler — 2008-06-24T17:59:50

The format is actually --format=macosx-sha1. This assumes you are using the latest jumbo patch applied to john-1.7.2 from the openwall site. Here is the link to the patch: http://www.openwall.com/john/contrib/john-1.7.2-all-12.diff.gz Erik

Re: Mac OS X 10.5.3 Leopard password hashes

55 89 e5 — 2008-06-24T14:39:17

Ulises, Thanks a lot for your reply. Your explanation was very clear. However, can John 1.7.2 (the latest version) handle Apple's salted SHA1? I've tried using the --format=ssha option and I just can't get it to work. Is there a particular format that the hash/salt needs to be put in? Thank you!

Re: Mac OS X 10.5.3 Leopard password hashes

Ulises2k — 2008-06-24T04:52:52

Hi, I'm speak spanish. Read: http://www.dribin.org/dave/blog/archives/2006/04/28/os_x_passwords_2/ It is: Apple also added salts to the SHA1 hash. The format of the hash file changed, too: % sudo more $hash_file 00000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000\ 00000000000000000000000000000000000000000000000000000000000000000000000000000000\ 000000000E6A48F765D0FFFFF6247FA80D748E615F91DD0C7431E4D9000000000000000000000000\ 00000000000000000000000000000000000000000000000000000000000000000000000000000000\ 00000000000000000000000000000000000000000000000000000000000000000000000000000000\ 00000000000000000000000000000000000000000000000000000000000000000000000000000000\ 00000000000000000000000000000000000000000000000000000000000000000000000000000000\ 00000000000000000000000000000000000000000000000000000000000000000000000000000000\ 0000000000000000000000000000000000000000000000000000000000000000000000

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 000000000000000000000000000000000000000000000000000

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?

Re: NetscreenOS passwords

Samuel Moñux — 2008-06-23T10:24:14

2008/6/20 Solar Designer public.gmane.org>: I do attach the patch again, with that minor corrections, and a python script for generating ciphered passwords. Anyway, the guy who first unscrambled Netscreen's password format has just released his JtR patch[1], so the whole effort has been pretty pointless. Best regards, Samuel [1] http://esec.fr.sogeti.com/blog/dotclear/?2008/06/19/34-patch-netscreen-pour-john-the-ripper # netscreen.py # Generate passwords in netscreen format. # import md5 import sys def net(user, password): b64 = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" middle = "Administration Tools" s = "%s:%s:%s" % (user, middle, password) m = md5.new(s).digest() narray = [] for i in range(8): n1 = ord(m[2*i]) n2 = ord(m[2*i+1]) narray.append( (n1<<8 & 0xff00) | (n2 & 0xff) ) res = "" for i in narray: p1 = i >> 12 & 0xf p2 = i >> 6 & 0x3f p3 = i & 0x3f res = res + b64[p1] + b64[p2] + b64[p3]

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 chan

Re: NetscreenOS passwords

Solar Designer — 2008-06-20T21:10:07

Thank you for your contribution. We'll consider it for the next revision of the jumbo patch. Meanwhile, you could want to fix two things: 1. Replace my generic MD5 code with its newer revision, which may be found here: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/popa3d/popa3d/md5/ 2. Introduce proper binary_hash and get_hash functions instead of the dummy wrappers: ... This issue has been mentioned in here just recently: http://www.openwall.com/lists/john-users/2008/06/13/2 Thanks again, Alexander

Re: wiki page on parallelization

RB — 2008-06-20T20:45:47

Oi, I hadn't linked it yet since it's still a bit raw. Regardless, thanks! I plan on breaking it out more into subtypes and some implementation-specific procedures, I just got sidetracked chasing some other bits this week. rants/fixes/addendums appreciated, fanmail to /dev/null... ;)

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 ASFLAG

Re: Password generating tool

Solar Designer — 2008-06-18T20:59:24

I've attached a couple of Perl scripts that do what you have asked for - and more. The scripts require the Authen::Passphrase module from CPAN, and they accept a wordlist (such as JtR's default password.lst) on standard input and produce /etc/passwd-like or PWDUMP-like entries on standard output. This covers all of the hash types supported by JtR natively, and NTLM. The plaintext passwords are placed into the GECOS field, which lets the "single crack" mode crack them instantly. Alexander #!/usr/bin/perl use Authen::Passphrase::DESCrypt; use Authen::Passphrase::BigCrypt; use Authen::Passphrase::MD5Crypt; use Authen::Passphrase::BlowfishCrypt; $u = 0; while ($p = <>) { next if ($p =~ /^#!comment/); chomp $p; $h = Authen::Passphrase::DESCrypt->new(passphrase => $p, salt_random => 12); print "u$u-des:", $h->as_crypt, ":$u:0:$p", "::\n"; if (length($p) > 8) { $h = Authen::Passphrase::BigCrypt->new(passphrase => $p, salt_random => 12); print "u$u-bigcrypt:", $h->salt_base64_2, $h->hash_base64, ":$u

Re: interpretation of results

Solar Designer — 2008-06-18T20:12:50

OK. BTW, this is not relevant to your question, but you should run JtR against combined passwd and shadow files (use the included "unshadow" program/symlink), not just against the shadow file. This makes a difference for the "single crack" mode. I understand that you might have run it against the shadow file above in order to not reveal irrelevant info in your posting. ;-) The issue is that some systems, in some cases, will in fact generate hashes of empty strings instead of leaving the passwd or shadow file field empty. This does not make much sense as intended behavior, but it sort of makes sense as a somewhat common peculiarity. The systems might or might not treat such cases equally when authenticating users (e.g., as it relates to possible "permit empty passwords" settings). That's right. The "Incremental:All" mode will in fact try zero-length (empty) candidate passwords: # Incremental modes [Incremental:All] File = $JOHN/all.chr MinLen = 0 MaxLen = 8 CharCount = 95 Alexander