Tagged: hackrf

Rolling-Pwn: Wireless rolling code security completely defeated on all Honda vehicles since 2012

Back in May we posted about CVE-2022-27254 where university student researchers discovered that the wireless locking system on several Honda vehicles was vulnerable to simple RF replay attacks. A replay attack is when a wireless signal such as a door unlock signal is recorded, and then played back at a later time with a device like a HackRF SDR. This vulnerability only affected 2016-2020 Honda Civic vehicles which came without rolling code security.

Recently a new vulnerability discovered by @kevin2600 that affects ALL Honda vehicles currently on the market (2012-2022) has been disclosed. The vulnerability is dubbed 'Rolling-PWN' (CVE-2022-27254) and as the name suggests, details a method for defeating the rolling code security that exists on most Honda vehicles. Rolling code security is designed to prevent simple replay attacks, and is implemented on most modern vehicles with wireless keyfobs. However @kevin2600 notes the following vulnerability that has been discovered:

A rolling code system in keyless entry systems is to prevent replay attack. After each keyfob button pressed the rolling codes synchronizing counter is increased. However, the vehicle receiver will accept a sliding window of codes, to avoid accidental key pressed by design. By sending the commands in a consecutive sequence to the Honda vehicles, it will be resynchronizing the counter. Once counter resynced, commands from the previous cycle of the counter worked again. Therefore, those commands can be used later to unlock the car at will.

The vulnerability has been tested on various Honda vehicles with HackRF SDRs, and this seems to indicate that all Honda vehicles since 2012 are vulnerable.

Although no tools have been released, the vulnerability is simple enough and we've already seen people replicate results.

The story of Rolling-Pwn has already been covered by magazines and news organizations such as TheDrive, Vice, NYPost, and FoxLA.

It should be noted that when the previous replay attack vulnerability was highlighted, Honda released a statement noting that it has no plans to update its older vehicles. It is likely that Honda will not issue updates for this vulnerability either. It is possible that this vulnerability extends beyond just Honda vehicles too.

LimeSDR 2.0 Mini Now Crowdfunding, Standard LimeSDR Discontinued

Back in March we posted about the LimeSDR Mini 1.0 becoming end of life due to component shortages, and a slightly upgraded LimeSDR Mini 2.0 was being planned. The LimeSDR Mini 2.0 has just been released for preorder over on the CrowdSupply crowdfunding website with a price of US$399 + shipping. The first 1000 units are expected to be ready within 14-weeks, with subsequent batches out at 32-weeks.

The new pricing is at quite a premium over the original LimeSDR Mini which released in 2017 for US$139, and the standard LimeSDR which released in 2016 for US$249. However we of course must to take into account the extreme inflation of electronic parts pricing that has occurred over the past few years.

Lime Micro have also noted that the standard LimeSDR has also now been discontinued due to the same supply shortages. The standard LimeSDR had 2x2 RX/TX channels and was capable of a bandwidth of up to 61.44 MHz. In comparison, both versions of the LimeSDR Mini are a 1x1 channel product with 40 MHz of bandwidth.

The LimeSDR Mini 2.0 is almost identical to the LimeSDR Mini 1.0, both still making use of the LMS7002 RF transceiver as the main chip and using the same overall design. The only change is an upgrade to the FPGA, which replaces the Intel MAX 10 16k logic gate FPGA with a significantly more capable Lattice ECP5 44k logic gate FPGA.

Given the new pricing, people on the lookout for a new hacker/research/experimenter SDR in this price range might want to consider this brief comparison to find the best suited SDR for your needs:

  • LimeSDR Mini 2.0 - US$399
    1x1 channels, 40 MHz bandwidth, 10 MHz to 3.5 GHz, 12-bits.
     
  • HackRF One - US$330 (~$150 clones)
    1x1 channels (half-duplex), 20 MHz bandwidth, 1 MHz to 6 GHz, 8-bits.
     
  • PlutoSDR - US$229.18
    1x1 channels, 20 MHz bandwidth, 325 MHz to 3.8 GHz, 12-bits.
     
  • bladeRF 2.0 Micro xA4 - US$540
    2x2 channels, 61.44 MHz bandwidth, 47 MHz to 6 GHz. 12-bits.
The LimeSDR Mini 2.0

Opening and Starting Honda Civic Vehicles with a HackRF Replay Attack

A few months ago University student Ayyappan Rajesh and HackingIntoYourHeart reported cybersecurity vulnerability CVE-2022-27254. This vulnerability demonstrates how unsecure the remote keyless locking system on various Honda vehicles is, and how it is easily subject to very simple wireless replay attacks. A replay attack is when a wireless signal such as a door unlock signal is recorded, and then played back at a later time with a device like a HackRF SDR.

Most car manufacturers implement rolling code security on their wireless keyfobs which makes replay attacks significantly more difficult to implement. However, it appears that Honda Civic models (LX, EX, EX-L, Touring, Si, Type R) from years 2016-2020 come with zero rolling code security:

This is a proof of concept for CVE-2022-27254, wherein the remote keyless system on various Honda vehicles send the same, unencrypted RF signal for each door-open, door-close, boot-open and remote start(if applicable). This allows for an attacker to eavesdrop on the request and conduct a replay attack.

In the videos on the GitHub demonstration page they show a laptop with GNU Radio flowgraph and a HackRF SDR being used to turn the engine of a Honda civic on, and to lock and unlock doors.

Various news agencies reported on the story, with "The Record" and bleepingcomputer contacting Honda for comment. Honda spokesperson Chris Martin replied that it “is not a new discovery” and “doesn’t merit any further reporting.” further noting that "legacy technology utilized by multiple automakers” may be vulnerable to “determined and very technologically sophisticated thieves.”. Martin went on to further note that Honda has no plans to update their vehicles to fix this vulnerability at this time.

Laptop and HackRF used to turn on a Honda Civic Engine via simple Replay Attack.

In the past we've seen similar car hacks, but they have mostly been more advanced techniques aimed at getting around rolling code security, and have been difficult to actually implement in the field by real criminals. This Honda vulnerability means that opening a Honda Civic could be an extremely simple task achievable by almost anyone with a laptop and HackRF. It's possible that a HackRF and laptop is not even required. A simple RTL-SDR, and Raspberry Pi with the free RPiTX software may be enough to perform this attack for under $100.

More information about the hack can be found on HackingIntoYourHeart's GitHub page. He writes:

Recording the "unlock" command from the target and replaying (this works on most if not all of Honda's produced FOBs) will allow me to unlock the vehicle whenever I'd like to, and it doesn't stop there at all On top of being able to start the vehicle's ENGINE Whenever I wished through recording the "remote start", it seems possible to actually (through Honda's "Smart Key" which uses FSK) demodulate any command, edit it, and retransmit in order to make the target vehicle do whatever you wish.

Controlling a Toy RC Car with a HackRF

Over on his blog Radoslav has created a post showing how he has used a HackRF to wirelessly control a toy RC car by reverse engineering the wireless control protocol, and generating the control signals in a C++ program.

Having already created the rf-car HackRF RC car control software on GitHub a few years ago, Radoslav was easily able to modify it for a new RC car that his daughter received. The process was to simply look up the FCC data on it, finding that it operated with 2.4 GHz and used GFSK modulation. He then used the Inspectrum signal analysis tool to determine the bit strings used to control the car. Finally using, his C++ interface to the HackRF he implemented the new bit string and GFSK modulation.

The video below demonstrates Radoslav controlling the RC car with the keyboard on his laptop.

Controlling 2.4GHz FSK car with HackRF

In the past we've posted about another project that also used a HackRF and computer to control a RC drift car, and another project that used the RPiTX software to control an RC toy car with GNU Radio and a Raspberry Pi.

[Project also seen on Hackaday]

Tesla Charging Ports Opened with HackRF Replay Attack

The charging port on Tesla electric vehicles is protected via a cover that can be opened by charging stations via a wireless signal transmitted at 315 MHz. It turns out that the command to open the port is totally without any security. This means it's possible to record or recreate the signal, and play it back anywhere using a transmit capable SDR device like a HackRF.

Twitter user @IfNotPike has done just that, managing to open the Tesla charging port using a handheld HackRF with Portapack setup. If you cannot record the signal, a repo hosting a valid signal file is available on GitHub from jimilinuxguy. Interestingly jimilinuxguy notes "The range for this is INSANE. I was able to perform this from VERY far away." and the same signal can be used to "open any and all Tesla vehicle charging ports in range"

Fortunately for Tesla owners, the level of damage a malicious party could cause through the charging port is limited, since the charging port is not active until a correct charging cable is connected. It also seems that the charging port on most models will automatically close after some time if no charger is connected.

Tesla Charging Port Opened with HackRF and Portapack | Credit: @IfNotPike

Receiving Analog TV from Turkmenistan Unintentionally Bouncing off a Russian Military Satellite

Over on Twitter @dereksgc has been monitoring the 'Meridian' communications satellites, which are Russian owned and used for civilian and military purposes. The satellites are simple unsecure repeaters, meaning that actually anyone with the hardware can transmit to them, and have their signal automatically rebroadcast over a wide area. This has been taken advantage of recently by anti-Russian invasion war activists who have been trolling the satellite with SSTV images of the Ukrainian flag, as well as audio.  

Apart from intentional abuse, a side effect of being an open repeater is that sometimes the satellite can pick up powerful terrestrial signals unintentionally, such as analogue broadcast TV from Turkmenistan. Over on his blog, @dereksgc has written up an excellent post documenting the background behind this finding, his entire setup involving the hardware he's using and how he's aligning with the satellite, and what software he is using to decode the TV signal. In his hardware setup he notes that he uses a HackRF, but that a RTL-SDR would suffice.

SignalsEverywhere: Review of SDR++ on Android

In our last post we mentioned that a 'pre-release' public version of SDR++ for Android was recently released. Now over on the SignalsEverywhere YouTube channel Sarah has uploaded a new video where she reviews and demonstrates the new SDR++ Android App. 

In the video Sarah demonstrates how to connect and start a SDR, shows SDR++ in action, then tests listening to NOAA weather audio reports, Inmarsat reception via the bias tee support, P25 and broadcast FM. She also shows how it's possible to use the split screen multitasking feature on Android to send audio from SDR++ into APRSdroid for APRS decoding.

She goes on to show how to fine tune the screen PPI resolution for different sized devices, and how to set up multi-VFO listening on the HF bands. Next, she compares the audio decoding quality between SDR++, SDRTouch and RFAnalyzer. Finally she shows that a HackRF running at a wideband 20 MHz of bandwidth can run smoothly. 

The Android SDR App That Beats Them All! Supports RTL-SDR Airspy HackRF and Many More!

Turbine: Capture and Stream all Frequencies in a Trunked Radio System with a HackRF

Over on Reddit we've discovered an interesting program called 'Turbine' that has recently been open sourced by the author. This program connects to a wideband capable SDR such as a HackRF and captures and streams all frequencies in a trunked radio system. Users can then browse the recordings online. On his reddit post u/norasector introduces Turbine, and his application for it called 'NoraSector'.

I am open sourcing the SDR code for NoraSector, which currently captures and streams the radio systems for both King and Snohomish County, WA. It uses a HackRF One to capture every channel concurrently, and can even process multiple systems at the same time, provided they are within the same bandwidth that is captured by the SDR and there's adequate reception. I plumb the output through a WebRTC streaming infrastructure I built to stream audio to clients over the web with very low latency. My goal was to give complete access to an entire system to anyone over the web, just as they would have if they were using a handheld scanner, and with comparable latency.

Turbine is a bit different other SDR software out there. It's written entirely in Go, and was built explicitly to only use a single SDR rather than bonding multiple SDRs together.

Turbine works by tuning known control frequencies and then tuning all voice frequencies it learns from them. Voice transmissions are encoded using the Opus audio codec for compatibility with WebRTC and blasted out as frames over UDP. It also includes a functional-but-janky built-in visualization web server to look at each stage of the DSP pipeline for each frequency, which was crucial for debugging as I was building it.

Right now, it only supports legacy Motorola SmartZone systems (which is what is used near me), but it shouldn't be a large lift to make it support P25. The code is heavily influenced by op25 and GNURadio (and in some places just outright copying them). I built it in Go because a) it's what I'm most familiar with and b) the sheer density of GNURadio made it hard for me to piece things together how I wanted. Go's concurrency model is a natural fit for doing many concurrent operations on the byte stream, and I haven't had issues with garbage collection pausing execution in a detrimental way.

Turbine isn't intended for use with lower sample rate SDRs like the RTLSDR. It has a driver for it, but doesn't support bonding multiple SDRs together. If an entire system fits within the 2MHz sample rate, it would probably be fine. You should be able to fire it up with a RTLSDR but it will not be able to capture very much. It currently only officially supports the HackRF One, but adding other SDRs should be relatively trivial. Note that the HackRF I am using is the model with the upgraded TCXO, as I found that the built-in oscillator was not accurate enough.

Turbine has only been tested to run on Linux and is very CPU-intensive; the production radio runs on a dedicated i7-11700k 8c/16t CPU and consumes about 60% of all cores decoding both systems. There are some potential optimizations that could be made that would lower CPU consumption during periods of low activity, but I built it for the worst case of having to encode every voice frequency at once.

The usual disclaimers about OSS apply. I hope you find it interesting or perhaps useful, and maybe portions can be adapted so Go can be used more in SDR projects.

There have been similar projects in the past like radiocapture-rf, scaneyes, and broadcastify calls, but Turbine looks like one of the most comprehensive.

Norasector: An implementation of the Turbine Trunk Recording software