Another BTC MultiBit Classic wallet (no password or seed words)

[mr_fish2021]

Hi all,

I have an old (2014) MultiBit Classic wallet that I've recovered from an old Windows computer, with some BTCs inside.

I do have all the wallet files, including backups, keys, rolling backups, wallet-unenc-backup, etc.  All the files seem OK.
But everything (including unenc-backup files) is encrypted with a password that I'm unable to find. I do not have any seed words either...

I've tried the "multibit_recovery" scripts to open the files and for all files it request the password, including for the unenc-backup cipher files.

My last hope was to use the "btcrecover" script using passwords lists and tokens but it didn't work in a reasonable time with my normal passwords.
Of course I can try to run it for the following 5 years in a GPU, maybe BTC in 2026 will be worth ...

Any other ideas?

Thanks!

[BitMaxz]

What OS you currently use?

Would you mind sharing your BTCrecover command here?

For some tips that I found to help speed up the brute-force process check them below.

If you are using Linux you can have a small speed boost for the Multibit wallet by compiling BTCrecover with Cython.
Commands

Code:

sudo apt-get install python-pip
sudo pip install Cython

cython -o btcrecover/btcrpass.c btcrecover/btcrpass.py
gcc -O3 -fwrapv -fno-strict-aliasing -fPIC -I /usr/include/python2.7 -shared -lpython2.7 -o btcrecover/btcrpass.so btcrecover/btcrpass.c

./run-all-tests.py

The source can be found here https://github.com/gurnec/btcrecover/issues/90#issuecomment-317757608

If you are going to use GPU add this command.

Code:

--enable-gpu

Sample command to brute-force encrypted.key with GPU

Code:

python btcrecover.py --enable-gpu --wallet encrypted.key --tokenlist tokensamples.txt --no-dupchecks --autosave sampleprogress.txt --max-eta 5000

[mr_fish2021]

Thanks for the tips!

Currently using macOS big sur in a macbook pro: python btcrecover.py --wallet wallets.key --tokenlist tokens/tokens.txt  --no-dupchecks

I'll try in Linux and with a GPU as soon as I can. I'm not really confident to find it by brute force :-(
I'm still reviewing old notebooks and backups for a clue of the password or seed.

[ranochigo]

You might want to see if this[1] fork will be better, it's far more active than the previous repository. As with your chances, it would probably be not worth your time unless you have some vague idea of the password. AES-256-CBC is not particularly weak.

[1] https://github.com/3rdIteration/btcrecover

[mr_fish2021]

Thanks! I didn't know this fork.

[HCP]

Also, it's possible to use the "multibit2john.py" script (that is part of JohnTheRipper) to extract a hash from either a multibit .key (preferred option) or a multibit .wallet file (VERY slow to crack as it is encrypted with Scrypt).

The hash output from multibit2john.py will look something like this (for a .key file):

Code:

cwoern.key:$multibit$1*0b4989bdf01e4746*02d61e0c77e7131cb12a638ed742f571ba884621f4e0bebdfc900357cd9a310a

Once you have the hash, you can use "hashcat" to attempt to crack the password.

To do that, we copy everything after the ":" and put it into a .txt file like this:

Code: (multibit_hash.txt)

$multibit$1*0b4989bdf01e4746*02d61e0c77e7131cb12a638ed742f571ba884621f4e0bebdfc900357cd9a310a

And then the hashcat commandline should be something like:

Code:

hashcat -m 22500 -a 3 multibit_hash.txt <PUT YOUR HASHCAT "MASK" HERE>

You can practise using the hash above... and the mask ?a?a?a?a?a?a:

Code:

hashcat -m 22500 -a 3 multibit_hash.txt ?a?a?a?a?a?a

And it should find the password "abc123" relatively quickly. For your .key/hash, you'll need to experiment with different "masks" based on what you believe the password is likely to be... refer here: https://hashcat.net/wiki/doku.php?id=mask_attack

Finally, unless you have a fairly good idea of what the password was likely to be, and that it's relatively short... your chances of bruteforcing it aren't great

[mr_fish2021]

Thanks HCP! I'll give it a try. I hope the password is one of the variations of the passwords I've used in the last 7 years...

[NotATether]

Thanks HCP! I'll give it a try. I hope the password is one of the variations of the passwords I've used in the last 7 years...

Also, if you remember only using certain characters in your password, you can define a custom character set in hashcat so that it only looks for password combinations with those characters in it:

If you know your password only has the characters "abcdefgh12345", use

Code:

hashcat -m 22500 -a 3 multibit_hash.txt -1 abcdefgh12345 ?1?1?1?1?1?1?1?1

Finds an 8-character password with only the above characters in them. If you know the password is between 6 and 8 characters long, use this:

Code:

hashcat -m 22500 -a 3 multibit_hash.txt ?a?a?a?a?a?a ?a?a?a?a?a?a?a ?a?a?a?a?a?a?a?a

This tries all ASCII characters. Unfortunately there is no shorthand syntax for ranges of passwords.

[mr_fish2021]

Thanks NotATether, I've already obtained the multibit hash and installed hashcat, this will help me a lot to reduce the number of iterations
 

[HCP]

This tries all ASCII characters. Unfortunately there is no shorthand syntax for ranges of passwords.

Yes, there is

Have a look at -i, --increment-min and --increment-max as described here:

Code: (https://hashcat.net/wiki/doku.php?id=hashcat#options)

 -i, --increment                |      | Enable mask increment mode                           |
     --increment-min            | Num  | Start mask incrementing at X                         | --increment-min=4
     --increment-max            | Num  | Stop mask incrementing at X                          | --increment-max=8

So, if you know the password is between 6-8 chars...

Code:

hashcat -m 22500 -a 3 multibit_hash.txt -i --increment-min=6 --increment-max=8 ?a?a?a?a?a?a?a?a

will only check the masks that have 6-8 chars in them

[NotATether]

Yes, there is

Have a look at -i, --increment-min and --increment-max as described here:

Code: (https://hashcat.net/wiki/doku.php?id=hashcat#options)

 -i, --increment                |      | Enable mask increment mode                           |
     --increment-min            | Num  | Start mask incrementing at X                         | --increment-min=4
     --increment-max            | Num  | Stop mask incrementing at X                          | --increment-max=8

So, if you know the password is between 6-8 chars...

Code:

hashcat -m 22500 -a 3 multibit_hash.txt -i --increment-min=6 --increment-max=8 ?a?a?a?a?a?a?a?a

will only check the masks that have 6-8 chars in them

Ah OK, thanks for that. I never really understood how --increment worked and I thought it took a mask, and then made the mask shorter as in less characters. That's what the hashcat wiki page seemed to imply at least, in the part where it talks about having an 8 character mask but the mask's length decreases. Maybe that's what happens if you use -i and --increment-max by themselves?

[HCP]

If you use the -i on it's own and a mask like this:

Code:

?a?a?a?a?a?a?a?a

Hashcat will actually try:
?a
?a?a
?a?a?a
?a?a?a?a
?a?a?a?a?a
?a?a?a?a?a?a
?a?a?a?a?a?a?a
?a?a?a?a?a?a?a?a

It is essentially the "brute force" mode...

So if you only use -i and --increment-max, it'll start at length 1... and go up to the max. Seems somewhat pointless, as you could just set the "max" with the length of the mask and setting max to something less than the mask length seems a bit pointless

The --increment-min is probably more useful.

[mr_fish2021]

Thanks HCP and NotATether! I'm writing some masks for the passwords patterns I usually use and this will be very helpful.
I must say I'm quite impressed with hashcat capabilities.

[keychainX]

Thanks HCP and NotATether! I'm writing some masks for the passwords patterns I usually use and this will be very helpful.
I must say I'm quite impressed with hashcat capabilities.

Masks are useless. Try with rules. Its much more efficient and will increase the speed sometimes 90%
.

Pure brutforce is slow...

/KX

[mr_fish2021]

thanks keychainX! It seems powerful. I'm just learning how to use it while the computer is doing some mask attacks. I'll probably combine both approaches.

A couple of questions regarding MultiBit Classic wallet: I see many people complaining about corrupted MultiBit wallets not opening with the correct password. I *believe* my wallet files are ok because they load into MultiBit Classic for Mac or, when I extract keys o see transactions with other scripts, they do not complain, but:

... is there a way to be sure the wallet files have not been corrupted?
... is there the possibility that hascat (or other recovery scripts) is not able to open the wallet even if they find the correct password?

Thank you!

[Myleschetty]

... is there a way to be sure the wallet files have not been corrupted?

If the wallet is MultiBit? No, the last time i checked the wallet is deprecated and people are advised not to use it cause it developer no longer work on it or provide support which is the reason why people complain about it.

... is there the possibility that hascat (or other recovery scripts) is not able to open the wallet even if they find the correct password?
Thank you!

Hascat does not illustrate how wallet cause it own function is to help you recover your lost or forgotten password.

[HCP]

... is there a way to be sure the wallet files have not been corrupted?

... is there the possibility that hascat (or other recovery scripts) is not able to open the wallet even if they find the correct password?

hashcat doesn't open the wallet... all it does is "hash" password combinations and compare to the "hash" you already have. If it finds a match, it tells you.

Depending on how corrupt the file is, you'll either get incorrect password or invalid file messages.

I know my Python multibit recovery scripts will often know if the password on a "corrupt" .key file is incorrect... but if the correct password is supplied it will spit out garbage data instead of the private keys etc... This is because the .key files are just encrypted "text" files. I've tested this by overwriting a few random characters of an encrypted ".key" files and then running the script.

.wallet file corruption is a bit different... the file format is a lot more sensitive to corruption as it is a "protobuf" binary file... so any corruption will generally mean that it is not able to be deserialised properly and the script will just crash with a "not a wallet file"-type error.

Same with the .wallet.cipher files... it'll generally know if the password to the file encryption is "OK", but then because the "protobuf" is damaged, it'll crash the script.

[mr_fish2021]

thanks Myleschetty and HCP!  I believe my .wallet files are OK because multibit itself, multibit_recovery and other scripts seem to behave well managing the files. I understand hashcat does not manage the wallet, just the key. I believe my private key extracted is correct. I was wondering if there is a way to tell if a key has been corrupted (any parity, checksum, redundancy, ...). I'll keep trying in any case, thanks!

[HCP]

I was wondering if there is a way to tell if a key has been corrupted (any parity, checksum, redundancy, ...)

Yes... the WIF format key that you should have got from decrypting the .key file (for MultiBit it'll be a "compressed" key so it will start with a "K" or an "L"), contains a checksum...

If you can import that private key into a wallet like Electrum without error, then it's almost guaranteed that the key is not corrupted in any way. Changing even a single character will likely render the entire address invalid.

You can see an example of WIF checksum's in action here: https://gobittest.appspot.com/PrivateKey

Note that this page is quite old so it is using "uncompressed" keys for it's examples, so the WIF keys start with a "5"... it still works with "compressed" keys and WIFs that start with a "K" or "L", it just gives spurious errors.