Using GRC for security research and auditing-converting radio signals into packets

Using GRC for security research and auditing-converting radio signals into packets
0x00 Introduction

As a company engaged in information security research and consulting, InGuardians has not only focused on penetration testing and network forensics for web applications since its founding, embedded devices and other fields are also devoted to the evaluation of wireless networks. During this period, wireless network evaluation gradually evolved from the initial deployment of a single enterprise wireless network to the analysis of some general or custom Bluetooth, zigbee and other networks.

Like other enterprises and security agencies, InGuardians has been expanding their knowledge by referring to some of the research results published by others. While using the content posted by others to improve their self-improvement, they have never stopped by sharing their own experiences and research results. If you are interested in BH, DC, and other meetings, you should have seen them at these meetings.

 

While seeking to fully understand the technical process behind radio auditing, InGuardians realized that there was a lack of step-by-step instructions on how to analyze radio signals. The biggest gap is how to use GRC (GNU Radio Companion) to thoroughly analyze Radio signals, finally, the radio signal is converted into data packets that are easier to understand and analyze. Although we cannot apply the analysis methods in some cases to any project as they are, understanding the steps behind the analysis cases not only helps people develop better tools, in some cases, it can also help people do other similar research. GRC Bit Converter3 (GRC Bit Converter: https://github.com/cutaway/grc_bit_converter) is a good example. It can help security researchers and radio enthusiasts complete their projects and work well.

0x01 installation and configuration

There are many tutorials on how to buy a suitable radio device, how to install GRC, and how to install spectrum analysis applications. Therefore, it is meaningless to repeat those things. Here, only links to these hardware and software are provided.

. Hardware resources

USRP, http://home.ettus.com/

HackRF Jawbreaker. https://github.com/mossmann/hackrf/wiki (. 1)

BladeRF-http://nuand.com/

RTL-SDR. http://en.wikipedia.org/wiki/List_of_software-defined_radios

CC1111EMK-http://www.ti.com/tool/cc1111emk868-915

Http://ubertooth.sourceforge.net/

Atmel RZUSBstick-http://www.atmel.com/tools/rzusbstick.aspx

Software resources

GNU Radio Companion-

Http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion

SDR #-http://sdrsharp.com/

GQRX-http://gqrx.dk/

Baudline-http://www.baudline.com/

RFcat http://code.google.com/p/rfcat/

Ubertooth-http://ubertooth.sourceforge.net/

KillerBee-http://code.google.com/p/killerbee/

By learning and using GRC (GNU Radio Companion), you can easily open the door to the Radio world. GRC's easy-to-use graphic operation interface allows you to easily implement some complex radio functions. Many specific operations in GRC depend heavily on the configurable modules ). By connecting and configuring different blocks, we can finally implement the functions we want. There are plenty of tutorials on the market to teach people how to use GRC and its main modules to capture and display the radio signals we need. Understanding and exploring how to get started with GRC should be a good training opportunity for readers in this article. InGuardians suggests that you use the software listed above. The use of SDR #, GQRX and other software can help readers have a preliminary understanding of radio transmission visualization and adjustment. This may help readers access GRC more quickly.

0x02 manage DC Spike

HackRF, BladeRF, or some other RTL-SDR users will see a big Spike when using spectrum analysis tools for frequency modulation ). This Spike is called DC Spike. (Peak at the center of figure 2)

Figure 2 DC Spike

When some users see these Spike for the first time, they may worry about whether their devices are defective, here we can tell you that this has nothing to do with the hardware you bought or the firmware used by the hardware. As long as you use the radio DC Spike, it will be with you. For more information about DC Spike, see https://github.com/mossmann/hackrf/wiki/faq.

As described in the HackRF FAQ, we do not need to consider DCSpike in most cases. However, if you want to successfully describe the signal you captured or capture the signal to be sent, you need to try your best to ensure that the signal is clean. Therefore, to avoid interference with DC Spike, we can use "DC Offset" to solve this problem. What we need to do is to adjust the receiving frequency to a bandwidth other than that of the radio through the correct GRC module. The only thing to note is that we need to select a reasonable offset to move the DC Spike out of the transmitted signal, at the same time, make sure that you do not set the offset too large so that we have to use the bandwidth we do not need.

There are two methods to determine how to configure DC Offset. The first method is to analyze the data in the product manual to determine the performance of the radio device. In the manual, you can usually find the channel interval annotation. In short, the channel interval is the distance from the center frequency to two different transmission regions. With this information, we can well adjust our DC Spike. The channel interval is not necessarily related to the transmission size. For example, when observing Wi-Fi signal transmission, we will find that although wifi has 14 channels, six of them will be swallowed up during the transmission of the radio adapter. In addition, observing the transmission bandwidth through spectrum analysis tools can help us adjust DCOffset, which is the second of the two methods we mentioned earlier. Figure 3 shows an example of applying the channel interval to a wireless mesh network to implement FHSS. Use the "PeakHold" option in grc fft to see the position where the DC Spike will appear.

Figure 3

The radio device sets a channel interval to prevent mutual interference between channels. The default channel interval varies with the device and manufacturer. Fortunately, because these values are preset, we can usually find these values in the documentation provided by the manufacturer. If you cannot obtain the value from the product reference manual or product supplier, you may find the value of the parameter You Want To Know in the Forum, product source code, or some patent applications.

Figure 4 DC Spike appears in the transmission signal

If the document you find is incomplete or the value of the channel interval needs to be verified, graphical analysis can help determine a rough channel interval. Figure 4 shows an example of a good visual channel interval through a graphical interface. The blue peak is the DC Spike, the green peak is the transmission signal, and the distance marked in red is the channel size. The interval between the edges of a transmission signal is exactly the channel interval.

GRC usually uses variable blocks to modify some values. In the following example, we will use the variable module to define the channel interval value. Once channel_spacing is set, we can use the value we set in other modules. To control the DC Spike using the channel interval, we define another variable module freq_offset and set its value to (channel_spacing/2) * (channel_spacing *. 1 ). With this formula, we can move DC Spike to the edge of the signal. If we further adjust 1 to 10 here, we can move the DC Spike out of the transmission signal (5 ). Figure 6 shows you how to set the relevant osmocom Source.

Figure 5 configuration of freq_offset

Figure 6 set the corresponding osmocom Source module

Once we have completed the configuration of these modules, we will see the results of the formula calculation thick in the corresponding area of the club. The calculated result is 7.

Figure 7 GRC capture Configuration

Finally, in figure 8, we can see that we have successfully moved the DC Spike out of transmission.

Figure 8

0x03 separation of transmission signals

Once the DC Spike problem is solved, we can process the signal without interference. What we need to do next is signal separation. There are two modules in GRC that can help us to separate signals. They are Low Pass Filter (LPF) and FrequencyXlating FIR Filter (FXFF) modules. In terms of functions, the two are almost the same for us. However, compared with LPF, FXFF provides us with more options to make it easier to separate or operate on transmitted signals. Here we will give a brief introduction to LPF.

In the LPF configuration, the first adjustable option is Decimation. By adjusting this value, we can modify the Sampling Rate of the incoming signal ). You will see Decimation in the GRC examples of FM demodulation. The value of this parameter is usually calculated by the formula like freq_offset in Figure 5. Although Decimation needs to be used in some signal demodulation, we will not use it in this example. So we can keep it in the default value "1", so that it will not have any impact on our sampling Rate. This practice also ensures that we do not break the meaning that two sampling is required for each sine period mentioned in the sampling theorem.

Next we need to set the "Window" option. The default value of this option is "Hamming ". But in the Balint Seeber's "Blind signal analysis with GNU Radio" speech, he once mentioned that we should set the Window value to "BlackMan ", this is a better algorithm than the other one.

After setting the Decimation and Window parameters, we also need to set SampleRate, Cutoff Frequency and Transition Width to complete our signal separation. The setting of Sample Rate is very simple. It is the input sampling Rate and should be set to "samp_rate" by default as mentioned above ". Note that even if we use decimation to modify the output sampling Rate, the Sample Rate should still be set to our input sampling Rate. Cutoff Frequency is the channel size shown in Figure 4 previously mentioned. However, the interval setting should also be the same as we mentioned earlier. A variable module with the same name should be set.

The most troublesome one is the setting of Transition Width. Before setting this value, we need to perform some tests to give it a correct value. More experiences and surveys will help you set this value at first. Of course, this will also depend on factors such as the center frequency, bandwidth, and radio device type. In some cases, the transmitted signals are not exactly concentrated in the center frequency. It is often affected by weather, Power, or other signals. All in all, the unreasonable setting of this value may lead to the generation of redundant signals or the loss of signals. Based on our experience, we will set this value to 40% ~ of Channel Spacing ~ Value Between 50%. Later we will see that this setting can bring us the best results. In Figure 9, we will use the following parameters to configure LPF.

Frequency Offset 120,000

Channel Spacing 200,000

Channel Transition 80,000

Window BlackMan

When we use the above parameters to observe the signals we have separated, we find that our signals are not at the center of the FFT Plot. However, to properly demodulated the signal, we need to move the signal to the center of the FFT Plot. Here we need to use Frequency Xlating FIRFilter (FXFF) to implement this operation.

FXFF, as we mentioned earlier, has many similarities with LPF. So here we can set Decimation and Sample Rate to the same value as previously in LPF. There is also a variable called Center Frequency in FXFF. Like DC_Offset, this variable is usually used to correct the signal and adjust it to the center. If DC_Offset is not used during the setting process, the value should be set to 0. If it is not, the value should be set to freq_offset. The last one we need to set is the Taps variable. For the setting of this variable, we use the formula "firdes. low_pass (1, samp_rate, channel_spacing, channel_trans, firdes. WIN_BLACKMAN, 6.76 )". (See Figure 10)

After setting FXFF, we can see the expected results in Figure 11.

0x04 actual mediation

The separation of Signals Using LPF and FXFF can help us demodulated the signals more effectively. Michael Ossmann described how to demodulated from this point in his radio training course. In his course, he not only talked about related concepts and mathematical knowledge, but also told us that in order to describe different ASK (amplitude-shift key) and irrelevant (frequency-shifykey) the required module. For the demodulation ASK, we can use "Complex to Mag" or "Complex to Mag ^ 2 ". However, we can use "Quadrature Demod" to describe the 'baset' (especially 2PSK and GFSK ".

In this example, We Need To demodulated the signal transmitted through GFSK. Some of the results we have seen in the previous images are the data transfer results between the Texas Instrument (TI) Chronos Watch and IChronos black dongle. On TI's site, we can find some data related to this dongle, or even its source code. Finally, we can see the information we want to know (Mudulation = (1) GFSK) in the source code of this product, as shown in 12.

Now that we know Modulation type, we need to know about Deviation. This value can be obtained from the source code (Deviation = 32 Khz in figure 12 ).

When we configure the "Quadrature Demod" module to be used for GFSK demodulation, we will see that the default Gain variable will be calculated using this formula: samp_rate/(2Math. piFsk_deviation_hz/8.0), which means we also need to add a variable module fsk_deviation_hz to assist Gain computing. This fsk_deviation_hz is exactly the second variable Deviation (13) we mentioned previously that needs to be known and set ). This is why we should know the value of Deviation in addition to Modulation type.

In Figure 13, we can see that the Quadrature Demod processing result of the module is finally output to the File Sink module. This is because from this step we need to put the result after demodulation into other tools to complete our subsequent steps. One thing to mention here is about file naming and output location. Sometimes we need to write large files to the disk in a short time. If you are a Linux user, we recommend that you write the file to "/dev/shim", which is faster than writing the file directly to the hard disk. For file naming, you can refer to storing some useful and important information in the file name to facilitate future analysis and processing. For example,

"/Tmp/blog_demod_1e6_905.99e6_gfsk_76721_hackrf.cfile ."

After these settings are completed, GRC in Figure 13 will store the adjusted signal to our pre-set file. Import this file to the spectrum analytics tool Baudline (Baudline: http://www.baudline.com/) to continue our work. If you have any questions about the details, you can see more detailed explanations in the Keyfob blog post published by Dragorn (there are many highlights in the comments ). As shown in figure 14, the FFT and waveform diagrams presented after the file is imported to Baudline.

By using Baudline, we can analyze and judge our results before converting the radio signal into a data packet. Now we will zoom in the waveform to further observe. (15)

By observing the signals after demodulation, we can find some valuable information. First, we can see that the signal we get is not as clean as we expected. Secondly, the overall off of the waveform map does not pass through the X-axis. However, these are very unfavorable for us to convert the radio signal to 0 and 1. To achieve signal conversion, we need to add another LPF between Quadrature Demodulation and File Sink blocks. As mentioned earlier, this module requires us to configure its "Cutoff Freq" and "Transition Width" variables. However, the problem is that there is no good documentation to tell us how to set the two variables in this LPF. The values of these variables may be affected by the frequency, Modulation, and other configurations. Based on experience, we usually set "Cutoff Freq" from 100,000 and set "Transition Width" to half of it. Repeat these parameters and import the output file to Baudline for observation, after several or more rounds of debugging, we will see a waveform chart that looks more like data in Baudline. The waveform in Figure 16 is the result after we set "Cutoff Freq" to 80,000 and "Transition Width" to 50,000.

Now we can see that our signal looks much better. However, the waveform and central axis issues remain unsolved. To solve this problem, we only need to Add an Add Const module in the LPF and File Sink to migrate the waveform as a whole. For how to set the value of AddConst, you can refer to the previous LPF Adjustment Method to gradually increase the value until the screen shown in Figure 17 appears (Here we set contast to 6 ).

Understanding how to operate wave pattern without losing data is also important when we analyze other signals. For example, if the vendor's document mentions that data is transmitted after being put upside down, we can reverse the data by setting the contast value to-1.

0x05 count

After understanding the call, we need to check all 0 and 1 from the wave. In GRC, we can use "Clock Recovery MM" and "Binary Slicer" to implement it. Among them, "Clock Recovery MM" is responsible for finding the high position and position from the wave, and then "Binary Slicer" is responsible for converting them to 1 and 0. First, we need to configure the "Clock Recovery MM" module. After opening the "Clock Recovery MM" configuration interface (shown in 18), you may be scared by these many uncomfortable variables. But in fact, variables such as "Gain Omega," "Mu," "Gain Mu," and "Omega Relative Limit" generally do not need to be reset. So you only need to keep the default values. So the only thing we need to set here is the "Omega" variable. In the default value of "Omega", we can see this setting: samp_per_sym * (1 + 0.0 ). This means that we need to add a variable module samp_per_sym as before to help "Clock Recovery MM" calculate the number of Samples Per frame (Samples Per Symbol ).

Here samp_per_sym can be calculated using the formula "int (samp_rate/data_rate)" (19 ). Samp_rate is known to us, but what about data_rate? The value can be found in Figure 12. Therefore, to calculate samp_per_sym, we need to add another variable module "data_rate" and set its value to 76721.191 shown in Figure 12.

In the end, we connect the configured modules to the GRC we have prepared (from Figure 20, we can see that the original File Sink is in the Disabled state). This is what figure 20 shows.

0x06 analyze the demodulated data

After we run the GRC shown in Figure 20, we will get a file. Open the file we obtained through xxd in Linux or hex editor on any platform, and you will see the content of 21.

As we expected, we can see 0 and 1 in the middle. Each 8 bits can be regarded as a bit of data. For example, the first line of 0101 0101 0101 0101 0101 0101 0101 should be 0b1111111111111111 or 0xff. The third row's 0101 01010101 0101 0001 0100 0100 0101 should be 0b1111111101011 or 0xff6b.

However, these outputs may be transmitted data, and may be anything else that can be expressed by 0 and 1. So finding the real data here will be our greatest challenge. Based on experience, the data shown in Figure 21 is highly similar to noise transmitted in the air. In our current configuration, "Clock Recovery MM" will throw all the high and low positions to "Binary Slicer" for processing. However, from the current data point of view, we have received too much noise compared with the actual data ). That is to say, our current GRC configuration does not have the ability to identify data, noises, and signals from other radio devices. Maybe we can locate the actual data through the header bit of the data packet, but does GRC have such a module to implement the function we want?

In addition, the data we see in Figure 21 is raw data. So we need to convert the data into bytes to discuss how to identify the noise or find the real data. Here you can use GRC Bit Converter (https://github.com/cutaway/grc_bit_converter) developed by InGuardians to convert data to bytes (22 ).

Run grc_bit_converter.py by default. The script converts every 2000 bits into 250 bytes and marks them as a data packet. This process repeats until all data is processed. The parameter "Occurrences" tells us how many packages have identical data. This parameter will be of great use after we find the data packet.

After the conversion, we need to determine how the transmitted data is formatted. This will help us find them from this pile of data. Many radio devices (not all, but most of them) Send the preamble and SyncWord before data transmission ). The forward guide code is a series of transmission from high to low. If you look at binary files, it will usually be like "0b10101010101010" or "0xaaaa ". The number of forward Code bytes depends on the device or its related configurations. Since there is no way to determine what is the first guide code, after we have processed binary files, the forward code you see in the parsed file may have changed to "0101010101010101" or "0x5555 ". The forward code is usually used to tell the device that the next data needs to be processed. The synchronization code is responsible for telling the device where the data starts. The most common synchronization code in real-world radio transmission is "0xd391 ". However, just like the pre-guide code we mentioned earlier, after parsing, "0xd391" may have become another value. In this case, we need to use ipython to perform a small processing on this "0xd391. In Figure 23, you may see 0xa722, 0x4e44, or 0x9c88 appear in the parsed file.

With a clue, let's try to find our synchronization code (0xd391) from the output result of grc_bit_converter.py to locate our data packet (24 ).

Now we finally find something that looks like data. Of course, we can also review the synchronization code and forward code descriptions in Figure 12 to determine the accuracy of our operations. Here we can see that the forward guide code we mentioned earlier is "\ xaa". The 4 bytes mentioned in Figure 12 exactly matches. However, our synchronization code "\ xd3 \ x91 \ xd3 \ x91" is exactly 32 bits, which is also consistent with the 30-bit Synchronous Code described in the source code to detect 32 bits. In the source code, we also see that the first byte after the synchronization code represents the length of the entire data packet. We can see that the first byte after the synchronization code is exactly \ x0f, that is, 15. Starting from here, we will find that there are still two bytes left, and these two bytes are CyclicRedundancy Check (CRC. These two are called data errors. Cyclic Redundancy checks are usually used to check the correctness and integrity of data.

0x07 mark data packets

When the information on our hands is very limited, parsing data manually or using scripts may sometimes be our only way out. However, in this case, we have enough information to use the GRC module to mark data packets.

This action can be completed using the "Correlate Access Code" module in GRC. In the "Correlate Access Code" module, we need to configure two variables to complete the marking operation. They are "Access Code" and "Threshold" respectively ". The "Access Code" is the feature vector we need to define to represent the packets that need to be labeled. However, another parameter "Threshold" is the number of digits in the feature vector that may change. In Figure 12, we can see that only 30 of the 32-Bit Synchronization Codes are detected, which means that the two of them may be different. The value of "Threshold" here should be 2. The feature vector "Access Code" should be filled with the value corresponding to the synchronization Code, as we mentioned earlier (25 ).

As mentioned earlier, "Correlate Access Code" marks the data processed by "Binary Slicer. The related positional relationships are shown in Figure 26.

After the file output is completed, we can use xxd or hex editor to open the output file as before, and search 02 or 03 to find the marked data packet. (27)

Just like using grc_bit_converter.py to analyze the output file, this script can also be used this time. This time, we need to add several parameters after the script to check the packets marked by the "Correlate Access Code" module and modify the packet size (28 ).

0x08 Verification

The GRC configuration in this example works well for our TI Chronos Watch. But can these technologies be applied to other or similar radio transmissions? For verification, we will use the packet captured by offsets Offset for verification.

To analyze this package, we need to replace the original sources module with the "File Source" and "Throttle" modules. In this case, the capture rate is 500,000, but the DC Offset is 200,000Hz. The GFSK signal is transmitted at 903 MHz (29 ).

As shown in Figure 29, the signal we captured is close to the left edge of the image. We can also find that the channel size is nearly 902,950,000Hz from 903,100,000 to 150,000. Then, set the Channel interval in FXFF to 100,000 and "Channel Transition" to 50,000. Then we can see the change in Figure 30.

We can also know other information through Jay's Post. For example:

. Deviation 16,500

. Data rate 19200

After using these values to complete the previous steps, we can import the signal to baudline for adjustment and analysis. After many adjustments, we finally set "CutOffFreq" and "Transition Width" to 25,000 and 10,000 respectively. The adjusted waveform is shown in Figure 31.

We know that the waveform still needs to be adjusted up and down. Here we need to set "Add Constant" to-6 to move the wave downward. After completing the wave adjustment, we need to verify the synchronization code as before, and finally know that only one "0xd391" will be sent ". When this information is received, we set "Correlate Access Code" to mark the package. After setting the package size to 80, we call grc_bit_converter.py again to observe the result (as shown in 32 ).

After completing these steps, the next step is to determine the protocol used in the data transmission. Starting with the package length, CRC bytes, and whether to use the data vernacular technology will be of great help for us to analyze the data. As an additional data capture, we can also try to capture packets in the context of power-on, power-off, and pairing. The more data is captured, the better we can understand how they communicate and what is the middle-end data transmission, how should we set GRC to implement the communication we need.

0x09 conclusion

With appropriate equipment and software, we can easily capture the signals we want to capture. However, it is a little difficult to understand how to use GRC to operate the captured signal. This makes it more complicated to demodulated the signal and convert it into a data packet. Fortunately, we can read analysis cases shared by many people over the Internet. Understanding these cases can make our analysis process much easier.