[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <000901cd44f9$efdbb030$cf931090$@net>
Date: Thu, 7 Jun 2012 17:07:31 -0500
From: "jfoug" <jfoug@....net>
To: <john-users@...ts.openwall.com>
Subject: RE: JtR to process the LinkedIn hash dump
>>From: Brad Tilley [mailto:brad@...ystems.com]
>>> The patches are found here:
>>>
>>> http://openwall.info/wiki/john/patches
>>
>>Thanks. That's working well in testing with the rockyou word list.
>
>You will note that 'most' of them that you crack will have 00000 as the
>first bytes of the hash (if you are using the rock-u words, and nothing
>more than 'rules' from JtR). This shows that whomever released this,
>that they are using 00000 as a 'already cracked' signature.
One thing that has been brought up, is there are lots of hashes like this:
0000003ced2802e237e597f6a9d14e963206d6c3
122b603ced2802e237e597f6a9d14e963206d6c3
These are broken by the word camp1985hill. Now, since this is a non-salted
hash, except we are allowing these to be loaded, AND viewed as the same
thing.
But there are a few things 'built in' to JtR which will cause a few strange
side effects. The biggest, is JtR believes that the above 2 are duplicates.
It will list the password was found for both strings. However, only one of
them is written to the .pot file. JtR sets a 'dupe' flag, and does not
write the other.
So, to work around this, run your cracks, then do this:
cut -d: -f2- john.pot > pw
./john -w=pw combo_not.txt
./john -w=pw combo_not.txt
./john -w=pw combo_not.txt
What this does, is to re-run the already found passwords. JtR will remove
the found hashes from memory (exactly matched), when it loads the .pot file.
Then what is left, is the hash that was not cracked. I have found that you
may have to run JtR 2 times (not sure why, but it could be because I am
running multiple instances of JtR at same time), on the already cracked
passwords. By the 3rd (possibly 2nd) run, JtR will list that NO passwords
were cracked. At that time, all duplicate matching hashes are now in the
.pot file, and when JtR loads combo_not.txt, it will properly remove ALL
hashes.
A simple format fix was NOT enough to change this logic. This duplicate
detection logic is deep within the core JtR code, and it is in a couple of
places. I will NOT be trying to fix this behavior to work with this (semi
busted) format. Simple note the procedure which properly builds the .pot
file, removing both hashes.
Jim.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
