TempestSDR

TempestSDR: An SDR tool for Eavesdropping on Computer Screens via Unintentionally Radiated RF

This dissertation presents a software toolkit for remotely eavesdropping video monitors using a Software Defined Radio (SDR) receiver. It exploits compromising emanations from cables carrying video signals.

Raster video is usually transmitted one line of pixels at a time, encoded as a varying current. This generates an electromagnetic wave that can be picked up by an SDR receiver. The software maps the received field strength of a pixel to a gray-scale shade in real-time. This forms a false color estimate of the original video signal.

The toolkit uses unmodified off-the-shelf hardware which lowers the costs and increases mobility compared to existing solutions. It allows for additional post-processing which improves the signal-to-noise ratio. The attacker does not need to have prior knowledge about the target video display. All parameters such as resolution and refresh rate are estimated with the aid of the software.

The software consists of a library written in C, a collection of plug-ins for various Software Defined Radio (SDR) front-ends and a Java-based Graphical User Interface (GUI). It is a multi-platform application, with all native libraries pre-compiled and packed into a single Java jar file.

Practical Attack

The demonstration is undertaken in controlled conditions. However, in order to make it as similar to a real-world attack as possible, we will assume the adversary has no knowledge of the victim’s system. We will estimate the frequency at which the emission strength peaks. We will then analyze the signal to detect the resolution and refresh rate of the screen. We will afterward lock onto the signal and try to recover the original video.

Set-up

The choice for a front-end for this demonstration is a HackRF. Depending on the particular requirements, an attacker might prefer mobility over accuracy and choose the smaller Mirics FlexiTVTMMSi3101 USB Dongle. However, for this demonstration, we will attempt to obtain the highest possible resolution. Therefore we need a radio that is capable of obtaining a wide bandwidth. This makes the 32 MHz of bandwidth that the USRP provides a much better choice.

For an antenna, we will choose the portable ANT500 - The Telescopic Antenna for HackRF. For better reception from a longer distance, a suitable log-periodic antenna, an amplifier, and a band-pass filter could be used for preconditioning. This can make the system less portable. However, the ANT500 antenna is a cheaper choice and in the end, did the required job.

Attack

We now take the place of the adversary that has set up their system, connected the SDR to the laptop and the antenna to the SDR and launch the JTempest.jar executable. We should now see the “Start” button becoming active. Once we press on the button, the system will start processing the data sampled by the HackRF.

If we knew the resolution, frame-rate and the frequency at which the emanations from the target occur, we could enter them directly into the GUI and the story would end here. However, since we don’t, we need to estimate them. That’s why we started with a low sampling rate (8 MHz). Such mode will not be good for actual eavesdropping since it will not provide the full resolution, however, this will allow for improved interactivity and for faster autocorrelation results.

The interface of the program. The “A” button will enable the frame-rate tracking feature. The “Auto” button will attempt to detect synchronization regions. The “AUT” button will try to automatically detect the resolution and line rate (video height). The scale on the right of the video shows in realtime the grey-scale values that map to a particular sample
intensity.

First, we need to estimate the frequency at which the emanations from the target peak. To do that we need to keep an eye on the autocorrelation plot and keep changing the frequency until a promising signal appears. There would be a lot of background signals so this would be challenging. However, most video displays run at known refresh rates of 60 Hz, 75 Hz or 71 Hz. If we spot a signal near these values, then we know we are on to something. Figure 4.2 shows that there might be a possible signal onto the current frequency of 125 MHz.

In order to set the video parameters to the frequencies in those spikes, we just need to click with the mouse on top of them. We can inspect the frequency at a certain position by hovering the mouse on top. Once we select the best candidate for the refresh rate, we can now choose the best candidate for the line rate as well. This defines the height of the video frame. Note that we can try the “AUT” button which will simply choose the highest values of the two plots. However, when the signal-to-noise ratio is low, other repeating signals on the same frequency may be more prominent so the manual adjustment would be required. The autocorrelation plots are interactive and the user can zoom with the mouse wheel and pan around for choosing small details in the plots. Now we click on the 60.3 fps spike on the top plot and the 628 px spike on the bottom one.

If we turn on the “Lpass” averaging, we will get rid of most of the noise and improve the signal-to-noise ratio bringing up the weak video signal. We can clearly see the synchronization pulses. We are also only seeing rapid changes in colors, so we know this is an analog signal. Digital signals will also show activity in regions that have constant intensities. That’s why digital signals could be eavesdropped easier – they emit more energy because of the sharp edges of the individual bits. However, we are apparently dealing with a VGA signal with resolution 800 × 600 @ 60. Note that the system auto-detected it (it shows up in the list underneath the “Stop” button).

We see another autocorrelation peak at 61 Hz. This is aliasing due to the two strong synchronization lines that appear in the video (you can see them on the left). By clicking on the other peak, we can indeed confirm our suspicion that it is just aliasing. Now that we have a signal, we can try to improve it. Since the signal is strongly polarized, changing the antenna angle and position can have a dramatic effect on the end result. Now we can increase the sampling rate of the HackRF to improve the resolution of the obtained image.

Conclusion

If we obtain a good enough signal, we can reconstruct text from the screen.

This shows that a practical attack is possible even from an adversary on a low budget with very little knowledge of the DSP. We also demonstrated that we can deduce the video parameters of a screen remotely in a real-world environment. A more sophisticated attacker could use better equipment with a lower noise floor and higher antenna gain to undertake such an attack from an even further distance. This should open the discussion about what could be done to prevent compromising emanations leaking from cables.