> 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).
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.
Readit News
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
to even implement such a design is audacious
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.
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).