Trouble recovering Multibit Classic Keys

[Autoband86]

Hey all,

After searching everywhere last night, I have found several solutions to a problem I am experiencing, which don't work (yet). My Multibit Classic wallet is quite old, from 2013, using version 0.5.15, and I cannot decrypt the wallet, it rejects the password.. Apparently a common problem with the classic?

I have several rolling backups, a number of encrypted files, and a .key file, yet none seem to get decrypted properly with the password. I have used OpenSSL without succes.

Another thing I tried is a python script called Multibit Recovery by one of the forum members here. With the password, I am getting the Pubkey but not the privkey, it then shows the following output:

Traceback (most recent call last):
  File "decrypt_multibit_classic_walletkeys.py", line 215, in <module>
    wallet = load_wallet(wallet_file, get_password)
  File "decrypt_multibit_classic_walletkeys.py", line 172, in load_wallet
    print("Privkey: " + bitcoin.encode_privkey(privkey, 'wif_compressed'))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bitcoin/main.py", line 224, in encode_privkey
    return encode_privkey(decode_privkey(priv), formt, vbyte)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bitcoin/main.py", line 237, in decode_privkey
    if not formt: formt = get_privkey_format(priv)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bitcoin/main.py", line 217, in get_privkey_format
    bin_p = b58check_to_bin(priv)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bitcoin/main.py", line 427, in b58check_to_bin
    assert bin_dbl_sha256(data[:-4])[:4] == data[-4:]
AssertionError

I am hoping someone can make more sense of this than I can? Some of my files give an incorrect password message, some do give me back the PubKey but always the same error above.

[HCP]

Firstly, sorry that my script is not working for you. I tested it with a number of files and never got this error

This part of the error message suggests that the checksum of the generated WIF format private key, doesn't match the original checksum from the private key stored in the file:

  assert bin_dbl_sha256(data[:-4])[:4] == data[-4:]
AssertionError

Is the .key file encrypted as well? Can you open it in a text editor like Notepad and read anything? If it is all encrypted, can you run the decrypt_multibit_classic_keys.py script on the .key file with that password? Does that generate any errors?

Unfortunately, I cannot replicate this error... so it is a little hard for me to test and figure it out...

I have made a quick modification here: https://pastebin.com/Z2zfbwiv

It should hopefully print out the "hex" version of the private key after the Pubkey: line... and before the error occurs. it'll look something like (NOTE: hex should be exactly 64 chars long):

Privkey: 41e09d37764805f234d2d17995d1c8f6338243f413a374c8d8a8b1e002b5b67e

Create an offline copy of the bitaddress.org website (links are at the bottom of the bitaddress.org page)... and then copy/paste that hex value into "Private Key" section of the "Wallet Details" page and click the "View Details" button. See if it gives you the matching addresses or an error message.

If you don't actually get that big long hex string (exactly 64 chars) from the script... then that is the reason for the error... as the private key is not being retrieved correctly... which is a bit of a problem

[Autoband86]

Hi HCP,

Thanks for your reply, and your script! I ran your mod and it gives me a 94 character long output, which I guess it is not supposed to do. The error after that is:

Traceback (most recent call last):
  File "decrypt_multibit_classic_keys2.py.py", line 216, in <module>
    wallet = load_wallet(wallet_file, get_password)
  File "decrypt_multibit_classic_keys2.py.py", line 173, in load_wallet
    print("Privkey: " + bitcoin.encode_privkey(privkey, 'wif_compressed'))
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bitcoin/main.py", line 224, in encode_privkey
    return encode_privkey(decode_privkey(priv), formt, vbyte)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bitcoin/main.py", line 237, in decode_privkey
    if not formt: formt = get_privkey_format(priv)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bitcoin/main.py", line 217, in get_privkey_format
    bin_p = b58check_to_bin(priv)
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/bitcoin/main.py", line 427, in b58check_to_bin
    assert bin_dbl_sha256(data[:-4])[:4] == data[-4:]
AssertionError

When I run the script for the .key file, it tells me the password is incorrect. I was wondering about the password, but if it decrypts the PubKey correctly it must be the right one, right? I am afraid the .key and other files are corrupted? All the files I have give the same output btw, I have a saved file from when I installed Multibit, and one from after that. Another option I guess would be to decrypt the wallet.cypher files, I havent managed to do that with OpenSSL yet though, because it is more than 64 char, and my knowledge of it is little.

Would it be possible to decrypt the .wallet file and look at where the problem lies in the code? I have encoded and decoded a wallet file with the same password and name, which decrypted perfectly with your script! If I can put those decrypted next to each other, I might be able to spot the difference.

The output PrivKey I guess is wrong, but would it be decrypted correctly, just with a few to many characters?

I am using a mac btw

[HCP]

Sent you a PM with my Skype... but I guess you dropped offline before I sent it.

Anyway, 94 characters?? that's not a good result. That sounds like something is going a bit wonky somewhere...

Does the script output say the following right at the beginning?:

File NOT Encrypted
--------------------------------------------------------------------------------
Keys are encrypted

The script should have generated a file called "parsed_wallet.txt". Can you open that up and see what it contains?

you should see things like:

key {
  type: ENCRYPTED_SCRYPT_AES
  public_key: "\0030g\351\227 ~-\370b\261 6\031\347\004U\321\331cFV\222HRD\255\240\255H\317\254\252"
  creation_timestamp: 1494035052000
  encrypted_data {
    initialisation_vector: "\201e\2700m}\217x+I}\235\237\356\201n"
    encrypted_private_key: "\2564\274\217\263Q\177\345\270\216\275]N\326\305\360\226\246\207B\033\225e\311j\200\353\014\016\205\355jn\206Q\366\023\306\303\306\017\267\2670\021\3501_"
  }
}

NOTE: DO NOT POST ANY OF THE CONTENT OF YOUR "parsed_wallet.txt" FILE HERE!!!

The pubkey isn't encrypted within the file... but the private key is... can you confirm that your "parsed_wallet.txt" has key{}'s that have type: ENCRYPTED_SCRYPT_AES and also contains the encrypted_data{} section that has the initialisation_vector and encrypted_private_key?

Also, near the end of the file should be some sections that look like:

encryption_type: ENCRYPTED_SCRYPT_AES
encryption_parameters {
  salt: "\355\220\310M\277UJ/"
}
version: 2
extension {
  id: "org.multibit.walletProtect.2"
  data: "\000"
  mandatory: true
}

Again, DON'T post any of that here... I just want to confirm that you have ENCRYPTED_SCRYPT_AES with the "salt"... and that there is the org.multibit.walletProtect.2 in there as well?

I'm trying to rule out a different wallet format to what I have seen and that the script is expecting...

[Autoband86]

HCP, thanks for your skype!

I'm having Dad duty today, so only sporadicly online. I do have a parsed-wallet file, and it also contains an encrypted_private_key. There is also a salt in the form of:
encryption_type: ENCRYPTED_SCRYPT_AES
encryption_parameters {

And the encryption is also version 2

[HCP]

Well... colour me confused then... I honestly have no idea why your private key is decrypting as 94 chars which is effectively 47 bytes... that just makes no sense??!?

Do you have a .key file at all? maybe try just running the decrypt_multibit_classic_keys.py script on the .key file...

Are you not able to open your wallet with MultiBit Classic and export the keys from there?

[HI-TEC99]

Did you only ever use one password for that wallet, or did you ever change it?

In 2013 if you added a password multibit classic made a timestamped backup in a folder whose name ends in -data. If you changed your password multibit classic made another timestamped backup. The first password would only work with the first timestamped backup, and the second password would only work with the second timestamped backup.

You said you had several rolling backups and a .key file. You can choose to manually create a .key file, but if you change your password multibit automatically creates one. If you ever changed your password then try all possible combinations of passwords and backups.

When you add a password to a wallet MultiBit creates a timestamped copy of it in the

"name of wallet"-data/wallet-backup

directory.

Then when you change the password it creates another timestamped copy in the same directory.

Thus your older backup will use the older password.
You should be able to open it, it will sync and then you can spend using your old password.

When you change the password it does tell you that OLD backups are not being changed to tell you that if your old password had been compromised you would need to take further action.

[Autoband86]

The .key file I have wont decrypt with the password (your script says the password is wrong), and with the password I get gibberish when using OpenSSL. The fact of the matter is I wasn't able to export my private keys in the first place, because my multibit wallet rejected my password.

It was the start of the problem, I used all kinds of other passwords, but only this password gave me a "Provided AES key is wrong" reaction. I guessed this must have been the correct password so I tried to decrypt all other files.

When decrypting with the MultiBit Recovery script however, I do get the correct Public Key, so I think this password should be correct?


@HI-TEC99 Considering the timestamp, I have two files in the wallet-backup. One from 29 of nov, one from 30th. Both decrypt (only in the Multibit Recovery script) with the password I have above. But in multibit it says the password is wrong. If I look at the hex both are identical strangely.

The .key file is made at the same moment as the 1st backup. It doesnt decrypt either...

[HCP]

When decrypting with the MultiBit Recovery script however, I do get the correct Public Key, so I think this password should be correct?

Not necessarily... Does the script output this:

File NOT Encrypted
--------------------------------------------------------------------------------
Keys are encrypted

Right at the start? If so, then the wallet file itself isn't actually encrypted... it is just in a "protobuf" format, hence why you can't read it. The public key isn't encrypted either, even though it "looks" all weird and encrypted. It is just binary encoded hex values stored as text characters...

The really confusing thing though, is that if your password was incorrect, the decryption of the keys should fail and you should see "incorrect password" and get prompted for the password again... it shouldn't give an incorrect private key??!?

File NOT Encrypted
--------------------------------------------------------------------------------
Keys are encrypted
terminal does not support UTF; passwords with non-ASCII chars might not work
This wallet file is encrypted, please enter its password:
incorrect password
File NOT Encrypted
--------------------------------------------------------------------------------
Keys are encrypted
terminal does not support UTF; passwords with non-ASCII chars might not work
This wallet file is encrypted, please enter its password:

[ABitConfused]

I have exact the same problem. I have a Multibit HD wallet (damn me, I lost the seeds), locked by the Multibit bug. I have the right password and tried your modified script:
First: find_unspent_multibitHD_txes.py. That works fine.
Then: your modified script with output of private key.
My private key ist 170 (hex) characters long, not 64...
The key-file is encrypted in my case. I call your script with the password, that works fine - its working a while. Then it asks for the password a second time and begins working again, stopping with the 170 long privkey and error message.
So Autoband and my problem is the same!
Both corrupted wallet-files, it seems.
50$ blown away...
If someone can help me, getting access back to my BC, that would be very nice!
Thanks

[HCP]

I have exact the same problem. I have a Multibit HD wallet (damn me, I lost the seeds), locked by the Multibit bug. I have the right password and tried your modified script:
First: find_unspent_multibitHD_txes.py. That works fine.

That is all you should have to do... that script should find all the unspent coins in your wallet (excluding any unconfirmed transactions)... and output the private keys for the addresses containing those UTXOs...

Then: your modified script with output of private key.

Ummmmm NOPE! That script is for multibit CLASSIC... it is even in the script name... decrypt_multibit_classic_walletkeys.py

That script is NOT designed for MultiBit HD... the only MultiBit HD script is: find_unspent_multibitHD_txes.py

In any case, if you want to recover your seed and you have mbhd.wallet.aes file and password... try: https://github.com/gurnec/decrypt_bitcoinj_seed

[Autoband86]

Unfortunately I am still not able to find any solution, I've had the help of HCP to decrypt my wallet file, but his script outputs a 94 char Private address, which of course is wrong. None of the 64 char slices from the address actually seem to be my private address...

Does anyone know how the wallet.cipher files are encoded? Or how the encryption of the bitcoin wallet can be split to see which parts are encoded/where the IV and Salt are?

[HCP]

Does anyone know how the wallet.cipher files are encoded? Or how the encryption of the bitcoin wallet can be split to see which parts are encoded/where the IV and Salt are?

So as I PM'd you... I went ahead and read through the multibit code to figure out the file format for the wallet.cipher files... and how they are meant to be decrypted... Then attempted to recreate that Java code in Python... I did a quick test and it seemed to decrypt my wallet.cipher (using my wallet password) and spat out an unencrypted wallet file containing unecrypted keys... and displayed my addresses and private keys... so I *think* it works...

#fingersCrossed

For anyone who wants to try it or is curious, the "ugly code" is currently here: https://pastebin.com/2PYVG6My

Once it is confirmed that it is working "properly" and with some more testing, I'll tidy up the code and add it to the github project

[vamosrafa]

Any luck gentlemen,

I am having the same issue, although I am less competent at code than both of you. My situation was pretty similar.

HCP scripts appear to attempt to decrypt the keys and wallet file, but I get the same error message as Autoband86.

I was chatting with a couple of the original devs on Github about this who were not of very much help. I can offer up a bounty of 1BTC for a solution.

HCP the wallet cipher decryption did not work for me either   (I have all the same files as autoband and confirmed in the wallet.info file the wallet with the address with the bitcoin)

I think what I did is upgrade from version .14 to version .15 then I put in the password. Prior to testing if the password unlocked the wallet I transferred the coins to cold storage from the exchange (since everyone tells you to do that) now they might be in permanent cold storage

I was thinking about buying a keep key as they have a script to move private keys from Multibit classic to their device, as a hail mary as well...

[HCP]

 I've sent you a PM... I'll have a play with some old versions of MultiBit Classic when i get off shift tonight... hopefully i can replicate these different file formats and figure out exactly what these 94 character strings are...

[vamosrafa]

Unfortunately I am still not able to find any solution, I've had the help of HCP to decrypt my wallet file, but his script outputs a 94 char Private address, which of course is wrong. None of the 64 char slices from the address actually seem to be my private address...

Does anyone know how the wallet.cipher files are encoded? Or how the encryption of the bitcoin wallet can be split to see which parts are encoded/where the IV and Salt are?

Autoband are most of your .cipher files in Chinese? Wonder what caused that?

[Autoband86]

I have not had any code in Chinese, I haven't been able to crack the keys yet, but gave it a rest, considering there was no urgent need. However, I would like to recover my coins one day 

[filbanum]

Hi there,

I have more or less the same issue except that I've been able to decrypt the key with openssl :

$ openssl enc -d -p -aes-256-cbc -a -in First-data/key-backup/First-20140130220522.key -out file.key
enter aes-256-cbc decryption password:
salt=84D98ZEDAAF43B7F
key=7EB90668080C400F0E90E2CBZLDP7B29A036E2C9B59194BE5D330324D4F6C70
iv =1277FA41948C21AA8E3A721DDBC12841

The decryption seems to be ok :

$ echo $?
0
The problem is that I don't obtain a text file in file.key :
$file file.key
data

same thing when I use decrypt_multibit_classic_keys.py I got some binary caracteres as output. nothing that looks like a private key.

Does anybody understand why the output is not plain text with both openssl and decrypt_multibit_classic_keys.py ?

Thanks   


 

[filbanum]

The problem is that I don't obtain a text file in file.key :
$file file.key
data

same thing when I use decrypt_multibit_classic_keys.py I got some binary caracteres as output. nothing that looks like a private key.

Does anybody understand why the output is not plain text with both openssl and decrypt_multibit_classic_keys.py ?

If I use decrypt_multibit_classic_walletkeys.py I have this output :
File NOT Encrypted
--------------------------------------------------------------------------------
Keys are encrypted
terminal does not support UTF; passwords with non-ASCII chars might not work
This wallet file is encrypted, please enter its password:
incorrect password

How the password from the wallet can be different than the password of the key ?

 

[HCP]

It shouldn't be... it sounds like either the password you are entering is incorrect, or the file is corrupted so the decryption fails and the script detects this as an "incorrect" password

Which file are you attempting to run the script on? I think you may be using the wrong script... walletkeys.py was made for extracting keys from a wallet file...