 Welcome to day four of SHA 2017. Are you enjoying yourselves? Tonight we have car hacking, getting from A to B with Eve. So I saw a Tesla standing outside the parking lot, and I thought to myself, like if he says to Wally, directives, enjoy your talk. Thank you. Well, thanks for being here. About our talk about car hacking and our adventures in car security. So I must first start with a notice that we currently are still in the disclosure process, unfortunately, which means that we cannot give a full detail on what we found, so no full technical detail, nor are we able to tell which manufacturer this all appeals to. And yeah, so no fancy Ida screenshot or whatever. So that's unfortunate, but that's the way it is. So my name is Dan Koeper. I'm a security researcher at Compitest. Today with me I have Thais Alkamada, also a security researcher at Compitest. And we both spent a lot of our time on R&D projects, so not directly affiliated to work for customers. What we do for customers is we test, we verify their software quality, and we do that on a security base, performance base, and functional testing, where we of course are focused on the whole security department. So at Compitest we have a specific lab, which we call the Chaos Lab, and the Chaos Lab is our resource lab where we get to spend time researching projects that we deem interesting, and they will often have, well, will be beneficial for either society or the community. So you might know us from some of our previous work. The most famous thing we did was last year we found a vulnerability in a let's encrypt clone, which allowed you to get free SSL certificate for domains names like Google.com and GitHub.com. And we published vulnerability about Ansible, how you could own the farm if you compromised a single host in the network. That being said, one of our colleagues said, why don't you hack a car? And we're like, okay, let's just give it a go and see how that car, how it goes. The reason we try this is that cars are less about hardware than they used to be. They're currently more focusing about onto software. And also more and more cars come with Internet connectivity nowadays. And we all know that the Internet of Things is a fantastic thing that makes the world a better place. So we thought, let's give it a try. So I looked up some quick statistics, and apparently in 2015, 35% of all cars have some sort of Internet connectivity. That can either be direct or via a mobile phone. The problem with the current eco structure is that these cars will still be on the road in 2030, most likely. And most cars will have a lifespan of 15 years or longer, meaning that vulnerabilities in the current cars will be there for the next 15 years, which makes this whole thing a little bit frightening. And experts estimate that in 2020, almost all cars will come with Internet connectivity in some way. So with that in mind, we set some research goals for ourselves. We wanted to find a remote attack. So an attack that required no user interaction at all. So no ODB ports or a user has to visit a website on their infotainment system because they use an outdated WebKit, et cetera. The goal was fully remote, no user interaction. And from there, try to work away up to the canvas, especially, of course, the high-speed canvas that controls things like steering and braking. Oh, yeah. Also, a very important thing was to keep away from any legal fights because we're only a relatively small company if you compare us to all the car manufacturers, so we didn't want any legal issues. So keep it legal. We are a consultancy firm, which means that almost everybody in our company has a lease car, which means we had about 85 cars to choose from. And phase one was to select which cars have the largest remote attack service. So I sent on the email to all employees, okay, so who here has a car that also has a mobile app? Because if they have a mobile app, then it will also have Internet connectivity in some way. I got about 12 responses saying, yes, I have such a car, and they all said, but the app is shitty. I never use it. So I would like to do a small test here. Who here has a car that also has a mobile app? Who is actually happy with that app and uses it on a regular basis? Wow, that's one. Okay. So they want to connect the thing to the Internet, but the user interface sucks, so actually nobody uses it, but okay. So we have 85 cars, and people can choose their own lease car in our company, so that will mean that we also have a very different variety of cars. So all the cars we tested were different brands, different models, etc. So if we look at the attack service that a car has, the typical attack service, the most cool way is, of course, if you have a cellular attack. There's some attack that works remotely via this cellular interface that your car probably has. Some cars also have a Wi-Fi hotspot that you have to enable. Slightly less cool because then you have to be in the, you have to be nearby. TPMS, the tire pressure monitor system that's used for your car to monitor your tire pressure, because apparently it's very difficult to connect a cable to something that spins with 130 miles an hour, 20 kilometers an hour, sorry. So that's also something that works wirelessly, so an attacker could potentially drive next to you and try to hack your car via TPMS. Obviously you have Bluetooth, and then you have some factors that require physical access. So for example, the user has to insert a USB stick or has to connect something to the ODB port, which is your debug port basically for your car. So we started by looking how each car connected through the internet, and it seemed that there are different ways car manufacturers connect their cars to the internet. Some cars use some sort of embedded SIM cards, which means it's basically just embedded in the hardware, which makes it difficult to test remotely because you have no influence on the ISP the car is using. So you cannot man the middle of the connection because the ISP is probably netting everything, you cannot get on the same network, you cannot do a port scan, etc. So the embedded SIM is pretty difficult to do remote research on. Then you have cars where the user has to insert their own SIM or where you can replace the SIM of the manufacturer. That makes it slightly easier because then you can insert your own SIM, which gives out a public IPv4 address. You have cars that have no internet accent by itself, but use Bluetooth deethering. So if you ever hook up Bluetooth pairing with your car because you want to use the car kit, for example, it will also use the internet connection to get, for example, maps data, etc. We actually also saw a few cars that do have an app but don't feature internet connectivity. What they do is they have a local Wi-Fi hotspot, and if you want to use the mobile app, you first have to switch to their Wi-Fi network, which is very inconvenient, of course, and then you can use the app. Some of those apps also do firmware upgrades this way, which means that the app actually also has a copy of the firmware from the Wi-Fi chip in the car, which is, of course, for reverse engineering, very convenient. So use the Wi-Fi function from your telephone as a hotspot, so not Bluetooth, but you have to set up a Wi-Fi hotspot with your phone and then your car can connect to the internet. We saw some cars that no matter how you connect them to the internet, they will always set up a VPN tunnel to the manufacturer. So all traffic will always be encrypted end to end. It doesn't matter really if they're using their cellular network or if they're using the Wi-Fi hotspot on your phone, they will always set up a VPN tunnel. So inside your car is the CAN bus network, and that's where we want to be. The CAN protocol is eventually the protocol that allows you to unlock your doors, control your air conditioning, but it also currently is used to activate your brakes and to control your steering. For example, if you have adaptive cruise control, the car needs to brake if it sees another car in front of you. So there's a radar system in your car, and if it detects any obstacle ahead, it will send out a message to your brakes over the CAN bus, after which your brakes will automatically apply. Same control goes for steering. Some cars can auto park or have lane assist, which will keep the car between the lines. That also goes through the CAN protocol. So the CAN bus typically comes with rings. So the car manufacturers figured out that, okay, so having one big network that controls everything, that might not be a good idea. So they separate the CAN functionality in separate rings. So you have a low-speed CAN bus, which is used for convenience features, like opening up the windows, setting up the air conditioning, etc. And the high-speed CAN bus is used for everything that is critical for the car functioning, like the engine and the brakes, etc., etc. Obviously, if you're on the low-speed CAN bus, your messages should not end up in the high-speed CAN bus. That's the whole idea in general. So the CAN bus protocol, yeah, it's a bus. It's not like Ethernet. You don't have a sender or receiver information. Yeah, so it's just a bus with high volume of messages that you have no idea where the messages are coming from or where the message, for who the message is. Each message has an ID, which is an 11-bit field, and then some payload, which contains some data. Everything else is not standardized, actually. So what ID means, what? You have no idea. What each payload means, you have no idea. So it's very difficult to get a grasp on what each message actually means, because you have a very, well, if you actually log it to a file, you have a very big file within seconds, with only bits that you have no idea where they're coming from, who's actually interested in receiving those messages and or what the payloads are. Of course, it's all binary data. So to actually figure out what message has which action as a consequence, that is a very time-consuming task, and usually involves a lot of trial and error. So when we started out this research, I was really oblivious about car security. I didn't know anything about car security, actually. And my assumption at that time, which was rather silly, of course, was that if you have access to the high-speed Canvas, you can just spoof the front radar for, okay, so there's a car up ahead. Please apply the brakes. Apparently, it doesn't really work that way. Cars have a lot of security built in, and they will not break without any, well, very specific reasons to do so. So if you're on the Canvas network and you spoof the message from the front radar, that will most likely not work due to all kinds of security mechanisms. Furthermore, of course, the actual front radar is also sending messages at the same time, saying, nope, there's no car in front of you. You can just keep going. So typically, your brake system will say, okay, in that case, I won't do anything. So attacking the high-speed Canvas is a whole nother research topic on its own and also a lot of work. So it was clear that most car manufacturers will actually separate the internet connectivity from the high-speed Canvas in some way. But of course, the app needs to control the actual hardware in some way, because in most apps, you can do things like lock or unlock your door or control the air conditioning. So there has to be some link between the cellular connectivity and the actual Canvas to make that happen. The component that connects the car to the internet varies between models. In most systems, the IVI system, which is the infotainment system, so your satnav or radio, will actually house the internet connectivity. And most cars will also have what they call a Canvas gateway. The Canvas gateway is a separate hardware module, and its job is to restrict messages from the low-speed Canvas to the high-speed Canvas, because some messages need to go from the high-speed Canvas to the low-speed Canvas. For example, you want to have motor information on your IVI system. You have a car section and will give out error messages, for example, so change your oil or something. That's typically something that will go from your high-speed Canvas to your low-speed Canvas. And the Canvas gateway is required to filter that messages, et cetera. It's not always the case that the IVI system will also have the internet connectivity. In some situations, the cellular network will have its own line on the Canvas, and it will be a separate hardware component in the car. Or if you look at the car that Charlie Miller and Chris Velasek attacked a few years ago, there are actually the infotainment system was connected to the internet, and the infotainment system was directly connected to both the high-speed and the low-speed Canvas, which is for a security standpoint of view pretty much a bad idea. Yeah, we started out by looking at the infotainment systems because they were most likely to connect the car to the internet. And we were looking for a remote software-based attack. So, virtually now, we have to continue to the next slide, skipping some details because of this closure process. But at some point, we got roots on the IVI system via our Wi-Fi hotspot. So, it was not remote-remote, but the car had to connect to a Wi-Fi hotspot at first, but then we got roots on the IVI system, which was, of course, a first step. So, well, maybe steps at a time. I will give the words to Thijs, my colleague. We'll guide you to the next presentation. Okay, so we had a root shell on a car, and then we started to look around for common tools to find out other things about the system, and then we noticed there's nothing there. None of the tools that we would normally use to explore the system were there. So, we had nothing to work with. We could find out that it was running QNX, which is a real-time operating system, which is somewhat Unix-like. If you don't look too closely, you can just pretend it's Linux and then ignore that part. So, we had to invent some creative ways to do discovery on that CPU that we hacked. So, we could run iFconfig, I think, and we did find out that there was an internal network on the car. So, there must be something else out there, we think. So, we started to do some host discovery first. We just ramping instead of M-Map to find out which host was responding, and then we started the script to do a port scan by using FTP. So, by just trying to FTP to every port on the IP address that we found, we eventually got a complete picture of the other device on that network, which was a very annoying process, because every time it found an actually open port, we had to restart or manually close the connection and then let it continue, and it was really slow. So, we came back after a weekend, and then it processed three more ports, and then that found something open, and then we had to start it again. It was a very time-consuming process, and we had really not much information about what we are actually working on. Our current theory was that we had a CPU that was connected to our Wi-Fi hotspot, which was connected over Ethernet to something else, but we didn't know what. So, our hope, our assumption was that the CPU-A was connected to the cellular network, which was used by the app, but that was still an assumption at that point. We looked at some of the binaries, we dug around through the system, and we did find some references to text messages to SMS, so that might be it. There were some references to specific pieces of hardware that can be used to send out SMS messages. So, our theory then was that it was using SMS to update status, because we also found out that there was quite a long delay. You had to push refresh in the app, and then it was waiting for a minute, and then you saw the status of your doors. So, SMS might actually be plausible for something like this. So, there was still net running on the other device we found, so the other thing in the network, and then we thought, well, maybe it has the same password. We didn't know the root password yet, so we looked at what we had, and luckily it was encrypted to a desk script, so for about $100 we got to get the password in like three days, and then we thought, well, we need more tools there, so we signed up for a trial license for QNX. So, this is a commercial company that develops this, and you can request a trial license to evaluate it. So, after we filled in this form, they contacted us, and by email and by phone, they were asking, well, probably wanted to ask what we're going to use it for, but as we didn't really want it to say, well, we're going to hack this car, so we just didn't answer. And then they just, after a month, they sent the trial license anyway, so then we got the tools. So, at least we could now compile things for the device we were working with. We had some pre-compiled binaries that we can put on there. So, then we had Telnet. So, we tried to connect. We had the password, and it was wrong. So, okay, let's try something else. Let's brute force the password. How hard can it be? Well, no, that doesn't work. It crashed a lot. It may be a real-time operating system, but it doesn't mean that it can't crash or hang in different ways. We had to reboot that car quite a few times to get it to work. And then, it was clear this process wasn't working. Well, what it turned out to be was that the Telnet binary that we got from those tools was broken. So, we had to compile one of our own. And then, yes, it did accept the same password. So, both of them have the same root password, and we got access to that other CPU. And then, later on, as we were exploring the system more, we found out more things about QNX, because we had no idea what it was. Well, it turns out that there's a specific QNET protocol, which QNX devices can use to communicate. And this sort of like a file system, file sharing service, but it basically means that if two QNX devices are in the same network, then they can mount each other's complete file system inside their own file system. So, we had complete access to the other device, but we didn't know it. And actually, they can start processes on each other. There are actually commands to run a command on the other processor. And we found that out only much later. So, it was clear that these two CPUs were not a security boundary, because the same password, you can start processing both of them, and they both had Telnet open. So, what were they used for? So, our theory was that CPU A was for controlling the multimedia system, the UI, the device, and connecting to speakers, and that sort of thing. And we were also sure that it was connected to the Wi-Fi, and that CPU B was handling the low-level communication with the car. So, we dug around there, and we also found some references to specific hardware, but nothing that really seemed to influence the connection with the app. So, we were busy working on this for weeks, and at some point, we moved the multimedia device from the car, and then I checked the app, and it was updating. It was still working, even though we had the device disconnected from the car that we thought was handling this communication. So, it was clear that there must have been some other hardware device in the car that was handling this communication, and later on, we found out where it was, and it was completely somewhere else, and related to the device we were hacking. So, we realized that there was another hardware component, and as we didn't have firmware or anything, well, we decided, let's try a different car. So, there was somebody else in the company with a car with very similar infotainment system, but it did have the option to supply your own SIM card. So, what the situation is there is that we definitely have CPU A connected to the internet, and then connected to the other device, but then we got into the challenge of trying to get access to that from the internet. So, we know that this car can connect to the internet, but can we connect back? Well, most carriers these days use carrier grade net so that you don't get a public IP address. So, we had to use a very specific SIM card to get a routable IPv4 address, but when we did that, we could get access to it remotely. So, the car had a public IP address, we censored it and it's wrong, so ignore that, but we could connect to that from the internet to the car, and then use something we cannot disclose yet to run our own scripts on the car. There's nothing modified about this except for plugging in one SIM card into that car. So, if you know that IP address or if you scan the internet for specific open ports, you might be able to find cars like this with a specific SIM card. So, this might sound very bad, but there really were some defense mechanisms that we found that really indicate that security is a concern for cars. There is a firewall running on the device, but it wasn't enabled for all interfaces, as you can see in the previous slide. And there are cryptographic signatures that are used in the protocol to install updates on the car. So, here are some other things that we may have been thinking about doing, but did not do, certainly not. So, you should not request a test drive and then drive around the corner and try to see if you can do that on the car as well. You should also not go to showroom, plug in your laptop into a car if nobody's looking and then try to see if you can also do it there. You should definitely not do that. But there may be other devices where this might work. Maybe other models of cars with similar infotainment systems. So, how do you get from there? We have root access to the CPU A to CPU B, but how does that control the car? Well, we know that there is a gateway and there's also a separate chip on the multimedia system that controls the access to the canvas because the CPUs are not directly connected to the canvas. There's a canvas chip that limits what messages we can send to the canvas from the infotainment system. So, how could we gain access to that? Well, we could look for an exploitable vulnerability by just sending stuff to it, but that would be a lot of work. We could drive a mechanic or prepare the car, specifically to dump any USB sticks that are plugged into it and then send it to us. Although, according to our lawyer, we should definitely not do the last two of those. And we didn't get very far with that currently. So, we currently know that we can own the first CPU, that the second CPU can be owned, but whether you can attack the canvas from there, that's still theoretically at this point. So, as we're currently working on this, we're using canned sniffers before and after the gateway. We're trying to see what messages can we send from the canvas from our infotainment system and how do they look like and what do those messages do? So, what can the infotainment system actually control? So, what could we do as an attacker? And then we dig around a little more and even though at the start, we said, well, a cellular attack would be the coolest, we found something else. You can plug USB, you can plug USB devices into your car. That's gonna be a phone or a USB stick with music on it. But there was one specific identifier that looked for, it was kind of weird. It was doing something it didn't do for anything else. So, what did it do? It started a Ethernet over USB interface if you plug in a very specific USB Ethernet dongle. Well, guess what the firewall is like on that interface? There isn't any. So, if you have a USB stick that may not be completely trusted or if somebody has a phone with malware and they plug it into your car, then they may be able to start a network interface over that and then gain access to your car and then do whatever malicious thing they want to do. So, we currently have a remote attack against the IVI system, which gives out your GPS location, for example, which controls, of course, whether it's on screen, what's on your speakers, and which also can activate the microphone. So, an attacker could listen on the microphone to everything you say in the car. The Canvas chip that Ty spoke previously on which didn't allow us to send arbitrary Canvas messages, we found out that that is most likely unsigned. We have some specific, very clear indication that's unsigned. So, the next step in attack would be that we reflash the chip so that we can send arbitrary Canvas messages. But of course, for that, we need the firmware which we cannot obtain legally. So, maybe with some help with the manufacturer, we can get a copy. So, the IVI system is shared between models. So, the impact we have is broader than the model that we tested this on. The remote attack works sometimes. That, for example, depends on the version of the infotainment system that you have in your car, because there are different models, different versions. And what we saw that the USB attack, so suppose you have malware in your phone, you plug it in to your car, that will always work on all models that we have tested. So, what is next? Well, we are currently in the responsible disclosure process. The manufacturer has been most helpful on this point. So, the next step would be to get a hold on the Canvas chip legally. So, we can flash the firmware with a backdoor version, which would allow us to send arbitrary Canvas messages. And of course, look more closely at the Canvas gateway, which definitely needs more research. But of course, we're also interested into looking at more cars. Because, yeah, if we've done with this car, we'd like to look at another car. We have learned a ton about car security. And so, yeah, if manufacturers would like to work with us, please drop us an email. So, there are benefits from having an internet-connected car. I mean, we also love the internet. We're all geeks of course. And we also know that we cannot stop the IoT revolution, that we will connect everything to the internet. So, and actually, we don't want to. And of course, it's also natural, logical that all cars will have an internal network, which will include braking and steering. Because you want things like adaptive cruise control, autopilot, et cetera, et cetera. However, we think that, well, it's all software nowadays. And security vulnerabilities will always be a risk. And users are used to the fact that they have to update a laptop and their phone on a regular basis. But they're not used to that they also need to update the different components in their car. Most cars also don't have an over-the-air update system. So if you want to install an update for your car, then you have to drive to the dealer. And they will have insert, either plug it in with the laptop or have to insert an SD card. Most users will never do that, of course, or only once. So I think this is a problem that we can definitely fix for the car of tomorrow by supplying over-the-air updates in an automated fashion like we do for operating systems on your phone or your laptop. But we cannot fix this for the car that are currently on the road, of course. The current car is on the road, however, will be there for the next 15 years or so to come. And I also think that this is not a problem for the owners of the car, but actually a problem for everybody else who's on the road as well. Because I don't like driving next to a car that has remote vulnerabilities in them. So I think it's a problem that still needs a little bit more attention, especially for the cars that are currently on the roads and not the cars for the future. Okay, well, actually, that was this for today. We had to skip, of course, the demo because of the disclosure. So are there any more questions based on this? So in the middle are microphones. So if there are questions. Hello. Most of the cars have a diagnosis port. Yeah, correct. You know where that one fits in, which canvas, or where it is connected? Yeah, so the diagnostic interface is connected to the canvas on the specific diagnostic canvas line. So it's a separate line from the IVI system that we're currently on. So what we still would like to test is if you can send diagnostic messages from the current point of where we are currently are to see if the canvas of the Gateway will accept that. Because, of course, we need to check that to make sure that the separation is actually in place. But it is a different canvas line currently. Hi. I understand you can't really tell us anything about the remote vulnerability yet. But can you tell us anything about how you found it? Well, we found some... Well, we first looked at the Wi-Fi connection to look at what the remote attack surface was. We found out that over Wi-Fi there was quite a few open services. And then we dig deeper into each services and we could also find some information online or some reference stuff. From there on, we could work out how the system would actually work. We could eventually manage to get a full-working exploit. Thank you. Next question. Hi. You mentioned that you found the type number of the second CPU. Yeah. Did you actually physically look at the card to find out or did it report it in your command? Both. We could, of course, unscrew the IVI system and we look at the chips that were there. That also gives us some information about the rest of the system and how it works and how it operates. But once we had access, we could also check that using software, of course. Another question? One question. You exploited some undocumented feature. Did you do any ex... Look into, like, exploiting APIs? Like, the Tesla has a documented... Well, semi-documented way to retrieve car information through an API? Yeah. If you have the API key, which friends of mine really misused, but it was really funny. Did you do any research for that? Well, all the cars that we looked at didn't have a public API. So what they all did, they pushed their car status to the manufacturers and the app would connect to that same network. But none of the cars had an API of their own to connect to. You think it could be really misused? Of the API could be misused. If you supply an API on the IVI system, obviously, of course, yeah, of course. If it has vulnerabilities, or if you manage to get a hold of the API key to some other way, then, of course, you can not use that, yeah. Okay, thank you. So, thanks for your talk. I was wondering, you're not allowed to say anything now. Do you have a timeline for when you will be able to share your findings? Not currently. Well, we're in contact with the manufacturer and... Yeah, I hope I will get a timeline soon. But in this moment, well, we don't really have an idea. Hopefully in less than 15 years. Ha, ha, ha. Okay. Next question. Are you allowed to say whether you got to the internal fast Canvas or not? Well, that is still ongoing research. So we have CPU A, CPU B. We have an attack that will work on the Canvas chip, which, well, we are... Well, 99% certain that it will work if we have the firmware. The Canvas gateway, that is still some ongoing research that we're currently looking at. So what we're doing is with the two Canvas snippers on both sides of the gateway, we can look at which traffic flows through the Canvas gateway and which doesn't to get a map of which commands are actually allowed to send on a high-speed network. Other things that we're looking at, if we can send diagnostic information via the Canvas that we're currently on, maybe the gateway will accept that. And the best way, of course, would be if we can get a hold of the firmware, which might be possible. I have spoken to some guys and, well, it might be possible. Then if we have the firmware, then we can, of course, reverse engineer it and to look for specific vulnerabilities. And otherwise, we have to do that remotely, which is also possible, but a lot harder, but still possible, of course. Yeah. Another question. Just to qualify the risk, is it a broadcast attacker, or is it a single? Sorry. Is it a broadcast attacker, or is it a single device? Sorry, is it a broad? Is it a broadcast attacker, or is it a single device? So are you essentially picking off an individual card because you know that it's a VIP? Are you looking at an attack that you can roll out across an entire fleet of vehicles? Well, the IVI system is used between different models. So the attack is wider than the model that we currently look at looking at. I get that. But do you need to connect to an individual card, or can you essentially roll something out and roll from such a level? Yeah, OK. So the attack will, the remote attack will work on a percent of, I don't have the numbers, but will work on some of the IVI system, depending on which version it is. If it's a vulnerable version, the attack will work. However, you're most likely blocked by the ISP because most ISPs will use NET to prevent any, well, use NET for the IPv4 address. So you cannot directly connect to the car. And another option would be that you get a SIM card of the same ISP so that you can connect behind the NET to the car. Only for some ISPs, that is allowed. Here you have client-to-client communication from the NET.IP address. However, from most ISPs, at least in the Netherlands, this is not allowed. So you have no client-to-client communication. So I think for most users will be protected by the ISP, which is, well, actually, that's not where you want your security to be. You want your car to be secure on itself. So the car will work against the entire fleet, if, but with the limitations of that, you need an ISP that is allowing client-to-client communication or is handing out accessible public IPv4 addresses. Hi. So you said that every car has its own public IP address, right? No, that depends on the ISP. It depends on the ISP. So would it be possible to fingerprint a set of IP addresses to determine which IP addresses are cars? Yes, if you give me an IP address, I can tell you if it's a car or not. So I know from, of course, in biology, you have to capture and recapture a technique to determine how many species are within a certain area. And they tried that with their car vulnerability by scanning the internet. And then, sometimes later, rescanning the internet, see how many cars were still online. But that turned out to be completely wrong, that estimation. So we actually didn't do that for this research, because, well, we tried to focus on other stuff, getting deeper into the car rather than determining the number of vulnerable cars currently on the road. In general, I think, in the car, there is a network. Yeah? Is there not an encryption in this network? No. There's typically no encryption. The Canvas messages are most definitely not encrypted. And if you have internet in your car, it depends on the software stack. But in our case, the communication between A and B was entirely not encrypted. One moment you mentioned that something crashed and you had to reset something. I assume you didn't have to remove the battery from the car to do that, correct? No. To which level did you have to reset? Basically, reboot everything. I'm still not sure how to actually reboot it. It was just turn off car, wait for a few seconds, and then turn it on again. And then sometimes that rebooted the navigation too. So there was a button you could press for 10 seconds, and then sometimes that worked as well. And it was weird. Because, well, the IoT system will remain active even if you shut down the car. So it turned out, actually, within software, it was relatively doable to restart the car. If you have a shell, if you didn't have a shell, it was mostly pressing buttons until it worked. That worked about 95% of the time. Are all the exploits you found software patchable, or do some of the chips really need to be replaced? So the remote reliability, that would be software patchable. The not using signing on the Canvas chip, I think that will need some hardware replacement as well. So that's something you cannot easily fix. However, you can say, OK, that's accepted risk. As long as the Canvas gateway does a job, then that's OK. But the main vulnerability that can be patched via software, yes, but it cannot be patched over the internet. So you will need to go to a dealer. In what timeline will be the fixes slash patches available? Currently, I have no idea when the manufacturer will publish those fixes. So I have more questions. Over there. Wait, wait, wait. Just a small one. How many brands did you look at? How many brands of cars? I don't know the specifics, but more than 10. Is it models or is it brands? Oh, brands. I'm thinking, I think that's about the same. I think most also wear different brands, but also some models between. And your non-disclosure agreement was for one brand or for all of them? The disclosure process currently is we have a vulnerability and would like you to fix it. And not about brands or et cetera. OK, thank you very much. OK, thank you, Dan Köper and Thijs Alkemaade.