Need help identifying hashes

[poot36]

I have two hashes that hashid can not identify and am wondering if someone can help me with them.
They are "$1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJw" and "$1$xDz96xgqD$piln.bBT7i3c8qUNMsRB//" without the quotes.

[radar_macgyver]

https://en.wikipedia.org/wiki/Crypt_(C)

The leading $1$ indicates it's md5.

[poot36]

That does appear to be true but if you look at the length of each hash they do not match the standard md5 length and the first hash has the 3rd $ one position over from a standard md5 hash.

[Nominal Animal]

It looks like a home-cooked PHP salted MD5 hash output to me.

$1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJw has a 8-character or 48-bit salt eyPcxmTg, and a 21-character or 126-bit hash ZbDfrT4wU2TEyFPOw9XJw.

$1$xDz96xgqD$piln.bBT7i3c8qUNMsRB// has a 9-character or 54-bit salt xDz96xgqD, and a 22-character or 132-bit hash piln.bBT7i3c8qUNMsRB//.

If we assume /.0-9A-Za-z is used, then for the first, the 48-bit salt would be AB E6 E8 F7 27 EC and the 128-bit hash 96 73 EB DD F1 BC 80 47 D0 F9 16 DA F0 B8 D5 F0, corresponding to openssl passwd -1 output of $1$q+bo9yfs$lnPr3fG8gEfQ+Rba8LjV8A==.  For the second, the 56-bit salt would be F4 FF CB 23 DB 36 3C and the 136-bit hash D6 EC 73 06 73 5F 26 E1 68 2B 68 19 63 87 4D 00 (where the final zero is irrelevant, a consequence of the encoding method, and thus the hash being a normal 128-bit one), corresponding to openssl passwd -1 output of $1$9P/LI9s2PA==$1uxzBnNfJuFoK2gZY4dNAA==.

I'd need to know which application is involved, or where the hash was encountered, to delve any deeper.

[Shonky]

That does appear to be true but if you look at the length of each hash they do not match the standard md5 length and the first hash has the 3rd $ one position over from a standard md5 hash.

Note md5crypt != md5

[bitwelder]

An inquiry to chatgpt returned that the first one, with 8 chars salt and 21 chars hash could be a 'Cisco type 5 password hashing'

[poot36]

@Nominal Animal They came from a Linux based ARM NVIDIA development board.  The Linux version is 3.10.40.

@Shonky I did screw up the md5 thing, I meant to say md5crypt but was not thinking correctly as I was distracted when typing up the message.

Is it possible to decode these non standards hashes with hashcat or will that not work?

[radar_macgyver]

The 9-char salt isn't really an issue, is it? The salt length is arbitrary AFAIK so that alone shouldn't be an issue. I can't explain the longer hash length though.

[Nominal Animal]

@Nominal Animal They came from a Linux based ARM NVIDIA development board.  The Linux version is 3.10.40.

Where on that board? /etc/shadow?

The Linux kernel does not use passwords or hashes, it is all done by (privileged) userspace applications or services like PAM; specifically pam_unix.so[/URL] (C source) on typical workstations.

We need to know which program uses the file you discovered the information in, to find out the hash algorithm and encoding.  To me, this looks like a home-grown password checking one might do from e.g. PHP, where the resulting password entry (containing salt and hash) is somehow modified, and likely uses a different encoding (64-character set; perhaps in a different order) than the standard tools do.

Is it possible to decode these non standards hashes with hashcat or will that not work?

Perhaps.  If the source to the program that uses these hashes is available, we might be able to transform the hashes to a form that hashcat can work with to find the password that results in the same hash; especially because hashcat uses certain algorithmic approaches to find plaintexts corresponding to specific MD5 hashes.

The details we need to know are 1) the hash algorithm, 2) the number of iterations (typically 1000), and 3) the encoding method (between binary and readable text) for the hash and the salt.  For a 128-bit hash with result prefix $1$, MD5 is the most likely one.


The first one looks at first glance like it could be a straightforward /etc/shadow password entry, because
    openssl passwd -1 -salt eyPcxmTg password
yields similar entries, for example
    $1$eyPcxmTg$XKWhmekZYWOHM5G5Ds6v81   1234
    $1$eyPcxmTg$JxqddwETEUR0W.qKUWUN60   nvidia
    $1$eyPcxmTg$mTx649hh3BkkNRuntSdH31   nvidia-arm
But, when you compare to the hash of the unknown password using the same salt,
    $1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJw
you see the hash is one character short.  This is critical, because 6-bit encoding here uses groups of four characters to encode 24 bits, with a possible trailing 8-bit group represented using XX==, and 16-bit group using XXX=.  Even if the padding character = was omitted, hashes encoded to 4n+1 characters just do not happen using normal methods.

Similarly,
    openssl passwd -1 -salt xDz96xgqD  1234
yields
    $1$xDz96xgq$J0ZlMdHTZ.E.QF1J.vLVp.
with the final character in the salt dropped and thus unused.  Indeed, the salt length is not arbitrary for the $1$ hash method using PAM/openssl.  Even the md5crypt utility limits the salt to 8 characters.

[poot36]

@Nominal Animal The hashes came from /etc/shadow file.  I do have a dump of the entire firmware from the system so I can take a look at any other relevant sections that may tell us how they were encoded.
The entire string from the shadow file for each hash is as follows: "csdev:$1$eyPcxmTg$ZbDfrT4wU2TEyFPOw9XJw:16148:0:99999:7:::" and "gve6776696577:$1$xDz96xgqD$piln.bBT7i3c8qUNMsRB//:16176:0:99999:7:::" without the quotes.

[Nominal Animal]

I hope you are aware that you can also simply change the two strings in the firmware, for example to
    csdev:$1$eyPcxmTg$sytqkZd2hmk2JWSeTZi1H/:16148:0:99999:7:::
    gve6776696577:$1$xDz96xgq$FsovEQ3MZuqYRcWru6oU01:16176:0:99999:7:::
to change the passwords to be the same as the usernames are.

The regular expression format for pam-unix.so passwords beginning with "$1$" is
    \$1\$[^$]{1,8}\$[./0-9A-Za-z]{22}
which means the csdev cannot have worked (allowed access with any password) with standard pam-unix.so, because it has invalid hash length (21 characters instead of 22); and any login attempts should yield user "csv" has corrupted passwd entry system log messages (typically into /var/log/auth.log in Debian derivatives).

Similarly, the gve6776696577 cannot have worked (allowed access with any password) using standard pam-unix.so, because pam_unix/pam_unix_passwd.c:MD5Name(crypt_md5) will only use the first 8 characters from the salt, and as it passes the entire password hash construction (starting with $1$), the result will never match because the salt parts will differ.  Thus, any login attempts should yield user "gve6776696577" has corrupted passwd entry system log messages (typically into /var/log/auth.log in Debian derivatives).

Assuming the system used PAM, you can find the PAM login configuration in the firmware image in /etc/pam.d/login file.  It typically contains a @include common-auth, so that the actual config is in /etc/pam.d/common-auth, with the first non-comment line being
    auth    [success=1 default=ignore]      pam_unix.so nullok
which means pam_unix.so is the primary authenticator.  Its sources are at Github at linux-pam/modules/pam_unix/, so if you're investigating a security failure, it is quite possible an attacker not only added those two accounts but also replaced the pam_unix.so binary as well.

If you examine /etc/issue, /etc/lsb-release, and /etc/os-release files in the firmware image, you can tell what base Linux distribution this uses.  This would be important to investigate any further.

The full /etc/shadow lines show that the csdev account was created in 2014-03-19, and the gve6776696577 one in 2014-04-16 (assuming UTC time; might also be one day before or later depending on time zone), if not faked/synthesized by modifying /etc/shadow directly instead via e.g. the passwd command.

Why do you need to crack these hashes?  Do you suspect nefarious access?  Or are you investigating why these accounts cannot be logged in? Or for some other reason?