What Survives After Quick Formatting a VeraCrypt Drive with an Outer and a Hidden Volume?

[Michael Miroshnichenko]

Hi everyone! We recently conducted a laboratory experiment to investigate what happens when a USB drive containing both an outer VeraCrypt volume and a hidden volume is accidentally Quick Formatted.

I'm one of the developers at Hetman Software, a Ukrainian company developing commercial data recovery software for over 15 years. We used Hetman Partition Recovery in this experiment, but I'd like to focus on the VeraCrypt structures, what survived the formatting operation, and why recovery was possible.

The test was performed on a USB flash drive. No additional user data was written to the drive after Quick Format.

1. Initial configuration

The USB drive contained two encrypted volumes:

• Outer VeraCrypt volume: NTFS filesystem.
• Hidden VeraCrypt volume: exFAT filesystem.

Both volumes used different passwords and contained test files, including images, documents, archives, and videos. Before the experiment, both volumes could be mounted normally using their respective passwords, and all test files were readable.

We then Quick Formatted the underlying USB partition as exFAT, without formatting either decrypted VeraCrypt volume. After formatting, Windows recognized the USB drive as a new 14.46 GB exFAT volume.

Screenshot 1: The original encrypted partition is now recognized as a newly formatted exFAT volume.

2. What did Quick Format actually overwrite?

The partition still started at sector 2048 and contained 30,324,736 sectors, but its contents had changed. At the beginning of the partition, we found a valid exFAT boot sector instead of the original VeraCrypt header structures.

Screenshot 2: HEX view of the newly created exFAT boot sector. The filesystem metadata also includes a FAT, allocation bitmap, and root directory.

The important distinction is that Quick Format did not overwrite the entire previously encrypted area. VeraCrypt stores embedded backup volume headers near the end of non-system encrypted volumes. When hidden volumes are used, the format also provides separate header structures for the hidden volume.

In our experiment, the backup headers survived the formatting operation. That gave us a way to access the encrypted data using the original passwords, even though the beginning of the partition had been overwritten.

3. Recovering the outer NTFS volume

We first analyzed the affected partition using Hetman Partition Recovery 5.4 and entered the original outer-volume password. Using the surviving VeraCrypt backup header, the software was able to decrypt the outer volume and identify its original NTFS filesystem.

We then examined the decrypted filesystem in the built-in HEX editor.

Screenshot 3: HEX view of the decrypted outer volume showing its NTFS boot sector, including the NTFS signature and recognizable filesystem structures.

The original NTFS directory structure was accessible, and the test files could be opened and previewed. This demonstrated that overwriting the primary header area did not necessarily destroy access to the encrypted data.

In our case, the remaining backup header and the correct password were sufficient to regain access.

4. What happened to the hidden volume?

The next question was whether the hidden VeraCrypt volume had also survived. We returned to the affected encrypted volume and repeated the analysis, this time using the hidden-volume password.

The software successfully accessed the hidden volume and identified its original exFAT filesystem.

Screenshot 4: HEX view of the decrypted hidden volume showing its own exFAT boot sector and filesystem metadata.

The hidden volume's files were also accessible and readable. Therefore, after Quick Format, the same physical encrypted partition could still be opened in two different ways:

• Outer password → original NTFS filesystem
• Hidden password → hidden exFAT filesystem

This did not involve breaking VeraCrypt encryption or recovering unknown passwords. Both original passwords were available. The recovery was possible because the necessary backup headers and encrypted filesystem data remained intact.

5. Why did recovery work?

Several conditions were important in this experiment:

1. The partition retained its original starting position and size.
2. The embedded backup headers survived Quick Format.
3. The encrypted filesystem structures remained sufficiently intact.
4. The original passwords for both volumes were known.
5. No additional user files were written to the USB drive after formatting.

VeraCrypt itself provides functionality to restore volume headers using embedded backups. Our experiment used third-party recovery software to analyze the affected partition, access the encrypted volumes through their surviving headers, and examine the decrypted filesystems.

6. What if we had written new files after Quick Format?

This is where the outcome could have been very different. Quick Format creates new filesystem metadata without necessarily overwriting the entire storage area. However, the new exFAT structures already occupy sectors that previously belonged to the encrypted volume.

Every subsequent write can cause additional damage. Depending on which sectors are overwritten, this could affect:

• Encrypted filesystem metadata.
• Encrypted file contents.
• VeraCrypt backup header information.

Even if a valid backup header survives, it does not guarantee that the complete decrypted filesystem can still be recovered. The behavior may also differ on SSDs or other storage devices that support discard/TRIM.

7. Questions for the VeraCrypt community

I'd be interested in hearing about similar cases.

• Have you encountered situations where Quick Format overwrote both the primary and embedded backup headers?
• Have you seen cases where the backup headers survived but the encrypted filesystem was no longer recoverable?
• Would it be useful to compare the same Quick Format scenario across VeraCrypt, BitLocker, and LUKS?
• What additional tests would you suggest for a more complete investigation?

We're interested in reproducing realistic encrypted-volume failure scenarios and documenting what can actually be recovered, including unsuccessful attempts. I'd be happy to discuss the technical details, recovery process, and limitations of this experiment.