Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

The hacker has picked up a random IoT alarm from China. In parts 1 and 2, they dumped the firmware and figured out how it works. In this post, they decided to go through the reverse engineering of the radio wireless and how it communicates with the smart hub.

To start with, they identified the chip being used but couldn't find a datasheet (sad). To find the frequency of the device, mention the hackrf_sweep tool that comes from the HackRF SDR. Instead, they just looked at common frequency ranges in the graphical spectrogram GQRX. After doing this, they found the frequency of the alarm to be at 434MHz.

Once they had detected the frequency, they could do some further analysis. They chose to use Universal Radio Hacker (URH) to record the signal. The remote for the alarm has four buttons, where they take a recording of all of them. For each button, they repeat the capturing three times in order to analyze if the signal staus the same between runs.

When looking at the recording in URH, there are short blips of signals then breaks. Because of this, the data is likely encoded using Amplitude Modulation (AM). Zooming in on the signal shows no change in frequency or phase either. More specifically, On-Off-Keying (OOK). Simply but, if we want to send a 0, then don't off the transmitter (no signal). If we want to send a 1, then turn on the transmitter.

From analyzing the binary output of the signal with OOK, the authors determined a few things. First, all of the groups of captures are the same, such as unlock. Second, there are quite a few anomalous outputs. They determined this occurred because of the tool not understanding the difference between a break in transmission and zero, as well as the button being released part way through a transmission. After cleaning this up, there appears to be 97 bits of data. Interesting!

Figuring out the encoding can be tricky. Although OOK is used, a digital bit is commonly put into several bits of transmission. For instance, 4 bits may represent a single real digital bit being transmitted. In the case of the remote, they divided up the groups in several ways until something looked like a pattern. When dividing the data into groups of 4 and removing the first bit, they were left with only two patterns of 4 bit groups: 1110 and 1000.

Since the groups of 1110 and 1000 were likely not a coincidence, this must be how the data is encoded. Compared to the unlock and lock codes, only the last 8 bits were ever different. While doing research on common encoding algorithms for wireless, they came across the EV1527 protocol which showed exactly what the analysis mentioned above. Neat!

In terms of security, this wireless device is a joke. It is trivially vulnerable to spoofing and replay attacks, since there is no authentication on the device. Additionally, jamming could be done to prevent the alarm from working.

The one tricky part is that the first 20 bits are a remote control identification number. Although an eavesdropper can learn this and use it, a first time walk up is hard. Theoretically, an attacker can attempt to brute force this but it is likely too large of a space to work.

The authors of the post really went hard on recreating this with URH. By setting up the protocol, it is possible for it to recreate arbitrary signals that you have not seen before. For instance, you could modify a lock code to be an unlock code. Additionally, they fuzzed the other commands (16 possible command bits) to no avail.

Overall, interesting post going into their methodology for wireless signal reverse engineering. The groups use of URH is awesome as well, as I usually recreate stuff in GNU radio instead of URH.