Dynamic code remote denial of service?

Does anyone have ideas to do DOS attacks on remotes like the ones using keeloq ?
I did read about one attack on keeloq that will invalidate a valid remote and there is also this :

In short in some systems if one capture one code with flipper read raw and then transmit that code after it expired it will block the original remote from working as the system will see that remote as compromized …

Any ideas on how to do more DOS attacks ?

1 Like

I think the most interesting DOS weakness in these rolling code protocols is that they are designed to resync even if the remote has a number of unreceived / out-of-range activations. This is a seemingly inevitable issue with a one-way protocol.

As I understand these protocols (per some manufacturer documents), the codes increment a counter with each activation. For security, no code can be used twice. (Thus, in a properly implemented rolling code setup, Flipper’s RAW mode will only get you a single activation.) The receivers will recognize a code that is ahead of the expected sequence number by a certain amount, say 10–20 steps (depending on design). So if your kid gets ahold of the remote and presses it a half-dozen times, it will still work without a manual resend. However, if the transmitter gets too far ahead of the base, the base will not recognize the code and a manual resync / re-enroll will be necessary. Crucially, the sequence numbers go only one way—up.

This is where the problem / weakness comes in: if the remote “somehow” gets behind the receiver, the remote entirely ceases to work until it catches up. The DOS weakness here, then, is that if you can receive and crack the code once with some of the special purpose software that does this, you can then advance the base station, say, 10 sequence codes at a time rather quickly. Once the base is 100 or so codes ahead of the remote, the remote is effectively disabled. (Unless you know exactly why it is not working and are patient enough to press the button 100 times…)

Is this practical? I don’t really know. But it does illustrate something interesting about rolling code systems: even a perfect clone isn’t very useful if your clone and original don’t somehow synchronize with one another.

It would not be easy to get the key. An interesting way might be to remove the key fob from the cars memory and pair it again. Hopefully during that process you could listen in and get the NEW key generated during the pairing process.