 So we are Ben and Vladan from XIBMX for thread and we are involved in a lot of stuff but we like to hack hardware, software and especially if something has wheels and it's moving it is interesting target for us. So we spend a lot of time actually working with vehicle security testing and today we are here to share a little bit of stuff that we encountered through the years with you. So what we are going to cover today is about hacking car infotainment system and how far we can actually go with it. So where are the dangers and what is the approach that we have discovered which is different than everybody else is using. So why it is important? So unfortunately cars are becoming a lot more complex than they were before. So this screen we can see different number of lines of code that are used to develop specific systems and we see that Facebook is something about 6.7 million lines of code. Boeing 787 is a 7 million and we have 4 F 150 million lines of code including all systems in the car. So current modern car can have more than 200 kilos of just electronic and wires in it. So you will find like a hundred different smart computing units. So I'm not saying computer because they are of different level but smart computer units which control specific functions from your entertainment system, from your convenience systems until the suspension, motor ignition and everything else. So cars become a really complex multi computer systems which are all connected and they becoming more and more connected and exposed even to the internet. So we all like our infotainment system because it gives us constant access to everything. So we have, we can watch movies while we stand fortunately. We can gain information from the internet. We can retrieve data from systems about road, state situation on the road, if there are congestion, non congestion. We can do a lot of stuff. So it needs to be complex in order to support all of this. What is infotainment system? It is not so simple thing that we can think. What we see in our car is just a small screen which is presented to us and we interact with this screen by touching it, moving it, abusing it to different ways, spilling our coffee on it. But it is just what is exposed so we can actually see. What is behind it is usually much, much more complex than it. So it can contain different features, radio, Bluetooth, control cameras inside, outside, recording in autonomous car. It can have even more stuff. So if you have lane assist it can, it is used to do this lane assist. So cameras will be picking up the data, sending it to your infotainment system and it will do processing and help you stay out of the lines to keep you straight on. So there is a lot of stuff that is integrated, that is connected. We see a lot of radio communication. So for example, your tire pressure monitoring system, it is all wireless. You can have Bluetooth, you can have Wi-Fi, you can have Wi-Fi, you can have a lot of different technology and car is becoming actually like mobile phone on the wheels. So that's unfortunate because we know how bad we are surviving our mobiles. They take all of the time. We are looking at them all the time and we can hit stuff while we are walking. Imagine that happening while you are driving. Not the best situation for sure. So as I mentioned, what we see is just a single head unit usually, which is displaying all information. But behind it we have a plethora of different systems which are used to collect this information and to process and in the end to present it to us. So in specific case that we are mostly discussing today we saw that it is multi-system which has multiple different boxes which are dedicated to different things. Some functionality can overlap between different boxes because for example in one car manufacturer you can have one level which is basic or you can buy another option which is advanced functionalities or third one which are superb functionalities and all offer something that might be better than the previous box. And all of them together are connected and communicate with each other. So they collect information about your car, about where you are driving, about your location and even maybe some of your personal information which we are going to show a little bit later. The problem with this is we have a lot of software as I mentioned, 150 millions line of codes. Do you think it is bug free? No. And problem is that updating car is much more difficult than updating your mobile or windows operating system or Linux or whatever operating system you are using. So this is a part of the problem. So manufacturers make it very difficult for you to change your car computer software embedded. It's a little bit easier to update your infotainment system but it might be even not done because customers are not used to it. You need to go on the line to log in with some specific credentials that should be provided to you by your vendor. I hope they are not providing it free for all so you can just download, update on the internet. We saw even that happens. So it can be really dangerous and a long standing process which might not be done in time. So you might be exposed. In worst case, manufacturers need to recall the cars so they can update them and change the software in case of serious problems. So as I mentioned, in the head unit, we have some basic functionalities and we have another box which is hidden behind the dashboard which provides additional features. It might be connectivity, it might be better FM receiver with more functions. It can be GPS receiver for navigation and all these boxes are connected to each other with their own bus. So they are using their own bus to connect to each other to exchange information because in the end you always see the basic device screen. So there is only one device which has screen. Other device when connected to it will communicate and take over the screen from the base device, from navigation unit, from head unit. So it uses some inter-equipment communication protocol which can be vendor specific. There are few that are open and known but mostly they are using some proprietary communication protocols. When we open these boxes we can find different hardware inside it. So in this case what we commonly see is Texas Instrument Chip. It's big SOC which is optimized to run fun and nice operating system called QNICS which some of you might know was running on BlackBerry devices some time ago. Now they are upgrading it and maintaining it and they are selling it as the main car navigation platform. So it is new Neutrino platform which run on ARM, ARM v7 in this case and this chip is very powerful and can do a lot of stuff for you. It can do a lot of DSP processing so it can do video processing, it can process network information, it can interface with other stuff. So it is really a powerful device with complex architecture and it is implemented in such systems. So what we found on these devices is stuff like NAND flash. We have identified a lot of positions where we can connect and see what the information are there. So on these pins there can be a lot, something interesting, something we don't know until we verify. So as I mentioned the main operating system which you can find on most of these cars are Android and QNICS. QNICS is becoming really dominant in this place because it is microcarnal based unfortunately it's proprietary so it is very difficult to obtain anything open source. If somebody has any information about any open source tool chain for QNICS let me know, I'm interested. Otherwise licenses for QNICS for developers are somewhere like 10K dollars per license. So it is really expensive. What we also see that these devices are on top of the QNICS, they are running some user interface. It's based on SWF flash user interface and it utilizes known technologies which are a little bit modified and customized for specific purposes like Lula scripting, D-Bus, Java, X-Let. So all of these are standard but they are usually just enough modified so it's difficult to use pre-existing tools to do anything with this. So also during this we have discovered that one of these devices has more than one single partition. So these partitions are all custom QNICS file systems and they are optimized in order so when you're updating you overwrite only a single partition. So as I mentioned QNICS is similar to Linux but it is a little bit different because it implements a little bit different approach to the kernel. So it is microcarnal which is monolithic and in contrary to Linux which is modular. So everything should be already in the kernel itself but some of the drivers which are needed are loaded from user space. So it is a little bit different than the Linux kernel where everything is running in ring zero. So everything every driver run in kernel space unless you are using some hacks and you fuse or something that enables you to use user space drivers. So problem it is everything is proprietary as I already mentioned proprietary file systems which are mount as read only on device. There is no much documentation we spend few months researching about QNICS but as I said expensive licenses close source proprietary there is no much to find open. So we were spending a lot of time reading development manuals trying to find something that exists. So few people done something but they are limited. So we built on other existing tools. Problem is that it is impossible to cross compile for QNICS anything unless you have QNICS development tools which are costing 10k as I mentioned. So what we started we started to analyze the boot process first. So boot process start with IPL which is like your Linux loader. So it will load first and then load everything else. It will load this image file system that is actually zero Z image in Linux. So it is kernel and then it will start loading user space programs and finally it will load partitions from flash memory. So it has fully running system in the end. So what we see while reading this documentation that I mentioned we have discovered one interesting recommendation by the vendor and that is actually what we find really interesting and that is to eliminate everything that can slow down the booting process. So all security features like checksums, signatures, CRC, whatever you have they strongly advise you to disable it so device boots quickly. You don't want to be sitting in your car for 20 minutes waiting it to come up to check image before it loads it to check if it is consistent. So it is just optimized for quick boot because we are impatient. We like to be driving from point A to point D now waiting for our car to boot. We have windows for that. Also what we saw that there is no secure boot file systems were not encrypted so there was a lot of security features which are missing and which made our life a little bit easier, easier than it would be otherwise. So also one interesting thing, devices that we tested were customized for different car manufacturers. So we have checked not a single vendor but we have checked every car that we can find and that people will allow us to play with and you would be surprised that not many people will allow you to play with their car. I don't know why but we saw that they all use OM devices which are kind of similar to each other and they are just a little bit customized and optimized for each specific car. In some specific cases we saw that car vendor asked for additional security features to be included in such devices. So it is possible that the same device which is running in one car is vulnerable and the same device with same level of hardware version runs differently in other car manufacturers because car manufacturer asked for additional security features to be on. So when we dumped the firmware from these devices and we have done analysis we found references actually that the same firmware is actually baseline for a different car manufacturers. So we found strings that are relevant for anything that you can imagine so I believe they are selling to everybody. So problem in this area is that you don't, you're not sure even if it is the same hardware if it is the same level of software and feature packs that are implemented on this hardware. So our idea is to see what we can do first without actually dismantling the car. So we reviewed all access vectors so radio signals, available interface for USB, CD, available applications on the devices so they are having some kind of market where you can download and install your own applications some of them you need to pay some of them are free of charge and can be just downloaded. After we were done with this part then we started dismantling the devices so we pulled them out of the dashboard, we had wires everywhere so we start analyzing devices we saw there are flash chips, there are reproms, there are consoles, there are soldier points, test points where we can maybe do something with it. But unfortunately, car is not the best laboratory that you can work. This is poor Ben, Ben was not hurt during this work so he's safe, he's here, he's just very cold in this picture I know. So we were working in the UK in the winter it was not the best possible way it was around zero and we are sitting on car park with everything open because car is small and there is two of us and we are not so small we need a room, especially me yes. Thanks for pointing that out it was not obvious. So we removed just the plastic covers of the dashboard so we can actually access the wires and connections behind the devices and we started analyzing how these devices interacts with the car. So our idea was we don't like to work outside on cold in a very, very low space. So our idea was can we move the car inside guys maintaining our lobby? No, we don't allow, we will not allow you to drive car in. Elevators might be a little bit smaller than you need. So then we get another idea that is let us try to emulate the car outside of the car. So we need to replicate enough. So devices are operational but without actually needing to have the car. In very, very old times I would go to the junkyard and I would try to salvage ECU with everything but today we do not need to do that because modern car are not operating on the same principles. Even modern car do not have a lately proper OBD interface this is emulated. So even in the car you have emulation OBD and behind that it runs whatever you want. So there are different protocols and standards that are used. But in order to make devices operational at this point we needed to check status of the holy grail can bus. So how device interacting with the car? We started by connect discovering where can bus is connected to the device and start with sniffing. In order to find out what device needs from the car so we can set it up in our lab. But we discovered that we might not need to do anything because device is not communicating on the can bus. So device is just listening but at that point in time we could not find any single packet injected by device on the can bus. So what we saw after we started first device was removed. We started sniffing the can bus collecting what information we can see. Then we connected everything, started running comparing and we see exactly the same stuff. So device is not interfering with can bus at all. Anyway we just captured this traffic so we can replay it back in the lab. So if you missed something it will still work so we don't have a problem with that. So this is a little bit of hardware that I like to use. It is all small hardware and it is pretty cheap. I like blue pill. It is very cheap STM platform. It is less than two dollars on your favorite trainees supplier and it is cheaper than Arduino. It can be programmed Arduino but it is much more powerful. And what I like it? It has USB and I was very happy when I discovered it has can bus on it. When I start developing a sniffer that I needed I had one sniffer it is on the right corner but I needed to have two of them. One to sniff, one to inject. So I needed to create another tool and I like to have my own tools anyway. I discovered one very disappointing thing and that this platform cannot work on USB and can at the same time because of some memory overlaps in the architecture of device and you can use only USB or can. But luckily I had a can shield from Arduino which worked really well in this case. So we have collected all information from can bus and started creating our environment in the lab where we had standard power supply units. We have everything else. What we didn't have are actually cameras and tenors and speakers but that was not important because devices were fully operational even without that. So we were very lucky because now we can work in much hotter so in better environments our hands are not freezing, we are not hurting ourselves. Can bus emulation is working devices happy not complaining and everything is just fine so we can focus on to the operation. So as I mentioned devices are using wireless connectivity but not on themself. So they are they need to connect to cast to your phone. So you as a driver need to set it up set up the connectivity on your phone and share. So it is like a hotspot on or Bluetooth depending on devices some of them require Wi-Fi some of the required Bluetooth but it will use that as a communication channel in order to establish connection connectivity to the internet and to go to download everything it needs applications configurations to enable your access to up markets so you can buy applications that you like to install. So what we see is the device is now having standard IP address which enabled us to play with it without actually connecting to wires. So we have set up a rough access point which is controlled by us based on host APD DNS mask IP tables and our favorite burp tool and we connected to these devices to our access point and just intercept the traffic to see what device is doing. We have discovered that devices are devices that are using Bluetooth were a little bit more pickier than Wi-Fi devices so they needed to establish first before they establish PAN connectivity so private area network it needs to be set up as hands-free device. So it needs first to connect your target device that you're sharing with your car as a hands-free device and then it can use it as a network standpoint. So that made our life a little bit complicated but not too much because it was easy for us to create a small Python tool based on PyBluzzi which we use to emulate phone in both profiles. So that enabled us to actually establish connection and to sniff the traffic that goes from device to the internet and back. So we implemented only necessary devices, only necessary features in order to have this device connect and operate. So now Ben I'm tired. So now Ben has introduced the device, how they work and their specificities. I'm going to detail you what kind of attacks we have conducted on the device. But first of all, because we have described our tool, our talk story as a new approach, why previous attacks don't work anymore. You remember a couple of years ago here at DevCon and Black Hat some researchers have introduced vulnerabilities present on Jeep cars. So these vulnerabilities were exploiting connectivity. They were connecting to the device using Telnet. The password were well known and present on the internet. They were also using D-Bus over TCP to connect to the device. And last but not least, they were abusing the firmware upgrade process by passing the content signature check-in. So now for our test, we still have the IP connectivity to the device. So they have not configured any software firewall to prevent us to access the device. But D-Bus over TCP is closed, Telnet is closed and the firmware upgrade process has been hardened. So we couldn't reuse any of the previous vulnerability described on the web and here. So the angle we choose was the third party applications. So on the device we have been testing, we realized that the vendor has provided an app store and when they designed the solution, the goal was for them to open the devices to third party vendors and they could create their own application and they could sell it on the store, like for example the Android app store or the app store for iOS. In the reality, there is only a limited set of applications which are on it and they have never I think released the software development kit for third party applications, which is good you will realize why a bit later. So the first thing we did is we intercepted the communication between the software app store and its back end. So it was using HTTPS, which is good. Problem is the encryption is broken. When we try to intercept and replace the certificate by a self-signed certificate, the device did not show any warning and it was continuing operating as normal. So first problem. The second problem is the device is communicated with its back end using XML messages, a bit like SOAP. And we could easily intercept the content and modify the content on the fly. So for example, when the device request the software catalog, the server will reply with a full catalog, including the links to the URLs for the install package and just with a status, which is buy, install or install. So if the status is buy, the device when you will click on it will offer you to buy and pay for it. But if the status is just replay by install, the device will install it without having to pay for it. So the logic control is done at the client side, which is very bad and it might remind you the first mobile apps you have been testing a couple of years ago. So good stuff for us. We could get access to paid apps for free. But our goal is to go deeper. So here is an illustration. You see we have just replaced the buy status by install and we were able to install the application on the device. Now, we did some analysis on what was an install package for a third party application. So in the previous screenshots, you've seen that we have the URL for the install package. So we downloaded a couple of them. You don't need any authentication, so just a W get with the URL and you can access the third party application package. So we downloaded all of them and we started analyzing them. So what's an installation package? Basically it's a zip archive. We have inside a JAR file, so a Java archive, and one signature file which is a signed message digest using RSA signature. So we have tried to spend a little bit of time, but we were not able to break the signature encryption, which is good. Once we opened the JAR file, we realized that the source code is not obfuscated, which means with any of your favorite Java decompiler, you can access the source code which is good. However, the JAR file by itself is signed with some private keys. So here we are facing a system with two different levels of code signature. So does this mean game over? So what we first tried, our first attempt was to play with the process of zip extraction. You will understand why. The very first step that the app store is doing when you install an application is storing the zip file in a temporary area and extract it because to check the checksum of the file, its signature, it first need to extract it. So this is the piece of code in charge of unzipping the install package. And if you are good hackers and I believe you hold hard, you will immediately notice that if you have used the zip entry name, you might be able, because it's concatenated to do arbitrary file writing. So what happens if you had a file to the archive with a zip entry, something like dot dot slash dot dot slash something? So we wanted to validate this. Obviously this is not going to work with zip in zip and zip. You will get the message removing, trailing slash or whatever. But what happens with this dirty Java code? So we created a crafted zip archive using any Python lib. And you remember we don't yet have control on the device. So if we want to see if this was successful, we need to write somewhere, we can check the file is created. So so far the only thing we can do is plug a USB stick and check if we are able to extract a file to a USB stick. On QNX, if you read a little bit of documentation, you will find that the location of the USB stick is slash fs USB zero and then your USB device. So we created this crafted zip file with a directory traversal, writing an empty file on the USB stick. And you know what? It worked. So this means that we have an arbitrary file writing without creating any warning on the device once you install a crafted installation package. So good start. But now to take control on the device, what we need to do is to be able to copy a file to a place where it can be executed from. So it brings you two problems. As we said, most of the file system of the device are read only because if the device loses power, it need to restart without having to do content integrity, file system checking and whatever. So most of the file system are read only under normal operation, accepting some of them. And the place where third party apps are stored is a read write file system because you can install the applications, you can remove them, you can upgrade them. So the file system has to be mounted as read write. So we need to write at this place and we need to find this location. The second thing is so this Java archive, those are mentioned, Xlets. So this is one of the G2ME implementation. The problem is we cannot build any application or rebuild the application if we don't have the Vandor SDK or API or libraries. So this is also one of the problem we have been facing and we will explain how we solved it. So it is possible to decompile the Java source code but impossible to recompile it. This is what we just said. But how about backdooring, patching? If you all have done some testing training, you have been doing this assembling, x86, modification, changing instruction, repacking and whatever. And what about doing the same with Java? Because basically Java, what is that? Is Java source code compiled? So it is Java byte code, it is no analysis. And this is a portable code to be executed by the Java runtime environment. But basically the byte code is just assembly but for a different kind of machine and the machine is just Java runtime. So if you use the Java byte code and you modify it with kind of a disassembler, which exists, you can patch the Java code without needing the SDK nor API. This is what we did. But remember what we said, the Java archive itself is signed, which means that if we modified the byte code, the Java runtime environment should refuse to execute it. So because we didn't want to lose too much time, our first attempt was just to change a PNG icon from the Java package. And when we installed the application, it refused to start, which means that the GVM, the Java virtual machine, refused our modified application, which is good. So here again, game over? No, we tried something desperate. Desperate. We said, okay, the signature is not good, but what happens if we just remove the signature? So guess what? It worked. So if there is a signature and the signature is not good, reject the program. But if there is no signature, no problem, just start it. And it worked. So now we are able to write on the file system and we are able to execute malicious code that we have created. So the next step are pretty straightforward. We just have to create a malicious payload. So it is basically Java source code. So you just use the standard Java SDK. You just have to pay attention to the Java minor and major version. So basically your code has to be executable by the target. So what you do, you analyze the source code you extracted and you are compiling with the same target version and it should work. And then you have to hijack the normal execution flow to redirect it to your malicious payload. So here we have been using massively the USB connector of the car because we didn't want to recompile at every time our program. So what we did is we just did a payload, executed a script shell, which is on the USB stick. So if we want to modify it, it's easy. You just plug the USB stick on your computer, modify the script shell and re-execute the application without having to modify the assembly. So it's pretty easy. You just have to basically have the invoke static method, which is calling your payload. For various reasons, I'm not going into how the GVM works. You also have to have the instruction to map your assembly code to some virtual line numbers of the source code. This is the way it works. So it's not just one line but three instructions for this. The fundamental instruction here is the invoke static, which brings you to your malicious code. So now, every time the patched application is started from the user interface, it executes the script.sh located on our USB key. I'm not going through the details because we have performed maybe hundreds or several hundreds attempts because we have no idea on the device. We are doing iterative approach. We were writing commands in the script and collecting the output every time, editing the script and starting over multiple times. In the end, our goal is still to get connectivity to the device with an interactive shell. So remember the target device is using QNX and QNX provides something which is called Qcon. And Qcon is a debugging daemon for QNX used during the development phases. So Qcon is a remote code execution. Problem, the Qcon daemon was not part of the build because when you do production build, you remove any useless stuff that you won't need in production because you need to save space and time and whatever. So Qcon was not part of the build. But still network, for some reason. So we couldn't use still net as is because still net requires authentication and we don't have QNX license and our managers were not willing to buy us the license. We found Qcon on the web. We were just downloading a Raspberry Pi image for QNX which was using the same distribution and fortunately the Raspberry Pi is using the same CPU instruction which is ARM V7. So we desperately copied the Qcon from the device and we executed it and it worked. So we had a Qcon daemon working and we could interact with the device. So obviously the first thing we tried is getting the root password so we got the shadow file and we managed to crack the password. So now maintaining access and post-exploitation. Because we don't want to repeat all of those steps every time we want to get access to the device, we needed to find a way to get persistent access. So we got the Qcon and we got the root password because it's using Descript, the password length is limited to eight characters. So this could be cracked with a reasonably powerful system within a few hours. This is optional because you can use Qcon but it's nice because telnet is much better for interactive shell than Qcon because Qcon doesn't have for example the background and which reside on a read write partition and which is executed at every boot time. So it makes a lot of conditions but we still find one. When you're doing that you need to be very careful because if you mess with a startup script there is no reset to factory option because you will prevent the device to boot properly so you can't even go to upgrade mode and reinstall it and there is no reset to factory that will restore the content of the system. So be very careful during this step unless you will get a break. So during the post-exploitation step we were having some fun. First of all we realized that all the personal data are stored in SQLite which is very common if this is the same for Android and many of our system. So what was funny if you are in a rental car and there has been several drivers before you pairing their phone with the Android phones, names, Mac address, Bluetooth Mac address, phone books and if it's Android phones you will also get the content of SMS inbox which is fun. The second thing is there is a lot of logings so you know where was the car and when with the GPS location, time and date and some events which is also interesting and it has been used in France for a criminal investigation where they could demonstrate that the killer car had recorded this in the logs. For example you can do some tuning, customizing the color, get a different GUI because it's just flash and HTML5, HTML5 so you can customize it very easily and it's fun. And you can also play with the services. You remember when Vlad introduced the software architecture, it's using D-Bus so a common bus with a lot of services plugged on it. So for example the FM tuner so from the station you can change the volume from the command line, you can use the text to speech service which is used by the navigation to make the car speech to you and it's very fun. It's especially very fun if you re-enable D-Bus TCP and remote access to the car. So if it's a rental car and somebody else is connecting the car after you and you get access back to the device you can talk to the guy for the car which is very fun and that might be very scary for the guy. So systems, so all those services, D-Bus services are written in Lua it's a modified version because everything is non-standard but if you modified the Decompiler, Lua Decompiler to bypass some checksum, some magic numbers verification you are able to reverse it and obtain the source code. So it was very interesting for the next step. Now the holy grail, the canvas because all of this we did it in the objective of getting access to the canvas and to the car critical systems. Canvas is allowing access we've told you to the NGN ECU something less critical, air conditionings windows whatever and here we were facing a big frustration. The system we have tested did not have a full access to the canvas. It was actually going through a gateway and this gateway was responding to a proprietary protocol so it was only giving access to for example the fuel consumption the speed of the car accelerometer so that for example if the car is driving in a tunnel and there is no GPS signal the GPS navigation system still knows which speed the car is going on but it was a lot of frustration for us because we were not able to jump on the canvas. It was even more frustrating because the reason why it was not possible was not for it was not a security counter it was not because it was just because the device had a hold port device design so they had to put this gateway because the device itself didn't have the cantron sewer on the board so it was a lot of frustration for us now because we are hardware hacking village and we've mainly talked about software we're going to talk a little bit about hardware so the box was dismantled we have been used standard tools such as clamps power supply logic analyzer, oscilloscope and all the tools you can get to your favorite Chinese provider still and we have been able to identify the pins you see but we had no idea what was their purpose so using the logic analyzer we could quickly identify the console so it's a serial console at 115-200 bow unfortunately once you boot you have authentication required you know if you do this on a standard Linux you can boot in single user mode just by altering the kernel command but with QNX with the IPL you cannot do that the IPL so initial program loader which wasn't the device did not offer a disruption authentication was weak right so here we had to have the root password cracked otherwise we were not able to get into the device so this is what I just said we had a problem we needed this root password so what was our option doing the physical hardware attack there was a hefram so the hefram is a small memory chip using SPI because when the device is booting it doesn't have the drivers to talk to communicate with the big flash end it needs an intermediate the IPL is doing the IPL is loading the driver to communicate with the large chip and we found out that in this small 8 kilobytes hefram there is obviously some persistent information such the macOS of the device bluetooth wifi the serial number maybe the build version but there is mainly the QNX IPL which is the driver for the next step and our idea is if we modify the IPL if we recompile it offering the support to boot in single user mode by changing the initial program from login to just KSH then we can get access to the device without needing authentication using the serial console so here the work is still in progress but we found the QNX IPL source code because it is provided by Texas Instrument on their website so you just have to modify it recompile it write it in the eFram chip this is not a problem because if you remember there is no secure boot because everything has been disabled so you just have to recompile, write it in the device and then you're good to go work is still in progress maybe in a future talk we might be able to demonstrate it so just to summarize because some of you might be a little bit frustrated our idea is if you are a good software and a good system hacker don't be afraid of embedded and hardware because here hardware is just basically a computer a normal computer with some specificities because the operating system is a bit different you have a bit of constraint but it's basically a computer which you can hack using the old techniques you've been learning for 10 years so thank you for attending our call talk sorry and if you have any question you're welcome are there any questions? are these disclosed to manufacturer as far as we know yes they should be so it disclosed to the manufacturer but if you remember the problem of OEM the manufacturer don't necessarily have the capability to patch the firmware themselves so they might have to go to their OEM provider ask them to fix the problem get a build get it and push it to the cars in operation which might be a problem because you might have maybe one or two millions of cars with vulnerable systems if anybody has any questions later we will be around thank you everybody and see you around bye