Seek help to get back my private key... 9000$ reward.

[escobol]

this two *.dat files are not remains of wallet.dat (check hex)

[1715565805]

1715565805

[1715565805]

1715565805

[1715565805]

1715565805

[1715565805]

1715565805

[Igor76200]

I don't know about the hex search but opening them with the notepad you can see a lot of nonsense (windows media script...). So yes they seem highly damaged.

I can confirm they are the correct files. Because of their creation date. They were created the right day and hour... no mistake possible.

[morbius55]

I see... I ignored that. Is there any possible workaround ?
Except if we can meet in person I'm afraid I can't reasonably send you my passphrase.

If you have the passphrase why don't you run pywallet yourself and reveal those encrypted keys? With the very kind help of HCP i managed to get it running. Check out this thread. https://bitcointalk.org/index.php?topic=2398504.0

[NotATether]

Oh wait... could someone confirm it's actually useless to make a raw disk search for encrypted wallets ?

No it's not. Instead of private keys you will just get hashes of private keys instead.

There is a Python 2 script in Github called keyhunter, which searches for base58 legacy private keys, and I used it to do a disk search on your wallet.dat and wallet_1.dat files, but it did not return any hits.

Pywallet would not even open those files, it generated something like a "BDB error" which means it doesn't even think the file is a Berkeley database (the file format of wallet.dat).

I am downloading the VHD file right now and when that's done I'll keyhunter that too. I think VHD stores the host filesystem directly in the file without any manipulation or compression or other weird hiding.

[Igor76200]

Someone suggested to make a iso 1:1 copy instead of .vhd
I'll do that too just in case.

[BASE16]

Someone suggested to make a iso 1:1 copy instead of .vhd
I'll do that too just in case.

Not necessarily a ISO you can also IMG
But in any case a copy that includes all the RAW data from the drive regardless of partitions and file tables.
There is a lot of data on the vhd file, i did a scan and it recovered 159080 files.
Further examination is needed to look for the specific file contents, but given the amount of data this will take an awful lot of time.

[Igor76200]

Some infos that might be useful.

Computer is a ASUS netbook Eee PC 1001PX
Disk is WDC WD2500BEVT-80A23T0

I bought this laptop second hand on EBay in January 2014.
I created my bitcoin wallets January 7th 2014, including the one we are searching.
In total about 20 altcoins wallets and 5-6 Bitcoin wallets.

That particular bitcoin wallet I'm looking for was created on this laptop, I immediately made a copy on a SD card then deleted the original file. I think it was on this computer only for a few hours.

Does this have any importance ?

I rarely used that laptop since because it's old stuff.
I probably messed with windows at some point, because I can see there is an unverified version of windows running. I really can't remember what I did...

File should be named « ballet.dat » and « ballet_1.dat » (original + copy)
Address : 1FHYSH65uKdVGhR7Y2QznxfBtLWhjotqUq

[fxsniper]

file wallet.dat and wallet_1.dat

two file it is normal copy file from bitcoin folder

or wallet.dat this is recovery file from delete file

I think this is   recovery file right

because check wallet.dat , look like blank file, it is no data store inside

other file clone drive, I think clone drive not copy data all bits from drive, they copy only work file
so, file part have data is only on hard drive on laptop

[Igor76200]

The recovery software found these files. I used Recuva, Puran, EaseUS... they could not find it. Only Recoverit from Wondershare was able to dig it. However it seem to be unusable.

[BASE16]

This is most likely coming from an old file table that was found on the drive, in such case it found the file entry and there will also be a point that tells you where to find the data.
You need that point to go see if there is anything left of that old data, when you use this type of recovery method.

You can also do a RAW scan without using partition and file tables.
In a recovery from RAW data this file will not show up as wallet.dat or ballet.dat because it's raw data, it does not have a filename anymore.
But it does have a header so in such case the file will pop up as ******.db because the recovery application picked up on it's database header.
You can test the file in bash with $ file and it will tell you the exact type.

Code:

$ file ******.db

******.db Berkeley DB (Btree, version 9, native byte-order)

It can also show something else but in case of a wallet it will show Berkeley DB.

So if you found a wallet.dat then this does not mean that you found the actual wallet, it could be only a reference point.

But if you found a .db then you can be sure it's a database file and i have found several but they were already emptied.

We found exactly 44 wallets.

f4204024.db: Berkeley DB (Btree, version 9, native byte-order)
f35048320.db: Berkeley DB (Btree, version 9, native byte-order)
f61344210.db: Berkeley DB (Btree, version 9, native byte-order)
f58211446.db: Berkeley DB (Btree, version 9, native byte-order)
f33779786.db: Berkeley DB (Btree, version 9, native byte-order)
f0208040.db: Berkeley DB (Btree, version 9, native byte-order)
f4673642.db: Berkeley DB (Btree, version 9, native byte-order)
f61399680.db: Berkeley DB (Btree, version 9, native byte-order)
f4673674.db: Berkeley DB (Btree, version 9, native byte-order)
f18790112.db: Berkeley DB (Btree, version 9, native byte-order)
f4294446.db: Berkeley DB (Btree, version 9, native byte-order)
f33779818.db: Berkeley DB (Btree, version 9, native byte-order)
f4294478.db: Berkeley DB (Btree, version 9, native byte-order)
f17315832.db: Berkeley DB (Btree, version 9, native byte-order)
f61408994.db: Berkeley DB (Btree, version 9, native byte-order)
f58252320.db: Berkeley DB (Btree, version 9, native byte-order)
f46519344.db: Berkeley DB (Btree, version 9, native byte-order)
f3442350.db: Berkeley DB (Btree, version 9, native byte-order)
f18790080.db: Berkeley DB (Btree, version 9, native byte-order)
f36736740.db: Berkeley DB (Btree, version 9, native byte-order)
f46519312.db: Berkeley DB (Btree, version 9, native byte-order)
f0208008.db: Berkeley DB (Btree, version 9, native byte-order)
f21199420.db: Berkeley DB (Btree, version 9, native byte-order)
f61344242.db: Berkeley DB (Btree, version 9, native byte-order)
f4205656.db: Berkeley DB (Btree, version 9, native byte-order)
f4203992.db: Berkeley DB (Btree, version 9, native byte-order)
f3380142.db: Berkeley DB (Btree, version 9, native byte-order)
f61349908.db: Berkeley DB (Btree, version 9, native byte-order)
f61408962.db: Berkeley DB (Btree, version 9, native byte-order)
f21199404.db: Berkeley DB (Btree, version 9, native byte-order)
f58252288.db: Berkeley DB (Btree, version 9, native byte-order)
f35048288.db: Berkeley DB (Btree, version 9, native byte-order)
f61090356.db: Berkeley DB (Btree, version 9, native byte-order)
f61340690.db: Berkeley DB (Btree, version 9, native byte-order)
f61090324.db: Berkeley DB (Btree, version 9, native byte-order)
f3380174.db: Berkeley DB (Btree, version 9, native byte-order)
f51770738.db: Berkeley DB (Btree, version 9, native byte-order)
f4205688.db: Berkeley DB (Btree, version 9, native byte-order)
f17315864.db: Berkeley DB (Btree, version 9, native byte-order)
f58211414.db: Berkeley DB (Btree, version 9, native byte-order)
f61349876.db: Berkeley DB (Btree, version 9, native byte-order)
f61414436.db: Berkeley DB (Btree, version 9, native byte-order)
f36736772.db: Berkeley DB (Btree, version 9, native byte-order)
f61399648.db: Berkeley DB (Btree, version 9, native byte-order)

Dumped them with db-utils to see which ones were intact and which ones were corrupted or encrypted.

[morbius55]

The recovery software found these files. I used Recuva, Puran, EaseUS... they could not find it. Only Recoverit from Wondershare was able to dig it. However it seem to be unusable.

Don't bother with those, use pywallet to scan a copy of the the whole drive and use the passphrase. Don't share the results with anyone.

[HCP]

Pywallet n00b here: It gave me 39 possible wallets, 11764 possible encrypted keys and 105 possible unencrypted keys, followed by a segmentation fault. I don't think it wrote any of the keys to the output wallet file.
I used this:

Code:

./pywallet.py --recover --recover_size 33Gio --recov_device ~/d2630eda-4e56-11e3-99a1-806e6f6e6963.vhd --recov_outputdir recovered_wallets --dumpwallet

Can you share the command you used?

I used Windows... and the "old" Python2 version of pywallet... not the latest version.

Code:

c:\Python27\python.exe e:\pytest\pywallet.py --recover --recov_size=32Gio --recov_device=E:\d2630eda-4e56-11e3-99a1-806e6f6e6963.vhd --recov_outputdir=E:\wallet_search

Note: you shouldn't use --dumpwallet and --recover together... you do one or the other.

we found exactly 44 wallets.

From the OP's vhd image? And were these confirmed wallets... or just BDB files? As, all wallet.dat's are BDB files, but not all BDB files are necessarily wallet.dats

[BASE16]

we found exactly 44 wallets.

From the OP's vhd image? And were these confirmed wallets... or just BDB files? As, all wallet.dat's are BDB files, but not all BDB files are necessarily wallet.dats

No they were fake wallets that just happen to be there.
They also had a fake address inside.
I don't know what happened.
Maybe i have a virus.

[COBRAS]

I lost a .dat wallet with 1.54BTC.

I found the file by scanning the original laptop used to create the wallet in 2014. Unfortunately the file seem to be highly damaged. Someone tried to extract the keys using Pywallet but it failed.

I am looking for a deep disk partition research, in order to find the key. Unfortunately I am not capable of doing this.

I am willing to give 10% to the person able to succeed. If that's even possible. Which is around ~7500$ now.

I created an image of the disk here :
https://mega.nz/file/ux4WQLDB#cc_OHpVKRNszxDrnl5Y4A1GwzfszlNNpVJwi43vtXJY

Alternative download link here :
https://bitcointalk.org/index.php?topic=5321900.msg56502435#msg56502435

Address : 1FHYSH65uKdVGhR7Y2QznxfBtLWhjotqUq
https://www.blockchain.com/btc/address/1FHYSH65uKdVGhR7Y2QznxfBtLWhjotqUq

Wallet have a strong password. I'm ready to visit that person, or the other way around, preferably in the EU due to travel restrictions. In order to make the transaction as safe as possible.


More infos

It's an old netbook from 2010 or even older. I bought it second hand just to create the wallets. I rarely use it because it's very old and slow. 60% of the disk is free. I can't remember what I did with this laptop... maybe I reinstalled windows at some point. I'm not sure.

I created about 20 altcoin wallets and 5 bitcoin wallets with that computer. So there might be other keys around.

If it fail, my last option would be to submit the disk to a forensic data recovery lab. Maybe they will be able to find something.

Crossing fingers. Thanks for your help.

Dave give 20%, dont waste your  time, wait his answer, Inthin he will solve your problem... Br.

P.s. try send him message in this forum...

[Igor76200]

Current state of search :

Found 22 altcoin wallets and 38 other wallets, while scanning .db files : Berkeley DB (Btree, version 9, native byte-order)

17 wallets with a size of 9 bytes which is impossible to recover
21 wallets of 29 bytes many of these can not be dumped because encrypted.

Now have to check the ones that are encrypted and their files size this will show if it can be done and be used as an indicator for the amount of effort it will take to try.

We know the wallet is encrypted so it all does make sense at this point in time. Will require further investigation likely examination on the bit level.

A wallet has a specific structure, for example like a start header and end header. Positions of the elements in between is fixed so we know what should be where after a certain start header and before a certain end header.

This means you drag a partial overlay over the remaining data and when it slides over a old damaged wallet, and there are still elements present then the overlay will match and ID the underlaying data and we make a snapshot of that for further examination.

If there are enough bits left on the drive then you would be able to recover the coins.

The 9 bytes wallets mentioned earlier are the standard that gets written in case of failure. Those look like this:

main
 \00\00\00\02
DATA=END

It is empty, but it can be empty for many reasons that is why you have to compare those nine bytes to the original file. If the original file is larger then it means that there is more then those nine bytes.

[BASE16]

I realized that I had made a mistake.

The previous recycler was created at 15 November 2013 and lived up to 1 February 2014 and the last modification was at 29 January 2014.
On 1 February 2014 the second recycler was created which still is the current bin and it was last modified at 25 February 2021.
So that is not too long ago and I would tend to conclude that OP overwrote his own wallet less then two weeks ago.
Why would you write onto a drive that you are trying to recover ?
That is the biggest mistake you can make.

READ ONLY !

[NotATether]

Maybe i have a virus.

A virus can't manipulate the output of the pywallet scan to list wallets different from the ones in the VHD file. So I'm leaning towards the VHD having nothing interesting inside (the wallet file itself was deleted a while ago anyway, so it had plenty of time to get overwritten).

Keyhunter did not return anything against the VHD either, yes I did remember to unzip it.

[escobol]

I realized that I had made a mistake.

The previous recycler was created at 15 November 2013 and lived up to 1 February 2014 and the last modification was at 29 January 2014.
On 1 February 2014 the second recycler was created which still is the current bin and it was last modified at 25 February 2021.
So that is not too long ago and I would tend to conclude that OP overwrote his own wallet less then two weeks ago.
Why would you write onto a drive that you are trying to recover ?
That is the biggest mistake you can make.

READ ONLY !

On 25 february 2021 OP recovered this 2 dat files (you can search for the ballet.lnk), in my opinion after that he copied this 2 files and deleted them from hdd (maybe with use of some software that deleted and overwrote them? - why ithink so - because there is no sign of this two dat files in any recovery software)

[Igor76200]

@escobol In February 2021 I scanned the C drive with the recovery software, then pasted the recovered files on the D drive (I did not added the vhd of D I don't think it's there). If you scan C with Wondershare Recoverit you should still be able to see it.

I ran 4 brands of recovery programs, only one could find the ballet.dat
If I understand correctly I should not have done any scan before mounting the disk or create an image.

@Base16 I will try to check in lost partitions Bin. That may sound very stupid for computer programmers but I had no idea about how file deletion worked until a few weeks ago. Just presumed it was immediately overwritten.

Now,

I think the original bitcoin addresses I created in January 2014 could still be found in those encrypted .db files
I created 5 bitcoin adresses around January 7 2014. And the very first one is the winning one (starting 1FH...)

Will scan lost partition and check the bin. But I'm not sure I will be able to properly read the content.

[BASE16]

On 25 february 2021 OP recovered this 2 dat files (you can search for the ballet.lnk), in my opinion after that he copied this 2 files and deleted them from hdd (maybe with use of some software that deleted and overwrote them? - why ithink so - because there is no sign of this two dat files in any recovery software)

I agree.
He overwrote it himself a few days ago and he knows it.



And now he upload the entire disk in the hopes that someone can magically get it back/
 

Sorry I forgot to answer about that point... in February I scanned the C drive with the recovery software, then pasted the recovered files on the D drive (I did not added the vhd of D I don't think it's there).

With recovery software that you installed on the same disk you was trying to rescue thereby destroying the thing you were looking for.