I think part of the entire design is that it's quite hard to detect.
1: Reads/Writes are just routed to a COTS SD-card. 2: Unless the (correct?) password is detected in the write-data that starts the disconnect procedure.
The only way to detect it from what I can see is to profile writes then append a "password:" string multiple times to measure the write-delay, only works if the CPU cost is large enough to overtake the SD-card measurably and some constant-time optimizations should make it more or less undetectable.
It's a clever design and I think it should be possible to optimize to become more or less unrecognizable.
If I was building a black box to detect hidden data on a USB stick, I'd include a feature whereby it measures power consumption and flags USB drives that don't consume the expected power for that type of drive.
Can you flesh that out? If I've missed something and oversimplified the design here, I'd want to clarify that!
> The only way to detect it from what I can see is to profile writes then append a "password:" string multiple times to measure the write-delay,
- Have the first check be a simple 8bit hash that filters out most passwords in microseconds, or use a customizable prefix instead of “password:”.
- have your password checking thread run in background at idle priority
- when you get an async password match, force usb disconnect and reconnect and the system will rescan the bus and mount your real drive.
Short of adversary dumping drive firmware (or them figuring out your hn account t, having a LLM scan the messages and finding this conversation) it’s not really easily detectable..