What kind of hash is this?

[Znerox]

I'm trying to get the root password for a DSL modem/router, to unlock more features. In the config file the password is stored like this (I've censored some of it):

Code:

<Password>_encrypted_TKrP****eG7tXkK****OLQAAAABfQUxMAAAAIAAAACE=</Password>

I also got both hash/plaintext for the normal "admin" user, so I can verify if I just know what hashtype to check against.

[magnum]

Did you put any of the "A" in there or just the asterisks?

Did you keep the original length of the hash when obfuscating it, and does the hash of the admin user have the exact same length as this one?

[Znerox]

I just replaced 2x4 characters with asterisk. Both hashes are the same length, and both seem to include a lot of A's towards the end.

[atom]

can be anything. you will need to reverse engineer the algorithm used

[philsmd]

Yes, could be anything as atom said...

But still, the "string" above looks like plain base64 encoded.

See this example (ending of your string):

Code:

$ echo -n LQAAAABfQUxMAAAAIAAAACE= | base64 -d
-_ALL !

This is for sure no coincidence...

Said that, it doesn't mean that you get the plain password by decoding it (with base64), since there are also some algos that hash-then-encode etc ( see http://hashcat.net/wiki/doku.php?id=example_hashes etc)

P.S: what I mean is you should try w/ base64-decoding, starting w/ the letters "TKrP..." and maybe try other substrings too, but it seems that it is a long base64 encoded string

[Znerox]

This is interesting, I compared the hashes of admin/root, and found that the first 21 characters (not counting "_encrypted_" are unique, but the last 22 characters (not counting "=") are absolutely identical. Is it possible that they have just added thoose characters at the end to make it harder to crack? I don't get why they would do it though, as it's very easy to spot.

Code:

root
_encrypted_ TKrP****eG7tXkKbe0DOL QAAAABfQUxMAAAAIAAAACE=

admin (password is "password1")
_encrypted_ wOs0DDgsSDMJ6LeE5/iKB QAAAABfQUxMAAAAIAAAACE=

Decoding the unique string in root on base64decode.org actually returns 9 completely random characters, but reencoding that string again gives a diffrent base64 string. So it seems like it's not decoding correctly.
Looking over "example hashes", it looks similar to Cisco hashes

Code:

2400     Cisco-PIX MD5        dRRVnUmUHXOTt9nk
5700     Cisco-IOS SHA256     2btjjy78REtmYkkW0csHUbJZOstRXoWdX1mGrmmfeHI

[philsmd]

So we already proofed that those strings are base64 encoded, see example decoding (pls avoid online base64 decoding for non-ascii-chars , there are problems w/ encoding the bytes server-side, displaying them client-side etc):

Code:

echo -n "wOs0DDgsSDMJ6LeE5/iKBQAAAABfQUxMAAAAIAAAACE=" | base64 -d | xxd -p
c0eb340c382c483309e8b784e7f88a05000000005f414c4c0000002000000021

This is interesting because the first part seems to be exactly a 32-length long string of (maybe) random hex-chars (like in md5, but it could be also something completely different like half md5 + salt etc, j/k):
c0eb340c382c483309e8b784e7f88a05

The problem now is to identify and analyze the other parts and their meaning.

What you can do next is to test some variation of md5 (pass + salt), md5 (salt + pass) and/or some iterations of md5.
But first you should check if a salt is somehow involved by creating a new account (or if not possible just a password-change) and setting the password again to "password1". If the two hashes are identical than no salt is involved.
It could ofc also be that the username is somehow involved etc etc...

As atom said, nobody can said until someone reverses the algo or has luck and solves the puzzle without RE.

[Znerox]

When I do a password change the hash turns out exactly the same. I don't see why I should even bother finding out what "QAAAABfQUxMAAAAIAAAACE=" means, since it's just the same in all hashes.

So if I understand this correctly, the first 32 characters of the result of the hexdump (I don't really know what I'm talking about) of the complete original string, is the hash I'm looking for. In the case of "password1", that hash is "c0eb340c382c483309e8b784e7f88a05", as you pointed out.

Or, if I were to get read access to the complete filesystem, or perhaps by looking at the firmware image, might it be possible to find the algorithm used?

[magnum]

Or, if I were to get read access to the complete filesystem, or perhaps by looking at the firmware image, might it be possible to find the algorithm used?

Definitely, but you wont likely find any "human readable" information so you'd need to reverse engineer something... and before that, you need to figure out just what to reverse engineer...