-
Notifications
You must be signed in to change notification settings - Fork 2k
Commit
May be I'm too paranoid, but I wanted to make sure each format "understands" the hash format it uses for john.pot
- Loading branch information
There are no files selected for viewing
9 comments
on commit 546a203
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You may want to look at ./run/dynamic_flat_sse_formats.conf I am not sure if there are formats in there which you handled here that would benefit from same change. The dyna_flat.conf is for lower number hashes, which have sse 1 limb constraint problems, and are the same number as the lower format, but +2000
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't these formats write canonical hashes for the dyna formats < 2000 into john.pot?
They don't anymore:
(bleeding-jumbo)run $ ./john --format=dynamic_2014 --list=format-tests |cut -f 3|sort -u > h
(bleeding-jumbo)run $ ./john --format=dynamic_2014 --list=format-tests |cut -f 4-|sort -u > p
(bleeding-jumbo)run $ ./john h --wordlist=p
Loaded 3 password hashes with 3 different salts (dynamic_2014 [md5($s.md5($p).$s) (PW > 55 or salt > 11 bytes, sse2) 128/128 AVX 480x4x3])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
test1 (?)
thatsworking (?)
test3 (?)
3g 0:00:00:00 DONE (2015-01-01 12:34) 300.0g/s 300.0p/s 900.0c/s 900.0C/s test1..thatsworking
Use the "--show" option to display all of the cracked passwords reliably
Session completed
At Program Exit
MemDbg_Validate level 0 checking Passed
(bleeding-jumbo)run $ cat john.pot
$dynamic_2014$778e40e10d82a08f5377992330008cbe$aaaSXB:test1
$dynamic_2014$d6321956964b2d27768df71d139eabd2$123456:thatsworking
$dynamic_2014$1b3c72e16427a2f4f0819243877f7967$5555hh:test3
(bleeding-jumbo)run $ cat h
$dynamic_2014$1b3c72e16427a2f4f0819243877f7967$5555hh
$dynamic_2014$778e40e10d82a08f5377992330008cbe$aaaSXB
$dynamic_2014$d6321956964b2d27768df71d139eabd2$123456
That's why these formats didn't come up when I searched for formats which missed their canonical hash representation in the self tests.
BTW:
When I try to add this to the dyna 2014 self tests
Test=$dynamic_14$1b3c72e16427a2f4f0819243877f7967$5555hh:test3
the self test fails.
(bleeding-jumbo)run $ ./john --test --format=dynamic_2014
Error, invalid test line (wrong generic type): Test=$dynamic_14$1b3c72e16427a2f4f0819243877f7967$5555hh:test3
Error parsing section [List.Generic:dynamic_2014]
Error in line 192 file is ./dynamic_flat_sse_formats.conf
Will run 4 OpenMP threads
Benchmarking: dynamic_2014 [md5($s.md5($p).$s) (PW > 55 or salt > 11 bytes, sse2) 128/128 AVX 480x4x3]... (4xOMP) FAILED (valid ($dynamic_14$1b3c72e16427a2f4f0819243877f7967$5555hh))
Should this be a JtR issue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW:
When I try to add this to the dyna 2014 self tests
Test=$dynamic_14$1b3c72e16427a2f4f0819243877f7967$5555hh:test3
the self test fails.
Why would you think otherwise? dyna_14 is not dyna_2014, even if you conceptually 'think' it is.
Didn't these formats write canonical hashes for the dyna formats < 2000 into john.pot?
They don't anymore:
They never have. They are new functions. They do not work hand in hand with the lower ones. Yes, they could write them like that into the .pot file, since that file is not read to be processed, BUT if it is (like in the TS), you will now have hashes which can not be cracked, since they will be processed by lower dyna formats. So you cracked a dyna_2014 with a 75 byte password. Store is as dyna_14, and now it can not be cracked by the hash that lists it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought this has been discussed, but I must be wrong, since I can't find that discussion.
dynamic_14 and dynamic_2014 both are able to process the same raw hashes.
(bleeding-jumbo)run $ cat h
1b3c72e16427a2f4f0819243877f7967$5555hh
778e40e10d82a08f5377992330008cbe$aaaSXB
d6321956964b2d27768df71d139eabd2$123456
(bleeding-jumbo)run $ ./john h --wordlist=p --format=dynamic_14
Loaded 3 password hashes with 3 different salts (dynamic_14 [md5($s.md5($p).$s) 128/128 AVX 480x4x3])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
test3 (?)
test1 (?)
thatsworking (?)
3g 0:00:00:00 DONE (2015-01-01 15:21) 300.0g/s 300.0p/s 900.0c/s 900.0C/s test1..thatsworking
Use the "--show" option to display all of the cracked passwords reliably
Session completed
At Program Exit
MemDbg_Validate level 0 checking Passed
(bleeding-jumbo)run $ ./john h --wordlist=p --format=dynamic_2014
Loaded 3 password hashes with 3 different salts (dynamic_2014 [md5($s.md5($p).$s) (PW > 55 or salt > 11 bytes, sse2) 128/128 AVX 480x4x3])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
test3 (?)
thatsworking (?)
test1 (?)
3g 0:00:00:00 DONE (2015-01-01 15:21) 300.0g/s 300.0p/s 900.0c/s 900.0C/s test1..thatsworking
Use the "--show" option to display all of the cracked passwords reliably
Session completed
At Program Exit
MemDbg_Validate level 0 checking Passed
(bleeding-jumbo)run $ cat john.pot
$dynamic_14$1b3c72e16427a2f4f0819243877f7967$5555hh:test3
$dynamic_14$778e40e10d82a08f5377992330008cbe$aaaSXB:test1
$dynamic_14$d6321956964b2d27768df71d139eabd2$123456:thatsworking
$dynamic_2014$1b3c72e16427a2f4f0819243877f7967$5555hh:test3
$dynamic_2014$d6321956964b2d27768df71d139eabd2$123456:thatsworking
$dynamic_2014$778e40e10d82a08f5377992330008cbe$aaaSXB:test1
It would be great if you wouldn't need to re-crack hashes for dynamic_14 that have already been cracked with dynamic_2014 and vice versa.
(I know that dynamic_14 cannot crack all the hashes dynamic_2014 can crack, e.g., due to max. password length limit. But what prevemts dynamic_14 from recognizing the dynamic_2014 hashes in john.pot when using --show or when loading hashes? Most likely only the fact that nobody implemented it.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I am not that demented.
We had that discussion, at least a similar discussion, on john-dev.
http://thread.gmane.org/gmane.comp.security.openwall.john.devel/10404
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And this discussion, also on john-dev:
http://thread.gmane.org/gmane.comp.security.openwall.john.devel/10240
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, but this is aliasing, which I started on, but somewhat abandoned, due to all sorts of nuanced bugs that kept creeping up.
In no way should we modify dynamic14 to some how know about dynamic2014, or 2014 to know about 14. The alias 'concept' was good idea, but it simply had enough issues that I am not sure it will ever be solid enough to release prime time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NOTE, we 'could' add a limited alias abliilty, at least within the dynamic, and I think I probably 'could' get that solid. That is only part of the alias problem, but it is a significant part of it. I know that @magnumripper had me 'hide' some of the dynamic formats recently (the text book and self testing formats). While I am not too keen for doing that, since I think it describes for users just what 'can' be done, and if users do not see that, then they do not know how/what can be done within dyna. But one other complaint @magnumripper was that there are many dupes in dyna. Yes, there are formats that 'can' process the same hashes, and there are some dupes. But there are also some 2-class formats. One that is quicker but limited to a 55 byte input limb on SIMD, and one that is a little slower, but users FLAT buffer SIMD so does not have unreasonable length limits.
I could see adding dynamic only aliasing as a phase-1 I originally thought alias code would be a smaller undertaking. It is not. It 'really' needs to have core changes to have a couple methods added to the formats to 'help'. But instead of doing this like this, or like I was doing (which was piece meal ad-hoc), we really should address this in a an engineering design way, by asking what we have, and what we need to get the job done. (SORRY for long rant, it should be done on some other thread).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But there are also some 2-class formats. One that is quicker but limited to a 55 byte input limb on SIMD, and one that is a little slower, but users FLAT buffer SIMD so does not have unreasonable length limits.
With the current code, if you attack 1000 (bare) hashes with dynamic_1 and crack 300 of them, then try to use dynamic_2001 to crack some with longer passwords, John will load all 1000 as uncracked, right? Getting rid of such little issues would be a good enhancement.
This line causes a jtrTestSuite problem: openwall/john-tests#31