Hacking USB Firmware
An anonymous reader writes Now the NSA isn't the only one who can hack your USB firmware: "In a talk at the Derbycon hacker conference in Louisville, Kentucky last week, researchers Adam Caudill and Brandon Wilson showed that they've reverse engineered the same USB firmware as Nohl's SR Labs, reproducing some of Nohl's BadUSB tricks. And unlike Nohl, the hacker pair has also published the code for those attacks on Github, raising the stakes for USB makers to either fix the problem or leave hundreds of millions of users vulnerable." Personally, I always thought it was insane that USB drives don't come with physical write-protect switches to keep them from being infected by malware.
(More on BadUSB here.)
Back in my day we used to cut another write enable notch on the opposite side of floppy disks so we could write data on both sides.
They're not writing to the filesystem, so that won't help.
Not a sentence!
...were made of fused quartz, because UV wont go thru normal glass.
That's why the erasable ones were so expensive.
Truth isn't Truth - Guliani
Lock Switch? Then you don't understand the problem. The problem is that in many USB Flash are two chips: a computer and memory. The host PC communicates with the USB controller and the controller talks to the memory. Most controllers are just a version of the 8051 CPU with USB logic bolted on. The lock switch would be a high-level function that returns an error on a generic block device write command. Hacking the USB device isn't hacking the flash memory, it's hacking the firmware on the 8051. The Device Firmware Update function of USB that allowed that 8051 computer to be reprogrammed should be disabled.
This is a boring sig
You're completely misunderstanding the problem. It has nothing to do with flash drives, it has to do with USB devices, some of which happen to appear as block devices. Every USB device that you plug in has a controller chip, which runs a small program (the firmware) that implements the client part of the USB specification. Some of these are quite complex. There was an attack a few years ago on USB keyboards: some models come with 128KB of flash but only use 65KB for the firmware. You can replace the firmware with something malicious and have 31KB to cache keylog data for emptying when you plug in a specific device.
The firmware on the controller chips is not public, not audited, and generally written by people who have no idea about security. If there's a bug in it that allows a compromise, then you can use the controller to attack the host system. Lots of USB drivers behave poorly in the presence of malformed USB protocol messages, so all you need is to find one buffer overflow and you've got a kernel-mode exploit. Worse, some of the vulnerabilities are not in the drivers, but in the firmware of the USB host controller chip on the motherboard. If you can compromise that, then you can sniff a load of messages going across the bus in a way that's completely undetectable from the OS.
I am TheRaven on Soylent News
On page 6 I find out that the write enable signal is called WE, like always. And on page 7 I find out that it's on pin 18. What do you suppose happens if I switch open pin 18?
Most likely the whole device would stop working completely. You probably wanted the WP (write protect) line. The WE line is used for other functionality, as explained on page 9.
Even then, you are looking at the wrong flash memory. You are looking at the bulk memory used for storing user data. The microcontroller that handles the USB interface has its own internal flash memory, typically quite small at less than 1M words. That is where it's program code is stored, and microcontrollers rarely have an external write protect pin. Sometimes there is memory protection built in, but typically it only prevents you reading the program code and doesn't stop you erasing and replacing it with your own. Besides which, many deliberately include a handy bootloader so that the manufacturer can easily write their firmware over the USB interface without special tools.
Even if you somehow did secure the microcontroller it wouldn't be hard to replace with a hot air gun. Basically, no matter what you do, USB devices can't be trusted.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC