 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. A lot of really cool people doing some really interesting stuff. And I'm just glad to be back again here this year to relieve 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's crash reconstruction research consortium which is directed by Dr. Jeremy Daley who is 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 his 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 called True Digital Security. So who here in the audience remembers Tim Burton's Batman Returns from like the early 90's? 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 attend to his crime fighting business. And then all of a sudden the pink one and his gangster 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 pink one 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 pink one 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 originally 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, you know, 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're 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 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 we're interested in doing this type of research as well. We also do chip-level forensics on ECU, 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 was involved with last semester called Vehicle Communication Systems. That was co-taught by Dr. Daly and Dr. Maricio Papa, who is a computer scientist and who specializes in computer networks. It was designed originally as a proof of concept 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 were literally two problems. Actually, I know I had no prior knowledge of 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 pin 6 and 14 on your diagnostic connector underneath your steering wheel. Network protocols such as Flexray, Lin, most being more of a high-speed solution for multi-media 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 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 the 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 to 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 and 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 technicians 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, and 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 microcontroller for further processing. Otherwise it's disregarded. 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 a standard format which is used on the passenger automobiles. And then there's the extended format. With a standard format, it uses 11-bit message ID. And then, like I said, 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 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 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 eight 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 attempting to transmit at the same time, obviously form a collision, the way it handles arbitration is based on the identifier, the message ID itself. So the idea of being a node trying to transmit a message with a lower message ID has higher precedence to 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, you know, 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 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 know, you'll see what I'm saying here in a minute. But humans are 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 use 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. And then 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 lasts 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 the crash. And as you can see, the Mini Cooper didn't really stand much of a chance whatsoever. Oh, so we also actually hooked up a data logger to the actual CAN bus itself. They 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. And then we did like a 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 visually identifying CAN messages of 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 indicated of vehicle speed, such as the third one right here. And then for the tachometer, so if you noticed 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 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, 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. And our Arduino with a CAN bus shield that had a MCP 2515 CAN controller and an MCP 2551 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 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 a basically CAN controller library that was designed to communicate with the MCP 2515 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 means just like incrementing the speedometer and the talkometer. Like I said, I'll show you guys a demo afterwards if you're interested. So, you know, one might think, okay, so if you have physical access to the 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 potentially have momentary 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 a hundred dollars. 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 ECU and ECU or network to network on vehicles is somewhat non- existent or the ones that I had been or the ones that aren't 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, some kind of 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 email me. Thank you very much.