I've deleted my wallet and never backed up my files. How can I recover my coins?

Question

I've deleted my wallet when I wiped my computer recently and never backed up my files. The only thing I've done was convert money into bitcoins and it was sitting in my wallet never touched. I reached out to the company that processed my conversion and they provided me with the necessary addresses that were used. How can I recover my bitcoins? Any help would very appreciated. Thank you.

Answer 1

First, don't panic!

Second, make an image backup of the wiped drive to a physically different drive.

Third, you maybe able to recover the deleted files with tools such as magic rescue so long as the sectors on your drive that your wallet was wiped from are intact... otherwise you may be out those coins... I've had OK luck with rescuing data off drives for friends but also some failed attempts to because of rewritten blocks corrupting deleted data.

In other words this will cost you in either time or in the coins you've lost. Right now you're in limbo and I would suggest you do a dd backup of your wiped drive and try to use recovery tools on the backed up drive image so that you don't accedentaly wipe the target data off the original drive.

I'll see what I can find in my notes in a few hours on the subject of drive imaging and recovery for ya.

Updates

Here's an edited version of my private notes on data recovery steps that I've used to recently recover a corrupted USB drive that was being used to backup a client's Windows user account files. Note file names did get mangled during the process so be aware that there will be cleanup after this process.

Setup

• You'll need second drive with enough free space to house double the total number of bits of the target drive. Or in my case I had to get two drives of greater than 64gigs; one for the backup image and the other to receive recovered files. This is because we are going to be copying every bit off the target drive; even the zeros. In my case discussed here there was only 13~gigs used out of 63'ish but we still had to copy it all.

• You'll need a USB or CD bootable Linux distribution. I used Kali Sana for my recovery because it has pretty up to date tools for this job but you might want to hunt for a specifically designed distro. Web search for terms like "USB recovery Linux distro" and you'll likely find a top 10s list of someone's testing results or recommendations; there be choices in flavor so I'll keep this based off my expenses with Kali.

• You're going to need to locate the dev file path for your target drive, in this example it's /dev/hda but for you it maybe different. Hint use mount & blkid commands to show drives, their file paths and other info. Once located unmount it so you're normal programs don't write or read from it by accident. For example my target drive was mounted at the following umount command directory path

  umount /mnt/usb/damaged

Repeat above for any mount points associated with the target drive to be backed-up. For my revival there was two partitions associated with /dev/hda physical drive and both had to be unmounted. Also be on the look out for swap partitions associated with the target; mine didn't but if you roll the next command with any of the target drive's mounted you run the risk of a bad backup image being made to work from.

Backup command

dd if=/dev/hda bs=4K conv=sync,noerror | tee mybackup.img | md5sum > mybackup.md5

Be very very careful with the above because dd is not forgiving! Also note that the directory path is different than what was used with umount because we're now operating on the target drive a a whole and not a partition within the target drive. Hint, the previously mentioned mount & blkid commands used to reveal mounted directory paths should have shown the dev related path too.

• -if=/dev/sda should be the drive location of the hard-drive you need to recover data from. Don't include any partition numbers as you'll want every bit from start to finish.
• bs=4K is the bite count per read/write (I think) and lower values will take longer but be less prone to errors.
• conv=sync,noerror are options to keep dd chugging away even if there's a bad sector or two.
• | tee mybackup.img redirects (and duplicates with tee) output from dd reading the target drive and saves it to mybackup.img. Note this fine path should not point to the drive your imaging; if you write to the same drive you'll likely wipe bits you want back for good from your drive because right now the addresses/sectors are marked as available for writing that use to contain your data.
• | md5sum > mybackup.md5 takes the duplicated output from dd and writes a signature to mybackup.md5 same rules for file placement as the image file too.

Now the above is going to take some time; for the 64~gigs I had to recover I used an RPi board (cheaper on the electric bill) and ran the above in screen for one full night and half a day. The above also isn't going to give you any feedback or process until it's done. In other words, grab a book or watch a season of Firefly to pass the time.

Eventually it'll report the number of records in/out and the time it took in seconds. And we can roll some tools over the backup image instead of on the target drive; this means mistakes can be made and you're just out the time of making another image.

To verify that the backup image you've saved is good you can run the md5 command against the image file and compare against the one generated during backup. Furthermore if really worried you can roll the md5 command against the target drive and compare that all three signatures/fingerprints are equivalent. The following are steps that I used to verify the image I took.

dd if=/dev/hda bs=4K conv=sync,noerror | md5sum > drive.md5
## Above should modified to point to your target drive
## Bellow should point to your backup image
dd if=mybackup.md5 bs=4K conv=sync,noerror | md5sum > image.md5

Use cat to show the contents of each md5 file, they should all match or show the same human unrelated junk. Note for other readers, yes collisions (false matches) can happen but we're not trying to make any collisions so chances are low.

Tips for keeping sanity on next steps

• if you've the space then make a backup of your backup because it's safer that way and will save your target drive from any accidents when having to start a whole new dd command ;-) beware of sleepy terminal user input.
• if possible unplug/disconnect the target drive or attempt the next block of steps on different hardware operating only on your backup image.
• take your time at this point. There's little reason to rush at this point, well unless you liked waiting for the next backup image to complete. Not going to judge if that's what you're into.

Optional, install Windows partition compatibility

## For many Debian/Ubuntu based distributions
sudo apt-get install ntfs-3g
## Kali Sana
sudo apt-get install ntfs-config
## and some Ubuntu flavors
sudo apt-get install ntfsprogs

Using apt-cache policy ntfs-3g, subbing in application name to check, it's possible to see which is available to your system if using apt and a package manager.

Install software for working with drive images

sudo apt-get install kpartx

Install software for working with partitions

sudo apt-get install parted
## Either above or below, 'g' stands for GUI
sudo apt-get install gparted

Install software for data recovery & inspection

sudo apt-get install safecopy magicrescue testdisk testdisk-dbg

Getting documentation

Any of the above can have its manual or help docs printed via the following syntax

man magicrescue
safecopy --help

About kpartx

Using kpartx the backup image can be opened and it's internal partitions can be mapped to the /dev directory for later mounting to a path(s). This bit is better in use cases where corruption or deletions do not need to be recovered from.

## Make some directories for the image partitions to be mounted to
mkdir -p /media/rescue_p1
mkdir -p /media/rescue_p2
## Map image to dev loop paths
kpartx -v -a /media/backup_drive/mybackup.img
## Note the output of above command it will be similar to below
##  but not identical.
mount /dev/mapper/loop0p1 mkdir -p /media/rescue_p1 -o ro
mount /dev/mapper/loop0p2 mkdir -p /media/rescue_p2 -o ro

Note the use of - o ro means read only. Remove it if you wish to do stuff without protection to backups and like loading another backup image.

Files within the drive image should now be available to the same extent as the original target drive, however, because your files where deleted and my client's files where corrupted then there's still more work to do. So let's un-mount for now and install another tool. For now know that you've this power of resurrection unlocked.

unmount /dev/mapper/loop0p1
unmount /dev/mapper/loop0p2
kpartx -d /media/backup_drive/mybackup.img

information gathering

Now some info about the drive image needs to be know for you to make use of the following block

## Take note of Disklable in following output
fdisk -l /media/backup_drive/mybackup.img
## Take note of Partition Table, Type, & File system
##  in following output
parted /media/backup_drive/mybackup.img
## you may have to look for quit (q) command to get back to the terminal.

Now prepared with knowledge about your drive the following blocks can be tried on your backup image

About testdisk

Test disk is a command line, menu driven, application. So be very aware of what context your keyboard input will be read under. To test disk recover any files we should first cd to a directory safe for it to dump in to. For my recovery I mounted the second drive I had and changed directories to it as shown

mkdir -p /media/salvaged/testdisk
## mount recovery drive partition to above, then cd
cd /media/salvaged/testdisk
## start testdisk against image file
testdisk /media/backup_drive/mybackup.img
## Choose Analyse & Deeper-scan to go deeper
## Use bundled photorec program to try and recover deleted our corrupted files
photorec /media/backup_drive/mybackup.img

After using the above two recovery tools, the results can be reviewed using logs saved to your current working directory. Here's the command I ran

ls -hal /media/salvaged/testdisk | less -R5
## use letter q on keyboard to quit, arrow keys to
## move up and down though output in five row chunks
## and page keys to move though output based on
## the entire screen hight.

About safecopy

The safecopy tool can be used to read drives even when blocks within go bad. Supper useful if you run into a situation where a drive is reporting health issues or similar errors or into situations where partitions where messed with. It saves image files kinda like what we did with dd but unlike dd it's able to really dig into sectors marked as bad.

## Copy target drive source, bad block marks are listed in
## stage1.badblocks output file in your terminal's
## current working directory. They'll come in handy in the
## next steps.
safecopy --stage1 /dev/hda stage_one.img
## Attempt to read bad blocks marked in
## stage1.badblocks with no repeats marking ends
## of bad areas in stage2.badblocks
safecopy --stage2 /dev/hda stage_two.img
## Give no heed to bad blocks and attempt to copy
## everything. Note this next one will retry forever on
## every uncooperative block so it may take forever
## or just a ridiculously long time. Additionally if your
## target drive is a platter style then if there are problems
## with the mechanics of the drive this may cause
## increased ware and tare.
safecopy --stage3 /dev/hda stage_three.img

Next try any of the recovery tools already suggested to try and recover lost data. Even if these backups still don't have your data there are likely other tools you can try.

While there's still a chance that you've lost your coins, such as if a new file was written over it, the above steps should increase your chances at recovery. Try searching for terms like forensic drive imaging and similar to find even hope of recovering data from that state. Last but not least there maybe a place in your area that can open up the drive (it's platter style) and use specific tools for literally imaging the data off it; mom & pop tech shops and state level law enforcement are two good places to chat-up for suggestions on where they send out drives for full revival. However, that route will cost in time and in money so reserve this as last resort.

Hopefully the first image is the only one needed and you get your coins back without issue. In either case save these notes somewhere so that you can impress a luckier soul with your wizardry.