RKE: How To Hack A Car

I've always found cybersecurity to be more interesting when implications reflect in the "real world" and this is the reason hacking physical devices is fun to me. Well, it turns out that the more the hack is controversial, the funnier it is to carry out!  For this reason I got into remote controlled devices hacking, and in particular into car remotes hacking. A while ago I got all the hardware needed to attempt attacking these devices, so I could finally attempt some attacks.

In this article I want to share the theory of how these devices work, what are their weaknesses and how we can exploit them, both in theory and in practice.

Before we start, a few words from our sponsor: your sense of ethics.
We all know that hacking other people without their permission is bad, but entering in someone's vehicle without their permission is REALLY bad. So please use the information you get from this article to learn how these systems work and not for unethical reasons, alright

How to hack a car open (in theory)

RKE or Remote Keyless Entry systems are what's commonly referred to as key fobs or car remotes. Simply put, it's a radio control capable of making a car perform actions such as opening or closing the doors, the trunk, so on and so forth. The functioning of car remotes is pretty straightforward: they generate a radio signal containing an authentication code and some bits representing the command the car has to execute, the car receives it and if the authentication code can be validated, the car executes the command, it's simple! Or is it?

Fixed codes and replay attacks

As mentioned there are two parts of a code sent by a remote: an authentication code and a code representing the command to be executed. Cars used to have a unique authentication code associated with them and the key would send such code along with a command code to make the car perform a certain action. The image below shows how the communication works:

This system is called a "fixed code" system, since the unique authentication code never changes. This system is trivial to implement but it has an important flaw: it's vulnerable to replay attacks. This translates to the fact that an attacker could place a radio receiver near a car and capture the radio signal sent by the car's remote when the owner operates it. Once the signal is captured it can simply be replayed and the car would open. You can see an example in the image below:

While it requires specialized tools, the attack is relatively easy to carry out successfully and it can also be achieved with extremely cheap hardware. Keep in mind that while cars don't really use this mechanism anymore, some simpler devices still do (you can find an analysis of one of these remotes here).

Bruteforce attacks on fixed codes

For the sake of completeness, it's worth mentioning that, if the signal archetype is known (modulation, code length, presence of preamble/trailing bits, ...) it would be possible to recover the fixed code through a bruteforce attack. Depending on the length of the code and on the hardware used, it can be more or less practical to carry out this attack.

Instead of a "raw" bruteforce attack, it could potentially be much faster to bruteforce the code using a De Bruijn sequence.

A De Brujin sequence is, the shortest stream of bits containing every possible code of a certain length made from a specific alphabet. An ordinary bruteforce attack requires the attacker to send incremental codes sequentially attempting every possible code exhaustively, using a De Brujin sequence it is possible to generate a stream of bits that will contain every possible code in the alphabet once and only once.

To make it easier to understand this attack, here's a practical representation of a De Brujin sequence:

   {0  0  0  0} 1  1  1  1  0  1  1  0  0  1  0  1
    0 {0  0  0  1} 1  1  1  0  1  1  0  0  1  0  1
    0  0 {0  0  1  1} 1  1  0  1  1  0  0  1  0  1
    0  0  0 {0  1  1  1} 1  0  1  1  0  0  1  0  1
    0  0  0  0 {1  1  1  1} 0  1  1  0  0  1  0  1
    0  0  0  0  1 {1  1  1  0} 1  1  0  0  1  0  1
    0  0  0  0  1  1 {1  1  0  1} 1  0  0  1  0  1
    0  0  0  0  1  1  1 {1  0  1  1} 0  0  1  0  1
    0  0  0  0  1  1  1  1 {0  1  1  0} 0  1  0  1
    0  0  0  0  1  1  1  1  0 {1  1  0  0} 1  0  1
    0  0  0  0  1  1  1  1  0  1 {1  0  0  1} 0  1
    0  0  0  0  1  1  1  1  0  1  1 {0  0  1  0} 1
    0  0  0  0  1  1  1  1  0  1  1  0 {0  1  0  1}
    0} 0  0  0  1  1  1  1  0  1  1  0  0 {1  0  1 ...
... 0  0} 0  0  1  1  1  1  0  1  1  0  0  1 {0  1 ...
... 0  0  0} 0  1  1  1  1  0  1  1  0  0  1  0 {1 ...

In this example, it is possible to see how every possible 4 bit code is contained in a single stream of 16 bits.

Of course this attack only work in specific circumstances, in particular the receiver needs to use shift registers to read the incoming signal. Shift registers can be imagined as a fixed sized memory that handles data in a FIFO style, pushing out of the memory older bits to make space for newer ones. The following GIF explains it pretty well:

Seeing this animation makes it easier to understand why De Brujin sequences and shift registers work so well together.

Another requirement for this attack to work is that the communication doesn't use any type of preamble or trailing bits, as it would make the sequence useless.

Rolling codes

Luckily, cars today are a bit more secure than they used to be because "rolling code" systems are widely used. With these systems, instead of reusing the same code every time, the key will send a different code each time the button is pressed. If you try to replay a captured signal to a car that uses a rolling code system, the car will simply ignore it.

For the sake of simplicity we can imagine the car and the associated key to share an ordered list of valid codes that will be invalidated, one by one, once used.

Implementations may vary, but each key and car will have a counter, updated every time a signal is sent/received, and there will likely be a pseudo-random number generator (PRNG) algorithm that uses the counter and a cryptographic key, shared by the car and its key, as a seed to generate the next code. Here you can see an example of how this process works:

This approach makes it really hard for an attacker to generate a "future code" and makes it impossible to re-use codes that's been already received by the car, making a huge step forward in respect of a fixed code approach.

There is a problem with this approach though: the key and the car work independently, so if the key sends a signal outside of the car range (increases the counter, and marks the current code as used in its code list), it goes "out-of-sync" as the car would still expect the code the key just marked as used, in the next signal.

To solve this problem, instead of considering only one code as valid, the car maintains a range of valid codes (n, n+1, ..., n+k) updated each time a signal is received. If the key sends multiple signals outside the car's range and goes out of the range of valid codes, the next signal containing a valid code outside of the valid range will serve as a re-sync packet and will not make the car carry out any action.

RollJam attack

The mechanism behind rolling codes is pretty secure, but the fact that the key and the car operate independently is a weak spot in the design of this system. As we did before, let's consider the codes used in this scheme, as an ordered list of codes, shared by the key and the car. In a normal scenario the evolution of the code stack would be similar to this:

For each interaction, both the key code stack and the car code stack are in the same state. But as mentioned, the two stacks can go out-of-sync, as shown in the example below:

While the two stacks are now in-sync, this situation is still abnormal, as the next code used will be N+2, but the code N is still valid in the car stack and it will never be used again by the key. The RollJam attack is a technique that forces the key and car code stacks in an out-of-sync state to recover a valid code, that won't be used by the key but that is still acceptable by the car. This attack was originally developed by Samy Kamkar but I believe the weakness was known to researchers before he presented it.

The technique forcefully recreates the scenario in which the key is pressed while out of the car's range. This is achieved using a frequency jammer capable of inhibiting the communication between the key and the car. But jamming is not sufficient to open the car as the valid code is not automatically captured by the attacker, for this reason it is necessary to "sniff" the original communication while jamming in order to retrieve the valid code. In this scenario the attacker acts as a man-in-the-middle proxy. Here's a scheme explaining how the attack is carried out:

While this attack seems trivial to carry out, in practice there are a few obstacles to overcome.

This attack still works on a lot of cars, as it is compatible with most rolling code implementations around, but it is limited in other ways:

• Retrieved valid codes might not last for too long
• Each valid code can be used for one and only one operation on the car
• It might be hard to change the operation carried out by a signal containing a valid code (it requires reverse engineering the signal itself)

Some cars patched this vulnerability with a simple solution: instead of marking only received codes as used, the car can invalidate every code N+K with K lower than the one of the code just received. This way, the retrieved valid code, will be valid only until the next time the key communicates with the car.

Other attacks against RKE

It's worth mentioning that attacks against specific implementation of RKE systems exist.While not as widely applicable, these attacks are usually have a greater impact when compared to RollJam attacks.

Rollback attack

The Rollback attack, presented at Blackhat USA 2022 convention, is a new way to attack rolling code based RKE systems.The researchers behind this technique discovered that certain cars, after receiving two or more (used) consecutive codes in a certain time lapse, it restores a previous state: if an attacker has access to used codes N and N+1 and replays them, the state of the car code stack will be reset in such a way that codes from N+2 onward will be valid again.

In practice, the attack is similar to RollJam because in order to capture consecutive codes an attacker has to use a jammer to inhibit a signal from the key to the car, in order to make the owner press the key button again.

This attack is a lot more versatile than RollJam since it allows an attacker to control the car any time and as many time as needed (since they can reset the car state multiple times). However, depending of the targets, some parameters may vary, such as:  the consecutiveness of the codes replayed, the number of codes replayed ad well the time frame in which such codes are replayed.

In addiction to this, it seems like cars from Asian manufacturers are the most affected by this vulnerability. Tests have been carried out against Honda, Hyundai, Kia, Mazda, Nissan and Toyota cars and depending on the specific rolling code encoder used the cars were safe or vulnerable to specific instances of the attack.The only manufacturer that resulted safe during the research was Toyota.

It's not confirmed, but the documentation of some of the rolling code encoders suggested that this vulnerability is due to a "key fob learning process".

Unoriginal-Rice-Patty (CVE-2019-20626) and Rolling-PWN (CVE-2021-46145)

The following vulnerabilities are specific to Honda cars' RKE systems.

Unoriginal-Rice-Patty

Unoriginal-Rice-Patty is the name of the research/attack behind CVE-2019-20626, the attack itself is basic.Even tough the vehicles affected by the vulnerability use rolling code systems, they are vulnerable to simple replay attack.This demonstrates how modern cars can be vulnerable to very simple attacks.

In addiction, include the possibility to start the engine remotely, allowing the attacker, to open the car and even turn the engine on.

Cars known to be vulnerable are:

• 2009 Acura TSX
• 2016 Honda Accord V6 Touring Sedan
• 2017 Honda HR-V (CVE-2019-20626)
• 2018 Honda Civic Hatchback
• 2020 Honda Civic LXHonda

Rolling-PWN

This technique exploits CVE-2021-46145, while no details have been disclosed on the attack, we know the vulnerability lays in the fact that affected cars accept a sliding windows of codes, and when a specific sequence of commands is presented to the car, the rolling code state in the car gets re-synced to a previous state.

It is impossible to say for sure because details aren't public, but the attack seem to be similar to Rollback attack.

Cars known to be vulnerable are:

• Honda Civic 2012
• Honda X-RV 2018
• Honda C-RV 2020
• Honda Accord 2020
• Honda Odyssey 2020
• Honda Inspire 2021
• Honda Fit 2022
• Honda Civic 2022
• Honda VE-1 2022
• Honda Breeze 2022
• Honda Accord 2021

How to hack a car open (in practice)

Now that we have a good understanding of the security of RKE systems, we can try and attack them in real life. All of the attacks mentioned before are similar to carry out, but the objective of this section will be to attempt a rolljam attack since it's compatible with most vehicles.

Note that we will also talk about jamming radio frequencies, this practice can disrupt the functioning of nearby radio devices and is most likely illegal in your country, so make sure yo know what you are doing if you plan on trying this at home.

Hardware needed

To work with radio signals a transmitter and a receiver are needed.A few options are available:

FS1000A & XY-MK-5V
These modules, often sold in pairs, are an extremely cheap solution (< 5€) to receive and transmit data with radio signals.These devices are pretty simple and they are not ready out of the box. To work with these you'll most likely need a micro controller, like an Arduino and an antenna (DIY is an option).

As one may imagine there are limitations, in fact the devices are limited to 433.92MHz, 315MHz or 330MHz frequencies (depending on the model) and only support OOK.

The devices are widely available and easily supported in the Arduino environment, for this reason they can be useful to have around.

CC1101
The CC1101 is a low cost (5-10€) sub GHz transceiver, it's slightly more expensive than the previous solution but offers better compatibility.  MHz, 387-464 MHz and 779-928 MHz bands, covering every possible commonly used RKE frequency, world wide. It also supports 2-FSK, 4-FSK, GFSK, MSK as well as OOK and flexible ASK modulations.

This integrated circuit is available on a variety of boards, most of which include an antenna and pins to interface with an Arduino or other microcontroller. Given the specifications, this is the device that unsurprisingly handles the Sub GHz system in the flipper zero.

While this device is way more powerful than the previous ones, the software support is not the best and some work needs to be done in certain situations.

Software defined radios (SDR)
These devices are definitely the most expensive solution available (~100-∞€) but also the most generalized and overall better performing. Software defined radios are devices capable of receiving (and sometimes transmitting) radio signals, but use computers to elaborate the data, to keep the hardware design simpler and cheaper.

These devices usually work up to 2GHz at least and offer support for every modulation and encoding (since the elaboration is done via software).

Some SDR are receivers only, some are transceivers. Some are half-duplex, some are full-duplex. Some offer a wider operating frequency ranges than others.Depending on your needs (and money availability), you'll for sure find the perfect SDR. Keep in mind that RKE experiments focus on sub GHz frequencies, so nothing too fancy is needed as long as you can transmit a signal.

These are the devices I've experimented with, but I'm sure a many more are suitable for the job.

In my experiments I've used an HackRF One with portapack H2 (mayhem firmware) and a FS1000A to carry out the attack.

Attack scenario and setup

To carry out a RollJam attack we will need to be able to jam the RKE frequency and simultaneously sniff the signal sent by the key.

It could theoretically be possible to do that with a full-duplex transceiver, but since the HackRF One is half-duplex, I created a frequency jammer to take care of the jamming part. The jammer, uses an extremely simple design featuring an ESP32 board (for Wi-Fi control) and an FS1000A as RF transmitter. The project called 433mhz_jam, is available on github. I also used a battery pack to power the device, so it's remote controlled and throwable. This allows for a better flexibility and to work real time on the attack instead of automating the process.If you don't want to build a jammer yourself, you can use another car key working on the same frequency to disturb the signal, or even an HAM radio (but the transmission power in this case would be an overkill and would probably render impossible any sniffing effort).

For context, here's what the jam signal looks like in my setup:

And here's how a jammed signal from the key looks like:

Now, in the original RollJam attack you'd need to jam a specific frequency while you sniff on a frequency close by, where the original signal is repeated (because of harmonics, but that's out of the scope of this article). Using this approach results may vary greatly, mostly because a cheap jammer is not capable of blocking out one specific frequency and you would need to use a band-pass filter to achieve that.

For this reason I "developed" a slight variation of this attack I like to call *RollDumb*, because it's simpler yet surprisingly effective.

Since the jammer device I created is throwable and remote controlled, I can place it right by the car I'm trying to attack, so the jamming signal is received very strongly by it. Since the power of the jammer is not too strong, a few meters away the signal power is greatly reduced.

Now I can place my sniffer away from the car, in a position where it can easily receive the car key signal on the same frequency I'm jamming.

I feel like this variation of the attack is a bit more realistic, generalized and way easier to carry out automatically or by an attacker in real time. The only reason I feel this way is because to carry out a RolllJam attack, extensive research and tests on the exact car model are to be carried out before an attack can be attempted in real life, while requirements can be more lax in a RollDumb attack since you'd only need to figure out the key fob frequency.

Demo and conclusions

Now that I've explained how the whole attack works, a demo is mandatory:

Needless to say that when the car opens it's incredibly satisfactory.

Well, that said, it's been fun experimenting with opening cars, I've attempted this technique on multiple vehicles and I have to say that once you get a good grasp of it, it's easily reproducible and effective (or at least it was in my country since most, if not all the key fobs work at 433.92 MHz). A basic knowledge of radio transmissions is required, but I have to say good tools also play a big role in these types of attack.

Now you know how to hack your car open, thanks for reading!