Date: Sat, 26 Feb 2011 11:22:26 -0600 From: "jfoug" <jfoug@....net> To: <john-users@...ts.openwall.com> Subject: RE: md5_gen(0) broken for ages? This is actually a very good suggestion, and I 'think' it will be pretty easy to do. I will handle this much like is done in a 'thin' client. Where in the valid() function in md5-gen, it will fixup the hash, by adding the md5_gen(#) if it is running in this specific mode. There are several caveats (and I have not yet dug into any unintended consequences). 1. This will ONLY be used, if you fully specify the md5-gen format and a subformat. 2. This will likely only work for non-salted hashes, due to how md5_gen requires the salt to be placed. 3. There 'could' be hashes not checked, because they are in the john.pot file, and are things like 1/2 of an LM, etc. Also when getting into multi-pass MD5, there may be cases where there are some hashes not checked, due to situations like this. This 'should' be a pretty rare case. This is due to the subformat now picking up hashes out of john.pot that are NOT of the proper format. This is already seen today, where a .pot file with LM and a .pot file with 'raw-md5' will use each other's cracked hashes as their own, and not test them. 4. Any found hashes will be stored in the john.pot file as the raw hex number. They will not list that the found format was md5_gen(0), or whatever subformat found it. This is because john 'owns' the hash string. All that I am doing in md5-gen is fixing up a local string, so that that it will load properly. The salted hashes have been laid out in a specific way (salt appended to end preceded by a $ char, and 2nd salt, pretended to that preceded by a $$2 signature). Thus, simply appending md5_gen(12) to the front, will likely NOT get it into a 'valid' format. Also, I will not be able to add code to try to 'find' the salt. There simply is no way. It may be the first 8 characters, the last 8, the last 16, have a $1$ signature, then 8 chars, then a $. There simply is no 'generic' way to auto load salted hashes that are in 'native' format. However, even with the above caveats (and likely more), I do think this is a valid change, and I was surprised that it really was not that hard. Note, I do not have it fully working yet, but do have the 'valid' function working. I will have to make a few additional changes, but I do believe this is a doable function. Thus, -format=raw-md5 or -format=md5-gen -subf=md5_gen(0) 'should' be able to work over the same raw hash file, using the same pot file. Jim. -----Original Message----- From: magnum [mailto:rawsmooth@...dband.net] Sent: Saturday, February 26, 2011 4:59 AM To: john-users@...ts.openwall.com Subject: Re: [john-users] md5_gen(0) broken for ages? On 02/26/2011 02:20 AM, jfoug wrote: > It is no different than taking a line like > > User:abcdef0123456789abcdef0123456789 > > And calling john with john -format=md5a inputfile.in > > and expecting the above line in the input file to be 'used'. > It will not be used, because md5a has a specific format, and > That hash does not match it. If a hash does not start with the > $1$ when md5a will never choose that line. Same for md5_gen(0) OK, that makes sense. But there is a difference: You will never find hashes "in the wild" prepended with md5gen(n). Sometimes you have to guess format just based on hash length and hope that a weak password will reveal what it is. Unless you can iterate over the --subformat option, you have to modify the hash file for each try. So let me re-phrase it as a low-prio enhancement request. Would it be possible to have it accept bare hashes [of correct length etc] if --subformat was given, or could this introduce other problems? thanks magnum
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.