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:
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[
7400
6500
7300
7400] 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.