Recovering lost private keys, pywallet no results, hex editor 70+

[fajja]

Hello, like many recently, I've been furloughed so I'm using this time to revisit my old hard disks which contained bitcoin core wallet.dat and possible litecoin wallet as well, from 2014/2015. (quickformatted in error )

I've been using the great information in the forum. i've ran the pywallet from here: github.com/jackjack-jj/pywallet on a unbuntu usb drive to scan the old laptop and it comes up with 0 errors and 0 wallets found.

If i connect the disks to my new laptop and run hexeditor search for the string "0201010420" i get just over 70 results on the same disks (i stopped the search half way because it was taking so long). I've copied the the 32bytes after that which might be my private key, however i'm now doubting that they are.

Is it possible the string "0201010420" relates to something else? the 32bytes which follow mostly all have a similar pattern "D0305D........47" are then followed by "00 00"

 at the end of the search there are 3 other 32byte strings which look more varied such as "09744B......A3"

Using bitaddress.org offline i converted them to btc addresses and checked both the uncompressed and compressed address for transactions, all zero.

It occurs to me that the wallet would be encrypted, I still have the paper where i wrote the password down. Is it possible I need to decrypt these 32byte strings and then check? Or does it not work like that.

I might try run the hexeditor to completion (would take a day or two i think!) and see if there are more results that way.

Should I use a more recent version of pywallet?

I don't think I had much in it. but anything would help right now.

(update i just ran a test of pywallet on another disk where i put a fresh wallet.dat, then deleted it, i ran the test again and it said 0 results, so now i'm wondering if its actually working?!)

[1715371924]

1715371924

[1715371924]

1715371924

[1715371924]

1715371924

[HCP]

It occurs to me that the wallet would be encrypted, I still have the paper where i wrote the password down. Is it possible I need to decrypt these 32byte strings and then check? Or does it not work like that.

As far as I'm aware, if the wallet file was encrypted, then the search for hex "3081D30201010420" (or 2001010420) likely won't work... that was only valid for unencrypted wallet.dat files.


As far as PyWallet is concerned, I've had various success attempting to recover keys from "deleted" wallet files... sometimes it works, sometimes it doesn't I haven't been able to figure out the exact requirements for recovery, but if the wallet.dat was encrypted, it you don't have the correct passphrase, it won't be able to recover anything at all and you'll end up with an empty "recovered" wallet, even if it can "see" the deleted file.

Have you tried using any recovery software on the disks to see if they can recover the wallet.dat files? If you can recover the file itself, pywallet might be able to dump the info from it.

[PrimeNumber7]

Don't boot from the disk you are using, and don't add any files/programs to this disk.

I am not sure what "quickformatted" means, but its name implies that references to all the files have been removed, and the allocation for disk space for your files has been removed. If this is true (or something close to true), you can use file recovery software to recover the wallet files.

[HCP]

I am not sure what "quickformatted" means, but its name implies that references to all the files have been removed, and the allocation for disk space for your files has been removed. If this is true (or something close to true), you can use file recovery software to recover the wallet files.

If it's a Windows "Quick Format", then it means that the partition/file tables are reset, but the disk is neither "zeroed" (ie. all bits set to 0) nor is it scanned for bad sectors.

Since Windows Vista, a "full" format (ie. the non quick format) option would actually zero the disk in addition to scanning for bad sectors. Obviously, zero writing a full disk can take a while, so most people tend to opt for "Quick Format" (unless they're purposely trying to remove all the data).

refer: https://docs.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/format-command-not-write-zeros-to-disk


The upshot of this "quick format" behaviour is that the chances of data recovery are a lot higher if a "quick format" was done, as the underlying data is not immediately overwritten by the format procedure... it is only overwritten if new data is subsequently written to the disk in the sectors where the old data was stored.

[fajja]

Thank you for the replies so far!

I will try putting the keys into something like electrum directly. The reason i doubted they were keys is that they all follow the same pattern at the start and end of the 32byte string, whereas other example i've seen they are very much random, more like the strings which were found at the end of the search.

I've put the hex scan on again and I'll let it run fully this time before i check the results, it's been on over 24hours so far!

the only software which comes up with anything is Recuva, but it recovers .dat files which are 32gigs! maybe i should look closer at them with pywallet perhaps

The other thing about the 0201010420, it only shows up on the computer that had bitcoin on it, so that's a positive

[HCP]

I will try putting the keys into something like electrum directly. The reason i doubted they were keys is that they all follow the same pattern at the start and end of the 32byte string, whereas other example i've seen they are very much random, more like the strings which were found at the end of the search.

Yeah, it would not be very common that they all start and end with the same bytes... it's not impossible, just quite unlikely.

the only software which comes up with anything is Recuva, but it recovers .dat files which are 32gigs! maybe i should look closer at them with pywallet perhaps

32 gigs??!? Yeah, they're not likely to be wallet.dat files then... I've never seen a wallet file grow to more than a few megabytes at the most. Mind you, i've not really seen ANY files that are 32gigs in size except for cloned disk images etc.

[fajja]

Yeah that was my thinking, I'm continuing to try a couple of python scripts, I'll report back on my findings but i'm almost certain its long gone.

Recuva can restore data but sometimes merges files if the headers are messed up, so you end up with massive files containing mishmash of data.

I was curious about why pywallet didn't see the actual proper copy of a wallet.dat on a fresh harddisk

[HCP]

Yeah that was my thinking, I'm continuing to try a couple of python scripts, I'll report back on my findings but i'm almost certain its long gone.

Out of curiousity, what python scripts are you trying to use to scan the recovered data?

I was curious about why pywallet didn't see the actual proper copy of a wallet.dat on a fresh harddisk

I'm not sure if something changed in the file format of newer wallet.dat's that prevents PyWallet from being able to detect them or if it's just unreliable... but like I said, I've sometimes had issues with it detecting a wallet.dat file which I know is there.