Comment by teravor
18 hours ago
this will likely fail as block devices aren't dumb anymore, the firmware state will out the hidden volume. counting on the laziness/unsophistication of an adversary isn't a great move.
this problem may be solvable by a purpose-built abstraction where every write no matter what address will look identical to the firmware (naively, a randomized key-value map).
I largly agree, hence why the prudent move is not visiting shitholes like the (current) USA with anything important on your person.
However, if you must do it, there are better options than duress pins that wipe a device.
Not that shufflecake solves the issue you highlighted, but I found the shufflecake FAQ to be a good intro to the topic for anyone curious. It does a good job explaining the threat vectors and the relevant trade offs, in particular the TRIM and ORAM sections. It’s also just a cool project: https://shufflecake.net/
What does “block devices aren’t dumb anymore” mean?
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.
4 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.
1 reply →
I agree that trying to outcompete seems really hard, but also:
Given what the experience of using a non-rooted phone is like, how very very tight the sandboxing is and how useless it is a General Purpose Computer that will tell you anything: I find it very hard to believe the unlocked phone is going to let you start probing firmware & snooping on hidden volumes.
This post sent my BS detector on high alert. I'm struggling to take it seriously.
you do realize what the threat model behind a hidden volume is right?
no one will be accessing the firmware through the OS, they will access it from the PCB/chip/debug port. there is no point to a hidden volume if you cannot credibly deny its existance.