Well, another fantasy football season is behind us. I entered the season as the reigning champion and left it as the… not champion. It would be churlish to try to make excuses for my poor showing. So instead I’ll simply note that there is an ongoing, pressing need for organ donors in this country, and many of my fantasy players’ families are proud to have done their part. My heartfelt congratulations to Ben on his apparent championship and the masterfully subtle campaign of cheating that must surely lie at its foundation.

But the season did have a few bright spots, even beyond the news that my WR1 is expected to walk again. In particular, I embarked on a semi-ridiculous project to build a Raspberry Pi-powered fantasy football meter. It worked out pretty well!

I should probably begin by assuring you that I’m not actually all that maniacal about fantasy football. It was a purchase that spurred this project: a few months back I bought a big lot of antique electrical gauges on eBay.

(OK, actually I bought two lots.)

Since then I’ve been building some little projects with them using Raspberry Pis and lasercut wooden enclosures. The fantasy football meter is one of the more grandiose examples.

The top gauge measures my ranking in the league. The bottom gauge measures how many points ahead or behind I am at the moment. I realize that this is deeply stupid.

It’s fair to say that I have been working to (slowly) accumulate the expertise necessary for these projects for more than half a decade. It’s made me really, really wish that I had taken some electrical engineering classes in college.

Still, I’ve learned a lot during this process! So why not blog about some of those things?

Cut A Hole In The Box

3D printing gets a lot of attention, and it is indeed frighteningly neat. But for my money a good old-fashioned robotic lasercutter is even more exciting. Anyone who has turned an IKEA flat-pack into an unattractive wine rack will be familiar with the basic principles underlying my approach.

Conceptualizing the transformation from two to three dimensions is trivially easy for some people and essentially impossible for others. I fall somewhere in the middle, and find that I am best served by workshopping a given geometric idea under a variety of pharmacological conditions — specifically alcohol, caffeine and post-workout endorphines. Probably there is some nootropic cocktail available on the streets of San Francisco that delivers innovative furniture design insights and permanent synaptic damage instantaneously, but I’m uncool enough to require lengthy periods of mulling instead.

I would dearly love to employ interesting woodworking techniques, but working in two dimensions more or less mandates the use of finger joints. And really, that’s fine. The one thing you have to watch out for is kerf. Lasercutters work by vaporizing a small amount of material. The width of this area — called kerf — usually amounts to just a tenth or fifth of a millimeter, but it does add up.

I’ve written some python scripts to help generate finger joint geometries that account for tedious kerf calculations automatically. They do require quite a bit of fiddling and subsequent modification in Illustrator or Inkscape, but they work well enough. A nicer online application can be found at makercase.com, but I know my code and like it well enough.

I used Ponoko for this particular trophy, and they provide a wonderful service. But HacDC now has a lasercutter, and though it’s less powerful, you can’t beat the price and turnaround time. I’m still experimenting with materials, but have purchased a bunch of stuff from laserbits.com that I hope will produce good results.

Raspberry Foray

I’ve spent a lot of time playing around with Arduino, and the experience has taught me a lot. But if you want to connect to the internet — and look at you, of course you do — you’re going to want to turn elsewhere. I spent quite a bit of time on the BeagleBone, and I admire its commitment to openness.

But there is no competing with Raspberry Pi right now. It wins on price. It wins on its choice of native distro. Most importantly, it wins on community. Next to these things, its just-OK (nongraphical) technical capabilities are afterthoughts.

Still, making the damn thing useful in embedded applications takes some thought! I have condensed a number of these lessons into this repo. You might want to borrow parts of it (you probably won’t want all of it). Among the things the bootstrap.sh script and its siblings accomplish:

• Installs Bonjour so you can get to the Pi without looking up its DHCP-delivered IP address
• Gets a decent Python environment in place, complete with virtualenv
• Installs the wiringpi and wiringpi2 libraries, which are what you’ll want to use to control the General Purpose Input/Ouput (GPIO) pins on the device
• Sets up my default wifi networks. Whoops! You probably don’t want that. But use this /etc/network/interfaces and /etc/wpa_supplicant/wpa_supplicant.conf file templates to get yourself online. Note that you can have more than one network={} statements in the latter.
• Gives my SSH key root on the system. You probably don’t want that either.
• Turns off the swap file. Swap files are the means by which your disk impersonates RAM to expand your system’s capabilities. It’s a super-neat idea in general, but less so if your disk self-destructs the more often you write to it — which is indeed the case with a flash SD card. You should find a way to make do with physical memory. I’ve gone through a lot of SD cards.
• Relatedly! And not present in this install script! You should turn off journaling in the filesystem. Instructions can be found here. Journaling is a neat idea by which every change to the filesystem is first cached in a central location before being executed as a transaction. This allows for graceful recovery from a number of failure modes that can occur if an operation that requires multiple steps — and which really, really needs to complete all of them for things to make sense — is abruptly interrupted by a power loss or other failure. But that caching requires a ton of writes to disk, and will burn up your SD card in short order. You’ll just have to get by without journaling, and commit to pulling the power as little as possible
• The script also turns on the watchdog module in the Broadcom processor that lives at the heart of the Pi. This is a little piece of hardware that listens for a heartbeat signal from the system and, if it doesn’t hear one, reboots everything. Step one is turning on the hardware; step two is setting up the heartbeat. This can give your system a gentle kick when something you’ve done screws it up.
• Want to install a Python script in your virtualenv as a system service that starts at boot? I’ve made that fairly simple, though the script does bake in a few assumptions about your directory structure.
• Optionally, this script will help you set up outbound mail via your Gmail account
• Finally, there’s a script to install an ARM processor-compatible version of PhantomJS. More on that in a sec.

Some things are best done once, however. For a long time I installed whatever the latest Raspbian image was, then went through the raspi-config script (which launches automatically on the first boot) and then ran my bootstrap script.

This takes forever, though. I got particularly sick of reconfiguring raspi-config to expect a non-UK keyboard.

But creating a new and improved disk image eluded me for a while. Installing all the aforementioned junk requires that you expand the filesystem to use more of the SD card (the default uses only 2GB). But if you use the dd tool to image the result, it’ll show the full size of the SD card. And an image of one 4GB SD card (for instance) won’t necessarily fit on a different model or brand of 4GB SD card. (You should be using 8+GB cards anyway, to minimize system failures due to repeated writes to the same sector.)

The solution: expand the filesystem manually to 3GB or so. Use raspi-config to assert your American independence. Get everything set up. And then record an image using something like this:

sudo dd if=/dev/disk1 of=preconfigured_raspberry_pi.img bs=1048576 count=3000

This instructs dd to copy from /dev/disk1 in 1 megabyte chunks, and to pull three thousand of them. The remaining five thousand or so (on an 8GB card) can simply be ignored, I think? Honestly, it’s a bit difficult to keep track of which levels of filesystem abstraction and definition are included where. Perhaps those missing five thousand megabytes will come back to haunt me someday. But not yet.

Somehow the Vital Connection is Made

All of the above gets us a wooden box and a cheap and useful Linux environment. How do we make it actually translate Things On The Internet into a dial moving… somewhere?

Well, first you’ll need a wifi adapter. I tend to buy this one, which is tiny, less than ten dollars, compatible with the Raspberry Pi default distro without any additional drivers, and can mostly connect to wifi networks without exceeding the Pi’s rather wussy USB power capabilities. But there are other perfectly fine choices out there.

Getting wifi working on Linux is awful under the best of circumstances, but when done without a GUI it easily competes with the most imaginative punishments Greek mythology can offer. Please, please use the /etc/network/interfaces and wpa_supplicant.conf patterns linked above. For me, they’re the culmination of more than a year’s worth of trial and error across multiple embedded systems (next time you see me, ask to see my FUCK CONNMAN tattoo). Others will have wisely gone straight to LadyAda’s excellent series of Raspberry Pi lessons, from which this solution is cribbed.

But wifi connectivity is only the beginning.

A Ghost Is Born

Fantasy football is one of those strange areas of human endeavor in which Yahoo is successful. It’s free and it’s what my friends and I use, anyway. And it’s comforting to begin to know the annual rhythms: unnecessary redesign, mobile app flakiness, disastrous week 1 server outage, ensuing apology, eventual system stability. I look forward to repeating the cycle next year.

Alas, the API seems basically useless for anything beyond establishing that Yahoo runs a fantasy football service. So we’re going to be screen-scraping, navigating and disassembling messy HTML pages in just the same way that your browser does.

This is not a reliable process. Worse still, Yahoo counts on tons of Javascript to render portions of the page after the initial HTML has been delivered. Knowing what is supposed to happen after that point requires a Javascript interpreter, which is a sophisticated piece of machinery beyond most scripting environments. Instead, you have to connect your script to a browser and ask it, intermittently and politely, what the hell is going on right now.

This task used to be so hellaciously finicky that I’d never gotten it to work. But Phantom.js has removed most of those difficulties, and as I mentioned above, there’s a compiled version for Raspberry Pi which can simply be copied onto the device and used. I employed the Selenium Webdriver interface, but mostly because of peer pressure. I’ve been hearing good things about Casper.js.

Yahoo ensures that this will not be the end of your woes, but I’ve encoded a number of hard-fought lessons in this Python class, and will probably update it once the 2014 season redesign arrives and breaks everything. (The rest of the code for the meter is here, incidentally.)

Moving the Needle

The last piece of the puzzle: making the damn needles move. Most of the excitement is already recorded in this post. But in short: microcontrollers are all-or-nothing beasts, setting output pins to zero volts or ALL THE VOLTS (3.3 in the case of the Pi). But they can approximate intermediate values by turning a pin on and off very rapidly, with the ratio of on:off determining the voltage that’s being approximated. This is called pulse width modulation, and the Pi has built-in hardware that allows it to deal with this constant switching without expending any brainpower — but only on one pin.

Luckily, the wiringpi library has included as sophisticated a system for additional, software-controlled pins as one could hope for, though each additional pin comes at the cost of a bit more CPU utilization. Fortunately we only need two for this meter (the -100 to +100 meter is actually set up to behave as if it’s two separate meters).

The vintage gauges themselves are not configured for 3.3v, of course. But that’s where trim potentiometers come in:

Those little blue and white dials labeled 1, 5 and 6 are the trim pots in question. Some trial and error can deliver resistor levels that max out the meter’s range without overpowering it. The gauge’s response might still not be perfectly linear, but that’s where this little library comes in.

Wrapping Up

All that’s left is to add a little flair:

Ben will get a plaque now, too. I guess.

Yesterday Tim Lee and Ashkan Soltani reported a surprising and alarming revelation: some webcams can be activated without their accompanying light being turned on. This means it’s conceivable that criminals or government agents could compromise your computer and take surreptitious pictures of you. It’s a frightening prospect.

It’s also one that I had more or less deemed impossible based on what I know about electrical engineering. I owe Tim and Ashkan my thanks for teaching me something new.

But I think it’s worth delving into exactly what makes this attack possible. The paper their story focuses on concerns one particular attack on one particular type of webcam. Left unanswered is whether vulnerabilities like this one are commonplace. Examining how this attack works can provide some reassurance about engineers’ good intentions, but leaves plenty of reasons to worry about their insufficiency.

You can find the paper detailing the attack here (thanks, guan!).

Before we walk through how the attack works, let’s establish our cast of characters — one that’s slightly simplified relative to the specifics of this attack, but which will suffice for our purposes.

First, there’s your computer. It looks like a computer, and behaves in a computerlike fashion.

Second, there’s the webcam microcontroller. This is also a computer! But it’s a much tinier, lousier computer — one that fits on a single microchip. Still, it can run programs, and it can talk to your computer. And we’re not going to ask it to do very much: mostly it’s just supposed to manage the other components in the webcam and report their outputs back to the computer when asked.

Third, there’s the image sensor. It’s digital and electronic, certainly, and it even speaks binary code and executes commands, but it doesn’t run arbitrary programs. It does have internal states and settings, though — it’s not a completely passive, memoryless device like a lightbulb or motor.

Here’s the key diagram from the paper:

On the bottom is the microcontroller. On the top is the image sensor. There is a connection between the two of them labeled “standby”. When operating normally, the image sensor will go into standby mode whenever the microcontroller sends a voltage to this connection.

On the right side of the diagram is the LED. Its input side is connected directly to the system’s power source (V_cc), and its output side is connected to the “standby” line. A circuit can only do work when energy flows through it, so when both sides of the LED are set to the same voltage — when the standby line is “high” — no current will flow and the LED will remain dark. When the voltage on this connection is low, the image sensor will emerge from standby mode; current will flow from V_cc, through the LED and out the “standby” line; and light will be generated.

This is a pretty good system! The LED’s function is tied directly to something that enables or disables the image sensor. This arrangement can’t be undone without cutting wires. Really, that “standby” line looks a lot like a power switch.

But it isn’t. The image sensor was designed to be a flexible component that might be used in many different configurations, not just the iSight. This is the norm in electronics, with a few exceptions like the custom chips that Apple designs for its iPhones. In this case, the image sensor can be configured in different ways by sending it different setup commands from the microcontroller. One can imagine modes for “low light” or “video” or “grayscale”, but there are also numerous esoteric settings that are only useful to engineers. In the case of this particular image sensor, it’s possible to tell it to ignore any signals it sees on its “standby” pin.

This probably sounds pretty outrageous, but it’s not hard to imagine configurations in which this capability could be useful. When prototyping a circuit, minimizing the number of features and connections that must be used can make the process faster and simpler. In some applications the image sensor might be on all the time, making a usable “standby” line irrelevant (or, if not properly grounded and shielded, even a source of buggy behavior).

Alternately, it might seem outrageous that the engineer designing the webcam system overlooked this capability in the image sensor. This is a stronger argument. But this is an easy mistake to make.

Here’s the datasheet for the image sensor. At 61 pages it’s not especially long (microprocessor datasheets can be thousands of pages), but I think you’ll agree that it’s not the easiest thing to read. What you probably can’t see is that datasheets are often riddled with errors. They are usually written by engineers, which produces a terrible product but is better than the alternative. As you might imagine, the result is more or less impervious to editing and verification by humans. Datasheets for very popular or venerable chips can be very good, but for complicated, new or little-used products, they can contain serious problems. Partially for this reason, datasheets often contain information about “reference implementations”: partially or wholly built systems that show how the component is supposed to be used with a minimum of complicating details, and which engineers are implicitly encouraged to follow without question.

None of this excuses the webcam engineer’s failure to foresee this security hole. But you can imagine how it happened. Having someone manipulate this completely undocumented hardware system, reprogramming a microcontroller to, in turn, reprogram an image sensor to use a counterintuitive operational mode that (for all I know) might be completely idiosyncratic to this image sensor chip? It’s tough to get too angry over someone’s decision to spend their time on other problems.

Is this comforting? Sort of. It’s an awfully specific vulnerability. It’s pretty easy to see how to design around it (use the LED to test for power to the image sensor, not the state of its standby line; harden the microcontroller’s programming; the paper’s authors discuss a number of possible remedies and the occasional tradeoffs they entail). It’s clear that the engineer was trying to tie the LED’s activity as closely and irrevocably to the image sensor’s operation as he could, which is the right idea. We have no specific reason to think that similar bugs are present in other webcams that use different chips or have more careful authors.

Still. This is a reminder that the systems we use are wildly complex, executing code in many more places than just the CPU. And it’s increasingly clear that many of those places have never been scrutinized for vulnerabilities. It’s cheering to see security researchers uncover these problems, but criminals and governments have vastly greater resources and incentives to pursue this work, and have had plenty of time to do so. Some masking tape might not be a bad idea.

I often find myself defending Sam Biddle’s brand of Silicon Valley nihilism to Matt, so I’m sort of surprised to see us switching sides: today Matt joins Sam in deriding President Obama’s calls to teach schoolkids to program. He’s not alone! I think Matt’s specific objection doesn’t get us very far — some students’ failure to attain basic skills doesn’t really tell us all that much about what should be included in a general curriculum, just as the continued existence of murder doesn’t tell us much about the wisdom of enforcing speed limits.

But it is worth spelling out the case for teaching people to code. It’s not because we expect them to become programmers. We don’t expect every student in English class to write a novel or every student in Trigonometry to wind up manipulating triangles for a living. We certainly don’t expect every kid in music or art class to carry those skills beyond the classroom, or even to achieve proficiency within it.

Rather, we teach those skills because they are varyingly enriching and instructive windows onto reality and culture. They help kids navigate the world. In a few cases they’ll wind up being of practical value or make for a fulfilling hobby. But mostly they’re about building competent and intelligent human beings.

Coding qualifies. I still distinctly remember programming my grandparents’ VCR for them — a cliche of childhood technical affinity, yes. But also an instructive experience! Why was the schedule set with a 24-hour clock scheme? Why were the on-screen fonts the same across different brands of VCR? What the heck was the difference between SP, LP and SLP? The answers involve the nature of modulo arithmetic, the electronic industry supply chain and electrical engineering practices, and some pretty fundamental concepts from information theory. Some of these revealed themselves quickly; others came decades later. Gaining that simple, unimportant technical skill gave me a window into how engineers’ minds work and how the constraints imposed by physical reality shape the systems they build.

Without realizing it, the simple daily use of technology imparts lessons about data normalization, computability and signal processing. Stitching these hunches together with a light classroom introduction to the procedural nature of Turing-style computation is not a bad idea. It’s also not a trivial idea — some people think this perspective has enough explanatory power to describe the entire universe.

Nor is it of merely intellectual interest (though I’ll happily admit that I do find it deeply intellectually rewarding). In the same way that the economic perspective has largely triumphed over other dialectic forms in our culture, our physical environments grow ever more engineered. And engineering grows ever more digital in nature. Understanding how those processes work at a fundamental level is an increasingly necessary precondition to deciphering our deeply unnatural world.

Do you want to be able to quickly use a new product? Or organize a spreadsheet so that it will be useful later on? Do you want to know why your partner missed that SMS, or why the football broadcast looks blocky? Do you want to know what to fear, and when you’re being lied to, and how?

Learning to code “hello world” won’t guarantee you those answers any more than it’ll guarantee you a job at Facebook. But it isn’t a bad place to start.

Broadcast sports is finally, finally embracing the digital age. My Apple TV has separate apps for the NHL, NBA and MLB, for instance. Sadly, these are still subject to blackout restrictions, preventing me from being able to purchase Capitals games. Irritating!

As it happens, I have a pay-as-you-go account with IPredator, a Swedish VPN service. For a few bucks a month, they provide the ability to use a high-bandwidth encrypted link that terminates your internet traffic in Sweden. I mostly use this for Bittorrent (though pretty rarely, believe it or not). But I figured it might let me get around blackout rules, too.

Unfortunately, the Apple TV isn’t able to use VPN software. So we need something to handle that operation instead, making the Apple TV think that it’s on a perfectly normal network — albeit one in Sweden.

This had been on my to-do list for a while, but I finally got around to tackling it today. The results are pretty good! Sadly, it appears that hockey-crazy Sweden has blackout rules of its own — presumably the NHL has a distribution deal with some broadcaster there that makes it necessary to confound people like myself who want to pay to watch hockey but don’t care to pay for a complete cable TV package. Bah.

But the system is working — a laptop substituted for the Apple TV is convinced it’s sitting in Stockholm, and my Apple TV Netflix experience is substantially different (title availability is wildly altered). And the NBA League Pass stuff looks like it might be working fine (I don’t have an account, but will be bugging Matt to try his out shortly).

So I’ll go ahead and record what I did here before I forget it. Perhaps before too long I’ll switch to a VPN that terminates in a (non-Washington) US city and see if that doesn’t solve my problems.

1. Buy a Raspberry Pi Model B (the one with the on-board ethernet jack). Get the basic Raspbian distro up and running.
2. Add a USB ethernet adapter — one with Linux support. Note that I haven’t tried the one at that link, but it claims to be Linux-friendly. I’ve been using an overpriced Apple adapter.
3. The USB ethernet port is eth1, and will be what you plug your Apple TV/whatever into. The on-board Raspberry Pi ethernet port is eth0, and should be connected to your router.
4. Follow LadyAda’s instructions for making your Raspberry Pi into a wifi access point — except skip everything that has to do with hostapd or iptables. Also, replace references to “wlan0″ with “eth1″. After rebooting, you should now be able to plug a computer into the USB adapter via ethernet and receive an IP address that begins with 192.168.42. If you can’t, something is wrong.
5. Configure OpenVPN for IPredator using their Debian setup instructions. When running, this creates a virtual network adapter called tun0 — it’s quite similar to eth0 or eth1 (the ethernet cards) except it’s a software abstraction. Also, configure this to start up automatically — the IPredator instructions gloss over this. It shouldn’t take more than a “sudo update-rc.d openvpn enable”.
6. Use the following iptables configuration to make the Raspberry Pi act as a router that sends incoming traffic to tun0:
   

   # Generated by iptables-save v1.4.14 on Sun Dec 1 13:49:10 2013
   *nat
   :PREROUTING ACCEPT [329:25039]
   :INPUT ACCEPT [194:13371]
   :OUTPUT ACCEPT [0:0]
   :POSTROUTING ACCEPT [0:0]
   -A POSTROUTING -o tun0 -j MASQUERADE
   COMMIT
   # Completed on Sun Dec 1 13:49:10 2013
   # Generated by iptables-save v1.4.14 on Sun Dec 1 13:49:10 2013
   *filter
   :INPUT ACCEPT [1384:725715]
   :FORWARD ACCEPT [877:601931]
   :OUTPUT ACCEPT [1102:200985]
   -A FORWARD -i eth1 -j ACCEPT
   COMMIT
   # Completed on Sun Dec 1 13:49:10 2013

   You can grab the gist here. Save this into /etc/iptables.up.rules then create a file called /etc/network/if-pre-up.d/iptables that contains the following:

   #!/bin/bash
   /sbin/iptables-restore < /etc/iptables.up.rules

   Give it a good “sudo chmod +x /etc/network/if-pre-up.d/iptables” to make it executable and, if all has gone well, you’re done! You now have a Raspberry Pi that lets network traffic go in one end and emerge in Sweden. Kinda neat.