[john-users] loading OS X hashes from Davegrohl

[Eric Oyen]

Hello everyone,

as the subject says, john is giving me a fit.

here is the problem:
I dump the password hash and the shadow hash into a single file using Davegrohl (a nice little password checker tool from 2012). Both the hashes seem correct so far as I can tell. I have tried using the same file with a blank line between the passed and shadow hashes, tried to use separate files (named passed and shadow) and even tried to load the hashes directly on the command line. in all cases, john reports "no hashes loaded, see FAQ!".

unfortunately I have done everything called for, but no soap. Am I missing something.

btw, I am also totally blind here and depend on the screen reader on my old Lion OS X mac to tell me what's going on. So, if I am missing something that should be visually apparent, then that is happening.

so, what can I do here?


anyway, if anyone has any suggestions, I would certainly appreciate hearing from you.

btw, the relevant FAQ stipulates that password hashes need to be placed on their own lines inside the file. Since I am only working on 1, this should make things easy (or so I thought).

thanks,

Eric
Blind System Administrator (formerly of alt-hacker.org )

[Solar Designer]

Hello Eric,

Post by Eric Oyen
john reports "no hashes loaded, see FAQ!".

This means that either the file is not formatted as John expects it to
be, or the specific version/build of John does not support those hashes.

What version/build of John are you using?

Anyway, please try using the attached xpwdump Perl script instead of
Davegrohl. This script should produce the hashes in the correct format.

magnum, should we possibly get this into jumbo? Please feel free.

Alexander

[Eric Oyen]

ok, I am using the version that comes with macports on OS X Lion (last updated 2012). I can't get anything newer on here without a significant upgrade to the OS, which isn't possible given the age of the machine.

I will have to take a look at that script. Also, it might be time to convert this 2007 (late model 3.1 machine) to linux.

anyway, John reports it's version on this machine as 1.8.0 (which may be substantially old as far as that goes).

thanks for the info.

-eric

Post by Solar Designer
Hello Eric,

Post by Eric Oyen
john reports "no hashes loaded, see FAQ!".

This means that either the file is not formatted as John expects it to
be, or the specific version/build of John does not support those hashes.
What version/build of John are you using?
Anyway, please try using the attached xpwdump Perl script instead of
Davegrohl. This script should produce the hashes in the correct format.
magnum, should we possibly get this into jumbo? Please feel free.
Alexander
<xpwdump.pl>

[Solar Designer]

Post by Eric Oyen
anyway, John reports it's version on this machine as 1.8.0

Well, that suggests it's probably the "official" JtR, which includes
support for only a small set of hash types. It never supported OS X
hashes. For that, you need either jumbo or Pro.

You may try one of these builds:

http://download.openwall.net/pub/projects/john/contrib/macosx/

If john-1.8.0.9-jumbo-macosx_sse2.zip works for you, use that. (The
other one found in the directory now certainly won't work, needing a
newer computer than you have.) If this build refuses to start on your
OS X, go under the historical/ subdirectory for some older versions.
One of those should work.

Alexander

[Eric Oyen]

well, I tried to run that perl script you sent me and here is the output:

***


macbook:Compile proudhawk$ sudo perl xpwdump.pl
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
Hash type SALTED-SHA512 is not supported
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
Hash type SALTED-SHA512 is not supported
Warning: additional hash type SMB-NT found for user eric.
Use the -nt CLI option to dump this type of hash.
Hash type SALTED-SHA512 is not supported
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
Hash type SALTED-SHA512 is not supported
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
No such key: AuthenticationAuthority
Hash type SALTED-SHA512 is not supported
Warning: additional hash type SMB-NT found for user proudhawk.
Use the -nt CLI option to dump this type of hash.
No such key: AuthenticationAuthority
Hash type SALTED-SHA512 is not supported
No such key: AuthenticationAuthority
Hash type SALTED-SHA512 is not supported
No such key: AuthenticationHint
Cannot open /private/var/db/shadow/hash/333223CF-BE81-44BC-95C9-6A3C4BA13D37: No such file or directory
There is no hashes available for the user proudhawk
Cannot open /private/var/db/shadow/hash/F7D3F545-5DD8-4D89-9132-E16AF0BE8639: No such file or directory
There is no hashes available for the user eric

Post by Solar Designer
Hello Eric,

Post by Eric Oyen
john reports "no hashes loaded, see FAQ!".

This means that either the file is not formatted as John expects it to
be, or the specific version/build of John does not support those hashes.
What version/build of John are you using?
Anyway, please try using the attached xpwdump Perl script instead of
Davegrohl. This script should produce the hashes in the correct format.
magnum, should we possibly get this into jumbo? Please feel free.
Alexander
<xpwdump.pl>

[Solar Designer]

I don't know why it failed, and especially these messages are weird,

Post by Eric Oyen
Cannot open /private/var/db/shadow/hash/333223CF-BE81-44BC-95C9-6A3C4BA13D37: No such file or directory
There is no hashes available for the user proudhawk
Cannot open /private/var/db/shadow/hash/F7D3F545-5DD8-4D89-9132-E16AF0BE8639: No such file or directory
There is no hashes available for the user eric

However, have you tried using a different version/build of John as I
suggested in another message? The version you said you had tried first
doesn't support OS X hashes at all.

Also, what is the input file you provide to John (with the hash(es)
obtained from Davegrohl) like? It should be something like:

user:12345678F9083C7F66F46A0A102E4CC17EC08C8AF120571B

That is, username followed by a colon followed by some hex digits.
Is this the case? How many hex digits are there in your case?

For the above example, you crack it with the "--format=xsha" option
provided to a version of John supporting OS X hashes, such as one of
those you download from:

http://download.openwall.net/pub/projects/john/contrib/macosx/

For your older OS X, you'll need to take a version from the "historical"
subdirectory.

BTW, why are you doing this? Is it just for fun and learning, or do you
need this password recovered (and why)? Since you seem to be able to
use the system and even access the root account with sudo, you probably
do know the password(s) anyway? I am asking just so that we might help
you achieve your ultimate goal, rather than an intermediate one.

Alexander

[Eric Oyen]

well, the file was formatted with user:hash from the davegrohl output (using both -passwd and -shadow options).

Also, I checked the directory in question after getting the inconsistent output from that perl script. It appears that the folder referenced under /private/var/db didn't exist. so, I am at a loss as to why davegrohl could get a full hash dump.

also, the SSE2 version of john in the site you provided failed with an illegal instruction 4. so, I will try the V3 version. If that fails, then I will go into the historical folder and find a version consistent with my current OS.

Also, as reported in another email, I was able to dump hashes and salts using the dscl command. I don't know if that will work or not. However, I am willing to give it a try.

-eric

PGP fingerprint: 6DFB D6B0 3771 90F1 373E 570C 7EA2 1FF3 6B68 0386

Post by Solar Designer
I don't know why it failed, and especially these messages are weird,

Post by Eric Oyen
Cannot open /private/var/db/shadow/hash/333223CF-BE81-44BC-95C9-6A3C4BA13D37: No such file or directory
There is no hashes available for the user proudhawk
Cannot open /private/var/db/shadow/hash/F7D3F545-5DD8-4D89-9132-E16AF0BE8639: No such file or directory
There is no hashes available for the user eric

However, have you tried using a different version/build of John as I
suggested in another message? The version you said you had tried first
doesn't support OS X hashes at all.
Also, what is the input file you provide to John (with the hash(es)
user:12345678F9083C7F66F46A0A102E4CC17EC08C8AF120571B
That is, username followed by a colon followed by some hex digits.
Is this the case? How many hex digits are there in your case?
For the above example, you crack it with the "--format=xsha" option
provided to a version of John supporting OS X hashes, such as one of
http://download.openwall.net/pub/projects/john/contrib/macosx/
For your older OS X, you'll need to take a version from the "historical"
subdirectory.
BTW, why are you doing this? Is it just for fun and learning, or do you
need this password recovered (and why)? Since you seem to be able to
use the system and even access the root account with sudo, you probably
do know the password(s) anyway? I am asking just so that we might help
you achieve your ultimate goal, rather than an intermediate one.
Alexander

[Solar Designer]

Post by Eric Oyen
also, the SSE2 version of john in the site you provided failed with an illegal instruction 4. so, I will try the V3 version.

If the "SSE2" version fails like that, then it's not actually SSE2 -
it's probably more like SSE4. Your Core 2 Duo supports up through SSSE3
inclusive, but not SSE4. These are recent user-contributed builds, so
it's likely that the contributor didn't consider recent macOS'
assumption that SSE4 has to be available for that OS anyway.

"V3" certainly won't work on your computer - it needs even newer (AVX).

I went ahead and renamed the files as follows:

mv john-1.8.0.9-jumbo-macosx_v3.zip john-1.8.0.9-jumbo-macosx_avx.zip
mv john-1.8.0.9-jumbo-macosx_sse2.zip john-1.8.0.9-jumbo-macosx_sse4.zip

based on user reports so far. Maybe this will help reduce further
confusion, although few users appear to know what AVX and SSE4 are.

Post by Eric Oyen
If that fails, then I will go into the historical folder and find a version consistent with my current OS.

Right.

Please try to post fewer messages - try multiple things at a time, then
post. We're bothering a lot of people with this discussion right now.
That's what this list is for, so the "bothering" is OK, but grouping the
information in fewer messages is preferable.

Post by Eric Oyen
according to the website (that incidentally references open wall as well) the dscl command as issued should dump the salt and hash in a file in that order. it also seems to get a lot of other stuff (like hint, etc).

Yes, it did dump a lot of stuff, but not what we needed.

Post by Eric Oyen
btw, I do know that the salt is SHA512.

You mean the hash. Yes, it should be, but we haven't seen it yet, nor
its corresponding salt.

Post by Eric Oyen
so, I am not sure what is going on. everything I try here seems to work,

None of this has dumped the hash yet, as far as I can tell.

Post by Eric Oyen
but the results don't conform to what john expects.

They were not supposed to be directly usable with John, except for
xpwdump's output, but that one failed for unknown reasons. Possibly
something is corrupted on the system.

Do you have anything under /private/var/db/shadow/hash at all? For
example, try this command:

ls -R /private/var/db/shadow/hash

Post by Eric Oyen
btw, did I mention that being totally blind and trying this really sucks ass!

You didn't mention how you felt about that. Sorry to hear it's this way.

Back to one of my previous questions: why are you doing this? Aren't
you able to access the system anyway? What's your ultimate goal?

Alexander

[Eric Oyen]

ok, I had to do a little google search. A command turned up I can use called dscl. so I used dscl to dump both the salts and hashes for each user on my system. The command went like this: sudo dscl localhost read Search/Users/<username> >> <Username.txt>

this dumped what appears to be proper data into those files. now all I need to do is run the jumbo supported john on them.

I just hope this works.

-eric



PGP fingerprint: 6DFB D6B0 3771 90F1 373E 570C 7EA2 1FF3 6B68 0386

Post by Solar Designer
Hello Eric,

Post by Eric Oyen
john reports "no hashes loaded, see FAQ!".

This means that either the file is not formatted as John expects it to
be, or the specific version/build of John does not support those hashes.
What version/build of John are you using?
Anyway, please try using the attached xpwdump Perl script instead of
Davegrohl. This script should produce the hashes in the correct format.
magnum, should we possibly get this into jumbo? Please feel free.
Alexander
<xpwdump.pl>

[Solar Designer]

Post by Eric Oyen
ok, I had to do a little google search. A command turned up I can use called dscl. so I used dscl to dump both the salts and hashes for each user on my system. The command went like this: sudo dscl localhost read Search/Users/<username> >> <Username.txt>

The "dscl" command is what that Perl script uses internally. I don't
know why the script would fail for you if the manual command works.

Post by Eric Oyen
this dumped what appears to be proper data into those files. now all I need to do is run the jumbo supported john on them.

Great. Right.

Alexander

[Eric Oyen]

ok, the V3 version command also failed with "illegal instruction 4" inside the john/run folder.

it also generated this output in problem reporter:
***
Process: bash [38503]
Path: /bin/bash
Identifier: bash
Version: ??? (???)
Code Type: X86-64 (Native)
Parent Process: bash [38152]

Date/Time: 2018-04-23 04:11:39.762 -0700
OS Version: Mac OS X 10.7.5 (11G63)
Report Version: 9

Interval Since Last Report: -118598267 sec
Crashes Since Last Report: -46
Per-App Crashes Since Last Report: 3
Anonymous UUID: DA2AAE55-9DAE-4251-9CB2-E442878C9B7B

Crashed Thread: Unknown

Exception Type: EXC_BAD_ACCESS (SIGILL)
Exception Codes: KERN_INVALID_ADDRESS at 0x00007fff5fc01028

Backtrace not available

Unknown thread crashed with X86 Thread State (64-bit):
rax: 0x0000000000000055 rbx: 0x0000000000000000 rcx: 0x0000000000000000 rdx: 0x0000000000000000
rdi: 0x0000000000000000 rsi: 0x0000000000000000 rbp: 0x0000000000000000 rsp: 0x0000000000000000
r8: 0x0000000000000000 r9: 0x0000000000000000 r10: 0x0000000000000000 r11: 0x0000000000000000
r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x0000000000000000 r15: 0x0000000000000000
rip: 0x00007fff5fc01028 rfl: 0x0000000000010203 cr2: 0x00007fff5fc01028
Logical CPU: 0

Binary images description not available


External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 10591
thread_create: 0
thread_set_state: 0

Model: MacBook3,1, BootROM MB31.008E.B02, 2 processors, Intel Core 2 Duo, 2.2 GHz, 4 GB, SMC 1.24f3
Graphics: Intel GMA X3100, GMA X3100, Built-In, 144 MB
Memory Module: BANK 0/DIMM0, 2 GB, DDR2 SDRAM, 667 MHz, 0x7F98000000000000, 0x393930353239352D3034352E4130314C4600
Memory Module: BANK 1/DIMM1, 2 GB, DDR2 SDRAM, 667 MHz, 0x7F98000000000000, 0x393930353239352D3034352E4130314C4600
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x88), Broadcom BCM43xx 1.0 (5.10.131.36.15)
Bluetooth: Version 4.0.8f17, 2 service, 11 devices, 1 incoming serial ports
Network Service: Ethernet, Ethernet, en0
Network Service: Wi-Fi, AirPort, en1
Serial ATA Device: Hitachi HTS542525K9SA00, 250.06 GB
Parallel ATA Device: HL-DT-ST DVDRW GSA-S10N
USB Device: USB 2.0 Hub [MTT], 0x050d (Belkin Corporation), 0x0237, 0xfd100000 / 3
USB Device: iPhone, apple_vendor_id, 0x12a8, 0xfd110000 / 7
USB Device: Expansion Desk, 0x0bc2 (Seagate LLC), 0x3312, 0xfd150000 / 8
USB Device: External USB 3.0, 0x0480 (Toshiba America Info. Systems, Inc.), 0x0110, 0xfd140000 / 6
USB Device: External USB 3.0, 0x0480 (Toshiba America Info. Systems, Inc.), 0xd011, 0xfd170000 / 5
USB Device: iPhone, apple_vendor_id, 0x12a8, 0xfd120000 / 4
USB Device: Built-in iSight, apple_vendor_id, 0x8501, 0xfd400000 / 2
USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0229, 0x5d200000 / 3
USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x5d100000 / 2
USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8205, 0x1a100000 / 2

Post by Solar Designer

Post by Eric Oyen
ok, I had to do a little google search. A command turned up I can use called dscl. so I used dscl to dump both the salts and hashes for each user on my system. The command went like this: sudo dscl localhost read Search/Users/<username> >> <Username.txt>

The "dscl" command is what that Perl script uses internally. I don't
know why the script would fail for you if the manual command works.

Post by Eric Oyen
this dumped what appears to be proper data into those files. now all I need to do is run the jumbo supported john on them.

Great. Right.
Alexander

[Eric Oyen]

This post might be inappropriate. Click to display it.

[Eric Oyen]

ok, this is getting frustrating. the john command tells me that no hashes were loaded (see faq's). grrrr. that is the 1.7.9 jumbo version.

btw, I will include a copy of one of the files so that you might take a look.

Post by Solar Designer

Post by Eric Oyen
ok, I had to do a little google search. A command turned up I can use called dscl. so I used dscl to dump both the salts and hashes for each user on my system. The command went like this: sudo dscl localhost read Search/Users/<username> >> <Username.txt>

The "dscl" command is what that Perl script uses internally. I don't
know why the script would fail for you if the manual command works.

Post by Eric Oyen
this dumped what appears to be proper data into those files. now all I need to do is run the jumbo supported john on them.

Great. Right.
Alexander

[Solar Designer]

Eric,

Post by Eric Oyen
ok, this is getting frustrating. the john command tells me that no hashes were loaded (see faq's). grrrr. that is the 1.7.9 jumbo version.
btw, I will include a copy of one of the files so that you might take a look.

Well, this file is:

1. Not of the correct format for John. Like I said, you need username,
colon, hash all on one line.

2. Does not contain the salt+hash that you'd need to crack the password.
(It contains a related raw SHA-1 hash, but that's not exactly it.)

Alexander

[Eric Oyen]

wonderful.

according to the website (that incidentally references open wall as well) the dscl command as issued should dump the salt and hash in a file in that order. it also seems to get a lot of other stuff (like hint, etc).

btw, I do know that the salt is SHA512.

so, I am not sure what is going on. everything I try here seems to work, but the results don't conform to what john expects.

-eric

PGP fingerprint: 6DFB D6B0 3771 90F1 373E 570C 7EA2 1FF3 6B68 0386

Post by Solar Designer
Eric,

Post by Eric Oyen
ok, this is getting frustrating. the john command tells me that no hashes were loaded (see faq's). grrrr. that is the 1.7.9 jumbo version.
btw, I will include a copy of one of the files so that you might take a look.

1. Not of the correct format for John. Like I said, you need username,
colon, hash all on one line.
2. Does not contain the salt+hash that you'd need to crack the password.
(It contains a related raw SHA-1 hash, but that's not exactly it.)
Alexander

[Eric Oyen]

btw, did I mention that being totally blind and trying this really sucks ass!

-eric

PGP fingerprint: 6DFB D6B0 3771 90F1 373E 570C 7EA2 1FF3 6B68 0386

Post by Solar Designer
Eric,

Post by Eric Oyen
ok, this is getting frustrating. the john command tells me that no hashes were loaded (see faq's). grrrr. that is the 1.7.9 jumbo version.
btw, I will include a copy of one of the files so that you might take a look.

1. Not of the correct format for John. Like I said, you need username,
colon, hash all on one line.
2. Does not contain the salt+hash that you'd need to crack the password.
(It contains a related raw SHA-1 hash, but that's not exactly it.)
Alexander