| ▲ | JSR_FDED 15 hours ago |
| What does “block devices aren’t dumb anymore” mean? |
|
| ▲ | greyface- 15 hours ago | parent | next [-] |
| 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. |
| |
| ▲ | OsrsNeedsf2P 28 minutes ago | parent | next [-] | | 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" | |
| ▲ | vlovich123 15 hours ago | parent | prev [-] | | 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 11 hours ago | parent | next [-] | | > 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 3 hours ago | parent [-] | | > 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- 14 hours ago | parent | prev [-] | | 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 11 hours ago | parent [-] | | That still doesn’t tell you anything about the existence of partitions within the filesystem UNLESS you discover a side channel attack. |
|
|
|
|
| ▲ | yencabulator 15 hours ago | parent | prev [-] |
| 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. |
| |
| ▲ | teravor 15 hours ago | parent [-] | | 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. | | |
|
