[<prev] [next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP33797F85A2B34CB1CD143E0FDB10@phx.gbl>
Date: Wed, 8 Jan 2014 11:02:24 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: ./john --fork=4 --session=x and ./john --restore=x.3
I think the handling of .rec files <session_name>.<n>.rec created with
--fork=n should be improved.
Consider this test:
$ ./john --fork=4 --format=nt --session=nt nt --incremental=upper
Loaded 43 password hashes with no different salts (NT [MD4 128/128 SSE2
+ 32/32])
Node numbers 1-4 of 4 (fork)
Press 'q' or Ctrl-C to abort, almost any other key for status
1 0g 0:00:00:08 0.00% 0g/s 944992p/s 944992c/s 40634KC/s BJIXD..BJBMJ
4 0g 0:00:00:08 0.00% 0g/s 1002Kp/s 1002Kc/s 43086KC/s AAAHAEL..AAAHALI
3 0g 0:00:00:08 0.00% 0g/s 971995p/s 971995c/s 41795KC/s EVRYOD..EVRYCH
2 0g 0:00:00:08 0.00% 0g/s 1007Kp/s 1007Kc/s 43337KC/s CHNTRYD..CHNXAIE
2 0g 0:00:00:21 0.00% 0g/s 1034Kp/s 1034Kc/s 44501KC/s LARBOYJ..LARBHRN
1 0g 0:00:00:21 0.00% 0g/s 1005Kp/s 1005Kc/s 43230KC/s AGUWYR..AGUWDX
Waiting for 3 children to terminate
4 0g 0:00:00:21 0.00% 0g/s 1037Kp/s 1037Kc/s 44596KC/s COLYLXZ..COLGHAS
3 0g 0:00:00:21 0.00% 0g/s 1032Kp/s 1032Kc/s 44382KC/s ASDNSSE..ASDNSUI
Session aborted
$ wc -l nt.log
1861 nt.log
$ ./john --restore=nt[tab][tab]
nt nt.2 nt.3 nt.4
I think it would be better if bash completion would only list nt, not
nt.2 - nt.4.
I could live with the fact that completion wouldn't list a session nt.2
if it was created like this:
$ ./john --format=nt --session=nt.2 nt --incremental=upper
But since restoring just session nt.2 "works" (for a certain definition
of "working"), I canÄt do this yet.
$ ./john --restore=nt.3
Loaded 43 password hashes with no different salts (NT [MD4 128/128 SSE2
+ 32/32])
Node numbers 1-4 of 4 (fork)
2 Session completed
3 Session completed
4 Session completed
Press 'q' or Ctrl-C to abort, almost any other key for status
1 0g 0:00:00:27 0.00% 0g/s 1631Kp/s 1631Kc/s 70135KC/s DEETHERI..DEETHEWS
1 0g 0:00:00:29 0.00% 0g/s 1738Kp/s 1738Kc/s 74761KC/s HUFZCD..HUFHJH
Waiting for 3 children to terminate
Session aborted
IMHO, restoring nt.3 should not be allowed, because of
$ grep session nt.2.rec
--session=nt
$ wc -l nt.log
1937 nt.log
$ tail -n +1862 nt.log
1 0:00:00:22 Continuing an interrupted session
1 0:00:00:22 Loaded a total of 43 password hashes with no different salts
1 0:00:00:22 - Node numbers 1-4 of 4 (fork)
2 0:00:00:22 No crash recovery file, terminating
1 0:00:00:22 Continuing an interrupted session
1 0:00:00:22 Loaded a total of 43 password hashes with no different salts
1 0:00:00:22 - Node numbers 1-4 of 4 (fork)
1 0:00:00:22 Continuing an interrupted session
1 0:00:00:22 Loaded a total of 43 password hashes with no different salts
1 0:00:00:22 - Node numbers 1-4 of 4 (fork)
1 0:00:00:22 - Hash type: NT (lengths up to 27)
1 0:00:00:22 - Algorithm: MD4 128/128 SSE2 + 32/32
1 0:00:00:22 - Candidate passwords will be buffered and tried in chunks
of 40
1 0:00:00:22 - Configured to use otherwise idle processor cycles only
1 0:00:00:22 Proceeding with "incremental" mode: upper
1 0:00:00:22 - Lengths 1 to 13, up to 26 different characters
3 0:00:00:22 No crash recovery file, terminating
1 0:00:00:22 Continuing an interrupted session
1 0:00:00:22 Loaded a total of 43 password hashes with no different salts
1 0:00:00:22 - Node numbers 1-4 of 4 (fork)
4 0:00:00:22 No crash recovery file, terminating
1 0:00:00:22 - Switching to length 5
1 0:00:00:22 - Expanding tables for length 5 to character count 25
1 0:00:00:22 - Trying length 5, fixed @1, character count 25
...
1 0:00:00:29 - Switching to length 6
1 0:00:00:29 - Expanding tables for length 6 to character count 24
1 0:00:00:29 - Trying length 6, fixed @6, character count 21
1 0:00:00:29 Waiting for 3 children to terminate
1 0:00:00:29 Session aborted
What is surprizing here is:
What has been node number 3 is now node number 1.
Node 1, not node 3 continues to work, nodes 2, 3, 4 terminated with log
messages "No crash recovery file, terminating".
$ ./john --restore=nt
Loaded 43 password hashes with no different salts (NT [MD4 128/128 SSE2
+ 32/32])
Node numbers 1-4 of 4 (fork)
Press 'q' or Ctrl-C to abort, almost any other key for status
1 0g 0:00:00:22 0.00% 0g/s 1050Kp/s 1050Kc/s 45153KC/s KAIOVJ..KANVEU
3 0g 0:00:00:30 0.00% 0g/s 1714Kp/s 1714Kc/s 73703KC/s COAMOAM..COAMEDU
4 0g 0:00:00:22 0.00% 0g/s 1080Kp/s 1080Kc/s 46463KC/s PRRMPMA..PRRTSER
2 0g 0:00:00:22 0.00% 0g/s 1079Kp/s 1079Kc/s 46427KC/s GRSEGGZ..GRSUCAP
And now, node 3 is 8 seconds ahead of the others, and node 1 will create
new log entries with time stamps 0:00:00:22 - 0:00:00:29 that have
already been used by ./john --restore=nt.3
Another funny observation:
$ ./john --session=nt.4 nt --incremental=uppernum --format=nt
Loaded 43 password hashes with no different salts (NT [MD4 128/128 SSE2
+ 32/32])
Remaining 32 password hashes with no different salts
Press 'q' or Ctrl-C to abort, almost any other key for status
0g 0:00:00:00 0g/s 168525p/s 168525c/s 5392KC/s 2223122..01011111
0g 0:00:00:02 0g/s 1138Kp/s 1138Kc/s 36439KC/s 9B3TEN..9B3T02
0g 0:00:00:04 0g/s 1502Kp/s 1502Kc/s 48080KC/s 4436372..4433367
$ md5sum nt.4.rec
e8cf6a183c4f9ddd80f07198d228c4ed nt.4.rec
$ ./john --restore=nt
Loaded 43 password hashes with no different salts (NT [MD4 128/128 SSE2
+ 32/32])
Remaining 32 password hashes with no different salts
Node numbers 1-4 of 4 (fork)
Inconsistent crash recovery file: nt.4.rec
Press 'q' or Ctrl-C to abort, almost any other key for status
1 0g 0:00:01:16 0.00% 0g/s 1041Kp/s 1041Kc/s 41954KC/s ZWHVYL..ZWHVVU
3 0g 0:00:01:24 0.00% 0g/s 1284Kp/s 1284Kc/s 52787KC/s RUBNNGI..RUBNBHA
2 0g 0:00:01:17 0.00% 0g/s 1045Kp/s 1045Kc/s 42338KC/s MALUIDO..MALUIME
0g 0:00:00:06 0g/s 1280Kp/s 1280Kc/s 40972KC/s 10250355..10250492
0g 0:00:00:10 0g/s 1135Kp/s 1135Kc/s 36345KC/s 7949269..7951889
1 0g 0:00:01:20 0.00% 0g/s 1047Kp/s 1047Kc/s 41718KC/s CYTHKYLE..CYTHKYRD
2 0g 0:00:01:21 0.00% 0g/s 1049Kp/s 1049Kc/s 41998KC/s DUVUTEE..DUVUTYA
3 0g 0:00:01:28 0.00% 0g/s 1275Kp/s 1275Kc/s 51976KC/s GUBLIDM..GUBLEKY
2 0g 0:00:01:22 0.00% 0g/s 1051Kp/s 1051Kc/s 41972KC/s FUJJBON..FUJJBUL
1 0g 0:00:01:21 0.00% 0g/s 1049Kp/s 1049Kc/s 41670KC/s BBSHUENG..BBSHUECI
Waiting for 3 children to terminate
3 0g 0:00:01:30 0.00% 0g/s 1260Kp/s 1260Kc/s 51243KC/s KIMUFKI..KIMUYCA
0g 0:00:00:12 0g/s 1030Kp/s 1030Kc/s 32975KC/s ADOU23..ADES06
Session aborted
$ md5sum nt.4.rec
2e71677760fbfda453810d5509f4442f nt.4.rec
So, john recognized that nt.4.rec is no the right recovery file.
Nevertheless, it continued the processing the 3 remaining forked nodes,
plus the other session, writing all into the same log file.
I think, in such a case, john should either just continue those sessions
with a consistent crash recovery file, leaving nt.4 untouched.
(After all, the correct nt.4 node could have been finished.)
Or, it should refuse to proceed at all.
(The user could then decide what to do with the nt.4.rec file...)
To fix this situation, I suggest the following changes:
1.
./john --session=something.<number> shouldn't be allowed anymore
(invalid session name).
2.
./john --restore=something.<number> should only be allowed if the
session name listed in the .rec file matches the .rec file name, i.e.,
if that file had been created by ./john --session=xxx.4 ...
(Otherwise people woudn't be able to restore such sessions created with
older john versions.)
3.
Bash completion will ignore any name.<n>.rec file for completion of
$ ./john --restore=
(<n> is any sequence of digits)
4.
John should refuse restoring forked sessions if there is one
inconsistent crash recovery file, and just print an error message.
Any thoughts? Did I miss something?
Frank
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.
