[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 19 Sep 2011 20:03:06 -0400
From: David Jones <jonesd@...umbus.rr.com>
To: john-dev@...ts.openwall.com
Cc: David Jones <jonesd@...umbus.rr.com>
Subject: Re: Patch for dynamically loaded formats
On Sep 19, 2011, at 11:58 AM, Solar Designer wrote:
> David,
>
> I finally took a closer look at your stuff
> (john_1.7.8.jumbo6.plugin.diff and jtr_vms_2-3.zip on the wiki).
Thanks, your feedback is much appreciated.
> On Mon, Sep 05, 2011 at 11:55:04PM -0400, David Jones wrote:
>> Actually, I wasn't aware of compile-time plugins. I did the initial work for this enhancment a couple years ago on John 1.7.3.1, and earlier this summer decided to revisit it to update it for the official 1.7.8 release, not -jumbo. It appears the compile-time stuff assumes the module is a single source file, I have to consolidate 5 or so source files to follow that format. The project also includes a piece that lives on OpenVMS, i.e. the uaf_to_passwd program to convert the native password hash data to a ciphertext suitable for JtR to process.
>
> I think this would be best integrated into -jumbo fully, not even as a
> compile-time plugin. Then you don't need to merge any source files.
> uaf_to_passwd should probably become uaf2john, and be compiled/installed
> alongside ssh2john, etc. If it may only be compiled on VMS natively (I
> did not verify if this is the case or not), then only refer to it from
> the proper DCL scripts. You're not using the Makefile when building on
> VMS, right?
Yes, the Makefile only builds the vms_fmt dynamic library. The DCL scripts are generated from the MMS description file (descip.mms, which mostly follows makefile syntax) when the zip file is built.
I use the documented method to access the user account information (SYS$GETUAI()) and don't attempt to directly read the underlying file, SYSUAF.DAT. SYSUAF.DAT is not a flat file and stores binary data, so getting a clean transfer to a Unix-like system can be problematic.
> We can't afford making pthreads mandatory, but your code appears to
> support building without pthreads as well, correct?
Yes, compiling without pthread support forces the degenerate case of 0 worker threads so all work gets done by the main thread. Processing the request list may or may be straight forward with OpenMP, I don't know that interface.
> BTW, in vms_fmt.c you set MIN_KEYS_PER_CRYPT to SINGLE_HASH_MIN. This
> looks wrong to me: for "single crack" mode, the equivalent of this is
> ...
>
> Also, I think you shouldn't be setting FMT_BS - you don't have a
> bitslice implementation there.
OK, I was guessing.
>
> Regarding "FMT_CASE | FMT_8_BIT", are you only supporting a hash type
> for which this is right? As your aaareadme.txt says, some VMS hash
> types were not case-sensitive - are you not supporting those? I think
> it'd be best to integrate support for them as well (using Jean-loup
> Gailly's code?), but as separate formats (so that we can set the flags
> right). What do you think? Indeed, we can and should integrate any
> extras like this separately.
Case sensitivity and the symbol space are set on a per account basis, controlled by a flag bit (PWDMIX) in the user's SYSUAF record. On a single system, some users can have case insensitive passwords from a limited character set while others can have mixed case with any printable character. The format string generated in uaf_encode.c includes the state of the PWDMIX bit so the hash can be generated correctly for any password. The hash really isn't any different, it's just whether you begin with a conversion to upper case and check for out of range characters or leave as is.
I could generate different tags based upon PWDMIX, but that would mean tracking 2 separate fmt_main structs. In the pseudo-homedir field output by uaf_to_passwd, accounts with PWDMIX set begin with /Users while accounts with case insensitive passwords begin with /USERS. I was thinking that would facilitate splitting up the input file for processing by different rule sets.
>>Dave
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.
