How to Hack Your Mini Cooper: Reverse Engineering Controller Area Network (CAN) Messages on Passenger Automobiles
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 112 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/38934 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 2170 / 112
3
6
8
9
13
14
15
16
17
22
23
24
25
29
32
33
36
37
39
42
45
47
49
53
60
61
64
65
66
71
76
79
80
82
89
103
106
108
00:00
CAN busReverse engineeringMessage passingCAN busMultiplication signReverse engineeringBitMessage passing
00:24
Personal digital assistantDigital signalInformation securityInformationCrash (computing)CybersexCrash (computing)Student's t-testComputer networkDigitizingCybersexHypothesisInformation securityBitFundamental theorem of algebraCollisionIntrusion detection systemComputer scienceComputer forensicsComputer animation
01:32
Information securityMathematical analysisCommunications protocolComponent-based software engineeringCAN busComputer networkSurfaceMessage passingAuthenticationSystem programmingComputerPoint (geometry)Vector potentialVulnerability (computing)Computer networkComputerType theoryComputer forensicsLevel (video gaming)Event horizonControl systemData loggerGoodness of fitBlack boxFlow separationDemosceneQuicksortBuildingTouchscreenPhysical systemInterface (computing)Crash (computing)InfotainmentMetropolitan area networkObservational studyPoint (geometry)Vector potentialInterior (topology)Bus (computing)Vulnerability (computing)RingnetzConnectivity (graph theory)InterprozesskommunikationInformation securityGame controllerComputer animation
05:04
CAN busComputer networkReverse engineeringMessage passingProof theoryProof theoryMessage passingTable (information)Reverse engineeringBus (computing)Social classFunctional (mathematics)DampingComputer scienceProjective planePhysical systemNatural numberComputer networkCAN busInterprozesskommunikationComputer animationLecture/Conference
06:28
CAN busCommunications protocolComputer networkMessage passingMultiplicationPhysical systemStandard deviationFile formatIntrusion detection systemAreaGame controllerFrame problemCyclic redundancy checkUniqueness quantificationData transmissionPlug-in (computing)Integrated development environmentCodeMessage passingRight angleDiagramBus (computing)Functional (mathematics)Gateway (telecommunications)Communications protocolPhysical systemFile formatInterprozesskommunikationStandard deviationFrame problemQuicksortGame controllerRingnetzMultiplicationComputer wormRing (mathematics)MicrocontrollerSource codeVermaschtes NetzService (economics)Point (geometry)Workstation <Musikinstrument>Operator (mathematics)View (database)Spektrum <Mathematik>Integrated development environmentBroadcasting (networking)Filter <Stochastik>SubsetProcess (computing)CAN busAddress spaceBitComputer networkInformationConditional-access moduleType theoryCollisionMultiplication signPhysical lawPlastikkarteIdentifiabilityVery-high-bit-rate digital subscriber linePersonal identification numberCartesian coordinate systemMultimediaSet (mathematics)AreaComputerIntrusion detection systemComputer animation
11:37
System programmingControl flowPhysical systemAbsolute valueMaß <Mathematik>TelecommunicationPhysical systemMereologyView (database)Vulnerability (computing)Point (geometry)ComputerPatch (Unix)Computer networkFirmwareGame controllerOrder (biology)SoftwareExecution unitTelecommunicationVariety (linguistics)CAN busAverageComputer animation
12:25
Component-based software engineeringCAN busMessage passingInformationPhysical systemLatent heatIdentifiabilityComputer wormReverse engineeringWebsiteMotion captureVideoconferencingLatent heatGraph (mathematics)IdentifiabilityFuzzy logicComputer worm1 (number)Motion captureCollisionIntrusion detection systemPhysical systemDemo (music)Level (video gaming)InformationOrder (biology)MeasurementMessage passingInteractive televisionFunctional (mathematics)Bus (computing)Pattern languageCAN bus2 (number)Right angleComputer animation
14:15
Reverse engineeringMessage passingCAN busWebsiteVideoconferencingCrash (computing)CAN busData loggerComputer animationLecture/Conference
14:33
E-learningReverse engineeringMessage passingCAN busWebsiteVideoconferencingFrame problemCyclic redundancy checkUniqueness quantificationData transmissionStandard deviationPlug-in (computing)Integrated development environmentCodeMotion captureBus (computing)Message passingTrailComputer animationLecture/Conference
14:55
CAN busUniqueness quantificationRippingMessage passingIntrusion detection systemFunction (mathematics)Moving averageComputer wormMessage passingIntrusion detection systemInformationRaw image formatFrequencyMultiplication signCounting1 (number)Bus (computing)Motion captureCAN busComputer animation
15:18
Message passingCAN busComputer wormMessage passingIntrusion detection systemRight angleGraph (mathematics)Computer animation
15:44
Message passingCAN busGUI widgetPlot (narrative)Field (computer science)TouchscreenReverse engineeringPhysical systemVideoconferencingState of matterField (computer science)CollisionFuzzy logicMultiplication signMessage passingGame controllerIntrusion detection systemComputer animation
16:16
ComputerGauge theorySource codeMicrocontrollerCAN busModul <Software>Asynchronous Transfer ModeReal numberGame controllerBuildingComputer networkDemosceneProcedural programmingWebsiteComputer wormGame controllerGauge theoryVoltmeterModul <Software>Conditional-access moduleSource codeReal-time operating systemBus (computing)Message passingFunctional (mathematics)CAN busPower (physics)Computer animation
16:59
CAN busGame controllerAsynchronous Transfer ModeDemo (music)Military operationLevel (video gaming)Medical imagingCAN busAsynchronous Transfer ModeDemo (music)Bus (computing)Library (computing)Frame problemWater vaporOperator (mathematics)Game controllerComputer animation
17:38
CAN busAuto mechanicTape driveComponent-based software engineeringContext awarenessMessage passingComputer networkZugriffskontrolleFirewall (computing)RippingSoftware testingCrash (computing)InformationDemo (music)CodeCASE <Informatik>Source codePressureWebsiteLink (knot theory)Computer networkInformation securityMessage passingFamilyService (economics)Bus (computing)Row (database)1 (number)Mechanism designQuicksortVector potentialExistenceFirewall (computing)Multiplication signPhysical systemContext awarenessGame controllerCAN busComputer animation
19:51
Computer animationLecture/Conference
Transcript: English(auto-generated)
00:00
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. There are 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 have the experience. So the title of my talk is how to hack your Mini Cooper reverse engineering controller area network messages on passenger automobiles.
00:25
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
00:41
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's crash reconstruction research consortium, which is directed by Dr. Jeremy Daley. He was actually
01:05
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 his caliber of expertise leading those efforts. And then before I came to TU, I was actually
01:23
a cyber security analyst for an information security firm in Tulsa, Oklahoma 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
01:44
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 sort of stumble across the Batmobile
02:01
and they start playing ‑‑ 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.
02:24
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
02:44
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 originally got me interested in vehicle network security was some research that was
03:02
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
03:22
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, you know, what all could they do? They were able to take full control of, like I said, the brakes, the accelerator
03:43
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 physical access to the car anyways, why not just cut the brake lines? Well, okay. So the following year they put out some
04:05
more research. Basically they were able to carry out the same types of attacks basically by taking advantage of some vulnerabilities and some shortwave radio communication such
04:20
as Bluetooth and a telemetry device. So at TU 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
04:43
pre‑crash and crash data stored on event data recorder, 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
05:05
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
05:21
it is the CAN clock. It was actually a project that was the outcome of a research‑driven class that I was involved with last semester called vehicle communication systems. That was co‑taught by Dr. Daley and Dr. Mauricio Papa, who is a computer scientist and who specializes in computer networks. It was designed originally as a proof of concept
05:44
to demonstrate 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 clock. So there was literally two problems. Actually
06:04
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
06:25
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
06:40
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 pin 6 and 14 on your diagnostic connector underneath your steering wheel. Network protocols such as flex ray, LIN, MOST,
07:04
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 the
07:29
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 the gateway. And these systems are actually kind of segmented
07:45
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 to actually as a method for basically communication between
08:04
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 the ring style mesh topology where nodes were sort of interconnected
08:21
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
08:47
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 your BMW, Mercedes,
09:05
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
09:25
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 microcontroller for further processing. Otherwise it's disregarded.
09:41
And 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 that uses
10:07
11‑bit message ID. And then like I said, in the automotive, the passenger automobile world, these message IDs are actually proprietary. But when we're talking about something like J1939, which is the protocol for the heavy trucking industry, it uses
10:24
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
10:40
for J1939 to construct such a message. Here's what a CAN frame looks like. So with a CAN frame, the actual payload portion of it is limited to up to 8 bytes, which I thought was somewhat limited compared to like stuff like Ethernet, which can be up to
11:03
1,500 bytes. And so the way ‑‑ one of the cool things about CAN is the way it handles arbitration. So if two nodes attempting to transmit at the same time, obviously perform a collision, the way it handles arbitration is based on the identifier, the message ID
11:22
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
11:44
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
12:05
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
12:23
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
12:45
manipulate these accordingly. So we actually used several methods to actually figure out what's, you know, 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
13:04
inherently good at this. We're inherently good at seeing, you know, 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. In my
13:23
demo right now, the lighting is causing some issues, 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. And then so the actual instrument cluster from the Mini Cooper was salvaged from a rec Mini Cooper that was involved in a stage automotive
13:41
collision with a GMC envoy. Before these cars were actually involved in the automotive collision, they were outfitted with 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
14:09
of that capture, it gave us around 106,000 actual messages on the CAN bus. I'll show you guys the crash. As you can see, the Mini Cooper didn't really stand much of a
14:29
chance whatsoever. So we also actually hooked up a data logger to the actual CAN bus
14:52
itself to record all the messages obviously on the bus. And here's kind of the raw output of that. So message IDs and raw payload information. And then we did like a
15:03
unique basically on all the message IDs to see, you know, 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 the visually identifying CAN messages of
15:22
interest based on plotting the data on a 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 indicative of vehicle speed such as the third one right here. And then for the tachometer, so if you
15:50
notice in the video I just showed you, both of 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
16:04
fuzzing techniques on the data fields of the suspect message IDs until the tachometer basically started flipping out of control and the needle starts spinning like crazy. So that was kind of interesting. So up until now, we've actually identified, you know,
16:20
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, a 12‑volt power source, an Arduino with a CAN bus shield that had an MCP2515 CAN controller and an
16:44
MCP2551 CAN transceiver, the instrument cluster obviously, and then a realtime clock module for implementing the clock functionality. All this is available on our site, a full step‑by‑step tutorial and procedure, as well as the source code for this. And here's
17:00
an image of what it looked like early on in the prototyping stages. It's kind of a mess. And as far as talking CAN with the Arduino, we just used basically a CAN controller library that was designed to communicate with MCP2515 that allowed us to construct basically CAN frames and then inject them onto the bus. And then so basically
17:29
there's two modes of operation. There's the clock mode and then there's the demo mode. So demo mode means just like incrementing the speedometer and the tachometer. Like I said, I'll show you guys a demo afterwards if you're
17:43
interested. So, you know, one might think, okay, so if you have physical access to a car anyways, you know, oh, well. But, you know, there's a bunch of possible scenarios in which case like potential conspirators like service technicians and mechanics, car rental companies, co‑workers, family, friends, ex‑girlfriends could
18:04
potentially have momentarily access to your CAN bus or car and they could attach a road 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 OBD 2 port underneath the
18:24
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
18:42
guess, between ECU and ECU or network to network on vehicles is somewhat nonexistent or the ones that are in existence aren't very good and have 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
19:05
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 should be a message that says, okay,
19:23
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,
19:41
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 roaming 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.