4

After failing to check whether my USB stick firmware can be rewritten AT ALL, I want find out, whether it WAS rewritten when I sticked it in another computer. In particular the question is: how to find out, whether my USB flash drive tries to behave like different devices (or device classes)?

Would it be enough to udevadm monitor and to see if it "removes" itself? Are there any way to controll how Linux communicates with the USB device (like in a console)?

3

Watching udevadm may give you false negatives, as the malicious payload may be triggered by a specific event or after a timeout, and it would not need to act as another USB device to inject malicious payloads in files.

One thing you may do is ensure that no storage area is reserved for malicious purposes: create a non-compressible random file in the hard drive the size of the USB drive, copy it to the usb stick and then verify it.

| improve this answer | |
  • I understand the part about the false negatives. Also interesting point about the non-compressible random file. But what about payloads that reside on the firmware/controller device? – Andrei I Jun 2 '15 at 7:27
  • @AndreiI a firmware cannot be trusted to verify itself: the only way I see is connecting the memory chip to a physical flash programmer and comparing the dump to a pristine version. (Hopefully someone will soon come out with a small USB "condom" that will only allow mass storage commands preventing BadBIOS infections in the first place.) – Enos D'Andrea Jun 2 '15 at 15:24
  • A USB condom against badUSB infections and devices was released as an open project. It is called USG. More information is available on the store and on GitHub. This version is only USB 1.1 therefore is pretty slow. – Enos D'Andrea Sep 29 '18 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.