Restore Veracrypt partition after accidental deletion of partition table

Hello guys and girls!

I 've accidentally deleted some initial portion (little I think) of my drive through the following command: openssl enc -aes-256-ctr -pass pass:"$(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64)" -nosalt < /dev/zero > /dev/sda

The following partitions existed prior to my fault:

sda1/2 (Windows) - about 100GB
sda3 (Extended) - about 100GB
sda4 Veracrypt - about 700GB
some Unallocated space

With the above command I wanted to fill with noise the sda3 partition, but due to a mistake while typing the number 3, didn't reach the command, so as soon as I noticed it (pretty quickly) I hit CTRL+C (about 1 sec after the initial ENTER).

What I 've done already:

1) Run gpard /dev/sda with the following output after 24+ hours of the command running:

Begin scan...
Possible partition(DOS FAT), size(10mb), offset(6720mb)
Possible partition(Windows NT/W2K FS), size(0mb), offset(31042mb)
Possible partition(Windows NT/W2K FS), size(3mb), offset(33462mb)
Possible partition(Windows NT/W2K FS), size(3mb), offset(33466mb)
Possible partition(Windows NT/W2K FS), size(3mb), offset(33469mb)
Possible partition(Windows NT/W2K FS), size(3mb), offset(34282mb)
Possible partition(Windows NT/W2K FS), size(0mb), offset(38780mb)
Possible partition(Windows NT/W2K FS), size(100767mb), offset(50486mb)
Possible partition(Windows NT/W2K FS), size(953866mb), offset(953867mb)

*


** Fatal error: dev(/dev/sda): seek failure.

2) Run testdisk with the following outputs:

Intel/PC partition option prior to analyzing

Non partitioned media option prior analysis

So the first scan only came up with:

Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63
Partition Start End Size in sectors

  • Linux 12858 253 4 24340 40 20 184444928

Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
Enter: to continue
ext4 blocksize=4096 Large_file Sparse_SB, 94 GB / 87 GiB

so that should be the Extended Linux partition (that is sda3, before sda4)

and the second one with those (among other little FAT partitions):

P NTFS 6436 37 34 19282 67 17 206372864

Structure: Ok.

Keys T: change type, P: list files,
Enter: to continue
NTFS, blocksize=4096, 105 GB / 98 GiB

P ext4 12858 253 2 24340 40 18 184444928

Structure: Ok.

Keys T: change type, P: list files,
Enter: to continue
ext4 blocksize=4096 Large_file Sparse_SB Backup_SB, 94 GB / 87 GiB

3) Run MiniTool partition recovery option & EaseUS one, through mounting the disk to Windows pc, with the scans not showing the veracrypt partition, but one of the (MiniTool) showing the above linux one (87.95GB)

My question is, do you know any possible way that I should proceed in order to recover the Veracrypt partition (previous sda4)? In the end thats the only data that I care of.

I look forward to your insights, as I am available for any clarifications! Thank you in advance for your time!

Any help from anyone?

Am on mobile so can't research, but next time, make sure to create a rescue disk for your veracrypt partition. With this you cna recreate the header of the partition, which is what you've probably overwritten. You can read more about it on the veracrypt website.

Thanks for your reply!

I guess that is not the problem, as I stopped the dd command right after its execution, so I think (or presume if you want) that no data from previously sda4 were overwritten.

In that case, that no data from sda4 were changed, how can I proceed, so I can restore that partition.

boot a live version of linux with testdisk.
launch testdisk from a root terminal.
follow the prompts and then select the disk to be recovered
select the type of partition table (mbr is the intel/pc choice i believe)
then select "analyse"
follow the prompts , starting with quick search. a deeper search appears as a option after you run the quick search.
Q to return to previous, exits from the 1st screen.

Thats exactly what I 've already done and I 've already posted the output of the analysis in my initial post.

Intel/PC partition option prior to analyzing

Non partitioned media option prior analysis

missed that sorry

If you haven't powered down or rebooted since making the mistake, it's possible the partition table might still be in memory. Also, you may be able to infer partition sizes from some previous boot / mount logs.

If you have rebooted, the first thing you should do next is to make an image of the entire drive, either to a second drive or to a file on some other storage. This becomes a "gold copy" so that you can always restore it and try again if a recovery attempt fails.

Personally I'd use Kurt Garloff's "dd_rescue" http://www.garloff.de/kurt/linux/ddrescue/, but there is also GNU "ddrescue" (very similar name, but different tool). If all else fails, regular "dd" will work provided both source and destination media are error free.

In general, partitions align on certain boundaries, and extended partitions usually occupy the remaining space (though in your case it seems not). This means you can guess the sizes within a certain range, and it will round up/down.

I think your Veracrypt partition is immediately after the last detected partition, ie starting at or after:
C/H/S = 24340 40 21
C/H/S = 24340 40 19

...depending which Testdisk output you trust. It might be a case of starting at these addresses and reading forwards until you find something. Hopefully it will be an obvious change from blank space to data at this point.

You can probably get away with creating partition 4 so that it spans the remainder of the disk, as the filesystem inside will define the usable size (ie you probably don't need the exact end location of partition 4. It's best to make it too big than too small).

Good luck!

1 Like

Thanks for you answer!

Let's assume that it might start at C/H/S = 24340 40 19 , how can I proceed from that knowledge? At that time I have a disk with no partitions and all the data seems Unallocated.

You suggest creating only 1 new partition starting from C/H/S = 24340 40 19 ?

And if yes how can I do that?

Thanks in advance!

Caution: First back up your disk, as above.
Caution: Check my working below - don't just assume it's correct. It probably isn't :slight_smile:

C/H/S addresses used on PCs are a work of pure fiction and bear no resemblance to actual drive geometries these days. I don't know why TestDisk uses them (but I'm not that familiar with TestDisk). It would be preferable for it to work with LBA addresses, IMO.

Anyhow, as TestDisk gives you the geometry it's using we can convert it to an LBA address:
Disk /dev/sda - 1000 GB / 931 GiB - CHS 121601 255 63

So, 121601 Cylinders, 255 Heads per Cylinder (HPC), 63 Sectors per track (SPT)

LBA address = (C x HPC + H) x SPT + (S - 1)

So, for C/H/S = 24340 40 19

LBA = (24340 x 255 + 40) x 63 + (19-1) = 391024638

This is to say, I/we think your partiton starts on or after logical sector number 391024638.
Logical sectors are 512 bytes.

So, try this:
dd if=/dev/sdX bs=512 count=1 skip=391024638 2>/dev/null | hexdump -C
(Replace X with the actual device letter, and note that's an uppercase C at the end)

...and see what you can see. Unfortunately it's not unusual for an un-encrypted partition to start with a sector of all zeros, BUT as this is an encrypted partition it will encrypt to look like a sector of random data. You can vary the "skip" offset above to view the adjacent sectors, but since fdisk may round up/down the start address by several MB you could be looking for quite a while. You can also change or omit the "count=" flag.

Hopefully whatever was in partition 3 was not encrypted and it was not full - so you're basically looking for a transition from sectors containing all zeros to one with "random" data, which will indicate the start of encrypted partition 4.

So, now try to create a partition which starts at sector 391024638 (or the value you just determined) ideally with whatever tool you originally used. The following is just an example, and uses "fdisk":

fdisk /dev/sdX
o         < Create new (MBR) partition table
n         < Create new partition
p         < Create new primary partition
4         < Make it partition number 4, as it was previously
391024638 < The start address (example)
<return>  < For the end address, means rest of drive
p         < Print the partition table - see where it's been rounded up/down to.
v         < Verify (ignore unallocated sectors, check for other issues)

If you're feeling brave/lucky you can use w to write the partition table to disk, then q to quit and see if it will mount. Try a "read-only" mount first time...

This is just an outline, but might get you started.
Good luck!

1 Like

First of all thanks once again for your insight! You are my last hope as I was getting frustrated on this!

Luckily when I run a scan with MiniTool's software meant for recovery (when I mounted the disk on a windows laptop), it showed among other partitions the Extended one (sda3 previously) with the following info:

Ext4 Starting LBA: 206579712 Ending LBA: 391024639 and the sizes (87.95 GB)

So you were pretty close to the ending LBA (you mentioned 391024638).

Should I proceed with 391024638 or 3910246**40**, as starting point for the new partition (sda4), as it should be the next value of the Ending LBA of the previous one (sda3)? There will be any differences?

Also, the partition sda3 (Extended - Linux) was also fully encrypted (except /boot partition).

EDIT:

Also that command does no harm, right, as it writes everything at /dev/null and not to disk?
dd if=/dev/sdX bs=512 count=1 skip=391024638 2>/dev/null | hexdump -C

The command will read 1 sector from the disk at the offset given by "skip=", and display it on the screen in hex and ASCII.
dd if=/dev/sdX bs=512 count=1 skip=391024638 2>/dev/null | hexdump -C

Try reading sectors 391024637, 391024638, 391024639, 391024640, 391024641, etc.

A lot of partitioning tools leave a gap between partitions, so if you find a few sectors of all zeros you can try creating a partition starting at the next sector which does contain data. If there is no gap, you might have to resort to trial end error - but if you use read-only mounts I think you'll be OK to keep trying until you find it.

I'd try 391024640 first, I think.

Good luck!

2 Likes

Wow, last ditch effort... Backing up keys to encrypted drives is a must nowadays

Sorry for the late update, but I was busy and just now got some time to try what you suggested. Thanks once again for your help!

So this is what I 've got:

dd if=/dev/sdd bs=512 count=1 skip=391024637 2>/dev/null | hexdump -C Returned:

00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200

dd if=/dev/sdd bs=512 count=1 skip=391024638 2>/dev/null | hexdump -C

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

391024639

dd if=/dev/sdd bs=512 count=1 skip=391024639 2>/dev/null | hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

dd if=/dev/sdd bs=512 count=1 skip=391024640 2>/dev/null | hexdump -C

Returned some data, do you want me to post them here (I think that's the sda4 partition)?

So now I should do the following part that you suggested (with 391024640)?

fdisk /dev/sdX
o         < Create new (MBR) partition table
n         < Create new partition
p         < Create new primary partition
4         < Make it partition number 4, as it was previously
391024640 < The start address (example)
<return>  < For the end address, means rest of drive
p         < Print the partition table - see where it's been rounded up/down to.
v         < Verify (ignore unallocated sectors, check for other issues)

It worked like a charm thanks to your directions! I did as I described/asked in my previous post!

You just saved me from a lot of trouble, as I was away from my backup drive for some weeks! I don't know whether words are enough to express my thankfulness, but once again thank you very very much for your help!!!

Nice one! You're welcome! :slight_smile: