#201 IMPORTANT! Partition table corruption after expansion of the encrypted partition

[BaggerMAN]

Hello.

I use VeraCrypt 1.22 on Windows 8.1 x64 (on SSD) with several disks.

I have a 2 TB HDD with the following MBR partition table:
W: 56 GB - VeraCrypt encrypted system (primary) partition with Windows XP (as second OS).
X: 731 GB - VeraCrypt encrypted non-system logical (extended) partition for files.
Y: 1025 GB - Unencrypted logical (extended) partition for files.
Z: 50 GB - VeraCrypt encrypted non-system logical (extended) partition for files.
All partitions have an NTFS file system.

Every time I make an extension of the encrypted partition X, I get a corrupted partition table and I have to restore it from the backup.
If I did not backup, it would be a disaster.

Here is my sequence of actions.

• I boot the computer from the USB with Ubuntu 18.04.
• I make the first backup of the partition table:

disk="sdb"
lsblk -p                        > "$disk-lsblk-p"
lsblk -pf                       > "$disk-lsblk-pf"
parted "/dev/$disk" print free  > "$disk-parted-print-free"
sfdisk -l "/dev/$disk"          > "$disk-sfdisk-l"
sfdisk -d "/dev/$disk"          > "$disk-sfdisk-dump"
true | sfdisk -nbO "$disk-raw" "/dev/$disk"

sfdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdb1  *          2048  117442559  117440512    56G  7 HPFS/NTFS/exFAT
/dev/sdb2        117444608 3907028991 3789584384   1.8T  f W95 Ext'd (LBA)
/dev/sdb5        117446656  680304640  562857985 268.4G  7 HPFS/NTFS/exFAT
/dev/sdb6       1650739200 3802169343 2151430144     1T  7 HPFS/NTFS/exFAT
/dev/sdb7       3802173440 3907026944  104853505    50G  7 HPFS/NTFS/exFAT

• I boot the computer from the USB with Acronis Disk Director 11 (stable and many times verified version). I know about GParted, but Acronis DD works faster.
• I reduce the unencrypted partition Y (for example, by 100 GB) using Acronis Disk Director to make room for partition X.
• I boot the computer from the USB with Ubuntu 18.04.

• I make the second backup of the partition table.

• I expand partition X with cfdisk:
  cfdisk /dev/sdb
resize
write
quit

• I make the third backup of the partition table.

• I boot into Windows 8.1
• I go to VeraCrypt -> Volume Expander and expand partition X.
• The process goes well.
• All disks correctly displayed in Windows and successfully pass the chkdsk checks.

• Then I reboot the computer and find out that ALL LOGICAL (EXTENDED) PARTITIONS IS ABSENT!

• I boot Ubuntu 18.04 from the USB.

• I check the current state of the partition table:

root@ubuntu:~# sfdisk -l /dev/sdb
Ignoring extra data in partition table 6.
Ignoring extra data in partition table 6.
Ignoring extra data in partition table 6.
Invalid flag 0x4888 of EBR (for partition 6) will be corrected by w(rite).
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdb1  *          2048  117442559  117440512    56G  7 HPFS/NTFS/exFAT
/dev/sdb2        117444608 3907028991 3789584384   1.8T  f W95 Ext'd (LBA)
/dev/sdb5        117446656 1650737153 1533290498 731.1G  7 HPFS/NTFS/exFAT
/dev/sdb6       3754030439 4445899316  691868878 329.9G a0 IBM Thinkpad hibernation

Note the "Invalid flag 0x4888 of EBR (for partition 6)" and "3754030439 4445899316 691868878 329.9G a0 IBM Thinkpad hibernation".
These values are absolutely random and last time were different.

• I find the partitions boundaries in my last backup:
  cat sdb-sfdisk-l
• I create partitions again through parted, using START and END from the backup:

parted /dev/sdb
unit s
print free
mkpart logical ntfs 1650739200 3802169343
print free
mkpart logical ntfs 3802173440 3907026944
print free

Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start        End          Size         Type      File system  Flags
        63s          2047s        1985s                  Free Space
 1      2048s        117442559s   117440512s   primary                boot
        117442560s   117444607s   2048s                  Free Space
 2      117444608s   3907028991s  3789584384s  extended               lba
 5      117446656s   1650737153s  1533290498s  logical
 6      1650739200s  3802169343s  2151430144s  logical   ntfs         lba
 7      3802173440s  3907026944s  104853505s   logical   ntfs         lba
        3907026945s  3907028991s  2047s                  Free Space
        3907028992s  3907029167s  176s                   Free Space

quit

sfdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos

Device     Boot      Start        End    Sectors   Size Id Type
/dev/sdb1  *          2048  117442559  117440512    56G  7 HPFS/NTFS/exFAT
/dev/sdb2        117444608 3907028991 3789584384   1.8T  f W95 Ext'd (LBA)
/dev/sdb5        117446656 1650737153 1533290498 731.1G  7 HPFS/NTFS/exFAT
/dev/sdb6       1650739200 3802169343 2151430144     1T  7 HPFS/NTFS/exFAT
/dev/sdb7       3802173440 3907026944  104853505    50G  7 HPFS/NTFS/exFAT

• Now, logical partitions 5, 6, 7 have been restored.
• I'm doing the third backup.
• I reboot back to Windows 8.1.
• The disks are displayed normally.

Important: this problem stably reproduces every time! And even in a virtual machine!
I think this is a terribly serious bug that needs to be fixed as soon as possible.

I can attach some more data if this helps to fix the bug.

[BaggerMAN]

And in general, it's very strange that VeraCrypt makes some changes in the partition table, because it is NOT NECESSARY to do this.

The partition is already extended with cfdisk (because VeraCrypt can not do this itself).
Therefore, VeraCrypt need only fill this partition with random data and increase the file system inside it.

Why does VeraCrypt interfere with the partition table?

[Alex Kay]

"Why does VeraCrypt interfere with the partition table?"
I'd like also know this. And more importantly how to recover the table back?
That's why so many people lose data.

[BaggerMAN]

And more importantly how to recover the table back?

If you have previously made a backup of the partition table as I described above, then it is not difficult to restore the partition table. I described all this above.

But if you do not make a backup of the partition table in advance, then you will have to use the programs to find and restore partitions: Acronis Disk Director, testdisk, etc.

In any case, this is an extremely risky task caused by this terrible bug, which needs to be fixed urgently.

[Alex Kay]

Unfortunatly I didn't make a backup nor did I make a backup of my data...I am just an average user who doesn't have an indepth knowledge.
I tried several recovery programs and none of them were able to recover partition. I was able to recover some files though....but not all.