Reddit user [SDR_LumberJack] writes how he was recently featured in his local newspaper [Part2] in Ontario, Canada thanks to his efforts in helping to hunt down the cause of an RF deadspot with an SDR. He began his journey by reading a story in his local newspaper called the [Windsor Star]. The story was about locals having found a ‘dead-spot’ for car key-fobs. In the dead-spot key-less cars wouldn’t start, key-fobs wouldn’t unlock cars, and alarms would go off.
Being intrigued by the story [SDR_LumberJack] investigated by driving around with an RTL-SDR, HackRF and a laptop running SDR#. Eventually he found that there was what appeared to be a WBFM Broadcast radio station interfering at 315 MHz. This frequency happens to fall into the ISM radio band that used by car remotes and key-fobs. The exact source of the interference hasn’t been nailed down just yet though.
While it’s possible a broadcast station is at fault it is also possible that his SDR was just overloading, causing broadcast FM imaging. Perhaps a WBFM filter could be used to prevent signal imaging that could interfere with the investigation.
Hopefully [SDR_LumberJack] will continue his investigation and we’ll get an update on this story.
If you’re interested, back in 2016 we posted a very similar story about the exact same thing happening at a car park in Brisbane, Australia. The conclusion to that story was that the dead-spot only occurred in particular locations in the car park, and this was due to the shape of surrounding building causing the RF signals to reflect off the walls and distort the signal.
This weeks episode of Hak5 (an information security themed YouTube channel) features Dale Wooden (@TB69RR) who joins hosts Shannon and Darren to demonstrate a zero day vulnerability against Ford keyless entry/ignition. More details about the vulnerability will be presented at this years DEF CON 27 conference, which is due to be held on August 8 - 11.
In the video Dale first demonstrates how he uses a HackRF with Portapack to capture and then replay the signal from a Ford vehicle's keyfob. The result is that the original keyfob no longer functions, locking the owner out from the car. After performing a second process with another keyfob, Dale is now able to fully replicate a keyfob, and unlock the car from his HackRF.
Dale explains that unlike the well known jam-and-replay methods, his requires no jamming, and instead uses a vulnerability to trick the car into resetting the rolling code counter back to zero, allowing him to capture rolling codes that are always valid. Dale also notes that he could use any RX capable SDR like an RTL-SDR to automatically capture signals from over 100m away.
The vulnerability has been disclosed to Ford, and the full details and code to do the attack will only be released at DEF CON 27, giving Ford enough time to fix the vulnerability. It is known to affect 2019 Ford F-150 Raptors, Mustangs and 2017 Ford Expeditions, but other models are also likely to be vulnerable.
The video is split into three parts. In part 1 Dale demonstrates the vulnerability on a real vehicle and in part 2 he explains the story behind his discovery, how he responsibly disclosed the vulnerability to Ford and how to reset the keyfob yourself. Finally in part 3 Darren interviews Dale about his experiences in the RF security field.
Over on YouTube user ModernHam has uploaded a video showing how to perform a replay attack on a car key fob using a Raspberry Pi running RPiTX and an RTL-SDR. A replay attack consists of recording an RF signal, and then simply replaying it again with a transmit capable radio. RPiTX is a program that can turn a Raspberry Pi into a general purpose RF transmitter without the need for any additional hardware.
The process is to record a raw IQ file with the RTL-SDR, and then use RPiTX V2's "sendiq" command to transmit the exact same signal again whenever you want. With this set up he's able to unlock his 2006 Toyota Camry at will with RPiTX.
We note that this sort of simple replay attack will only work on older model cars that do not use rolling code security. Rolling code security works by ensuring that an unlock transmission can only be utilized once, rendering replays ineffective. However, modern rolling code security systems are still susceptible to 'rolljam' style attacks.
In the video below ModernHam goes through the process from the beginning, showing how to install the RTL-SDR drivers and RPiTX. Near the end of the video he shows the replay attack in action.
Unlock Cars with a Raspberry Pi And SDR - Replay attack
The attacker utilises a device with full-duplex RF capabilities (simultaneous transmit and receive) to produce a jamming signal, in order to prevent the car from receiving the valid code from the key fob. This is possible as RKEs are often designed with a receive band that is wider than the bandwidth of the key fob signal (refer Figure 3, right). The device simultaneously intercepts the rolling code by using a tighter receive band, and stores it for later use. When the user presses the key fob again, the device captures the second code, and transmits the first code, so that the user’s required action is performed (lock or unlock) (Kamkar, 2015). This results in the attacker possessing the next valid rolling code, providing them with access to the vehicle. The process can be repeated indefinitely by placing the device in the vicinity of the car. Note that if the user unlocks the car using the mechanical key after the first try, the second code capture is not required, and the first code can be used to unlock the vehicle.
In his demonstrating the attack he uses the RTL-SDR to initially find the frequency that they keyfob operates at and to analyze the signal and determine some of it's properties. He then uses a Raspberry Pi running RPiTX to generate a jamming signal, and the YardStick One to capture and replay the car keyfob signal.
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.
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.
[EN subs] Hacken eines Autos und Garagentors – AdalmPluto Replay Attacke