Topic: [HELP] Finding deleted 2009,2010 wallets from original early Bitcoin client (Read 702 times)

Then how, other than waiting another 4 weeks for the latest Bitcoin Core to sync?

That's too complicated.

With Bitcoin Core v0.15.1, the old wallet.dat files I could try each of them by copying wallet.dat to this directory?

C:\Users\{user name}\AppData\Roaming\Bitcoin

I did this with one of them and some how my wallet went from one key that was 16k to 2400 keys with a size of 2400k.  But it has not synced yet so balance is 0.  When I dump keys with pywallet they do not look like bitcoin addresses though.  They look like sha64?

Rather than waiting weeks for this thing to sync, could I copy each of these addresses to blockchain info and I think it is called sweep to determine the balance?

https://www.piriform.com/recuva

This works well to recover wallet.dat files. I have recovered many files from hd's over the years using this tool

Given this situation I also strongly suggest you take two dumps of each drive. Put them in separate storage locations, then put the original drives in a safe.

The dump files are much easier and safer to work with.

It's entirely possible that you try to retrieve the data, and fail. But a year later, a method occurs to you or is suggested, that is worth a try.

Have patience, don't give up, study and learn about data retrieval techniques.

pywallet has not recovered any keys from any of the chunks from the grep or from any of the disks.  It creates recovered_wallets and partially_recover_wallets but without keys.  I will try the manual WIF key conversion on the data as you described.   thx

They're probably unprintable.
But if you convert the output to hex (e.g. with hexdump or xxd), then after visually identifying the starting sequence, you can take the next 32 hex bytes, concatenate them to a string like "DECAFBAD0ABBCDE7F...", and convert them to WIF keys with a
 tool like bitaddress.org (It should always be used offline!)


Also, pywallet can recover the keys directly from a corrupted filesystem on a disk, see --recover, --recov_device and --recov_size.

e.g.
"20Go" is the size required.
The output directory must exist.
You will need to set the password of the recovered wallet to something you'll not forget.
The list of passwords can be empty, just press enter on the "Possible passphrase" prompt.

It searches for keys in the way described by you (looking for data string above), but converts them automatically.

They are 30 characters unfortunately and pywallet against the text file I created through grep does not get them out.  I tried db_recover, no good.  Also tried your dump keys program from here https://bitcointalksearch.org/topic/m.26661685

Is this the kind of thing you add two characters to the beginning like 08, gives you 32 and then you convert the keys to Bitcoin format and do something with converting the pair, or the other way around?

Any ideas?

edit: maybe they are 32 with the Berkerley DB masking the last two characters as ^@  or the first as   or ^]

Those 32 character groups (after the sequence) are your private keys.
You've probably found your wallet file.

Will try that to but I think those key names like keymeta are for later code? Not February/March 2009 and 2010?

Anyway I tried the grep above and I am getting chunks of some sort of keys back.  There are a repeating sequence of 30 characters which looks like shortened SHA followed by 8 garbage characters followed by another set of 30 character SHA.

You should try to do a binary-search of the harddisk for the magic bytes of wallet.dat

Anyone familiar with grep?  Does this look right?

grep -i -a -B10 -A100 --binary --text --perl-regexp 'fd1701308201130201010420' /dev/sda1

I thought I found one but no. What do you think of pywallet 2.2?  Does it really cover all the hex and handle fragments on an hd for that period?  I have used that most on every hard disk.

I did start out with recurva, nothing relevant in deleted files. Then tried photorec, they even had a signature Bitcoin Armory wallet, not sure if that was the same, but tried it along with a hex that was different from the one above.  Was thinking of going back through the disks with winhex trying the hex above, but if pywallet covers them all then what is the point I guess.  Already been at it for weeks, going insane over it.

The private key should be part of the wallet file, as the wallet file is what holds all of your keys. In the event that you just have a randomly private key lying around somewhere, you can at least know that you are making progress, and access the funds on the address the private key is associated with (could be all your mining earnings, could be nothing).

If I only find a private key does that get me anywhere?

I have it mounted separately so nothing is going to get written to it since grep is being executed from the boot disk, any temp files or output by grep will be written there.

What about that second part, about the encryption, is it all just unencrypted Berkerely DB prior to 2011? (I do not remember it that way, maybe I am confusing converting it from text to berkerely DB why I thought it was encrypted and mistaken about password encrypted - faulty memory)

No, that doesn't seem correct.
I recommend dumping an image of the disk drive (you should keep a copy, NEVER do anything on the disk you're trying to recover the data from!)

Then you can use a hex editor such as Okteta to search for the hex string in the dump file.

Does this look right?

grep -i -a -B10 -A100 --binary --text --perl-regexp 'fd1701308201130201010420' /dev/sda1

Doing some research I just read a blog that says wallet encryption was not until version 0.4.0 on September 23, 2011?

If that is correct does that mean the wallet.dat before that date are plain text or still Berkerely DB?  If it is in Berkerely DB would that mean I could retrieve the entire wallet including all keys by simply using db_dump.py on a found wallet.dat file?

thx

Try searching for the hex string "fd1701308201130201010420".
In old wallet files, a 32 byte sequence following the above string will be your private key.

Hi, I have a few questions in my long shot to recover lost mined coins from 2009 and 2010. The hard disks I am searching through have since been overwritten with Linux ext3 partitions, NTFS or FAT32. I have tried Recurva no luck and photorec but was unsure whether the contents were just some other program using Berkerely DB.

So my questions are:

1. I have also been using pywallet 2.2 in this fashion:  pywallet.py --recover --recov_size {disk size}Gio --recov_device={partition} --recov_outputdir={working directory}

Does pywallet 2.2 sufficiently cover 2009 and 2010? It is finding allot of files but reports 0 encrypted or 0 unencrypted keys.

2.  For an unencrypted wallet file what would be the ideal text or hex pattern I should be searching for that period?  Much of the info I am finding here is for later recovery and from what I understand the format changed a bit.  I suppose if someone could post an unencrypted example from back then of parts that never change, that would be ideal. (not much luck finding samples here, or Bitcoin.com or google).

3.  Same question as #2 but for an encrypted wallet file.  Going from memory I remember I could read what I mined in a text file assuming wallet in 2010 and 2009 I remember doing something where I could no longer read the file, assuming password encrypted.