[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110919155802.GA29125@openwall.com>
Date: Mon, 19 Sep 2011 19:58:02 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Patch for dynamically loaded formats
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).
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?
A drawback is that we lose the test case for runtime plugins, but
perhaps we can provide a sample one, just to show how this is done - for
use by people preparing further plugins for stuff that's not in -jumbo
at the time?
We can't afford making pthreads mandatory, but your code appears to
support building without pthreads as well, correct?
> The module is naturally multi-threaded, but I disabled it
We're currently using OpenMP and not explicit pthreads elsewhere in JtR,
so it'd be best to use that. But we can make this change later (after
integration of your code).
> since I didn't know a simple way to test for the presence of pthread support.
Assuming that you don't switch to using OpenMP yet, you can replace your
NOPTHREADS with HAVE_PTHREADS (the opposite meaning), then add -lpthread
-DHAVE_PTHREADS only in make targets where pthreads are known to be
available (since we use a make target per target platform).
Overall, I feel that you should have contributed your stuff earlier -
before adding parallelization, etc. Then it would be easier to integrate
and then update incrementally.
But let's try to integrate what you already have.
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
done automatically, and for other modes the value of SINGLE_HASH_MIN is
irrelevant. If your code reasonably supports MIN_KEYS_PER_CRYPT of as
low as 1, just set it to that. Or set it to the number of threads, when
applicable.
Also, I think you shouldn't be setting FMT_BS - you don't have a
bitslice implementation there.
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.
Oh, and many source files say that they are copyrighted by me (as well
as by you), but I don't recognize any of the code in them as mine.
If this is just for the overall source file structure (such as what
kinds of functions are defined and in what order), then I think this is
not subject to copyright - so let's drop those notices (keep the files
copyrighted by you only).
Thanks,
Alexander
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.
