Aléas numériques

Linux, infosec and whatever crosses my mind.

» Keyless entry systems protection and bypassing

Recently, I got gifted a Flipper Zero \o/

I’m still in the phase where I’m trying to understand all its capabilities, and as I’m not very familiar with RFID/NFC, and more generally with everything RF-related (my radio signals classes were a long time ago) I’m reading a lot of stuff on the Internet about it. One of the first thing I stumbled upon is stories about people getting locked out of their cars, and I wanted to know more about it.

Replay attack

A replay attack occurs when an attacker intercept a legitimate communication between two agents and is able to act as one of the agent by sending again the information he or she captured. Typically, it can be static ID codes, hard-coded passords etc.

In the context of a Keyless entry system, it can be illustrated as follows:

A system vulnerable to replay attacks is fairly easy to implement, but not secure at all. If an attacker grabs the secret key, then the only way to mitigate is to patch both the transmitter and the receiver.

Rolling codes

Rolling codes, also called hopping codes, are a way to rotate the secret sent by the transmitter in a “predictive” way. Ideally, only the receiver should be able to know what will be the next code. Rolling codes are in use in most modern RKE systems (garage doors, cars…).

A common way to implement rolling codes is to use a shared PRNG in both the transmitter and the receiver. They both have a pre-computed list of sequential codes, and when the receiver receives a code it compares it to its own list.

Usually, the receiver compares the code received to the next, let’s say, 10 entries in its computed array and if the one of them match, the receivers accept it as a valid code and then sync to be at the same code. Indeed, a user may press the key button multiple times while being out-of-reach, and the codes index in the transmitter (the car key) will keep incrementing. This avoid being stuck outside of our car.

But if someone replaces it’s key by, for example, a Flipper Zero then the code index on the car will be incremented, but not on the key. In the end, the key will be too far away from the current index in the car’s memory and will no longer open the car. At least, that’s how I understand it. 🤔


KeeLoq is a proprietary block cipher (meaning that it works on fixed-length groups of bits, blocks) dedicated to be embedded in hardware components. It has been designed in the 80’s. Microchip bought it in 1995 for a big pile of cash, and is now selling encoders and decoders (HCS101/2XX/3XX/4XX/5XX, NTQ etc.).

The HCS301 encoder datasheet using the KeeLoq cipher tells us about the various security fearures KeeLoq provides:

During the production of the HCS301, the transmitter serial number and the crypt key (generated by mixing the transmitter serial number and the manufacturer’s code with an unknown algorithm1) are written into the EEPROM of the chip:

The HCS301 combines a 32-bit hopping code, generated by a nonlinear encryption algorithm, with a 28-bit serial number and 6 information bits to create a 66-bit code word.

It is worth noting that the EEPROM array is read-protected to prevent accessing the keys or manipulate them.

When the user presses a button on a keyless system equipped with this encoder, here is what happens:

  1. The crypt key and the sync counter are read from the EEPROM and inputted into the KeeLoq encryption algorithm to generate a 32-bit encrypted data. This will be the hopping code.
  2. The serial number (28 bits) is added.
  3. The button code (4 bits) is also added to the frame, as well as the 2-bit status. This is used on the received side to do various operations.

On the receiver side:

  1. The serial numbers are checked to see if they match.
  2. The encrypted data is decrypted using the crypt key, the output is compared with the receiver’s stored sync counter.
  3. If the sync counters match, then the receiver does the stuff it should do based on the button code (open the door/gate, …).

As we previously saw with rolling codes, the future codes are usually stored on both ends. With the KeeLoq system, this is not the case. The decoder provides a mecanism to toss invalid transmissions, and resync with valid transmitters that might have been activated too far away for the decoder to intercept them (up to 32k codes):


One way to bypass the security mechanisms behind KeeLoq and co. is jamming.

The idea behind jamming is to:

  1. Intercept what the transmitter is sending;
  2. Block the signal so the receiver doesn’t receive anything.

In the end, you end up with a valid transmission that is not considered as already sent by the receiver. You can then use it, but only once. You’ll have to repeat the operation if you want multiple working transmission to use.

A lot of research papers and articles about jamming RKE exist. Here are some nice one:

And of course the DEFCON23 presentation by Samy Kamkar on the topic.

Well, I hope you enjoyed reading this article as much as I enjoyed learning and writing it. I feel that I only scrapped a tiny bit of the surface of the huge RF field. If I end up doing cool stuff with my Flipper Zero, I’ll do write-ups about it. Until then, happy hacking!

  1. Well, not so unknown as implentations are available online, i.e.↩︎