[00:10.410 --> 00:19.510]  Got the correct audio set up here. So just one second...
[00:30.460 --> 00:35.860]  There we go. Mr. Liali.
[00:38.140 --> 00:41.760]  Hey, how's it going, John? Good. How are you, sir?
[00:43.260 --> 00:46.900]  I'm good. Sorry about the background noise. 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:03.750]  So it's your show. What can you tell us about
[01:03.750 --> 01:07.830]  fundamentals of diagnostic requests over CAN bus?
[01:12.450 --> 01:18.410]  So this is a new one for me. Not diagnostic over CAN, but trying to present from a garage
[01:18.410 --> 01:21.790]  that doesn't have air conditioning. So wish me some luck.
[01:22.410 --> 01:28.550]  So right now I'm in the Car Hacking Village garage that we're hosting the Village. So
[01:28.550 --> 01:36.530]  behind me, you'll hear the emcee for our 101 talk. So there's a little bit of crosstalk,
[01:36.530 --> 01:42.050]  but once that's over, it'll just be me. Hello, everybody. My name is Robert Liali.
[01:42.050 --> 01:50.770]  I also go by CarPlucker. So you'll find me on the Discord right now. I have actually two different
[01:50.770 --> 01:55.590]  names going on. One so I can get the experience of the user, and one so I have the experience
[01:55.590 --> 02:01.630]  of the Village user. So you'll see two CarPluckers, C-A-R-F-U-C-A-R. So just go ahead and DM
[02:02.530 --> 02:06.850]  any one of those. I should get that if you guys have any follow-up questions.
[02:07.130 --> 02:12.770]  I'm also in the voice channel right now. I've muted myself, but later when I take some questions,
[02:12.770 --> 02:17.110]  I'll make sure I unmute myself so I can hear some of the questions that might be coming up.
[02:17.110 --> 02:23.330]  I won't be able to respond to them because I don't have... I'm as a normal user, but I'll
[02:23.330 --> 02:29.610]  try to type it in there, and maybe as John is rebroadcasting, I'll try to get some of that
[02:29.610 --> 02:34.590]  information out. So let me go ahead and get started and just kind of go over real quickly
[02:34.590 --> 02:42.850]  what is Diagnostics. So I don't have a very perfect presentation here, but I do have an
[02:42.850 --> 02:48.850]  old presentation that I've given before. So let me just close this up and just kind of go over
[02:48.850 --> 02:55.690]  the concepts of Diagnostics as it relates to vehicle systems. So Diagnostics is a layer
[02:55.690 --> 03:01.590]  of communications that allow you to connect and send requests directly to
[03:02.630 --> 03:10.190]  vehicle controllers, right? So one of the challenges though is Canvas has a very limited
[03:10.190 --> 03:15.610]  amount of space that you can put data bytes in. Specifically, you can't send more than eight
[03:15.610 --> 03:24.830]  data bytes. So in order to do that, they need to send... they need to send about 4,095 bytes. You
[03:24.830 --> 03:30.370]  have to use other protocols. So specifically, most Diagnostics in vehicle systems use a protocol
[03:30.370 --> 03:39.290]  called ISO 15765-2. This is sometimes referred to as the transport protocol or ISOTP
[03:39.820 --> 03:45.590]  or CAN ISOTP sometimes. This is the transport protocol that nearly every Diagnostic protocol
[03:45.590 --> 03:52.230]  builds upon. So this is that middle layer or transport layer that bridges the CAN bus limitations
[03:52.230 --> 03:59.390]  to allow for longer message lengths. So a lot of people and a lot of companies
[04:00.770 --> 04:08.850]  GM, Ford, Toyota, everybody uses this... seems to use this protocol now for all of their Diagnostic
[04:08.850 --> 04:13.930]  protocols. Now there are a handful of different Diagnostic or what we call high-level protocols
[04:13.930 --> 04:19.770]  or application layer protocols. I'm going to focus on one. It's called UDS. And the reason
[04:19.770 --> 04:26.810]  why I'm going to focus on UDS is because it's the most well-known and highest used one.
[04:26.810 --> 04:32.190]  Almost all Diagnostic protocols are kind of based off this particular one. So what I want to do is
[04:32.190 --> 04:38.570]  I'm going to take you through a process. Now this is a process that is actually related to OBD2,
[04:38.570 --> 04:45.390]  but this particular process takes apart a Diagnostic CAN message. So here's a flow
[04:45.390 --> 04:51.250]  for Diagnostic CAN messages. Let me just... I have two screens, so this is coming across
[04:51.250 --> 05:03.850]  the wrong screen. So let me just turn that feature off so that we can play this back on
[05:03.850 --> 05:13.490]  the main screen. I would like to run the slideshow from the current slide, but I don't want presenter
[05:13.490 --> 05:21.010]  mode. So let me just find out. No, I don't want that. I want to do that out of the primary monitor
[05:21.690 --> 05:26.950]  and from the current slide. So this should allow us to see this a little bit better.
[05:27.310 --> 05:33.550]  So I'm going to take you through the individual process, just sort of on a slide, and then I'm
[05:33.550 --> 05:37.370]  going to take you through it on an actual vehicle, but actually going to take you through on the
[05:37.370 --> 05:42.750]  vehicles that we're using for the Car Hacking Village challenges today. So
[05:43.950 --> 05:51.230]  here is ISO 15765-2. There are high-level protocols that run on top of it. I'm going to
[05:51.230 --> 05:57.190]  talk about specifically the OBD2, in this case this will be OBD2 Diagnostic Protocol, sometimes
[05:57.190 --> 06:05.370]  called J1979. So this is sort of like a standard protocol family that's across all vehicles,
[06:05.370 --> 06:10.930]  makes and models that are on the road today. So let's take a look at a flow of messages,
[06:10.930 --> 06:16.010]  the example of flow. So I'm going to take a really simple one that really illustrates every
[06:16.650 --> 06:23.210]  facet of this particular protocol, ISO 15765-2, specifically the VIN request. So the VIN request
[06:23.210 --> 06:33.670]  has the two bytes. The two bytes are 09 and 02. 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:43.670]  In this case, we'll ask the engine controller, because every vehicle tends to have an engine
[06:43.670 --> 06:50.210]  controller. We'll ask the engine controller, hey, what is the VIN? And the first part of every
[06:50.210 --> 06:54.810]  request is the service or function you want it to perform. Now there's a list of all of these
[06:54.810 --> 07:03.150]  functions, specifically OBD2 functions. If you just google OBD2 services or OBDIDS, you'll see
[07:03.670 --> 07:11.270]  Wikipedia has a very good list of the individual services called modes that are available for OBD2.
[07:11.270 --> 07:21.650]  So service 09 is a request service. The function or sub-function 02 is the parameter ID for the
[07:21.650 --> 07:26.370]  VIN. So if I were to change that from 02 to 01, I would get the VIN. I'd get something else
[07:26.970 --> 07:31.830]  from the controller. But it'd still be a request, but for a different parameter.
[07:31.830 --> 07:39.270]  So here's my VIN request, 0902. And I'm going to go ahead and move this up to my VIN request.
[07:39.270 --> 07:45.070]  Look at that. Pretty exciting. Kind of came through the video. I'm also monitoring the
[07:45.070 --> 07:49.390]  video. It looks like you guys saw a little bit of animation. Spent a whole two hours
[07:49.390 --> 07:55.570]  working on that animation, so give me some credit there. So there's our request, 0902.
[07:56.430 --> 08:01.630]  Everybody with me? Raise your hand if you are. Okay, good. Excellent. I like to see that.
[08:01.630 --> 08:06.230]  So next, we have our VIN response. So you'll see our VIN response is significantly larger
[08:06.230 --> 08:12.010]  than our request, because it includes our information about the success of the request,
[08:12.010 --> 08:17.850]  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:28.670]  So we'll have at least 17 characters to encode the VIN. In fact, in this case, we'll have 20
[08:28.670 --> 08:37.630]  characters, 17 characters plus three overhead bytes that are happening. So we see the 0902,
[08:37.630 --> 08:43.990]  but now our response will come back, and you'll see it says 4902. So as you guessed it,
[08:43.990 --> 08:49.450]  that first databyte is, again, a service indicator, so a service byte. But it's not the service or
[08:49.450 --> 08:54.350]  function that we perform, but rather the response or the information that's coming back from the
[08:54.350 --> 09:01.630]  service itself. And rather, will we see a successful request or not? And each time we see 49,
[09:01.630 --> 09:07.270]  or 40 hex more than our original service ID, we know that this is a positive response. So in this
[09:07.270 --> 09:13.930]  case, this request that we're getting, that we sent out, was successful. Our response is positive,
[09:13.930 --> 09:20.750]  because we see 40 hex more than our original request. The 02 is just an echo of the original
[09:20.750 --> 09:25.890]  parameter ID, or PID, in this case, the VIN request. So even if we didn't see what the initial
[09:25.890 --> 09:33.350]  response was, we could tell that this wasn't that, indeed, a response to the VIN request.
[09:33.390 --> 09:41.030]  The next byte, the 01, is actually an encoder to let us know that this is actually an ASCII-encoded
[09:41.030 --> 09:48.110]  parameter. So now one challenge we have here is this is now 20 bytes. If you know anything about
[09:48.110 --> 09:54.150]  CAN bus, CAN bus only allows 8 bytes per frame. So we have to do something about this. If we can't
[09:54.150 --> 09:58.590]  fit this into a CAN bus frame, we have to segment it. We have to break it apart.
[09:58.830 --> 10:05.210]  And so, how do we do that? So we take the first part of the message, we take the second part of
[10:05.210 --> 10:09.110]  the message, then we take the third part of the message and we break them across three different
[10:09.110 --> 10:16.110]  frames. Okay? So now we have three frames of CAN bus messages. So here they are,
[10:16.990 --> 10:22.070]  490201C. It's the same frames, but we had to break them up into different frames. Okay? So
[10:23.610 --> 10:29.770]  I'm going to go back. I'll reiterate that we are sending this message to the engine control system.
[10:29.770 --> 10:36.010]  So since it's to the engine controller, we need to identify each frame. Each frame identifier
[10:36.510 --> 10:41.590]  is essentially part of the arbitration ID of a CAN message. Every CAN message has an arbitration ID,
[10:41.590 --> 10:45.550]  and inside of that arbitration ID is the identifier for the controller that we're
[10:45.550 --> 10:52.370]  talking to. In this case, we're talking to the engine controller, which is legislated at 7E0
[10:52.370 --> 11:01.130]  for 11-bit CAN bus system. So since we're talking on an 11-bit CAN bus system, we'll say 7E0 and
[11:01.130 --> 11:09.290]  then we'll say 0902. Okay. Awesome. Here we have a message that goes across. But we need to add
[11:09.290 --> 11:15.050]  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:28.510]  So the PCI data could be the frame type specifically. So here we put a 0 in. A 0
[11:28.510 --> 11:36.050]  is a frame type. That frame type 0 is a single frame message. So right away in the first data
[11:36.050 --> 11:41.910]  byte of this particular frame, we know that this message is going to be a single frame message
[11:41.910 --> 11:47.870]  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 --> 12:00.550]  So it indicates how many bytes this particular message is going to be. In this case, since our
[12:00.550 --> 12:06.830]  message is 0902, we have two bytes in our message, we put a 2 in that data byte, indicating that
[12:06.830 --> 12:15.910]  there's two bytes of data. Really simple. 02. Very obvious if you think about it. Here we have a 020902.
[12:16.310 --> 12:21.550]  And now we'll do one more thing. We'll do this thing called padding. Padding is a way of filling
[12:21.550 --> 12:27.850]  in the data. Not all cars require this, but I always recommend it because some cars do require it.
[12:27.850 --> 12:33.550]  And later what I do in my demo, I'm going to show you guys how that is the case. So now we fill in
[12:33.550 --> 12:38.250]  the rest of this data with padding. The reason why we know it's padding, because again, we go back to
[12:38.250 --> 12:44.250]  the beginning of the data frame, and we see the 02. That 2 is an indicator of how big this
[12:44.250 --> 12:50.070]  particular message is. So we count one, two bytes, 0902. Those are our two bytes of our message.
[12:50.070 --> 12:55.510]  Anything after that must be padding, right? 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:06.790]  All right, so we send a request out. Now we should get a response back.
[13:06.790 --> 13:11.610]  Our response ID has got to be different than our request ID, but it's usually just a little bit
[13:11.610 --> 13:15.890]  different. Sometimes it's significantly different, but sometimes it's very much the same. In this
[13:15.890 --> 13:23.350]  case, our response ID will be 8 more than our request ID. So 70E0 returns a 70E8. This is
[13:23.350 --> 13:29.550]  part of the OBD2 specification for emissions-related controllers, so that's just very
[13:29.550 --> 13:35.610]  common, as you'll see. So again, we'll have a frame type, just like we had before in the first nibble
[13:35.610 --> 13:41.030]  of the first byte of the last frame. We do the same thing here. We have a one to indicate that
[13:41.030 --> 13:49.010]  this is indeed a multi-frame message. So one equals multi-frame. Just like before, we had a
[13:49.010 --> 13:55.910]  data length, but since our multi-frame messages can be over 4,000 bytes, 4,095 to be exact,
[13:55.910 --> 14:01.650]  because we can have 4,095 bytes, we need more bits to encode that information. So the four bits,
[14:01.650 --> 14:07.330]  or one nibble, that we saw in the single frame message just before is not enough. We need more
[14:07.330 --> 14:13.690]  bits. So we expand. Now that we use those four bits, but we also use the next eight bits as well,
[14:13.690 --> 14:21.930]  giving us a total of 12 bits, so 2 to the power of 12 total number of values that we can have,
[14:21.930 --> 14:29.970]  so 4,095. So now we know how many bytes we can have. So I put a 014 to indicate that this is
[14:29.970 --> 14:37.230]  actually going to be 20 bytes long. So 014 is hex. That equals 20 in decimal. And then we fill in the
[14:37.230 --> 14:45.770]  rest of the actual message itself. So recall the VIN message starts at the 49, 02, 01, 31, 32, 33.
[14:45.770 --> 14:52.410]  So that's the data that's going to be encoded in the VIN. So we just sent a request to a controller.
[14:52.410 --> 14:57.910]  It just responded back to us saying it's going to send us a multi-frame response. What if we can't
[14:57.910 --> 15:05.150]  handle a multi-frame response? Or what if we need to reserve a buffer and we need to do that quickly?
[15:05.150 --> 15:12.090]  We need to give some feedback to the controller saying, hey, listen, I'm either able to do this or
[15:12.090 --> 15:15.750]  I'm not able to do this. So that's what we call our flow control. So we're going to send another
[15:15.750 --> 15:22.750]  message back to the controller to let it know that the kind of the rules of how it's allowed
[15:22.750 --> 15:28.530]  to transmit the rest of the data back to us. 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:39.110]  So we're going to send a flow control response back to it. Now, we have to do this within 100
[15:39.110 --> 15:44.010]  milliseconds of the request that we sent. So you have to do this programmatically. You'll never be
[15:44.010 --> 15:48.750]  able to do this by hand or manually. So if you're typing in, like, send flow control or something
[15:48.750 --> 15:53.470]  like that, you'll never get the timing that you need in order to do that. So you have to run some
[15:53.470 --> 15:59.410]  sort of script locally to the hardware or something like that in order to have success with it. Or
[15:59.410 --> 16:04.470]  your hardware needs to support this particular feature. So that's something that's important to
[16:04.470 --> 16:10.890]  keep in mind when you're doing diagnostics. Next, we need to send a... it's clear to send.
[16:11.050 --> 16:17.790]  So we say a 0 in the next nibble of the next bite indicating it's clear to send. If it's not a 0,
[16:17.790 --> 16:23.870]  it's some error. 1 is an error. Hey, you can't send this. So usually that will mean
[16:23.870 --> 16:29.730]  that the controller stops sending its request. The next is the block size. So that's how many
[16:29.730 --> 16:36.010]  blocks or messages or frames, I should say, that you need to... you can send before another
[16:36.670 --> 16:43.590]  flow control is sent back. So normally that's set to 0, meaning I'm not going to send any more
[16:43.590 --> 16:48.850]  blocks. Don't worry about the blocks. I'm just going to... I'm just going to send this one flow
[16:48.850 --> 16:53.310]  control frame. You finish up the rest of the message. You don't need to hear from me again.
[16:53.310 --> 16:59.190]  These are the rules. Sometimes it can be a number not 0, meaning if that was a 0, 1,
[16:59.190 --> 17:03.290]  then the controller would send a message back to me, and then I would send another flow control
[17:03.290 --> 17:06.210]  frame, and then the controller would send another message, and I would send another flow control
[17:06.210 --> 17:12.010]  frame, et cetera, et cetera, et cetera. So that number essentially is how many more frames until
[17:12.010 --> 17:19.710]  I send a flow control. Last parameter here is the frame separation. This is the actual time
[17:20.410 --> 17:25.610]  in milliseconds that we need to wait between... that the controller that's returning the data
[17:25.610 --> 17:30.790]  back to me needs to wait for it to send a message. So 0A equals 10 milliseconds.
[17:30.990 --> 17:38.630]  And again, we have padding as well. Now we get a response back. The next frame comes after the
[17:38.630 --> 17:43.870]  first frame that we got. The next data bytes. In fact, the next seven data bytes. Why seven,
[17:43.870 --> 17:48.630]  not eight in the Canvas frame? Because we still have more PCI data. Specifically,
[17:48.750 --> 17:54.250]  a frame type of two. Two indicates that this is a... what we call a consecutive frame. A frame
[17:54.250 --> 17:59.310]  that happened after a first frame. So if you were just to look at this and just monitoring the
[17:59.310 --> 18:03.030]  Canvas, and you saw that this is a consecutive frame and you didn't have the first part of the
[18:03.030 --> 18:08.510]  frame, you would know that you missed some data. So it's super important to know that if some other
[18:08.510 --> 18:13.550]  system is monitoring it, that this is not the first part of the data. But what part of the data
[18:13.550 --> 18:18.410]  is it? Well, we have this rolling code that comes next, indicating that this is the first
[18:19.670 --> 18:26.450]  consecutive frame. So we have a one there. The next frame will come. It will also be a... have
[18:26.610 --> 18:31.130]  a two as well, because it's also a consecutive frame. But instead of having a one in the rolling
[18:31.130 --> 18:36.630]  code section, it will have a two. And guess what? The next one will have a three and a four and a
[18:36.630 --> 18:41.250]  five, et cetera, all the way until we hit F. And then we just roll back over to zero. So you'll
[18:41.250 --> 18:47.370]  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,
[18:47.370 --> 18:51.290]  5, et cetera, et cetera, if there were more data or more frames that needed to be sent.
[18:51.430 --> 18:55.870]  But for the most part, this is pretty simple. We've essentially requested the VIN and received
[18:55.870 --> 19:03.050]  the VIN back from the controller, all pretty quickly and pretty simply. So I want to take
[19:03.410 --> 19:08.370]  a little bit of time. So I'm about 18 minutes in. Great. I'm doing well on time. I want to
[19:08.370 --> 19:13.030]  take some time and do a little live demo. Now, you know what live demos are. They're always bad.
[19:13.030 --> 19:17.030]  Don't ever do this. So I'm going to go ahead and do this. All right? So let me bring up
[19:18.110 --> 19:26.130]  all of these. I've got a few different windows open here. Specifically related to our system
[19:26.130 --> 19:34.050]  here. I'm going to go ahead and minimize a few things here. Okay. So this is the
[19:36.150 --> 19:40.530]  this is SocketCAN. If you're not familiar with SocketCAN, we have some really cool information
[19:40.530 --> 19:45.310]  about how to get started with SocketCAN. In fact, everything I'm doing right now, you can come over
[19:45.310 --> 19:52.890]  to the CarHacking Village. Join the virtual.carhackingvillage.com CTF. It's easy to join.
[19:52.950 --> 19:58.550]  Just sign up and you can get into the queue. And you, too, can also plug into this vehicle
[19:58.550 --> 20:03.050]  virtually as well and do all of these same things. So I highly recommend you guys do that
[20:03.050 --> 20:08.990]  if you have time. And we have some pretty good getting started instructions on our web page as
[20:08.990 --> 20:14.910]  well. If I have time, I'll try to go into those as well. So I've taken a few seconds and created
[20:16.190 --> 20:20.710]  a couple different windows. One window looks like some people are having some fun on these
[20:20.710 --> 20:25.690]  networks as well. So we might get some spurious data coming across. Also, I'm going to clear up
[20:25.690 --> 20:32.090]  some of these windows real quick. Let me just cancel out of this and reload it. Okay. So
[20:32.650 --> 20:36.550]  it might be a little tight to see. You might need to zoom in, squint your eyes.
[20:36.850 --> 20:41.170]  Let me just see if I can make this a little bit bigger. Yeah, a little bit bigger. Okay.
[20:41.170 --> 20:48.510]  A little bit bigger. All right. That's a little bit bigger. That's nice. That's very nice. Okay.
[20:49.930 --> 20:56.410]  Same here. Okay. So I made it a little bit bigger. Hopefully you guys can see a little bit easier.
[20:56.910 --> 21:01.550]  So what we have, I have three different windows. One I use for... these are all terminal windows.
[21:01.550 --> 21:07.450]  One I use a program called CanSend. It's a CAN utility. You can download CAN utilities available
[21:07.450 --> 21:13.290]  as well. It's already available on this particular device for you. CanSend essentially takes a few
[21:13.290 --> 21:20.270]  arguments. One is the device that we want to send the data on. We have two CAN buses that are
[21:20.270 --> 21:26.450]  available. CAN0 and CAN2 are available on this particular vehicle. If I send data on CAN2,
[21:26.450 --> 21:35.570]  it's actually on a gateway network. So you can't see the data. This is actually the CAN dump of
[21:35.570 --> 21:43.750]  CAN2. So what we see below here is nothing. So if I were to send a CANSend message, which I'll do.
[21:43.750 --> 21:49.930]  In fact, I'm going to do a bad message. So you guys can see a bad message go across. Of course,
[21:49.930 --> 21:57.810]  I sent it on CAN1, my bad. I'm going to send it on CAN2. Give me a second here.
[21:57.990 --> 22:06.530]  It's a little slow. All right. So I sent a message on CAN2, and then I was monitoring CAN2 using
[22:06.530 --> 22:13.190]  CAN dump. Again, I sent my message. I actually sent what's called a tester present message. So
[22:13.190 --> 22:17.350]  it's a pretty standard way of just kind of pinging the network, just saying, hey, there's a tester
[22:17.350 --> 22:24.370]  here. I sent it on an ID7DF, which is a broadcast ID to a handful of controllers. So hopefully I
[22:24.370 --> 22:28.730]  get one of them to respond back to me. But I malformatted the message intentionally. I sent
[22:28.730 --> 22:33.870]  it with seven data bytes, not eight. And remember, I was talking about padding. Padding is important.
[22:33.870 --> 22:38.170]  So you have to make sure that you pad with all eight data bytes. As soon as I do that, you'll
[22:38.170 --> 22:44.310]  see I get a few more responses back. Again, this is a broadcast message to a handful of controllers.
[22:44.310 --> 22:49.730]  I actually got three different messages happen after my initial request. So here's my initial
[22:49.730 --> 22:57.850]  request right here. I don't know if you can see this very well. But it's essentially 7DF023E,
[22:57.850 --> 23:04.550]  and then the rest are zeros. That is a tester present. And so I get a bunch of responses back
[23:04.550 --> 23:09.870]  from three different controllers, two of which give me what are called the negative response.
[23:09.870 --> 23:15.830]  The negative response is a 7F, and the positive response is a 7E, which is 40x more than my
[23:15.830 --> 23:21.810]  initial request. So I set the request correctly, but I got different responses back. That tells
[23:21.810 --> 23:25.910]  me a lot about the system right away, that these different controllers are configured with
[23:25.910 --> 23:34.130]  different versions of diagnostic request services. So it's quite normal to see that different
[23:34.130 --> 23:40.750]  controllers run different diagnostic request applications, and that's no different here. So
[23:40.750 --> 23:48.930]  you might find something like that. So let's go back to our original concept of sending a
[23:48.930 --> 24:00.330]  request for our engine, or our VIN. So again, 7E0020902, and then I'll fill this in with
[24:00.750 --> 24:09.110]  zeros. So I send that request. Of course, you know how it goes. There it goes. I get my response
[24:09.110 --> 24:13.690]  back. 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.850]  I'm sure if it's hard for me, it's even more difficult for you. So let me just try to make
[24:17.850 --> 24:27.030]  this even bigger, so you guys can see it a lot better. Okay, so I'll send my request.
[24:27.490 --> 24:33.250]  I got to actually hand dump. Okay, send my request again.
[24:35.030 --> 24:42.930]  And you'll see we get a request and response. So our response is the first part of the VIN
[24:43.490 --> 24:46.890]  on this particular vehicle. I'm not going to do the rest, because I'm broadcasting
[24:47.610 --> 24:52.270]  live on a real vehicle, and you can get the idea. You know, sending VINs out there,
[24:52.270 --> 24:56.590]  as cool as that is, if you want this VIN, you got to get it yourself. But you know what the
[24:56.590 --> 25:01.930]  next thing is, I have to send a flow control frame. Now, like I told you, I can't do this
[25:01.930 --> 25:08.850]  by hand, right? So if I want to send a flow control, I would need to send a 70, 0,
[25:09.970 --> 25:19.890]  3, 0, and then space there. It's a little slow here on my end. You guys are going through.
[25:19.890 --> 25:25.110]  But I'd have to set something like this. Now, because of my timing, I'm not going to get this
[25:25.110 --> 25:29.910]  message going out correctly. Even if I wanted to, I'd have to script this in some way. So I could
[25:29.910 --> 25:34.830]  create a bash command to send one and then the other within a certain period of time. I could
[25:34.830 --> 25:39.910]  create a script. I could try to chain them together, maybe with an ampersand. It's, you know,
[25:39.910 --> 25:45.870]  maybe a little time sleep between them. Something like that. I don't know if time sleep has a
[25:45.870 --> 25:50.910]  millisecond control on bash. But if it did, we could do it that way. We just did a little bit
[25:51.810 --> 25:57.450]  of a delay. Maybe there's enough of a delay already. But if we send our flow control a little
[25:57.450 --> 26:04.590]  too fast before the actual controller sends its response, it might ignore our follow-up.
[26:04.590 --> 26:11.170]  So that's kind of how we can send a simple request to these controllers. Later tomorrow,
[26:11.170 --> 26:19.230]  I'm going to have a whole talk related to what I call CMAP. It's a way of mapping out diagnostic
[26:19.230 --> 26:26.030]  requests across the board. Not necessarily using SocketCAM, but using a Python interface that just
[26:26.030 --> 26:32.730]  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:39.010]  I have also here the actual powertrain network that's on the bus. Now, you'll notice there's a
[26:39.010 --> 26:42.710]  lot of data running across there. I'm going to go ahead and cancel this. And what I'm going to
[26:42.710 --> 26:47.770]  do is I'm just going to filter. I want to show you a little bit about SocketCAM filtering.
[26:48.410 --> 26:55.150]  So CanDump, we can monitor the CanDump, but I'm going to monitor a different network,
[26:55.150 --> 27:00.490]  specifically Can0, which is the powertrain network. Can2 is the diagnostic network. So
[27:00.490 --> 27:06.250]  any diagnostic, as I said, I can see they get transferred over to the correct network
[27:06.250 --> 27:12.730]  that is supposed to manage that particular identifier. In this case, 70.0 should get
[27:12.730 --> 27:21.090]  rebroadcast by the gateway over to the powertrain network, which is Can0 in this case.
[27:21.090 --> 27:25.250]  But because there's so much data, it's really hard to see it. So what's cool about CanDump is
[27:25.250 --> 27:32.070]  you can do some filtering. In this case, I'll filter on 70.0, but I also want to capture the
[27:32.070 --> 27:39.310]  70.8 message. So I'll type in 70.0 here, but what I'll actually do is I'll add a filter mask. If I
[27:39.310 --> 27:46.350]  just want to do 70.0 messages, I put a 7FF, which is an indicator of 11 bits of 1s. If you understand
[27:46.350 --> 27:52.550]  how bit masks work, if you don't, I recommend doing a reading up on bit masks. Specifically,
[27:52.550 --> 27:57.530]  what I'm interested in is I want to see anything that starts with 7E, but I don't care about what
[27:57.530 --> 28:03.950]  the last byte is or bit or nibble, I should say. Now, in this case, I'll just put a 0 there,
[28:03.950 --> 28:12.010]  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:18.830]  So I just put a 7F there. If I hit enter here, now only messages that have 7E something in them
[28:18.830 --> 28:22.870]  will show up. So I'll go ahead and send my initial request. Now remember, I'm sending on
[28:22.870 --> 28:29.210]  Can2 right now, but I will see it on Can0, which are two separate, physically separate networks,
[28:29.210 --> 28:33.610]  but there is a controller in between them that is gatewaying that information. So go ahead and send
[28:33.610 --> 28:38.970]  that request. Oops, I did not send the actual request. Let me send this one again. And we can
[28:38.970 --> 28:45.610]  see both my message going across, not only on the Can2 network, which I anticipate, right? You
[28:45.610 --> 28:49.270]  monitor a network, you look at it, you're going to get the data back, but you also see it on a
[28:49.270 --> 28:55.010]  separate network as well. That's because I'm actually sending through something. Now, the
[28:55.010 --> 28:59.470]  reason why I set it up this way is I wanted to see if somebody could go through and say, hey,
[29:00.250 --> 29:08.070]  I'm going to scan all possible identifiers on the diagnostic network and see what comes out,
[29:08.070 --> 29:16.610]  see what actually is being forwarded between the diagnostic side and the non-diagnostic side,
[29:16.610 --> 29:20.930]  or the powertrain side. There's probably some correlation. You can learn a lot about how the
[29:20.930 --> 29:26.730]  system works just by poking at it. It's a great way to poke at it. So I've run about 30 minutes,
[29:26.730 --> 29:31.190]  which was my goal today, to hit about 30 minutes. So what I'm going to do is take it there and then
[29:31.190 --> 29:36.510]  see if there are any questions for you from the audience. So I'm going to turn my audio back on
[29:36.510 --> 29:42.790]  so I can hear you guys if you guys are talking in this channel. And go ahead and fire an audio
[29:42.790 --> 29:50.770]  question away. If there's a question inside of the one-on-one chat section, I'll also switch
[29:50.770 --> 29:56.610]  over to that support. So I'm also monitoring the one-on-one chat. So if there are any questions,
[29:56.610 --> 30:02.110]  I'm happy to take them. If not, I'll say, hey, thank you very much. And hopefully you guys get
[30:02.230 --> 30:11.130]  a chance to hack these cars. Please go ahead, anybody. Robert, thank you so much for the
[30:11.130 --> 30:24.310]  presentation. It was fun. Sorry, I have an echo. Sorry, it might be my fault. Let me just fix my
[30:24.310 --> 30:31.870]  end. Just one second. I'm going to mute myself. No, I don't know where it's going.
[30:37.000 --> 30:45.920]  Don't worry, it's okay. Did that exit? No, that didn't exit. No problem. No, it's not my fault then.
[30:48.600 --> 30:53.400]  Actually, I have a question. What kind of tools are you using
[30:54.240 --> 31:01.780]  to do this? Like, what hardware? I typically, I mean, I use Vehicle Spy right now. And Vehicle
[31:01.780 --> 31:07.840]  Spy is? Yeah, I use Vehicle Spy with a value can. I'm a big fan of it because I used to work there.
[31:08.240 --> 31:15.280]  So Vehicle Spy is a commercial tool. So it's not a free one, but it really, you know, when you're
[31:15.280 --> 31:20.440]  first learning this, one of the hardest parts is just setting it up and plugging it in. And if you
[31:20.440 --> 31:25.520]  got the time and the money, you know, to do it, I recommend getting a commercial tool because they
[31:25.520 --> 31:30.820]  work really well and there's support. But, so not everybody has that ability or their
[31:30.820 --> 31:39.160]  wherewithal to do that. So, you know, the obvious tools are out there are the Cannibal by
[31:43.620 --> 31:50.020]  Eric Evacek. He's got the, or not the Cannibal, he's got the Cantac, sorry. He's got the Cantac
[31:50.020 --> 31:54.140]  Pro that just came out. Those are really good tools that I've used several times.
[31:54.600 --> 32:01.100]  There's a lot of different CAN devices out there. You know, in general, you'll probably spend, no
[32:01.100 --> 32:05.880]  matter what you buy, you'll probably be in the $100 range, no matter, like for a good one. So I
[32:05.880 --> 32:11.900]  recommend it. There are tools called Elm, Elm devices. I, you know, for a beginner, I, and
[32:11.900 --> 32:17.100]  somebody who really wants to get into this, I would recommend staying away from them only because
[32:17.100 --> 32:24.920]  they really limit your ability to see what is actually happening. So I feel like you're limited
[32:24.920 --> 32:31.120]  to that particular protocol, which is great. Once you learn how diagnostics works, you can switch
[32:31.120 --> 32:36.060]  over to one of these tools, but I wouldn't start there. I think you're going to not get the full
[32:36.060 --> 32:40.500]  picture. And that's the reason why I like using one of these other tools that kind of, you can
[32:40.500 --> 32:44.980]  see everything on the bus, whereas these other tools are very hard to configure. Just something
[32:44.980 --> 32:48.600]  that you can plug in and just start monitoring right away. And that's the reason why I like the
[32:48.600 --> 32:56.300]  ValueCAN. It's pretty simple to set up. Even it works on Windows, it works on Linux. It works in
[32:56.440 --> 33:03.360]  a ton of different environments. Thank you for the question. Yeah, yeah, of course. And actually,
[33:03.360 --> 33:09.740]  so you have hardware, and then which software is to use most often?
[33:12.340 --> 33:17.680]  Again, Vehicle Spy is my number one tool. And then I write my, like, write your own, you know,
[33:17.680 --> 33:24.800]  Python. Probably Python is my biggest, like, fallback. But I like, I'll prototype it usually
[33:24.800 --> 33:29.340]  in Vehicle Spy, because it's really easy to write scripts and everything like that in it. And then
[33:29.340 --> 33:35.700]  once I'm ready to, like, make a tool and try it again, I'll switch over to Python and write
[33:35.700 --> 33:40.600]  everything there. There's a lot of good CAN libraries in Python as well.
[33:42.400 --> 33:49.260]  Okay, great. Thank you so much. Yeah, there was a lot of discussion going on in the Discord channel
[33:49.260 --> 33:59.420]  about getting involved, getting started, and how to, which hardware, which softwares,
[33:59.420 --> 34:04.480]  and which tools in general. So if you have any recommendations about where you would like to get
[34:04.480 --> 34:10.540]  started, or if you were getting started, I think that would really help everyone.
[34:11.820 --> 34:16.900]  Yeah. You know, my problem is I'm a little biased just because I started working at the
[34:16.900 --> 34:20.420]  company that makes the tools. So I know them really, really, really well. And I also know
[34:20.420 --> 34:28.060]  the people who wrote the tool. So I have a very distinct advantage. So that helps. So not a lot
[34:28.060 --> 34:31.280]  of people have that particular thing. So it's really hard for me to recommend other tools,
[34:31.280 --> 34:36.300]  because honestly, I don't use anything else that much, besides writing my own tools. I typically
[34:36.300 --> 34:43.900]  stay with what I know, not to say that there's not other good tools out there. And I've heard a lot
[34:43.900 --> 34:48.440]  from a lot of other tools, like good news from other tools. So it's really hard for me to answer
[34:48.440 --> 34:53.500]  that. But there's a lot out there. I mean, over the past four or five years, it's just been an
[34:53.500 --> 34:58.760]  explosion of CAN bus tools. It seems like every year DEF CON, somebody's releasing a new CAN bus
[34:58.760 --> 35:05.520]  tool. So, you know, just check out a bunch of talks. Find out what you like. Ask your friends.
[35:06.300 --> 35:11.240]  And, you know, we're using the value CANs attached to Raspberry Pis here
[35:11.240 --> 35:15.060]  at the Car Hacking Village. And so they work really well.
[35:22.360 --> 35:25.180]  Yeah, absolutely. Please.
[35:25.860 --> 35:34.620]  Robert, just one last question. So where do you find all your resources? Like,
[35:34.620 --> 35:41.800]  is there a specific place that you like to look for different links or different, like, softwares?
[35:44.500 --> 35:51.440]  There's not a lot of good resources out there. 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:11.780]  MHH Auto is a really good forum out there that you can get on. I've also used,
[36:11.780 --> 36:16.100]  that I've been a part of, that are really good. So some private slacks. I don't know
[36:16.100 --> 36:21.340]  if there's one that's public right now. Some car research slacks. I don't know. I'm sure
[36:21.340 --> 36:27.120]  the ASRG has probably some good ones out there, too, that are happening that might be available.
[36:27.460 --> 36:31.480]  But, you know, everything's, you know, the automotive industry is pretty tight-lipped
[36:31.480 --> 36:38.660]  in general about how to access these systems. So you've just got to, like, you know,
[36:38.660 --> 36:45.900]  figure it out, like, with just poking at the vehicle sometimes. There's some good, like,
[36:45.900 --> 36:54.540]  databases that are coming up in GitHub. There's a CAN OpenDBC, I think it's called,
[36:55.520 --> 37:04.440]  GitHub repository by comma AI that I really like. So it's not perfect, but it's a great start. It
[37:04.440 --> 37:11.460]  gives you an idea of what's on the other end. Now, these DBC files are sort of de facto standard
[37:11.460 --> 37:17.680]  for CAN bus normal messages that doesn't really do much for diagnostics. So diagnostics,
[37:17.680 --> 37:24.200]  I typically take existing scan tools, get my hands on them in whatever way I can.
[37:24.260 --> 37:28.400]  I like the eBay borrow method. If you've never had done the eBay borrow method,
[37:28.400 --> 37:33.220]  you buy something on eBay, and then you resell it on eBay after you're done with it for the
[37:33.220 --> 37:38.720]  same price you bought it for. It's a really great way to get into this space for very cheap.
[37:38.820 --> 37:44.540]  These tools used tend to not devalue after you purchase them, and especially if you're using
[37:44.540 --> 37:48.880]  them only for a few months. So it's a great way to, like, be out a few, you know, maybe if it's
[37:48.880 --> 37:53.200]  $1,000, but you can turn around and sell it for $1,000 a few months later. So it's not like,
[37:53.200 --> 37:58.780]  you know, it's not like you're out a ton of money. Even if you're out only 100 bucks,
[37:59.420 --> 38:04.720]  so just borrowing tools, scan tools from different companies, each manufacturer tends to sell their
[38:04.720 --> 38:10.320]  own. Great resources for it. So there's a lot of different ways to do this.
[38:10.800 --> 38:17.940]  Awesome. Well, thank you so much for the talk, the presentation, the demonstration and everything.
[38:19.740 --> 38:24.100]  Robert, I don't think we have any more questions, so I think we're just going to move on to the
[38:24.100 --> 38:28.160]  next talk. The next talk is in 21 minutes.