Meta: Apologies for the long delay in updating. The end of 2016 was a turbulent time for me (politics and world news excluded), so it made updates difficult. In spite that, here we are in 2017.
The end of 2016 saw me spending a great deal of time working on wireless communications protocols. Most of this turned out to be catching data over the air, modulated with OOK/ASK, some 2FSK, etc. These modulations are ever present in the world of non-WiFi/non-IP IoT devices. They're simple to implement. You need little processing power to receive or transmit. Above all that, modules that do the hard RF work are available everywhere.
Figuring out how a device works (and talks) is one part of the battle. It's easy to point to something and say 'FIX YOUR BROKEN PRODUCT!' and vendors will ignore you because they see no immediate threat. Many of these simple wireless devices operate at 433 MHz or 900 MHz. The devices are short-range by nature, so physical presence is necessary. Pre-made modules are plentiful, so FCC licensing becomes a cinch. You don't even need RF expertise in-house for many of these systems. That also means that expertise on how to fix these systems is short. So unless you prove there's a real threat, you'll find yourself ignored.
Wireless IoT Backgrounder
The simplest wireless devices are only capable of transmitting and receiving on one frequency. More complex devices might spread their transmissions across a 1MHz (or much smaller) chunk of the spectrum. This is well within the capabilities of inexpensive SDR to capture. An IoT device might carve this band up into channels, each a few kHz wide, and pick a channel to send on. More sophisticated devices will hop channels on each transition. This reduces the odds that devices will interfere with eachother. It also makes it a bit trickier to attack. But only a little bit.
Low-cost receive-only software defined radios (SDRs) like the RTL-SDR and Airspy make snooping easy. The entire spectrum from ~50 MHz all the way up to ~1750 MHz is open to amateur SIGINT enthusiasts. So how do you snoop on scale using these devices?
Making it Real
GNUradio provides an amazing platform on which to explore and prototype these things. But if you're looking to weaponize what you've learned, it's a clunky tool to use. I ran up against the limits of GNUradio while building a platform that implements my findings. This left me replacing chunks of GNUradio with my own components.
A desire to build this on top of a well-known and plentiful embedded ARM platform led to me building TSL-SDR. TSL-SDR is a GPL/MIT licensed library and applications that provide the DSP side of things for SDR reception. As-released, TSL-SDR supports only the RTL-SDR dongles, but support for Airspy and UHD/USRPs is incoming. Track its progress on Github.
Out of the box, TSL-SDR provides a simple FM channelizer. The example configurations show how you can receive all the FCC GC pager bands. You can write the output PCM waveforms to a file or a FIFO (for processing with multimon-ng, say). There's also a polyphase rational resampler, but this is due a whole blog post of its own.
Gory Technical Details
TSL-SDR is written in C. The filters (and receive chain) take advantage of NEON on ARM. All filtering code uses fixed-point arithmetic during processing. This gives TSL-SDR decent performance on limited-resource embedded systems.
To build the TSL-SDR, you will need to have Python installed. The build uses waf, which is pre-packaged with the source distribution. You'll also need libjansson, concurrency-kit and, of course, librtlsdr. Most distributions come with these packages pre-built.
TSL-SDR is somewhat rough around the edges, so consider it alpha-quality software. It's been running 24/7 since November for me for one of my applications, so it's up to the task. You might find certain configurations trigger bugs. If you're not up to the task of fixing it, create an issue on Github and I'll try tackling it when I get a chance.