hashcat / hashcat

World's fastest and most advanced password recovery utility
https://hashcat.net/hashcat/
21.45k stars 2.93k forks source link

Bitcoin wallet.dat (-m 11300) limits salt size to 8 bytes #2219

Closed solardiz closed 5 years ago

solardiz commented 5 years ago

This is mostly JFYI, feel free to act on it or ignore it:

https://github.com/hashcat/hashcat/blob/11c8a4040b0b439b520952a461cbfa8f1d12898e/src/modules/module_11300.c#L147 requires that the salt size be exactly 16 hexadecimal characters. All test vectors that we have in JtR match this requirement. However, I've just learned that the legacy wallet for Nexus https://github.com/Nexusoft/Legacy used salt size of 18 bytes, or 36 hexadecimal characters. A minor revision of JtR's bitcoin2john.py script (dropping the unneeded parsing of transaction data from it, for which I opened an issue with JtR) appears to be able to parse such wallet, producing a "hash" that JtR accepts as-is, but hashcat rejects for wrong salt length (hashcat wants exactly 16, but the "hash" has 36 in there). Maybe hashcat's check should be relaxed, after confirming that the OpenCL kernel accepts a variable salt length correctly. I've tried this, and hashcat accepts the "hash" and appears to run fine. Unfortunately, I do not currently have a test vector with a known password. I suppose one can be produced with the legacy wallet.

$ fgrep -r _SALT_ .
./src/wallet/crypter.cpp:        if (nRounds < 1 || chSalt.size() != WALLET_CRYPTO_SALT_SIZE)
./src/wallet/crypter.h:    const unsigned int WALLET_CRYPTO_SALT_SIZE = 18;
./src/wallet/wallet.cpp:        kMasterKey.vchSalt.resize(WALLET_CRYPTO_SALT_SIZE);
./src/wallet/wallet.cpp:        RAND_bytes(&kMasterKey.vchSalt[0], WALLET_CRYPTO_SALT_SIZE);
solardiz commented 5 years ago

Update: it's not that simple regarding that Nexus wallet - they seem to have blindly changed the key and salt size constants in the code relative to Bitcoin's (32 to 72, 8 to 18), but the code wouldn't handle the new values correctly. So we should not blindly accept 36 as valid and try to crack that - it doesn't work.

I'll close this issue for now since the actual issue, if any, would be different. Maybe we'll get away with a bitcoin2john.py update, or maybe an update to JtR and hashcat will also be needed - we'll see.

Sorry for the noise.