Recovery Operation for an old Wallet.dat

[callerman]

Hello,

A few years ago, between 2011-2012, I remember mining with Bitcoin-QT. Of course, at that time, I didn’t have any knowledge about Bitcoin and ended up deleting Bitcoin-QT from my computer. It was an old computer, and I needed to free up some space. Yes, this is very unfortunate.

I have little to no technical knowledge, so I’ve been trying to recover this wallet for several years. I did manage to create a backup of the disk. As far as I remember, the computer wasn’t used much after Bitcoin-QT was deleted because it eventually broke down. I still have the hard disk and made a copy of it to work on.

Any advice or guidance would be greatly appreciated.

I’ve tried several methods to recover the wallet.dat file. I scanned the external drive using data recovery programs, but it seems the file name and path have been altered, so I don’t know how to locate it.

I searched for hexadecimal code strings like 0201010420 and found a lot of results. I converted these to WIF (Wallet Import Format) keys, but the unencrypted WIF keys turned out to be completely invalid. However, I did find one encrypted WIF wallet.

When I checked the address, it showed activity between 2014 and 2020, with transactions totaling 2.81 BTC. However, I’m certain this is not my wallet, as the balance should have been higher. Could this just be a coincidence?


By trying to recall more details, I remembered that my Bitcoin-QT wallet was encrypted, and back then, I used just a few passwords across all platforms.  I still remember those passwords. Later, I learned that the hex string 0201010420 doesn’t apply to encrypted wallets, or maybe I’m making a mistake somewhere.

Then, I came across another method using Pywallet. I installed Python 2.7.18, Pywallet, and necessary dependencies like ecdsa, twisted, pycrypto, and bsddb3 on Windows 10.

I ran the following command:

Code:

pywallet.py --dumpwallet --recover --recov_device=G: --recov_size=80Gio --recov_outputdir=C:\users\computer\desktop\newwallet

Enter the passphrase for the wallet that will contain all the recovered keys:

Enter the possible passphrases used in your deleted wallets.
Don't forget that more passphrases = more time to test the possibilities.
Write one passphrase per line and end with an empty line.
Possible passphrase:
Possible passphrase:
Possible passphrase:
Possible passphrase:
Possible passphrase:
Possible passphrase:
Possible passphrase:
Possible passphrase:
Possible passphrase:

Starting recovery.
.
.
.
.
.
Read 59.0 Go in 54.0 minutes

Found 0 possible wallets
Found 0 possible encrypted keys
Found 0 possible unencrypted keys


All the found encrypted private keys have been decrypted.
The wallet is encrypted and the passphrase is correct


Importing:


The new wallet C:\Users\computer\Desktop\newwallet/recovered_wallet_1734864041.dat contains the 0 recovered key

After these results, I scanned another wallet.dat file that I created with PyWallet in Bitcoin Core, and the result was the same. Right now, I don’t know what to do or which method to use. I’m writing here as a last resort, hoping we can find a few different methods. Thank you in advance for all the answers.

[nc50lc]

When I checked the address, it showed activity between 2014 and 2020, with transactions totaling 2.81 BTC. However, I’m certain this is not my wallet, as the balance should have been higher. Could this just be a coincidence?

With the size of a Bitcoin private key (almost 2^256), that can't be a random coincidence and you've properly restored one of the private key in that disk.
If you're certain that it's not yours, then you might have imported that private key that you got somewhere.

If you're expecting more bitcoins, those might be the other keys but each has at least one Bit flipped since it's already party overwritten or corrupted.
You could iterate one to a few bits difference of the result empty private keys;
e.g.: if your restored privKey is ...001010101 but the actual private key is ...001011101, you can try to switch each Bit of the restored prvKey to reproduce the correct prvKey.
But don't put your hopes on it since usually, the damage is a significant chunk, not just a few bits.

It's worth the try for a last resort but I can't find a tool that does that so you need a specifically written script for that.

[callerman]

When I checked the address, it showed activity between 2014 and 2020, with transactions totaling 2.81 BTC. However, I’m certain this is not my wallet, as the balance should have been higher. Could this just be a coincidence?

With the size of a Bitcoin private key (almost 2^256), that can't be a random coincidence and you've properly restored one of the private key in that disk.
If you're certain that it's not yours, then you might have imported that private key that you got somewhere.

If you're expecting more bitcoins, those might be the other keys but each has at least one Bit flipped since it's already party overwritten or corrupted.
You could iterate one to a few bits difference of the result empty private keys;
e.g.: if your restored privKey is ...001010101 but the actual private key is ...001011101, you can try to switch each Bit of the restored prvKey to reproduce the correct prvKey.
But don't put your hopes on it since usually, the damage is a significant chunk, not just a few bits.

It's worth the try for a last resort but I can't find a tool that does that so you need a specifically written script for that.

Hello, thank you for your response. While scanning hexadecimal values, I found multiple identical hex codes. For example, there are 15 instances of the value D030123456...47 00, and I converted only one of them into a WIF code. I found many similar results. Does this seem normal?


Am I correct in understanding that, using the method you mentioned, I need to convert the hexadecimal code into a WIF code and then randomly modify the prvKey values?

Also, could entering the wrong password while scanning with Pywallet lead to a result like the one above?

[nc50lc]

Hello, thank you for your response. While scanning hexadecimal values, I found multiple identical hex codes. For example, there are 15 instances of the value D030123456...47 00, and I converted only one of them into a WIF code. I found many similar results. Does this seem normal?

Those example may not be private keys since the possibility of randomly generating multiple collisions (or even one) is near impossible.
The logical explanation is those are may be from duplicate copies of your wallet.dat file or the same private key imported to multiple wallets or other data that's normally repeated.

Am I correct in understanding that, using the method you mentioned, I need to convert the hexadecimal code into a WIF code and then randomly modify the prvKey values?

You need to modify the private key one or multiple Bits per iteration.
To visualize that and to do it manually, you need the "binary" format, it's not something that can be easily done manually.
Flipping each Bit (change '1' to '0', vice-versa) at a time, maybe, since that's 256 iterations per private key, but with 2 or more, you'll need to automate it.

That suggestion isn't normally used to recover corrupted data since it's basically bruteforcing your way to reproduce the correct data.

Also, could entering the wrong password while scanning with Pywallet lead to a result like the one above?

No, pywallet will still show if there are encrypted private keys to be recovered from the "recov-device".
Providing the wrong password will result with failed to decrypt private keys, it'll show you an error message saying that the provided passwords do not work.

[callerman]

Hello again everyone,

I wanted to give a technical update and ask some detailed questions about my progress.

I have spent weeks working on this problem, trying to recover my old encrypted wallet.dat (Bitcoin Core, 2012–2014 era) from a full dd disk image. I strongly suspect that the original wallet.dat file has been fragmented (split into pieces) on the disk over time. The original filename and path were lost or changed, so standard data recovery programs (like Recuva, Photorec, TestDisk, etc.) have not been able to help.

I have written and used various Python scripts to scan the disk image for wallet fragments. These scripts can recover mkey and ckey data as separate pieces, but there seems to be no existing tool or ready-made program that can actually reassemble a complete wallet.dat from these fragments. So far, I have only been able to extract mkey and ckey blobs as individual fragments, not as a complete, original file.

I wrote and used several Python scripts to scan the .dd disk image for wallet fragments. My scripts look for both mkey and ckey structures, using entropy, struct, salt, and iteration count filters to try to select only genuine blobs. The scripts report blocks with high confidence, but sometimes I’m not 100% sure which results are “real” and which are false positives.

I can locate files or fragments that contain what appear to be valid mkey and ckey entries (sometimes with high entropy and correct struct). However, almost never in the same file or at the same offset—typically, one fragment has mkey, another has ckey. I have my password and am sure it’s correct. I tried creating “hybrid” wallet.dat files by combining mkey from one fragment and ckey from another (using PyWallet, manual methods, and so on). When I do this and try to open or dump the wallet, I usually get a checksum error—so the file is seen as a wallet, but keys cannot be used. Sometimes my script finds multiple candidate mkeys/ckeys with different offsets, and it’s not clear how to know which ones are valid or “complete.”

My main questions: If I have extracted “good-looking” mkey and ckey blocks (with correct entropy, struct and salt/iterations), is it theoretically possible to recover the encrypted private keys (knowing the passphrase) even if they are from different fragments? Or must they be from the exact same original wallet.dat? Are there proven methods (or real-world forum threads) where someone has matched mkey/ckey from different disk locations and successfully reconstructed a working wallet? Are there advanced scripts or workflows to help determine which mkey/ckey are actually a valid pair, or to brute-force through combinations, given many extracted fragments? Does the checksum error always mean a bad match, or can it be caused by other recovery problems?

I have tried PyWallet and also my own scripts; I know about the difference between encrypted/unencrypted keys (0201010420 prefix vs. ckey). I filtered for entropy, salt variation, iterations, and struct signatures, but sometimes blocks “look right” yet fail in decryption. I’m not sure if my “good” mkey/ckey are really valid, or if there’s something I’m missing in their extraction or recombination.

If anyone here has successfully recovered a wallet this way, or can point to forum links or scripts for this exact “mkey/ckey from disk fragments” situation, it would be a huge help. Thanks for any ideas or references!

[whanau]

I put this up a while back.
Have a look at the last post. OFFLINE you will be able to substitute and test your information.
You can also modify it to make it more useful to you

https://bitcointalk.org/index.php?topic=5331322.0

It will be a long process good luck.

[Cricktor]

Something to OP's story doesn't add up. At the start of 2011 difficulty and network hashrate were already at a level where you couldn't really compete to mine blocks with a CPU alone. And OP speaks of an old computer...

Yes, I'm aware OP might have left out some specific details, but I'm pretty sure you couldn't mine anything with a CPU alone. GPU mining software was already a thing and later in 2011 first FPGA miners surfaced which started to smoke the GPU miners, IIRC.

I mined in spring or summer of 2011 with a modest GPU and I had to use a mining pool to pick up some breadcrumbs (ok, ok, it wasn't that bad but still took quite some days to mine a whole bitcoin).