Topic: Seek help to get back my private key... 7500$ reward. (Read 923 times)

I found one encrypted address

   "mkey": {
        "encrypted_key": "1665e0b9375c20a720c77799a7386eba77149b97bd34ebce42ee962882da8a3abfe566040b7aae4 5e941880972dc7a8b",
        "nDerivationIterations": 62166,
        "nDerivationMethod": 0,
        "nID": 1,
        "otherParams": "",
        "salt": "96d596871f9a2dcc"
    },


you can check password on this encrypted_key
here is guide
https://bitcointalksearch.org/topic/m.7690647
if your password works this will be your wallet with bitcoin

That mean I put the wallet in the first bin. 100%
If I understand correctly, I need to look for lost partitions and locate the first bin ?

...

I didn't deleted those file... you can try to download the demo version of Wondershare recovery. They are still there.

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 ?

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

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)

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

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 !

Maybe i have a virus.

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.

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://bitcointalksearch.org/topic/m.56502435

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.

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

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:
Can you share the command you used?

we found exactly 44 wallets.

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.

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)

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

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

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.

3. Forensic data recovery lab. But I don't even know what to tell them. They probably don't know so much about private keys and stuff

There seem to be two recovery businesses operating
David from https://walletrecovery.info/
Dave from https://walletrecoveryservices.com/

I contacted David but got no answer from Dave so far. Not sure what happened.

If you open the .dat files with windows notepad, both seem completely unreadable.

1. Rescan with Pywallet + passphrase

2. Raw partition search for keys or key fragments (I can't do that myself)

3. Forensic data recovery lab. But I don't even know what to tell them. They probably don't know so much about private keys and stuff

The original title on disk was ballet.dat and ballet_1.dat

Some people complaining about the Mega link, could you suggest a good file sharing website ?
File is 30gb.

if want to try yourself
use python 2.7 from Miniconda2

problem it is store on encrypted keys is very hard to crack

PyWallet read the image file... gave this summary:

https://www.walletrecoveryservices.com/

Contact them if you haven't!

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.

You are sure that You want to share vhd like that?

You are sure that You want to share vhd like that?

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.