Obscure Ethernet for $200 please, Alex: The Ethernet PAUSE frame

This is a bizarre one. It all started when the internet seemed to go out at my house. My desktop, phone, TV, everything stopped working. The usual solution at a time like this is to power cycle the modem and router. While this fixed the situation temporarily, soon after the problem returned. What made me think this was more than just ISP flakiness was that for some reason Chrome actually locked up; good ol’ Windows “this program stopped responding” so like any enterprising engineer I busted open Wireshark.

Continue reading “Obscure Ethernet for $200 please, Alex: The Ethernet PAUSE frame”

When code is suspiciously fast: adventures in dead code elimination

Part of a recent assignment for one of my classes involved calculating the Fibonacci sequence both recursively and iteratively and measuring the speed of each method. (BONUS: For a fun diversion, here is a paper I wrote about using the Golden Ratio, which is closely related to the Fibonacci sequence, as a base for a number system). In addition, we were supposed to pass the actual calculation as a function pointer argument to a method that measured the execution time.

The task was fairly straight forward, so I fired up Visual Studio 2015 and got to work. I usually target x64 during development (due to some misguided belief that the code will be faster), and when I ran the code in release mode I received the following output as the time needed to calculate the 42nd Fibonacci number:

Recursive: 0.977294758 seconds
Iterative: 0.000000310 seconds

Since calculating $F_{42}$ through naive recursion requires ~866 million function calls, this pretty much jived with my expectations. I was ready to submit the assignment and close up shop, but I decided it’d be safer to submit the executable as as 32-bit application. I switched over to x86 in Visual Studio, and for good measure ran the program again.

Recursive: 0.000000000 seconds
Iterative: 0.000000311 seconds

Continue reading “When code is suspiciously fast: adventures in dead code elimination”

CVE-2016-1562: Unauthenticated “filter” parameter leads to customer information leak in the DTE Energy Insight app


Here in southeast Michigan nearly all of our electricity (and a good chunk of our natural gas) comes from DTE Energy, which serves 2.1 million people in the greater Metro Detroit area. DTE recently upgraded most of their electricity meters to ZigBee-enabled smart meters, and as part of this rollout they released the DTE Energy Insight app which allows customers to view their energy usage, set targets, and earn a host of achievements (no Steam cards sadly) when meeting different energy goals. In addition, at no charge DTE sends customers an “Energy Bridge”, a small device that connects to a home network and monitors the ZigBee messages generated by a smart meter to give real-time energy consumption information.

The DTE Energy Insight app and the Energy Bridge device

Given my curious nature I decided to poke around to discover how exactly the app and the Energy Bridge worked. This post is about a vulnerability in the app itself (although I’ve been tinkering with my Ettus Research B200 SDR to intercept the ZigBee messages as well).

Continue reading “CVE-2016-1562: Unauthenticated “filter” parameter leads to customer information leak in the DTE Energy Insight app”

Introducing MissionControl

A few months back I purchased a Parrot Bepop drone and started writing some code to actually fly it from my PC (being unhappy with only Android/iOS options). In particular I wanted a system that would let my fly it with my shiny new X-55 Rhino HOTAS I got for Star Citizen and Elite: Dangerous. Unfortunately my Bepop drone was stolen, so I’m releasing the code for what I call “MissionControl” a bit prematurely. You can connect and fly your Bepop drone with this, although there is no UI to configure the controls yet. If I get another drone at some point I may pick this back up but I wanted to release what I had because it didn’t seem like anyone had gotten flight control of a Bepop working on Win32 yet.

It’s up on github: MissionControl.

Penguicon 2015: Scheduling

I’ll be at Penguicon this weekend, Michigan’s largest sci-fi/open source convention! I’ll be giving a talk about my upcoming research paper “Scheduling a conference to minimize RSVP conflicts” which is currently undergoing peer review.

Here are the slides for my talk: Scheduling: The first academic paper about Penguicon

A pre-print of the actual paper: Scheduling a conference to minimize RSVPs

Automotive Ethernet: The Definitive Guide

ETHERNET-GUIDE-2I’m excited to announce my first real published work! Automotive Ethernet: The Definitive Guide is a comprehensive guide to the developing world of Automotive Ethernet. For the past twenty years most automotive networking has relied on CAN bus to move information around the car. CAN is quickly outgrowing it’s usefulness though, and the industry is now shifting to using Ethernet. I wrote this book along with several others at my company, and it will be available on October 20th, 2014 as an eBook from Amazon, and the physical version will be available soon after. Enjoy!


Using emscripten/WebGL to run a Nintendo 64 emulator at full speed in most games with Firefox

I recently spent some time learning emscripten, the LLVM-to-Javascript compiler and decided that porting mupen64plus, the popular Nintendo 64 emulator, would be a good test of its features. Took a bit to get right, but you can checkout the code and a working demo of it here: http://jquesnelle.github.io/mupen64plus-ui-console/ (Requires Firefox unfortunately for now)

Setting up a man-in-the-middle device with Raspberry Pi, Part 1

I recently purchased that most marvelous of devices the Raspberry Pi and naturally my thoughts turned to the nefarious given its cheap price and small package. I decided to attempt to create a man-in-the-middle device that could be discreetly attached to a remote network and could redirect and sniff traffic. I’m only a very novice Linux user so it took a bit of learning to wrangle man pages as well as some intrepid Google-fu, but I’m going to document how I was able to turn this tiny device into an evil packet-sniffing machine. Continue reading “Setting up a man-in-the-middle device with Raspberry Pi, Part 1”

A word on multithreading

A lot of people have asked why nds4droid only takes 50% of their CPU on quad core devices. The reason is generally straightforward: nds4droid has two main threads, one that does the actual emulation and one that does all drawing/compositing/input processing. The actual “main” emulation thread is bottleneck and why the emulator can be slow; we’re only doing the “heavy lifting” using one core. When emulating the DS we have to emulate the CPU instruction per instruction, and doing this on several threads is an extremely complicated (if not an impossible proposition). However, there is some low hanging fruit for parallelization: the DS actually is made up of 2 CPUS, the main ARM9 as well as an auxiliary ARM7 (the same CPU as in the GBA, this is how backwards compatibility was achieved). The ARM7 does sound processing and some 2D graphics work. Currently on the main thread we emulate a few ARM9 instructions, then a few ARM7, and back and forth. In theory we could emulate each of these CPUs on their own thread, giving more time on the main thread for the ARM9 emulation which is our current bottleneck. The problem is that these threads still require lots of synchronization; we often have to “halt” the instruction emulation to process the rest of the DS machinery (graphics, interrupts, etc). I have code that does this, the problem is that my synchronization mechanism is too slow… we lose more than we gain.

In my experiments, I spawn a new thread for each CPU. These then sit in a “wait state”, waiting to be told to emulate instructions. They’re then signaled to execute, and then halt again when they detect some other work needs to be done (usually about 6-12 instructions are emulated before we need to halt again). The problem is that my signaling mechanism is too slow: I’ve tried the standard model of pthread mutexes, but these are way too slow. From my understanding pthread mutexes involve kernel syscalls, and yield the thread timeslice (which is way too long, we need to execute again quickly). Spinlocks are also very slow (although I suppose I’m not 100% sure why). If anyone knows of/can suggest some better thread synchronization models, or maybe some libraries that do intelligent user mode synchronization it’d be greatly appreciated!

snes4nacl — SNES emulation in the browser

I was at Google I/O in San Francisco last week and went to a great talk about Google Native Client, which is a new technology that allows direct execution of x86 code in the browser via some clever sandboxing. While in the talk about Gaming in the Cloud I got the idea of porting a SNES emulator to Native Client and started working on it right then and there. Well, here’s the result 🙂

Continue reading “snes4nacl — SNES emulation in the browser”