{"id":2186,"date":"2016-02-07T19:20:44","date_gmt":"2016-02-07T19:20:44","guid":{"rendered":"https:\/\/zed.inguardians.com\/?p=2186"},"modified":"2019-02-07T20:15:30","modified_gmt":"2019-02-07T20:15:30","slug":"grc-transmission-analysis-getting-to-the-bytes","status":"publish","type":"post","link":"https:\/\/zed.inguardians.com\/blog\/grc-transmission-analysis-getting-to-the-bytes\/","title":{"rendered":"GRC Transmission Analysis: Getting To the Bytes"},"content":{"rendered":"

Post Author: Don C. Weber [Twitter:\u00a0@cutaway<\/a>]
\nDate Published: 15 May 2014<\/p>\n

I have not picked up my\u00a0HackRF Jawbreaker<\/a>\u00a0in a while (Figure 0x0). Family and billable work trump side projects. Lucky for me\u00a0Tom Liston<\/a>\u00a0and I started teaching the\u00a0Assessing and Exploiting Control Systems<\/a>class which leverages the\u00a0Samurai Project’s Security Testing Framework for Utilities (SamuraiSTFU)<\/a>. I say \u201clucky\u201d because I have a few updates I want to work into the courseware that center around improving the\u00a0GNU Radio Companion (GRC)<\/a>\u00a0frequency analysis labs. Even with the SamuraiSTFU updates I still found myself busy. I kept putting this off until\u00a0Jay Radcliffe<\/a>\u00a0asked me to take another look at a radio capture he had grabbed from his insulin monitor\/pump setup. He wanted to see if we could use GRC pull the transmitted data out of the air and into a file as I had done a couple months before with RFcat.<\/p>\n

\"\"<\/a><\/p>\n

Figure 0x0: HackRF Jawbreaker<\/p>\n

Both of these projects had a similar issue: we were having difficulty moving from the captured radio transmission to actual demodulated data representing a \u201cpacket\u201d of bytes. There are several reasons for this predicament, but the biggest issue is the recent advances to GRC. The rapid development and growth of the GRC code over the last year has been staggering. All of my old GRC files use blocks that are listed as \u201cOld\u201d or the blocks that do not appear in the main GRC window at all. The most frustrating case, of course, is when the blocks don\u2019t appear at all because I have to try to remember what I was trying to accomplish a year ago. Imagine opening up a script you wrote a year ago (one you didn\u2019t really fully understand at the time) only to find out that fifty percent of the functions had been deleted, seemingly at random.<\/p>\n

Another general issue related to proper signal processing is that each block has its own parameters that are specific to efficient processing of the signal into a demodulated state. For those of us who are not radio engineers and do not work with GRC every day, understanding these parameters is extremely difficult. If you don\u2019t understand exactly what they do, how can you know how some of these parameter values are obtained or modified? Let\u2019s face it, there is a LOT of math involved with frequency analysis and demodulation. Fortunately, tools like GRC exist to do the majority of the difficult math for us. However, many of these math functions require very specific values so that the results of the computations are accurate for the specific signals being analyzing.<\/p>\n

Like everyone else, my family and billable work issues never let up. Thus, I found myself, as most of us do, working deep into the night on these \u201cside projects.\u201d Here are a few things I learned \u2013 by asking questions, reading blogs, using default settings, and (in true hacker fashion) guessing through trial-and-error.<\/p>\n

DISCLAIMER<\/b>\u00a0(Yes, this needs one\u2026):\u00a0I am not a Radio Engineer. The information provided here is accurate to the best of my knowledge. These are techniques gleaned from taking Mike Ossmann\u2019s radio analysis course, doing extensive research, listening to my mentors and peers, and by trial-and-error over several radio analysis assessments. I may not use the right terms or express a technique the way a Radio Engineer would approach it. What I will do is show you what has worked for me, repeatedly. If I do make a mistake or an incorrect assumption, just let me know, and I will update this information.<\/i><\/div>\n

Before we start, I have created a white paper for those people who are impatient, do not like the conversational tone of a blog post, or want to have this information in a document to read and pass around:Converting Radio Signals to Data Packets<\/a>. Additionally, for quick reference, I will be using a tool called\u00a0GRC Bit Converter<\/a>\u00a0to help analyze and print the captured data.<\/p>\n

Managing Direct Current Spike<\/h2>\n

When using a HackRF or one of the many RTL-SDR dongles there is a large spike at the center frequency to which the radio has been tuned. This is the Direct Current (DC) spike (demonstrated using\u00a0SDR#<\/a>\u00a0in Figure 0x1), that occurs naturally in radios that have not specifically accounted for this spike via hardware \/ firmware. The HackRF team does a great job explaining why this occurs and what can be done with it in their website\u2019s\u00a0Frequently Asked Questions (FAQ)<\/a>.<\/p>\n

\"\"<\/a><\/p>\n

Figure 0x0: HackRF Jawbreaker’s DC Spike<\/p>\n

As described in the HackRF FAQ, the DC spike can simply ignore it. However, because I have had a hard time successfully demodulating the signals recently, I want my data to be as clean as possible (yes, I am probably a little naive, but learning this also method helps when I \u201cdo\u201d need it).<\/p>\n

To avoid the DC Spike, I like to create my captures by leveraging the \u201cDC Offset\u201d method. Capturing with an offset is easy enough to understand and easy to accomplish with the currently available GRC blocks. The challenge here is to select an offset that moves our DC Spike outside of our source\u2019s transmitted signal while still staying within the bandwidth that is being captured. There are two methods can be leveraged to determine this offset. The first is to conduct data sheet analysis to determine the radio and devices capabilities. These documents will outline \u201cChannel Spacing.\u201d The channel spacing is the distance between the center frequencies of two transmission areas configurable by the radio. While this helps, and is often enough information to adjust for the DC Spike, the channel spacing is not necessarily related to the size of the transmission. We see this in Wi-Fi which has fourteen (14) channels but the transmission of a wireless adapter will engulf approximately six (6) of those channels. To compensate for this possibility I use spectrum analysis software, as shown in Figure 0x2.<\/p>\n

\"\"<\/a><\/p>\n

Figure 0x2: DC Spike Inside TX Signal<\/p>\n

The spectrum analyzer allows me to visually select a frequency in an area outside the transmission. Once I have selected a frequency, I note the distance between them and configure my GRC variable blocks appropriately. In this example I will add a variable block named \u201cchannel_spacing.\u201d This allows me to configure the Frequency Offset in another variable block, named \u201cfreq_offset\u201d, with the equation: “(channel_spacing \/ 2) * (channel_spacing * .1)<\/i>“. Dividing the channel spacing by two gives me the distance from the center frequency to the edge of the transmission. Using this number should move the DC Spike to the very edge of the transmission. Adding an additional 10 percent to this offset \u201cshould\u201d move it completely outside the transmission. Figure 0x3 demonstrates the \u201cfreq_offset\u201d variable block configuration and Figure 0x4 shows how it is implemented within the source block.<\/p>\n

\"\"<\/a><\/p>\n

Figure 0x3: GRC “freq_offset” Variable Block Configuration<\/p>\n

\n

\"\"<\/a><\/p>\n

Figure 0x4: GRC “osmocom Source” Block Configuration<\/p>\n

Once this is all configured, each of the blocks in the primary GRC window will display the computed values after doing the math for us. Each of these values is shown in Figure 0x5.<\/p>\n

\"\"<\/a><\/p>\n

Figure 0x5: GRC Capture Configuration<\/p>\n

When this GRC script is run the Top Block will display the location of DC spike in relation to the transmitted signal. Figure 0x6 shows how this will appear in a spectrum analyzer.<\/p>\n

\"\"<\/a><\/p>\n

<\/p>\n
Figure 0x6: GRC Top Block With Offset DC Spike<\/div>\n

<\/center><\/p>\n

\n

Isolating The Transmission<\/h2>\n

Now that the DC Spike has been addressed (or not), I concentrate on processing the data transmission itself. The basic concept is to \u201czero in\u201d on the transmission and isolate it from any other signals. I used to do this using a Low Pass Filter (LPF) block (more on that in a moment). The LPF takes several parameters, and we can spend a lot of time delving into each of them. For brevity sake, I\u2019ll just explain the ones that I use the most.<\/p>\n

The first variable I consider configuring is the \u201cDecimation\u201d parameter. Decimation provides a mechanism to modify the sampling rate of the incoming signal. My understanding is that Decimation is particularly valuable when taking a transmitted signal and modifying it for output as an audio signal. The best way to leverage this parameter is to use the same equation-method that we used to implement the frequency offset. Begin by specifying the input sampling rate, which is usually automatically identified by the \u201csample_rate\u201d variable block, and then dividing by the intended (a.k.a output) sampling rate. Configured the Decimation parameter with this equation will result in this block outputting our signal with our intended output sampling rate. For this current example, however, there is no need to modify the sampling rate. Therefore, I simply check to make sure this parameter is set to a value of \u201c1\u201d which indicates no change. Not decimating also helps avoid any issues associated with breaking the Nyquist\u2013Shannon sampling theorem rule. This rule simply states that a signal must be sampled at twice the data rate to avoid data lose.<\/p>\n

The first value I actually change in this block is the \u201cWindow\u201d value. This parameter use to be one of those values that I left as the default: \u201dHamming\u201c. However, after watching Balint Seeber\u2019s talk about\u00a0\u201cBlind signal analysis with GNU Radio\u201d<\/a>\u00a0I realized that I needed to change this setting to \u201cBlackman.\u201d I don\u2019t exactly know how this improves the computations or the mathematics performed by the LFP, but I\u2019ll trust his judgment after listening to his radio experience.<\/p>\n

Next, in order to actually isolate the transmission, I provide the appropriate values for \u201cSample Rate,\u201d \u201cCutoff Frequency,\u201d and \u201cTransition Width.\u201d Sample Rate is simply the incoming sample rate. Even if we are using Decimation to modify the output sample rate we use the incoming sample rate as the value for this variable. The \u201cCutoff Frequency\u201d (from what I understand) is the bandwidth (size) of the transmission extending out from the center frequency. We have already computed this value when we specified the \u201cChannel Spacing.\u201d Therefore, we can leverage the value already specified in the \u201cchannel_spacing\u201d variable block.<\/p>\n

\u201cTransition Width\u201d is, to me, another one of those mystery parameters. I don\u2019t know specifically how to determine this value. Therefore, using common sense, I simply assume that the transmission signal is not always going to be exactly centered on our intended center frequency. Many things are going to impact our signal: weather, other signals, power lines, etc. Therefore our radio has to compensate for anomalies to ensure that \u201call\u201d of the signal is received. While there may be a very \u201cmathematical\u201d way to describe what this value does, I think of it as \u201cblurring\u201d what the radio considers to be the edge of the signal so that if there is atmospheric jitter the data will still be accessible. Using this logic, I figure that while creating a steep transition will isolate the center frequency very well, it will ultimately generate some signal and data loss at the edges. On the other hand, a slow transition may include too much extra signal and ruin our ultimate goal of signal isolation. So, how do I determine it? I guess and test. From my guessing and testing I have determine that setting the \u201cTransition Width\u201d to a value between forty (40) and fifty (50) percent of the channel spacing gets me the output signal that works the best in the follow-on demodulation blocks. Yes, you can do this using the math equation style mentioned previously. I usually just do the division in my head and input the value into a variable block.<\/p>\n

Figure 0x7 shows the captured signal leveraging the following inputs for the LPF.<\/p>\n