> Even though using SDRs to listen and transmit data is not illegal in itself, please check with your local laws regarding the need to have a radio license to transmit on specific frequencies.
Big fat warning here: in some countries such as Germany it is even illegal to receive on bands where you do not have a permit, or to use unlicensed transmitters.
Let me sum it up, in case it is of interest:
- FM radio band (87.5 to 108 MHz): TX banned outside of in-car adapters with extremely low power, RX free for all
- Aeronautics (108-137 MHz), maritime (156-162 MHz) communication: both RX and TX illegal unless you hold a valid certificate (AZF/BZF for aero, ROC/GOC/SRC/LRC/UBI for maritime). Distributing streams or recordings is also illegal, covered by other laws, and importantly includes situations like filming on the bridge of a ship/boat... you may film it, but you have to censor the audio where radio communication can be heard according to §5 TDDDG [2]. This also applies for all other radio communications without a "free for everyone" rule (e.g. corporate radio, public transit radio, ...).
- CB (26,565-27,405 MHz): RX and TX free for everyone, but respect the channel roster and power limits [1]
- PMR446 (446,000–446,200 MHz): RX and TX free for everyone, but only with specially certified PMR446 devices. Ham radio equipment is not allowed, even if kept inside the regulatory requirements!
- Ham radio bands (I'm not typing that list down...): RX free for everyone, TX according to the operator's license (HAREC/ECC (05)06/National class N) restrictions
- ISM: RX/TX free for all but please don't be a dong.
The problem is most cars remotes are one-way comms, and the car remote has no concept of time.
Given those constraints, there is no fix possible.
However, a more modern car remote could easily send a signed message saying "Open car, Time is 1/1/2025 17:53, Signature: 7F82SA42ad==". The car would then check the time against its clock and only accept the command if the message is only a few seconds old.
The battery in a car remote should be able to keep a clock ticking for the 20 yr lifespan of the car (and a sync procedure for keys where the battery gets replaced).
The clock doesn't need to use wall time, but some custom "seconds since birth of key" would do just fine too, eliminating bugs due to leap seconds, incorrectly manually/auto set clocks, timezone changes etc.
> The problem is most cars remotes are one-way comms, and the car remote has no concept of time.
> Given those constraints, there is no fix possible.
There are in fact multiple "fixes" which have been widely implemented in devices that care to get it right for decades.
The simplest of course being a basic rolling code, where a counter is transmitted along with the command and this has to increment compared to the last press.
That would be easy to spoof based on a single capture and likely could just be brute forced, so with a slight bit more effort you make it skip a fixed amount forward and lock out for a short period of time if it receives values outside of the expected possibilities.
This could still be spoofed by logging multiple uses, so a bit more complexity for a massive amount more security can be had by using a PRNG for the code instead of an incrementing counter. Now you have to have a pairing process to sync the transmitters up, but that could be as simple as a button under the remote's battery cover that makes it transmit the RNG seed.
In any of these cases you accept the next however many potential codes in the cycle based on how many times you want to tolerate someone using their remote as a fidget toy (or how much you want to support low battery operation).
> The simplest of course being a basic rolling code, where a counter is transmitted along with the command and this has to increment compared to the last press.
These attacks typically rely on jamming the receiver in the car (eg. with a tone at a frequency between the two frequencies used by the FSK of the key), whilst capturing the signal sent by the remote.
Then the attacker replays the signal to the car at a later date.
Since the car has never seen this signal, it defeats any rolling code mechanism. Without both sides having a clock, there is no defence.
That would only work if the car has also not seen any further valid messages since the one that was blocked, so I'm not seeing how this technique could be useful for anything other than preventing someone walking away from their car from successfully locking it and being able to go through the car before replaying the signal and locking it yourself to cover your tracks.
Even then if they're the sort of person who does the double click for horn/flash thing they'll just assume their fob batteries are dying and return to the vehicle until they're close enough to defeat the jammer.
If the rolling code is predictable and the attacker can generate their own valid "next message" that's an entirely different matter, but a pure replay is only useful in very specific situations.
The typical process, which I see active in London pretty frequently, is to jam and record everything on 433.92 Mhz.
Then, when you have received at least one lock and unlock request for a car, start retransmitting lock and unlock requests, but delayed by one request.
That way, the owner of the car thinks their key is working, and it unlocks and relocks reliably, but in fact the attacker always has one code 'spare'
Then, at 3am they come use their spare code to unlock the car and steal stuff or drive it off (the car only needs to see to fob present briefly to start the engine, but I believe that bit is done with a relay attack. I see the guys who do this waving their suitcase antenna around peoples doors regularly).
One giveaway to know on my car that such an attack is underway is that if you press the lock button 5 times in a row, it would normally flash the indicators with every press. However, when an attack is underway, it will only flash the indicators the first time, and won't do it again till after the next unlock, which makes sense because the command (lock or unlock) is not independent of the rolling code.
> Then, when you have received at least one lock and unlock request for a car, start retransmitting lock and unlock requests, but delayed by one request.
For this story to play out with a non-spoofable implementation the attackers would have to be present for and able to jam/intercept every use of the fob between the first one in their sequence and the present.
I'm not saying it's not technically possible, but any use of the fob that slips through the cracks resets the sequence so if the target takes the vehicle somewhere else or even just uses the fob while close enough to not be jammed the idea falls apart. Unless the target is in the habit of going back out to their parked car to retrieve things and then locking it back up it seems like that'd be a rare catch.
> (the car only needs to see to fob present briefly to start the engine, but I believe that bit is done with a relay attack. I see the guys who do this waving their suitcase antenna around peoples doors regularly).
Relay attacks on pushbutton start vehicles are an entirely different matter as they do involve two-way communication and if you have the ability to start a car with one you also have the ability to unlock it with the same method. I'm just talking about traditional long range one-way fobs here.
No. The developers are very capable. Think about Volkswagen’s diesel defeat device. The managers are the ones running the show. And you can do anything you like as developer in such situation. Managerial decisions will not change. It’s hidden caste system where (somehow arrogant automotive) managers will never listen to (probably for particular project leased from some bodyshop) developers.
> Even though using SDRs to listen and transmit data is not illegal in itself, please check with your local laws regarding the need to have a radio license to transmit on specific frequencies.
Big fat warning here: in some countries such as Germany it is even illegal to receive on bands where you do not have a permit, or to use unlicensed transmitters.
Let me sum it up, in case it is of interest:
- FM radio band (87.5 to 108 MHz): TX banned outside of in-car adapters with extremely low power, RX free for all
- Aeronautics (108-137 MHz), maritime (156-162 MHz) communication: both RX and TX illegal unless you hold a valid certificate (AZF/BZF for aero, ROC/GOC/SRC/LRC/UBI for maritime). Distributing streams or recordings is also illegal, covered by other laws, and importantly includes situations like filming on the bridge of a ship/boat... you may film it, but you have to censor the audio where radio communication can be heard according to §5 TDDDG [2]. This also applies for all other radio communications without a "free for everyone" rule (e.g. corporate radio, public transit radio, ...).
- CB (26,565-27,405 MHz): RX and TX free for everyone, but respect the channel roster and power limits [1]
- PMR446 (446,000–446,200 MHz): RX and TX free for everyone, but only with specially certified PMR446 devices. Ham radio equipment is not allowed, even if kept inside the regulatory requirements!
- Ham radio bands (I'm not typing that list down...): RX free for everyone, TX according to the operator's license (HAREC/ECC (05)06/National class N) restrictions
- ISM: RX/TX free for all but please don't be a dong.
[1] https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sac...
[2] https://www.gesetze-im-internet.de/ttdsg/__5.html
Lots of other interesting projects on the author's site, check them out
it's nothing new for cars to be susceptible to replay attacks, yet it's always a proof of incapacity of the involved developers.
to even implement such a design is audacious
The problem is most cars remotes are one-way comms, and the car remote has no concept of time.
Given those constraints, there is no fix possible.
However, a more modern car remote could easily send a signed message saying "Open car, Time is 1/1/2025 17:53, Signature: 7F82SA42ad==". The car would then check the time against its clock and only accept the command if the message is only a few seconds old.
The battery in a car remote should be able to keep a clock ticking for the 20 yr lifespan of the car (and a sync procedure for keys where the battery gets replaced).
The clock doesn't need to use wall time, but some custom "seconds since birth of key" would do just fine too, eliminating bugs due to leap seconds, incorrectly manually/auto set clocks, timezone changes etc.
> The problem is most cars remotes are one-way comms, and the car remote has no concept of time. > Given those constraints, there is no fix possible.
There are in fact multiple "fixes" which have been widely implemented in devices that care to get it right for decades.
The simplest of course being a basic rolling code, where a counter is transmitted along with the command and this has to increment compared to the last press.
That would be easy to spoof based on a single capture and likely could just be brute forced, so with a slight bit more effort you make it skip a fixed amount forward and lock out for a short period of time if it receives values outside of the expected possibilities.
This could still be spoofed by logging multiple uses, so a bit more complexity for a massive amount more security can be had by using a PRNG for the code instead of an incrementing counter. Now you have to have a pairing process to sync the transmitters up, but that could be as simple as a button under the remote's battery cover that makes it transmit the RNG seed.
In any of these cases you accept the next however many potential codes in the cycle based on how many times you want to tolerate someone using their remote as a fidget toy (or how much you want to support low battery operation).
> The simplest of course being a basic rolling code, where a counter is transmitted along with the command and this has to increment compared to the last press.
These attacks typically rely on jamming the receiver in the car (eg. with a tone at a frequency between the two frequencies used by the FSK of the key), whilst capturing the signal sent by the remote.
Then the attacker replays the signal to the car at a later date.
Since the car has never seen this signal, it defeats any rolling code mechanism. Without both sides having a clock, there is no defence.
That would only work if the car has also not seen any further valid messages since the one that was blocked, so I'm not seeing how this technique could be useful for anything other than preventing someone walking away from their car from successfully locking it and being able to go through the car before replaying the signal and locking it yourself to cover your tracks.
Even then if they're the sort of person who does the double click for horn/flash thing they'll just assume their fob batteries are dying and return to the vehicle until they're close enough to defeat the jammer.
If the rolling code is predictable and the attacker can generate their own valid "next message" that's an entirely different matter, but a pure replay is only useful in very specific situations.
The typical process, which I see active in London pretty frequently, is to jam and record everything on 433.92 Mhz.
Then, when you have received at least one lock and unlock request for a car, start retransmitting lock and unlock requests, but delayed by one request.
That way, the owner of the car thinks their key is working, and it unlocks and relocks reliably, but in fact the attacker always has one code 'spare'
Then, at 3am they come use their spare code to unlock the car and steal stuff or drive it off (the car only needs to see to fob present briefly to start the engine, but I believe that bit is done with a relay attack. I see the guys who do this waving their suitcase antenna around peoples doors regularly).
One giveaway to know on my car that such an attack is underway is that if you press the lock button 5 times in a row, it would normally flash the indicators with every press. However, when an attack is underway, it will only flash the indicators the first time, and won't do it again till after the next unlock, which makes sense because the command (lock or unlock) is not independent of the rolling code.
> Then, when you have received at least one lock and unlock request for a car, start retransmitting lock and unlock requests, but delayed by one request.
For this story to play out with a non-spoofable implementation the attackers would have to be present for and able to jam/intercept every use of the fob between the first one in their sequence and the present.
I'm not saying it's not technically possible, but any use of the fob that slips through the cracks resets the sequence so if the target takes the vehicle somewhere else or even just uses the fob while close enough to not be jammed the idea falls apart. Unless the target is in the habit of going back out to their parked car to retrieve things and then locking it back up it seems like that'd be a rare catch.
> (the car only needs to see to fob present briefly to start the engine, but I believe that bit is done with a relay attack. I see the guys who do this waving their suitcase antenna around peoples doors regularly).
Relay attacks on pushbutton start vehicles are an entirely different matter as they do involve two-way communication and if you have the ability to start a car with one you also have the ability to unlock it with the same method. I'm just talking about traditional long range one-way fobs here.
What kind of cheap low power clock do you propose to use that only loses a couple seconds over 20 years?!
No. The developers are very capable. Think about Volkswagen’s diesel defeat device. The managers are the ones running the show. And you can do anything you like as developer in such situation. Managerial decisions will not change. It’s hidden caste system where (somehow arrogant automotive) managers will never listen to (probably for particular project leased from some bodyshop) developers.