Is this a known and implemented algo?

Is this a known and implemented algo? - Printable Version

+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Developer (https://hashcat.net/forum/forum-39.html)
+--- Forum: hashcat (https://hashcat.net/forum/forum-40.html)
+--- Thread: Is this a known and implemented algo? (/thread-8296.html)

Is this a known and implemented algo? - Ring0 - 04-11-2019

I found such algo that cracks ESET client passwords
https://github.com/LFriede/eset-password-recovery/blob/master/algo.pas

I was wondering if that's a known algorithm and perhaps already implemented in hashcat? If not, where do we submit requests?

RE: Is this a known and implemented algo? - undeath - 04-11-2019

the hash is only 4 bytes, there are going to be loads of collisions, even on cpu only. https://github.com/LFriede/eset-password-recovery

RE: Is this a known and implemented algo? - DanielG - 04-11-2019

Looks like the CRC32 table and method, only on end it does XOR $68DBAF89.

So my guess is to use hashcat -m 11500 but first manually XOR the recovered data out of registry with 0x68DBAF89.

//edit:

I did some searching and my assumption seems to be correct. I found a screenshot of a ESET password (lockpassword in registry) here:

[Image: screenshot-75.jpg]

This has a value of 4f03c2e3 and the password is "test".
In your github example it seems to brute-force using a datatype of 'WideString' (current_pw:WideString), so a kind of UTF-16. Meaning "test" has a null-byte after each character, this is something you have to account for in brute-forcing. I hope this quirk results in fewer collisions of passwords, but who knows.

To test this you can see the following code works:

PHP Code:
password_utf16 = "t\0e\0s\0t\0"; // nullbyte after each character
password_crc32 = crc32(password_utf16); // calculate CRC32
password_xored = password_crc32 ^ 0x68dbaf89; // XOR it with 68dbaf89
echo dechex(password_xored);

4f03c2e3 

To use this in hashcat you need to account for the UTF-16/Unicode nature of the password and first manually xor the value with 68dbaf89.

So, 4f03c2e3 xor 68dbaf89 = 27d86d6a. There is no salt so we provide this to hashcat as 27d86d6a:00000000 as per https://hashcat.net/wiki/doku.php?id=example_hashes.

Below a quick brute-force of 4 lowercase letters, each with a 00 after each letter:

Code:
hashcat -m 11500 -O -a 3 --hex-charset -2 00 "27d86d6a:00000000" "?l?2?l?2?l?2?l?2"

27d86d6a:00000000:$HEX[7400650073007400]

Session..........: hashcat

Status...........: Exhausted

Hash.Type........: CRC32

$HEX[7400650073007400] is the hex representation of the word "test" in the UTF-16 format.

To use wordlists and other better hashcat features you must look out for the UTF-16 format, look at --encoding-to option (perhaps utf-16LE). Also since collisions can occur you might want to use the option --keep-guessing. But yeah, hashcat can crack this format.

RE: Is this a known and implemented algo? - atom - 04-14-2019

Like