Bitcoin Forum
September 19, 2018, 12:05:25 PM *
News: ♦♦ Bitcoin Core users must update to 0.16.3 [Torrent]. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [HELP] Finding deleted 2009,2010 wallets from original early Bitcoin client  (Read 269 times)
idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 19, 2017, 05:22:02 AM
 #1

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.



Make a difference with your Ether.
Donate Ether for the greater good.
SPRING.WETRUST.IO
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1537358725
Hero Member
*
Offline Offline

Posts: 1537358725

View Profile Personal Message (Offline)

Ignore
1537358725
Reply with quote  #2

1537358725
Report to moderator
1537358725
Hero Member
*
Offline Offline

Posts: 1537358725

View Profile Personal Message (Offline)

Ignore
1537358725
Reply with quote  #2

1537358725
Report to moderator
1537358725
Hero Member
*
Offline Offline

Posts: 1537358725

View Profile Personal Message (Offline)

Ignore
1537358725
Reply with quote  #2

1537358725
Report to moderator
SopaXT
Full Member
***
Offline Offline

Activity: 161
Merit: 109


View Profile
December 19, 2017, 08:34:46 AM
 #2

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

idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 20, 2017, 06:16:17 PM
 #3

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

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
SopaXT
Full Member
***
Offline Offline

Activity: 161
Merit: 109


View Profile
December 20, 2017, 06:39:40 PM
 #4

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

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

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.

idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 20, 2017, 06:48:48 PM
 #5

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

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

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.

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)
idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 20, 2017, 09:56:05 PM
 #6

If I only find a private key does that get me anywhere?
DarkStar_
Legendary
*
Offline Offline

Activity: 1092
Merit: 1331

:D


View Profile WWW
December 21, 2017, 12:51:51 AM
 #7

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

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).

idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 21, 2017, 04:52:13 AM
 #8

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

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).

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.
idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 22, 2017, 08:15:27 PM
 #9

Anyone familiar with grep?  Does this look right?

grep -i -a -B10 -A100 --binary --text --perl-regexp 'fd1701308201130201010420' /dev/sda1
kahc
Member
**
Offline Offline

Activity: 294
Merit: 11


View Profile
December 22, 2017, 10:46:21 PM
 #10

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

Activity: 13
Merit: 0


View Profile
December 23, 2017, 01:29:03 AM
 #11

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

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.
SopaXT
Full Member
***
Offline Offline

Activity: 161
Merit: 109


View Profile
December 23, 2017, 10:08:24 AM
 #12

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

idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 23, 2017, 04:33:14 PM
 #13

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

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://bitcointalk.org/index.php?topic=2619534.msg26661685#msg26661685

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 ^]
SopaXT
Full Member
***
Offline Offline

Activity: 161
Merit: 109


View Profile
December 24, 2017, 04:55:19 PM
 #14

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

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://bitcointalk.org/index.php?topic=2619534.msg26661685#msg26661685

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 ^]

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.
Code:
sudo pywallet.py --recover --recov_device /dev/sda1 --recov_size 20Go --recov_outputdir $HOME/bitcoin_recovery

"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.

idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 24, 2017, 05:50:44 PM
 #15

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

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://bitcointalk.org/index.php?topic=2619534.msg26661685#msg26661685

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 ^]

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.
Code:
sudo pywallet.py --recover --recov_device /dev/sda1 --recov_size 20Go --recov_outputdir $HOME/bitcoin_recovery

"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.

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
Spendulus
Legendary
*
Offline Offline

Activity: 2002
Merit: 1047



View Profile
December 24, 2017, 11:02:03 PM
 #16

....
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)

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.
PEG-TOKEN
Copper Member
Newbie
*
Offline Offline

Activity: 56
Merit: 0

peg-token.com


View Profile WWW
December 24, 2017, 11:44:31 PM
 #17

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

| PEGTOKEN |  - https://peg-token.com - | Digital Asset Creation | BTC | ETH Cross-Chain Tokens
idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 28, 2017, 08:19:19 PM
 #18

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?


1discovery
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
December 30, 2017, 12:47:31 AM
 #19

That's too complicated.
idelcoins
Newbie
*
Offline Offline

Activity: 13
Merit: 0


View Profile
December 30, 2017, 02:23:11 AM
 #20

That's too complicated.

Then how, other than waiting another 4 weeks for the latest Bitcoin Core to sync?
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!