Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Aug 2012 15:22:42 -0500
From: "jfoug" <>
To: <>
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:


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).  


>-----Original Message-----
>From: jfoug []
>Sent: Monday, August 20, 2012 2:25 PM
>Subject: RE: [john-dev] Was: Re: [john-users] Cracking Gauss using
>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
>functions, flags, and other data, are do NOT have proper parsing table
>This function certainly does not, likely there are others which were
>The 'raw' functions were a later addition, and it appears I did not get
>properly placed into the john.conf parsing code.   Simple fix, but it
>will not work as it exists today.
>>From: Matt Weir []
>>Hey JimF,
>>   I was trying the code you specified in your reply on the john-users
>>list, (, and ran
>>into the following problem:
>>Error, unknown function:
>>Error parsing section [List.Generic:dynamic_2033] Error in line 12 file
>>is ./test_dynamic.conf
>>The actual line in question is:
>>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
>>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.
>>On Fri, Aug 17, 2012 at 8:16 AM,  <> 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.