WEBVTT 00:10.410 --> 00:13.890 Got the correct audio set up here. 00:16.490 --> 00:19.510 So just one second... 00:30.460 --> 00:32.700 There we go. 00:34.180 --> 00:34.720 Mr. 00:34.740 --> 00:35.860 Liali. 00:38.140 --> 00:39.880 Hey, how's it going, John? 00:39.900 --> 00:40.400 Good. 00:40.400 --> 00:41.760 How are you, sir? 00:43.260 --> 00:44.280 I'm good. 00:44.280 --> 00:45.460 Sorry about the background noise. 00:45.460 --> 00:46.900 Hopefully it's not too bad. 00:47.960 --> 00:50.980 No, I think we'll be able to deal with that. 00:54.140 --> 00:55.100 Excellent. 01:00.630 --> 01:02.690 So it's your show. 01:02.690 --> 01:07.830 What can you tell us about fundamentals of diagnostic requests over CAN bus? 01:12.450 --> 01:15.230 So this is a new one for me. 01:15.230 --> 01:20.190 Not diagnostic over CAN, but trying to present from a garage that doesn't have air conditioning. 01:20.190 --> 01:21.790 So wish me some luck. 01:22.410 --> 01:28.410 So right now I'm in the Car Hacking Village garage that we're hosting the Village. 01:28.410 --> 01:34.770 So behind me, you'll hear the emcee for our 101 talk. 01:34.770 --> 01:39.270 So there's a little bit of crosstalk, but once that's over, it'll just be me. 01:39.690 --> 01:40.690 Hello, everybody. 01:40.690 --> 01:42.050 My name is Robert Liali. 01:42.050 --> 01:43.550 I also go by CarPlucker. 01:43.550 --> 01:49.690 So you'll find me on the Discord right now. 01:49.690 --> 01:52.330 I have actually two different names going on. 01:52.330 --> 01:56.490 One so I can get the experience of the user, and one so I have the experience of the Village user. 01:56.490 --> 02:00.430 So you'll see two CarPluckers, C-A-R-F-U-C-A-R. 02:00.530 --> 02:03.410 So just go ahead and DM any one of those. 02:03.410 --> 02:06.850 I should get that if you guys have any follow-up questions. 02:07.130 --> 02:09.150 I'm also in the voice channel right now. 02:09.150 --> 02:17.110 I've muted myself, but later when I take some questions, I'll make sure I unmute myself so I can hear some of the questions that might be coming up. 02:17.110 --> 02:30.750 I won't be able to respond to them because I don't have... I'm as a normal user, but I'll try to type it in there, and maybe as John is rebroadcasting, I'll try to get some of that information out. 02:30.750 --> 02:37.690 So let me go ahead and get started and just kind of go over real quickly what is Diagnostics. 02:38.090 --> 02:45.810 So I don't have a very perfect presentation here, but I do have an old presentation that I've given before. 02:45.810 --> 02:54.370 So let me just close this up and just kind of go over the concepts of Diagnostics as it relates to vehicle systems. 02:54.370 --> 03:04.350 So Diagnostics is a layer of communications that allow you to connect and send requests directly to vehicle controllers, right? 03:04.350 --> 03:13.550 So one of the challenges though is Canvas has a very limited amount of space that you can put data bytes in. 03:13.550 --> 03:16.650 Specifically, you can't send more than eight data bytes. 03:16.650 --> 03:24.830 So in order to do that, they need to send... they need to send about 4,095 bytes. 03:24.830 --> 03:26.550 You have to use other protocols. 03:26.550 --> 03:35.210 So specifically, most Diagnostics in vehicle systems use a protocol called ISO 15765-2. 03:35.210 --> 03:42.350 This is sometimes referred to as the transport protocol or ISOTP or CAN ISOTP sometimes. 03:42.350 --> 03:47.090 This is the transport protocol that nearly every Diagnostic protocol builds upon. 03:47.090 --> 03:56.510 So this is that middle layer or transport layer that bridges the CAN bus limitations to allow for longer message lengths. 03:56.750 --> 04:09.910 So a lot of people and a lot of companies GM, Ford, Toyota, everybody uses this... seems to use this protocol now for all of their Diagnostic protocols. 04:09.910 --> 04:16.130 Now there are a handful of different Diagnostic or what we call high-level protocols or application layer protocols. 04:16.190 --> 04:18.030 I'm going to focus on one. 04:18.030 --> 04:19.410 It's called UDS. 04:19.410 --> 04:26.810 And the reason why I'm going to focus on UDS is because it's the most well-known and highest used one. 04:26.810 --> 04:31.350 Almost all Diagnostic protocols are kind of based off this particular one. 04:31.350 --> 04:34.870 So what I want to do is I'm going to take you through a process. 04:34.870 --> 04:44.270 Now this is a process that is actually related to OBD2, but this particular process takes apart a Diagnostic CAN message. 04:44.270 --> 04:48.010 So here's a flow for Diagnostic CAN messages. 04:48.010 --> 04:52.530 Let me just... I have two screens, so this is coming across the wrong screen. 04:52.530 --> 05:04.930 So let me just turn that feature off so that we can play this back on the main screen. 05:04.930 --> 05:14.130 I would like to run the slideshow from the current slide, but I don't want presenter mode. 05:14.130 --> 05:15.470 So let me just find out. 05:15.690 --> 05:17.550 No, I don't want that. 05:19.050 --> 05:22.970 I want to do that out of the primary monitor and from the current slide. 05:22.970 --> 05:26.950 So this should allow us to see this a little bit better. 05:27.310 --> 05:42.370 So I'm going to take you through the individual process, just sort of on a slide, and then I'm going to take you through it on an actual vehicle, but actually going to take you through on the vehicles that we're using for the Car Hacking Village challenges today. 05:42.530 --> 05:46.710 So here is ISO 15765-2. 05:47.410 --> 05:50.810 There are high-level protocols that run on top of it. 05:50.810 --> 05:58.930 I'm going to talk about specifically the OBD2, in this case this will be OBD2 Diagnostic Protocol, sometimes called J1979. 05:59.890 --> 06:07.630 So this is sort of like a standard protocol family that's across all vehicles, makes and models that are on the road today. 06:07.630 --> 06:11.910 So let's take a look at a flow of messages, the example of flow. 06:11.910 --> 06:22.130 So I'm going to take a really simple one that really illustrates every facet of this particular protocol, ISO 15765-2, specifically the VIN request. 06:22.130 --> 06:26.250 So the VIN request has the two bytes. 06:26.470 --> 06:30.470 The two bytes are 09 and 02. 06:30.470 --> 06:33.670 So 09 is what we call the service byte. 06:34.230 --> 06:39.270 The service byte is essentially the function that we're asking the controller to perform. 06:39.270 --> 06:44.670 In this case, we'll ask the engine controller, because every vehicle tends to have an engine controller. 06:44.830 --> 06:48.670 We'll ask the engine controller, hey, what is the VIN? 06:48.710 --> 06:53.390 And the first part of every request is the service or function you want it to perform. 06:53.390 --> 06:56.990 Now there's a list of all of these functions, specifically OBD2 functions. 06:56.990 --> 07:11.270 If you just google OBD2 services or OBDIDS, you'll see Wikipedia has a very good list of the individual services called modes that are available for OBD2. 07:11.270 --> 07:15.570 So service 09 is a request service. 07:15.930 --> 07:22.310 The function or sub-function 02 is the parameter ID for the VIN. 07:22.310 --> 07:25.390 So if I were to change that from 02 to 01, I would get the VIN. 07:25.390 --> 07:27.790 I'd get something else from the controller. 07:27.790 --> 07:31.830 But it'd still be a request, but for a different parameter. 07:31.830 --> 07:35.030 So here's my VIN request, 0902. 07:35.310 --> 07:39.270 And I'm going to go ahead and move this up to my VIN request. 07:39.270 --> 07:39.670 Look at that. 07:39.670 --> 07:40.670 Pretty exciting. 07:40.750 --> 07:43.790 Kind of came through the video. 07:43.850 --> 07:45.370 I'm also monitoring the video. 07:45.370 --> 07:48.010 It looks like you guys saw a little bit of animation. 07:48.170 --> 07:52.330 Spent a whole two hours working on that animation, so give me some credit there. 07:52.750 --> 07:55.570 So there's our request, 0902. 07:56.430 --> 07:57.770 Everybody with me? 07:57.770 --> 07:59.230 Raise your hand if you are. 07:59.410 --> 08:00.210 Okay, good. 08:00.210 --> 08:00.750 Excellent. 08:00.750 --> 08:01.630 I like to see that. 08:01.630 --> 08:03.990 So next, we have our VIN response. 08:03.990 --> 08:17.850 So you'll see our VIN response is significantly larger than our request, because it includes our information about the success of the request, information about how the request is encoded, and the actual VIN characters in ASCII databytes. 08:17.850 --> 08:23.610 So the VIN on most vehicles, in fact, vehicles in the United States, are 17 characters long. 08:23.610 --> 08:26.510 So we'll have at least 17 characters to encode the VIN. 08:26.510 --> 08:33.670 In fact, in this case, we'll have 20 characters, 17 characters plus three overhead bytes that are happening. 08:33.670 --> 08:42.650 So we see the 0902, but now our response will come back, and you'll see it says 4902. 08:42.650 --> 08:48.410 So as you guessed it, that first databyte is, again, a service indicator, so a service byte. 08:48.410 --> 08:55.370 But it's not the service or function that we perform, but rather the response or the information that's coming back from the service itself. 08:55.370 --> 08:59.950 And rather, will we see a successful request or not? 08:59.950 --> 09:06.870 And each time we see 49, or 40 hex more than our original service ID, we know that this is a positive response. 09:06.870 --> 09:12.270 So in this case, this request that we're getting, that we sent out, was successful. 09:12.270 --> 09:17.390 Our response is positive, because we see 40 hex more than our original request. 09:17.390 --> 09:24.230 The 02 is just an echo of the original parameter ID, or PID, in this case, the VIN request. 09:24.230 --> 09:33.350 So even if we didn't see what the initial response was, we could tell that this wasn't that, indeed, a response to the VIN request. 09:33.390 --> 09:41.930 The next byte, the 01, is actually an encoder to let us know that this is actually an ASCII-encoded parameter. 09:41.930 --> 09:47.210 So now one challenge we have here is this is now 20 bytes. 09:47.210 --> 09:51.530 If you know anything about CAN bus, CAN bus only allows 8 bytes per frame. 09:51.530 --> 09:53.370 So we have to do something about this. 09:53.370 --> 09:57.270 If we can't fit this into a CAN bus frame, we have to segment it. 09:57.270 --> 09:58.590 We have to break it apart. 09:58.830 --> 10:00.550 And so, how do we do that? 10:00.550 --> 10:09.930 So we take the first part of the message, we take the second part of the message, then we take the third part of the message and we break them across three different frames. 10:09.930 --> 10:10.490 Okay? 10:10.830 --> 10:14.890 So now we have three frames of CAN bus messages. 10:15.030 --> 10:17.590 So here they are, 490201C. 10:17.590 --> 10:21.090 It's the same frames, but we had to break them up into different frames. 10:21.090 --> 10:21.730 Okay? 10:21.790 --> 10:24.810 So I'm going to go back. 10:24.810 --> 10:29.770 I'll reiterate that we are sending this message to the engine control system. 10:29.770 --> 10:34.270 So since it's to the engine controller, we need to identify each frame. 10:34.270 --> 10:39.550 Each frame identifier is essentially part of the arbitration ID of a CAN message. 10:39.550 --> 10:46.570 Every CAN message has an arbitration ID, and inside of that arbitration ID is the identifier for the controller that we're talking to. 10:46.570 --> 10:55.270 In this case, we're talking to the engine controller, which is legislated at 7E0 for 11-bit CAN bus system. 10:55.270 --> 11:03.850 So since we're talking on an 11-bit CAN bus system, we'll say 7E0 and then we'll say 0902. 11:03.850 --> 11:04.370 Okay. 11:04.370 --> 11:05.210 Awesome. 11:05.230 --> 11:08.210 Here we have a message that goes across. 11:08.210 --> 11:15.050 But we need to add some more information specifically about how large this particular message is going to be. 11:15.050 --> 11:19.950 So then what we do is we're encoding something called PCI data or program control information. 11:20.370 --> 11:24.930 So the PCI data could be the frame type specifically. 11:25.370 --> 11:28.110 So here we put a 0 in. 11:28.110 --> 11:29.610 A 0 is a frame type. 11:29.610 --> 11:34.290 That frame type 0 is a single frame message. 11:34.290 --> 11:47.870 So right away in the first data byte of this particular frame, we know that this message is going to be a single frame message because there's a 0 encoded in the first nibble of the first data byte of the frame. 11:48.750 --> 11:55.150 The second part of that particular nibble, the second nibble of that byte, is the data length. 11:55.150 --> 11:59.410 So it indicates how many bytes this particular message is going to be. 11:59.410 --> 12:08.590 In this case, since our message is 0902, we have two bytes in our message, we put a 2 in that data byte, indicating that there's two bytes of data. 12:08.590 --> 12:09.690 Really simple. 12:09.790 --> 12:10.650 02. 12:10.650 --> 12:12.770 Very obvious if you think about it. 12:12.770 --> 12:15.910 Here we have a 020902. 12:16.310 --> 12:18.610 And now we'll do one more thing. 12:18.630 --> 12:20.290 We'll do this thing called padding. 12:20.290 --> 12:22.650 Padding is a way of filling in the data. 12:22.770 --> 12:27.850 Not all cars require this, but I always recommend it because some cars do require it. 12:27.850 --> 12:31.990 And later what I do in my demo, I'm going to show you guys how that is the case. 12:32.190 --> 12:35.610 So now we fill in the rest of this data with padding. 12:35.610 --> 12:42.050 The reason why we know it's padding, because again, we go back to the beginning of the data frame, and we see the 02. 12:42.110 --> 12:45.690 That 2 is an indicator of how big this particular message is. 12:45.690 --> 12:48.670 So we count one, two bytes, 0902. 12:48.670 --> 12:50.070 Those are our two bytes of our message. 12:50.070 --> 12:52.790 Anything after that must be padding, right? 12:52.790 --> 12:55.510 Because it's not part of the message itself. 12:55.510 --> 13:00.850 So even if there were data there, we could ignore it because it's not part of the actual message. 13:00.950 --> 13:04.490 All right, so we send a request out. 13:04.490 --> 13:06.790 Now we should get a response back. 13:06.790 --> 13:12.130 Our response ID has got to be different than our request ID, but it's usually just a little bit different. 13:12.130 --> 13:15.590 Sometimes it's significantly different, but sometimes it's very much the same. 13:15.590 --> 13:19.910 In this case, our response ID will be 8 more than our request ID. 13:19.910 --> 13:22.870 So 70E0 returns a 70E8. 13:22.870 --> 13:31.150 This is part of the OBD2 specification for emissions-related controllers, so that's just very common, as you'll see. 13:31.350 --> 13:37.210 So again, we'll have a frame type, just like we had before in the first nibble of the first byte of the last frame. 13:37.210 --> 13:39.050 We do the same thing here. 13:39.050 --> 13:44.650 We have a one to indicate that this is indeed a multi-frame message. 13:44.650 --> 13:46.790 So one equals multi-frame. 13:47.450 --> 14:00.770 Just like before, we had a data length, but since our multi-frame messages can be over 4,000 bytes, 4,095 to be exact, because we can have 4,095 bytes, we need more bits to encode that information. 14:00.770 --> 14:06.610 So the four bits, or one nibble, that we saw in the single frame message just before is not enough. 14:06.610 --> 14:08.110 We need more bits. 14:08.110 --> 14:10.190 So we expand. 14:10.190 --> 14:23.930 Now that we use those four bits, but we also use the next eight bits as well, giving us a total of 12 bits, so 2 to the power of 12 total number of values that we can have, so 4,095. 14:23.930 --> 14:26.810 So now we know how many bytes we can have. 14:27.090 --> 14:32.130 So I put a 014 to indicate that this is actually going to be 20 bytes long. 14:32.130 --> 14:33.770 So 014 is hex. 14:33.790 --> 14:35.950 That equals 20 in decimal. 14:36.290 --> 14:39.370 And then we fill in the rest of the actual message itself. 14:39.370 --> 14:45.770 So recall the VIN message starts at the 49, 02, 01, 31, 32, 33. 14:45.770 --> 14:48.930 So that's the data that's going to be encoded in the VIN. 14:49.370 --> 14:52.410 So we just sent a request to a controller. 14:52.410 --> 14:56.610 It just responded back to us saying it's going to send us a multi-frame response. 14:56.870 --> 15:00.410 What if we can't handle a multi-frame response? 15:00.410 --> 15:05.150 Or what if we need to reserve a buffer and we need to do that quickly? 15:05.150 --> 15:12.890 We need to give some feedback to the controller saying, hey, listen, I'm either able to do this or I'm not able to do this. 15:12.890 --> 15:14.710 So that's what we call our flow control. 15:14.810 --> 15:25.370 So we're going to send another message back to the controller to let it know that the kind of the rules of how it's allowed to transmit the rest of the data back to us. 15:25.590 --> 15:28.530 So we'll send a 70, 0 back to the controller. 15:28.530 --> 15:33.970 And then we'll send a 3 for the frame type indicating this is a flow control message. 15:33.970 --> 15:37.690 So we're going to send a flow control response back to it. 15:37.730 --> 15:41.430 Now, we have to do this within 100 milliseconds of the request that we sent. 15:41.430 --> 15:43.370 So you have to do this programmatically. 15:43.370 --> 15:45.730 You'll never be able to do this by hand or manually. 15:45.730 --> 15:52.290 So if you're typing in, like, send flow control or something like that, you'll never get the timing that you need in order to do that. 15:52.290 --> 15:59.090 So you have to run some sort of script locally to the hardware or something like that in order to have success with it. 15:59.090 --> 16:02.330 Or your hardware needs to support this particular feature. 16:03.010 --> 16:07.210 So that's something that's important to keep in mind when you're doing diagnostics. 16:08.250 --> 16:10.890 Next, we need to send a... it's clear to send. 16:11.050 --> 16:16.610 So we say a 0 in the next nibble of the next bite indicating it's clear to send. 16:16.610 --> 16:19.130 If it's not a 0, it's some error. 16:19.410 --> 16:20.730 1 is an error. 16:20.730 --> 16:22.070 Hey, you can't send this. 16:22.070 --> 16:27.330 So usually that will mean that the controller stops sending its request. 16:27.410 --> 16:29.030 The next is the block size. 16:29.030 --> 16:38.990 So that's how many blocks or messages or frames, I should say, that you need to... you can send before another flow control is sent back. 16:38.990 --> 16:44.510 So normally that's set to 0, meaning I'm not going to send any more blocks. 16:44.550 --> 16:46.010 Don't worry about the blocks. 16:46.010 --> 16:49.790 I'm just going to... I'm just going to send this one flow control frame. 16:49.790 --> 16:51.550 You finish up the rest of the message. 16:51.550 --> 16:53.310 You don't need to hear from me again. 16:53.310 --> 16:54.630 These are the rules. 16:54.790 --> 17:06.770 Sometimes it can be a number not 0, meaning if that was a 0, 1, then the controller would send a message back to me, and then I would send another flow control frame, and then the controller would send another message, and I would send another flow control frame, 17:06.770 --> 17:08.230 et cetera, et cetera, et cetera. 17:08.230 --> 17:13.510 So that number essentially is how many more frames until I send a flow control. 17:14.690 --> 17:18.250 Last parameter here is the frame separation. 17:18.270 --> 17:28.270 This is the actual time in milliseconds that we need to wait between... that the controller that's returning the data back to me needs to wait for it to send a message. 17:28.270 --> 17:30.790 So 0A equals 10 milliseconds. 17:30.990 --> 17:33.570 And again, we have padding as well. 17:34.250 --> 17:36.090 Now we get a response back. 17:36.090 --> 17:40.750 The next frame comes after the first frame that we got. 17:40.750 --> 17:41.790 The next data bytes. 17:41.790 --> 17:43.250 In fact, the next seven data bytes. 17:43.250 --> 17:45.610 Why seven, not eight in the Canvas frame? 17:45.610 --> 17:47.490 Because we still have more PCI data. 17:47.570 --> 17:49.990 Specifically, a frame type of two. 17:49.990 --> 17:53.850 Two indicates that this is a... what we call a consecutive frame. 17:53.850 --> 17:56.790 A frame that happened after a first frame. 17:56.790 --> 18:05.150 So if you were just to look at this and just monitoring the Canvas, and you saw that this is a consecutive frame and you didn't have the first part of the frame, you would know that you missed some data. 18:05.150 --> 18:12.350 So it's super important to know that if some other system is monitoring it, that this is not the first part of the data. 18:12.510 --> 18:14.010 But what part of the data is it? 18:14.010 --> 18:20.770 Well, we have this rolling code that comes next, indicating that this is the first consecutive frame. 18:20.770 --> 18:22.750 So we have a one there. 18:23.190 --> 18:25.090 The next frame will come. 18:25.090 --> 18:29.170 It will also be a... have a two as well, because it's also a consecutive frame. 18:29.170 --> 18:33.730 But instead of having a one in the rolling code section, it will have a two. 18:33.830 --> 18:34.450 And guess what? 18:34.450 --> 18:38.790 The next one will have a three and a four and a five , et cetera, all the way until we hit F. 18:38.790 --> 18:40.550 And then we just roll back over to zero. 18:40.550 --> 18:51.290 So you'll see it go 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, and then go back to zero, 1, 2, 3, 4, 5, et cetera, et cetera, if there were more data or more frames that needed to be sent. 18:51.430 --> 18:53.170 But for the most part, this is pretty simple. 18:53.170 --> 19:00.370 We've essentially requested the VIN and received the VIN back from the controller, all pretty quickly and pretty simply. 19:00.670 --> 19:03.950 So I want to take a little bit of time. 19:03.950 --> 19:05.710 So I'm about 18 minutes in. 19:05.790 --> 19:06.210 Great. 19:06.210 --> 19:07.410 I'm doing well on time. 19:07.830 --> 19:10.210 I want to take some time and do a little live demo. 19:10.210 --> 19:11.970 Now, you know what live demos are. 19:11.970 --> 19:13.030 They're always bad. 19:13.030 --> 19:14.170 Don't ever do this. 19:14.170 --> 19:15.650 So I'm going to go ahead and do this. 19:15.650 --> 19:15.930 All right? 19:15.930 --> 19:19.130 So let me bring up all of these. 19:19.130 --> 19:22.070 I've got a few different windows open here. 19:22.870 --> 19:26.650 Specifically related to our system here. 19:26.650 --> 19:29.050 I'm going to go ahead and minimize a few things here. 19:29.970 --> 19:30.770 Okay. 19:31.570 --> 19:37.870 So this is the this is SocketCAN. 19:37.870 --> 19:42.850 If you're not familiar with SocketCAN, we have some really cool information about how to get started with SocketCAN. 19:42.850 --> 19:46.750 In fact, everything I'm doing right now, you can come over to the CarHacking Village. 19:46.950 --> 19:51.190 Join the virtual.carhackingvillage.com CTF. 19:51.190 --> 19:52.890 It's easy to join. 19:52.950 --> 19:55.230 Just sign up and you can get into the queue. 19:55.230 --> 20:01.130 And you, too, can also plug into this vehicle virtually as well and do all of these same things. 20:01.130 --> 20:04.650 So I highly recommend you guys do that if you have time. 20:04.690 --> 20:09.630 And we have some pretty good getting started instructions on our web page as well. 20:10.250 --> 20:12.510 If I have time, I'll try to go into those as well. 20:12.510 --> 20:17.390 So I've taken a few seconds and created a couple different windows. 20:17.450 --> 20:21.770 One window looks like some people are having some fun on these networks as well. 20:21.770 --> 20:24.850 So we might get some spurious data coming across. 20:24.850 --> 20:27.630 Also, I'm going to clear up some of these windows real quick. 20:27.630 --> 20:30.070 Let me just cancel out of this and reload it. 20:31.030 --> 20:31.670 Okay. 20:31.750 --> 20:34.510 So it might be a little tight to see. 20:34.510 --> 20:36.550 You might need to zoom in, squint your eyes. 20:36.850 --> 20:39.470 Let me just see if I can make this a little bit bigger. 20:39.470 --> 20:40.650 Yeah, a little bit bigger. 20:40.650 --> 20:41.170 Okay. 20:41.170 --> 20:42.170 A little bit bigger. 20:43.750 --> 20:44.490 All right. 20:44.490 --> 20:45.690 That's a little bit bigger. 20:45.750 --> 20:46.670 That's nice. 20:47.030 --> 20:47.950 That's very nice. 20:47.950 --> 20:48.510 Okay. 20:49.930 --> 20:51.010 Same here. 20:52.770 --> 20:53.490 Okay. 20:53.490 --> 20:54.630 So I made it a little bit bigger. 20:54.630 --> 20:56.410 Hopefully you guys can see a little bit easier. 20:56.910 --> 20:58.850 So what we have, I have three different windows. 20:58.850 --> 21:01.550 One I use for... these are all terminal windows. 21:01.550 --> 21:04.070 One I use a program called CanSend. 21:04.070 --> 21:05.510 It's a CAN utility. 21:05.510 --> 21:07.890 You can download CAN utilities available as well. 21:07.890 --> 21:10.650 It's already available on this particular device for you. 21:10.930 --> 21:13.910 CanSend essentially takes a few arguments. 21:13.910 --> 21:17.290 One is the device that we want to send the data on. 21:17.810 --> 21:21.230 We have two CAN buses that are available. 21:21.230 --> 21:24.810 CAN0 and CAN2 are available on this particular vehicle. 21:24.810 --> 21:30.450 If I send data on CAN2, it's actually on a gateway network. 21:30.730 --> 21:32.830 So you can't see the data. 21:32.890 --> 21:36.210 This is actually the CAN dump of CAN2. 21:36.210 --> 21:39.150 So what we see below here is nothing. 21:39.310 --> 21:43.750 So if I were to send a CANSend message, which I'll do. 21:43.750 --> 21:45.770 In fact, I'm going to do a bad message. 21:45.770 --> 21:48.930 So you guys can see a bad message go across. 21:48.930 --> 21:52.310 Of course, I sent it on CAN1, my bad. 21:53.090 --> 21:54.870 I'm going to send it on CAN2. 21:56.090 --> 21:57.810 Give me a second here. 21:57.990 --> 21:59.450 It's a little slow. 22:00.610 --> 22:01.810 All right. 22:02.050 --> 22:07.490 So I sent a message on CAN2, and then I was monitoring CAN2 using CAN dump. 22:08.450 --> 22:10.450 Again, I sent my message. 22:10.450 --> 22:12.970 I actually sent what's called a tester present message. 22:12.970 --> 22:17.870 So it's a pretty standard way of just kind of pinging the network, just saying, hey, there's a tester here. 22:17.970 --> 22:23.430 I sent it on an ID7DF, which is a broadcast ID to a handful of controllers. 22:23.690 --> 22:25.890 So hopefully I get one of them to respond back to me. 22:25.890 --> 22:28.270 But I malformatted the message intentionally. 22:28.330 --> 22:30.810 I sent it with seven data bytes, not eight. 22:30.810 --> 22:32.650 And remember, I was talking about padding. 22:32.770 --> 22:33.870 Padding is important. 22:33.870 --> 22:36.690 So you have to make sure that you pad with all eight data bytes. 22:36.690 --> 22:39.790 As soon as I do that, you'll see I get a few more responses back. 22:39.790 --> 22:44.310 Again, this is a broadcast message to a handful of controllers. 22:44.310 --> 22:49.070 I actually got three different messages happen after my initial request. 22:49.070 --> 22:51.650 So here's my initial request right here. 22:51.710 --> 22:53.910 I don't know if you can see this very well. 22:53.910 --> 22:59.990 But it's essentially 7DF023E, and then the rest are zeros. 23:00.990 --> 23:02.970 That is a tester present. 23:02.970 --> 23:09.870 And so I get a bunch of responses back from three different controllers, two of which give me what are called the negative response. 23:09.870 --> 23:16.910 The negative response is a 7F, and the positive response is a 7E, which is 40x more than my initial request. 23:16.910 --> 23:21.310 So I set the request correctly, but I got different responses back. 23:21.310 --> 23:30.830 That tells me a lot about the system right away, that these different controllers are configured with different versions of diagnostic request services. 23:30.830 --> 23:40.490 So it's quite normal to see that different controllers run different diagnostic request applications, and that's no different here. 23:40.490 --> 23:42.410 So you might find something like that. 23:42.410 --> 23:54.410 So let's go back to our original concept of sending a request for our engine, or our VIN. 23:54.410 --> 24:01.470 So again, 7E0020902, and then I'll fill this in with zeros. 24:02.190 --> 24:03.990 So I send that request. 24:04.670 --> 24:06.770 Of course, you know how it goes. 24:06.770 --> 24:07.490 There it goes. 24:07.890 --> 24:09.770 I get my response back. 24:09.770 --> 24:13.690 Let me just clear this up a little bit, so it's a little bit harder to see what's going on. 24:13.730 --> 24:17.050 I'm sure if it's hard for me, it's even more difficult for you. 24:17.050 --> 24:24.730 So let me just try to make this even bigger, so you guys can see it a lot better. 24:24.730 --> 24:27.030 Okay, so I'll send my request. 24:27.490 --> 24:30.250 I got to actually hand dump. 24:31.290 --> 24:33.250 Okay, send my request again. 24:35.030 --> 24:38.570 And you'll see we get a request and response. 24:39.110 --> 24:44.670 So our response is the first part of the VIN on this particular vehicle. 24:44.670 --> 24:51.050 I'm not going to do the rest, because I'm broadcasting live on a real vehicle, and you can get the idea. 24:51.050 --> 24:55.450 You know, sending VINs out there, as cool as that is, if you want this VIN, you got to get it yourself. 24:55.530 --> 24:59.050 But you know what the next thing is, I have to send a flow control frame. 24:59.050 --> 25:03.790 Now, like I told you, I can't do this by hand, right? 25:03.810 --> 25:14.790 So if I want to send a flow control, I would need to send a 70, 0, 3, 0, and then space there. 25:15.270 --> 25:18.170 It's a little slow here on my end. 25:18.410 --> 25:19.890 You guys are going through. 25:19.890 --> 25:22.070 But I'd have to set something like this. 25:22.070 --> 25:26.870 Now, because of my timing, I'm not going to get this message going out correctly. 25:26.930 --> 25:29.610 Even if I wanted to, I'd have to script this in some way. 25:29.610 --> 25:34.650 So I could create a bash command to send one and then the other within a certain period of time. 25:34.650 --> 25:35.730 I could create a script. 25:35.730 --> 25:39.430 I could try to chain them together, maybe with an ampersand. 25:39.430 --> 25:42.570 It's, you know, maybe a little time sleep between them. 25:42.570 --> 25:43.430 Something like that. 25:43.430 --> 25:47.770 I don't know if time sleep has a millisecond control on bash. 25:47.770 --> 25:50.070 But if it did, we could do it that way. 25:50.070 --> 25:52.890 We just did a little bit of a delay. 25:52.890 --> 25:55.250 Maybe there's enough of a delay already. 25:55.410 --> 26:04.590 But if we send our flow control a little too fast before the actual controller sends its response, it might ignore our follow-up. 26:04.590 --> 26:09.450 So that's kind of how we can send a simple request to these controllers. 26:09.910 --> 26:16.570 Later tomorrow, I'm going to have a whole talk related to what I call CMAP. 26:16.570 --> 26:21.870 It's a way of mapping out diagnostic requests across the board. 26:21.870 --> 26:32.730 Not necessarily using SocketCAM, but using a Python interface that just says, hey, I'm going to sort of copy or take all of this information and broadcast it out to you. 26:32.870 --> 26:38.050 I have also here the actual powertrain network that's on the bus. 26:38.050 --> 26:40.050 Now, you'll notice there's a lot of data running across there. 26:40.050 --> 26:41.630 I'm going to go ahead and cancel this. 26:41.690 --> 26:44.550 And what I'm going to do is I'm just going to filter. 26:44.810 --> 26:47.770 I want to show you a little bit about SocketCAM filtering. 26:48.410 --> 26:58.450 So CanDump, we can monitor the CanDump, but I'm going to monitor a different network, specifically Can0, which is the powertrain network. 26:58.450 --> 27:00.410 Can2 is the diagnostic network. 27:00.410 --> 27:10.670 So any diagnostic, as I said, I can see they get transferred over to the correct network that is supposed to manage that particular identifier. 27:10.670 --> 27:21.090 In this case, 70.0 should get rebroadcast by the gateway over to the powertrain network, which is Can0 in this case. 27:21.090 --> 27:23.530 But because there's so much data, it's really hard to see it. 27:23.530 --> 27:27.010 So what's cool about CanDump is you can do some filtering. 27:27.150 --> 27:33.410 In this case, I'll filter on 70.0, but I also want to capture the 70.8 message. 27:33.410 --> 27:38.950 So I'll type in 70.0 here, but what I'll actually do is I'll add a filter mask. 27:38.950 --> 27:45.630 If I just want to do 70.0 messages, I put a 7FF, which is an indicator of 11 bits of 1s. 27:45.630 --> 27:51.930 If you understand how bit masks work, if you don't, I recommend doing a reading up on bit masks. 27:51.990 --> 28:01.270 Specifically, what I'm interested in is I want to see anything that starts with 7E, but I don't care about what the last byte is or bit or nibble, I should say. 28:01.270 --> 28:12.010 Now, in this case, I'll just put a 0 there, I don't care what's in those last four bits, I just want to see anything that's 7E, anything. 28:12.010 --> 28:13.590 So I just put a 7F there. 28:13.590 --> 28:19.830 If I hit enter here, now only messages that have 7E something in them will show up. 28:19.830 --> 28:21.890 So I'll go ahead and send my initial request. 28:21.890 --> 28:32.890 Now remember, I'm sending on Can2 right now, but I will see it on Can0, which are two separate, physically separate networks, but there is a controller in between them that is gatewaying that information. 28:32.890 --> 28:34.330 So go ahead and send that request. 28:34.330 --> 28:37.070 Oops, I did not send the actual request. 28:37.070 --> 28:38.490 Let me send this one again. 28:38.530 --> 28:44.950 And we can see both my message going across, not only on the Can2 network, which I anticipate, right? 28:45.210 --> 28:50.250 You monitor a network, you look at it, you're going to get the data back, but you also see it on a separate network as well. 28:50.270 --> 28:54.110 That's because I'm actually sending through something. 28:54.150 --> 29:16.610 Now, the reason why I set it up this way is I wanted to see if somebody could go through and say, hey, I'm going to scan all possible identifiers on the diagnostic network and see what comes out, see what actually is being forwarded between the diagnostic side and the non-diagnostic side, 29:16.610 --> 29:17.850 or the powertrain side. 29:17.850 --> 29:19.650 There's probably some correlation. 29:19.650 --> 29:22.990 You can learn a lot about how the system works just by poking at it. 29:22.990 --> 29:24.830 It's a great way to poke at it. 29:24.950 --> 29:29.150 So I've run about 30 minutes, which was my goal today, to hit about 30 minutes. 29:29.150 --> 29:34.250 So what I'm going to do is take it there and then see if there are any questions for you from the audience. 29:34.250 --> 29:39.810 So I'm going to turn my audio back on so I can hear you guys if you guys are talking in this channel. 29:40.050 --> 29:43.750 And go ahead and fire an audio question away. 29:43.750 --> 29:52.390 If there's a question inside of the one-on-one chat section, I'll also switch over to that support. 29:52.530 --> 29:55.170 So I'm also monitoring the one-on-one chat. 29:55.170 --> 29:57.810 So if there are any questions, I'm happy to take them. 29:57.810 --> 30:01.130 If not, I'll say, hey, thank you very much. 30:01.230 --> 30:03.310 And hopefully you guys get a chance to hack these cars. 30:03.310 --> 30:04.850 Please go ahead, anybody. 30:05.850 --> 30:12.110 Robert, thank you so much for the presentation. 30:14.650 --> 30:16.490 It was fun. 30:18.110 --> 30:19.570 Sorry, I have an echo. 30:21.550 --> 30:22.830 Sorry, it might be my fault. 30:22.830 --> 30:25.070 Let me just fix my end. 30:25.450 --> 30:27.090 Just one second. 30:27.750 --> 30:29.730 I'm going to mute myself. 30:30.410 --> 30:31.870 No, I don't know where it's going. 30:37.000 --> 30:38.600 Don't worry, it's okay. 30:38.640 --> 30:40.060 Did that exit? 30:40.220 --> 30:41.940 No, that didn't exit. 30:42.460 --> 30:43.760 No problem. 30:43.760 --> 30:45.920 No, it's not my fault then. 30:48.600 --> 30:50.860 Actually, I have a question. 30:50.900 --> 30:55.740 What kind of tools are you using to do this? 30:55.740 --> 30:56.840 Like, what hardware? 30:57.220 --> 31:00.860 I typically, I mean, I use Vehicle Spy right now. 31:01.000 --> 31:02.880 And Vehicle Spy is? 31:02.880 --> 31:04.760 Yeah, I use Vehicle Spy with a value can. 31:05.340 --> 31:07.840 I'm a big fan of it because I used to work there. 31:08.240 --> 31:11.000 So Vehicle Spy is a commercial tool. 31:11.180 --> 31:19.380 So it's not a free one, but it really, you know, when you're first learning this, one of the hardest parts is just setting it up and plugging it in. 31:19.800 --> 31:27.960 And if you got the time and the money, you know, to do it, I recommend getting a commercial tool because they work really well and there's support. 31:28.260 --> 31:32.460 But, so not everybody has that ability or their wherewithal to do that. 31:32.460 --> 31:39.160 So, you know, the obvious tools are out there are the Cannibal by 31:43.620 --> 31:44.940 Eric Evacek. 31:45.040 --> 31:49.320 He's got the, or not the Cannibal, he's got the Cantac, sorry. 31:49.320 --> 31:51.560 He's got the Cantac Pro that just came out. 31:51.560 --> 31:54.140 Those are really good tools that I've used several times. 31:54.600 --> 31:57.720 There's a lot of different CAN devices out there. 31:58.380 --> 32:05.520 You know, in general, you'll probably spend, no matter what you buy, you'll probably be in the $100 range, no matter, like for a good one. 32:05.520 --> 32:06.560 So I recommend it. 32:06.560 --> 32:09.660 There are tools called Elm, Elm devices. 32:09.860 --> 32:22.440 I, you know, for a beginner, I, and somebody who really wants to get into this, I would recommend staying away from them only because they really limit your ability to see what is actually happening. 32:22.700 --> 32:27.740 So I feel like you're limited to that particular protocol, which is great. 32:27.740 --> 32:34.220 Once you learn how diagnostics works, you can switch over to one of these tools, but I wouldn't start there. 32:34.220 --> 32:36.920 I think you're going to not get the full picture. 32:37.000 --> 32:44.520 And that's the reason why I like using one of these other tools that kind of, you can see everything on the bus, whereas these other tools are very hard to configure. 32:44.540 --> 32:47.660 Just something that you can plug in and just start monitoring right away. 32:47.660 --> 32:49.340 And that's the reason why I like the ValueCAN. 32:49.340 --> 32:51.500 It's pretty simple to set up. 32:52.040 --> 32:54.680 Even it works on Windows, it works on Linux. 32:55.060 --> 32:58.320 It works in a ton of different environments. 32:59.260 --> 33:00.720 Thank you for the question. 33:00.720 --> 33:02.020 Yeah, yeah, of course. 33:02.020 --> 33:09.740 And actually, so you have hardware, and then which software is to use most often? 33:12.340 --> 33:15.460 Again, Vehicle Spy is my number one tool. 33:15.480 --> 33:18.380 And then I write my, like, write your own, you know, Python. 33:18.380 --> 33:22.220 Probably Python is my biggest, like, fallback. 33:22.300 --> 33:29.000 But I like, I'll prototype it usually in Vehicle Spy, because it's really easy to write scripts and everything like that in it. 33:29.000 --> 33:36.580 And then once I'm ready to, like, make a tool and try it again, I'll switch over to Python and write everything there. 33:36.580 --> 33:40.600 There's a lot of good CAN libraries in Python as well. 33:42.400 --> 33:43.640 Okay, great. 33:43.640 --> 33:44.960 Thank you so much. 33:45.060 --> 34:01.240 Yeah, there was a lot of discussion going on in the Discord channel about getting involved, getting started, and how to, which hardware, which softwares, and which tools in general. 34:01.240 --> 34:10.540 So if you have any recommendations about where you would like to get started, or if you were getting started, I think that would really help everyone. 34:11.820 --> 34:12.220 Yeah . 34:12.340 --> 34:18.180 You know, my problem is I'm a little biased just because I started working at the company that makes the tools. 34:18.180 --> 34:19.840 So I know them really, really, really well. 34:19.840 --> 34:22.040 And I also know the people who wrote the tool. 34:22.100 --> 34:24.580 So I have a very distinct advantage. 34:24.860 --> 34:27.260 So that helps. 34:27.360 --> 34:29.520 So not a lot of people have that particular thing. 34:29.520 --> 34:35.960 So it's really hard for me to recommend other tools, because honestly, I don't use anything else that much, besides writing my own tools. 34:35.960 --> 34:42.860 I typically stay with what I know, not to say that there's not other good tools out there. 34:42.860 --> 34:46.800 And I've heard a lot from a lot of other tools, like good news from other tools. 34:46.800 --> 34:48.820 So it's really hard for me to answer that. 34:48.820 --> 34:51.000 But there's a lot out there. 34:51.160 --> 34:55.400 I mean, over the past four or five years, it's just been an explosion of CAN bus tools. 34:55.540 --> 34:59.360 It seems like every year DEF CON, somebody's releasing a new CAN bus tool. 34:59.360 --> 35:03.460 So, you know, just check out a bunch of talks. 35:03.460 --> 35:04.340 Find out what you like. 35:04.340 --> 35:05.520 Ask your friends. 35:06.300 --> 35:13.540 And, you know, we're using the value CANs attached to Raspberry Pis here at the Car Hacking Village. 35:13.540 --> 35:15.060 And so they work really well. 35:22.360 --> 35:24.200 Yeah, absolutely. 35:24.200 --> 35:25.180 Please. 35:25.860 --> 35:28.660 Robert, just one last question. 35:29.960 --> 35:34.380 So where do you find all your resources? 35:34.380 --> 35:41.800 Like, is there a specific place that you like to look for different links or different, like, softwares? 35:44.500 --> 35:47.380 There's not a lot of good resources out there. 35:47.380 --> 35:51.440 I've been trying to make them happen. 35:51.960 --> 35:58.820 I feel like, you know, there's a couple of good forums out there that I've used before. 36:00.620 --> 36:06.900 MHH Auto is a really good forum out there that you can get on. 36:06.900 --> 36:14.080 I've also used, that I've been a part of, that are really good. 36:14.080 --> 36:15.440 So some private slacks. 36:15.440 --> 36:18.460 I don't know if there's one that's public right now. 36:18.460 --> 36:19.760 Some car research slacks. 36:19.760 --> 36:20.260 I don't know. 36:20.680 --> 36:27.120 I'm sure the ASRG has probably some good ones out there, too, that are happening that might be available. 36:27.460 --> 36:36.340 But , you know, everything's, you know, the automotive industry is pretty tight-lipped in general about how to access these systems. 36:36.440 --> 36:42.920 So you've just got to, like, you know, figure it out, like, with just poking at the vehicle sometimes. 36:43.580 --> 36:49.180 There's some good, like, databases that are coming up in GitHub. 36:49.180 --> 37:00.380 There's a CAN OpenDBC, I think it's called, GitHub repository by comma AI that I really like. 37:00.780 --> 37:04.360 So it's not perfect, but it's a great start. 37:04.360 --> 37:07.180 It gives you an idea of what's on the other end. 37:07.180 --> 37:16.700 Now, these DBC files are sort of de facto standard for CAN bus normal messages that doesn't really do much for diagnostics. 37:16.740 --> 37:24.200 So diagnostics, I typically take existing scan tools, get my hands on them in whatever way I can. 37:24.260 --> 37:26.220 I like the eBay borrow method. 37:26.220 --> 37:34.380 If you've never had done the eBay borrow method, you buy something on eBay, and then you resell it on eBay after you're done with it for the same price you bought it for. 37:34.380 --> 37:38.720 It's a really great way to get into this space for very cheap. 37:38.820 --> 37:46.160 These tools used tend to not devalue after you purchase them, and especially if you're using them only for a few months. 37:46.220 --> 37:52.080 So it's a great way to, like, be out a few, you know, maybe if it's $1,000, but you can turn around and sell it for $1,000 a few months later. 37:52.080 --> 37:56.220 So it's not like, you know, it's not like you're out a ton of money. 37:56.220 --> 38:05.420 Even if you're out only 100 bucks, so just borrowing tools, scan tools from different companies, each manufacturer tends to sell their own. 38:05.420 --> 38:07.420 Great resources for it. 38:07.420 --> 38:10.320 So there's a lot of different ways to do this. 38:10.800 --> 38:11.720 Awesome. 38:11.720 --> 38:17.940 Well, thank you so much for the talk, the presentation, the demonstration and everything. 38:19.740 --> 38:25.060 Robert, I don't think we have any more questions, so I think we're just going to move on to the next talk. 38:25.060 --> 38:28.160 The next talk is in 21 minutes.