On Tue, Nov 26, 2019 at 4:49 AM <to...@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
