2 ms·

This is pretty nifty, but I have to imagine that it is also detectable if you look for it. The drive can't differentiate between being read for execution and b

This is pretty nifty, but I have to imagine that it is also detectable if you look for it. The drive can't differentiate between being read for execution and being read for analysis. So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change. Such a program could be injected into the firmware of the machine, so it will never be read from disk, and it is unlikely need updating. One could also produce a second, clean room, program which does the same thing. This could serve as a back up in case a buffer overflow or similar exploit is found and leveraged in the first validation program. Additionally, without the ability to self-update its signature database, version updates would render this hack ineffective.

josephg 5y ago
> So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change. The drive could do things like serve up a malicious version of a system DLL on boot (within the first 20 seconds of being powered on). Then deliver unmodified copies of the file on subsequent read requests. An attack like that would be difficult to detect even if you plugged the drive into another computer. And as for self updating, the payload could make internet requests, and fetch updated versions of itself online. The controller could then look out for any write which contains a well known sequence of (seemingly random) bytes. And then flash itself with subsequent bytes written to disk. The system component just needs to write the update to a temporary file, flush to disk, then immediately deletes it again afterwards. I agree with some other sibling posters that the best protection against this is probably full disk encryption. Is that enabled by default yet on windows or macos?

josephg 5y ago

> So if an executable has been modified from the expected value, presumably a bit-by-bit or checksum comparison would reveal the change. The drive could do things like serve up a malicious version of a system DLL on boot (within the first 20 seconds of being powered on). Then deliver unmodified copies of the file on subsequent read requests. An attack like that would be difficult to detect even if you plugged the drive into another computer. And as for self updating, the payload could make internet requests, and fetch updated versions of itself online. The controller could then look out for any write which contains a well known sequence of (seemingly random) bytes. And then flash itself with subsequent bytes written to disk. The system component just needs to write the update to a temporary file, flush to disk, then immediately deletes it again afterwards. I agree with some other sibling posters that the best protection against this is probably full disk encryption. Is that enabled by default yet on windows or macos?