0

I have an embedded device running Armbian which I was able to get the drive image from. The entry in /etc/shadow combined with /etc/passwd after unshadowing is this:

root:$6$TV6ML2bG$TncnN/adtU9xaQs/OpmkWzpMIGuYexLf.timEI28P5RIPn5xjKRu.aibfgss2OdXoyXK.Dhh3yQPAsRHQLx.1/:0:0:root:/root:/bin/bash

I am just learning JtR now (and Unix in general). I have found most of the documentation very good with JtR, and perhaps I'm not asking the right question, but what do I do about the salt in this?

If I use the following command:

john john-input2 --wordlist=manyword.txt --format=SHA512crypt-opencl -dev=gpu

Will JtR automatically account for the salt + hash, or will it fail to ever find the correct password, even if it is present in the manyword.txt file because of the salt being unaccounted for?

I come here as my last resort as hours of searching has not led me to the answer.

2
  • 1
    Have you tried looking at pentestmonkey.net/cheat-sheet/john-the-ripper-hash-formats for some inspiration and seeing if you can use one of the formats here on a test hash? If I were you I would see if you can test this with creds and a salt you already know. If you are not able to test then you could also try running dynamic scripts in John. Commented Jul 6, 2021 at 9:20
  • 1
    Great suggestion, thank you. I'll do a baseline to make sure the process is going as expected, the whole salt comment on openwall is very confusing to me, and I can't find anywhere that confirms/denies that salt is automatically factored for by JtR. Will try a verification of both to see if it is actually doing so without the --salt being included in the string.
    – Nubtastic
    Commented Jul 6, 2021 at 9:32

2 Answers 2

2

Will JtR automatically account for the salt + hash, or will it fail to ever find the correct password, even if it is present in the manyword.txt file because of the salt being unaccounted for?

But the salt is accounted for - it's right there in your password string, which breaks down using $ as a delimiter like such:

root:$6$NP3vF5ciATM7Ng3u$oB.k/TPp8VTuE.3H/YvzTRjZymnIEdladJemXKn8iV4B1IeTwxsbvyMEuxzXsupp3/cSRWdAG6O6aYFyBu4aB/
Field Value
User root
Hash format 6 (SHA-512)
Salt NP3vF5ciATM7Ng3u
Password hash oB.k/TPp8VTuE.3H/YvzTRjZymnIEdladJemXKn8iV4B1IeTwxsbvyMEuxzXsupp3/cSRWdAG6O6aYFyBu4aB/
1

Let's assume you have the following hash to crack, which is taken from the unshadowing process from a Unix system:

galoget@hackem:~$ cat hash_to_crack.txt
root:$6$NP3vF5ciATM7Ng3u$oB.k/TPp8VTuE.3H/YvzTRjZymnIEdladJemXKn8iV4B1IeTwxsbvyMEuxzXsupp3/cSRWdAG6O6aYFyBu4aB/

In this case, we only left the username and the hash separated by colons, the rest of the information is not useful for the password cracking process.

In order to crack the previous file, you can use the following command with JtR:

galoget@hackem:~$ john hash_to_crack.txt --format=sha512crypt --wordlist=rockyou.txt 
Warning: detected hash type "sha512crypt", but the string is also recognized as "HMAC-SHA256"
Use the "--format=HMAC-SHA256" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (sha512crypt, crypt(3) $6$ [SHA512 256/256 AVX2 4x])
Cost 1 (iteration count) is 5000 for all loaded hashes
Will run 8 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
password123      (root)
1g 0:00:00:00 DONE (2021-07-06 10:26) 3.030g/s 6206p/s 6206c/s 6206C/s kucing..lovers1
Use the "--show" option to display all of the cracked passwords reliably
Session completed

As you can see, the password was cracked successfully and it is shown in the output of JtR, for this example, the password is: password123

It did not require any other special parameter to crack it. Finally, you can check the cracked password by using the following command:

galoget@hackem:~$ john hash_to_crack.txt --show
root:password123

1 password hash cracked, 0 left

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .