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!

This post starts with a device that the author wants to hack: a wireless weather station and a temperature sensor. They knew it was using some custom protocol to communicate the temperature to the base station but did not know how.

The author had an RTL-SDR and an Adalm-Pluto. The Adalm-Pluto is Analog Devices (the company) branded education level SDR. This SDR has a 20MHz bandwidth, 12-bit ADC & DAC, full duplex, Gnu radio blocks and a range from 325MHz-3.8Ghz. These and the tool Universal Radio hacker (URH) were great starting points for this project.

The device itself had a carrier frequency labeled on it at 915MHz. When going to this on a spectrum analyzing, there were two peaks. Two distinct peaks indicates binary (0,1) frequency shift keying (FSK) in order to communicate the data. From looking at the spectrum analyzer, the communication occurred every 12 seconds ont the dot about the temperature.

The author absolutely abuses Universal Radio hacker for this project. Using this tool, it automatically decoded the symbol rate, samples per symbol and the modulation type (obviously FSK). From there, they took a bunch of recording with the device in several different locations, such as the freezer with specific temperatures.

Once they had 10ish recordings, they began to analyze the protocol. Once they began analyzing, they realized URH had done the automatic decoding wrong, which led them down a path of manually calculating some of the parameters for the calls. Eventually, they got a data that looked consistent enough to attempt to really decode.

The protocol had two beginning portions: a preamble of A's (0x1010) then a sync word to sync up the timings once everything had been completely powered on. It is common in a lot of RF communications to have both of these values. The middle portion contained a slightly different values that appeared to be the temperature. Finally, there were two values at the end that they were unsure of but were likely a CRC.

The payload were binary coded decimal (BCD) digits shifted by a -40C offset. They found this common practice out by googling online, since the initial values were confusing to the author. The -40 offset is because they did not want to send negative numbers.

What about the CRC? The author attempted to use the built in CRC maker in URH with all the different parameters but did not get anywhere. They tried online but nothing checked out. Eventually, they ran into a project that called CRC_RevEng which, given enough inputs, will find the proper parameters for the CRC check. Neat!

After doing all of this work, they noticed a simple replay attack works. Even cooler, in URH, they could change the temperature information from the signal where the CRC would automatically be updated. Once this was done, URH could be used to transmit the signal to the weather station. Cloudy with a chance of pwnage!

The author had some issues making this work on other devices though. Eventually, they figured out what the 8th and 9th nibbles were: a synchronized time to transmit the signal from the thermometer to the base station. There were 256 possible timing that it chose at bootup; this allowed for the station to ONLY listen at this interval and sleep otherwise.

The two channel mode just had a different timing interval. Besides this, everything was exactly the same as the previous protocol. Overall, I really appreciated the article with practical knowledge on using URH, the CRC repo and practical knowledge in protocol reverse engineering. Good work mate!