Thread by @InfoSecDJ

Alright, you wanted me to do it, so here goes.
A real quick and dirty tutorial on how to use #Universal #Radio #Hacker or #URH to do something useful.

You can find the tool here: github.com/jopohl/urh
It's a bit flaky at times, but it appears to support capture and replay on most hardware out in the field today, which is GREAT

The tool comes in useful when you're confronted with a radio link and want to find out the details (modulation, bitrate, etc) when those aren't made public by the manufacturer. It's also handy when you just have a signal and no device in hand.

In my area, we have quite a lot of activity in the "IoT" bands. Here's what goes on around 433.925MHz. Remember energy at a particular freq is plotted horizontally while time flows (falls?) vertically.

Quite a few blips of energy there! But what do they mean? Who knows!
This is what URH may help us to investigate.

First and foremost, you can record right from URH, very handy. Lots of knobs to twiddle! They also provided a button to start over if the signal you wanted was not recorded for whatever reason -- most of them come at intervals.
Signal power is shown live when recording.

With any luck, you got your signal saved on your disk. It also gets added for the analysis -- this is what it looked like for me, about a minute of noise and blips. The tool tries to guesstimate the noise level for you (in red) but this often needs adjustment.

That's more like it. Most of noise is within the red while signal blips stick outside.
The noise level influences what the software takes as "signal" -- if the level is above, then it's processed. Which is exactly what we want.

As I have NO CLUE whatsoever as to what I'll be looking at, I just picked the thickest blip, which is probably the lowest bit rate too. Let's zoom in on that one.

Clearly, this is composed of three distinct elements: short pulse, long pulse, and a pause. So maybe this is a simple modulation scheme like on-off keying (OOK)? But it's a tad hard on the eyes, let's tweak things a bit.

Setting modulation to ASK (here same as OOK) and switching the signal view from "analog" to "demodulated" we get this image. The pattern is a bit more distinct; this view also shows that would be taken as 1 and 0 with color and this is adjustable.

Conveniently enough, you can also zoom in more and measure the features via click-and-drag selection method; selection is highlighted. The program reports how many samples got selected as well as converting that into a time interval.

After extremely precise measurement, I got the short pulse of 487us, the long pulse of 1463us, and the pause of 982us!
Completely useless at this point, but if the short pulse is 1 unit long, then the long pulse is 3 units and the pause is 2 units. Not random at all.

Setting the "samples/symbol" to our measures 487us and enabling the "show signal" thing, we get the "bits!" 1001001001001001001001110010011100111...

Of course, they are not real bits. At least, it's not what the device probably thinks it transmits. Why's that? Because there is too much redundancy. More likely than not, the device actually encodes a "0" as a short pulse + pause, and a "1" as a long pulse + pause.

But you can work around that using the analysis features the software provides! Specifically, decoding -- it is quite configurable. Switching to the "analysis" tab, here are our ASK messages (there are two identical copies)

You can configure the decoding via Edit -> Decoding menu and dialog box, and then apply the custom decoding via the "decoding" drop-down in the tab (where is says Non Return To Zero now).
Rummaging in the options, the "morse" base function fits well. Add it and test:

Oh wow, it did replace 100 with 0 and 11100 with 1, as expected! There is a chance it will actually work. Remember to "save as" your new decoding method and then apply:

Boom! Done. We figured out how to go from noise in the air to ones and zeros. We can go ahead and collect a few hundred of these and see if we can figure out what the bits mean! Maybe. Possibly.