Well, as you should already know by registering to this forum, it is not allowed to post hashes (
https://hashcat.net/forum/announcement-2.html). It's a reason to ban you. In this case it's even worse because we don't know the password and also we do not know if you are trying to trick somebody to crack it for you.
Back to the second password for blockchain.info: there is already a github issue over here:
https://github.com/hashcat/hashcat/issues/1650
but there wasn't much interest about this algo so far and I think no dev looked into it yet (so far).
I did some research now and the algorithm is quite straight forward.
You basically first need to crack and decrypt your main wallet/password and after that you get a "guid" string etc.
If there is a second password the decrypted string will have some info about the next step.
You can read the full details here:
https://github.com/gurnec/btcrecover/blo...-passwords (credits of course go to this btcrecover project from gurnec, because without that I would be clueless what's going on, without any source code and documentation. Credits where credits are due).
So btcrecover makes the process 2-fold too:
1. run python extract-scripts/extract-blockchain-second-hash.py wallet.aes.json to get this base64 string you are talking about all the time
2. python btcrecover.py --data-extract --passwordlist dict.txt (and here you interactively enter the base64 string at the start, before cracking)
there is a signature within the decoded base64 string "bs:" such that btcrecover.py (the second step) recognizes that it is a blockchain second (bs) password cracking attempt.
The format of the base64 decoded string is also quite straight forward:
Code:
echo -n YnM6LeP7peG853HnQlaGswlwpwtqXKwa/1rLyeGzvKNl9HpyjnaeTCZDAaC4LbJcVkxaECcAACwXY6w= | base64 | xxd -p
62733a2de3fba5e1bce771e7425686b30970a70b6a5cac1aff5acbc9e1b3bca365f47a728e769e4c264301a0b82db25c564c5a102700002c1763ac
here are my notes/annotations:
Code:
62 73 3a bs: <- signature
2d e3 fb a5 e1 bc e7 71 e7 42 56 86 b3 -......q.BV.. <- iterated sha256 hash
09 70 a7 0b 6a 5c ac 1a ff 5a cb c9 e1 b3 bc a3 .p..j\...Z......
65 f4 7a e.z
72 8e 76 9e 4c 26 43 01 a0 b8 2d b2 5c r.v.L&C...-.\ <- salt (used for the UUID conversation)
56 4c 5a VLZ
10 27 00 00 .'.. <- iteration: 0x2710 = 10000
2c 17 63 ac ,.c. <- crc32
the crc32 check is done on the first 55 bytes (59 minus the 4 bytes checksum):
Code:
crc32 <(echo 62733a2de3fba5e1bce771e7425686b30970a70b6a5cac1aff5acbc9e1b3bca365f47a728e769e4c264301a0b82db25c564c5a10270000 | xxd -r -p)
ac63172c
as you can see the checksum matches because we got ac63172c from crc32 (as we have in the last 4 bytes)
BTW: you can see here how the base64 string is generated by extract-scripts/extract-blockchain-second-hash.py:
https://github.com/gurnec/btcrecover/blo...sh.py#L207
Now back to the algorithm details.
There are older algorithms for this second blockchain.info password too (see
https://github.com/gurnec/btcrecover/blo...2163-L2178), but the current one is just some iterations of sha256 hashes, after concatenating the converted salt (UUID) and the password, see:
https://github.com/gurnec/btcrecover/blo...2157-L2159)
The final hash must match the extracted "hash" from the main password decryption (
https://github.com/gurnec/btcrecover/blo...s.py#L2160).
There are also some example hashes (credits go to the people from the btcrecover project of course, again):
YnM6LeP7peG853HnQlaGswlwpwtqXKwa/1rLyeGzvKNl9HpyjnaeTCZDAaC4LbJcVkxaECcAACwXY6w=:btcr-test-password
YnM6ujsYxz3SE7fEEekfMuIC1oII7KY//j5FMObBn7HydqVyjnaeTCZDAaC4LbJcVkxaCgAAACsWXkw=:btcr-test-password
YnM6/e8Inpbesj+CYE0YvdXLewgN5UH9KFvliZrI43OmYnyHbCa71RBD57XO0CbuADDTCgAAACCVL/w=:btcr-тест-пароль
(this is base64string:password notation)
I have also written a POC, just to make it very clear (this is of course a slow single-threaded cracking script, don't compare the speeds or blame me for the bad code PLEASE
):
blockchain_second_password.pl :
Code:
#!/usr/bin/env perl
#
# Author: philsmd
# Date: February 2019
# License: public domain, donated to hashcat, credits go to philsmd and the hashcat project
#
use strict;
use warnings;
use Digest::SHA qw (sha256);
use MIME::Base64 qw (decode_base64);
# Example:
# YnM6LeP7peG853HnQlaGswlwpwtqXKwa/1rLyeGzvKNl9HpyjnaeTCZDAaC4LbJcVkxaECcAACwXY6w=:btcr-test-password
# my $hash_target = pack ("H*", "2de3fba5e1bce771e7425686b30970a70b6a5cac1aff5acbc9e1b3bca365f47a");
# my $salt = "728e769e-4c26-4301-a0b8-2db25c564c5a";
# my $iterations = 10000;
if (scalar (@ARGV) != 2)
{
print "USAGE: $0 <base64 string> <dictionary>\n";
exit (1);
}
my $base64_string = $ARGV[0];
my $dict_file_name = $ARGV[1];
if (length ($base64_string) != 80)
{
print "ERROR: The base64 string (hash, salt, iterations) was not specified correctly as the second command line argument\n";
exit (1);
}
my $bin_string = decode_base64 ($base64_string);
if (substr ($bin_string, 0, 3) ne "bs:")
{
print "ERROR: signature of the decoded base64 string did not match 'bs:'\n";
exit (1);
}
my $hash_target = substr ($bin_string, 3, 32);
my $salt = substr ($bin_string, 35, 16);
my $iterations_str = substr ($bin_string, 51, 4);
my $iterations = unpack ("L<", $iterations_str);
# salt to UUID conversion
$salt = unpack ("H*", substr ($salt, 0, 4)) . '-' .
unpack ("H*", substr ($salt, 4, 2)) . '-' .
unpack ("H*", substr ($salt, 6, 2)) . '-' .
unpack ("H*", substr ($salt, 8, 2)) . '-' .
unpack ("H*", substr ($salt, 10, 6));
# TODO: crc32 check (not really needed, we assume the rest is okay, not corrupt)
my $fh_dict;
if (! open ($fh_dict, "<", $dict_file_name))
{
print "ERROR: Could not open dictionary file file '$dict_file_name'\n";
exit (1);
}
binmode ($fh_dict);
while (my $pass = <$fh_dict>)
{
chomp ($pass);
my $hash = $salt . $pass;
for (my $i = 0; $i < $iterations; $i++)
{
$hash = sha256 ($hash);
}
if ($hash eq $hash_target)
{
print "found pass: $pass\n";
last;
}
}
close ($fh_dict);
Code:
cat dict.txt
btcr-test-password
Code:
./blockchain_second_password.pl YnM6LeP7peG853HnQlaGswlwpwtqXKwa/1rLyeGzvKNl9HpyjnaeTCZDAaC4LbJcVkxaECcAACwXY6w= dict.txt
I think we could implement this in hashcat and we could get a quite fast speedup by using GPUs. Maybe if more people show interest at the current github issue (
https://github.com/hashcat/hashcat/issues/1650), we will consider adding it. My only concern is that we probably would also need to add the older ones too, I didn't research how widespread the older ones are (or their relative distribution and or date/year they were generated/used with each and every version).
update: this algorithm and new hash type was added to hashcat. see
https://github.com/hashcat/hashcat/issue...-466670491 and
https://github.com/hashcat/hashcat/commi...75f98ef00a
is.