[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Aug 2012 15:22:42 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: Was: Re: [john-users] Cracking Gauss using dynamic
There were 4 functions missed. I have added these, and pushed to j6-fixes
git tree, and need to be merged downstream.
The functions 'missed', were the 4 raw functions:
DynamicFunc__append_from_last_output2_as_raw
DynamicFunc__append2_from_last_output2_as_raw
DynamicFunc__append_from_last_output1_as_raw
DynamicFunc__append2_from_last_output1_as_raw
In the checking I did, all other flags, and all other functions appear to be
properly 'linked' and usable from a script. These 4 were missed.
NOTE, these 4 functions will ONLY work properly on md5/md4 (or if MD5/MD4
was the function that just filled the crypt buffer being read from). The
md5/md4 are the only functions which 'keep' their results in the crypt
buffer (sha1 might in certain usages).
Jim.
>-----Original Message-----
>From: jfoug [mailto:jfoug@....net]
>Sent: Monday, August 20, 2012 2:25 PM
>To: john-dev@...ts.openwall.com
>Subject: RE: [john-dev] Was: Re: [john-users] Cracking Gauss using
>dynamic
>
>This is a bug in dynamic. I will investigate more.
>
>Here is what dynamic 'should' have.
>
>1. there is a function declared in dynamic.h These functions must be
>void Func(void).
>2. there is a function body defined in dynamic_fmt.c 3. there is a
>string lookup in dynamic_parser.c that is the proper function (in string
>format), and there is a function pointer to the 'right' function.
>
>In this case, DynamicFunc__append_from_last_output2_as_raw IS properly
>setup in #1 and #2 above. However, the lookup entry in dynamic_parser.c
>is NOT there. That is not good. I need to audit, and find out which
>'exported'
>functions, flags, and other data, are do NOT have proper parsing table
>entries.
>
>This function certainly does not, likely there are others which were
>missed.
>The 'raw' functions were a later addition, and it appears I did not get
>them
>properly placed into the john.conf parsing code. Simple fix, but it
>simply
>will not work as it exists today.
>
>Jim.
>
>
>>From: Matt Weir [mailto:cweir@...edu]
>>
>>Hey JimF,
>> I was trying the code you specified in your reply on the john-users
>>list, (http://www.openwall.com/lists/john-users/2012/08/17/3), and ran
>>into the following problem:
>>
>>Error, unknown function:
>>Func=DynamicFunc__append_from_last_output_to_input2_as_raw
>>Error parsing section [List.Generic:dynamic_2033] Error in line 12 file
>>is ./test_dynamic.conf
>>
>>The actual line in question is:
>>
>>Func=DynamicFunc__append_from_last_output_to_input2_as_raw
>>
>>While I see an entry for the function in the doc/DYNAMIC readme, when I
>>look at the actual code in src/dynamic_parser.c I don't see that
>>function, (or the similar function of
>>"DynamicFunc__append_from_last_output2_as_raw")
>>
>>I've tried copying/pasting the function name several times as well to
>>try and rule out any typos. This is in JtR 1.7.9-jumbo6.
>>
>>*Note I'm posting about this in john-dev since it seems like it might
>>be more of a code issue.
>>
>>Thanks,
>>Matt
>>
>>On Fri, Aug 17, 2012 at 8:16 AM, <jfoug@....net> wrote:
>>> Dev talk, brought to john-dev. I will make a non-dev follow up on
>>> john-users.
>>>
>>> On Fri, Aug 17, 2012 at 12:40 AM, Solar Designer wrote:
>>>>
>>>> On Thu, Aug 16, 2012 at 11:06:48AM -0400, Matt Weir wrote:
>>>> I thought that maybe the implementation of phpass in the dynamic
>>>> format was generic enough - but it is not. Its loop is hardcoded in
>>>> DynamicFunc__PHPassCrypt(). So it seems like the current dynamic
>>>> format is incapable of arbitrary loops. This may be something for
>>>> JimF to enhance - not for this specific target, but in general.
>>>
>>>
>>> This has been on my 'to figure out' list for several years. I would
>>> like to add looping, variables, condtional etc. But I just have not
>>> gotten down to doing this of yet. Currently, dynamic is just an
>>> array of function pointers, that is run 1 after the other. These
>>> function pointers all have exactly the same prototype: void fp(void).
>>> Then there are a few input
>>> (working) buffers, length pointers, a matching set of output (crypt)
>>> buffers, some 'CONST' buffers, a salt, a salt2, a username, and
>>> generic 'fields' buffers (fields from the input file). That is really
>>> all there is to dynamic now. Seems overly simplified, but it has
>>> allowed most of what we do for cracking hashes to be able to be done.
>>>
>>> The biggest shortcomings, are:
>>>
>>> strange input handling, like byte transposing for the 'crypt'
>>> md5/sha/sun/..., partial byte usage (like PIX), etc. These are all
>>> one-off coded.
>>> lack of simple looping (phpass, crypt* formats) lack of variables
>>> lack of dynamic parsing of variables (sunmd5, php/wordpress, or other
>>> variable round crypts) lack of conditionals (likely fits in with
>>> variables).
>>> lack of a hooking function mechanism (to add 'custom' code). This
>>> would be needed/usable for things like the coin flip in sunmd5,
>>> possibly for handling strange inputs, etc. Probably adding
>>> specialized hooks for pre-init, (post-init also??) and post-crypt
>>would be helpful.
>>>
>>> I have thought of things in the past, such as pre-processing (like
>>> macro expansion in C). This would by things like looping. It would
>>> allow for 'constant' pre-defined variables (like building phpass
>>> that does 2048 loops). This would be on the easier side of
>>> implenting. It would only require changes in the code that loads the
>>> array of
>>function pointers.
>>>
>>> The full 'enhancement' would be a very large undertaking, on an
>>> already overly complex format.
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.
