Suggest you stick with 1 thread: https://bitcointalk.org/index.php?topic=2383713.new#new
Topic: Trouble recovering Multibit Classic Keys - page 3. (Read 15313 times)
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
Suggest you stick with 1 thread: https://bitcointalk.org/index.php?topic=2383713.new#new
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:
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
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:
Quote
assert bin_dbl_sha256(data[:-4])[:4] == data[-4:]
AssertionError
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.
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.
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.
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.
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.
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.
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.
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...
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...
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 ?
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
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
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 
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?
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?
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...
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...
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...
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
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?
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?
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...First: find_unspent_multibitHD_txes.py. That works fine.
Quote
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
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
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
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??!?
Quote
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:
--------------------------------------------------------------------------------
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:
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...
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...
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.
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.
"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.
Jump to: