Grand Theft Auto – RF Locks Hacking Flipper-Zero Edition Part 2

0x00. INTRODUCTION

Previously from part1, we have looked at some common methods for hacking fixed-code RF Locks, such as signal jamming, replay, and brute-force attack. In part2, we are going to look at more advanced techniques to hack the rolling codes of RF Locks. This series of articles serves as a beginner’s RF lock system hacking journey, performing lock hacking with Flipper-Zero and other RF hacking tools. I hope each case study will help people get a better idea of what they would need for hacking RF locks.

0x01. PROPRIETARY ENCRYPTION 

In part1 we mainly target RF locks that rely on fixed-code. Fixed-code locks are vulnerable to replay attack by design. One solution to prevent replay attacks is to implement a so-called rolling codes mechanism. For example, the keyfob and the car synchronized with the same rolling codes algorithm. As the codes change with each use, we will not be able to predict the next sequence of rolling code. The car will not accept the command until the rolling codes is valid, so a simple replay attack will not work.

When it comes to designing a secure cryptosystem, people always say we should never use untested proprietary encryption algorithms in our products. However, there are always some “smart” people trying to challenge this statement. Let's take this commercial RF remote control lock as an example. What makes it very eye-catching is the advertising terms, such as the lock is use a “US military grade of rolling code” chip. What could possibly go wrong then?

As always, we can fire up our URH with HackRF and capture some unlock signals as sample data to reverse engineer. Of course, just to be sure we can try the replay attack first. However, the lock did not respond, indicating that a rolling codes mechanism was indeed applied.

We need to go back and analyze those unlock samples. For the sake of easy comparison, we view the data as Hex mode and decoding the data as Manchester. We soon found some interesting rolling code flaws; every unlock command only randomly changes at bytes 15th, 31st, and 47th, all other bytes remain the same. Not only have that, the rolling codes return to an expired command value every 5 to 10 rounds. This indicates that the keyspace of such proprietary rolling codes is extremely small and we do not even need bruteforce to unlock it.

As you can see in the demo video below, we only need to capture the unlocking command once, and then replay it repeatedly, until the lock is finally unlocked. 

   

In addition, Flipper-Zero can add some well-known keyfobs protocols manually. Take LiftMaster_315 as an example. It implemented a rolling code mechanism. However, as you can see in the pics below, the counter value is predictable, so does the key. Therefore, it is very easy to capture then spoof an unlock command to such system.

0x02. ROLLJAM ATTACK

Fortunately, most car manufacturers will not use such naive designs for the car door locks. They prefer to use their own proprietary encryption algorithms instead. As you can see in the picture below is a 2014 Jetta keyfob. Since Volkswagen keeps the algorithms secret, the flipper-zero is not able to recognize it.  

Again, we use URH for the analyzing Jetta keyfob packets. One nice feature of URH is that we can highlight the sequence of packets in color; this makes analyzing job much easier. Each valid sequence of commands will start with 10101000 in green as the sync-word. 

From the 305th to the 312th in red are operation commands. For example, 00011100 is the command to open the door, and 00101010 is the command to close the door. The blue part is the rolling codes that change every time. 

URH comes with a comparison function that can be used to compare and analyze the rolling code parts between different commands.

As you can see in the demo video below, since modern cars nowadays have implemented the proprietary rolling code mechanism, we can only replay the unlock command once.

  

Years ago, a security researcher, Samy Kamkar, came up with an idea that can manipulate certain rolling code system. He called it the Rolljam Attack. How Rolljam attack works is well explained in the slides below. The Rolljam attack works by jamming the target radio signal at slightly deviated frequency and recording the signal at tight receiver filter bandwidth from the keyfob at the same time. Since the first unlock signal is blocked, the car door will not unlock and the car owner will likely try again. Attacker can again record and block the second signal, but this time the attackers also replays the first code to unlock the car door.

     (Source from Samy Kamkar)

As you can see in the demo video of rolljam attack below, the HackRF has been used as a signal jammer, and Yardstick 1 as the recorder and transmitter.

   

Since Rolljam attack needs a jammer and recorder work at the same time, we can use HackRF and Flipper-Zero as combo tools for this attack.

   (Source from @takeapart)

0x03. ROLLING-PWN 

In year 2021, I have found a very interesting yet scary car lock vulnerability, which affected all Honda vehicles currently existing on the market globally from year 2012 up to year 2023. All Honda vehicles allow a replay of the already expired commands in a consecutive sequence to unlock the car door permanently. 

    

The CVE-2021-46145 has assigned to this bug, and I have written an article dedicated to this bug (https://rollingpwn.github.io/rolling-pwn). Special thanks to researcher, Rob Stumpf helped us to verify the bug with his own 2021 Honda Accord from the US.

        (Source from @RobDrivesCars)

Moreover, Honda officially acknowledge the bug. However, Honda concluded this is a low risk to customers, and Honda regularly improves security features as new models are introduced that would thwart this and similar approaches. Fingers crossed.

In later Aug 2022, group of researchers from Singapore presented a talk at Blackhat USA addressing the same issue, and they found out the bug also affected many other brands of cars. As we mentioned in the Rolling-Pwn article, we knew about this.

However, we were keeping what other brands were also affected by the bug quiet at that time. Because we are busy preparing for a Pwn2own style hacker competition called Geekpwn, and one of our modern smart car targets for the competition is vulnerable to the bug. Luckily, we won second runner-up in the end. As you can see in the pic below, we were using a high gain antenna to pwned those two different brands of cars in a fairly long distance.

0x04. KEELOQ DECRYPTION

In the world of crypto, there is a well-known Kerckhoff principle; a crypto system should be secure even if the attacker knows all the details about the system, except the secret key. However, have you ever wondered what happen if that secret key leaked from manufacturer or a default manufacturer key from the datasheet used in the final products? These kinds of incidents are not uncommon; remember the mifare crypto1 default key hacks, anyone? Let’s take a widely used rolling code algorithm called Keeloq as an example.

KeeLoq is a proprietary cipher owned by Microchip. It is widely used in keyfob systems by car companies such as Honda, Toyota, Volvo, Volkswagen Group and so on. If we found HCS200 or HCS300 series chipset inside the keyfob, which means we are facing the Keeloq cipher based system. In March 2008, researchers from the Ruhr University, Bochum, broke the KeeLoq-based cipher with side-channel analysis. By measuring the power consumption of a device during encryption, the researchers can extract the manufacturer key from the receivers and the remote control.

When we connect the HCS201 chip to an oscilloscope or logic analyzer, we can see Keeloq's signal waveform. First, there will be a preamble at the start of the signal, followed by the rolling codes, serial number, function code and status code.

Keeloq data structure has a total of 66 bits, including 32 bits of rolling code, 28 bits of serial number, and 4 bits of button function code and 2 bits of status code. The encoding is PWM.

In terms of encryption key generation, Keeloq has three modes: simple, standard and secure. The manufacturer's secret key for simple encryption is the same. For standard encryption, the manufacturer's secret key for each keyfob is unique. Taking standard encryption as an example, assumes that the serial number is 0x1234567. First add 2 as prefix for serial numbers, it become 0x21234567, then encrypted using the manufacturer's secret key to get a 32-bit LSB of 0x89074278. Second add 6 as prefix for serial numbers, it become 0x61234567, again encrypted using the manufacturer's secret key to get the 32 bit MSB 0x0516FBE9. The encryption key to this is 0x0516FBE989074278.

We can use the simulator to demonstrate it in practice. Here we set the manufacturer's secret key to 0123456789ABCDEF, the serial number to 4141410, and the counter starts from 2600.

After analyzing the packets with URH, we can see that the 28-bit serial number is indeed 4141410.

The 32-bits rolling code contains key information such as counters to prevent a replay attack.

As mentioned earlier, if the default manufacturer key has been used. We can decrypt the 32-bits rolling codes with the program, you can see the rolling code in sequence in the decrypted message, which matches the starting value of 2600 we set earlier.

As you can see the video below, we can spoof a new command to turn on the light.

     

0x05. SUMMARY

In Part 2, we have looked at some of the advanced techniques, such as RollJAM; Rolling-PWN and Keeloq Decryption. However, there are many other types of encryption and rolling code algorithms to play with. Stay tuned.