Recovering funds

[markburns]

I have an old multibit classic wallet with some bitcoin in.

It is password protected, and after following the instructions for determining passwords I managed to use openssl to determine the correct password.

openssl enc -d -p -aes-256-cbc -a -in wallet.key -out restored.key -pass pass:<some password>
salt=18...
key=95...
iv =9C...

This saves a binary file with 79 bytes in it to restored.key

Trying to turn various combinations of the bytes in here into private keys has not been successful. I've tried over 200,000 combinations all leading to invalid keys or leading to different public addresses. So I don't think this is the private key.

Here @jim618 mentions that these are protocol buffer files.

Whilst I am not a java developer, I am familiar with what protocol buffers is. However I am still having trouble working out where to look to determine how to decode this. I also can't find the bitcoin.proto file that was mentioned there.

FYI the wallet is from Nov 2013 (I have also had a quick look by checking out bitcoinj at around then, but can't find a protobuf definition).

Am I looking in the right direction? Is this 79 byte output a protobuf definition? What kind of object will it decode to?

Also are the salt, key and iv values related in any way? I presume that is info on how the file was decrypted and nothing to do with further decoding it into a usable private key or wallet object.

[jim618]

If you have the wallet and the password, why not just open it in MultiBit Classic ? The binaries are all available on https://multibit.org

[jim618]

Or if you just have the encrypted private key, create a new wallet (in MultiBit Classic) and import the private key.

[markburns]

Sorry I missed that out. It doesn't decrypt with that password in multibit itself, although openssl does decrypt it to a 79 byte file. Same problem for importing private keys. The error I get is:

The removal of the password failed. The error was "Could not decrypt bytes".

Which contradicts the fact that openssl could decrypt it. Has it decrypted it to garbage bytes?

Is this supposed to be decrypted to a plain text private key? Or is it a binary representation of an object or something else?

So maybe the advice on using openssl to determine the password is incorrect, or there is some kind of bug in multibit classic. Now I think that understanding the file format will be a quicker solution than determining and fixing a bug in a now old piece of software or heaven forbid openssl.

Does a 79 byte binary file make sense?

I don't mind getting my hands dirty, would just really appreciate a bit of guidance on what to look for. And particularly if I'm barking up the wrong tree with thinking this 79 byte binary is a good starting point.

[jim618]

Once decrypted the private key file is ASCII. There is a private key in WIF format and then a date (the age of the private key).

79 bytes is about the right length but you are after ASCII, not binary.

If you export the private keys from any MultiBit Classic wallet you'll get an example of the format. Note that we don't write out the long comment block preamble with encrypted exports but the payload is the same.

[markburns]

OK so it sounds like there is a problem with the private key file or the decryption of it. I had a look at the encrypted private key and it looks similar to another one I just created, so it must be a fluke that openssl thinks it can decrypt it but just outputs a bunch of garbage bytes.

Closing for now, hopefully I won't need to be back for further questions.

Thanks very much and I appreciate you taking the time to answer my questions

[markburns]

@ksaur No but I spent a bunch of time writing a tool to help try brute force the password. Still have no idea what it is.

[doge2021]

@markburns @ksaur do you resolved the problem. this is caused by a bug, stil have chance to recover. you may check, he helped me on dogecoin https://btc2doge.com/multibit-hd-wallet-seed-words-not-work/