Trouble recovering Multibit Classic Keys

[Dorky]

Do NOT use Multibit to encrypt your keys.
Even it can't decrypt its own encryption.
I know because I have such experience.
You, the thread starter, are better off exporting the keys and encrypting them directly on your own, like using WinRar or any encryption software that you know to be very reliable (anyone who says WinRar is unreliable and/or untrustworthy, please state the evidence proving that is so).
Different wallets may use different methods of encryption and so decrypting the keys may not be compatible between different wallets.
Multibit is no longer supported now.
You have been warned.

Edit:
I was lucky I didn't uninstall my Multibit after encrypting my keys with it, so I managed to export the keys unencrypted, and encrypt them myself.
Or else, I would be in seriously deep shit.

[1715109064]

1715109064

[1715109064]

1715109064

[filbanum]

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...

Thanks for your reply. Yes, walletkeys.py for the wallet

In fact, I found an interesting thing that can be usefull to other people who forgot their password (like me) :

=> you CAN'T rely on OpenSSL to be sure that your key has been unencrypted

I generated 210000 passwords with crunch and I used this command line to bruteforce the key :

cat passfile | while read i ; do pass=`echo -n $i` ;  openssl enc -d -p -aes-256-cbc -a -in enc.key -out clear.key -pass pass:$pass && echo $pass && exit ; done

When the script stopped first I was very happy but the pb that I described previously on this thread appears. Then I modified the command like that :

cat passfile | while read i ; do pass=`echo -n $i` ;  openssl enc -d -p -aes-256-cbc -a -in enc.key -out clear.key -pass pass:$pass &&  && echo $pass >> PASS ; done

So the script doesn't stop when the key is decrypted at the first time.

Guess how many password there was in PASS ??

$ wc -l PASS
1049 PASS

So, OpenSSL has decrypted the key with 1049 different passwords !! :-D

I gonna mofity the script to keep the output and to check after if the file is plaintext or not.
Antother possiblity would be to use walletkeys.py to bruteforce the key but I don't know yet if you can call it via a script. 

 
 

[vamosrafa]

I am approaching Dave at wallet recovery services to see if he has any ideas, so it might be of some help. HCP tried to figure out what the correct password decrypts to 94 characters using his utility but to no avail. I will report back here if Dave is able to help. I'll send some BTC to HCP if I am able to crack the wallet, it has now become a life changing amount of money stuck in the wallet.

[vamosrafa]

No response from wallet recovery services

Also I tried this guys tool, to export the private key, when I enter the wrong password it gives a bad decrypt error, when I enter the correct password it gives a "not a valid private key" error. The search continues.

[Simon H]

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

Hi I have a similar problem. And really need help....

I have Multibit classic 0.5.19 with BTC in it back form 2013. When I try to send or export the keys the password bug mean the correct on does not work.

I have tried the multibit to Keepkey utlity and i get error message no balance.
I have the .wallet .key and .wallet.cipher files but they are encrypted.

I used this script on GitHUb. But it showed me error messages when I entered my password. I worked and showed me the keys for my other no passworded Multibit classic wallets.

https://github.com/Multibit-Legacy/read-multibit-wallet-file/tree/c4956f1c5a1ecb2df7a5612c8d9ea04388cdde0f

I got to this page but how do I run the python script on my Mac in Terminal?
https://pastebin.com/Z2zfbwiv

I hope this will work and will decrypt my .keys file. The BTC in there is worth a lot to me so any help will be appreciated.

[HCP]

Please don't cross-post across multiple threads... you'll get answers all over the place. It wasn't necessary to start a thread requesting help in the Dev & Tech Discussion section, a thread in the MultiBit section and then "necropost" 2 other threads with the same request

Suggest you stick with 1 thread: https://bitcointalk.org/index.php?topic=2383713.new#new

[Autoband86]

Do NOT use Multibit to encrypt your keys.
Even it can't decrypt its own encryption.
I know because I have such experience.
You, the thread starter, are better off exporting the keys and encrypting them directly on your own, like using WinRar or any encryption software that you know to be very reliable (anyone who says WinRar is unreliable and/or untrustworthy, please state the evidence proving that is so).
Different wallets may use different methods of encryption and so decrypting the keys may not be compatible between different wallets.
Multibit is no longer supported now.
You have been warned.

Edit:
I was lucky I didn't uninstall my Multibit after encrypting my keys with it, so I managed to export the keys unencrypted, and encrypt them myself.
Or else, I would be in seriously deep shit.

How were you able to export your keys unencrypted after you encrypted them? Did you have the same AES key is Wrong error? Has anyone else with this error been able to recover their wallet keys?

[Spockrates]

I'm having a similar problem and have tried everything in this thread.

Running the script on my Multibit key file generates a string of characters that I don't quite know what to do with. 72 characters long, lots of this sort of stuff:

Code:

Wá
IΦB

Any ideas? Thanks!

[HCP]

And that is a MultiBit classic .key file?

Does the script generate a "parsed_wallet.txt" file? Does that file have some "encryption" information at the end like the salt and iterations and encryption type?

[Spockrates]

And that is a MultiBit classic .key file?

Does the script generate a "parsed_wallet.txt" file? Does that file have some "encryption" information at the end like the salt and iterations and encryption type?

Hey, thank you for replying!

It's a Multibit classic .key file and I don't see a "parsed_wallet.txt" key. There's no information either.

Running:

Code:

openssl enc -d -aes-256-cbc -p -md md5 -a -in multibit.key -out newtest.txt

Gives me:

Code:

salt=2160B0AD6A6A5181
key=B0C5233E10A1227719077F3D5195ED45A5ABDEA796286F46120F2F86EF271251
iv =78A8C8A78F60194F0D44751683E1EC6A

But a file that again is jibberish.

ANOTHER EDIT:

If I run:

Code:

openssl enc -d -p -aes-256-cbc -a -in multibit.key -out test5.txt

Like it says to here: https://github.com/Multibit-Legacy/multibit/wiki/Export-and-limited-import-of-private-keys

It gives me this:

Code:

salt=2160B0AD6A6A5181
key=5340CEB7D94A3FE9754832332D9F3956B17B296E548FBCC85C74D4B658F72329
iv =BD773CE174D69C8716DB6264CDECD550
bad decrypt
20756:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto\evp\evp_enc.c:536:

Though, I'm pretty sure this is the correct password as it's the only one that doesn't get the password error when I tried to unlock in Multibit classic. Instead it gives me:

Code:

The private keys unlock failed. The error was "Could not understand address in import file".

[vamosrafa]

Spockrates,

What error does it give you when you type in your correct password in the actual multibit software GUI?

Autoband and I both get provided AES key is wrong instead of the usual "could not decrypt bytes"

Thanks

And that is a MultiBit classic .key file?

Does the script generate a "parsed_wallet.txt" file? Does that file have some "encryption" information at the end like the salt and iterations and encryption type?

Hey, thank you for replying!

It's a Multibit classic .key file and I don't see a "parsed_wallet.txt" key. There's no information either.

Running:

Code:

openssl enc -d -aes-256-cbc -p -md md5 -a -in multibit.key -out newtest.txt

Gives me:

Code:

salt=2160B0AD6A6A5181
key=B0C5233E10A1227719077F3D5195ED45A5ABDEA796286F46120F2F86EF271251
iv =78A8C8A78F60194F0D44751683E1EC6A

But a file that again is jibberish.

ANOTHER EDIT:

If I run:

Code:

openssl enc -d -p -aes-256-cbc -a -in multibit.key -out test5.txt

Like it says to here: https://github.com/Multibit-Legacy/multibit/wiki/Export-and-limited-import-of-private-keys

It gives me this:

Code:

salt=2160B0AD6A6A5181
key=5340CEB7D94A3FE9754832332D9F3956B17B296E548FBCC85C74D4B658F72329
iv =BD773CE174D69C8716DB6264CDECD550
bad decrypt
20756:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:crypto\evp\evp_enc.c:536:

Though, I'm pretty sure this is the correct password as it's the only one that doesn't get the password error when I tried to unlock in Multibit classic. Instead it gives me:

Code:

The private keys unlock failed. The error was "Could not understand address in import file".

[Spockrates]

I get this:

Code:

The private keys unlock failed. The error was "Could not understand address in import file".

[kriwan]

I'm helping someone with a multibit wallet that was made back in 2014 and I'm getting the same issue as Autoband86 with the hex of the private key from HCP's script spitting out 94 characters instead of 64. Are there any characters within the parsed wallet that could be indicative of a corrupt file? Or maybe the number of characters. Maybe I'm being dumb but I can't quite figure out how the strings like "}\5\027\120\334D3" translate to the alphanumerical keys. (Yes I was being dumb, answer was earlier in the thread.)

EDIT: So I've tried importing all 64 character slices of that 94 character string (all encoded as actual 52 character private keys) but none of the private keys match up to the original address. What is the likelihood that an issue with the initial encryption led to it not even being the private keys being encrypted? Would there just be no recourse in that case? From what I can gather it's mostly likely to have been an issue with the encryption header.

[HCP]

Would like a feature to input a file with possible passwords rather than one password. Basically run a dictionary attack against my wallet through the script.

I have a list of possible passwords.

If you're trying to crack the password, then maybe you want to try gurnec's btcrecover scripts: https://github.com/gurnec/btcrecover

However, it appears that the issue is generally not a bad password... or bad encryption... but bad data being encrypted. It seems that MBC has somehow screwed up the data when it is being encrypted, so what is actually being written to disk is effectively useless when decrypted... ie. Garbage In, Garbage Out...

I still have absolutely no idea what these 94 character "private keys" are... or how they were generated in the first place??!?  

I've been unable to replicate this problem.

[kriwan]

Considering that MBC is open source, has anyone tried to replicate it using the exact same code and password with a salt from one of these "bad" wallets? And using a key from someone who came across this issue but managed to keep an unencrypted backup?

Or maybe just running a script to keep generating keys, encrypting, and attempting to decrypt until a bad one comes up.

[HCP]

Considering that MBC is open source, has anyone tried to replicate it using the exact same code and password with a salt from one of these "bad" wallets? And using a key from someone who came across this issue but managed to keep an unencrypted backup?

Or maybe just running a script to keep generating keys, encrypting, and attempting to decrypt until a bad one comes up.

For reference... the code dealing with the Encryption/Decryption is here: https://github.com/Multibit-Legacy/multibit/blob/master/src/main/java/org/multibit/crypto/KeyCrypterOpenSSL.java

Interestingly, there was a commit (https://github.com/Multibit-Legacy/multibit/commit/b2dfb4b3f9a8e7305b737bf76b0176c4560aa25e#diff-479841ac9117242ee643ad7c13727b58) back in 2013, where the char[] was changed to a CharSequence... CharSequences are UTF-16, not UTF-8... I think this was in v0.5.9?

and another commit (https://github.com/Multibit-Legacy/multibit/commit/2d3f9cbcbad330920da0797ec0758fd4b0df5236#diff-479841ac9117242ee643ad7c13727b58) which fixed the padding for the encryption... which looks like it was v0.5.18

I'm not able to find a version v0.5.9 to download... so the only way to test is to download JDK and Maven and the 0.5.9 source package and compile it... which I am currently doing

EDIT: And was unsuccessful... seems it is a bit outdated and there are missing links which is breaking the maven build and I just don't have the time to try and figure out my way around it...

[Mat008]

Hello,

I'm sorry, that tread is pretty long and I'm trying to see clear... Can someone please help me wrap this thing up? I have very basic programming knowledge.

I'm having trouble with Multibit version 0.5.16 on a MacBook Pro running OS X El Capitan 10.11.6.

When trying to remove the password from the wallet using the proper password, Multibit is returning the following error message:

    "Provided AES key is wrong"

When entering any wrong password, Multibit is returning another error message :

    "Could not decrypt bytes"

There is a problem with Multibit since it will not unlock my Bitcoins when providing the right password. What is the solution to the problem ?

I've noticed that other users were experiencing the same issue.

I can't believe my coins will stay locked!?

Please help me! Thank you very much!

[Autoband86]

I guess there are quite a number of people now experiencing the same problem. I have to mention I have been using multibit 0.5.15 on a mac. I'd like some confirmation whether others are using the same version and system?

Like one of you I base64-decoded my keyfile, which gives me a Salted__kjncisiflsjfnlkasnetcetc output. This shows me that the keyfile has not been damaged during the time I had it on my computer. And that the problem lies before multibit's base64 encoding.

The fact is, the script is trying to emulate openssl AES 256 encoding, but it might be that it doesn't do that entirely correctly. At the same time it might actually be trying to decode it correctly, which results in an error. Although I still do not get the "AES key is wrong" error.

Another interesting thing I noticed is that the 0.5.15 version is not on github. I thought it was there before, I might be mistaken.

[Spockrates]

I was finally able to open the file by using BTCRECOVER to find the password. It turns out what Multibit was implying was the right password, actually was not. BTCRECOVER allowed me to enter parts of what I knew were in there and it tried a bunch of different combinations.

https://github.com/gurnec/btcrecover

Hope this helps somebody!

[Mat008]

This seem to be a password recovery procedure... I don't see how it can help in the case where Multibit is corrupting some files. How many people are stuck with this problem? Can the old Multibit team do something about it? This is insane!