One of the key understandings of growing up is beginning to appreciate the difference between “should” and “do”. We should eat a balanced diet full of green leafy vegetables, but life happens, and ice cream tastes really good.
As engineers and software developers … same thing, different day. We should write good data and protocol definitions, evaluate them for correctness, and continuously monitor and update them over time. But we don’t. Because life happens.
In the world of pure software, maybe this isn’t a big problem. We can replace our broken XML serializer with a JSON serializer, and maybe no one notices. But in the world of cyber-physical systems, we have bigger issues. That CAT scanner, or that radar system, is a combination of software and hardware that’s been certified (in its exact configuration!) for use in safety-critical systems. Throwing it away and starting over is expensive. At the same time, keeping a Windows 3.11 (for Workgroups!) machine running on eBay-scrounged hardware, just so that we can run the original interface software … well, that also isn’t a great life. But the company that made the thing went out of business, and the specifications were lost in the fire sale, so … what can we do?
Well, I’m glad you asked.
We often ask companies for the specifications of their protocols when we verify their critical systems. We then run into a variety of reasons why those specifications aren’t available. Most often, this is due to a piece of the system that was built by a third party who is now out of business, but we’ve heard some great stories. (So far: flood and fire, but not famine.) As a result, we have been working with researchers at Tufts University to investigate ways to recover the specifications, quickly and correctly.
The demo above gives you a quick outline of that task. We use a suite of tools to reverse engineer a protocol based on example data captured from real data streams. These tools can help you quickly visualize common patterns in the data, and find interesting common pieces of protocols: checksums, type/length/value or length/value sections, sequence numbers or timestamps, etc.
Our plan is to keep expanding our set of detectors as we go, to identify interesting semantic values as well. A couple of examples “this is a float that (based on the values observed) appears to be in radians,” or “this is one of several common serialization formats for latitude.”
This effort is part of a larger model recovery, verification, and digital engineering effort at Galois. The truth is that there aren’t good models, specifications, or requirements for many existing systems in the world. This is a significant limiting factor in our ability to formally verify critical systems, or even do good resilience reviews. Furthermore, reverse engineering these things by hand is difficult, expensive, and error prone.
So, through a variety of projects, including this one, we are looking to leverage our and our partners’ expertise to help accelerate this process. This will make it easier and cheaper for all of us to know what the heck is actually going on with our systems.
Well, and to mess with botnets. Obviously.
Now if we could just get it to help us eat more leafy greens at dinner…