In Latin America, some automotive dealerships source RKES systems from the Chinese market and subsequently homologate them for official use in their vehicles. This practice is risky, in another hand, these types of commercial RKES units are sold worldwide through the internet. In this post, I present the reverse engineering process I performed on this very common Chinese commercial rolling code algorithm and I explain why these aftermarket RKES systems should not be used.
Chinese Manufacturer
FACTORY (in China): MICCA AUTO ELECTRONICS CO., LTD.
Street Longzhu#2, ShangTang Road, South District, Zhongshan City, Guangdong, China.
In their web page you can verify that this entity have customers in South America, Center America, Europe and Asia:
Product: OEM Car Alarm System (This is a best-selling proprietary aftermarket Rolling Code
RKES system in Latin America, Europe, and Asia. The same rolling code algorithm identified in
this research is also used by many Chinese manufacturers and has been implemented by some
car dealerships mainly in Latin America)
RKES analyzed in this post: Model number KE700 / KE700+:
Recognition phase
Key Fob Chip:
Components:
- Oscillator SFR433k (Frequency is 433Mhz)
- Chip Tx: Chip FMD A4kQRKE manufactured by Fremont Micro Devices (FMD), No public datasheet
Frequency verification:
Receiver ECU:
Components:
- Decoder: Microcontroller STM8S105
- Anthena
- High-Voltage, High-Current Darlington transistor array (relay): ULN2003G
- Peripherals connectors
- Chip RX: 509R 2431
The rolling code is received by the ECU antenna and processed by the 509R-2431 chip. Finally, the rolling code exits through pin 5 (DO) of that chip. This DO signal then enters the ECU’s STM8 microcontroller at pin 36, as shown below:
PIN DO 509R
Reversing the Rolling Code signal
From a simplified perspective and based on my experience, the signal is modulated using ASK and employs PWM encoding (logical ‘1’ is transmitted as 1110 / long pulse, and logical ‘0’ as 1000 / short pulse).
After collecting approximately 300 samples and performing demodulation and PWM decoding, I determined that the frame is not encrypted. I was able to identify the frame contents, which consist of several counters and a random number component used as the rolling code. Therefore, the rolling code frame is as follows:
Frame:
- Random Number: 6 bits.
- C0 Down counter: 2 bits, in descending order starting from three (11…to..00).
- C1 Up counter: 8 bits, each 6 times, every 6 times, the counter is kept only once.
- C2 Up counter: 16 bits, normal increase without conditions.
- C3 Slowest counter: 9 bits, this counter increases by 2 each time, this counter increases only when the C1 counter has incremented 256 times.
Also, I discovered more interesting information about this RKES:
- The rolling code frame/signal is not encrypted using AES or another secure symmetric encryption. The coding used is very weak!!.
- The offset between key fob 2’s unlock and lock signals is constant because X (unlock counter) – Y (lock counter) = constant.
- The receiver unlocks the system if: (counter received – constant) = lock counter. The receiver to lock the system if: counter received + constant = unlock counter.(This is a possibility).
- This offset remains consistent even without pressing the unlock button. If I press the lock button n times, the unlock counter also advances at the same rate.
- Each key fob has independently counters.
- Each key fob has different seed and the seed is not the counter because both key fobs with the same counter has different random numbers.
- The frame has not preamble
Therefore, the Rolling Code Algorithm is the following:
Brute Force Attack
The random number is only 6 bits. Therefore, 2^6 = 64 possible numbers (I could unlock the car in less than 1 minute!!). To execute the brute force attack I updated my previous RF exploit tool “AutoRFKiller” with this final exploit which add 1500 lines of python code to the previous GNU Radio blocks. Just in case, the updated tool is not public in my Github.
Demonstration of a brute-force attack on the next rolling code after sniffing the current one:
Real Car Demo PoC: Brute force attack against the subsequent rolling code after capturing the current rolling code. Test vehicle: older Mazda model, the original RKES had been replaced with the aftermarket Chinese RKES, making the vehicle brand IRRELEVANT.
RollBack vulnerability discovered
This Chinesse RKES also is vulnerable to RollBack attack, where we cand send a signal to resyncronize the window of the RKES and after that, send previous/used/old rolling codes (ex, n-100). For example:
To unlock/lock the system, two rolling codes must be sent in the following way:
– The first rolling code will enable the receiver so that the second rolling code can unlock/lock the system.
– The first rolling code must precede the second rolling code in any sequence, for example:
Valid Case 1:
Captured rolling code 1: n – 4
Captured rolling code 2: n – 1
Valid Case 2:
Captured rolling code 1: n – 15
Captured rolling code 2: n – 1
Valid Case 3:
Captured rolling code 1: n – 2
Captured rolling code 2: n – 1
The attack:
Demo PoC:
Key Fob Cloned
If we combine the brute force attack with the rollback vulnerability, it becomes possible to clone the key fob.
Why? As a reminder, exploiting the rollback vulnerability requires two valid signals: one to resynchronize the RKES system and a second to lock or unlock it. Using a brute-force attack, an attacker can perform a man-in-the-middle (MITM) attack to capture a single valid frame. The attacker then brute-forces the second frame. Once these two valid frames are obtained, they can be used at any time to execute the rollback attack. At that point, the key fob is effectively cloned. This represents a serious security risk.
Demo PoC (the same of the rollback attack, with rollback attack you have basically a replay attack!!!):
Conclusions
- These RKE systems are currently sold worldwide in auto parts and aftermarket car parts stores in all over the world and all over the world through internet.
- When does the vulnerability appear? In South America, it typically arises when a vehicle’s original RKES needs to be replaced, for example, if it is damaged, very old, or if the owner has lost the key fobs. In such cases, owners often purchase a replacement RKES outside the official dealership, such as from local stores (e.g., Autolujos) or online. In most cases, these replacement systems are Chinese RKES implementations that use a vulnerable rolling-code mechanism.
- Affected countries: South America, Center America, Asia, Europe.
- Is very difficult to find a secure aftermarket rolling code RKES.
- Aftermarket Rolling Code RKES is a serious risk: Thousands of thousands of cars in risk in all over the world!! May could exist MANY MORE CHINESE ROLLING CODE RKES MODELS WITH THE SAME ALGORITHM.
- Recommendation: Avoid to buy any Chinese aftermarket Rolling Codes RKES, if you lost your key fobs or if do you want to change you old and originl RKES, you should request/buy to your official car dealership the original RKES with the original key fob.
Disclosure
Finally, the vulnerability was reported to Automotive Security Research Group (ASRG) , however, MICCA AUTO ELECTRONICS never responded to ASRG’s repeated communication.
About the Author
