 So did anyone see the talk I gave here last year? A few people. Okay. The first little bit of this, you can choose to go get a beer and come back if you want. It might be a little bit of a repeat, but there will be new things, I promise. So, contact OpenTools Automotive. This is a project I've been working on for the last year and a half almost now. And the goal is to create some new tools that make it cheaper, easier, and more open for people that want to mess with cars. So, on a security note, automotive security, it's been this really big topic lately. You might have seen some big news about it, especially last year. Why? Well, automotive systems were never really designed to be secure, which makes them really great targets. The security often is just bi-obscurity. They just kind of hide stuff and hope that you don't go looking. And this worked for a very long time, really from early 2000s when CAN started being a thing, or even way back to 1991 when OBD was first mandated for diagnostics, because accessing these protocols like CAN and vehicles was hard and expensive. You'd have to drop a good amount of money to get the right tools to play with it. And researchers that are typical security folks, they don't really know this CAN thing. They don't know anything about the automotive world because it really was never involved with security until more recently. But there is kind of a theme that once we connect to IP, things really have changed. And you'll see this in other industries too, things like industrial control systems or SCADA. Once things connect to the internet, bad things happen. These are two bad things that happened in the last year. One was, of course, the Fiat Chrysler hack that we saw, which involved a remote exploit on the infotainment system in the Jeep Cherokee. And the other one was more recent in February of this year, where the app for accessing remote features on the Nissan Leaf, it turned out that all you needed was the VIN number of a car in order to authenticate. Now, the VIN number is the thing that's printed on the front of the car. Probably, it's like a post-it note with the password on it on the car. So yeah, once you connect things to IP, things break down pretty quick. But inside the car we use this thing called CAN. It's existed since 1989. It kind of became popular in early to mid-2000s. And as of 2008, it's required in all vehicles sold in the US for diagnostics. So you'll find it in basically every car on the road today. And it stands for Controller Area Network. And it's low cost and has integrated controllers. So you can buy a microcontroller. And in fact, most of you have one around your neck right now that actually has CAN on it. The badge for Norsak is using an ST micro that actually has a CAN peripheral on it, which is kind of nifty. And it's cheap. I mean, the guys who bought those micros to build the badge, they weren't thinking, let's put CAN on it because it doesn't do anything right now. But that controller was probably in the right price point. It just happens to have CAN. And this is why it became popular as opposed to something like Ethernet, is you didn't need any external hardware. It's just this controller built in. There is a cheap transceiver that you hook up, so one of their IC. But there's no magnetics. There's no, you know, PHY and MAC and nothing complex. There's a bunch of different types of CAN. The four that I'll talk about. There's high speed, which is your traditional differential CAN. So this is a network where you have a twisted pair, kind of like RS485. It's multi-drop, so you can just attach as many devices as you'd like. And you can communicate over that. It's got good noise rejection. It's differential. There's also low speed CAN. It's the same theory. The only difference is instead of the twisted pair, you just kind of get rid of a wire and use the ground of the car as chassis ground of the car as your other wire. It's really cheap, and that's why it's used. Which is a theme in the automotive industry. Everything is to be cheap. Fault-tolerant CAN, this is for like airbags. Basically, if you accidentally manage to cut a wire on the differential CAN bus, it will fail over to being a single wire CAN bus for reliability. Then we have CAN FD, which is this new flexible data CAN. It's new and not in any cars, but it allows some longer payloads and faster bit rates. The typical bus that you'll see, which some of you may have seen before, in a car is that you'll have kind of two separate CAN buses, or in the case of a modern vehicle, like up to ten separate CAN buses. And these will have different controllers on them, and they will typically be linked together with something called a gateway. In this case, you have a body control module, which is date weighing messages from a high-speed bus over to a lower-speed bus. Very common that you'll have the really important features on the high-speed, like brakes and engine and transmission. And on the low-speed, you'll have more convenience features, lights, mirrors, that type of thing. So these gateways kind of act as routers, in a sense, to move these messages around in a CAN network. And if you actually want to look at how this protocol works, it's pretty simple. There's a bus, which is what I drew there. It's the two wires, and you connect all your stuff up to it. And on that bus, these controllers are going to send and receive frames. And this is like a single packet. And it consists of only three things from the programmer's view, which is an identifier, which just says, what does this mean? A data-length code, which says how many bytes are in this, and some data, which is the actual payload, which looks like that. And that's really all there is to it. You just send these messages out, and everyone receives them, and they look at them and figure out what to do. So how it actually works in practice is you have these things called signal databases, often in the industry called DBC files. These are proprietary lists of all these signals that have real-world meanings. For example, one might be your engine RPM is located in a certain message with ID 0x123, and it's the first two bytes, but you have to put them together, and then you get the actual value for that. These get a little bit more complex. You'll have things like offsets where you actually have to add a number. Maybe you'll have a multiplication factor, so you have to multiply by some number. But really, that's it. These messages are being sent out by every controller on the bus, and they're being sent out periodically. So this engine RPM might be sent out at a rate of every 100 milliseconds that shoots out a message. Whether or not it has new data, it's just going to throw the message on the bus, and everyone can receive that, they can choose to do something with it, or they can choose not to. The interesting security part of this is there's really no routing or ARP or anything like that. If you're on the bus, you can just shoot out frames, and people will believe that they're coming from whoever's sending them. So it's just a totally trusted network that you can have quite a bit of fun on. The other part of CAN, so that's the periodic data that's always being sent around. That's what your vehicle is using 99% of the time whenever it's actually working, and your tachometer is moving because it's receiving a CAN frame, or your antilock breaks. You know they're not faulting out because there's no error bit set. Things like that, it's all happening all the time from the time you turn your car on to the time you turn it off. But whenever you want to service your car, you get into these features that are not so obvious. In fact, you sort of have to go looking for them. And these are diagnostic features. Now, there is a set of these called OBD2, which is standard across all vehicles sold since 1996. And there's actually OBD1, which is 1991 to 1996. And that will allow you to get some really basic diagnostic info. It's quite fun. You can go out and buy like a little $10 dongle from Amazon that will plug into your OBD port, which every car has, usually somewhere around the drivers like me. You plug this in, pair your phone to it over Bluetooth, and you get some data. And you can clear fault codes and read fault codes. I will warn you that you may want to unplug those devices and not leave them in all the time because, well, I actually had to evaluate one of them that someone was interested in the security of the device. And if you read the manual, it simply says, the PIN code is 0000. And there's no way to change it. So don't drive around if that plugged into your car. It's probably a bad idea. Anyway, those tools allow you to do this basic diagnostics. You can get in clear fault codes. You can read some parameters about your engine. But all of the fun stuff is proprietary. They don't put the fun stuff into the generic protocols. And they're all based on this standardized protocol called Unified Diagnostic Services, which is UDS. It's an ISO standard. And it's a very simple request response thing. So the scan tool, which is a diagnostic tool, you plug it in, it will send a request saying, give me some data or maybe start this test routine or reset this controller, download new firmware onto this controller. Those are all different types of services you can request. And then the server or the automotive controller will actually shoot back a response saying, OK, I got your data, or no, and with a fault code. So it's somewhat standardized for how these actual services are laid out. But what all the different IDs mean and parameters mean, that's totally proprietary. So you have to kind of do a little bit of reverse engineering to figure any of it out. And then once you do that, you can do some pretty neat things. But to do any of this canned stuff, you need tools. And there's some very expensive tools out there. And this is sort of what you were looking at in the past, which there's Vector who makes some very nice German hardware that is very expensive, kind of out of the price range of most people who are just playing with it. And that's kind of all I'll say about Vector. Kvassar gets cheaper. Their tools are kind of a pain to work with, to be honest. You're still looking in the thousands of dollars. Then there's this Pecan grid connect thing. So it's a $250 dongle USB can. And it comes with some free software that lets you see what's going on a little bit on the bus and send some messages. That's all it does. And the full software, it's like 600 bucks. And then if you want to do diagnostics, it's like more and more and more and more. And actually, yeah, that software has no support for advanced diagnostics like the UDS stuff. It only does the basics. There's also the Ecom cable and CanCapture software. This is what the folks doing the Jeep hacking actually used. And the device itself is like 200 bucks. And you can actually write your own software accessing its APIs. But the CanCapture software is quite expensive. Then you have the OBD tools I was talking about that let you do the basic diagnostics. They're super cheap. You can go on Amazon like $10. But they only really do the diagnostics part. You can sort of send and receive Can messages, but it's pretty limited. So let's do open source tools. That's, you know, a good thing. And people have been doing this for a little while. The first one that I came across was the Goodthopter by a guy named Andrew Ryder. And it was based on the Goodfet, hence the name. It was a low-cost tool, open source, and it works, but you can't really buy it or find it anywhere. It's just, the design is out there. You could get a PCB fabricated and, you know, build it yourself. Then you have the Canbus Triple. This is actually a really neat and unique thing that I've seen a few of in the wild. It's designed for actually embedding in your car and then you write your own apps for it. It has Bluetooth and three Canbuses, which is probably how they got the name Canbus Triple. And it's actually a, it's a development platform based on Arduino, so you can write Arduino-style code and do your own thing. You have Socket Can, which on the software side has existed within Linux for quite a while. Actually, Volkswagen are the guys who made that happen. And they actually added support into the Linux kernel. If you have Ubuntu, you can probably mod probe Can right now and you'll have some Can support. And what Socket Can does is it makes devices that talk Can look like Ethernet devices, which is a total hack that works really well. To the point where you can actually open up Wireshark and like click on the Can device and it will spew frames out at you. And so Wireshark actually does Can. I showed this a little bit last year, but if you have a Can device, you can just connect to it. You can filter stuff. You can get a PCAP out of it. All the stuff you'd expect. And that's sort of the open-source tools that were around when I started looking into this. So I built this CanTac thing. And in 2015, which was last year, the hardware came out and it just supports Socket Can on Linux at that point. You could use it on Windows and OS X, but you couldn't really do much because there was no software that would work with it. So unless you wanted to manually read the frames, like in Putty, then, yeah. So in 2016, this year, there was new software time and I worked on this new GUI and it's Windows Linux OS X and provides a lot of stuff that I find useful for reverse engineering cars and hopefully you guys can use too if you're interested in that kind of thing. So hardware. The hardware, it's a single-channel USB high-speed Can device. So it uses the virtual serial port, which is a total hack because serial ports usually only go a certain speed. Turns out that if you have a USB serial port, it can run a lot faster than the bit rate that's advertised and this works across, like, all platforms without any drivers, which is nice. And it's based on this single STM32F0 microcontroller, which is quite similar to the one on all of your badges, like I said. In fact, you could probably run the CanTac firmware on your badge if someone wants to do some serious badge hacking. One of the important things for me was being able to use this for a number of different purposes and the way that I kind of put that in was to make the pin-out jumper selectable. There's a few different pin-outs that Can uses and annoyingly the OBD2 cables that plug into your car use one pin-out. Everything else uses a different pin-out. This probably exists to get you to buy really expensive cables and adapters. So with this, you can buy the cheap cable and just change the jumpers and everything works. You can also terminate the Can bus with a jumper. And it's totally open-source hardware. It looks like that. And if you go on the GitHub, which is at the end of this presentation, you can get, like, the Kaikad project, which is an open-source EDA tool, so you can get the tool that was used to build the tool for free. And then you can take that and export the Gerbers or just grab the Gerbers online. You could then take that, send it off to whoever you like to make boards and make it yourself. But they also are for sale, so you have the option of doing either of those things. And the firmware also open-source, also on GitHub. And it also uses totally open-source tool chains, so you don't need to buy any compilers or anything. It's just GCC. You, you know, install the tool chain with apt-get on Ubuntu, and then type make and hit enter, and it should build. But this is the new stuff. Now that I've kind of run through CAN is the software. And, you know, this tool was useful as just a USB to CAN, mostly socket CAN on Linux device, but Wireshark is great for looking at CAN messages if you are treating them like Ethernet frames, but you can't really send anything from Wireshark, so it was time for something new. The commercial stuff costs money, sometimes lots. It all basically runs only on Linux, or on Windows, sorry, I want it to run on Linux, runs on Windows. And it's not extensible really. There are some APIs, some of them better than others, but the actual GUI tools are like quite locked down, and they're closed-source, so you can't do anything to them. On the open-source side, it was only Linux really. Socket CAN, there was a few things based on it. Kayak is one GUI tool, but it relies on socket CAN. So you were stuck with Linux, which is fine for probably most people in this room, but not fine for lots of people in the world. So it was time for something that could work on both. It's a little hard to use, and hard to use my benchmark is not to the people in this room. I mean, it's all terminal stuff to set it up. If you're not used to opening a terminal and running commands, you probably are going to have a little bit of trouble. And graphical tools were limited. Kayak was one that you can use, but everything else really happened on the command line, and you had to sort of write your own scripts to look at things. So there was definitely some limitations with what was out there, and it was time to do something new. My goals were to make something cross-platform, so runs everywhere off the same code base, Windows, OSX, Linux. Graphical and kind of easy to use, like you can start it up, and things happen really fast, and you can look at frames. I wanted to do raw can as well as diagnostics, so there are a lot of diagnostics tools for just the basic OBD out there, not much for the advanced diagnostics. I wanted to be able to do all that stuff, plus just the raw can frames, the periodic messages I showed with like engine RPM and that sort of thing. Easy to extend, so kind of based around something and throw your own new tool into and share that, and it should just work. Have it be hardware agnostic, so it happens to work with this contact hardware, but if you wanted to use something else, or you built your own hardware, it should be pretty trivial to just, you know, write some little wrapper and have it work. And a bit of a focus on reverse engineering, because, you know, Wireshark will dump frames for you, and there's other tools out there that will do certain things, and there's some really interesting techniques that are really simple, that there was no tools that really helped me with. So I ended up using Java 8 plus NetBeans platform, where this directly accesses the contact device, and then the whole thing is open source, so you can play with it. So a lot of people have some views on Java. You're not wrong, but Java's gotten better over the years. I did some research into Java, some highly technical research into Java, and found that Java sucks has been dropping over time. It really oscillated a lot around 2005, but it's been coming down. Actually, Java 8 is kind of neat having not used Java since like 1.4 before it became 5. It was nice to know that things had gotten a lot better. But the real reason for this choice was making cross-platform graphical tools is really a pain, especially when they need to access hardware. It's not much fun. There is stuff like Qt, and you can use... There actually is an implementation of the contact interface that runs based on JavaScript that runs in a Node WebKit wrapper, which actually does work, but is terrible. So Java 1. So I'm just going to run through kind of the tools that this does. I don't really have time to do a really nifty demo for it, so I think the useful thing is just to sort of show what it does and how you would use these in practical usage. So first is the trace. You just see a bunch of frames flying by, and this would be like the real-time view of what's happening in your CAN bus. So every time a message is received, it just gets tossed into this at the top. You get a timestamp, you get the ID, you get the data length, and you get some data. This is useful to be like, hey, there's CAN frames in existence. It's not so useful once you actually want to do anything, because there will be like thousands and thousands of these flying at you and good luck trying to figure out what they mean looking at them like that. You can do some filtering. There's a filter tool. It just lets you set a range that you'd like to filter for, but it's not great for analysis. It logs every frame, though, and you can export it into the CAN dump format, which is a part of Socket CAN. So you can actually just do that, hit save, and then replay the whole thing, which is pretty useful. And it has that simple filtering tool, which if you say, oh, I know that this diagnostic thing happens between IDs 0x700 and 710, you can just set a filter and you'll only get those messages. Really simple basic stuff. This live view is, looks the same, but is very different. It basically, and I have a very simple example to illustrate it, it looks at one, or every row is for one ID. So you're receiving the same message with the same ID every 100 milliseconds. It will just update the row with that ID. Just keep tossing the data in there. If it changed, it will turn red, which is what this is doing. And the reason this is quite useful is you plug into a CAN bus and there's a lot of messages going on, but they're all just sending the same data, like over and over and over again. This populates with a bunch of that stuff and you start to see that a lot of things are just staying black, which means that they're not changing at all. Then you start doing stuff to the car and you just look for where the data is changing. This is like elementary reverse engineering, like do a thing and then see what happened and then try to correlate those, but it turns out that it works quite well when it comes to automotive systems, despite being really basic. And one example of using this was we had this tool on a Mercedes vehicle and we're looking at one of the kind of convenience CAN buses, so it's got the radio functions and doors and lights, but we wanted the GPS location because it's got a nice GPS receiver and we wanted to see where's this car going. And in that case, we actually just sat in the car and we looked at all the messages and how often they were changing. And there were some messages with same ID but changing every second, which is probably a good contender for GPS. GPS doesn't update that often. Then we literally just started driving the car around and watching stuff change kind of, you know, it made sense, the rates that it was changing at and you could see where the most significant byte was and the least significant byte was just based on what was changing when. Then we went back to this trace, set a filter for that message, recorded it for a while, took that data and actually kind of did some offline analysis to convert the hex values back into like DMS for GPS or decimal for GPS. And that was it. That was how we pulled the GPS data out. That was actually a hard one. While we were doing that, we were like, you know, putting the windows up and down, you'd see stuff change and you can like hit the brakes and you see things happen. If you shift gears, you see stuff happen. So this stuff is really pretty basic once you get on there. There's no security, you're not supposed to be there, so just look and you'll find. So it always shows the newest data for that ID and it highlights what changes and again very useful for the reverse engineering aspect of, you know, do something, see what happens, then try to correlate the values back to real units. ISOTP, this is a standard that is part of the diagnostics stack. So if we looked at the OSI model, this would be kind of above the bottom of it where CAN sits and below like the top layer and really what ISOTP is, is a means for you to chain together these eight byte long frames into longer than eight byte frames because it turns out that if you're trying to update firmware eight bytes at a time, it takes a long time. So this is a view that is basically for people who are debugging this tool almost, but it lets you just send arbitrary messages that use this standard. So in this case, I'm sending a request for some diagnostics information and back I'm getting the decimal values that are coming back from that ECU. I believe this particular example was on a Nissan vehicle where I was just requesting like the ECU name parameter or something like that, so just some random data, it's like the really low level of diagnostics and it's useful if you're messing around with it, but probably not for most people. So it's raw support and it's the basis for diagnostics. But yeah, you need to know what the actual standards are in order to use that and make useful messages. So diagnostics. This allows you to choose a service and it defines currently about half of the unified diagnostic services that are available. So there's security access is the one that I'm showing here. And for each of those, it loads up a different UI view because each one has different parameters and sends you different stuff back and you then enter that stuff, hit the buttons and things happen. So security access. Here's how authentication works in a car. You plug in a tool that's supposed to be trusted by the manufacturer and you say I would like a seed value, please. So in this you would put in the security level value which they can have different authentication levels. So typically one is like the basic one. So you put that in and there's this optional data access record thing which is sometimes used to identify the tool or whatever. Usually you don't need it. You hit the request seed button and it will send you back a seed. Then you're supposed to apply some kind of crypto to that seed value and then punch it back into that box and hit send key and then it unlocks. These algorithms are sometimes very bad. Sometimes you just have to bit shift. Sometimes you just have to add. Sometimes you have to bit shift and add which is like pretty hard. Sometimes they use actual crypto but that's only now becoming kind of common. So yeah, a lot of vehicles have some pretty weak authentication in them. But that's just one service. We're also requesting different data identifiers which are just kind of arbitrary data. You can run arbitrary routines which is kind of nifty, things for testing, but you can also just try out different routines and see what happens. I don't recommend doing that. But yeah, this lets you play around with all of the advanced diagnostics that was previously kind of trapped in the expensive scan tools. There is also scripting support. It uses JavaScript because there's a really cool engine called Nashorn for running JavaScript within Java 8 that's actually wildly fast. And basically it gives you two callbacks. Whenever it gets a CAN frame it will call on CAN received. Whenever it gets a valid ISOTP payload which is a bunch of CAN frames that are put together in the right way it will give you this on ISOTP received callback and pass you the data. So you can then choose to log the data or you can transmit using that scripting interface and this is pretty useful for making really quick, quick scripts. So one example was reverse engineering one of the security keys that I was talking about. I actually had a device that could unlock the controller. It was a valid device that was supposed to do this authentication. But I wanted to extract all of the keys for all the values out of it so that I would then have the key. So I would no longer need that device I would just know what I have to do. And what I did is I wrote a little script so on ISOTP received it would actually in this case the tool would send the request to say I would like you to unlock but then I had control of what seed value I would send back to the tool. So I'd start with zero and send something back and it would send me back the valid thing one and it would send me back and keep doing this and I knew that there was two bytes so 65,365,4 different values for that seed and key which isn't that many I'm like okay we'll brute force it we'll just get through the whole key space and that would be great. I got about like 10 in whenever I realized that they were just like subtracting a number and that really was the end of it. This is really great for just whipping up like I don't want to make some fancy thing I just want to receive a message and then send a different message which in a lot of these systems is quite useful. So what's next for this? I have a lot of things I would like to do with it. One is I talked about the signals and how you can decode those into things like engine RPM and all this and it's very specific to the vehicle that you're using and it's proprietary and it's starting to reverse engineer this and OpenGarages is actually one group that is awesome and is publishing a lot of what are people are finding but this tool does not yet but hopefully in the future we'll just allow you to take in a standard file format that defines all these messages and then instead of seeing bytes you'll see like here's the vehicle speed here's the GPS coordinates here's the engine RPM so if someone else has done all the work what's going on in your car which is kind of nice and then we're also actually working with OpenGarages to sort of make a central repository for this type of stuff so if you are doing the reverse engineering you can collaborate with people a little better right now a lot of this is trapped in like Excel documents and like notepad stuff it's not great so we're trying to make that better scripting right now it is pretty basic and I think there's a lot of utilities that are a lot easier to do responding to these messages in reliable ways that are very common support for other protocols so I kind of gave a whirlwind tour of the whole automotive thing CAN is also used in SCADA, ICS it's used for motor controls both in electric vehicles but in like industrial systems and there's things like CAN Open is another protocol that's commonly used in Excel performance enhancements there's a few things that cause your CPU to get a little angry I blame Java but it's actually my fault so that has to be made a little better and whatever else people want let's talk about adding more features if you're hacking cars and need some tools super random bonus from like last week CANTAC now works with Go because why not so you can this is like a really simple Go script that creates a device you pass it the path to the device it sets the bit rate to this mode 6 which is 500 kilobits per second opens a connection it creates some data it sends a frame with that data and then it waits to read a frame and prints it kind of useful if you like Go last thing I'm going to talk about is some emerging tech we're seeing some security things come in now MACT CAN so message authentication codes in CAN frames they're putting in like counter values and message authentication codes this is starting to make its way in but they're still stuck with 8 bytes so often you'll see like a 1 byte counter and a 2 byte MAC which is not ideal CAN FD I talked about that allows you to have 64 bytes so now you can do better MACs and you have more room to do those types of things the other one that's going to be really interesting is Automotive Ethernet yes Ethernet is coming to cars it's already in some vehicles Tesla namely has lots of Ethernet BMW is starting to have Ethernet but there's this thing called BroadAR Reach which is now standardized as the IEEE 100 base-t1 which basically you can use the wiring for CAN just two cheap pieces of wire twisted together and you can run 100 100 megabit Ethernet over that so people are very interested because that's cheap but also way faster and you can do lots more of course the issue with that is when you start to go with Ethernet you have sort of more complex protocols and then the attack surface kind of gets bigger so Automotive Security is probably going to be getting a little bit more complex in the near future as opposed to simpler yeah so that's my little presentation I'm not quite sure how much time we have for questions but thanks for coming thanks to the NSET guys for having me and hopefully you enjoyed it