CAN Injection: keyless car theft

This is a detective story about how a car was stolen – and how it uncovered an epidemic of high-tech car theft. It begins with a tweet. In April 2022, my friend Ian Tabor tweeted that vandals had been at his car, pulling apart the headlight and unplugging the cables.

It seemed like pointless vandalism, the kind of thing that makes it impossible to have nice things. Then three months later it happened again.

This time the bumper was pulled away and the headlight unplugged. But it turned out neither incident was vandalism, because a couple of days later:

The car was gone. And it looks like the headlight was how it was stolen. Ian is a cybersecurity researcher in the automotive space and has previously been awarded bug bounties for finding vehicle vulnerabilities, and I initially thought from reading his tweet that this might be a trophy hack. But it turns out not: Ian’s neighbour had their Toyota Land Cruiser stolen shortly after. For Ian this is personal and he wanted to know just how they stole the car. After all, it’s got sophisticated car security systems, including an engine immobilizer. How did they drive these cars away?

Ian did some more sleuthing, starting with the ‘MyT’ telematics system that’s included in a lot of Toyota cars. The automotive industry has been adding built-in diagnostic systems to cars for decades. It’s called ‘on-board diagnostics’ (or OBD for short) and when an Electronic Control Unit (or ECU) detects a fault, it records a code. In the industry, it’s called ‘dropping a DTC’ (or Diagnostic Trouble Code). The MyT system will send DTCs up to Toyota servers, and the MyT app can show them.

These are codes that indicate what the detected fault is and when it occurred. Some DTCs include a ‘freeze frame’ – a collection of sensor data around the time of the fault, to help a workshop mechanic try to diagnose the fault (it might be the speed of the vehicle, the temperature outside, the battery voltage, that kind of thing). In modern cars, ECUs are connected together with a communications link, running a protocol called CAN bus (CAN stands for Controller Area Network). It was invented more than 30 years ago, and is used today in more than cars: it’s built in to boats, farm equipment, aircraft, construction equipment, and even spacecraft (there’s a CAN bus orbiting Mars right now). One of the ways an ECU will diagnose a fault is if it doesn’t hear from another ECU it needs to talk to, and this is often done with a timeout: if a CAN message isn’t received regularly then after some time without hearing anything the listener assumes there’s a fault with the CAN bus or the other ECU. And sometimes it’s obvious the CAN bus has failed: if an ECU’s own messages are not sent, for example, or the CAN bus interface hardware says that communication has been lost.

It turns out that around the theft of the car, Ian’s car dropped a lot of DTCs.

In the front of the RAV4 there is an ECU that controls the lights (the high and low beam headlights and the turn indicators). In most cars there is such an ECU because the days of there being a simple switch to turn on lights are long gone: lights are smart, and include things like motors to level the headlights (so when the car is loaded with heavy luggage, the lights are turned to compensate), steering headlights to illuminate the corners, to automatically detect if the lights have failed, to turn on pumps to spray water on the lights, and so on. And on the RAV4, it’s to also choose which LEDs in a grid are lit up to not dazzle oncoming drivers but still light the rest of the road.

The DTCs showed that communication with the lighting control ECU was lost. This isn’t surprising since the thieves had ripped the cables out of it. But the DTCs also showed that lots of systems had failed: the control of the front cameras, the hybrid engine control system, and so on. How could that be? This was the next clue: the ECUs probably hadn’t failed, but rather the communication to them had been lost, and the diagnostics had flagged this as a fault. The common factor: CAN bus.

Ian did some more sleuthing around the dark web, sites that talked about how to steal cars, hunted around forums, and found YouTube videos on car thefts. He tracked down a web site selling more than a hundred products for by-passing car security, from programming fake key fobs to ‘emergency start’ devices (a fiction that these products are for owners who have lost their keys or somehow reputable locksmiths will use these).

The prices are eye-watering (up to €5000) for an ordinary owner, but for a gang of car thieves this is an investment. There are products targeting many car models, including from Jeep, Maserati, Honda, Renault, Jaguar, Fiat, Peugeot, Nissan, Ford, BMW, Volkswagen, Chrysler, Cadillac, GMC – and Toyota.

For Toyota, the ‘emergency start’ system is a bit of electronics hidden inside a JBL Bluetooth speaker case. This gives thieves plausible deniability: if stopped by the police, they aren’t at first sight carrying obvious car theft tools, but what looks like an innocent music device. The web site lists the models of cars ‘supported’ by the theft device: Lexus models including the ES, LC, LS, NX, RX and Toyota models including the GR Supra, Prius, Highlander, Land Cruiser – and RAV4. Ian had discussions with Noel Lowdon of vehicle forensics company Harper Shaw about this device and decided to buy one to reverse engineer it. At this point I was called in to help with how the device works on the CAN bus.

Ian calls me a CAN guru: I worked with Volvo on their first CAN-based car platform and architected the first low-cost CAN hardware for small chips used in cars, my start-up company produced the CAN networking software used by Volvo in all their cars, and I was part of the team that won the Volvo Technology Award for the CAN networking system (my start-up was later sold to Bosch and today is a thriving part of Bosch’s ETAS group for in-car software technology). Together, we started to tear apart the theft device to see how it worked.

Before I go any further, I must make a disclaimer: this story will not disclose details that make it easier for someone to build a copy of the theft device. The creator is a criminal and neither I nor Ian will ever help these people. The purpose of telling this story is to help law enforcement and car makers to do something about these devices (at the end I will give some ways that car makers and their suppliers can update their ECU software to defeat thieves). I also want to emphasize that this is not something specific to Toyota: Ian investigated the RAV4 because his stolen car was a RAV4, and other manufacturers have car models that can be stolen in a similar way.

A new theft technique: CAN Injection

Modern cars are protected against thefts by using a smart key that talks to the car and exchanges cryptographic messages so that the key proves to the car that it’s genuine. This messaging scheme is generally reckoned to be secure and can’t be broken without huge resources (of the type only a nation state has). But thieves don’t attack the hard part: they find a weakness and work around it. In the past, this was done with a Relay Attack. Normally, the car asks the key by radio to prove itself, and then when it receives a valid message back by radio it unlocks the car and disables the engine immobilizer. The thieves found a simple way around this: they used a hand-held radio relay station that beams the car’s message into the home to where the keys are kept, and then relays the message from the keys back to the car. The car accepts the relayed message as valid because it is – the real keys were used to unlock the car. Now that people know how a relay attack works generally possible to defeat it: car owners keep their keys in a metal box (blocking the radio message from the car) and some car makers now supply keys that go to sleep if motionless for a few minutes (and so won’t receive the radio message from the car). Faced with this defeat but being unwilling to give up a lucrative activity, thieves moved to a new way around the security: by-passing the entire smart key system. They do this with a new attack: CAN Injection.

The diagram below shows how ECUs in a RAV4 are wired together with CAN bus (it’s a very simplified diagram and doesn’t show every ECU or CAN bus).

There are three CAN buses shown:

• A control CAN bus (which has ECUs for headlights, door control, telematics, aircon, etc.)
• A powertrain CAN bus (which has ECUs for engine control, the hybrid battery and motor control, etc.)
• An autonomy CAN bus (which has ECUs for radar, forward looking camera, and self-parking)

The way CAN Injection works is to get into the car’s internal communication (i.e. the CAN bus) and inject fake messages as if from the smart key receiver, essentially messages saying “Key validated, unlock immobilizer”. In most cars on the road today, these internal messages aren’t protected: the receivers simply trust them. You can see how it can work in the RAV4 from the wiring diagram above: thieves break into the wiring for the red CAN bus (the one the smart key receiver ECU – shown in yellow – is connected to) and then use a simple electronic device to send CAN frames on to the red CAN bus to send fake “Key is validated” messages as if from the smart key receiver. The gateway ECU (a simple device that just copies certain CAN messages back and forth) will copy that fake message over to the green CAN bus, and the engine control system (shown in blue) will accept the message and deactivate the immobilizer function.

The thieves can then use their CAN Injector device to send a different fake CAN message that the door ECU (also shown in blue) that in essence says “Key is valid, unlock the doors”. So they don’t even need to damage the car to break into it: they can simply open the door, get in, and drive the car away – all without needing the key.

The CAN injection device

Here’s what the CAN Injector theft device that Ian bought looks like:

Looks just like a JBL Bluetooth speaker. And inside it mostly still is (it’s missing the speaker).

The CAN Injector is grafted on to the JBL circuit board, enclosed in a big blob of resin. Ian melted the resin with a heat gun, worked out how it’s wired to the JBL circuit board, and even worked out what the chips are (using the technique of matching pinouts against chips until the right pattern is found).

It turns out it’s about $10 of components: a PIC18F chip that contains CAN hardware, plus software pre-programmed into the chip (known as firmware), a CAN transceiver (a standard CAN chip that turns digital signals from the CAN hardware on the PIC18F into the analog voltages sent on CAN wires), and an extra circuit connected to the CAN transceiver (more on this shortly). The device takes its power from the speaker battery, and connects to a CAN bus. A CAN bus is basically a pair of wires twisted together, and in a car there are several CAN buses joined together, either directly with connectors, or wired digitally via a gateway computer that copies some CAN messages back and forth between the CAN buses it is connected to.

The theft device is designed to be connected to the control CAN bus (the red bus in the wiring diagram) to impersonate the smart key ECU. There are several ways to get to the wires for this CAN bus, the only requirement being that the wires need to come to the edge of the car so that they can be reached (wires buried deep in the car are impractical to reach by thieves trying to steal a parked car on the street). By far the easiest route in to that CAN bus on the RAV4 is through the headlights: pulling the bumper away and accessing the CAN bus from the headlight connector. Other access would be possible: even punching a hole in a panel where the twisted pair of CAN wires goes past, cutting the two wires, and splicing in the CAN Injector would also work, but the diminished value of a car with a hole in it means thieves take the easiest route (Ian’s sleuthing found that mostly these cars are destined for export, sent via shipping container to places in Africa).

When first powered on, the CAN Injector does nothing: it’s listening for a particular CAN message to know that the car is ready. When it receives this CAN message it does two things: it starts sending a burst of CAN messages (at about 20 times per second) and it activates that extra circuit connected to its CAN transceiver. The burst of CAN messages contains a ‘smart key is valid’ signal, and the gateway will relay this to the engine management ECU on the other bus. Normally, this would cause confusion on the control CAN bus: CAN messages from the real smart key controller would clash with the imposter messages from the CAN Injector, and this could prevent the gateway from forwarding the injected message. This is where that extra circuit comes in: it changes the way a CAN bus operates so that other ECUs on that bus cannot talk. The gateway can still listen to messages, and can of course still send messages on to the powertrain CAN bus. The burst repeats 20 times a second because the setup is fragile, and sometimes the gateway is not listening because its CAN hardware is resetting itself (because it thinks that being unable to talk is an indication of a fault – which in a way it is).

There is a ‘Play’ button on the JBL Bluetooth speaker case, and this is wired into the PIC18F chip. When this button is pressed, the burst of CAN messages changes slightly and they instruct the door ECU to unlock the doors (as if the ‘unlock’ button on the wireless key had been pressed). The thieves can then unhook the CAN Injector, get into the car, and drive it away. There is CCTV of this taking place for another victim (if impatient, seek to 2 minutes 55):

The modified CAN transceiver

Let’s revisit that modification to the CAN transceiver that changes how CAN works (this section is going to go into detail about how CAN bus operates so feel free to skip to the section ‘Defeating the CAN Injector’ where I discuss how Toyota and other manufacturers stop the thieves).

Normally CAN operates as a giant AND gate, where the bus will read logic 1 if all devices are inputting logic 1, and will read logic 0 if any device inputs a logic 0. It works by the bus ‘floating’ to what’s called a recessive level: the two CAN wires H and L are each at about 2.5V, and the difference between them is close to zero (the level is floating because a CAN transceiver in recessive state is high impedance). This is translated by the CAN transceiver into a logic 1 (and the RX pin of the transceiver outputs a logic 1 to the CAN hardware embedded in the main processor chip). Any CAN controller can drive the bus to a dominant level (usually about 4.5V on CAN H and 0.1V on CAN L, with a difference of about 4.4V). But the CAN Injector has a different CAN transceiver: it has a mode where it actively drives a recessive state, and no other CAN device can drive the bus to a dominant state (one device can move the CAN H and L voltages a little bit, but not enough to change the state to logic 0).

Ian has built a benchtop CAN bus for the CAN Injector, replicating its electronics and adding pseudo ECUs (Ian has a lot of experience of this: he built a portable ‘car in a case’ emulator that is used to demonstrate car hacking techniques). A logic analyzer and oscilloscope can measure the effects of the CAN Injector on a real CAN bus. Here is a trace of an ‘ECU’ sending a CAN frame before the CAN Injector enables the dominant-override circuit:

The lines of the logic analyzer trace are:

• INJECT-TX: the TX pin into the CAN transceiver from the CAN Injector’s CAN controller
• INJECT-CS: the override enable (enabled when high)
• ECU-TX: the TX pin into the ECU’s CAN transceiver from the ECU’s CAN controller
• CAN H and CAN L: the CAN high/low signals on the twisted-pair CAN bus (these are analog signals)
• ECU-RX: the RX pin from the ECU’s CAN transceiver into the ECU’s CAN controller

This is all normal and the CAN bus is operating correctly.

Sleep and wake

At the start of the theft process, the CAN Injector sends a CAN frame to wake the CAN bus. When cars are switched ‘off’ they aren’t really off: the ECUs will go into low-power sleep mode, with a tiny power consumption. They are ‘woken’ by a frame on the CAN bus (which typically comes from a door ECU or a wireless key ECU). In the early days of CAN, this wake-up would be an edge on the CAN bus that is the start-of-frame (SOF) field of a CAN frame. But it turned out that radio interference could cause an edge on the CAN bus and cars would wake up for no reason. It became a problem for car owners who parked at the airport (where the powerful radar sweep would put an edge on the CAN bus) because when they came back from holiday they would discover the car battery was drained. Today, the state-of-the-art in wakeup is to use a System Basis Chip that is a combined CAN tranceiver, power regulator and wake-up circuit in one chip: the wake-up circuit has minimal CAN logic and is able to recognize a proper CAN frame, and because noise from a radar sweep is never going to look like a proper CAN frame, there is no spurious wake-up.

The CAN Injector wakeup frame is sent several times a second until it receives a CAN frame from a woken ECU on the CAN bus. The CAN Injector at this point has not enabled the dominant-override circuit, and so the woken ECU can send its CAN frame. The CAN Injector then engages the dominant-override and starts periodically sending its impostor CAN frame (called a spoof) pretending to be the smart key.

Dominant-override

The recessive/dominant mechanism is core to how CAN bus works: it uses this to work out which frame should go next (called arbitration), and it uses it to signal errors. The primary purpose of the dominant-override in the CAN Injector is to block other CAN devices from transmitting so that there is no clash when the spoof and the real frame are send at the same time. This clash would normally cause a long-lasting ‘loop’ of errors on the CAN bus, and is actually the topic of my first CAN Quiz question:

When the CAN Injector actively enables its dominant-override then it effectively blocks other CAN devices from transmitting on the bus and forces its own spoof frames to be the only ones received. The blocking doesn’t just stop other frames, it also blocks the error mechanism of the CAN protocol, so that other ECUs cannot raise an error to stop the CAN Injector spoof frames. This is the secondary purpose of the dominant-override mechanism: it is able to defeat CAN security hardware. For example, the silicon vendor NXP has product called the Stinger that is a CAN transceiver with security logic built-in that detects a spoof frame and destroys it with a CAN error. The CAN-HG system from Canis Labs is also able to detect and destroy spoof frames with CAN errors. But approaches based on CAN errors cannot defeat the CAN Injector with its modified transceiver – because that prevents any single CAN device from signalling a dominant state.

When blocked from setting a dominant state, the CAN controller gets stuck in a loop trying to send a CAN frame, gives up, and then may try again later. This was the subject of my second CAN Quiz question, and used a particular CAN controller (that is almost never seen in production vehicles) to illustrate the problem (a real ECU will have a more sophisticated network management approach to how it tries to rejoin a CAN bus after what appears to be a hardware fault).

The logic analyzer trace below shows how an ‘ECU’ on Ian’s benchtop CAN bus tries to send its own CAN frame but fails when the dominant-override is enabled.

In the trace, INJECT-CS is high, enabling the override. INJECT-TX is high, a recessive bit. Normally this is CAN idle, and other CAN controllers can start sending a CAN frame by entering arbitration. The ECU-TX line shows a CAN frame beginning with start-of-frame (which in CAN is a dominant bit) but it cannot drive the bus to a logic 0 (ECU-RX is stuck at logic 1), and so goes through the defined CAN error recovery process (this is described in more detail in the second CAN Quiz question). The voltages on the CAN H and CAN L wires are shown, and the ‘ECU’ has managed to move these voltages a small amount, but not enough for this to be seen by any CAN transceivers (including its own transceiver) as a dominant bit (as seen in the ECU-RX line on the trace that is stuck a logic 1).

There is a potential problem with blocking ECUs from sending dominant bits: the CAN ACK field. The ACK field in CAN frame is a 1-bit field and is used by a transmitter to know that there is at least one device listening and that has received the frame OK. A transmitter sends a logic 1 for the ACK (i.e. a recessive bit) and expects to read it back as a logic 0 because normally all receivers send a logic 0 (i.e. a dominant bit) to say they have received the frame OK. If a receiver tries to send a logic 0 but reads back a logic 1 then the CAN protocol treats that as an error – and it won’t accept the frame. And that would mean that the gateway ECU in the RAV4 would not receive the spoofed smart key ECU frame. And in turn that would mean the spoofed frame would not be forwarded to the powertrain CAN bus for the engine management system to see. However, it turns out not to be an actual problem: because multiple CAN receivers are sending a logic 0 at the same time, and when they all do this together, the combined transceivers are able to overpower the dominant-override circuit and drive a dominant state on to the bus. This can be seen in the following trace: there are a total of four ‘ECUs’ on the benchtop CAN bus here, and together they are able to move the voltages to the level required for a dominant state on the bus and a logic 0 in the ACK field of the spoof frame sent from the CAN Injector. And so all ECUs receive the CAN Injector spoof frame OK.

Defeating the CAN Injector

First, the good news. A CAN Injector can be defeated, and it can be defeated with a pure software fix, so existing cars can be updated and once again we can avoid fitting a mechanical steering wheel lock at the end of each journey. There are two levels of fix:

• Quick and dirty. This relies on knowledge of how the CAN Injector currently works and can make a small change that stops it working. It won’t be a permanent fix: the criminal who designed the CAN Injector can then respond with changes, and it will likely start working again. But this can buy time for the next fix.
• Cryptographic messaging. This uses encryption and authentication codes to protect CAN frames so that the CAN Injector cannot create valid spoof frames. If implemented properly, this is a permanent fix. But it requires some effort (more on that shortly).

These fixes apply to all makes and models of car vulnerable to a CAN Injection attack (this is an industry-wide issue, not limited to any manufacturer or model).

Quick and dirty fix

The CAN Injector at present causes mayhem on the control CAN bus: by driving the bus recessive, it causes ECU CAN controllers to fail to transmit, and to fail with a particular type of CAN error: a dominant-to-recessive bit error. This is very rare, and usually indicates a hardware fault (you can see this from the DTCs dropped). The gateway ECU (or engine immobilizer ECU in a different model) could monitor its CAN controller to see if these errors occurred, and follow Ian Fleming’s maxim: “Once is happenstance, twice is coincidence, and three times is enemy action”. So the gateway could be re-programmed to only forward a smart key CAN frame if it has recently transmitted a CAN frame without problems, and in the recent past there have been no bit errors of this type on the CAN bus. The definition of ‘recent’ could be a few seconds, which would solve the problem of false positives (where there actually was a rare but real fault): the driver can simply wait a short time and try again.

This quick and dirty fix can be defeated by changing the CAN Injector (we won’t be disclosing how). But the brutally crude way this CAN Injector works today suggests that would take a while. This should buy car makers some time to apply a proper fix.

Cryptographic messaging fix

The proper solution to a CAN Injection attack is to adopt a Zero Trust approach to CAN – or at least to specific messages on specific CAN buses. A Zero Trust approach means that an ECU does not automatically trust messages from other ECUs but requires some proof that they are genuine. A good approach to this is to use a Hardware Security Module (HSM), and the automotive industry have defined a standard for one (called Secure Hardware Extensions, or SHE). Normally, this would mean using chips that include the hardware, making a retrofit impossible. Fortunately, a software emulation of an HSM is possible, and Canis Labs have done that for the SHE HSM: it requires about 3Kbyte of code and 200 bytes of RAM. And using the software to encode or decode a protected CAN message takes about 40 microseconds of CPU time. ECU firmware typically will have some spare memory, and would likely need about 0.05% of the total CPU time. In other words, it ought to be straightforward to fit this into new firmware (in fact, Canis Labs have been successfully working with the US Army under an R&D contract to retrofit an encryption scheme for CAN to military vehicle ECUs).

This approach of using encryption does mean more significant changes than the quick and dirty fix:

• Cryptographic messages use extra CAN bandwidth to carry authentication codes (the CryptoCAN scheme devised by Canis Labs uses a pair of encrypted CAN frames to send one plaintext CAN frame; other schemes use half the payload of a CAN frame).
• ECUs have to be provisioned with secret keys (typically at the factory) so that each vehicle uses different keys (otherwise the creator of a CAN Injector just needs to buy one vehicle and use sophisticated benchtop tools to extract the keys once and then they can break into any car). ECUs may also need to have their keys re-provisioned: if an ECU needs to be replaced or moved to a different vehicle, it needs to have new keys that match the ones stored in the other ECUs.

The first change is not too bad to undertake, since only one or two CAN frames need to be protected (and so only very little CAN bus bandwidth overall is needed). But the second one requires that key management and distribution infrastructure be built (which at least must include tools to inject keys, and a database that stores the keys). Adopting the SHE HSM standard does at least mean that these tools are standardized and off-the-shelf solutions are possible. However, car makers have learned over the years to act carefully when making changes to vehicle systems: what appears to be quick and simple often turns out to not be, and even a simple fix requires extensive testing to make sure there are no unintended consequences. So it will take some time to implement this.

Next steps

Ian has tried to get in touch with Toyota to discuss the CAN Injection attack, and to offer help, but hasn’t had much success. Part of the problem is that any large corporation finds it difficult to respond to security issues. And part of the problem is that this isn’t a vulnerability disclosure and so the processes that Toyota does have in place are not appropriate. The normal vulnerability disclosure process is that an ethical hacker finds a vulnerability that criminals potentially could exploit, gets in touch with the vendor, who gets time to fix it. This is known as a Zero Day (because the manufacturer has to act quickly, having potentially just zero days to find a fix before a criminal exploits it). The CAN Injection attack is not a Zero Day: it’s more like a Minus 365 Day because criminals have already been exploiting it to steal cars (and extensively: there has been a spike in keyless car thefts, with law enforcement just assuming that these are relay attacks). There is no risk that describing a CAN Injection attack will lead to criminals exploiting it: they are already exploiting it widely, and their exploitation of it with Ian’s car was what caused Ian to become a digital forensic detective.

Vehicle access

So far, Ian has tried to get access to a RAV4 to test that his benchtop CAN bus accurately captures the full behavior of the CAN Injector. Access would also allow the real CAN Injector to be tested in situ with tools (including an oscilloscope and logic analyzer). This can’t be done without access to a dealer workshop and a car, because the attack causes a rash of DTCs that have to be reset with the proper authorized tools. Getting access has not been possible so far. Any car maker or industry body that wishes to engage with CAN Injection attacks should feel free to get in touch.

Firmware reverse engineering

A full analysis of how the CAN Injector works should include reverse engineering its firmware. The PIC18F used in the CAN Injector has been locked to prevent its firmware from being read out, but there are at least two techniques to break that lock. However, neither can be done without risking destruction of the device and one of the techniques requires access to expensive specialist equipment. This goes beyond amateur sleuthing and requires proper resources. Ideally, an industry body dedicated to car security would take over the project and become a focal point for car makers who want to understand how thieves are using CAN Injection and adopt the most practical ways to defeat them.

原文始发于Ken：CAN Injection: keyless car theft