|
|
|
|
|
|
by 05
9 days ago
|
|
|
> 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.. |
|
|
So detecting this drive is just a matter of writing "password:anything" to the drive, unmounting, remounting and checking the file you just wrote. If it's not what you wrote, then you have detected the existence of this drive.
The parent comment was correct that if this was mitigated by testing if the key is valid then you can detect it by checking for timing differences between writing a sector that starts "password:" and one that doesn't. Moving the password check async just means that you run the risk of having the real password written to the SD card before it was detected.
If you buffer that sector from being written, then you might be able to detect it because the write was faster than expected, or if you write the modified version and go back and overwrite it with the original if the check fails, then you will slow down a different subsequent access, again which would be detectable. This would also invalidate one of the design goals of never keeping the password in memory, only the derived key.
Having a customizable prefix is possible, as the project is open source. Personally, I'd be tempted to make this possible on the base build by storing the prefix in the hidden area of the SD card.