My name is Jason Staggs. This is my second time here at DEF CON. I was here last year
at DEF CON 20. I had a great time, met a lot of really cool people doing some really interesting
stuff. And I'm just glad to be back again here this year to really live the experience.
So the title of my talk is how to hack your Mini Cooper reverse engineering controller
area network messages on passenger automobiles. So a little bit about me. First and foremost,
I am a graduate student of computer science at the Institute for Information Security
at TU. I'm also currently finishing up my master's thesis related to drive‑by‑download
attack mitigation. I also have very strong research interests in network intrusion detection
systems and critical infrastructure protection, digital forensics, and most recently, vehicle
network security, which I carry out through TU.
TU's Crash Reconstruction Research Consortium, which is directed by Dr. Jeremy Daly. He was
actually a professor of mechanical engineering who quite literally wrote the book on automotive
collision reconstruction fundamentals. So we're very fortunate to have somebody with
this caliber of expertise leading those efforts. And then before I came to TU, I was actually
a cybersecurity analyst for an information security firm in Tulsa, Oklahoma. And I was
working with a company called True Digital Security.
So who here in the audience remembers Tim Burton's Batman Returns from like the early
90s? Okay. Several of you. Good. Good. There's a scene actually in the movie where Batman
parks his Batmobile behind a building in a back alley somewhere. He then leaves it and
takes off to, you know, attend to his crime‑fighting business. And then all of a sudden, the Penguin,
and his gangster thugs come out of the building, and he's like, what's going on? What's going on?
And the thugs sort of stumble across the Batmobile and they start playing with it. They start
taking things apart. And then all of a sudden they attach a little wireless gizmo to the
Batmobile designed to interface with the actual computer systems on the car. They basically
reassemble everything they take off. Batman comes back later on that night, hops in his
Batmobile and goes off and leaves. And then all of a sudden the Penguin kind of appears
on the infotainment screen and says,
Gentlemen, start your engines. And then from that point forward, Batman is frantically
trying to stomp on the brake pedal. And as the Penguin is basically wreaking havoc on
the citizens of Gotham City. A scenario such as that back then was somewhat near impossible,
considering all the mechanical devices that were used to control the various components
of the vehicle. But today a scenario such as that is actually fairly realistic. So what
got me interested in vehicle network security was some research that was put out by the
University of Washington and the University of California San Diego back in 2010 and
2011. What they did originally was they actually did an empirical study to see how resilient
the computer systems on vehicles were to digital attacks. And the short answer to that is they're
not too resilient whatsoever. Surprise, surprise.
So in their first paper they actually were able to compromise various systems on the automobile.
Assuming the attacker had physical access to the bus, what all could they do? And they were able to
take full control of, like I said, the brakes, the accelerator pedal, body control mechanisms
such as the locks, interior and exterior lighting, basically everything. They later received some
criticism from automotive manufacturers saying, yeah, well, you were able to do that, but you had
no access to the car anyways. Why not just cut the brake lines? Well, okay.
So the following year they put out some more research. Basically they were able to carry
out the same types of attacks. Basically by taking advantage of some vulnerabilities
and some short wave radio communication, such as Bluetooth, and a telemetry device.
So at TU, you know, we're interested in doing this type of research. We're interested in
doing this type of research as well. We also do chip level forensics on ECUs, so the actual
systems on the actual vehicle networks themselves. We also assess the accuracy of the actual
pre crash and crash data stored on event data recorders, so the little black boxes that
automobiles contain. And then we want to be able to understand these systems and networks
at a very low level and be able to understand the potential points of vulnerability on these
systems and networks. But most importantly, we want to be able to prevent something like
this from turning into this because of this. So what you guys are looking at right here
on the table, I'm sure a lot of you can't see it in the back, what we're calling it
is the CAN clock. It was actually a project that was the outcome of a research‑driven class that I
worked with last semester called Vehicle Communication Systems. That was co‑taught by Dr.
Daly and Dr. Mauricio Papa, who is a computer scientist and who specializes in computer
networks. It was designed originally as a proof of concept to demonstrate that, you know,
what a rogue ECU device could do if it was attached to a CAN bus. And the overall goal was to
actually transform the instrument cluster from the Mini Cooper into a functional cluster.
So there was literally two problems. Actually, I know I had no prior knowledge to how these
systems work beforehand. So I had to build a CAN bus from scratch. And then also with passenger
automobiles, the actual message IDs themselves that are responsible for controlling the various
devices and functionality of the systems on the vehicle are proprietary in nature. So some
reverse engineering methods were used to identify the message IDs themselves.
So it's actually quite common for vehicles to have multiple types of networks in place on
these vehicles. If you have a car that was manufactured on or after 2008, then by law you
actually have CAN, whether you know it or not, on your vehicle. If you're curious to see whether
or not you have a CAN‑enabled vehicle, you can do a voltage check on pins 6 and 14 on your
diagnostic connector underneath your steering wheel.
Network protocols such as FlexRay, LIN, MOST, MOST being more of a high‑speed solution
for multimedia applications within vehicles. J1850, J1939 is actually the protocol used
for the heavy trucking industry. That sort of sits on top of CAN. And then what we're
looking at right here is actually ‑‑ there's a lot of information out there that we don't
have access to. It's a data bus diagram of the Mini Cooper itself. As you can see, there's
actually four different networks here that are all interconnected with the actual instrument
cluster, believe it or not, acting as a gateway. And these systems are actually kind of segmented
based on common functionality and information that they share between one another.
So when we're talking about CAN, controller area networks, it was actually developed by
Robert Bosch back in the 80s. It was developed by Robert Bosch back in the 80s. It was actually
as a method for basically communication between embedded systems with a bus style topology
within vehicles. Prior to CAN, a lot of the solutions for networking embedded systems
on vehicles sort of called for more of a ring style mesh topology where nodes were
sort of interconnected and dependent upon one another. So if one node were to fail,
that could potentially affect the other node on the vehicle.
And this was somewhat of a nightmare from a service technician's point of view trying
to troubleshoot these networks. So CAN was actually designed to be a very resilient networking
protocol and standard designed to withstand harsh operating environments such as the heats
and the colds, electromagnetic interference, those sorts of things.
And then automotive manufacturers from, like, European automotive manufacturers were early
adopters of the standard. So BMW, Mercedes, Volkswagen, Volvo, those guys were early adopters
of the standard. And CAN is actually a multi‑master broadcast bus system. So the idea obviously
being that if one node were to transmit a message, then all other nodes on the bus would
actually receive that message. Whether or not a node actually processes that message
is dependent upon something called access filters.
I'm sorry, acceptance filters on the actual CAN controller itself. So if a message matches
up with the actual acceptance filter, it then gets passed on to the micro controller
for further processing. Otherwise it's disregarded. And there's ‑‑ with CAN there's no notion
of source addresses. So it's nearly impossible to identify where a message actually came
from. Which is sort of a problem. And CAN actually comes in two flavors. So there's
the standard format.
Which is used on the passenger automobiles. And then there's the extended format.
With the standard format, it uses 11‑bit message ID. And then, like I said, in automotive,
the passenger automobile world, these message IDs are actually proprietary. But when we're
talking about something like G1939, which is the protocol for the heavy trucking industry,
it uses a 29‑bit message ID.
And actually this whole standard is fully documented. So if somebody was wanting to
create a message designed to maybe override a brake controller, all they would have to
do is refer to the society of automotive engineers documentation for G1939 to construct such
a message. Here's what a CAN frame looks like. So with CAN frame, the actual payload portion of it is
up to 8 bytes which I thought was somewhat limited compared to like stuff like Ethernet
which can be up to 1500 bytes. And so the way ‑‑ one of the cool things about CAN
is the way it handles arbitration. So if two nodes are attempting to transmit at the same
time, obviously perform a collision, the way it handles arbitration is based on the identifier,
the message ID itself. So the idea being a node trying to transmit a message with a
lower message ID has higher precedence than another node trying to transmit a message
with a higher message ID. And then the actual computer systems on CAN networks or vehicle
systems for that matter, we call ECUs, electronic control units. And these are designed to control
a variety of features on the vehicle.
Everything from vehicle safety critical systems to non‑safety critical systems. And these
devices are for the most part programmable which is nice from the automotive manufacturer
point of view because if there's a flaw or vulnerability discovered within one of these
devices, they can just push out new firmware updates or patches or whatever, software updates
as opposed to physically removing these devices. And then the average modern‑day luxury vehicle
has somewhere on the order of 70 or so ECUs.
All right. So let's get back to the actual CAN clock instrument cluster thing that I
built here. So what we want to do is we want to be able to manipulate the tachometer and
the speedometer. The problem with that is manufacturers don't publish the actual CAN
IDs or specific payload information in order to manipulate these accordingly. So we actually
use several methods to actually figure out how we control the various functionality.
The first one was we developed a method for visually correlating physical system interactions
with identifiable patterns. You'll see what I'm saying here in a minute. But humans are
inherently good at this. We're inherently good at seeing patterns that we recognize
on a graph. Maybe something that's indicative of vehicle speed or engine speed. And then
for the ones that we weren't able to use this method on, we used some simple fuzzing techniques
to identify.
The various functionality that we're interested in. And my demo right now, the lighting is
causing some issue. But afterwards, if you guys want to see this, I'll be out in the
hallway or the chill‑out lounge and I'll be happy to demonstrate it for you guys.
So the actual instrument cluster from the Mini Cooper was salvaged from a wreck Mini
Cooper that was involved in a stage automotive collision with a GMC Envoy. Before these cars
were actually involved in the automotive collision.
They were outfitted with an external, like, instruments to measure such things as vehicle
speed. And then we would correlate that data with the data on the CAN bus itself to verify
its accuracy.
And this capture lasted for roughly 90 seconds. And over the course of that capture, it gave
us around 106,000 actual messages on the CAN bus.
I'll show you guys.
Just a little bit of the crash.
As you can see, the Mini Cooper didn't really stand much of a chance whatsoever.
Oh, so we also actually hooked up the
data logger to the actual CAN bus itself to record all the messages, obviously, on
the bus. And then here's kind of the raw output of that. So message IDs and raw payload information.
Then we did like a unique basically on all the message IDs to see which IDs actually occurred.
And then a frequency count to see actually how many times a message was transmitted on
the bus during that capture. And then we started to play with the ones that were most occurring
first.
So back to the method of visually identifying CAN messages of interest based on plotting
the data on graph. If we're interested in vehicle speed, we basically started to play
with suspect message IDs and then for each byte offset in the payload, we would plot
the data until we saw something that was indicated of vehicle speed, such as the third one right
here. And then for the
So if you noticed in the video I just showed you, both the cars were actually being pulled
together like with a pulley system for the collision.
So the actual engine speed itself was at an idle state the entire time.
So we basically had to use some simple fuzzing techniques on the data fields of the suspect
message IDs until the tachometer basically started flipping out of control and the needle
started spinning like crazy.
So that was kind of interesting.
So up until now we've actually identified, you know, the message IDs responsible for
the speedometer and the tachometer as well as the payload and the data offsets for those.
So then we just built a simple CAN bus.
We used some 18 gauge wire, 220 ohm terminating resistors, 12 volt power source, an Arduino
with a CAN bus shield that had an MCP2515 CAN controller.
And an 8 volt power source.
And an MCP2551 CAN transceiver.
The instrument cluster obviously.
And then a real time clock module for implementing the clock functionality.
And all this is available on our site, full step by step tutorial and procedure as well
as a source code for this.
And here's an image of what it looked like early on in the prototyping stages.
It's kind of a mess.
And then as far as talking CAN with the Arduino, we just used basically a CAN controller library.
That was designed to communicate with the MCP2515 that allowed us to construct basically
CAN frames and then inject them onto the bus.
And then so basically there's two modes of operation.
There's the clock mode and then there's the demo mode.
So demo mode being just like incrementing the speedometer and the tachometer.
Like I said, I'll show you guys a demo afterwards if you're interested.
All right.
So one might think, okay, so if you have physical access to the car anyways, oh, well.
But there's a bunch of possible scenarios in which case like potential conspirators like
service technicians and mechanics, car rental companies, coworkers, family, friends, ex-girlfriends
could potentially have momentarily access to your CAN bus or car and they could attach
a row ECU kind of like the one I built here.
For less than $100.
So that's kind of a problem.
And they could attach whether that be to the OBD2 port underneath the steering wheel or
tapping the CAN bus via vampire tap style either under the hood or by some other means.
So what's surprising to me is that the actual access control, I guess, between the CAN bus
and ECU and ECU or network to network on vehicles is somewhat nonexistent or the ones that have
been ‑‑ or the ones that are in existence aren't very good and they're easily bypassed.
So maybe applying conventional network security techniques such as like maybe network intrusion
prevention systems of some kind or some firewall methods to these networks might provide a
better solution.
And then maybe some sort of like message anomaly prevention.
Depending on the context of other messages present on the CAN bus at the time.
So maybe there shouldn't be a message that says, okay, someone's trying to apply full
throttle to the accelerator but at the same time they're trying to, you know, apply full
pressure to the brakes.
And then if you're ‑‑ in case you're interested in some of the research that we're doing,
here's some links to our sites.
And some of the stuff that we're working on.
Like I said, a full tutorial and source code is available on our site.
So feel free to check out our stuff.
And I'll be out running around.
So if you see me around here, feel free to come out and ask me questions.
If you have some questions or ideas or concerns, feel free to e‑mail me.
Thank you very much.