Software Defined Everything With Mike Ossmann And Kate Temkin

Software defined radio has become a staple of the RF tinkerer, but it’s likely that very few of us have ever taken their software defined toolchain outside the bounds of radio. It’s an area explored by Mike Ossmann and Kate Temkin in their newly published Supercon talk as they use GNU Radio to do some things that you might find unexpected.

For most people, a software defined radio is a device. An RTL-SDR dongle perhaps, or the HackRF that a popular multi-tool for working in the radio frequency realm. But as they explain, the SDR hardware can be considered merely as the analogue front end, being just the minimal analogue circuitry coupled with a digitiser. The real software-defined part comes — as you might expect — in the software

Kate and Mike introduce GNU Radio Companion — the graphical UI for GNU Radio — as their tool of choice and praise it’s use as a general purpose digital signal processing system whether or not that includes radio. Taking their own Great Scott Gadgets GreatFET One USB hackers toolkit peripheral as an input device they demonstrate this by analysing the output from a light sensor. Instantly they can analyse the mains frequency in a frequency-domain plot, and the pulse frequency of the LEDs. But their bag of tricks goes much deeper, exploring multiple “atypical use cases” that unlock a whole new world through creative digital signal processing (DSP).

Continue reading “Software Defined Everything With Mike Ossmann And Kate Temkin”

Michael Ossmann Pulls DSSS Out Of Nowhere

[Michael Ossmann] spoke on Friday to a packed house in the wireless hacking village at DEF CON 25. There’s still a day and a half of talks remaining but it will be hard for anything to unseat his Reverse Engineering Direct Sequence Spread Spectrum (DSSS) talk as my favorite of the con.

DSSS is a technique used to transmit reliable data where low signal strength and high noise are likely. It’s used in GPS communications where the signal received from a satellite is often far too small for you to detect visually on a waterfall display. Yet we know that data is being received and decoded by every cell phone on the planet. It is also used for WiFi management packets, ZigBee, and found in proprietary systems especially any dealing with satellite communications.

[Michael] really pulled a rabbit out of a hat with his demos which detected the DSSS signal parameters in what appeared to be nothing but noise. You can see below the signal with and without noise; the latter is completely indiscernible as a signal at all to the eye, but can be detected using his techniques.

Detecting DSSS with Simple Math

[Michael] mentioned simple math tricks, and he wasn’t kidding. It’s easy to assume that someone as experienced in RF as he would have a different definition of ‘simple’ than we would. But truly, he’s using multiplication and subtraction to do an awful lot.

DSSS transmits binary values as a set called a chip. The chip for digital 1 might be 11100010010 with the digital 0 being the inverse of that. You can see this in the slide at the top of this article. Normal DSSS decoding compares the signal to expected values, using a correlation algorithm that multiplies the two and gives a score. If the score is high enough, 11 in this example, then a bit has been detected.

To reverse engineer this it is necessary to center on the correct frequency and then detect the chip encoding. GNU radio is the tool of choice for processing a DSSS capture from a SPOT Connect module designed to push simple messages to a satellite communication network. The first math trick is to multiply the signal by itself and then look at spectrum analysis to see if there is a noticeable spike indicating the center of the frequency. This can then be adjusted with an offset and smaller spikes on either side will be observed.

When visualized in a constellation view you begin to observe a center and two opposite clusters. The next math trick is to square the signal (multiply it by itself) and it will join those opposite clusters onto one side. What this accomplishes is a strong periodic component (the cycle from the center to the cluster and back again) which reveals the chip rate.

Detecting symbols within the chip is another math trick. Subtract each successive value in the signal from the last and you will mostly end up with zero (high signal minus high signal is zero, etc). But every time the signal spikes you’re looking at a transition point and the visualization begins to look like logic traced out on an oscilloscope. This technique can deal with small amounts of noise but becomes more robust with a bit of filtering.

This sort of exploration of the signal is both fun and interesting. But if you want to actually get some work done you need a tool. [Michael] built his own in the form of a python script that cobbles up a .cfile and spits out the frequency offset, chip rate, chip sequence length, and decoded chip sequence.

Running his sample file through with increasing levels of noise added, the script was rock solid on detecting the parameters of the signal. Interestingly, it is even measuring the 3 parts per million difference between the transmitter and receiver clocks in the detected chip rate value. What isn’t rock solid is the actual bit information, which begins to degrade as the noise is increased. But just establishing the parameters of the protocol being used is the biggest part of the battle and this is a dependable solution for doing that quickly and automatically.

You can give the script a try. It is part of [Michael’s] Clock Recovery repo. This talk was recorded and you should add it to your reminder list for after the con when talks begin to be published. To hold you over until then, we suggest you take a look at his RF Design workshop from the 2015 Hackaday Superconference.

Michael Ossmann Makes You An RF Design Hero

To a lot of people, radio-frequency (RF) design is black magic. Even if you’ve built a number of RF projects, and worked your way through the low-lying gotchas, you’ve probably still got a healthy respect for the gremlins lying in wait around every dimly-lit corner. Well, [Michael Ossmann] gave a super workshop at the Hackaday Superconference to give you a guided tour of the better-illuminated spaces in RF design.

five_rules[Michael] is a hacker-designer, and his insights into RF circuit design are hard-won, by making stuff. The HackRF One is probably his most famous (and complex) project, but he’s also designed and built a number of simpler RF devices. And the main point of his talk is that there’s a large range of interesting projects that are possible without getting yourself into the fringes of RF design (which require expensive test equipment, serious modelling, or a Ph.D. in electro-wavey-things).

You should watch [Mike]’s workshop which is embedded below. That said, here’s the spoilers. [Mike] suggests five rules that’ll keep your RF design on the green, rather than off in the rough.

Continue reading “Michael Ossmann Makes You An RF Design Hero”

Pulling Data From The IM-ME Spectrum Analyzer

A small, cheap spectrum analyzer with an LCD can be a fun thing to play with. But to be truly usefully you need access to raw data, and lots of it. [Travis Goodspeed] set out to make that possible by pulling data with a GoodFET and a Python script.

He started with [Michael Ossmann’s] IM-ME spectrum analyzer, which uses a CC1110 chip. The two of them are giving a lecture at Toorcon 12 (called Real Men Carry Pink Pagers) and this will be used as a demonstration device. After studying the datasheet he found the starting RAM address and did some further work to deciphered how the data is stored in it. From there it was a matter of working out the timing for grabbing the data, and coding a method for storing it. Now he’s looking for brave souls to help him trailblaze with this newly-discovered tool. It seems that if you know what you are doing, and have abundant patience, you can use this for a bit of old-fashioned reverse engineering.