Don't even need to go that far. Just short all the pins and you will will kill a lot of motherboards.
My friend accidentally jammed his headphones into the front USB socket on his PC and killed the motherboard. Of course it doesn't work on all computers, my old laptop would just shut down (which is still inconvenient), and I'm not sure what would happen to my Macbook (and don't want to find out).
> Don't even need to go that far. Just short all the pins and you will will kill a lot of motherboards.
Interesting. USB 2.0 spec mandates overcurrent protection on the power rail and ability to withstand continuous short circuit to ground or power on the data pins. I think 3.0 lifted the latter requirement, though.
But I never tested actual hardware for that, besides power short-circuit protection which seems to work on my machine (YMMV).
There's a computer inside that SSD that reads a soft signal to decide if writing is enabled or not. More often than not its firmware is full of known bugs.
Correct me if I'm wrong, but that's because SD cards are half duplex, right? So there's no way to disable writing through a "disconnect pins x and y" because those pins are needed for reading.
SD cards implement a simple four-pin mode (SPI) for which there's public documentation, and a proprietary mode parallelizing data over more pins. I know more about the former than the latter, but it's probably a similar situation.
SPI is full duplex; it has a dedicated line per data direction (MISO and MOSI), however the same lines are used for commands and data. So with MOSI (master out, slave in) physically disconnected, it'd be impossible to send the command asking to read data, even though that data would be delivered on the separate MISO (master in, slave out) line.
most paranoid I can think of: Use an Atmel AVR (Harvard architecture means no code execution, and it doesn't have low-level firmware that could be vulnerable) to read the filesystem and sanitize data, then feed it over serial to a host machine to analyze?
If you trust your hardware and VM hypervisor to be secure, pass the USB controller to a VM?
I'm wondering if even this route is no longer safe - stcredzero comment [1] points out things that could be added to completely circumvent even a system that is essentially "off-the-grid" or just uses the USB for power.
Right, you can't tell if there is a hidden malicious component that hasn't been activated yet. You can extract assumed non-malicious data without giving a malicious component the ability to do anything, if it hasn't an build-in data exfiltration channel (microphone and wireless transmitter could spy on you without attacking your system)
I guess one could setup a jammer or some room that could completely cut off any signal possibility. However then they could put something even more malicious then just spying into the device. As much as a tin foil hat theory that is, maybe it's just best to not know what's on the drive cause it's more than likely not worth even the slightest bit of trouble. Sad the world has come to this
There are commercial test products that are "dumb" enumerators. I used to have some in the lab I worked at. You can script low level usb commands to them and see how the device responds. Here is an example that is pretty simple.
Again I can't remember the cost, but I think it was about $30K or so.
Anyway in theory with a device like this you could develop a test to check a device actually only performed the functions it was supposed to, like for instance it never changed its USB descriptors from the function it was supposed to have.
Sand-boxed environment I would have to say. But as the article states this attack vector could become more sophisticated (if it has already not gotten to this level for sectors that can afford this).
If anything I would say it's not worth it all, just turn it in to your nearby local law enforcement or trash it, not worth what could be the last thing you plug into your computer.
To whomever down-voted me: will that not work? I know on my system at least I can tell it to prompt me when a new USB device is inserted to mount it to the VM directly. In which case key presses would go to the VM. So as long as it doesn't issue a key sequence to escape keyboard capture all key presses should go to the VM... or am I missing something?
If you plug a keyboard in your system the system doesn't take key presses from it until you've confirmed what to do with it? That's at least an unusual configuration. Otherwise it could run the malicious sequence before you had time to switch the connection to the VM.
