Good with a keyboard and fluent in gibberish.
Background Illustrations provided by

At work, we have a big display (that will be) mounted on the wall and driven by a Beaglebone Black. We thought it’d be cool to be able to show each other what we’re doing by throwing it up on the screen.

After some research, I decided to use x11vnc. I thought I’d have to SSH in to the Beaglebone and set up a port forward. But then I read the man page for x11vnc and discovered VNC reverse connections.

A VNC reverse connection is when the VNC client (the one displaying) listens and the VNC server (the one with the applications) connects to it. Using this, I could create a simple daemon with off-the-shelf programs and the tiniest of shell scripts.


The Beaglebone Black already has an .xsessionrc on its user, so you just configure it to autostart X and then add xvncviewer -listen 0 -fullscreen & to the end. Easy peasy.

As a bonus, we set up a hostname and mDNS on the Beaglebone so that we don’t have to deal with static IPs, servers, DNS entries, etc.


The client script is a bit more involved just because I went a little overboard on options to make sure weirdness didn’t happen. We install this script on each machine we want to connect to the display.

Due to our individualized configurations, we have different options to send to x11vnc.

  • I have two displays, so I use -clip xinerama0 and -clip xinerama1 to switch between them.
  • My coworker has a display of a higher resolution than the display mounted, so he uses -scale 3/4 to

Does it work?

It works well! Videos don’t play well and there’s a lot of tearing, but it works. Multiple users work fine, too; they just stack up in connection order, so the newest one is on top.

In fact, the only changes I want to make are things like removal of the desktop environment on the display and the set-up of a default application.

This is the actual talk going into full detail on BadUSB. Some of the attacks they’ve discussed are meh, but some are horrific. It is important to note that BadUSB itself does not depend on any security holes; it is a systemic design vulnerability. None of the techniques I highlight use a security bug, either.

DISCLAIMER: I am not a security researcher or by any means a security expert. I am a software developer who’s always been better at building things than breaking them.

The two that really stuck in my mind are an Ethernet+DHCP attack as a stepping-stone for MITM, and fingerprinting attacks.

They discuss an attack where a USB device acts as an network device and has its own DHCP server (there doesn’t need to be any real-world network connection on the device for this to work). When you plug it in, the Computer sees a network connection and autoconfigures it with DHCP. The device returns a DHCP advertisement with a public DNS server. This server is added to the system’s pool of DNS servers, regardless of interface it came from, allowing it to be used with any request. Of course, whence you’re using a malicious DNS server, that opens a pile of attack vectors.

This DHCP attack could be mitigated by adding a verification to the DHCP daemon/service: Just check to see if the interface being configured has a route to the advertised DNS server. If not, don’t use that DNS server. Unless the device does have a network connection. Or it has the route and DNS server in the device as well.

The second attack that caught my eye is a flash drive fingerprinting attack. (This probably only works on devices with significant storage.) A device uses the behavior of the USB host to fingerprint it. If it is an operating system, show a plain-jane flash drive. If it is a BIOS, show a bootable partition. BIOS boots this, and the malicious device installs a rootkit and boots the harddrive.

This application of fingerprinting is of course mitigated by setting boot order correctly, especially since many BIOS now support selecting a boot device in a menu for one time.

The real danger of fingerprinting is that it hides malicious interfaces from scanning. It would be easy to build a stateless stand-alone device that displays the enumeration of a USB device (Raspbery Pi Model A, PiTFT, and lsusb). But if that device is fingerprinting hosts, this scan may or may not show anything out of the ordinary.

The biggest WTF in all this, of course, is why on earth the firmware for a USB device is updatable over USB in the first place? We have test points and JTAG and ICSP for a reason. Karsten & Jakob in fact recommend that USB-based reflashing be disabled at the factory.

For extra fun, reframe that entire discussion in the context of Android phones. I don’t know if Android applications have the ability to define new device profiles for the phone/tablet on unrooted devices. If they do, then all an attacker has to do is get their application on the phone and wait for the user to plug it in to a computer.

The BadUSB website has a proof-of-concept that runs on a rooted Android phone. It demonstrates an attack where the phone runs a DNS server, allowing DNS-based MITM.

I have found an… odd collision of problems. I have the following packages installed:

  • Twisted
  • Google protocol buffers (google.protobuf)
  • The google package from PyPI (not affiliated)

Twisted provides an application system which lets you define .tac files and then have twistd handle a bunch of boiler plate (logging, background, reactor selection, etc).

  1. twistd is installed as a Python file to my PATH (ie /usr/bin)
  2. google installs to my PATH (/usr/bin)
  3. When you start twistd, Python adds its directory (/usr/bin) to its path
  4. When my application imports google.protobuf, Python first imports google
  5. Python finds /usr/bin/ and imports it as google
  6. Python can’t find protobuf in google.

So what went wrong?

  • twistd was installed in such a way to allow unnecessary items into Python’s path
  • google installed a .py file into the PATH
  • I wasn’t using a virtual environment.

I’m now considering the opinion that Python scripts should never be installed directly. Instead, they should be installed as __main__ modules and a shell script of the form exec python2/3 -m mypackage is installed to your PATH.

To start off, I’ll do a brief introduction to sconsduino. It’s a library I’ve been working on at work that lets me write simple SConsconstruct files (for scons) to build software for Arduino. It’s meant to be a step between the Arduino IDE and full raw AVR development.

Currently, it only supports Teensy3, Arduino Pro Mini, and raw ATMEGA328P, because that’s what we use at work.