[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 10 Dec 2011 00:23:18 +0100
From: Didier Arenzana <darenzana@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: cracking RADIUS shared secrets with john the ripper
On Fri, Dec 9, 2011 at 7:52 PM, jfoug <jfoug@....net> wrote:
> It has been posted as patch 0043- the salt() function now does all of the
> work, including figuring out what salts are identical. Dynamic returns 4
> byte or 8 byte 'salts' back to john, which will always be unique. These 4
> or 8 bytes are simply the data contents of a pointer.
I have donwloaded and built the patch, and you will find attached a
patch on top of this one, that contains the following modifications:
It did not compile out of the box on macosx-x86-64. I added a line to
johnswap.h, where ARCH_WORD_32 was used without being #defined
I made some changes in valid() and ConvertFromHex(), so that salts
such as "HEX$abc" (note the odd number of chars) or "HEX$mysalt" are
considered valid, and taken litterally (not converted from base16). In
the current implementation, something like this would pass valid() and
be converted in salt() to an incorrect value. Note that I took the
verification code from my own version of valid(), which has a
different logic than yours, but should produce the same result : it
searches first for HEX$, validates the string after, and computes an
'expected' length, and then checks against this length.
>>I will stick on my rad2john perl script then; and have a related
>>question: what is the absolute maximum length for a salt in dynamic_n
>>format ? The attack on radius responses use a whole packet as salt, so
>>it can get pretty big, I want to check in the script if it does not
>>generate too big salts.
>
> This depends upon how you have written the format. If you write them
> non-SSE, then any length salt 'should' work. With the changes I have made,
> I can easily do this. Prior code would have been hard, because we had to
> return max_length often, if we did not know, since many formats do not
> specify the max salt length. There is still 'some' of that logic within
> john. I think the max length at this moment (fully updated 1.7.9 up to
> patch 0043), I think is somewhere in this area: #define SALT_SIZE
> (64*4+1+3+1) NOTE, I have not validated this. The format would HAVE to
> be written to handle this. Keep in mind, that for x86 mode (i.e. anything
> other than MMX type builds), the buffers where you manipulate input data
> (and do the crypts from), is only 124 + 96 bytes, and I believe that on
> 'some' builds, those extra 96 bytes are used by the crypt code, as temp
> storage. So it may be that the largest salt you can 'use' is password_len -
> 124.
>
> NOTE, for any MMX build, unless you switch the data into and out of x86 type
> buffers, the max salt you can use is 55-password_len bytes long. This
> limitation is where most of the 'bullet proofing' of lengths within the
> built in types in the dynamic format come from.
I was not expecting such a long answer :) I will make it a variable in
the script so it's easy to change, and use a default value of 45.
Based on your explanation, it will give room for 10-characteres
password in the worst case.
> Jim.
>
View attachment "john-1.7.9.diff.txt" of type "text/plain" (5896 bytes)
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.
