Date: Tue, 6 Dec 2011 01:51:45 +0100 From: Didier Arenzana <darenzana@...il.com> To: john-users@...ts.openwall.com Subject: Re: cracking RADIUS shared secrets with john the ripper Hi Jim, and thank you for your comments. On Tue, Dec 6, 2011 at 1:19 AM, JimF <jfoug@....net> wrote: > Using set_salt() vs salt() to do the HEX->binary conversion causes this to be done each time, for each password. If we can do this in salt, it is only done one time, at startup. I had suspected this at one time, but when testing with gdb and the following line, which I have intentionnaly modified so the hash is 'unsolvable' : crack:$dynamic_1008$af25d95ad759e0f43921be2782d10b74$HEX$7ae3c680caee7171e28e0409b2e2f3ab seting a break point to dynamic_fmt.c:set_salt, I have seen set_salt is called 3 times with the $HEX$ salt (and 48 times with the example that is listed in the relevant section in dynamic.conf), and after that john is runing uninterrupted; so I assumed it was ok. Maybe this is due do the fact that I use dynamic_>1000 as opposed to the internals dynamic_n formats ? > However, the caveat here is, 'can' these salts contain NULL bytes? If so, then we either have to do the work like you have it done, or have the salt returned be like a Pascal string (length prepended to the string of bytes). Other than this 'possible' change, I think this addition to dynamic is good. The salts used in the RADIUS protocol, which is why I wrote the patch can and do contain NULL bytes, unfortunately. Is this pascal string format already taken into acount in other parts of john ? in other words, If I change the patch to use salt() and return a pascal string, are there other changes needed than in the salt() and valid() functions ? > I do believe we will need to make changes in the 'length' computation parts (in valid I believe), which causes hashes to be set as invalid if lengths of things are too much (such as salt length). This computation should be done POST hex2bin, so that these salts would only be properly counted as 16 bytes, even though they take up 36 bytes in 'string' format. I did not bother to change the valid() function, because using dynamic_>1000, I did not specify a fixed length so I expected that it would not cause trouble. And anyways, I could even have specified in the config file a fixed len of 4 (the size of HEX$) + double the length of the salt, to pass the check. > once this is added, we could add $HEX$hex_salt to any salted format, and it should be 'happy' with it. I might modify the patch later to comply with this, for now this patch fulfill my needs I guess (except if I'm wrong on the set_salt vs salt part). Of course, if anyone wants to improve the patch by applying your suggestion, I have nothing against it . > > Jim. Didier.
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.