[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120725195248.GA10288@debian>
Date: Wed, 25 Jul 2012 23:52:48 +0400
From: Aleksey Cherepanov <aleksey.4erepanov@...il.com>
To: john-dev@...ts.openwall.com
Subject: Aleksey's status report #13
I missed two previous status reports. So this one covers two weeks. I
am sorry.
During these weeks I rewrote file management system to use scp and to
be extensible. Currently it makes clients to download only files that
are needed for some attack (not all files available like before).
Possible improvement and extensions are already described. Also it
could useful to think about what to do we are offline: use old files
that we already have or give up and abort?
When client starts an attack mjohn checks it to be unique. For not old
the same attack it shows its old name. For that I get sha1 from
parameters passed to john (except cosmetic parameters). MJohn replaces
file names with sha1 from files so sha1 from parameters also takes
files listed in options into account. Problems here: I do not handle
defaults for options (for instance -i), I do not handle config file
(but Frank wrote a patch for john to simplify this).
I got (near) working restore functionality: user could start attack by
name. Problems here: I exclude cosmetic options (at this time:
dupe-suppression save-memory mem-file-size crack-status mkpc length
fix-state-delay) from attack (so they are not in 'parameters' file on
the server) but I pass them to john so they are .pot files and if
client restores session he gets parameters from other user and it is
hard to exclude that parameters from .rec for exchange, also it is
hard to include other or new cosmetic parameters.
And as a minor related problem: there are path to .pot and to .rec
itself in the session. It is important when we clone session (to
restore it then). Currently I modify .rec to adjust these values:
open $f, '<', "$run_name.rec" or die "could not read";
my @lines = <$f>;
close $f;
for (@lines) {
s/^(--session=|--pot=)\Q$best_session\E/$1$run_name/;
}
# TODO: could not I do it in one open?
open $f, '>', "$run_name.rec" or die "could not write";
print $f @lines;
close $f;
Later I plan to use separate folders to run john, work right there and
always name .pot like ./john.pot and session like ./john.rec so I will
be able to clone session just copying its folder.
But till that I'd say it is only *seems* to work. So Frank pointed me
out to disable it and allow only restore on the same client (others
will be able to start that attack from the begin).
I faced a problem how to refer to file with hashes. Easy way is to
have constant files and refer to them and remove file when it is
totally cracked. But for salted hashes it is not fast if we use new
empty .pot for session so we need to merge all pots together and use
them. But merged .pot means slow start of john. Also we need to merge
them right before attack for perfect results but we could reduce pot
updates to one centralized update each N minutes (or even hours).
Other way is to track uncracked hashes. Being not sure how to refer to
them. I assumed the contest environment with such files generated by
server: currently user specifies format (it does not included in
attack description, so attack is formatless) to mjohn and mjohn gets
latest uncracked from the server, not tracking files well I just copy
them into folder with attack (it eats disk space obviously): I think I
could reduce amount of copies referring by sha1, also it could be
worth to refer to old file if there is less than N minutes since its
creation (so server could update files often as it wants but mjohn
does not follow that strictly).
Currently cloned/restored sessions use the same hash file as original
session.
I got a question: could I restore a session with other (reduced) hash
file? It could be worth in case of salted hashes (together with big
attack somewhere at the half of wordlist; in other cases it could be
better to just restart attack with new session).
It seems there are many actions I would like to perform that are tight
to ability to start attack from some point, not the begin. Something
like percentages for markov mode. Adding an ability to get a status in
percentages I'd be able to do a high-level restoration of attack. Also
it would provide an ability to split an attack into pieces.
Though it is not very important right now.
Currently MJohn stops if user supplies any of: config stdin pipe
restore session make-charset status show stdout test users groups
shells salts pot format list nolog max-run-time plugin help subformat
field-separator-char log-stderr. Some of that options should be just
passed to john without any special handling (help, list) while others
are used by mjohn itself (session, pot) or should be supported by
mjohn in special ways (for instance 'show' should work in conjunction
with option to specify attack name because it should pass 'pot' option
to john).
I missed testing during mini contest. And most of planned
functionality is very far from suitable state if exist at all. So I
think MJohn will be of little use during the contest. It seems that
the biggest but realistic goal is to make it stable enough to track
all attacks during the contest.
This goal misses some important parts: config should be saved, all
options should be handled and stored right (mjohn should support all
options and do all work option needs (for instance 'incremental'
without argument needs to store default .chr file)). In general
MJohn should be robust and convenient.
Convenience needs documentation. One of primary tasks is to write
(even minimal) documentation, prepare examples at least one day before
the contest.
Current code is attached.
Done
- scp copying
- avoiding same attacks
- attack start and restore for simple case
Priorities
- disable dangerous session restoration,
- prepare draft of example how to start attacks,
- write support for all options involved into attacks (though without
'pipe' option),
- adjust examples,
- post them.
Thanks!
--
Regards,
Aleksey Cherepanov
View attachment "u.pl" of type "text/x-perl" (34236 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.
