Over on YouTube the channel "Lead Cyber Solutions" has uploaded a video presentation for the Cyber Skills Competition. In the video Christopher Flatley, James Pak and Thomas Vaccaro discuss a man-in-the-middle attack that can be performed on vehicle Tire Pressure Monitoring Systems (TPMS) with a transmit capable SDR such as a HackRF.
A TPMS system consists of small battery powered wireless sensors placed on a vehicles wheels which automatically monitor tire pressure. An LCD basestation usually exists on the dashboard of the car indicating live tire pressure. Most modern cars come with this feature, and it is simple to retrofit an older car with an aftermarket TPMS system.
The idea behind the vulnerability is that a HackRF can be used to reverse engineer the TMPS signal, and then re-transmit a new fake signal that causes the base station to read the tire pressure as low. This can set off an alarm in the car and possibly cause someone to pull over. More alarmingly, they discuss how tractors have automatic tire inflation systems which work using similar sensors. A false low pressure reading could cause the tractor tires to over inflate and be damaged.
Thanks to RTL-SDR.com reader 'flatflyfish' for submitting information on how to get Martin Marinov's TempestSDR up and running on a Windows system. If you didn't already know by definition "TEMPEST" refers to techniques used by some spy agencies to eavesdrop on electronic equipment via their unintentional radio emissions (as well as via sounds and vibrations). All electronics emit some sort of unintentional RF signals, and by capturing and processing those signals some data can be recovered. For example the unintentional signals from a computer screen could be captured, and converted back into a live image of what the screen is displaying.
TempestSDR is an open source tool that allows you to use any SDR that has a supporting ExtIO (such as RTL-SDR, Airspy, SDRplay, HackRF) to receive the unintentional signal radiation from a screen, and turn that signal back into a live image. This can let you view what is on a screen without any physical connections. If a high gain directional antenna is used then it may be possible to receive images from several meters away as well.
Although TempestSDR has been released now for a number of years it hasn't worked properly in Windows with ExtIO interfaces. In his email flatflyfish showed us how to compile a new version that does work.
1. You need to install a 32-bit version of the Java runtime. The 64-bit version won't work with extio's possibly because they are all 32-bit. Also install the JDK.
2. You need to install MingW32 and MSYS and put their bin folders in your Windows PATH.
3. Then when compiling I was seeing a lot of CC command unknown errors. To fix that I just added CC=gcc to the top of all makefiles. I also removed the Mirics compilation line from the JavaGUI makefile to make things easier as we're not using that sdr.
4. Originally my JDK folder was in Program Files. The makefile didn't like the spaces in the folder, so I moved it to a folder without spaces and it fixed the errors.
5. Lastly to compile it you need to specify the ARCHNAME as x86 eg "make all JAVA_HOME=F:/Java/jdk1.7.0_45 ARCHNAME=X86"
After doing all that it compiled and I had a working JAR file. The extio's that are used normally with HDSDR work fine now and I get some images from my test monitor with an rtlsdr.
We've tested the software with the ExtIO for RTL-SDRs (available on the HDSDR downloads page) and confirmed that it works. Images from one of our older DELL monitors using DVI are received nicely, although they are a bit blurry. We also tried using an Airspy or SDRplay unit and this significantly improved the quality of the images a lot due to the larger bandwidth. The quality was good enough to make out large text on the screens. ExtIO's for the Airspy are available on this page, and for the SDRplay on the official SDRplay website. Note that for the SDRplay we were unable to go above 6 MHz, and on the RTL-SDR 2.8 MHz was the limit - anything higher on these SDRs did not produce an image possibly due to dropped samples.
To use the software you should ideally know the resolution and refresh rate of your target monitor. But if you don't there are auto-correlation graphs which actually help to predict the detected resolution and frame rate. Just click on the peaks. Also, you will need to know the frequency that your monitor unintentionally emits at. If you don't know you can browse around in SDR# looking for interference peaks that change depending on what the image of the screen is showing. For example in the image below we show what the interference might look like. A tip to improving images is to increase the "Lpass" option and to watch that the auto FPS search doesn't deviate too far from your expected frame rate. If it goes too far, reset it by re-selecting your screen resolution.
The best results were had with the Airspy listening to an older 19" DELL monitor connected via DVI. A newer Phillips 1080p monitor connected via HDMI had much weaker unintentional signals but images were still able to be recovered. A third AOC 1080p monitor produced no emissions that we could find.
Clear images were obtained with an antenna used in the same room as the monitor. In a neighboring room the images on the DELL monitor could still be received, but they were too blurry to make anything out. Possibly a higher gain directional antenna could improve that.
Below we've uploaded a video to YouTube showing our results with TempestSDR.
Defcon is a huge yearly conference based on the topics of information security and hacking. Some of the talks relate to wireless and SDR concepts. Recently videos from the last Defcon 25 conference held in July 2017 have been uploaded to YouTube. Below is a selection of some interesting SDR and radio related talks that we have found. If you're interested in exploring the rest of the talks then you can find them on their YouTube page. Most of the radio related talks are in the 'WiFi Village' category.
DEF CON 25 Wifi Village - Balint Seeber - Hacking Some More of the Wireless World
The hacking continues on from last year! Three interesting applications will be demonstrated, and their underlying theory and design explained. The audience will be exposed to some novel GNU Radio tips and DSP tricks. INMARSAT Aero will be revisited to show (in Google Earth) spatial information, such as waypoints and flight plans, that are transmitted from airline ground operations to airborne flights. A good chunk of the VHF band is used for airline communications; plane spotters enjoy listening to tower and cockpit communications.
Modern SDRs can now sample the entire band, and as AM modulation is used, it's possible to use a counterintuitive, but simple, demodulator chain (first shown by Kevin Reid's wideband 'un-selective AM' receiver) to listen to the most powerful transmission. This will be demonstrated with a GNU Radio-based implementation. It is also possible to 'spatialise' the audio for the listener using stereo separation, which can convey a transmission's relative position on the spectrum. FMCW RADAR experiments are enhanced to include Doppler processing.
Plotting this new velocity information, due to the Doppler effect, shows whether a target is heading toward or away from you, and often reveals targets not normally seen in range-only information - this demonstrates the true power of full RADAR signal processing. This technique will be applied to the live audio demo, a new live SDR demo, CODAR ocean current tracking, and passive RADAR exploiting powerful ATSC digital television signals (this was used to track aircraft on approach across the Bay Area).
DEF CON 25 - Matt Knight - Radio Exploitation 101
What do the Dallas tornado siren attack, hacked electric skateboards, and insecure smart door locks have in common? Vulnerable wireless protocols. Exploitation of wireless devices is growing increasingly common, thanks to the proliferation of radio frequency protocols driven by mobile and IoT. While non-Wi-Fi and non-Bluetooth RF protocols remain a mystery to many security practitioners, exploiting them is easier than one might think.
Join us as we walk through the fundamentals of radio exploitation. After introducing essential RF concepts and characteristics, we will develop a wireless threat taxonomy by analyzing and classifying different methods of attack. As we introduce each new attack, we will draw parallels to similar wired network exploits, and highlight attack primitives that are unique to RF. To illustrate these concepts, we will show each attack in practice with a series of live demos built on software-defined and hardware radios.
Attendees will come away from this session with an understanding of the mechanics of wireless network exploitation, and an awareness of how they can bridge their IP network exploitation skills to the wireless domain.
Most modern vehicles use some form of rolling code security on their wireless keyfobs to prevent unauthorized replay attacks. When the car owner presses a button on the keyfob, a unique rolling code is sent to the car. If it matches one of the codes currently stored in the car, the car will unlock and then invalidate that code so it can never be used again, thus preventing a replay attack. On the next press the keyfob sends a new code. In most designs when a code is used up, a new code is added to the list of valid codes via a random number generator based on a secure algorithm only known (presumably) to the engineers.
Essentially Tom found that instead of producing a randomly generated rolling code, the Subaru keyfob simply increments the rolling code number each time. This allows an attacker to perform a second key press simply recording an initial real key press, decoding the packet, increasing the decoded rolling code by one, then re-transmitting. It also means that the attacker could continually raise the rolling code value on the car himself, which would eventually make the real keyfob useless as the codes on the keyfob would be outdated and no longer match the same number range as the car.
The entire exploit was found on a super low budget. Tom used only an RTL-SDR and Raspberry Pi. The receive is obviously handled by the RTL-SDR, but the transmit side is handled by RPiTX which is software that allows the Raspberry Pi to transmit RF signals directly from a GPIO pin without the need for any additional transmitting hardware. Tom writes that the exploit probably affects the 2006 Subaru Baja, 2005 - 2010 Subaru Forester, 2004 - 2011 Subaru Impreza, 2005 - 2010 Subaru Legacy and the 2005 - 2010 Subaru Outback. Tom also writes that various dealers and spokes people have contacted him stating that the exploit probably only affects US models. If you have one of the affected models and are worried the only way to stay safe is to simply not use wireless entry on the keyfob, at least until/if Subaru fixes the issue with a recall. Although so far no statement from Subaru has been released.
Tom has also uploaded a demonstration video to YouTube which is shown below.
The PandwaRF (formerly known as GollumRF) is an RF analysis transceiver tool that can be very useful for investigating ISM band devices that communicate with digitally modulated RF signals. It can be used for applications such as performing replay attacks, brute force attacks, and other analysis. The RX/TX frequency range of the device is from 300 – 928 MHz, with a transmit power of up to +10 dBm.
The PandwaRF is based on the CC1111 chip which is the same chip used in devices like the Yard Stick One from Great Scott Gadgets (creators of the HackRF). Compared to the YS1 the PandwaRF is essentially the same, but designed to be much more portable, with a built in battery and an Android app that you connect to via Bluetooth. This makes it very useful for taking out in the field as no laptop is required to use it, just a phone or tablet. The PandwaRF can be used just like a YardstickOne when plugged into a PC however.
We should also clarify that CC1111 based devices like the PandwaRF and YS1 are not classed as SDRs. Rather they are RF transceiver chips that can demodulate, decode and transmit a fixed set of digital modulation schemes, such as OOK/ASK, 2-FSK, 4-FSK, GFSK, and MSK. While these devices are not able to receive or transmit any arbitrary signal like an SDR, they make reverse engineering, analysis, replay attacks, brute force attacks etc much simpler for common modulation schemes compared to using an SDR for the same purpose.
Early on in the year PandwaRF sent us a sample of their device for review. Unfortunately during that time their Android software was extremely buggy and we were simply unable to use the device properly. Others reported similar troubles on forums and blog comments. However fast forward to today and it now seems that the Android software is stable and functioning properly.
We first tested the PandwaRF on a simple task which was a replay attack. The goal was to record the signal of a cheap wireless RF alarm, and see if we could replay it back. The wireless alarm is controlled with a keyfob.
First we used the Spectrum Analyzer tool in the PandwaRF app to try and get the frequency of the keyfob. The Spectrum Analyzer tool allows you to see about 1.2 MHz of bandwidth. We assumed the signal would be around 433 MHz. After pressing the button a few times the peak showed up at about 433.9 MHz on the spectrum analyzer. The refresh rate of the spectrum analyzer is quite low, so if the signal is not continuous it’s possible to miss the signal, which is we why we had to try several presses before the signal showed. A standard SDR like an RTL-SDR might be better for this initial frequency searching. We confirmed the frequency to be at 433.893 MHz on an RTL-SDR blog V3.
Next we switched to the RX/TX tool. Here you can enter the frequency of interest and set the expected modulation. We know that this device is ASK/OOK modulated, so we chose this setting. You also need to set the data rate. If you don’t know this value then the app has a data rate measuring tool. So we just pressed on the Measure button, and then pressed a button on the remote until it converged to a data rate of 5,121.
Next you need to set the ‘desired payload’. This is how many bytes long the packet is and determines how long the capture is. As we were unsure we simply set it to 250 bytes to ensure that a longer capture was taken. The PandwaRF will keep on receiving until it receives the desired payload of 250 bytes or is stopped manually. Setting it longer allows us to capture a longer signal, and ensure that the replayed signal is received. For this alarm device it is okay if the same signal is played multiple times in a short time frame.
The final setting is the RX Frame length. This determines how many bytes will be captured before transferring the data to Android. So for example, if you set the desired payload to 100 Bytes, and the RX Frame length to 52 bytes, then in total you will capture 104 Bytes of data. The PandwaRF can only transfer in 14, 33, 52, 71 or 90 bytes, so select one that is closest to a multiple of your desired payload.
Finally we pressed on ‘Sniff’ and pressed the ‘bell’ button on the remote. The PandwaRF detected the signal and recorded the data. Now pressing Xmit replays the signal successfully causing the alarm bell to sound.
Brute Force Attack
The PandwaRF can also be used as a brute forcing tool. With cheap alarms the alarm code is relatively short, so can be brute forced in a matter of minutes. The PandwaRF already had a preset mode for our cheap Forecum door alarm, so we simply selected this mode and started the brute force. It gave an estimated brute force time of 28 minutes, which is the time it takes to run through every possible alarm code.
The PandwaRF app currently supports the Idk and PT2262 chipsets, as well as some models of DIO, Extel and Forecum house alarms. If the device that you want to brute force is not yet in their database, then you’ll probably need to do some analysis first on the PC with an SDR. Software like Universal Radio Hacker and DSpectrumGUI are good tools for this. Once you know the structure of the data, then you can program PandwaRF to perform the brute force attack.
Note that their newer ‘PandwaRF Rogue’ product is supposed to be significantly faster at brute forcing. For example the Android software gives us a estimated duration of 28 minutes with the standard PandwaRF, and only 3 minutes with the Rogue.
The Rogue is also able to brute force 32 bit codewords with zero delay in between transmissions. The standard PandwaRF has a minimum delay of 100 ms which can really slow things down. It also allows for function mask bit skipping, enable more brute force patterns and can split the brute force attempt into several steps. Also as we’ve seen from their videos the Rogue has more pre-set commercial devices built into its app.
So if brute forcing is your main use for the PandwaRF then it seems to make sense to get the Rogue. Unfortunately the Rogue is significantly more costly, coming in at 990 euros, vs 145 euros for the standard PandwaRF. Of course you could still use the standard PandwaRF on a PC with tools like rfcat to perform a faster brute force attack as well, just like you would with a YardstickOne.
The code runs on the Android device and not on the PandwaRF, so each RF command generates a bluetooth transfer which can be quite slow. They write this is why they have created a specific brute force implementation in the app, so that they can run their native brute force code on the PandwaRF itself, which is must faster than transferring the RF command for every brute force step.
Overall the PandwaRF is a very handy tool for doing replay and brute force attacks while in the field. It can also be converted back into a PC based CC1111 device, like a Yardstick One simply by plugging it into a computer with a USB cable so you’re not missing out on that functionality either.
Compared to the Yardstick One the cost is a bit more, with the Yardstick One costing $99 USD at most outlets, and the PandwaRF costing 145 Euros (~$173 USD). So it is probably only really worth it if you are doing field testing.
That said, now that the PandwaRF software seems stable it is an excellent tool for investigating wireless devices in a simpler way compared to with an SDR. An SDR is still much more powerful, but tools like this simplify the process significantly. The best set of tools for reverse engineering would be a SDR combined with a device like this.
In the future it looks like they plan to implement new features such as De Bruijn (OpenSesame) attack’s and rolling code attacks and we look forward to testing those out.
Over on his YouTube channel Tysonpower (aka Manuel) has uploaded a video showing how he was able to use his PlutoSDR to perform some simple replay attacks that open his garage and car doors. To do this he records the signal from the wireless keyfobs with the PlutoSDR, and then uses a GNU Radio program to replay that signal again at a later time. From the tests he concludes that the PlutoSDR can be a great cheaper alternative to a HackRF, with the PlutoSDR coming in at $100 vs $300 for the HackRF.
To get around the rolling code security on his car he records the keyfob with the PlutoSDR while it’s out of the wireless range of his car, so that the rolling code will not be invalidated. Then later closer to the car the PlutoSDR is used to replay the car keyfob signal which opens the door.
Note that Tysonpower’s video is narrated in German, but English subtitles are available through the YouTube interface.
In 2015, artist Ai Weiwei was bugged in his home, presumably by government actors. This situation raised our awareness on the lack of research in our community about operating and detecting spying microphones. Our biggest concern was that most of the knowledge came from fictional movies. Therefore, we performed a deep study on the state-of-the-art of microphone bugs, their characteristics, features and pitfalls. It included real life experiments trying to bug ourselves and trying to detect the hidden mics. Given the lack of open detection tools, we developed a free software SDR-based program, called Salamandra, to detect an locate hidden microphones in a room. After more than 120 experiments we concluded that placing mics correctly and listening is not an easy task, but it has a huge payoff when it works. Also, most mics can be detected easily with the correct tools (with some exceptions on GSM mics). In our experiments the average time to locate the mics in a room was 15 minutes. Locating mics is the novel feature of Salamandra, which is released to the public with this work. We hope that our study raises awareness on the possibility of being bugged by a powerful actor and the countermeasure tools available for our protection.
The paper first outlines the history of microphone bugs and tries to dispel some of the myths about them which originate from movies and other fictional sources. They then perform a survery of the current state-of-the-art microphone bugging techniques, and later go on to discuss the development of Salamandra and some experiments that they performed with it.
In their experiments they show that the Salamandra software and RTL-SDR is able to outperform a commercial bug detector. They also performed several real world simulations where one researcher would hide a bug in a room, and then another would have to use Salamandra to determine if a bug was present, and then locate it using the location feature of Salamandra. They concluded that Salamandra was a very useful tool as they were able to detect the location of the bugs in under 40 minutes in 4/5 tests.
Bitcoin is the worlds first and most popular digital currency. It is steadily gaining in value and popularity and is already accepted in many online stores as a payment method. In order to use Bitcoin you first need to download a large database file called a ‘blockchain’, which is currently at about 152 GB in size (size data obtained here). The blockchain is essentially a public ledger of every single Bitcoin transaction that has ever been made. The Bitcoin software that you install initially downloads the entire blockchain and then constantly downloads updates to the blockchain, allowing you to see and receive new payments.
Blockstream is a digital currency technology innovator who have recently announced their “Blockstream satellite” service. The purpose of the satellite is to broadcast the Bitcoin blockchain to everyone in the world via satellite RF signals, so that even in areas without an internet connection the blockchain can be received. Also, one problem with Bitcoin is that in the course of a month the software can download over 8.7 GB of new blockchain data, and there is also the initial 152 GB download (although apparently at the moment only new blocks are transmitted). The satellite download service appears to be free, so people with heavily metered or slow connections (e.g. 3G mobile which is the most common internet connection in the third world/rural) can benefit from this service as well.
The service appears to be somewhat similar to the first iteration of the Outernet project in that data is broadcast down to earth from satellites and an R820T RTL-SDR is used to receive it. The blockstream satellite uses signals in the Ku band which is between 11.7 to 12.7 GHz. An LNB is required to bring those frequencies back down into a range receivable by the RTL-SDR, and a dish antenna is required as well. They recommend a dish size of at least 45 cm in diameter. The signal is broadcast from already existing satellites (like Outernet they are renting bandwidth on existing satellites) and already 2/3 of the earth is covered. The software is based on a GNU Radio program, and can be modified to support any SDR that is compatible with GNU Radio. They write that the whole setup should cost less that $100 USD to purchase and set up.
To set it up you just need to mount your satellite antenna and point it towards the satellite broadcasting the signal in your area, connect up your LNB and RTL-SDR and then run the software on your PC that has GNU Radio installed.
You sell goats in a small village. A customer wants to buy a goat, but you have no banks so people have put their money into bitcoin. Your customer goes to the village center which has a few computers hooked up to the internet. He sends you payment then comes to get his goat. You don’t have internet near your goat farm, but you’re connected to the satellite so you can see he sent you payment and you give him his goat.
Or, you live in an area that caps your bandwidth. You want to run a full node, but downloading blocks eats away at your cap. Connecting to a satellite reduces your bandwidth usage.
Or, you’re using an air gapped laptop to sign transactions from your wallet for security reasons. You can now connect that laptop to the satellites so your laptop can generate its own transactions without connecting to the internet.
Or, your internet connection is terrible. You can usually broadcast transactions since they’re small, but downloading blocks and staying in sync with the blockchain is literally impossible. Connect to a satellite and now it’s simple.