 Hello, DEATHCON. I am Pen Truder. I'm Gensback. We are here today to present a framework built into the mainline Linux kernel for hacking connected vehicles. It's free, open source, free to all. It uses standard commercial off-the-shelf Wi-Fi hardware. And let's get started. So I'll state of the world, today, automation is becoming widespread in the commercial industry and it's starting to become available in commercial platforms, including in automotive systems. So particular network architectures today, such as Canvas, are not designed for highly complex systems, not designed to handle the throughput, latency, and security requirements. However, these architectures are still being used as the basis for developing future automotive systems. And this is bad, right? As we develop the next generation of automotive safety standards, it is important that we build security in from the bottom up and not use something that is heavily flawed such that we deploy, irreversibly deploy platforms that are vulnerable and weak, especially in the context of safety, critical infrastructure, like automotive systems that pretty much everyone in the civilized world use. Got you. Okay. So I think we're actually one slide ahead. Yeah, buddy. Up. Okay. So we can classify these autonomous systems that we'll see in the future. And so we have a classification of zero to five, where right now we can say we're at stage two automation for vehicles where we can say that non-safety critical functions are automated using the exchange of state information on the internal networks. And the transition up to stage three requires intervehicle communication and synchronization so that these safety critical functions can be automated with the presence of an operator. Yeah. And so some of the barriers to this are, so primary issues are who owns the infrastructure and who's responsible for problems that are resulting from the deployment of these systems, right? You know, who makes, you know, who can make these decisions about public safety, you know, in the context of automotive systems and who's responsible when the systems fail and there's injury and potentially even death. And a good example of this is that the machine learning systems we have that do vision aren't actually robust to a lot of the adversarial attacks that can be constructed. So you see this, this picture's an example of that. So in the top layer we have images that are fed into a machine learning classifying system to try and determine what the image is representing according to the classifier. And you can see in the bottom image we've introduced, or not we, but previous researchers have introduced noise to these images such that the human eye cannot tell the difference but the actual vision system on the car gets tricked. And you can imagine for things like a stop sign, a yield sign, you know, that are present here, that can lead to some very dangerous effects. Indeed. So this leads us to this concept of V to X. What is stage three autonomy? Essentially it can be described as such. Using a vehicular ad hoc network, a VA net, to enable rapid, high throughput exchange of state information between network participants that as such provides enhanced safety and network-wide optimization that isn't possible using the sensor systems on board any isolated system. So this is done by layering a protocol stack, the V to X protocol stack on top of the vehicle control pass to which reactionary instructions are sent to control the vehicle based on proximal network activity in the VA net. And this concept V to X serves as the technological bridge between stage two and stage four automation going from traditional automotive systems to self-driving cars to the future. So the deployment of robust, successful V to V will shed light on the technological but more so legal, ethical and moral challenges that are presented by the use of high-stage automation in public systems, in consumer systems. So the critical aspects, the critical aspects of this technology, using this VA net, promote greater operational awareness in a highly trafficked environment by the exchange of state information between vehicles and infrastructure points with the idea that this can be homogenously applied to transportation systems worldwide. It's designed to be integratable into the existing transportation network, leveraging infrastructure that already exists. And in fact some V to X systems are being experimentally deployed. However, they're being developed very much in isolation, not coordinated between standards bodies in different countries. Ergo, we are, the standards as they exist are very much fragmented and disorganized. So we'll come back to this though. First let's do a little more with the impact of the technology. So I guess one of the most important questions to ask is why the hell should we care about this? So transportation is obviously a ubiquitous thing that we all engage in. Everyone has to get somewhere in society. Not only just people but freight, industrial processes. So the increased levels of automation here and the increased connectivity of these systems, unprecedentedly expands the threat landscape present in terms of the automotive cybersecurity. And more generally in terms of the security of critical infrastructure as all of these systems are in some way connected to critical infrastructure in the transportation network. So I guess more specifically then, what does this mean for consumers? Okay, cool. Let's see. Okay, so the deployment of these strong, you ubiquitous adopted V2V systems have a number of benefits. These are all estimated from the U.S. Department of Transportation based on three pilot studies they ran in Tampa Bay, New York City, and I believe Wyoming. And you see a significant reduction in fatalities, crashes, property damage and significant improvements in traffic throughput and general roadside optimization. So by integrating these systems in with the actual cars, you can reduce the stress of the driver, remove certain safety hazards and just generally improve it for the consumer. But let's expand this perspective. What's the impact on the global industry? So this allows us to scale VDAC technologies across industrial platforms to optimize economic operations, right? Like freight and agriculture. It provides the same kind of enhancement to safety of the operator of the machines. It allows for the synchronization and coordination of logistical operations, right? Think air traffic control for trucks. So it sheds the stress or enables greater transparency to the root cause of inefficiencies and failures. These are what's attractive right from industrial perspective. Let's keep going, right? What's the impact on critical infrastructure systems? So the VA net outside the context of intravehicle communications serves as a potential carrier for data in the absence of something like LTE. So it's a, it provides access to a network that you can easily propagate messages across from one single entry point across the national and potentially global transportation network. And it, therefore you can like distribute information about emergency events. You can distribute, you can use it for distributing software updates right to vehicles to infrastructure systems or potentially for the people in this room. You can use it to do a whole lot of interesting word driving and data collection and fuzzing of critical infrastructure systems that simply wasn't possible before. The barrier to a lot of automotive security is wireless access. I mean we have seen it's trivially easy to physically modify a CAN bus, but can you get in wirelessly? Well now you eliminate having to break a 4G modem. Now we have a Wi-Fi like protocol that has become standardized in every consumer vehicle that doesn't use strong authentication or encryption or association that you can rapidly propagate information across arbitrarily and compromise from one single entry point. That is pretty cool, right? Now, so we, you know, what's the impact for automotive security in general? I mean Duncan run over some of the messages, but I guess generally the exposure of this wireless attack surface means that you can very rapidly propagate messages from one point to another. Say you are at the bottom of some highway system and you send a message off to one car, that carries it to another car, they carry it to another and so on and so on and now all of a sudden you're in New York. So that's, you know, a huge impact and beyond that you can actually do sort of packet sniffing. You can place either on the roadside little sniffers or have your car, you know, actively war driving and actually listening to this traffic and reconstruct behavioral profiles of the cars as they move across the road and this allows you to reverse engineer some of their behaviors. You can send probe responses, try to figure out what firmware they're running potentially and use that knowledge of their firmware and their system architecture to actually exploit. Right. So that means that you can hack cars easier than has ever been possible before, but it also means that your cars are going to get hacked a lot easier. So here's some examples of some of the features that are intended to be implemented through these coordinated system. So we have collision avoidance, so say you have a blind spot, a car in front of you, you know, off to a blind spot is going to send a message to you saying hey I'm here and now you know they're there. So you don't hit them. Advanced driver assistance, cooperative adaptive cruise control which is where you have messages cascading back throughout traffic to try and synchronize how the cars actually accelerate and decelerate to optimize the gaps between them and make traffic smoother. And of course you have things like automated ticketing, automated tolling and other application level products that we'll go into in a bit later. So this gives our primary motivation for developing this free and open source and easily accessible Vita X stack so that we can and you can communicate using just a Linux box with some cheap hardware and mess around with these systems. And participate in the national and potentially global VA net. So let's talk vision. Vision of Saka Vita V, our platform, right, is history tells us that security through obscurity leads to inevitable poning. We have allowed security standards for safety critical systems to be developed behind closed doors and in the general case those that have developed these standards have widely failed us. This is the counterpoint of our vision here in releasing this. We are providing a means for security researchers and global researchers alike to participate in the development of the Vita X standards because they affect us, they affect our daily lives and our families, our wives and our children if we could ever find one. And the deployment of another set of weak standards will inevitably lead to the compromise of systems that are integral to the continuing functioning of our society. It's not just the transportation network but what will the transportation network, the connected transportation network touch. It will touch financial systems, it will touch energy and like all of the infrastructure sectors alike as we move into higher levels of automation. That's why perhaps it's particularly interesting to all of us here from hacking car using Wi-Fi we can potentially gain access to a global transportation infrastructure and to the energy systems that control it. So this is neat for us but at the same time there's a clear need to make these standards not suck as badly as they have before. So we, let's see, probably the selling point here is that previously to do this required a 2 to 5 to $10,000 DSRC radio. We are enabling you to do it with a $20 commercial off the shelf Wi-Fi card that can run 5 gigahertz and will tell you the couple of simple modifications you need to make to your standard Linux kernel and pretty much after you take a stack and compile it in your kernel and make a few little changes to IW you can immediately start participating in the VA net which pretty much doesn't really exist yet and that's why we're giving it to you. So a little background, begin development, circa 2015. There had been a good amount of work done and published previously in the space which we quickly found was non-existent, non-functional. Pretty much every project that had been started had been orphaned or those that the state that they were developing an open source made them close source and are there no longer compliant as they're being deployed. So we basically spent 2 years of digging deep into the solace chasm that is Linux kernel driver development and at last have managed to surface here again and now I would say the V2V is more real than it has ever been before. So we already touched on some of these motivations but just to reiterate a little bit, increase in automation leads to increase in attack service. Industry is calling for proprietary close source implementations of V2V. Well, let's think about this for a moment. The standards are incomplete and bound for change. In fact, the security layer of the VDAC standards is non-existent as it stands today. So OEMs, big corporate is going close source and developing these standards in isolation while the standards are bound or developing these systems in isolation while the standards are bound for change. This will inevitably lead to the deployment of obsolete systems and hinder the development of V2V any further. And it's already happening today. So this is one of the lessons we learned from previous epic failure, right? Close source leads to weakness and also kernel dev is hard. You keep using those words kernel dev. I don't think they mean what you think they mean. This is an example of we pulled this from a patch that was submitted to the main line Linux kernel by a developer thinking that he was enabling 8 or 211P, which is the physical layer of the VDAC stack. Well, if you look right here, I commented something out at WTF. If it's this frame, return false. If it's this return false, this return false, otherwise return false, right? So pretty much the accepted solution is completely dysfunctional. Like no frame would ever actually be accepted and patched to the wireless interface. That took about a year to find in the millions of lines of code. This is one of many, many, many critical mistakes while things are very, very partially implemented and widely accepted as functional. It simply isn't true and it took two years to claw my eyes out to get here to tell you that. So let's see. Now we're going to do a stack overview. Real quick. Okay. So we'll start at the physical layer of the stack. That is 8 or 211P. This operates on a 5.8 to 5.9 gigahertz OFDM, 5 to 10 megahertz subcarrier width. And right above that we got IEEE 16094, which is the multi-channel operation modes. It determines how you switch between the service channel and control channel. You know, service channel has services and control channel has privileged controls that propagate through the network. And then going above that even further we have 16093, which handles the message encoding for the short messages that are used as the primitives in communication. And we also have things that deal with the RF parameters, the routing advertisements, the service advertisements, and so on. And at the application layer there's J2735, which contains basic safety messages, emergency vehicle alerts and roadside alerts, along with many others. And those are packed inside of the short messages that end up getting down and dispatched finally along the physical layer of 802.11p. So to quickly go over each of those in a little bit more depth, 802.11p comprises the physical and mac layer of the V-to-X stack. So the curl components are 510 megahertz width subcarriers using OFDM over 5.8 to 5.9 gigahertz frequency band reserved for use by intelligent transportation systems. Using multicast addressing with no association, no authentication, no encryption. This is specified to exist at a higher layer, such as in the 1609 and J2735. And to define this networking mode called OCB mode out of context to BSS that pretty much allows you, it's like ad hoc mesh networking just with the beginning association, authentication, encryption all disabled. So next is Wave DSSR. Looks like you got a little preview there of our entire presentation. All right, here we are. So Wave slash DSSR. So Wave is the basis of the Wave short message protocol. Wave stands for wireless access in vehicular environments specified in IEEE 1609. So it's an encoding scheme and it's also a management plane for V2V. So that includes multi-channel operation, service identifier allocations, you know, all of the stuff you might expect in this kind of ad hoc networking that allows the communication of the kind of fields you would expect in vehicles, you know, location, telemetry, trajectory, these kinds of things. Okay. And J27, oh sorry, this is a Wave, this is an example of a Wave short message. So you can see that this is a fairly bare bones, you know, quite literally a hello world example. So you have the version, the sub type, information element block which is similar to that found in other 802.11 stuff. And then at the bottom here we have, you know, the transport identifier which determines how the message is actually forwarded along the network, whether it hops or it floods out and then we have the data field which contains hello world. This brings us to the application layer, SAEJ 2735 provides a grammar and dictionary set of safety messages for use in interoperating V2V systems. So probably the most common example is the basic safety message, a message that will be continuously transmitted at a periodic interval between every member of the VA net to exchange state information about, say, the dimensionality of the car, heading, acceleration. So you can use this to, you know, depredictive optimization of the traffic flow. There's collision avoidance which is exchanged when there's the collision imminent to try and reduce or mitigate the harm to the driver and the, and the stand, those standing nearby. There's emergency vehicle alerts which the emergency vehicles will use to, you know, modify traffic flow in the event that like an ambulance needs to get through or a cop wants to pull you over. So, or say in like the case of a natural disaster. Really what this allows you to do is define, you know, autonomously define reactionary behavior that will happen independent of the driver in order to create a safer VA net by, you know, by orders of magnitude as have been cited in studies for last 15 years. So this is a great idea, right? This is, this sounds awesome and people have been talking about it since 2004 and people have been making slides and presentations and nobody's really been doing anything and the standards are continually getting changed in there and we're going to talk a little bit now actually about the, the state of the standards. The, there have been multiple major revisions made to, to wave and to J2735 and they are not backwards compatible. They have, they lack a complete trust management framework. They, the current, the current standards that are deployed are proprietary and close source and incomplete. So this is a clear attempt at monopolization of the connected vehicle industry but it's the inevitable outcome is the development of, is the deployment of, of incomplete obsolete and vulnerable platforms. Some, let's go a little more in depth about these changes, right? Okay. So some of the major changes that we've seen is that the, the certificate management system has actually been totally overhauled. They, they added support for some implicit certificates and also a peer-to-peer certificate distribution system. There have been proposals for a trust management system that use misbehavior reporting. So like, you know, if you listen to a car next to you and they do something you don't like, you report them and then if enough people report them, they'll eventually get their certificate revoked. I mean that's the idea. Obviously that is quite a number of ways to actually manipulate that potentially. And, you know, the, the J2735 standard has been completely overhauled several times, such that, you know, the old encodings don't even work, like at all. And we, you know, with respect to the new encodings. So the question is, you know, how are these completely incompatible, not backwards compatible systems and systems where the security is just totally in flux supposed to actually work properly without exposing huge vulnerabilities? And the answer is, they're not supposed to work. I mean. So we, we like to call this possibly unintentional application of the standards, right? Because we're, we're gonna allow the possibility that this could be someone on it, that this could possibly be a mistake, right? We, in, in revision to the J2735, measures verification codes, CRC is our move from emergency vehicle alerts, from roadside advertisements. And some of the, there's almost no specification given for a lot of design choices. I mean, here's, here's something pulled out of, out of the 1609 spec. This guy here affects the receipt. Nothing. So we, we see there's ambiguity, right? What does ambiguity mean in terms of communication systems? It means that there is yet another attack surface in, in the way that the messages are received. So, like, what gives, right? What freaking gives? Just to go over some of the subtleties that are in the protocol, you know, to drive home the point a little bit, there are typing congruities and they're actually typed, there's type redundancy in these messages. So you actually have lower layer of protocols that will specify, or lower layer of segments of the protocols that will specify certain things like location and GPS data. And they'll also be redundantly specified in the higher level, higher layer protocols. And if these two things are incompatible, you know, the values are different, then you can actually have issues where you can confuse the software and, you know, cause the car to go swerve off somewhere. The actual encoding of the 1609 messages, it's a little poor. I mean, so there are, there are points in some of the routing advertisements where there's actually a bite that, depending on who you interpret in the committee, should be there or maybe shouldn't be there. So that can lead to very obvious parsing issues that can just cause memory to crash and do whatever. And the channel switching mechanisms on single antenna systems are actually such that you can, you can jam the actual, effectively jam the communications for however long you want just by broadcasting off sync with the rest of the network. And that can just shut down communication and disrupt peer to peer certificate distribution and no one can talk in some closed area for a very long time. So what does the, are we on attack surfaces yet? No, no attack surfaces. So let's move on to the juicy interesting stuff here, right? What are the attack surfaces for V to X? Well, the entire V to A network is accessible from one single endpoint due to the, the ad-hoc mesh nature of it, such that you can propagate a message from one single point of entry, massively distribute malware, of course it was meant for safety information. You compromise one radio in one vehicle and that could be a compromise due to a proprietary implementation weakness. Then you can therefore potentially compromise all vehicles in the nearby proximity, which will propagate to the global network. You can hijack emergency vehicle authority and execute services like platooning that are built into the V to X standards in order to disable vehicles, you know, for law enforcement or, or whatever reason, you know, somebody might want to make your vehicle stop in the middle of the road on a, in the middle of a highway. So what does the adversary look like? A passive adversary can do, you know, sniffing and mapping of the, of the network, both in terms of, you know, mapping services that are available built into the 1609 standards and those that are left reserved for the manufacturers to implement. So what this means is diagnostic functions built into DSRC that allow you to execute routines on, you know, on, on each vehicle. And there's a lot of services that are defined and there's a lot of, that are left very ambiguous in the 1609 standards. What else? Let's see. We can gain a lot of visibility into the global transportation network that is going to be rather unique to the individual, right? So think, if you can understand where, you know, the nature of economic operations in terms of the transportation network, you know, where supply and distribution networks are operating, you know, poorly and efficiently, then you can perform arbitrage and, and gain, you know, economic advantage and, and use it for, you know, for, for evil shit, right? But more interesting, what does the active adversary look like? I mean, he, he might look like that. You can, he might perform denial of service and man in the middle of attacks between vehicles and infrastructure points so you can manipulate the misbehavior reporting schemes, for example. You can disrupt vehicle traffic and target individuals, not just individuals, you can target, you know, classes of systems. So not only perform, you know, target individual, you can target a company or a corporate entity or a, some kind of other governing body that, that uses these kinds of systems that is going to use a highly proprietary or, or highly specific, you, custom tailored implementation of it. And, and I mean, who, who wants to deal with that guy right there? He looks like a dick. So now if we consider the threat model that we introduced earlier from a theoretical level and then apply what the information we gave you about the state of the standards, et cetera, how does the threat model change? So the, the threat model that we have in light of this information, so we can corrupt traffic over the air, wirelessly on, you know, on the road. You can use the diagnostic information in the DSSC radios to manipulate and control vehicles, ex sultrate data, do whatever the hell you want. You can use the RF signatures of the actual radios on these things to break the pseudonym, the pseudonymity schemes that they use to try and protect the identity of drivers. So what they do is, you randomize your MAC address and your certificates time out and you generate new certificates. But the problem with this is that if you have great enough visibility over the network, you can trivially track this and identify anyone as they move across the road, regardless of this, you know, kind of like slapped on attempted anonymity. So obviously V2V has quite a number of problems and, you know, our solution, right, is to, is to just put it on Linux. Yeah, man, just, just use Linux, dude. Just use Linux. So, right, we, we have this free and open source platform that is, I mean, it's, so we have little asterisks here. It's platform independent. It's, it's extensible in a generic Linux environment. So it's, we, we took the V2X stack and implemented it in the Linux kernel networking subsystems. The asterisk there is because hardware that manufactured, manufacturers specify a regulatory domain in the hardware that they produce. So you have to go into the driver and make slight modifications to participate in the intelligent transportation bands. But past that, the modifications to each driver are pretty slight. Right now, we have published support for Anthros 9K. We're extending it to RTL Wi-Fi and, you know, ideally soon enough to, to all standard network and driver architectures. So, just use Linux. It's, it's always, it's never been that easy, right? How we do this? First, we'll start with 802.11p. So we'll go up, up the stack. You just define the ad definitions for the intelligent transportation channels in the Wi-Fi drivers. So this one we stick into Anthros 9K. The same one goes into RTL, et cetera. Next, you modify the kernel and you just space regulatory domains. So this is what we're saying. The FCC and the, the manufacturers like to specify a specific regulatory domain that you're allowed to use in each country. So you can pretty easily modify this by going and doing a little bit of kernel hacking and forcing the kernel to accept a regulatory domain that you specify. So what we do here is we add the intelligent transportation bands, make it OCB only because there's no channel sharing, et cetera. And we do the same thing here in the Anthros driver on the bottom. And then we add support for filtering of 802.11p frames. So this is just a function that we pulled, we stuck in there and these are the sorts of frames you accept. Management data and QoS frames. And then you just make to, to finish the integration of 802.11p. We modify standard Linux user space utilities such as IW, the wireless rig DB, which we went over a second ago in CRDA. So in IW, what we do is add, you specify command that allows you to join an OCB channel, specify the frequency and the megahertz, whether you're going to use 5 or 10 megahertz with subcarriers. We add definitions for the 5 and 10 megahertz with subcarriers in the IW regulatory domain and then using the command specified above, you can see we successfully join an OCB 5 gigahertz network. We publish the code to do this in the GitHub repo, we'll give you at the end. So moving up to... Okay, moving up, sorry, moving up to Wave or 1609. So we have to specify, or rather we had to specify all the relevant data structures, you know, the short message, the service advertisements, the routing advertisements and so on. And all, you know, full modification or full ability to modify any of the fields in there to create custom packets that you just inject off to the wireless interface and send over the air. As well as managing the channels, channel synchronization and channel hopping and just the Mac level extensions of the actual management plane inside, you know, inside the operations. Click. Click. Okay. So the usage of the WSMP, so you have the ability to take the structs that are defined and encode them, conversely decode them as they come over the air because they'll come up through a socket interface and you just take the byte stream and decode it and use the user specified WSMP packet using libpcap to just, or whatever you want, to just inject it into the wireless interface and it's there. It's on the air. So this is the WSM struct, the wave short message. This is the top level structure of the actual message encoding. This specifies the transport identifier which is how the message will actually be routed across the network where they're going to hop, you know, however many times you want and also the data fields and all of the ancillary data gets packed into here. So this is the, this is the information element extension which includes the RF parameters, the routing information and all of this other fun stuff. And other, you know, ancillary structures that include, you know, routing advertisement, service advertisements, channel info and service info, right? So then how do we apply this? We take some of the, we define J2735 critical messages somewhat based on the SAE provided, broken ASN one spec that we fixed and made a heck of a lot more pretty. And then you see we just filled up with parameters that are compliant within the limitations of each field. Then what we can do, generate a WSM message as he just showed. And these fields are from the sample given, you know, a couple, 20 slides up. We serialize it using a encoding function that we wrote. Well, first we pack the basic safety messages that we made right here and you pack it right into the data field of the WSM, serialize it and dispatch it to the wireless interface using PCAP inject. And the result is successfully transmitted WSM messages. So Wireshark has a plug-in for WSM P that's outdated, doesn't support the current encoding types, but at least sort of recognize what we did here. Figured, given the nature of the week, we would avoid doing a wireless demo with 5G tech. But what we can see here is that we successfully transmit and inject a WSM message using Linux, open-source stack and an atheros 9K $20 Wi-Fi chip. And now you can do this too, right? So the exact same thing is possible for the other types of safety messages using the exact same methodology. So we show an emergency vehicle alert, roadside advertisement, you pack it into the WSM struct and you can serialize and transmit it just as easy and actually start interfacing with infrastructure and connected vehicle systems that exist today in isolation. So yeah, what are you going to do with this? You want to be a master? You want to hone some connected vehicles? Well, we're going to sort of go here in increasing level of when. Right, so level one you can imagine would be a denial of service. So fuck with the channel synchronization and just kind of disrupt the network, prevent people from broadcasting. It's very possible for single antenna systems and I'm sure there are more clever ways to do it by breaking the parsers. Um, stage two, sorry, level two would be to enumerate essentially map out all of the proprietary services offered at the application layer to get an understanding of the attack service of each car and actually exploit that. Oh, oh. Okay, level, sorry, level three would be sort of masquerading as a toll booth, right? So, um, electronic toll collection is actually a future, or future aspect of this technology. So if you're able to hijack that certificate, you can essentially prop up a mobile toll station and go around collecting fare from everyone, you know, as you pass by. Then of course you bump up a little bit and you can start dealing with emergency vehicles, you know, go, uh, pretend you're a squad car and, uh, force someone to pull over. I'm an ambulance, yep. And if you really want to be elite, maybe you can figure out how to execute the platooning service. That's built into J2735 that lets you, uh, take full control, uh, or rather assume direct control of any vehicle participate in the VA net, right? But, um, I think we have a few more types of pounding here, right? Um, what do we got? What do we got? We can not read at all. So you can, you can put it a bunch more clever ways, um, but really it, this isn't just about pounding vehicles, um, completely. This is about providing an interface that allows you to participate in the development of secure good standards by hacking them. So we're using all these evil superpowers to deploy systems that will be homogenous in transportation systems worldwide. Um, we don't want another CAN bus. We, we don't want, um, to, to get stuck with a fully deployed, completely vulnerable arbitrarily hackable, uh, network protocol, all right? So we give this to you so that we together can make something that doesn't suck, you know, in layman's terms, right? Um, as always, hack the planet, see what you can break, use it to make the world better and please come in, uh, please reach out to us with any thoughts, ideas, questions. We are releasing this. It's posted already on Github. Um, you can find us in the car hacking village. We're giving a talk immediately after this at 3 o'clock and we'll be in the car hacking village afterwards at 4. Um, so thank you, DEF CON.