[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: USB Examiner Package? Special USB Kernel Modules?




On Tue, Nov 26, 2019 at 4:49 AM <tomas@tuxteam.de> wrote:
On Mon, Nov 25, 2019 at 10:37:42PM -0500, Kenneth Parker wrote:

[...]

> So, what I want, is a USB Debugging Package, that will  *NOT*  attempt to,
> actually open this device, but will give me information about it.

I think before trying an analysis, you'll have to make up your mind about
what you want "open" to mean. With USB, there are many layers involved[0],
from

 - /physical/ (someone mentioned malicious USB devices frying your
   hardware: here[1]'s an actual example; the trick is to overwhelm
   USB's built-in overvoltage protection), through

 - /device/ (what's this: A keyboard? A network adapter? A serial port?
   A mass storage device? A webcam? All of the above?
   This is something typically handled in Linux by udev: once you plug
   in an USB device, some ttyUSB0 or eth17 or something magically
   "appears". Bugs in the kernel and in the udev scripts could be
   exploited here.

   My setup usually ends here: I manually mount my file systems,
   manually add my USB keyboards, etc -- but that's not everyone's
   cup of tea.

 - /higher layers/ When your operating system/desktop environment/
   whatever machinery tries to mount a file system found on a new
   block device, set up a new keyboard or mouse ("human interface
   device", aka HID) whithin your X/Gnome/KDE/Wayland thingie.
   More kernel bugs (file system code is fiendishly complex) can
   be exploited here. The USB can type things into your desktop.
   Other strange things may happen. For a rough idea, enter
   the keyword "badusb" into hackaday[3].

 - /even higher layers/ The new file system may contain code
   to be automatically executed "For Your Convenience" (TM) --
   think Windows AUTORUN.EXE. I'm not sure "modern" free desktop
   environments haven't come up with an equivalent botch: convenience
   is always horribly tempting. And then there are things like
   trying to show you nice icons for the files in that freshly
   mounted file system: even more bugs to exploit there, from
   generic file-content scanning code to rendering code.

 - /even more higher layers/ It's turtles all the way down!

Enjoy the trip

[0] https://en.wikipedia.org/wiki/USB#System_design
[1] https://techcrunch.com/2015/03/12/this-usb-drive-can-nuke-a-computer/ 

Wonderful picture!
 
[3] https://hackaday.com/?s=badusb 

Many thanks!  I *will* Enjoy this Ride.  Between my last response and this one, I found a USB Extension Cord, with a frayed cable.  I just took it apart, separating, and identifying which Wire goes where.  It's made to extend USB-2, meaning that one for USB-3 might have an extra wire or so.  So, when *completely unsure* about a device, I can plug it into that, and use a Volt Meter, to see which wires connect to which wires, and if there is any Voltage.  Remember, here, that I will have a bunch of, Control tests too, including USB-2 and USB-3 *verified* Thumb Drives, USB Keyboards and, finally, a USB Wifi Dongle, with only Closed Source support.  

If nothing else,  I will be on my way to contribute to Reverse Engineering Legitimate, yet unsupported USB Devices.  Once again, I'm already learning quite a bit, from the /doc directory of the Linux Source package.

Once again, let's cool down a bit:  I'm not "knee jerk connecting" all USB Devices into my Production Linux Servers.  I've got a direction to go, and I texted the Windows Friend, to tell him this will "Take an extended period of time".  But I *did* forward him the  [1] Link (above), so that he doesn't ruin something.

Thanks again!

Kenneth Parker

Reply to: