5 ms·

Hacking cars in JavaScript (Replay attacks in the browser with the HackRF)

125 points by rmason 2y ago

genericacct 2y ago
Lots of other interesting projects on the author's site, check them out
letters90 2y ago
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
- lnsru 2y ago
  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.
- londons_explore 2y ago
  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.
  - wolrah 2y ago
    > 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).
    - londons_explore 2y ago
      > 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.
      - wolrah 2y ago
        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.
mschuster91 2y ago
> 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/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/MobilfunkDectWlanCBFunk/vfg212021CBFunk.pdf?__blob=publicationFile https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sac... [2] https://www.gesetze-im-internet.de/ttdsg/__5.html https://www.gesetze-im-internet.de/ttdsg/__5.html

125 points by rmason 2y ago

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

lnsru 2y ago
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.
londons_explore 2y ago
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.
- wolrah 2y ago
  > 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).
  - londons_explore 2y ago
    > 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.
    - wolrah 2y ago
      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.

mschuster91 2y ago

> 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/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/Frequenzen/Allgemeinzuteilungen/MobilfunkDectWlanCBFunk/vfg212021CBFunk.pdf?__blob=publicationFile https://www.bundesnetzagentur.de/SharedDocs/Downloads/DE/Sac... [2] https://www.gesetze-im-internet.de/ttdsg/__5.html https://www.gesetze-im-internet.de/ttdsg/__5.html