[00:01.100 --> 00:05.080]  Hey, hello world. It's your boy Brent, back with another talk on hacking cars.
[00:05.500 --> 00:07.720]  Last time we talked about how we automate the hack.
[00:07.720 --> 00:11.520]  This time we're going to talk about how to stop the hack automatically.
[00:11.760 --> 00:18.660]  So without further ado, this does not reflect any opinions of the government, the military,
[00:18.660 --> 00:21.860]  and any photos or cited papers that are shown in the talk.
[00:21.860 --> 00:24.700]  Those, of course, belong to their original copyright holder.
[00:25.180 --> 00:27.020]  And so let's talk about the threat.
[00:27.020 --> 00:32.800]  All right, so if we spoof the acceleration brakes and the parking assist to control the steering,
[00:32.800 --> 00:39.200]  we can get into a pretty dramatic situation where, let's say, a cyber criminal starts a three-way call with a mother.
[00:39.600 --> 00:44.100]  Their teenager is in the car. They say, Mom, the car won't slow down.
[00:44.340 --> 00:47.740]  And all of a sudden there's a new strange voice, maybe a computer-automated voice,
[00:47.740 --> 00:54.100]  that says you have three minutes to send me $10,000 using the link in the text message I just sent you.
[00:54.100 --> 00:58.140]  If you don't comply, I will crash this car at 110 miles per hour.
[00:58.460 --> 01:03.920]  The attacker disconnects, leaving the scared mother on the line with their teenager,
[01:03.920 --> 01:07.420]  who's about to possibly die from this exploit.
[01:07.760 --> 01:10.220]  This is not necessarily a fictional scenario.
[01:10.780 --> 01:14.640]  Surely you've probably heard of Chris Miller and Balasek's hack of the Jeep.
[01:14.800 --> 01:16.700]  So this is already something that's happened.
[01:16.700 --> 01:20.400]  And as cars get more and more automated, more and more connected to the Internet,
[01:20.400 --> 01:22.600]  this is a threat that will continue to happen.
[01:22.600 --> 01:25.060]  So how do we stop it? Let's use offense.
[01:25.060 --> 01:31.000]  Offense is the best defense. We can specifically do bit smashing to stop the attacker in their tracks.
[01:31.020 --> 01:35.900]  What it turns out is actually if you look at it, these control protocols that are in cars,
[01:35.900 --> 01:40.480]  while they may seem super insecure, with a very small and inexpensive change,
[01:40.480 --> 01:42.580]  we can achieve almost perfect security.
[01:42.580 --> 01:46.140]  I'll get into that. I understand it's a very bold claim to make,
[01:46.140 --> 01:51.560]  but it's pretty surprising how elegant and well this defense method would work.
[01:51.560 --> 01:55.800]  So it will stop your denial of service, which is typically thought to be unstoppable.
[01:55.800 --> 01:59.160]  In these control network situations, it will stop spoofing.
[01:59.440 --> 02:03.280]  And this will work for a lot of the control networks that are multicast,
[02:03.280 --> 02:08.900]  which means one sender sends a message and nearly all or all of the other devices on the network
[02:08.900 --> 02:10.500]  will receive that message.
[02:10.680 --> 02:14.820]  And the ones that it's not intended for will simply ignore it while it's on the wire.
[02:15.200 --> 02:20.540]  One other nice benefit of this, particularly for cars, is you no longer need an intrusion detection.
[02:20.540 --> 02:24.620]  It works out that the way that this defense is implemented,
[02:24.620 --> 02:30.940]  you achieve effectively perfect intrusion detection without any sort of complicated machine learning or AI.
[02:30.940 --> 02:32.400]  It just works.
[02:32.640 --> 02:35.060]  All right, so what is bit smashing, first of all?
[02:35.060 --> 02:42.020]  Let's say agency on the network wants to send a payload of hex A, and they're the fraud.
[02:42.020 --> 02:46.240]  They're the attacker trying to send some malicious data on the network.
[02:46.240 --> 02:53.500]  Now they're sharing a physical wire with all of the other nodes in the vehicle or in the multicast control network.
[02:53.700 --> 02:57.060]  So B is our valiant hero who wants to stop this attack.
[02:57.080 --> 02:59.260]  So B wants to stop C in their tracks.
[02:59.260 --> 03:03.740]  What B will do is while the voltage is still going up and down on the wire,
[03:03.740 --> 03:06.520]  as C tries to transmit their message,
[03:06.520 --> 03:10.980]  B in real time can stop that transmission while it's in progress
[03:11.480 --> 03:15.340]  by putting extra voltage on the wire that C is not expecting.
[03:15.340 --> 03:20.160]  And what this will do is essentially smash the logic that C is trying to send,
[03:20.160 --> 03:22.660]  and B will take over the communication on the bus.
[03:22.700 --> 03:26.280]  C will stop talking, and then the attack is stopped.
[03:26.360 --> 03:30.520]  So as you can see here on the left, C is sending 01010,
[03:30.520 --> 03:35.980]  and by B sending that extra logical one, that extra amount of voltage at a certain time segment,
[03:35.980 --> 03:38.580]  they effectively stop C in their tracks.
[03:38.820 --> 03:40.060]  So that's bit smashing.
[03:40.420 --> 03:42.420]  Now, I'm not the chef here, okay?
[03:42.420 --> 03:47.760]  Last time we talked, the previous talk called Reverse Engineering, 17 Cars in Under 10 Minutes.
[03:48.220 --> 03:50.680]  In that, I was a chef and your waiter.
[03:50.720 --> 03:52.360]  In here, I'm not the chef.
[03:52.460 --> 03:56.100]  This, I did not come up with the solution, and it's actually pretty well documented.
[03:56.260 --> 03:59.900]  In particular, this article you see in the green on the top right,
[03:59.900 --> 04:05.660]  that 2017 academic proof of concept, which was in the IEEE Vehicle Magazine.
[04:05.800 --> 04:09.440]  I encourage you to grab a copy if you get a chance. Check it out.
[04:09.440 --> 04:14.880]  It's a very clear explanation of how the process works beyond what I'm talking about here.
[04:14.880 --> 04:19.320]  And then also, they show you the hardware they used to actually implement this proof of concept.
[04:19.320 --> 04:26.220]  That way, you can try this out yourself and tinker around without having to burn any sort of custom hardware.
[04:28.340 --> 04:33.240]  One part of this security that is not perfect is we're not getting confidentiality.
[04:33.240 --> 04:34.900]  Okay, this is still a control network.
[04:34.900 --> 04:39.480]  We're still basically talking in an open room where each person is a member of that room.
[04:39.480 --> 04:42.900]  And when they project their voice, no matter how loud you want to talk,
[04:42.900 --> 04:45.660]  you're not going to stop the fact that that other person is talking.
[04:45.660 --> 04:47.260]  Everyone else will still hear them.
[04:47.920 --> 04:52.580]  So you're not going to get confidentiality in an open room talking to other folks.
[04:52.580 --> 04:55.680]  But what we do get is integrity and availability.
[04:56.120 --> 05:00.640]  So integrity, am I sure who sent this message? Is the person I think it is?
[05:00.640 --> 05:03.320]  And then, is this the message that they originally intended to send me?
[05:03.320 --> 05:06.660]  Has it been modified? There's no man-in-the-middle business going on.
[05:06.880 --> 05:09.600]  And then for availability, that's your denial of service.
[05:09.600 --> 05:14.660]  Can I talk in the network when I want to talk on it? And is it behaving how it's designed?
[05:16.040 --> 05:20.360]  All right, so to give a little bit more context, we are not talking about general use networks.
[05:20.360 --> 05:26.040]  And here, I mean like the internet, Wi-Fi, anything where you can add or remove endpoints
[05:26.040 --> 05:31.940]  and adjust the structure and the number of participants in the network dynamically.
[05:31.940 --> 05:35.360]  And you don't need to make any adjustments. It just naturally works out.
[05:35.440 --> 05:37.440]  That's not what we're talking about here.
[05:38.860 --> 05:43.000]  We actually gain a lot of benefit by not having this because here in the general use network,
[05:43.000 --> 05:47.380]  there's no way of necessarily knowing how many participants are on the network.
[05:47.380 --> 05:54.200]  So when you see new data go on the network, it's unclear whether they are a legitimate user and member of the network or not.
[05:54.200 --> 06:00.160]  Additionally, there's tons of metadata for keeping track of which messages are where, who owns what,
[06:00.160 --> 06:07.260]  and spoofing that metadata is just one more attack vector to make it even more confusing to know the origin of a message.
[06:07.680 --> 06:09.400]  Here, we're talking about control networks.
[06:09.400 --> 06:13.800]  Okay, so medical electronics, vehicles, obviously in this case, CarHack Village,
[06:13.800 --> 06:17.600]  but planes, trains, automobiles, factory floors, you name it.
[06:17.600 --> 06:21.300]  So control networks, you're not trying to add or remove hosts very often.
[06:21.300 --> 06:26.860]  You pretty much know the machines and components that you want to communicate, and that's a fairly fixed number.
[06:27.000 --> 06:31.060]  Maybe you might add one or two every couple years, and you can document that.
[06:31.060 --> 06:32.720]  It's a very deliberate process.
[06:32.960 --> 06:34.660]  And you also lose metadata.
[06:34.920 --> 06:39.460]  And so in this case, it actually goes for a benefit here because now there's even less information.
[06:39.720 --> 06:41.260]  The attacker has a spoof.
[06:41.260 --> 06:47.080]  They basically have to talk in the wide open, and there's not a lot of extra information that they can lie about.
[06:47.080 --> 06:50.500]  They simply say, I'm this person, and send their information.
[06:50.960 --> 06:56.600]  And if there's already someone that says, hey, that's my name, so who are you?
[06:56.600 --> 07:00.620]  It becomes very clear and evident that that person is not who they say they are.
[07:00.620 --> 07:02.920]  That node is not legitimate.
[07:03.920 --> 07:05.880]  So what does this look like in practice?
[07:05.880 --> 07:10.000]  If A wants to send some information, they send it over the bus.
[07:10.100 --> 07:12.900]  Again, this is multicast, so everyone gets a copy.
[07:12.900 --> 07:16.720]  And if you look at this wiring harness from a vehicle, it might look something like this,
[07:16.720 --> 07:21.520]  where it originates at one point of that wire, and then it gets sent out to multiple other endpoints.
[07:22.080 --> 07:27.020]  Now, granted, in vehicles, there's a lot of things like gateways, which effectively create collision domains,
[07:27.020 --> 07:33.120]  or if this term is more familiar to you, subnets, even though it's not strictly subnetting.
[07:33.480 --> 07:37.820]  So sometimes these gateways, you don't necessarily see the entire bus on the vehicle.
[07:37.860 --> 07:39.660]  We'll get to that, but that's not a problem.
[07:39.660 --> 07:42.460]  As a matter of fact, it actually goes for a benefit even more.
[07:43.180 --> 07:45.040]  So what is the problem?
[07:45.240 --> 07:51.620]  So because I have this multicast nature, and let's say I've got my instrument cluster talking to some other piece of information,
[07:51.620 --> 07:53.800]  I may also have a telemedics unit.
[07:53.840 --> 08:01.280]  I may have an entertainment system that has a SIM card in it, where I pay for Wi-Fi connection to my vehicle.
[08:01.280 --> 08:06.220]  That way, I have in-vehicle Wi-Fi. I can update my maps, whatever reason you want to be connected.
[08:06.220 --> 08:11.960]  Or for example, the Tesla business model, which is instead of having to recall vehicles,
[08:11.960 --> 08:15.580]  and it's a very expensive and time-consuming process, I can do a lot of things,
[08:15.580 --> 08:22.720]  over-the-air software updates to change the behavior of the car, in which case a data connection is mandatory to do that.
[08:23.280 --> 08:26.780]  So again, we've got some sort of internet connectivity to the vehicle.
[08:26.960 --> 08:34.060]  Now these systems, which were designed to be pretty insecure, there's no cryptology, there's nothing, really no authentication,
[08:34.060 --> 08:38.500]  but it used to be air-gapped, so it was okay, now it's no longer air-gapped.
[08:38.500 --> 08:41.000]  Now we've got attackers that can reach these networks.
[08:41.060 --> 08:43.540]  So let's assume the attacker has done so.
[08:43.560 --> 08:48.400]  One way or another, they've gotten onto our control network, and they can modify our brakes,
[08:48.400 --> 08:51.480]  they can turn off our accelerator, they can turn off whatever,
[08:51.480 --> 08:56.260]  possibly even take control if we have that power steering module, and we're in a lot of trouble.
[08:56.260 --> 08:58.160]  So we want to stop that from happening.
[08:58.160 --> 09:02.240]  One thing the attacker can choose to do with a pretty dangerous attack,
[09:02.240 --> 09:09.920]  simply pick a high-priority message identifier that no one else is using, and just spam that as quickly as they possibly can.
[09:09.920 --> 09:17.060]  Essentially, you turn off all communications, and now you've got no steering, no acceleration, no brakes, you're just dead in the water.
[09:17.340 --> 09:24.780]  So if you look at the Wired article, for when Miller and Balasek did the GPAC, they probably did something similar to this.
[09:24.780 --> 09:28.960]  The other situation is a little bit more nuanced.
[09:29.100 --> 09:36.120]  You've got a specific packet you want to send to a specific location to fool that part of the network,
[09:36.120 --> 09:38.760]  and you simply just say, I'm this person.
[09:39.060 --> 09:45.440]  And right now, the way it goes, even if B can see this happening, Module B here, there's really nothing they can do about it.
[09:45.440 --> 09:52.640]  They just have to grin and bear it that someone else is using their ID that they know should not be used by anyone else,
[09:52.640 --> 09:54.320]  and the attack simply happens.
[09:54.320 --> 09:59.800]  B can try to send messages all they want, but now you just get into basically dossing the network all over again
[10:00.320 --> 10:04.940]  when you get into a fight of the legitimate B versus the attacker acting like their B.
[10:05.120 --> 10:08.520]  So we want to stop denial of service, and we want to stop spoofing.
[10:08.980 --> 10:13.240]  So here's the solution. We're going to bit smash those communications.
[10:13.420 --> 10:20.640]  So again, bit smashing is adding that extra voltage on the wire, physical layer, in order to stop that communication or take it over.
[10:22.060 --> 10:25.880]  We're going to focus on cars here, obviously, because it's CarHack Village.
[10:26.060 --> 10:31.300]  But again, this is a fairly generic process, but here we've got the machine and its logic.
[10:31.300 --> 10:33.940]  So in this case, the actual physical brake caliper.
[10:34.000 --> 10:41.820]  There's going to be some internal wiring and control there to actually squeeze onto the disc brake and slow the car down.
[10:41.820 --> 10:43.880]  That's part of the machine logic.
[10:44.660 --> 10:48.860]  The vast majority of the cost of that component is that machine and the logic.
[10:49.420 --> 10:51.940]  Touching that is what's called a CAN controller.
[10:51.940 --> 11:01.660]  That's a piece of little chip and or software within the bigger logical board that actually implements the controller area network protocol.
[11:01.700 --> 11:07.800]  So what order do I send things, how do I interpret messages, how do I synchronize with the network clock, etc.
[11:08.080 --> 11:11.940]  And then separate and distinct from that, once more, is the CAN transceiver.
[11:11.940 --> 11:20.280]  And that's the piece that actually implements the layer one electrical engineering to talk on the wire.
[11:20.280 --> 11:24.940]  So how do I actually make a waveform and create voltage on the wire to communicate.
[11:25.220 --> 11:31.360]  So in either case, I can leave alone all the design that I'm doing for my main machine,
[11:31.360 --> 11:38.360]  and I could just modify that commercial off-the-shelf product, that CAN controller, or the CAN transceiver, or both.
[11:38.360 --> 11:43.800]  If I modify one of those to implement bit smashing, then the manufacturer really doesn't have to care.
[11:43.800 --> 11:47.740]  They can just buy that product off the shelf, attach it to their existing product.
[11:47.740 --> 11:51.600]  There's really nothing else that they have to do, and you get the security.
[11:51.720 --> 12:00.480]  So it's extremely low cost. These CAN controllers and transceivers, we're talking less than a dollar most of the time, if not pennies, to do this.
[12:00.480 --> 12:12.160]  And if we assume that that costs quadruples, to add the bit smashing capability, we're talking about $0.20 versus $0.80 to get a completely secure solution.
[12:12.660 --> 12:22.180]  One way of thinking of this, if you have any background in security, is this is doing intrusion detection and prevention using a decentralized access control list.
[12:22.180 --> 12:28.080]  So if every endpoint knows what their name is, and they'll bit smash anyone else that tries to use that name,
[12:28.080 --> 12:35.240]  essentially you get an access control list, that way stopping any sort of traffic does not pass that check.
[12:36.060 --> 12:42.160]  Alright, so here I am, B, our hero, once more, good boy, and he's watching the bus.
[12:42.160 --> 12:49.360]  And I'm watching the attacker send some information, and the way I know he's an attacker is I'm watching him send bits on the bus over time,
[12:49.360 --> 12:58.100]  and I'm processing this in real time, I see that, hey, you just used my ID, that's not okay, I'm the only one that gets to use that ID on this bus.
[12:58.260 --> 13:04.840]  So now I've got a long time, relatively speaking, to react and actually bit smash.
[13:04.840 --> 13:19.540]  There's about up to 80 or so, possibly even more, clock cycles, or bus cycles, should I say, of the clock going, clock increments, to have an opportunity to bit smash.
[13:19.540 --> 13:28.760]  So even if it takes a little bit of processing to actually decide, okay, yep, they used my ID, I'm going to use this clock cycle to figure out, yep, I definitely want to bit smash.
[13:28.760 --> 13:41.100]  And then in here, either the CRC or the data, I can just start holding the voltage high, I will bit smash that transmission, all of the members of the network will throw out that message,
[13:41.100 --> 13:46.720]  and they will even store it in memory, they won't even transmit it up to that higher component that they're supporting.
[13:46.720 --> 13:54.220]  It will stop at that CAN controller. So one time I just want to emphasize, if we're trying to, say, spoof or attack that brake,
[13:54.220 --> 14:07.920]  the brake won't even realize an attack is happening, because it will stop at that controller chip, or logic, and it won't even make it to the part of the control unit that's actually working the brake.
[14:07.920 --> 14:09.620]  It won't even realize it's happening.
[14:11.280 --> 14:19.220]  Alright, so the way that would look, the telematics unit, if we say that's the source of the attack, tries to send a message, before it even makes it to A,
[14:19.680 --> 14:27.800]  control module B, our hero, says, two B's? No way, not two B's, there can only be one, okay, I'm the only B.
[14:28.780 --> 14:41.960]  We get this out of benefit, okay, with CAN in particular, anytime that an error occurs while you're trying to transmit, by the way controllers are supposed to be implemented to meet the CAN standard,
[14:41.960 --> 14:48.480]  if a fault happens while I'm trying to talk, I essentially get a hit against an internal counter that I have.
[14:48.480 --> 14:57.820]  We'll call that a fail state counter, saying something went wrong, possibly me, maybe I'm defective, and I'm going to keep track, or I'm going to try again.
[14:58.020 --> 15:07.320]  Well, as B continues to bit smash me when I use its ID, eventually I'm going to exceed that threshold, and I'm going to go into what's called a fail silent state,
[15:07.320 --> 15:12.940]  which essentially means that I will continue to listen to the network, but I will not send messages.
[15:12.940 --> 15:21.880]  And so if you're the attacker, and you're trying to communicate with this car through the internet, and you've got some traffic, and you're seeing the traffic go,
[15:21.880 --> 15:29.340]  even better is not only do I stop that attacker from physically being able to transmit on the bus, but the attacker may not even realize that they're stopped,
[15:29.340 --> 15:37.000]  because they're still seeing the traffic come in, and they cannot necessarily get acknowledgments that their transmission was successful or not,
[15:37.000 --> 15:42.260]  depending on the logic between the machine and the controller that it's attached to.
[15:42.500 --> 15:49.960]  So the controller may or may not actually communicate that it's gone into a fail safe state, because it's failed, it's just not doing anything.
[15:50.360 --> 15:57.980]  So not only do we stop the attacks, whether that's denial of service or spoofing, but we've essentially done a DOS attack against the attacker's node,
[15:57.980 --> 16:00.600]  and turned them off for some period of time.
[16:01.380 --> 16:08.420]  A couple assumptions to actually make this happen. So each endpoint needs to have a unique ID on this multicast network.
[16:08.420 --> 16:13.180]  So if you have multiple possible people using the same ID, then that's a problem.
[16:13.220 --> 16:18.720]  Because now it's unclear, if I see that ID on the network, should I bit smash it or not?
[16:18.720 --> 16:21.940]  So every endpoint needs to have a unique ID.
[16:22.860 --> 16:28.760]  Gateways, okay, so if I have everything in my engine compartment, for example, going into a single gateway,
[16:28.760 --> 16:34.760]  and then that gateway talks to other parts of the vehicle, like brakes or something like that, or your tachometer,
[16:36.380 --> 16:45.320]  that essentially creates two different parts of the CAN bus, and nodes on either section may or may not be able to see traffic from each other.
[16:45.380 --> 16:47.740]  So now you've got back into the same situation.
[16:47.740 --> 16:54.520]  Well, if this node over on this section of the network is supposed to bit smash these IDs being generated on another section,
[16:54.520 --> 17:04.760]  but the gateway isn't forwarding that, it's not being a transparent, basically a bus, instead of a switch, then how do I stop that?
[17:04.760 --> 17:06.980]  Well, you just reverse the logic.
[17:06.980 --> 17:14.600]  So if endpoint logic is, I'm going to allow all traffic except my ID, if I see my ID, I'm going to bit smash it,
[17:14.600 --> 17:16.740]  you flip-flop that logic for gateways.
[17:16.740 --> 17:22.220]  I'm only going to allow this set of IDs, and I'm going to bit smash anything that doesn't make sense.
[17:22.220 --> 17:30.520]  And that access control list, if you want to call it that, can be specific for each section of the network that it's physically connected to.
[17:30.940 --> 17:36.120]  What that allows you to do is, going back to the denial-of-service attack example,
[17:36.120 --> 17:43.940]  with CAN, I could just pick the highest priority arbitration ID possible, according to the protocol,
[17:43.940 --> 17:49.200]  and more than likely there's not going to be a device on the network that's using that arbID,
[17:49.200 --> 17:53.620]  so if the gateways weren't implementing this, then they would just be able to DOS the network.
[17:53.780 --> 17:57.600]  But by having these gateways, looking to say, I know what arbID should exist,
[17:57.600 --> 18:01.820]  and you're using something that's outside of that list, I'm going to bit smash you,
[18:01.820 --> 18:05.660]  and then again we go into, alright, now we've turned off the attacker's CAN controller,
[18:05.660 --> 18:10.380]  they can no longer talk, it's not a problem, and the message is never finished anyways,
[18:10.380 --> 18:15.700]  so the overhead imposed on the bus is really not that bad.
[18:16.360 --> 18:23.780]  And then finally, one talk, if you watch a lot of the talks that Miller and Balasek gave a couple years ago,
[18:23.780 --> 18:34.420]  is a lot of these ECUs, the nodes on a vehicle, will accept reprogramming commands while driving at freeway speeds.
[18:34.420 --> 18:39.580]  There's really no logic to check, should I be allowing a reprogram to happen or not?
[18:39.580 --> 18:41.320]  They just simply accept it.
[18:41.320 --> 18:48.580]  So one small tweak that would need to happen, either in the CAN controller or possibly that more expensive component piece,
[18:48.580 --> 18:55.240]  is to add just a little bit of extra on that state machine to say, hey, I'm getting the signal,
[18:55.240 --> 19:00.840]  or I'm seeing that we're not in park, so I'm not going to allow a reprogram to happen,
[19:00.840 --> 19:03.500]  you need to put the vehicle in park before that happens.
[19:04.180 --> 19:11.860]  And then finally, we've got to make sure that the controllers are just not rewritable chips.
[19:11.860 --> 19:16.660]  So that imposes some recall issues if one of these transceivers starts bugging out.
[19:16.660 --> 19:18.640]  You will need to go back to the shop.
[19:18.640 --> 19:24.640]  But this basically makes it impossible, just like we wouldn't want to reprogram the logic for the larger component,
[19:24.640 --> 19:29.020]  if we have these very powerful bit-smashing controllers or transceivers,
[19:29.020 --> 19:35.220]  we do not want to open up the opportunity for those to get reprogrammed and then used to just hold the bus high,
[19:35.220 --> 19:37.620]  and then there's really nothing anyone can do about it.
[19:37.620 --> 19:42.800]  You're just putting voltage on the wire, and there's no workaround for that.
[19:42.800 --> 19:48.700]  So we don't want it to be rewritable, but we do want them to continue to comply with that fail silent state.
[19:48.740 --> 19:52.960]  All CAN controllers should comply with that, if they're compliant with the CAN protocol.
[19:52.960 --> 19:59.540]  And then again, other multicast protocols typically have similar fail states.
[19:59.980 --> 20:06.940]  But I'm not going to speak that I know for sure for every possible multicast ICS protocol.
[20:08.400 --> 20:13.420]  Thanks so much. Just again, references, if you want to look into this deeper,
[20:13.420 --> 20:18.800]  please check out the IEEE Vehicle Technology Magazine from 2017.
[20:18.800 --> 20:21.460]  Go ahead and grab a copy off of IEEE Explorer.
[20:21.460 --> 20:28.120]  And these guys did a pretty good job of really breaking it down and showing photos of how they created a working version of this
[20:28.120 --> 20:33.080]  without any sort of special hardware or production manufacturing capability.
[20:37.360 --> 20:40.360]  All right, with that, I'll open it up to questions. Thank you.