Comment by __MatrixMan__
3 hours ago
I worry about approaches like this because maybe the forensics tool fills all available space and then clears it, noticing that this particular phone is an anomaly re:
manufacturer published space = allegedly available space + size of known files
If you're hiding something in "empty space" it won't behave like empty space when you try to fill it.
I think we need to be stenographically smarter. Like if there's some mechanism of deduplicating blocks across volumes, then perhaps when given the special key you could temporarily render a volume whose parts are hidden in the data already occupied by the other volume and then just run it in memory so that a reboot clears it.
That's not how VeraCrypt hidden volumes work.
> If you're hiding something in "empty space" it won't behave like empty space when you try to fill it.
Yes, it will. It will overwrite the hidden data.
When you have a 1 TB drive that you encrypt with VeraCrypt using a hidden volume the following happens:
You have an outer decoy volume. This volume is 1TB in size and works like any other VeraCrypt volume.
You have a smaller, hidden inner volume with a different password. When you unlock this volume the following happens: Veracrypt tries to unlock the normal voume, but fails because the password is incorrect. It now tries to decrypt a secondary volume header at an offset. This header contains the layout for the hidden volume which is positioned inside the free space of the outer volume. So the position of the hidden volume is encrypted.
Now when you want to plant decoy files in the outer volume you actually do the following: While unlocking the volume you enable the option for hidden volumes and now you enter both passwords. So VeraCrypt knows where the inner volume is located and how large it is so it will not overwrite it. VeraCrypt will show the adjusted smaller size for the outer volume.
When you're in a situation where you are forced to give up your password: You tell them your decoy password. They open the outer decoy volume. It appears like any other VeraCrypt volume spanning the whole size of the disk. If they write any files to it that might overwrite parts of the hidden volume.
Notably all standard VeraCrypt volumes principally feature the option of hidden volumes. You cannot proof that a VeraCrypt volume does not have a hidden volume (short of it being full in the first place). The user base of people not using hidden volumes gives the plausible deniability to the people who do. Which is worth knowing as this can get you in trouble in certain scenarios.
There are some issues with this though:
SSD wear leveling and especially TRIM. You must not TRIM the blocks of the hidden volume, which can reveal it as it shall appear as free space that would usually be trimmed. So disable TRIM, which is suspicious in itself. Though TRIM also leaks information about file layout even for normal volumes, so there is some plausibility left. But it's not ideal. This is not an issue with HDDs (maybe with SMR though).
I don't remember exactly, but I think you can do statistical analysis on the layout of files inside the outer volume and deduct the existence of the hidden volume from this under certain circumstances. Essentially, in a normal volume the filesystem would have written this file to these blocks, but it didn't and chose other blocks instead. So there must have been a block layer translation that reroutes blocks from the hidden volume and these free blocks that should not be free must be the hidden volume. I'm not too sure that's really what it was about.
5$ wrench method. I suspect you are hiding certain information in this VeraCrypt volume. I torture you. You give me the password. The information is not in there. Either you do not have the information or you are lying and using a hidden volume. I continue to torture you for the second password on the chance that you're using a hidden volume. This is what I was about earlier when I said VeraCrypt can get you in trouble.