Reversing and breaking fixed-code remote keyless entry (RKE) systems has been thoroughly documented in the past. However, not a lot of online documentation exists on reversing and breaking rolling-code technology, which is prevalent in RKE systems used for cars. This is an attempt to grab more information on the matter using software-defined radio (SDR) techniques.
|Car key-fob: a quick look at the FCC information yields a circuit made by LEAR with a 315MHz operating frequency that uses ASK-OOK (PWM) modulation. Circuit pictures show a Microchip (tm) encoder module of unknown series.|
Michael Ossman's Yardstick One from Great Scott Gadgets
|Any software-defined radio. I'll use my trusty HackRF|
Getting the signal
The first step is getting the signal. Using GQRX and the HackRF as a receiver, we tune in at 315MHz and as expected, we find our ASK-OOK signal:
Decoding the signal
In order to decode the signal, we need a few parameters. From the FCC datasheet, we already know that the signal is modulated using amplitude-shift keying (ASK) to encode a PWM signal. Demodulating as an AM signal and saving to a WAV sound file, we can open the WAV file in Audacity to see our bits appearing:
Houston, we have data! There's a few key parameters that we can glean from this:
- The remote transmits 69bit packets in bursts of multiple identical packets for reliability reasons.
- These packets are prefixed with a 12 short-pulse preamble to allow the receiver to synchronize its internal clock with the transmitter's.
- The data itself is encoded in long and short pulses, typical of PWM encoding.
- Digging in the Microchip (tm) datasheets yields multiple hits for 69bit radio packet encoders that use PWM, namely the HCS encoder series!
Lets look into the HCS encoder chip datasheets...While there are numerous models with different operating parameters, they have a LOT in common...
- The HCS series encoders support a baud rate of 5000 bps, which is within tolerance of our measured short pulse length of 180 microseconds.
- The HCS series encodes a ZERO as a long pulse, and a ONE with a short pulse. The timings of the pulses are important, as each pulse uses 3 timing elements of 180 microseconds. Therefore, each symbol of 3 "bits" encodes one real bit: 110 being ZERO and 100 being ONE.
- Data is transmitted with the least significant bit (LSb) first, so we'll need to flip the received message around for it to make sense.
- Data is split into 2 parts: unencrypted, and encrypted. The encrypted part uses the Keeloq cipher, on which a lot of cryptographic work has been done, so we won't dwell on this issue since the interested reader can look it all up on the internet. Long story short, it has been brutally and completely broken using side-channel attacks. By monitoring the electrical power sent to the encoder chip during the encryption routine, one can measure the hamming weight of the master key used in the encryption process which makes bruteforcing the masterkey through SAT methods trivial.
NB: Don't message me on how to break Keeloq for you.
- We now know how we can expect the data to be formatted!
Interpreting the data
The encrypted part is in red, the fixed code part in yellow (please don't steal my shitty old rusted car...wink wink...), the button in cyan, and the queue/CRC in blue:
You can find my quick and dirty code on GitHub
Using the same rfCat device configuration as my GitHub script allows you to transmit data to the car's locking system (but I won't provide a sample script for obvious security reasons). Only do so on vehicles you own or you could get in major trouble. Happy hacking!