 All right. Let's go ahead and get started here. About me, my name is BitBang. I also go by Tim occasionally. I am a largely recovered software developer. I started my career doing a lot of safety critical aerospace and automotive and benefits systems. Came over to security about three years ago. And apparently, as you'll discover through this talk, I enjoy looking at bad situations and going, how can I make this worse? I work with a company called Grim. Grim does not take this view of making things worse all the time. We actually try to help people. We're a cybersecurity research development company located in Arlington, Virginia. As a company, we do most aspects of cybersecurity between our various teams. We're going to do a little bit of overview. We're going to talk about what is CANBUS. We're going to start with the basic high-level Wikipedia overview of how CANBUS works. And then we're going to dive into how CANBUS works at much greater detail than you typically get. Typically need to know because all the low level details are handled by an onboard CAN peripheral. And then we're going to talk about what we did this time. A little bit of history. CANBUS was developed by Bosch. It was released in 1983. The latest version, version 2.0 was released in 1991. It is a fairly old standard. And like many fairly old standards, when they developed it, they weren't really thinking about how to incorporate cybersecurity best practices because there was no such lane back then. The first production vehicle was in 1991. This here is patient zero. The 1991 Mercedes-Benz W140. ISO 11898 is the set of ISO specs that define CANBUS for automotive. So why do the car manufacturers love CANBUS so much and put it everywhere they possibly can? A lot of it, it's cheap. It's really cheap. Nearly any microcontroller you buy will have a CAN peripheral built into it because it's cheap, why not? It's reliable. If you don't ignore it, if you know all the people over there and what they like doing to cars, it's very reliable. It's designed from the ground up to be extremely reliable to environmental noise. It's used in a lot of situations like a building automation or some industrial applications where there's a lot of electromechanical noise going on. It's designed to be very reliable for that. And oh yeah, by the way, it's been mandated by law since 2008. Turns out a good way to get the OEMs to do something is to say you cannot sell your cars unless you do the thing. It's mandated by 40 CFR86, 1806-05. That mandates that all the cars have to follow the ISO spec 15765-4, road vehicle diagnostics on controller area network. This is required for your emissions related system. So any of you who live in a state that mandates that you do emissions tests, this is so that they can basically do those emissions tests more easily. They just have one tool, they plug in an OBD2 port, regardless of tool, and they can go in and make sure that all your emissions stuff is reporting that it is up to snuff. As I mentioned, CAN buses use quite extensively outside of automobiles. It's used a lot in some aviation areas, like I mentioned, billed automation, some industrial control type applications as well. Those often use a different physical layer. There's quite a few different physical layers that CAN bus will run on. We're going to focus on ISO 11898-2, which is the spec that the CAN bus uses in an automobile. So the way that ISO 11898-2, the physical layer works is you have this diagram here of a CAN bus. So we have bits going across the bus. CAN bus uses differential signaling. So anywhere you see that the voltages are the same on the two lines, that is an area that's transmitting a recessive bit, which is interpreted as a 1. And here where there are different voltages, that's a dominant bit, which is also interpreted as a 0. So this is the signaling across the lines on the car actual wires, the run through your car, this is what they carry. Those come into a CAN transceiver. And all the CAN transceiver really does is it takes this differential signaling and outputs your standard digital logic signal for your microcontroller to interface with. There's generally not really much in the way of smarts in a CAN transceiver. Some will do things like if you transmit a dominant state for 2-1, they'll shut off for you, but they don't really generally do a whole lot in terms of logic. If I'm sending a 1, it leaves the output of the recessive voltage I'm receiving. If I'm sending a 0, it puts the output at a dominant voltage and does the opposite for any signals that it receives. So that's how the physical layer works. And as we'll get to later, something that's important to keep in mind is that any time that you were, one of the core fundamental principles of CAN bus is that if any node on the bus is sending a 0, sending this dominant voltage, then that will be the state of the bus. So if any node is sending a dominant, the bus will be in a dominant state. The only time the bus will be in a recessive state is if every node on the CAN bus is sending the recessive state, sending a 1 to the bus. So this is what a CAN message looks like a CAN frame. You have a start of frame, which is a 0, so CAN in an idle state is a 1 of the recessive state. As soon as somebody wants to start sending a message, you have the start of frame, so we'll start transmitting a 0. Then you have this arbitration field. This message is for an 11-bit arbitration field. This is generally more common in automotive. There's also a variation that has a 29-bit arbitration field, and the difference there is that this ID extended bit instead of a 0 is a 1, and then after that 1, you have the other 18 bits of the arbitration ID plus two reserved bits instead of just one. But for all of the purposes, they're very similar, and they can operate with each other. You can have both 29-bit and 11-bit identifiers on the same CAN bus because you can look at this ID extension bit and know which length identifier it is. They have a length field. They have four bits for a length field. The maximum length of a CAN frame is eight bytes, and we'll talk slightly about why that can be somewhat problematic for some security applications in a little bit. You then have your 1 to 8 bytes of data that you're sending. It computes a 15-bit CRC. It's sort of a weird CRC, but it was chosen. It will always detect any single bit error and is really good at detecting like two and three bit errors as well. This plays into why CAN is so reliable that it's very good at detecting if a bit was flipped at some point due to automatic noise or whatever the case may be. A CRC delimiter, just a recessive at the end of the CRC to indicate the end of the CRC. Then you have this acknowledgement slot. So the acknowledgement slot is used for is any time a note on the bus properly receives a message. So it's the right length, it has the right CRC, everything about it looks good. It will send a dominant here in the acknowledgement slot. And whoever transmitted the message listens to this acknowledgement slot to make sure that at least one node acknowledges and receives the message. Otherwise you'll get an acknowledgement error. If nobody acts the message, you'll get an acknowledgement error and we'll talk about CAN's error handling when we dive into CAN a little bit more deeply. Then you have the act delimiter. You have a seven-bit end of frame and at least three more recessive bits after the end of frame as an inner frame spacing. Then once all this is done, the bus will stay idle until another node decides it wants to transmit on the bus. So I mentioned the arbitration ID before. And the arbitration ID is how the CAN bus determines who's allowed to talk on the bus. So as I mentioned before, one of the core fundamental things that CAN believes about how the world works is that if any node on the bus is sending a dominant, then the bus state will be a dominant. So if you have node A and node B that start transmitting, they both send a start bit at the same time. So they're not going to know at that point that somebody else is transmitting because they're sending a dominant bit. They're seeing a dominant bit on the bus. So they assume that it's their dominant bit that's making the bus in the dominant state. And they'll continue while it sends the arbitration ID until one of the nodes sends a one when the other node is sending a zero. As soon as a node sees that, hey, I'm sending a one, but because somebody else is a certain dominant state on the bus, that node has the higher priority and will get access to the bus. So node B will drop out here and node A will continue with this arbitration ID. And what you'll actually see on the CAN bus if you're not node A or node B is the arbitration ID sent by node A. So that's how CAN ensures that people aren't stopping on each other on the bus, how it does its bus arbitration. So now to dive a little bit more deeply into how CAN bus does its error handling and et cetera. So CAN bus is designed to be resilient to transient errors. Like I mentioned, electromechanical noise, just stuff that happens because digital signaling is a lie we pretend to tell ourselves about how analog signaling works. CAN has five different error detection mechanisms. It can detect bit errors, stuff errors like CRC errors, form errors and acknowledgement errors. Bit errors are only detected by a transmitter. So if a transmitter has one arbitration, so it knows it has access to the bus, and it is sending a specific bit on the bus, but the state that it reads back from the bus is the opposite state. So sending a recessive, dominant or vice versa, that'll be a bit error. And that will cause the transmitter to send an error frame and go into CAN's error handling. This won't be detected by the transmitter, of course, because anybody receiving won't know what the state of the bus is supposed to be. Then you have stuff errors. Another feature that CAN bus uses to increase its resiliency is something called bit stuffing. And how bit stuffing works is that with a couple exceptions for a couple of the fields, if you send more than, if you're going to send more than five bits in a row that are the same, either dominant or recessive, after you send the fifth bit, you're supposed to send one bit of the opposite, one opposite bit, so recessive if you're saying dominance and vice versa. This indicates basically prevents the bus from going into a DC state where the receiver is going, am I actually still receiving something or did the other know just die and it's done now. So it does bits to make sure that it also helps keep clocks synchronized, clocks drift a little bit on different nodes. It does reclock on each edge that it receives. And so that also helps to make sure that your clocks don't drift too far apart from each other so you're still able to properly receive a message. So any time that a node sees that the bus has been in the same state for longer than five bits, that is a stuff error and it will then also go into CAN's error handling functionality. CRC errors, CRC doesn't check out and that will also cause an error to happen. Form error is what happens if some of the fixed form fuel, so these three bits, the CRC delimiter, the act delimiter or the act slot, if that isn't right, like if you end up seeing a zero in the act delimiter, that would be a form error because that's not how it's supposed to be. And the last error, like mentioned before is the acknowledgement error. If you send a message but nobody acts your message on the bus, then that will give you an acknowledgement error to occur. There are three other CAN frames besides the normal data frame. There's something called a remote frame and how a remote frame works is it's basically a node on the CAN bus saying, hey, whoever sends this arbitration ID, which is the arbitration ID that it tries to send on the bus, go ahead and send the data that you have. I've never actually seen a remote frame used in automotive, but it's a feature of the bus. There's also error frames and I'll get into more error frames and overload frames and how they work starting on the next slide. So there's two types of error frames and we'll get into how CAN gets into three error states in a couple of slides. But there's an active error and if a bus is in the active error state, that means it basically hasn't seen very many errors and it will, whenever it detects an error on the bus, will send out six dominant bits. But of course, six dominant bits, that violates bit stuffing because it has more than five bits in a row that are the same. So all the other nodes on the bus will also start sending out error frames because of the bit stuffing error. So you'll end up with between six and 12 dominant bits on the bus depending on exactly when, you know, what bits you were sending before the error frame and how long it takes for the other nodes on the bus to notice that there was a stuff error essentially. When you're in the passive error state, then you'll send six recessive bits on the bus and we'll talk about how that's used as part of CAN's error recovery as well. And then after you send out your error frame, the six to 12 dominant bits or the six recessive bits, you send out eight more recessive bits essentially to leave the bus in the idle state for a period of eight bits. Overload frames, I had some fun with overload frames on this. So the intention behind an overload frame is that if you have a slower microcontroller on the bus that needs a little bit more time to process a message, it can send an overload frame in order to just kind of delay processing of CAN messages for a short period of time. It's six dominant bits followed by eight recessive bits. It's during the intermission, which is the three recessive bits after the end of frame, that first three bit interframe spacing that you saw on the previous slide. That is where the overload frame is sent if a node is sending the overload frame. According to the spec, it says at most two overload frames may be generated. It doesn't say anything about what to do if you generate more than two overload frames. This is how CAN does its error recovery. It uses error counters to do fault confinement. There's two error counters, a transmit error counter, which is the error counter that your CAN peripheral will use if it's transmitting something and gets an error, and the receive error counter, which is the error counter that it will use if it was receiving something and saw an error. So there's three error states. There's error active, and error active is the default state. It's what you're in when your error counter is less than 128. So you haven't seen any errors, or you haven't seen very many errors, and that is the state where you'll send the active error frames if you do see an error. Once your error counter has gone over 128, then you'll move into the error passive state, and the error passive state is where you send the passive error frame. The idea here is that if you're a node on the CAN bus and you're seeing a lot of errors, it's possible that actually you're the problem, not somebody else. So in order to, so you'll stop stomping on the CAN bus every time you see an error and send that active error frame, and you'll go into error passive state where you'll check to see if, basically if you get, if you get recessive bits on the bus to tell you whether or not something else is happening on the bus. Once your error counter has gone to over 256, then you go into the bus off state, and in bus off state you're supposed to completely stop participating in the CAN bus entirely until you either reset or get 128 occurrences of 11 consecutive recessive bits. So you can recover that way if the bus stays quiet for a while, but CAN buses often don't, you know a vehicle, CAN buses are often very, very chatty. And the way that the error counters get incremented, there's a bunch of edge cases in the spec, and I'm not going to go over all of them, but in general, on a receive error you'll increment the counter by one for every time you get a receive error, and you also will decrement by one every time you successfully receive a message, that's how you can move from error passive back to error active if it seems to start working properly, then you'll go back into the error active state. On a transmit error though, you increase your error counter by eight for every time you receive a transmit error in order to kick a transmitter off the bus, because a transmitter that's behaving poorly is going to be more problematic than a receiver that's behaving poorly. And that's how CAN does its error handling and error recovering. One of my, another of my favorite parts of the CAN specification is this quote here, it is in the nature of the MAC sublayer that there is no freedom for modifications. Well, what if I want to modify some of these things? CAN is essentially based on the premise that every note on the bus, everything that's connected to the CAN bus will behave the way that it's supposed to behave all the time. Sometimes you really don't want your tools to behave nicely. Sometimes you want them to do things they're not supposed to do. Wouldn't it just be so nice if somebody would make something like that? So existing research tools, like we have a tool we've opened source called the CANCAT, Eric Avanshek who's here somewhere has written tools, the CANTACT, a bunch of tools that are all written using a standard CAN peripheral. It's something that's baked into silicon on a microcontroller that will behave the way it's supposed to behave. Well, as far as, as far as like the error recovery, error detection, stopping transmitting when it's supposed to stop transmitting, all that stuff. But we've had conversations with several people in the industry that there's been a need for a tool that doesn't have those restrictions on what it can do on the CAN bus. The final kick in the pants from me about a year ago, ICS Alert 17-209-01 was published. This ICS Alert talked about essentially how you can do this sort of thing on the CAN bus. Now, I remember one of my coworkers told me that when he was in college, one of his classmates pointed out this was a problem on CAN bus. So this isn't exactly news to anybody who understands CAN bus, but now we have an actual ICS Alert begin point two and say, hey, CAN bus has some issues when it comes to security. I'm also tired of hearing that that can't happen. I got it more in aerospace, but that the mindset that people can have that people aren't going to actively do malicious things in order to bypass the assumptions you've made about the system is a mindset that really has been bothering me for a while. So a tool called CANT. CANT is purpose built to selectively target an individual ECU by abusing the CAN specification. It's based on an ST Micro Nucleo H743Zi dev board. It's like a 20, 21 dollar dev board that you can actually get now. I gave this talk the first time at Shmucon and they were back ordered on Mouser until April. So that was a little bit of a buzzkill. I just barely managed to get the two that I had before they were sold out. Currently supports five attacks. Denial of service attack where it just targets all messages, essentially sends an arbitration ID of zero every time a node starts to transmit so nobody else can actually talk on the bus because they will always lose arbitration. Replace data of selected messages. I can choose an arbitration ID and say, hey, instead of sending this data instead and just ignore the other guy yelling at you for sending the data that you shouldn't be sending. Transmitting multiple overload frames. Something that's interesting about the overload frames is that they're generally not reported up to your software. The CAN peripheral just, oh, it's an overload frame. I'm going to ignore that. But they don't actually check to see if they get more than two overload frames. So you can transmit overload frames. That doesn't even get reported up to the software that you're using. I also created a cyber paper clip mode and a knack attack that I'll talk about a little bit more in the demo videos that I have. So the advantages of CANT over a lot of the tools that we have right now is that we have complete control over signaling, including being able to force reassess a bit with the CANT shield that I made. We can follow the CANT spec as it suits us. Sniff messages as you would with a normal CANT peripheral. And then as soon as you want to start abusing the CANT spec, we can do that. If an ECU is giving you trouble, I've used CANT for this before. I'll just use CANT to knock a specific ECU offline so that it can stop interfering with what I'm trying to do. And it's more difficult to detect than packet injection. That's something they talked about in that the paper that led to the ICS alert is using this sort of technique to evade car IDS and IPS type systems. Because you're, as far as something resetting on the bus receiving is concerned, the bus is actually behaving properly. There's only the node that's transmitting knows that something is really going on often. I've got a demonstration that walks through the, walks through what we can do with with CANT. For this demo, I'm using three to demonstrate some of the CAN attacks that we can do with two of the open source. Is that picking up at all? No? All right. It has developed. One of these tools is CANCAT. CANCAT is a tool that GRIM has been developing for a few years now. It is, and Arduino Dewey is one of your common car hacking tool. We use it for doing CAN bus and packet injection, CAN bus sniffing. The one disadvantage that CANCAT has though is it is built on top of a standard CAN peripheral. So it's limited in how badly we can misbehave with that for demonstrating a little bit later. The other tool is the CANCAT tool that GRIM recently released. CANC is a Nucleo H743Zi development board with a CAN transceiver wired to it. And we use that to essentially bit bang CAN over GPIO. This gives us complete control over the CAN messaging at the electrical level and allows us much greater control over what is going out on the CAN bus. We're going to start the demo by showing how to use CANC to act as a bus killer. What this attack does is any time, any note on the bus tries to send a message, CANC will take over and send a message, a valid CAN message with an arbitration ID of zero. This limits, this effect of this, limits any other note from transmitting on the CAN bus. So we'll go ahead and set up that attack. We'll go ahead and set up the BOD reach, the bus killer attack, and we see that the very quickly the brake fluid light pops up, the instrument cluster starts shutting down. Currently nothing is able to transmit on this bus. We're going to come over here to the oscilloscope and see that we're shutting out. For this demo I'm using 3PO, our portable part hacking demo, to demonstrate some of the CAN attacks that we can do with two of the open source tools that GRIM has developed. One of these tools is CANCAT. CANCAT is a tool that GRIM has been developing for a few years now. It is an Arduino delay with a CAN shield. It is more of your common car hacking tool. We use it for doing CAN bus pack injection, CAN bus sniffing. One disadvantage that CANCAT has though is it is built on top of a standard CAN peripheral. So it's limited in how badly we can this behave with that for demonstrating a little bit later. The other tool is the CANCAT tool that GRIM recently released. CANCAT is a Nucleo H743Zi development board with a CAN transceiver wired to it, and we use that to essentially over GPIO. This gives us complete control over the CAN messaging at the electrical level, and allows us much greater control over what is going out on the CAN bus. We're going to start the demo to use CANCAT to act as a bus killer. What this attack does is any time, any node on the bus tries to send a message, CANCAT will take over and send a message, a valid CAN message with an arbitration ID of zero. This limits any other node from transmitting on the CAN bus. So we'll go ahead and set up that attack, set the BOD reach, the bus killer attack, and we see that the very quickly, the brake fluid light pops up, the electrical cluster starts shutting down on this bus. We come over here to the oscilloscope, always sending this message whenever any other bus tries to send its own message, effectively killing the CAN bus. That much different than you'd get from jamming a paper clip into the CAN bus, and shorting the two wires. The advantage of CANCAT approach is that it does that same, it has that same effect without both of the CAN bus. This is a perfectly valid, properly functioning CAN bus, just nobody else is allowed to transmit on it. Stop this attack from happening, the CAN bus goes back to normal on the oscilloscope. Next step is we're going to illustrate those differences I was talking about between how CANCAT works and how CANCAT works. So CANCAT is a tool we've been developing for a while, like I mentioned, it runs on the Arduino duet with a CAN shield on it using a standard CAN peripheral. So it allows us to do things like just send a CAN packet. What this CAN packet that I'm about to send does is it causes the brake fluid low light to come on, and we'll see that happen up in the instrument cluster. I'll send it, brake fluid low pops up, but only for a fraction of a second, and this is because the body control module is sending out the brake fluid status message about three times a second, and of course the brake fluid level is actually okay. So this message that we're injecting is being overridden by the body control module almost immediately once we send it. If we try to flood the bus with this message, just put this in a wild loop and keep pounding on it, we see that the brake fluid light will pop up and go away and pop up. This gives us very herky-jerky control over whatever it is we are trying to control. This is a problem that you run into quite frequently with CAN. You're trying to inject a message to do something malicious, but your message is getting overridden by a different ECU on the system. CANT has a very nice data replacement tool. We'll set the VOD rate to 125 for a bit per second. Place your attack. It's eight bytes long. If we go back we'll see the message is 8800106 000000 and as soon as we start doing this we see that our brake fluid level low light comes on in the instrument cluster and stays on. The reason for this is because this attack, since we're replacing the rules of the CAN bus from the perspective of the body control module, the body control module should be the one sending the message, the only one on the bus but we're taking the bus away from the body control module. So the body control module is going into an error state. We take a look at this one here. We'll see right here we see that the body control module is hitting out these longer pulses. These are error frames. The error frame that we were discussing earlier. We'll see there's quite a few of them. If you come along there should be 16 of them. Because the body control module is going into its bus off state resetting, sending an active error frame until it accumulates 128 send errors again. And once it's accumulated 128 send errors, it goes into the error passive and then eventually into bus off. So CANT allows us to then just override any message on the bus eventually knocking that ECU off line to allow us to have complete control over whatever message it is we are trying to control. Last attack I want to demonstrate is an attack of the overload inserter attack. So the overload frame dumped out of me when I was reading the CAN specification. The CAN spec says that no device on the bus should send more than two overload frames. It doesn't say what should happen if somebody does send more than two overload frames. The only purpose of the overload frame is to allow slower nodes on the CAN bus to request a little bit of extra processing time after they receive a message. So they say now the overload frame this gives them just a little bit more time to process a message that they've received. Let's go ahead and set the body rate again and choose the overload inserter. Let's just send two overload frames. Just behave in a nice appropriate manner. And we see that things seem to be functioning quite well. If we don't re-hear it into the scope we can go ahead and we see we have one, two overload frames everything looks nice and kosher. Let's send more. Let's send five overload frames see what happens. If we go back over to the scope we see we have one, two, three, four, five overload frames and we also see that everything seems to be running properly. So apparently sending more than two overload frames doesn't immediately cause any issues. Let's try sending more. Let's try sending a stream of these overload frames. We'll send quite a few. Now we see that this has taken some effect. The brake fluid level low light comes on for some reason and that it's not a camera glitch that instrument cluster really is kind of dimming. You can still see it's still kind of running but it's definitely something weird is going on. And if we come over here to the scope we see as we expect there is something in a whole bunch of overload frames. We also see that the amount of time we're spending sending overload frames that's the more than we're sending sending actual messages. So we're actually seeing a significant increase in bus load here. Let's try sending a hundred of these things. A thousand. So a thousand of these things. And if this in the thousand causes the instrument cluster to completely shut off at this point. And if we come back here to the scope at the point that we see we're spending very little time actually sending messages and we're almost spending the entire bus time is spent in these overload frames. This is a demonstration of what can't allow you to do. Can't allow you to do things that you can't do and see what the effects of that is. So after since that demo I've added a couple new features which are also interesting and I have a demo for those as well maybe. You know I recorded these videos I didn't have to go through all the problems you get with a live demo. One thing that can't couldn't do at the time and I figure if I'm going to release a tool called can't I should probably make sure there's nothing that can't can't do. The thing that can't couldn't do at the time was can't couldn't assert a recessive state on the bus. This is how can handles all of its arbitration all of its error handling and error recovery is by assuming that a node cannot assert a recessive state on the bus that if any node on the bus is asserting a dominant state then the state of the bus will be in the dominant state. So in order to accomplish this I created this piece of hardware. It's a shield that plugs into the Nucleo STM 32H7ZI dev board that we've been using and it is a standard can't transceiver. It has a can't transceiver connector or passives on it the thing that I added that makes it special is this little device here at U2. It's an analog switch and what this analog switch allows me to do is it allows me to short can't high and can't low together and when can't high and can't low are shorted together it allows it will cause any node on the bus to read a recessive state because it will be in the same potential. So this allows me to violate that last enviable for the can't bus is by asserting a recessive state on the bus and this allows me to create two new attacks plus adding a enhancement to a third attack. So the first attack I'm going to demonstrate is the cyber paperclip mode. This just turns on the bus it does the same thing that plugging a paperclip into the can't bus would do. It just causes the bus to short together and nobody can communicate. We'll go ahead and start that attack, the bus short attack and we see that this purple line here on the scope is the state of the switch so we see that this went high turned the switch on and that now we don't really have any traffic on the can't bus. At some point we should be able to see some sort of message starting to come up we can see that the instrument cluster is dead. We see it's kind of trying to get a message here and there but it's not able to actually send anything because the bus is shorted together. We'll go ahead and reset our can't reset the car because recovering from this is difficult. I'll have to get the instrument cluster running again. The second attack I want to demonstrate is a knack attack. So what the knack attack does is it tries to essentially harbor the acknowledgement bit that the nodes on the bus are supposed to send back once they properly receive a message. So we'll go ahead and set our bot rate the knack attack. This should, as we see here this is where the knack slot should be here on the scope. We see that our switch goes high for one can't fray or one can't bit and it does all this because all this is crazy stuff to happen on the bus and it tries to happen. So as we can see our cluster is still running. It seems like it's still getting enough back that the car isn't too unhappy but we're able to generate a bunch of noise on the knack frame. The last attack I want to show is an improvement to the data replacer attack. Previously the data replacer attack would only work if we were wanting to send a dominant bit where a recessive bit was being sent. The brake fluid test that I showed and the previous video showed that the brake fluid level low is a dominant state so I was able to assert that dominant state on the bus and had the brake fluid level low show up on the bus. But what if we want to go the other way? So in this case I've actually used our control box to cause the body control module to actually be sending the brake fluid level low which is, it does by setting that bit to zero to the dominant state and now I want to overwrite that with the recessive state for that bit to cause the brake fluid level low light to turn off. I was unable to do that with the previous version of CANT but now I can do that. So we go ahead and set the arbitration ID choose the bottom right again data replacer attack bikes first bike will be 98 0000106 0000000 then I added this line here the force recessive bit now force recessive is not currently the default I'm going to go ahead and say yes to force recessive bit and we'll see here that the brake fluid low light goes away now we will see occasionally that the brake fluid low light will flash back on for just a second and it will flash back off I haven't been able to figure out why that is happening if we go and look at the actual state of the bus using the CANCAT tool that I have hooked up we can see that it's all of the brake fluid message lights are being set to what I said it to it's going to be sending 98s all the way across there's some other behavior and the instrument cluster is causing that message to pop back up occasionally but the attack works the values that we're targeting are now coming across the bus with the correct value and one thing I forgot to mention in the video is that another advantage of being able to force the recessive bit is that I can also clobber the error frame that the body control module or whatever ECU is sending the message is sending so that the only node on the bus that has any idea anything is wrong is the one that I'm specifically targeting like nobody else is an error frame nobody else does anything to his error counters it would continue to operate as if nothing was wrong and have no idea anything else was going on so there are some limitations and mitigations to this one limitation is that you need physical access to the car in order to do this maybe it's also possible to theoretically possible to find a way to get into the car remotely or wireless or cell modem or something program in ECU to be a can't essentially because there's nothing minus the analog switch to force the recessive which I'm guessing most OEMs don't actually stick on the can bus for you to play with minus that feature everything else you can do it's just a bog standard can peripheral that is shipped with every car every ECU that has a can bus so increase for the attacks of just increased can bus load those could be detected by something that's looking at can bus you wouldn't necessarily be able to tell why with the overload attack because like I mentioned those overload frames aren't actually brought up to software so you'd see your bus load increasing and that stuff couldn't make its timings that it's supposed to make but it would be difficult to determine why without hooking a scope or similar up to the car power fingerprinting is something that some companies are working on were they able to fingerprint the nodes on the can bus to see if there's anything out of the ordinary can't is definitely out of the ordinary I haven't actually used one of these to see what can't looks like but I'm sure it sticks out like a sore thumb because I am bit banning can or GPIO that's going to look a bit different of course and the question is then what so yay we're something's happening what do you do now with that car to make it work properly increased network segmentation can help limit the how this attack some sort of encryption or authentication could help mitigate some of this possibly although can makes a lot of this difficult because of how small its data size is and how low power a lot of the ECUs are and of course you can always switch away from can bus minus the self is mandated by law that will give you some more options as I'm further reading the can spec is available right up there and this is the paper that led to that ICS report ICS alert going out I've made a couple other improvements to can't backspace works now as of a week ago so that's really handy couple other usability improvements and I am pushing those up to get hub right now so that will all be available shortly up on get hub I also have about 20 of those can't shields available I don't have the dev boards just the shields but those dev boards they're about 20 bucks get them from Mauser arrow whoever you generally order from and anybody who wants one feel free to come up and get one and they won't have any questions I switch to this because I wanted to make sure that I would have enough this dev board is an Arm Cortex M7 at 400 MHz it's a pretty beefy board I wanted to make sure that I would have time to actually launch the attacks I wanted to be able to launch and have the flexibility to do more complex attacks without then not being able to make timings on the can bus alright thank you all very much like I said if you have any more questions for me feel free to come up I have a handful of those shields that I'm handing out