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.
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.
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.
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.
SSD/NVMe keep track of what regions are wiped and which contain data that has to be preserved. To hide something in the seemingly-unused space, you have to turn off trim, eat the performance cost, and pretend you had a reason to have turned off trim.
I don't believe having trim disabled even helps here. smart firmware sees the same address being written to and may therefore reassign it to a different cell for wear leveling. it's a de facto trim.
trim lets the firmware know which mappings it can discard without the explicit reuse of the same address.
however I don't believe you can observe this effect from trim command results, it will report the usual size trimmed as if the firmware never realized that you reused the same address range multiple times.
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.
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.
> 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.
1 reply →
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.
2 replies →
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"
SSD/NVMe keep track of what regions are wiped and which contain data that has to be preserved. To hide something in the seemingly-unused space, you have to turn off trim, eat the performance cost, and pretend you had a reason to have turned off trim.
I don't believe having trim disabled even helps here. smart firmware sees the same address being written to and may therefore reassign it to a different cell for wear leveling. it's a de facto trim.
trim lets the firmware know which mappings it can discard without the explicit reuse of the same address.
however I don't believe you can observe this effect from trim command results, it will report the usual size trimmed as if the firmware never realized that you reused the same address range multiple times.
Data recovery providers can probably get access to firmware-internal metadata.