04-17-2019, 08:46 AM
so as far as I understood, the question (also in regards to your PM) was how to obtain the intermediate results between the two decryption step. Well, it's just using PBKDF2-HMAC-SHA1 (32 byte output) with a iteration count (5000 default?) included within the hash to derive an encryption key and it uses AES-256-CBC (using the 32 byte key) to decrypt the data.
The first 16 bytes of the last field of the hash ("the data", first 32 hexadecimal characters of that field) form the salt, the remaining bytes form the encrypted data, that needs to be decrypted and should contain "guid" (attention: not necessarily at the start, that's the main problem/mistake that some crackers had) etc in the decrypted data.
both pbkdf2 and aes decryption are straight forward steps and the btcrecover script (extract-blockchain-second-hash.py) does indeed exactly that (but note again that in its unpatched form it doesn't always validate the decrypted data with "guid" correctly, as mentioned above).
In the extract-blockchain-second-hash.py you basically just add this python code:
it's as easy as just printing the already available "decrypted" data/variable. of course you could filter this (add an if block) to only happen when the regex {.*"guid" matches , or alternatively you only execute the script with the correct password (to avoid that garbage data is printed with print (decrypted) when the password provided is incorrect)
An alternative would be to fill out the salt, data, pass (and correct the iterations) variables of the below script and execute it.
As already mentioned the data is the last field of the -m 15200 hash, it contains the salts at the beginning (first 16 bytes or 32 hexadecimal characters) and the data in hexadecimal (the part after the 32 hexadecimal chars of the last field of the hash).
blockchain_wallet_data_decrypt.pl
Anyway, my understanding of this algorithm with double_encryption enabled is that this intermediate data is kind of useless, because it's (what the word itself already tells us) double encrypted. Encrypted data is kind of useless to print, because it needs to be decrypted (again) first with the second password.
That's why I do not fully understand why you insist on printing the intermediate result. You can just use extract-blockchain-second-hash.py to obtain the hash for -m 18800 = Blockchain, My Wallet, Second Password (SHA256) instead (which indeed also contains the most important data needed to verify the next/second password !). This output of the extract-blockchain-second-hash.py is a base64 encoded string/hash (that can be used together with -m 18800 in hashcat), but of course it contains the most important data like salt, iteration count and the digest already.
The first 16 bytes of the last field of the hash ("the data", first 32 hexadecimal characters of that field) form the salt, the remaining bytes form the encrypted data, that needs to be decrypted and should contain "guid" (attention: not necessarily at the start, that's the main problem/mistake that some crackers had) etc in the decrypted data.
both pbkdf2 and aes decryption are straight forward steps and the btcrecover script (extract-blockchain-second-hash.py) does indeed exactly that (but note again that in its unpatched form it doesn't always validate the decrypted data with "guid" correctly, as mentioned above).
In the extract-blockchain-second-hash.py you basically just add this python code:
Code:
print (decrypted)An alternative would be to fill out the salt, data, pass (and correct the iterations) variables of the below script and execute it.
As already mentioned the data is the last field of the -m 15200 hash, it contains the salts at the beginning (first 16 bytes or 32 hexadecimal characters) and the data in hexadecimal (the part after the 32 hexadecimal chars of the last field of the hash).
blockchain_wallet_data_decrypt.pl
Code:
#
# Author: philsmd
# Date: April 2019
# License: public domain (credits go to philsmd and hashcat)
#
use strict;
use warnings;
use Crypt::PBKDF2;
use Crypt::CBC;
my $salt = ""; # first 32 hexadecimal chars of the last hash field (16 bytes)
my $data = ""; # remaining chars of the last field of the hash (after the first 32 hexadecimal chars)
my $pass = "";
my $iterations = 5000; # the 3rd field of the hash (iteration count)
my $hasher = Crypt::PBKDF2->hasher_from_algorithm ('HMACSHA1');
my $pbkdf2 = Crypt::PBKDF2->new (
hasher => $hasher,
iterations => $iterations,
output_len => 32
);
$salt = pack ("H*", $salt);
my $key = $pbkdf2->PBKDF2 ($salt, $pass);
my $cipher = Crypt::CBC->new ({
key => $key,
cipher => "Crypt::Rijndael",
iv => $salt,
literal_key => 1,
header => "none",
keysize => 32
});
$data = pack ("H*". $data);
print $cipher->decrypt ($data) . "\n";Anyway, my understanding of this algorithm with double_encryption enabled is that this intermediate data is kind of useless, because it's (what the word itself already tells us) double encrypted. Encrypted data is kind of useless to print, because it needs to be decrypted (again) first with the second password.
That's why I do not fully understand why you insist on printing the intermediate result. You can just use extract-blockchain-second-hash.py to obtain the hash for -m 18800 = Blockchain, My Wallet, Second Password (SHA256) instead (which indeed also contains the most important data needed to verify the next/second password !). This output of the extract-blockchain-second-hash.py is a base64 encoded string/hash (that can be used together with -m 18800 in hashcat), but of course it contains the most important data like salt, iteration count and the digest already.