[greyface-]

Modern SSDs are log-structured under the hood. The presentation to the host system as a random access block device is an abstraction on top of that, emulating the semantics of spinning rust. Inspecting the underlying log will reveal the location of the hidden area, even if it looks random when read linearly.

[vlovich123]

I’m not so sure that log structure would reveal to you VeraCrypt style hidden volumes. It would only tell you about which blocks are allocated but the whole point is that VeraCrypt would allocate the whole space and within it have hidden space. You wouldn’t be able to infer (at least ethically, but you could lie) whether or not a hidden partition exists because you don’t know if the allocated block is present in the filesystem or was just allocated and never trimmed.

[teravor]

> allocate the whole space

what do you imagine allocation is in this context? it's just a set of written blocks that mark address ranges and other metadata for the OS filesystem driver (all encrypted).

firmware metadata will leak the fact that there is churn in the address range where a potential hidden volume lies. the churn will be inconsistent with filesystem activity that would be present in its absence.

it's not just SSDs you need to worry about either, HDD firmware also keeps metadata, some of it could be be proxy to churn by region.

[vlovich123]

> churn in the address range where a potential hidden volume lies.

You’re assuming separation exists. VeraCrypt specifically and intentionally allocates the hidden partition blocks from the unallocated space within the normal partition. You know, the same thing that would happen if you wrote a file. Even if you had access to the “open” partition, you couldn’t conclude that “there’s allocated blocks but no files, thus hidden partition” - that presumes the filesystem would TRIM immediately, which is indistinguishable from “there’s just a lot of deleted files that haven’t yet been GC’ed”.

Now to be clear, VeraCrypt specifically is believed to be susceptible to SSD side channel attacks, but even still it’s not definitive conclusions. You’re less likely to be betrayed by the firmware than the OS helpfully remembering you opened a file on a hidden partition and saving that history into the unhidden partition.

[greyface-]

It would also give you information about the order in which blocks were written, and the historical state of the disk. Because of wear leveling, block allocation isn't just a one-time initial thing; the mappings between logical and physical address space are changing with each write.

[vlovich123]

That still doesn’t tell you anything about the existence of partitions within the filesystem UNLESS you discover a side channel attack.

[greyface-]

The VeraCrypt documentation disagrees with you:

> If you need plausible deniability, you must not use VeraCrypt to encrypt any part of (or create encrypted containers on) a device (or file system) that utilizes a wear-leveling mechanism.

https://veracrypt.io/en/Wear-Leveling.html

[OsrsNeedsf2P]

If you have access to the SSD, you can just see the partitions anyway. I assume the threat model here is simply safely showing the agents "your phone"