Is it possible to recover the private key of a partially overwritten wallet?

[JAMBO2014]

Hi everyone,
I have a problem with my wallet file.
The Multibit application cannot read the wallet because it was damaged with an overwrite and therefore I cannot have the BTC acquired in 2014.
I would like to understand if it is possible to trace my private key and recover the BTC inside the damaged wallet file.
I offer a reward to anyone who will be able to help me find my private key.

thanks a lot

[BlackHatCoiner]

So you're saying that you overwrote the wallet file? You replaced it with another one in the MultiBit's folder? I guess that private keys have nothing to do with this. If your old wallet file is the only one that has the private keys then you have to restore it.

I don't know if this will help, but I'll share it: https://www.easeus.com/file-recovery/recover-overwritten-files.html
I hope you "just replaced it" and not something worst.

[NotATether]

Do you still have the seed phrase of the damaged wallet? If you do then the wallet file is unnecessary. And by the way, Multibit development stopped in 2017 so I recommend installing a newer wallet software such as Electrum and create a new wallet, and follow the instructions to import your seed phrase to recover your funds.

MultiBit was a lightweight "thin client" Bitcoin wallet for Windows, MacOS and Linux based on bitcoinj. It was superseded by MultiBit HD, and the development of both stopped in 2017[1] after the acquisition by KeepKey, which was then bought by Shapeshift.

[JAMBO2014]

The pc containing the wallet file was formatted and reloaded the operating system, subsequently when I realized that I did not save the private keys correctly I recovered the wallet file, but it is partially overwritten and not readable by Multibit.
I tried to open it with the HxD editor program to check if my private key was intact anyway, and I tried to open some 32 Byte strings and I read them with the bitaddress.org program, but here I stopped.
Can't figure out what the exact 32-byte srtring is.

[BlackHatCoiner]

The HxD editor will show you the hexadecimal value of the private key. If you found it then you'll have to convert it to WIF and then import it to a wallet like electrum. The issue I see you facing is that you don't know what is the right 32 byte strings.(?)

when I realized that I did not save the private keys correctly I recovered the wallet file, but it is partially overwritten and not readable by Multibit.

How is this possible? Did you properly restore it? Did you install the same version of multibit you had? If the restored file is "changed" during all these formats and reloads, then you're f*cked. I don't understand how could this occur, though.

[Welsh]

If you have the private key or the seed then you're perfectly fine. However, I'm not quite sure what you mean by overwriting a wallet? If you've replaced the file with a new wallet.dat, then the only way of recovering it would be either taking a look at the filesystem, and maybe having a chance of salvaging the contents. Although, this gets more unlikely the more you use the device, since it will continue to write to the storage device.

On the other hand, if you have replaced your wallet.dat, with the same wallet.dat that contains your addresses, and sensitive data then that should be fine, and it might be as simple as re scanning if the wallet software is spitting out an error.

If the former is true, then depending on your operating system depends on the course of action. Windows based systems are a little bit harder, and its usually recommended to download third party software for this, for it to be effective. There's many out there, but you'll have to verify whether they are safe. I'm not fan of this approach. If you're using a Linux based system, then you can do it from the terminal most of the time. Debian based system, Ubuntu has a page on this: https://help.ubuntu.com/community/DataRecovery where they give programs that might be able to do it, most of these operate from the terminal though.

If you don't have your private key, or the data simply doesn't exist using the methods above, then unfortunately there is no other way to retrieve the private key. Its recommended by a few people, to keep a physical copy of your private key. Many people use different techniques for this, but the best way would likely to have it written down by hand, boot up a livecd of Ubuntu without internet, and then check that you can import the private key successfully, and that it corresponds with your Bitcoin addresses.

[JAMBO2014]

The problem is that with ExD editor there are so many hexadecimal strings that could be the private key, but I don't know which one is correct, there are programs that can look for it?

[BlackHatCoiner]

The problem is that with ExD editor there are so many hexadecimal strings that could be the private key, but I don't know which one is correct, there are programs that can look for it?

For how many hexademical strings are we talking about? Do you want to give us an example? Upload me a wallet file that has no funds from the same software, tell me what's the address and I'll open it with HxD. Just to check if I can do this. I think I can make a script that will brute force all the strings as private keys. But again, this requires the existence of private key within the file. If it's not there or it's written on mnemonic format, the whole procedure changes.

[JAMBO2014]

in this link you should see the hexadecimal image of a typical btc wallet opened with Multibit classic 0.5.17

https://imgur.com/a/f9qoEd0


this highlighted is the string of a typical private key with Multibit:

https://imgur.com/a/Ephrt5q

[BASE16]

Yes you can do a bit by bit scan.
You start at the beginning of the drive and take a 256 bit chunk of the raw data which will represent a private key, and turn that into various address types.
Then you check these addresses on the blockchain to see if they hold any balance.
If not then you shift the 256 bit chunk by one bit and you try again.
This way you wade through all bits on that drive, until you either reach your desired address, or the end of the drive.
If it is still on there then it will find it because the chunk of 256 bit will represent your binary private key which will be calculated into the target address that is holding the funds.
Make sure to also check the binary key in reverse, because sometimes the bits of the key are stored backwards on the drive.

However, if your keys are partly overwritten, as you said then it will not work.
It will only work when the all bit's of the key are there.
So at this point it is important to discuss why you think it's partly overwritten and how you think that this situation occurred.
If you think this because you re-installed the wallet and fear that it had overwritten the old wallet then it's a good idea to scan the drive because it is possible that it just put the new wallet onto a different block on the drive without actually overwriting the old one, so that would imply that the old one is still there fully intact as raw data, just not visible to the file system anymore because the file table is pointing somewhere else, to the new wallet file.
This also means that you will not find it by examining the new wallet file which possibly exists at a different location so a hex viewer isn't going to help unless you know the location of the old file which is basically invisible to the file system.

 

[BlackHatCoiner]

this highlighted is the string of a typical private key with Multibit:

https://imgur.com/a/Ephrt5q

Try putting the data you find here: https://gobittest.appspot.com/Address
Then check the address on a block explorer. Except if you remember how your address looks like.

[HCP]

in this link you should see the hexadecimal image of a typical btc wallet opened with Multibit classic 0.5.17
https://imgur.com/a/f9qoEd0

this highlighted is the string of a typical private key with Multibit:
https://imgur.com/a/Ephrt5q

That is correct... for unecrypted MultiBit classic wallets... the private keys (in hex) are the 32 bytes after the byte sequence "1A4E08011220"

However, if you can't find that byte sequence in the file and see some text towards the end of the file like: "org.multibit.walletProtect.2" then your wallet file is encrypted and you'll have to hope that the overwriting/corruption hasn't broken the file so that it can't be decrypted.



You can try using my "decrypt_multibit_classic_walletkeys.py" script from here: https://github.com/HardCorePawn/multibit_recovery (Requires Python 2.7 and a couple of dependencies installed, install instructions here).

If the wallet file is unencrypted, it should just output addresses/keys... if it is encrypted, it should prompt for the wallet password and once the correct password is entered, will output the addresses/keys.

If you get some sort of parsing error, chances are the file is corrupted. You might still be able to extract some keys if the wallet file was unencrypted, but if it was encrypted, then you're likely going to be S.O.L.

[HCP]

As an update for the interested observers... I've spent a few days trying various tihngs with the OP... initially they tried my multibit recovery scripts, but they were not able to read the wallet file as a "wallet file"

Then we tried inspecting the wallet file to see if it was encrypted or not, it does not appear to be an encrypted file.

Then we tried inspecting the wallet file using a hex editor looking for specific "key" markers... but they were not found. This was not great news and indicative of the file being badly corrupted and no keys being salvagable.

In a "grasping at straws" effort, I created a small python script which basically just converts EVERY 32 byte sequence in the file into a private key (stepping through 1 byte at a time)... it generated 8999 private keys from the OP's "wallet" file!!!

Alas, even after they imported them all into Electrum (1000 keys at a time into 9 separate wallets), no BTC or transaction history was found.

I can only conclude from this, that the wallet is so badly corrupted that no private keys can be recovered from this file (at least, not without some major "magic" )

[itod]

In a "grasping at straws" effort, I created a small python script which basically just converts EVERY 32 byte sequence in the file into a private key (stepping through 1 byte at a time)... it generated 8999 private keys from the OP's "wallet" file!!!

9K long wallet seems to be too short for a wallet file. Best option for OP is to make a dump of the the whole corrupted disk in the state before recovering the wallet.dat file, if it is possible. Some other file file recovery tool may get better results of finding parts of wallet file on the disk which may hold the actual key, but were lost during file recovery process.

[itod]

In a "grasping at straws" effort, I created a small python script which basically just converts EVERY 32 byte sequence in the file into a private key (stepping through 1 byte at a time)... it generated 8999 private keys from the OP's "wallet" file!!!

9K long wallet seems to be too short for a wallet file.

Too short? I find it too long since there's no reason to generate 9K private keys, even Bitcoin-Qt (before HD wallet exist) only pre-generate 100 private keys.

If I remember correctly size of the Bitcoin-QT wallet with only 100 keys was around 100k bytes. When they increased the number of pre-generated keys in the key-pool to 2000 size of the wallet went up to 1MB.

Multibit may store keys in much more optimal format than Bitcoin-QT, but 9k still looks too small to me. Maybe it's a good idea for OP to install version 0.5.17 on fresh computer and see how big the initial wallet will be.

[HCP]

An initial multibit wallet holds 1 key... by default it'll be somewhere around ~164 bytes... it could be a bit more if the user-defined "wallet description" that you enter within the app is quite long... Adding another 20 keys will extend the size out to around ~1790 bytes... a wallet file with 101 keys (and no transaction or other data) is around ~8100 bytes...

If I remember correctly size of the Bitcoin-QT wallet with only 100 keys was around 100k bytes. When they increased the number of pre-generated keys in the key-pool to 2000 size of the wallet went up to 1MB.

Multibit may store keys in much more optimal format than Bitcoin-QT, but 9k still looks too small to me. Maybe it's a good idea for OP to install version 0.5.17 on fresh computer and see how big the initial wallet will be.

They use a "protobuf" format... it is basically just straight serialization of text, so it doesn't have much overhead like the Bitcoin QT LevelDB format. So, I would say that a 9k file isn't really "too small" for a multibit wallet file.


The reason the script found ~9000 keys is because it stepped through 1 byte at a time, read the next 32bytes and used that to generate a private key... It did this as there was no way to determine which exact 32 byte sequence was a private key (if any), as the OP could not find the "1A4E08011220" byte sequence which is the "marker" for private keys in an unencrypted multibit wallet file.

Again, I suspect the recovered file was simply too damaged to be useful.