Good with a keyboard and fluent in gibberish

Tonight, I shall be giving a talk at the local Python Users Group on metaclasses and related. If there are any questions, feel free to ask them here!

So I have the raw database from the Mac version of the Lytro software. Each “image” is a directory with dm.lfp, raw.lfp, stack.lfp, stacklq.lfp, and thumbnail.jpg

The first thing I did was write a script to make galleries from the albums because UUIDs are incredibly unhelpful.

Looking at the other files, you can use lfpsplitter to get the sections out of LFP files. (The format has been reversed, but I’m not writing any software yet.)

I looked over everything. stack.lfp contains some H264 images, but nothing terribly useful. (Nothing like the jpegs lfpsplitter was made for.) However, raw.lfp contains the raw pixel array from the CCD. And raw2tiff can read this. So you just run:

raw2tiff -w 3280 -l 3280 -d short raw_imageRef0.raw raw.tiff

And you get what I’m calling the “bug-eye” view. It’s still needs to be demosaiced  (the process of turning raw CCD pixels into RGB pixels) and the bugeye thing is a problem (microlens problems).

But this solves one of the problems: turning the raw file off the camera into a usable array of pixels. Too bad I don’t know how to get them off the camera or what to do with the pixels after I have them.

I’d like to write my own photo manager for my Lytro camera. My basic problem is Linux support.

I’m not sure what platform to use. HTML5 (in the way of CouchDB + Chrome Extension) is appealing. Easy-to-build interfaces, computer independence, etc.

On the other hand, all the binary files & processing means that a native app might be easier to write. In particular, dealing with dynamic display of “living photos” (stuff with refocusing and other light-field effects).

In any case, having to research and implement the algorithms involved sound like the opposite of fun.

Just watch the Lytro tag for updates on this.

This is how I learned KiCad, the electronics design package. It’s great if you already have some idea about things like electronics and schematics and just need to learn the tools.

Since I’ve watched this, he’s released his whole KiCad course for free. I haven’t really looked into it, since I’ve got other stuff going on, but it might be helpful for you.

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.