Over .5 BTC in corrupt Multibit HD 0.5.1 wallet

[TheLANMan]

This is a pretty deep issue I have been working on and off at for the last few years for somebody and my bounty is .2 bitcoin out of the deal.

It is a tricky situation, but maybe someone might know of a way...

Wallet was affected by the 0.5.1 bug where you know the password, but upon reopening the wallet it tells you that the password is incorrect. From what I have read among the issues of Multibit's downfall was that there was issues with how UTF16 and UTF8 worked. Some of the characters would end up mangled into other characters for some people.

What makes the issue more complex is that this was the 1 time the person did not write down the seed words.

I have tried many different ways, but I am really curious about what I find in the .YAML files.

0.5.1 version YAML files contain values for:
encryptedPassword: "88 Characters with /, + and 2 = signs at the end"
encryptedBackupKey: "64 Characters with / symbols"

Not sure if I am missing a step, but when I run base64 decode I get an output of ">����P�......etc"

I feel I am missing something, but maybe someone can clarify what I am doing wrong here.

[TheLANMan]

Also, I can't seem to find the topic I was reading somewhere the other day. It was the only story I ever heard where the corrupt 0.5.1 wallet was brute forced and the password looked similar, but had some characters altered. I am curious as to the structure the corruption looks like as I have been throwing tokens, wildcards and other additional switches (--typos-delete, --typos-swap..etc) at it for weeks now. Does anyone know if the character count is always the same or is there truncation of any type? What kind of characters where involved as in were they all english characters.

Also, I assume if this could have been done, it would have by now.
Why hasn't someone made a script that replicates the bug of 0.5.1 where you input the original password and it outputs at least a rough idea of what it became?

Maybe I am wrong too because I have read 2 different things that make the claim to the password not working.
The UTF-16 BE issue as well as another issue with the version number being included in 1 part of the encryption and not later on through.

I am pretty techy, but some of this is not entirely clear.

[GoldTiger69]

The characters that you are getting out of the Base64 are bytes; that's why you can't 'read' them. I have worked with Multibit wallets in the past; and let me tell you, they can be a pain in you know where. If you want, I can try to recover/restore the wallet you are working with, just let me know.

Cheers.

[keychainX]

This is a pretty deep issue I have been working on and off at for the last few years for somebody and my bounty is .2 bitcoin out of the deal.

It is a tricky situation, but maybe someone might know of a way...

Wallet was affected by the 0.5.1 bug where you know the password, but upon reopening the wallet it tells you that the password is incorrect. From what I have read among the issues of Multibit's downfall was that there was issues with how UTF16 and UTF8 worked. Some of the characters would end up mangled into other characters for some people.

What makes the issue more complex is that this was the 1 time the person did not write down the seed words.

I have tried many different ways, but I am really curious about what I find in the .YAML files.

0.5.1 version YAML files contain values for:
encryptedPassword: "88 Characters with /, + and 2 = signs at the end"
encryptedBackupKey: "64 Characters with / symbols"

Not sure if I am missing a step, but when I run base64 decode I get an output of ">����P�......etc"

I feel I am missing something, but maybe someone can clarify what I am doing wrong here.


Did you solve this, we might have the answer...