The keyboard trick is quite a hack, but creative. At the same time afaik most barcode scanners also act as keyboards, you scan a number, it "types in" those numbers.

I can't see how the filesystem hack would work, if the OS has the drive mounted, it would cache files in memory, and not notice the file contents changing. You can't even modify the metadata, because most of that might also be in memory.

Barcode-as-a-keyboard was one of the vectors that researchers at last CCC used to hack ATMs. End result: show two barcodes, cash gets out.

https://media.ccc.de/v/35c3-9761-truly_cardless_jackpotting_...

USB is trash for security.

Don’t think that’s a vector per se. The ATM accepts untrusted USB keyboard input (THAT is the bug)—the barcode reader is just a product that happens to make it easy to type in the right series of characters. You could have done the same thing with a normal keyboard (or an Arduino, if you wanted the convenience)

I wouldn't be terribly surprised if you could create a barcode that caused a barcode reader to send <windows key>+r and run some arbitrary command. So perhaps it wasn't a vector for an ATM, but maybe some other barcode reader where workers scan in arbitrary things they are handed...TSA maybe?

As far as I remember that's roughly how that exploit against an ATM worked:

https://xlab.tencent.com/badbarcode/

Also, perhaps folks working in data centers can and confirm/deny, but from what I know it's usually strictly forbidden to bring any USB devices into a data center area.

We use USB drives as installers and, in some cases, as boot volumes. (And of course keyboards and mice on crash carts and USB serial ports for laptops.)

We’re not a cloud provider, but I’ve been in lots of DCs and seen plenty of USB devices.

I'd love to have a crash cart. I'd spend all day crashing it into other carts.

Before chip embedded credit/debit cards were prevalent, most magnetic strip reader (MSR) peripherals would often operate as a USB keyboard. It allows them to work with web app based POS systems without requiring things like ActiveX.

Same but different... I was working to get a Hotel property management web application running on iPad so host could check in people away from desk. The web application supported MSR swipe keyboard entry, but you can’t plug in a generic USB MSR device into iPad. I wrote a custom iOS keyboard that interfaces with lightning MSR and its API and the “typed” the characters into Safari. It was nice to be able to use generic Safari and not some App wrapper. And it wasn’t too difficult on host to change keyboards to swipe.

In high school we messed around with this in the crappy P.O.S. system at the place I worked (windowed app, running on Windows) to see what data was recorded on all our various student ID cards, gift certificates etc.

I was delighted about this when a client wanted a barcode scanner integrated with a web app. I envisioned major difficulties but instead it only took 5 minutes to implement.

Yep! I have a webapp that's been handling physical print-based photography awards for 7 years now. It generates a PDF label with barcode that the entrant sticks on the back of their print, and then they're shipped to the judging location and the award staff scan 4000+ entries over a couple of days. The barcode scanning was the easiest part of the whole project.

Emulate a MTP device (often used by cameras) and mount with a fuse driver. Since the content on the remote device can change the driver shouldn't be caching it.

Or emulate a network, generate a DHCP response for your favorite /31 and don't send a router, and point a public domain name at the other address in that /31.

I'm not sure if you are serious. My goal was to use an USB device standard for which open source drivers exist and which doesn't open security holes by allowing it into your system.

MTP devices are ~mostly harmless~ and relatively easy to trust. Network devices are not.

Can you elaborate? I understand the concept of RNDIS or CDC devices, but if you've sent an IP address only without a router, how is any traffic going to make it back to the other IP in that subnet? I figure it will go back over the default route, but how are you in control of the traffic itself?

The subnet mask determines the size of the connected network, which is in itself a route in your routing table.

It's the same mechanism used to reach your router. Subnet-local / connected routes are routes in themselves. Routers let you leave your subnet.

at that point you might as well just use the real drivers.

this is how they've always worked. How else should a barcode be entered by a scanner?

The driver could read data from the device and clamp the results to a reasonable number of non control code characters.

Eeewww. Why not just make it a virtual com port, which most computers already have drivers for?

Because Windows, the most popular operating system on the planet, didn't have VCOM drivers by default until Windows 10.

This is why everybody tries to piggyback on being a USB HID device.

It did for a few different devices, they could have mimicked one of those.

Source: Have plugged several brands of USB-to-COM adapter in to Win 7 / 8.1 and they've "just worked".

Somebody, somewhere had to install a driver. And, because you could never count on it, you can't design to it.

Now, since most things use a Prolific chip, you only have to install the driver for one device and you pick up a ton of them.

But it has to be installed by somebody, and that means all of the silliness that goes along with Windows driver installation.

FTDI chips have their driver deployed by default on most Windows, Mac and Linux installs. It's nice being able to buy a USB/serial cable and it just work, without needing to deploy any drivers at all. Check it out!

Had to install FTDI drivers on (an admittedly old) Windows laptop 3 weeks ago before I could use it to talk to the Cisco gear I was reconfiguring ...

IIRC the FTDI chips use a non-standard com driver on Win 7. IF you want your device (with your VID and PID) to show up as a serial port, you need to associate your device with the usbserial driver, which at the very least requires a custom .inf.

funny thing: my UPS also presents as a keyboard. and made my computer kept waking up from sleep at random intervals.

Very hard to troubleshoot.

That's kind of ingenious, but is sending temperature data over USB really such a hard problem in the first place? I'm not really familiar with the USB protocol.

USB doesn't work without a driver and sometimes you don't want to (or can't) install a driver. This sounds like the kind of hack that a clever (but arguably unwise) engineer would shove in to help them remotely troubleshoot a device.

"Sensor not detected? OK, open up Notepad and hit Caps Lock three times quickly. Did some text appear? The sensor is fine, the problem is with your computer."

It's not that hard to pick some standard class, like CDC and have a userspace app that uses it just like a serial device. You can get info on which serial device to use via sysfs on Linux.

The rest is just making up a serial protocol.

No need for a special driver.

Would this work for every operating system without requiring the user to do anything?

It was a long time ago, but I’m pretty sure CDC doesn’t auto-enumerate on Windows. Mac and Linux is fine. I think you still need a .inf for Windows, and for it to work generally, you need WHQL signing ($$, time).

The free (money-wise) approach we ended up doing was to use WinUSB and marking the device as “vendor specific”, and using libusb to talk directly to it. That was a bit awkward, but covered Windows, Linux, and OSX for us.

This was 5 years ago though. Windows 10 might directly support generic CDC devices, but Win 8.1 didn’t.

Edit: sibling mentions HID. HID does work like this, but we needed more bandwidth than HID provided. CDC was perfect for what we were doing but it didn’t auto install. Mass storage auto-installs but didn’t fit what we were doing.

Well, define "work", "every operating system", and "requiring user to do anythig".

:D Obviously you have to consider needs of your users as an engineer, when chosing any technology, for their particular problem.

USB can and does work without custom drivers. It's the raison d'etre for HID.

But that requires custom software to interface with it and parse the data or make payload requests and developers are that lazy.

why is this unwise?

Because it could lead to all manner of weirdness that the user doesn't expect. Imagine someone trying to type some data into a spreadsheet and every time they hit the capslock key a strange text string appears in the cell, maybe leading to data corruption. Or even worse, it happens in some program where the typed characters are interpreted as hotkeys and instantly perform some unknown combination of actions which the user may or may not even know occurred.

He failed to consider that people on hacker news would tut disapprovingly at his hack.

You can actually use the USB hid class to present pretty much any data in any way you want. The reason they present as a keyboard is probably so they don't need to worry about drivers. With newer versions of windows I think you can work with such hid devices without special drivers though.

Seems like the core problem is a single standard for many different kinds of devices, which makes it possible for devices to act totally different from what it physically appears to be.

Maybe we should have stuck to PS/2 keyboards after all.

I've use those as well, bit of a pain to work with in non keyboard mode but they are at least accurate enough.