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.
