 My name is Aaron, or Acorn, and I've seen a security researcher with Grim, and I've played with cars, and I'm going to tell you about what UDS is and why it can help you hack cars, and let's get moving. So what is UDS? I'm not going to go through all this detail because it's really boring and a bunch of standards, but basically UDS is a higher level protocol that lives on top of CAN. CAN itself, for the purposes of this particular talk, you can think of CAN as about kind of old school, 10, 100 ethernet, you can have a bunch of things on the bus, and they can talk to each other, they use the MAC address to figure out what messages are meant for them, right? So keep that in mind, that's basically CAN. UDS itself is then a higher level protocol living on top of that. As you may know, CAN has a limit of 8 bytes per message, and so if you want to send anything bigger than 8 bytes, like you want to send firmware to an ECU on a car, you're going to need to use a higher level protocol to segment that up into multiple messages. So ISOTP is a segmentation layer, kind of like IP, and then you have UDS itself, which you can think of like, I mean the analogies break down at this point, but you can go with maybe UDP, TCP, whatever you feel like. Like I said, the analogy does break down at that point. But there's the ISO standards, if you feel like looking at it. One quick mention, OBD2. OBD2 is a little bit different standard. It's not really living on top of these things as well, but it's meant, it's very specifically a single purpose meant to talk to the emissions related equipment for scanning codes. So it's not really the same thing, but sometimes the ECUs, which do talk OBD2, also talk UDS. Sometimes not. So CAN. You have a message ID, arbitration ID, it's what identifies what message is meant to go on the bus. The, if you have standard, CAN is 11 bits only for the message ID, arbitration ID. And standard for UDS is 7xx is going to be the request, and then 7xx plus 8 is going to be the response ID. This will make sense eventually, I promise. The 29 bit, or the extended CAN, is a little bit different, where it uses two different, you know, two different bytes as kind of the sender and receiver. It makes a little bit more sense. OBD2, there's a specialized set of IDs that are meant for OBD2 only. So you don't know, and so going back to the Ethernet and IP example, we don't have routers here. We don't have a switch. We don't have DNS to tell us what's on the bus. So the thing is we need to figure it out. But right here, we've got a very, it's a pretty limited subset of IDs that we can scan to figure out what's on that bus. It's like a maximum of, that's actually a little bit less than 256. So real quick, ISOTP, there's a couple different frame types. It's not really important at this point, but basically the first nibble of the CAN data frame indicates what type of message it is. Since it's a limited subset of values, it can make it really easy to see large data transfers, which is one of the things that is nice about UDS, it makes it easy to just visually take a look at it and see that something is happening. A couple different UDS services, if you take a look at this and you say, what do I want to do to a car? You can say that downloading and uploading things to the ECUs does sound interesting. Transferring data, security access, this is, there's a lot more than this. If you want to know, you can go look at the standard. Or actually the Wikipedia page for UDS is pretty good. And so you can go take a look at that. There's a lot of things in here that are custom per automaker, which means to figure out what is actually supported for an ECU. You need to either have the design documents or you need to figure it out. So that's kind of the goal here. So let's take a look. Here's a couple different ECU UDS responses. The whole idea is you've got a request. So in the very first message here, we've got a request ID of 74A. And the response here is 7B4. And you'll notice that that's not actually what I said earlier. Earlier I said it should be 8 more than that. Well, that's the standard. Just because it's the standard doesn't mean it's actually what is ever done because nothing's ever actually done standardly on passenger vehicles. So here we see the message. The very first, you see the first nibble of the data is zero, which means it's a single frame message. Again, it's very obvious what's going on. Second nibble is the length. And then after that, we see 10, 0, 3. 10 is the diagnostic session request. 3 is just a session ID. What does that session mean? Well, again, it means whatever the automaker wants it to mean. So the only way to figure out what it means is if you can start actually taking, you know, querying what functionality is available in that diagnostic session. You might have some simple diagnostics in session two. You might be able to reprogram the ECUs in session two. Maybe session three lets you do things like disable the brakes or something like that. You know, maybe it's some debugging or implementation. Some of the engineers we're doing that's not really meant for general consumption. Well, if you can figure out what that is, if you can get in there and scan what's going on, then it allows you to get access to what that type of functionality is. So another one, the second UDS request here, again, we've got seven, oh yeah. So the response itself, so we have zero six. So again, single frame message, six bytes, 50. So the first byte here is ISOTP. That's kind of the encapsulation layer. UDS itself is then the actual, the remaining bytes, right, then remaining seven bytes of this message. The request is the service ID, which was 10. The response, if it's a successful response, is then hex 40 more than the request. These all seem incredibly arbitrary, I know. And basically it's because, I don't know, the people who wrote the standard did it that way. It's actually, it's based on older standards. So what you're seeing here is kind of the evolution of a lot of things based on a lot of things, which is basically how all technology in computers has ever worked, because it's all based on, well, we did it this way, so let's do it this way now. That's why it's this way. So you just got to take a look at it and look at the standard and you eventually figure it out. So 50, that means successful, because it was 40 more than the request. And then, then the next thing is going to be three, which is the diagnostic session that was requested. The length is six, which means there's three more bytes of data here. I have no idea what they mean, but usually it doesn't actually matter much what they mean, but they're here in case you want to refer to it later. If you're actually implemented this or doing something with the dealer tools, it might be meaningful, I don't know. So if it's 40 more, that's a successful response. What happens if it's an unsuccessful response? That's the next example I've got here. Got zero to 10, four. So it's slightly different session ID I'm looking for. The response itself, then, is 7F. That means it's a negative response. And then you have the error code here, so it says after the negative response, the next byte is the service ID that caused the error, 10, and then it's the error code. Well, the error code itself is 12. That is, thankfully, a standard thing in this, and 12 means sub function not supported. So that basically is somebody telling us that we don't know what this means. So this is, again, this is the way that the UDS protocol is allowing us to enumerate what functionality exists on an ECU. The last one here is a read-did message. So a did in UDS speak is a block of data. If you want to find out what VIN is in a car, you read a particular data identifier, and in this case data identifier F-190. That's part of the standard. There's a range of these different dids which are standard for the ISO standard. Then there's a bunch of other stuff which automakers or suppliers do because they feel like it. Probably really to put in information that they feel is necessary. What version of software do we have in here? What version of the hardware is this? Who compiled it? Maybe. So here, the response was, there's a couple, two things I want to point out about this last one. You can see that the error is, we have a 7F which means error, but the error's code is 78. Error code 78 means that it's a, hold up. Let me read this properly. Request correctly received response pending. So basically it means, hold on a second. And this is one that always annoyed me a little bit. Because if you take a look at the timestamps, it didn't actually take that much longer for the actual message to come back. First nibble is one which means it's a first frame of a multi-frame message. And then again, like I said, three is the flow control. So it's saying here's, it's the person who's receiving the data telling the other end if it has any restrictions in the block sizes, right? So if you can think of this again in terms of Ethernet, it's just kind of like a hand shake working out like MTU sizes or something like that, right? Again, these analogies are a little bit strained, but you know, it's a way to think about it. But then the first frame is two. Two means it's a multi-frame message. And this is really good if you're like looking at the dealer tools for taking a look at, if you use the dealer tools and look at the canned messages that are happening while the dealer tools are like programming the ECU. It makes it extremely obvious when there's a block of data going to a particular location. Because it all starts with two and the message ID is all seven, something or other. In this case, the actual response doesn't matter too much. It was just because of those two things I wanted to point out there. All right. So that's the basics of UDS. I could go in for quite a long time going into detail of UDS, which would probably bore everyone more than you're already bore. Unless you're a standards nerd, you don't necessarily like look into standards, but it's useful to see that raw level of things. Tools can easily abstract what's the important stuff that's going on behind the scenes that helps you have a deeper understanding of how the computer is behaving. So a couple of useful tools I want to point out here. First one is CanCat. I work with the Grim. We like CanCat. We use it. It's not... It has a lot of libraries for allowing you to do the low level Can stuff, which is what we demonstrate over at our booth. But we also have a class in there for UDS. It allows you to interact with the ACU of doing UDS functionality. And what I'm going to show here in the second half is taking a look at a tool I wrote on top of the CanCat stuff that allows you to essentially do Nmap style scanning on a car. There's two other ones I'd like to point out here that are capable of doing UDS things. First one is Carrying Caraboo, which I have a hard time saying. It works pretty well. It works with standard Python Can stuff. If you have a Socket Can capability, it's like a CanTact. This will work well with it. It also does UDS scanning. Scapey can also do this as well. As much as I love Scapey, it's not... The interface is a little bit harder to use. And let's hear familiar with how it's working. In this particular case. So CanUtils, the low level Socket Can if you're running Linux, you've got Socket Can. You've got CanUtils. They're installed by default, pretty sure, on most distributions. But the thing is they interact with the raw Can messages. They don't necessarily give you the UDS capabilities. What we demo over our booth for just recording and replaying messages, you can do that with CanDump and CanPlayer. CanSniff is also a really useful tool. Unfortunately, CanSniffer isn't actually support 29-bit messages. There's a pull request that's been open for like a year for it. You can go and look at the pull request if you want to go and see it. You can go find a particular patch and download it and compile it. It's useful for low level things, but once you start getting to higher level protocols, you usually need to step outside of something like Socket Can. And here, like I said, you can use the CanUtils for doing Can injection. And here's just a simple example. You don't really see it interacting with the vehicle at this point, but what I did was I hit CanDump, we started logging. I hit the unlock button, and then I control C to kill the CanDump. Then I take the CanDump that was generated and I run it through CanPlayer, and I watch the car unlock itself. So this is again a simple example of message injection with CanUtils. CanSniffer is another useful one, and this allows you to do like an interactive viewing of the messages that are going on the bus. You hit the pound sign and then it will slowly shrink the window, like notches the messages it's receiving. And then it highlights, if you give it the dash C flag, it'll highlight the new messages it receives. So in this particular case, what I did was I started CanSniffer, and then I was periodically hitting the unlock button. And if you've got a sharp eye, you might notice what message ID is actually doing the door unlocking in this case. Or if you already did figured it out when you were taking a look at it on our booth. But anyway, so again, hit the unlock message, unlock the button on the key fob, and the message popped up here highlighted with the changed bytes in red. Can't the escapee again? So there's the, there's the incantation for doing it. You can go on the escapees, read the docs page, and it will, there's a good lot of, there's a lot of information there about using escapee for automotive testing. And you know, this is just a simple example. Again, you can do CanStiff. This again records all the messages and you can, it's a Python interactive shell, and you can interact with them using all the different Python tools escapee presents. Carrying Caraboo. Again, this is doing an ECU scan. So this is starting to get into more of what I was talking about. How you can use UDS capabilities to identify what's on the bus. So this again was looking, I was scanning 3PO, and I did UDS discovery. This is just using the can, cannibal. I was a little $10 piece of hardware, and it's going through all the different ECUs to find out what's present on the bus. And you can see here, it's finding different things. It's finding some things that are standard. It's finding some things that are not standard. The particular results in this case don't matter too much. It's nicer to have something animated on the screen. So UDS, one of the nicest, well okay, the functionality, not the nicest, but one of the nicer things about UDS is the error codes. They're extremely verbose. This is one of those things where you take a look at a protocol, and you can tell it was written by an engineer. Because they say, well, I want to know why this didn't work. I want to know what went wrong. And so there's, well, there's a bite for the messages, so you've got a couple hundred possibilities of what the error code is. They're not all valid, but a lot of them are valid. And here's some of the common ones. So it's not supported. Conditions not correct, which is an interesting one. Security access denied. Invalid key. Exceeded number of attempts. So exceeded number of attempts, for example, is one where, if you're trying to do a security access, what should happen if you do it wrong as you're supposed to then get an error message back saying that you ran out of attempts? Well, sometimes it happens, sometimes it doesn't. Conditions not correct is a good one, because what it's saying is, I can't do the thing that you're asking for, but I am capable of doing it if the conditions were correct. So then you got to figure out what those conditions might be. Again, it lets you start narrowing down the type of functionality you're looking for. There's also a really verbose section of errors like RPM too high, RPM too low. Engine is running, engine is not running. Throttle pedal too high, too low, transmission not in neutral, transmission in gear. And not all of these different error codes are things that all automakers implement, but when you see them, it allows you to know that, well, great, this thing I've almost gotten to the ability to activate this function, all I have to do is change the conditions that the car is in. So again, this is allowing you to scan the functionality. You don't have any knowledge of what's going on, and it's allowing you to figure out what is going on. So, UDS. So, because I can't help myself, I named it CANMAP, because it's based on CANCAT and it helps you do N mapping of a car, right? That's the theory anyway. So, there's my car, my own test subject that I tested this on, to try and figure out what's going on. So, again, when you're doing a pen test, right? If you're doing a pen test, you want to figure out what's on this network, what services are available on this network. You run NMAP with a different range of IP addresses, and you come back, if there's a service there that gives you a successful or an error, some error responses, it allows you to know that that IP address is valid, and allows you to know what services may or may not be present on there. It can allow you to detect if there's a firewall present. So, NMAP is, again, a blind tool that lets you go through and figure out what's going on. CANMAP is pretty much the same thing, and of course CaringCaribou does similar things as well, but I felt like doing it on my own. I don't really like using tools that I'd not wrote because I don't actually ever understand how the tools work until I play with them myself with my own hands. I might be the only one who ever uses a tool, but the whole point is it's helped me learn about how UDS works. It's written on top of CANCAT, so it's an example of how you can use CANCAT's existing API to interact with the bus. So use it as a way to learn how CANCAT stuff works. I use it as a tool, a standalone tool by itself. Whatever you use this as an example, or a chance to explore other new tools, as long as people are going out and learning new things, that's my goal. So first thing the tool has right now, because it's brand new, is it allows you to scan for ECUs. Right here it'll start over in a second. So it allows you to, first thing I'm doing is scanning for ECUs. There's a couple different ways you can do this. Any functionality you can send to an EC, any function you can request. So the things I pointed out earlier, read did, diagnostic session control, data transfer, ECU reset. There's all these things that you could send that would allow you to detect if an address is valid. In this particular case, the one of the default modes is just reading and dits. So it tries to read the VIN out of a vehicle. And you can see a bunch of things coming back here. So it's detecting that if there's a non-standard response. And it logs it in different ways. There's different, this is the way that I had figured out how I wanted to do it. I want to talk a little bit too about how the scanning works. UDS works. UDS is the basis of all the different functionality that like the dealer tools use. When the dealer goes and interacts with an ECU, if they need to reprogram it, they're going to use the UDS protocol to get this to happen. Well, one of the things that's been happening on newer vehicles is there's a CAN gateway sitting on the OBD2 port. That's supposed to only let the certain things through that are allowed to go through to the rest of the vehicle. One of the things that by design it has to allow through is the UDS messages that allow the dealer tool to interact with the ECUs. Which means that you using the UDS will help you find things even getting through a gateway. It's essentially using a firewall's capabilities to allow you to go through it on its own. You don't have to break through it as long as it lets you through in a nice and friendly manner. So here's the results, the results of my scanner I'll put into a YAML file. I'm not a fan of YAML but it does work well. And then the YAML file has the list of like what are the transmit IDs, what are the response IDs, and eventually what are the actual values of different dids. Now what is the bus speed that I use for this? And then this YAML file can be used in future scans that will allow you to not worry about scanning for the ECUs because you've got them already saved in a file and then you can use those and go on and scan for other things. It's also got the notes there indicating what the actual command you ran was. The idea being that it should help you find out how long did the scan take and what actually how did you actually invoke the command that generated the results you see there. So here again scanning for dids. I'm not going to show you an animated one for that because it's just a ton of output but I want to point out a couple things here. Again looking at the ISO, TP, frame IDs. If you take a look at the bottom one you'll see you've got the zero, one, three, and a bunch of twos. Again that's very classic. It's an easy way to see looking at the raw can messages that you're looking at an ISO, TP, block transfer. And then you can actually see the read did result there. In this case it was one of the application identifiers. F182, whatever this. I don't know. One of the things I also want to point out about how UDS is useful in this case is by taking a look at the contents that you can get out of the different data identifiers on the different ECUs once you have extracted the firmware for the ECU. They can act as good signposts because it allows you to have this particular string search for that string in the firmware somewhere and then once you find it you can start finding the references and you can you know that the references are going to be related to this particular can functionality. So it can allow you to go from a known set of information in the software that will allow you to figure out how you get back there to the can stuff and once you take a look at the can functions you can see what other functionality might be available through that can interface. One of the other things that is nice about that I like about the tool can cat so it allows you to do a save session file. You've recorded all this information all these can messages been saved you've been doing hours of testing. Well there's a function called save session to file. You can just type it interactively on the ipython shell that's normal way or what we can do here is if you pass the dash c flag to can map it'll save the session file for you also it's just a pickle a python pickle if you know how those work yes they're insecure so don't unpickle other people's pickles that they provide. If that phrase makes if that sentence makes sense. But it's really useful because it allows you to take your logged output that you see here's the results I see here's what's going on and you can take a look at the raw can messages themselves so if something has gone weird then it can allow you to find out exactly what's going on here. In my limited testing leading up to this I didn't have time to go through every scenario to figure out what works but being able to go through and look at the raw messages helps you figure out what's going weird. The last set of functionality I've gotten it is scan for diagnostic sessions. I've got the warning here because when I started doing this things do start acting weird because it does involve putting the ECUs into different modes. I set the immobilizer off on my car. It did clear as soon as I turn the car on and off again off and on again but again this is one of those things are once you start messing around with different diagnostic sessions in ECU resets things can get weird. On the other hand it can also help you identify which ECU does what on a car. When I was doing the scanning for for sessions and I saw okay well here's the session ID and then I see my radio start rebooting I know that that session ID is my radio because just looking at the raw message IDs you don't know which ECU those belong to necessarily. But when you start seeing the actual physical effects on the car then you can start correlating that to what ECU does what function. Again here's some results you can see some of the weird errors I started getting. One of them was like when I go to a particular session after I start scanning long enough then it just it just kind of stopped responding in a friendly manner. Again I'm not entirely sure why but looking at the raw messages can help you diagnose what's going on. And again this is the first version of it it'll get better. It's still sitting in a poll request up to the main can cat so it'll get there eventually. The no I must be a later site. So real quick wrap up UDS helps you to enumerate the vehicles attack service. Let's you figure out what ECUs are present and let's you figure out what data is in there the data can then be used to more easily reverse engineer what's going on in the thing. I do want to point out that UDS itself is not necessarily a vulnerability in and of itself. It's simply a way to discover the functionality that's present on the vehicle. The functionality itself might be the vulnerability. Right if I'm a lot if I can do things to a car that are bad if I can put my if I can unlock a vehicle from an external location that itself is the vulnerability not the fact that I found out I could do it with UDS. If I can put an ECU into diagnostics mode while the car is running and then impact the vehicle dynamics that is the vulnerability not the fact that I use a session control to do it. This is again similar to the way different protocols work and if you're taking thinking about regular computers. I can go on forever with these if I had time which I don't. Again the more tools better so I can map carrying caribou escapee other options out there and lastly go out there scan be curious play with your own car and have fun. That's it. I know it was really quick and if you have any questions we don't have time right now unfortunately but please I'll stand around afterwards if you have questions let me know and I'll answer them or go into more detail if you wish. A couple links here if you haven't got read Chris and Charlie's paper it goes a lot into UDS and security access key the seed key pairs that's very valuable to go and look at it talks about reverse engineering those algorithms out of the dealer tools the dealer tools are always a valuable resource when you're trying to figure out what the capabilities of a vehicle are and again some links to the other different can tools here that's it yes yeah question was if I've messed with the Tesla 3 I've not personally messed with the Tesla 3. Anyway I'm pretty sure I'm out of time it is in a pull request up on the CANCAT repo so if you go up to CANCAT and you look for pull requests you'll find one of them that's a branch labeled CANMAP so it's working on it it was a lot of code changes so it is a it was a lot of code changes so it's going to take a little while to review and make and fix all the stylistic things that I've messed up right question was about emulators so for messing around with this if you play with the soccer can tools you can even create a virtual can device which will allow you to play back pre-recorded data I do did create a testing can interface for CANMAP it's kind of limited at the moment though but it allows you to kind of fake out the high-level stuff but not the low-level ones so short answer is kind of yeah and there's also tool we also do SO tool in CANCAT now that allows you to go between soccer can dumps and P or P caps and CANCAT sessions files so you can convert from one to the other to play with them if you want to but that is functionality I would like to do eventually but I'm now a couple minutes past time whoever's next is going to need to get up here so I do need to shut down thank you everybody for being here and I'll be hanging around afterwards