CAR HACKING VILLAGE - Flash Bootloaders Exposing Automotive ECU updates

Video thumbnail (Frame 0) Video thumbnail (Frame 15053) Video thumbnail (Frame 29791) Video thumbnail (Frame 30983) Video thumbnail (Frame 32618) Video thumbnail (Frame 36658) Video thumbnail (Frame 39507) Video thumbnail (Frame 40519) Video thumbnail (Frame 46722)
Video in TIB AV-Portal: CAR HACKING VILLAGE - Flash Bootloaders Exposing Automotive ECU updates

Formal Metadata

CAR HACKING VILLAGE - Flash Bootloaders Exposing Automotive ECU updates
Title of Series
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Release Date

Content Metadata

Subject Area
Unified Diagnostic Services (UDS) provides a powerful interface into vehicle diagnostics. OEMs use these services to update firmware, manipulate calibration data, send and receive information from vehicle ECUs, and now more recently for over the air updates. This talk pulls back the curtain on automotive bootloaders and how poor security design or implementation choices can be used by attackers to exfiltrate firmware or even gain persistent code execution.
Group action Serial port Length Code Multiplication sign Coroutine Client (computing) Computer programming Non-volatile memory Mathematics Bus (computing) Flag Determinant Information security Algorithm Software engineering Block (periodic table) Staff (military) Schlüsselverteilung Sequence Flow separation Connected space Type theory Message passing Process (computing) Vector space Normal (geometry) Right angle Reverse engineering Game controller Server (computing) Service (economics) Identifiability Flash memory Number Latent heat Energy level Software testing Booting Hydraulic jump Address space Fingerprint Default (computer science) Dependent and independent variables Information Consistency Plastikkarte Cartesian coordinate system Interprozesskommunikation Software Logic Communications protocol Buffer overflow Software protection dongle Computer worm
Code INTEGRAL Ferry Corsten Multiplication sign Decision theory Modal logic Range (statistics) Coroutine Water vapor Parameter (computer programming) Mereology Computer programming Non-volatile memory Front and back ends Medical imaging Sign (mathematics) Formal verification Bus (computing) Encryption Symmetric-key algorithm Information security Algorithm Sequence Message passing Vector space Normal (geometry) output Right angle Writing Reading (process) Reverse engineering Game controller Service (economics) Flash memory Heat transfer Rule of inference Normal operator 2 (number) Power (physics) Product (business) Revision control Latent heat Goodness of fit Natural number Intrusion detection system Software testing Firmware Booting Address space Metropolitan area network Default (computer science) Scaling (geometry) Key (cryptography) Information Validity (statistics) Content (media) Volume (thermodynamics) Trojanisches Pferd <Informatik> Cartesian coordinate system Interprozesskommunikation Word Point cloud Communications protocol Buffer overflow
Code Boom (sailing) Computer programming Software bug Revision control Malware Term (mathematics) Internetworking Different (Kate Ryan album) Computer network Software testing Software framework Endliche Modelltheorie Information security Physical system Key (cryptography) Information Projective plane Volume (thermodynamics) Bit Connected space Type theory Software Vector space Repository (publishing) Point cloud Right angle Remote procedure call Window
Authentication Key (cryptography) Code INTEGRAL Multiplication sign Projective plane Numbering scheme Fault-tolerant system Mereology Electronic signature Type theory Message passing Sign (mathematics) Different (Kate Ryan album) Chain Computer hardware Right angle Firmware Booting Information security Physical system Vulnerability (computing)
Polar coordinate system Randomization Group action Building Server (computing) Random number generation Service (economics) Code Variety (linguistics) Multiplication sign Patch (Unix) Real-time operating system Open set Coprocessor Latent heat Goodness of fit Peripheral Different (Kate Ryan album) Computer hardware Encryption Entropie <Informationstheorie> Energy level Extension (kinesiology) Booting Information security Symmetric matrix Authentication Time zone Standard deviation Arm Inheritance (object-oriented programming) Key (cryptography) Information Data storage device Cryptography Interprozesskommunikation Public-key cryptography Exploit (computer security) Message passing Software Integrated development environment Reflektor <Informatik> Right angle Remote procedure call Communications protocol
welcome thank you for spending your time and skipping the lost testimony that come see me makes me feel great so I'm here to talk about automotive boot loaders so I guess first of all a little
bit about Who I am I'm Phil at chin ski so it's it's lap with all the consonants and then ski I'm a software engineer a senior staff engineer at a Renaissance and we make chips and all kinds of things so what am I here to talk about embedded boot loaders in automotive so what does boot loader do essentially it owns the reset vector in the microcontroller and on reset the bootloader is going to determine if your application is valid or not if it's valid it allows you to load the application in a big system on a chip it might it might copy that over into RAM and execute it for embedded devices though it typically will just jump to the start vector of your application also in like deeply embedded devices the bootloader usually allows you to reprogram the memory the flash in the micro so I guess all you guys see the mouse so here you have the the brew letter vector jumping to the bootloader it's gonna do some stuff determine if it's you have a valid application or not and then jump to the application vector so we've got these in the car we know that they're in there how do we talk to them well it makes we make it easy in automotive we have a proprietary connector for our obd and you have to get special dongles like the car hacking village dongle so everybody go buy one of those they're 80 bucks but that allows us to connect to the can bus so that's defined by ISO protocol released in 86 but it's 2008 become mandatory so we know that any vehicle after 2008 it's in there we can talk to it and so that's the physical layer connect it through the obd2 dongle to start talking to these things so can only a bite payloads that doesn't give us a lot of information some small commands but we can't send like large amounts of data so I know so we got the transport layer 15 765 that's the underlying transport layer that sits on top of kin and between can and the diagnostic layer so this basically allows us to send payloads up to 4k by segmenting the messages so on top of that we're just gonna make layers and layers and layers of protocols to make it confusing we've got ISO 14 to 29 that's unified diagnostic services so this is a ISOs pack that basically defines a whole bunch of common services essentially creating the API it's a client server so you send it a request with your client and the server running on the ECU will send the response essentially this this spec defines all of the different standard services there can be also OEM or supplier specific services as well when there's also security levels so there's different sessions to get elevated privileges for boot loaders we're typically talking about the programming session ISO define session 2 as the programming session so if you send a session control change request to go into the programming session now you go into the bootloader so this is where things get interesting and I guess before I jump to that let me explain on an embedded device in automotive the bootloader is typically a whole separate executable program that's separately compiled from the application so there's some kind of inter process communication that happens between like your normal application and the bootloader when you're sending passing the information through so that's usually done through like a reset so you might get a programming like a session control request and it'll set some flags and then cause a reset and then the bootloader says oh hey I'm in programming session let's go do something interesting so what does this look like the typical programming sequence it's it's broken up into three distinct kind of groups there's this pre programming sequence which happens before you program there's the programming sequence which is when you're doing the programming these are really easily named and then the post programming see you and switch I bet you guys can guess it's after you program alright so pre programming what happens here this is like usually OEM specific well really what you're doing but in the I suspect there's there's common things that typically happen oftentimes you'll do a session control and jump into this the extended session so that's session 3 in the extended diagnostic session gives you like elevated services than your normal diagnostic default session that would be like you're driving around in the car so what you do is you go into the extended session and you start doing things that are going to prepare the vehicle for programming so one of the common things is to turn off DTC's because so i'm gonna like change my you know the software my application software on the car and all these other users are still talking to each other or they're looking for messages so if I have a ECU that's down not you know sending its messages everybody else that relies on my messages is gonna say what the hell's going on it'll start setting DTC's it'll you know it doesn't going on so typically when the diagnostic tester is going to initiate a programming session it's it turns off all the DTC's it might turn off disable the non-diagnostic communication and so say okay everybody be quiet on the bus because I want to start reprogramming ECU's um this may or may not require security access to get into this session again this is all only AM specific and the OEM specs are all secretly guarded and under NDA and there's a bunch of omean people here that they weren't they don't let me tell the secrets so there's the programming step and this is this is when you basically activate the bootloader and unlock it UDS defines a security C key exchange so service 27 and you basically that the tester will say hey go give me a seed sends the seed back and then the tester will send the response it's the challenge response protocol but again the way this is programmed the actual algorithm is not defined by ISO that's defined specifically by the OEM one thing to note you know again the industry is continually trying to strive for it's better security but historically OMS didn't always do a great job with their security algorithms it might be a secret algorithm that's you know some engineer made up one day and the secrecy of it is because it's hidden in a desk somewhere but lots of smart reverse engineers out there that can figure things like that out so historically this is that that's been a problem of the industry is working towards better types of security there and also other things like better entropy on the seeds that's another problem anyway so you unlock this thing service twenty seven there may be some right data by identifier service where you write like a fingerprint or some specific information so this is typically like the tester might do like right the programming date into the ECU like the last time I did it or right it's like serial number so like the test or serial number into and say hey this was flashed by you know Ben's serial number one two three four very professional so then what it'll do is uh again this is a lot of this stuff is it's defined by a so but exactly how it's done is only I'm specific so some some OMS will have a secondary bootloader that you download and typically what's in that is like the actual flash routines so residing in these two normally they're not in there so you can't like just you know gain do like some buffer overflow and and get into there and write rewrite the ECU because the the code for that's not even in there the the flash drivers are actually downloaded by the tester and they're set up specifically for that you see you so if you download that and then you activate that and so that that enables now be programming routines so the next thing that happens then is we're gonna get into this so once we've activated the bootloader we're gonna get into this download step and the way that looks is you have a request download so service 34 which says you send basically your address and the length and there's different types of addressing like some Williams will have like actual address based addressing some have what's called like logical blocks where you give it the logical block identifier again it's
all of the stuff is proprietary then you have the service 36 which is the transfer data so you're sending this and you can send basically you know four K at a time until you have all of your data there once that's happened you do a transfer data exit and so this is typically where you do something like a checksum or do an integrity check of all of this data before activating it so there may be like a routine control after that it says hey do this check routine and you know check the checksum on it that's the the this basic least secure way is just doing the checksum you know it varies wildly it's all specific and proprietary so a lot of times this could be also where you do like the code signing check verification but really that could be done in the transfer data exit or it could be done with a special routine it's it's all up to an OEM to decide how to do that in their specifications so okay all the data's got there we sent it to the ECU we verified that the data is good it's it's good to go it looks authentic ish now what happens the tester will say okay go back into the Diagnostics or the extended session we start getting it ready for the post programming so you turn the DTC's back on because now your application is all working right and you can turn the normal diagnostic communication non-diagnostic communications on and then you usually do like a session control to the default session and so this usually happens through like a reset so the bootloader says okay we're done we reset and you jump back into the application so okay now that you have like the most basic understanding of how ECU boot loaders or automotive boot loaders work how are these used potentially as an attack vector well there's lots of things that it can do it's a very powerful it's its own application and so just by what it does its normal operation it necessity like by necessity has to do things like well it prevents the application from running because it's its own application so if you can say hey go into the blue letter well now the application is not working and why would you want to turn the application off well what if you're trying to like spoof messages if you're spoofing messages on the bus and the ECU is also sending out its valid messages well now you're you have this contention or confliction if you like to make up words the so if you have this you know now you can turn this ECU off and you can send its messages and spoof the messages most automotives right now are not using like can is not by the protocol itself is not sending authenticated messages it's a bus protocol so if I send messages with this ID with the signal I can now you know that you see yous that are listening to us can can now have to listen to it if it's if you're on the same bus and all this other things so turn the ECU off and send your own messages and spoof those it's also it is a reset the decision maker right it's deciding is this application valid or not and meaning you could also say if you can make it so that it thinks the application is not valid well now it's not going to run that application you're permanently disabled or if you can somehow subvert the validity checks now you can execute non signed code or you can execute whatever you want right it also by Nature has ways to input data or export data you know exfiltrated at a-- so some OEMs implement request upload part of the iso spec it's it's available the general practice is is not to do that because then you could just send requests to pull all the code out of there your firmware but it's some Williams do it or the supplier implements it for whatever reason um by the nature of the rule or you can write data to it request download that's you know if you can write something into RAM then maybe you can execute it like a couple slides back we've got this programming step where you're downloading a flash driver so that's basically downloaded and run out of RAM you can read interesting data right there's the service 20 to read data by ID so if you have IDs we can read certain things out of there that might be interesting and getting things out of it again it might have because it's so its own separate application it's a different session there may be different did available than what are in the application so there's more or at least different information sometimes out of the blue water you'll be able to read a specific spot in memory there's a service 23 read memory by address and again these are all like these are just the ISO services that are defined right it's you know you can look them up online right specific parameter data so right data by ID that's available right memory by address that's you know that's a service so usually there's range checking and stuff in there if it's done implemented correctly but again there's you know there's a lot of powerful things available if you can get around you know security there another tack vector is Man on the middle of the programming sequence so if you have a valid test or even without knowledge of you know the the security or anything like that you Mable to record the programming sequence you may be able to replay certain parts of it you could potentially intercept firmware over the wire because lots of volumes don't like encrypt the data once it gets to the canvas it might be encrypted at rest it might be encrypted in the cloud when they pull it down but the the ECU doesn't have like the symmetric keys in it - like decrypt the firmware so it's usually just transmitted over you know unencrypted again.this it's all only in specific and people are moving towards encrypted firmware of course but you know that could be with a valid test or that could be easier than you know trying to get JTAG on a device and and pull firmware right if you can just snoop it off the bus again I mentioned this before replay attacks on certain sequences so if it's if the testers validly doing something interesting maybe you can record that in can and then replay it and how would you do something like that well or I'll get to that second also by nature of what the tools have to do right the the programming tool is going to have the images right you have to flash these images to the ECU so if the tool itself is not well protected that may be like an easier attack vector than trying to like you know get a buffer overflow and a boot loader or trying to get JTAG or somehow like taking this you know pulling the firmware off the ECU because the programming tool itself needs to have the firmware because it's sending it to the ECU you can also get information about the proprietary programming sequences and things like that because you know unless you have specs from an OEM or you know have access to this stuff it's all highly secretly guarded right also any time you know it's using any kind of like symmetric keys like if it's the C key algorithm is not authenticated all the way to like a back end the tool itself you know may have the symmetric keys for C key so instead of trying to reverse engineer this firmware or you know hack into an HSM I you see you the programming tool might just have all the algorithms in it another thing that's awesome about UTS is that so that his seed keys design is basically it's like a you know it's like a blind Butler like the you do the secret knock and he opens the door and then anybody can go in so once you've you know once you've unlocked the EC or gotten into that session then you can just kind of keep that session alive from a valid tester and then send whatever messages you want so kind of snooping a valid session you could hijack that and send kind of other things and so having access to these testers or if you're on the bus at the same time it's kind of you have lots of access there other attack vectors a Bluewater trojan so you know there's ways to even gain persistence on an ECU by downloading a bootloader that overwrites the
bootloader right there's products that do this for updating boot loaders and essentially you program an application into the as the the new application has to look like a valid application and then it just overrides your bootloader with its own blue letter you might lose your keys you might you know now you gain permanent persistence on the ECU so what makes this even more scary so before for all of this you had to have physical access to the vehicle right so it doesn't scale well I can't physically walk to a thousand or a million different vehicles and start changing the firmware on them but don't worry everyone solved this problem
because now everyone wants to add over-the-air programming so many volumes are incorporating this implementing is just like a diagnostic tester that's connected to the Internet right so depending on how secure that is that can put in a lot of challenges right ?t is awesome it's great for fixing bugs we can add features we can do security updates it's helps facilitate you know rolling out recalls like fixing recalls and stuff because you can push these things out quickly but OTA basically is remote code execution and generally that's bad in terms of a security model so it's like it's it's the savior but it's also the thing that can really hurt us it's kind of a two-edged sword and it opens up some interesting challenges that we might not have had before so attacks on like repositories itself there's you
know DEFCON is huge right there's all kinds of fun talks going on I'm sure somebody maybe this year or certainly on previous years have talked about like repository attacks on updaters like for oh boom - and you know Windows Update and all that same thing with with automotive right if we're doing OTA updates its opening up attack vectors for our you know actual trading code signing keys you know repository poisoning things like that also there's some challenges in keeping OTA and going because the car has intermittent connectivity you know if it's parked in a garage it doesn't might not have access for who knows right or somebody might park this car in a garage for 20 years and then turn it on and now you have you know 6 million software updates you can't drive your car for three weeks because it's downloading and then like man-in-the-middle type of tax to the vehicle you know it's it's a it's literally a moving network computer network so it's it's a really challenging IT problem to maintain this kind of infrastructure and the securing all of that so there's a lot of new challenges that could prevent updates or past bad information to the cloud or to the vehicle and so it kind of it's pushing you know OEMs to have to really think about the full end-to-end lifecycle for updates oh yeah in cars move so if you break your phone usually that's you know that's a bummer but if you brick somebody's car and they're in the middle of I don't know the desert they're not going to be particularly happy there's also all kinds of like OTA attacks there's a so there's projects called obtain that's doing like a security model framework for OTA attacks and they've kind of enumerated a whole bunch of different things like malicious software attacks you know updating trying to poison the cache with bad to update its freezy tax where you're stopping the basically stopping the updates from having by slowing it down or maybe you have like bad vulnerable software trying to get the ECU to roll it back to a bad version it is a lot of challenges and lots of ways to like toss the system so it's it's quite a bit big challenge so now that it bummed
everybody out or maybe made them excited because maybe they're trying to hack cars this is the kuraki village right what's the industry trying to do to make it more secure and for people that don't care about that that also means what might not be implemented right now things like code signing right where I take a message digest signing it with private key pending that to the data and then verifying it on the ECU side so this is one of the like I mentioned that obtained project this is one of the things that that project is really trying to like set up delegations for how you make a signature scheme for automotive really fault tolerant against different types of attacks so a lot of work being done there secure boot push and secure boot you know so this is like building a chain of trust to ensure the authenticity and integrity of code at startup Smalley's use that have just like a like a she module which is like a small HSM you know these might have like a really simple secure boot but if you get into like the systems on a chip that there's the main main lang talked I think yesterday about the Qualcomm firmware and he showed like the the Qualcomm firmware secure boot chain and it was like it was like 45 different things so each one of these might have like could have a vulnerability right and you have to try to protect that whole thing so these can get really complicated and really really tricky and also who owns the keys for a secure chain is it becomes really complicated because it could be in automotive we have this big huge supply chain and different stakeholders might need to own different parts of it so I
can only a my one on some things but the original equipment like tier 1 supplier might also you know need a stake in it so it's like these things can be really complicated in they're hard to they're tricky to really secure but we're working on it another big thing like this is you know what what uh I work on all the time hardware security modules so this is like hardware acceleration to help facilitate some of these things so like I mentioned before you know you've got the seed key so off one of the big problems with that is like really really
poor entropy on your seeds so somebody might just implement because we don't have like there's no like real-time clock there's no you know good timers you don't have a good source of entropy on these ECU's so you know people wouldn't like this like super awesome proprietary random Joe Moore generator and you know it throws out four different random numbers or something so it's really easy to replay these seeds so hardware facilitated true random number generation that really helps with certain things like that protected key storage AES hardware acceleration for symmetric crypto or other symmetric crypto accelerators having public key crypto accelerators in there again you know the idea is to protect all the keys and also try to help accelerate some of these things so that we can do enable things like real time authentication and encryption and message authentication and things like that there's also things to like enable secure boot in hardware one of the challenging things with this though is that there's not like a one speck to rule them all in automotive so a lot of stuff is using like TPMS for you know like IOT or pcs and you know traditional IT in automotive there's this like baseline specification from the this is like the hilarious German pun here they called it the hiss she so there's a hiss is like the her stellar initiative software it's like a consortia of like a bunch of German suppliers and OEMs and they created this she spec which is a secure Hardware extension I mean it just defined like certain things in hardware that that would that they specified for security and it's it's kind of like a standalone peripheral and so a lot of silicon vendors have implemented that and have have support for that but uh OMS are you know moving even beyond that a lot of people need more keys or they need you know more specific stuff like a secure execution environment there's a there's a another there was another a few years later group in Europe called the Vita it was like a government you sponsored consortia and they came up with like another spec that kind of divided it up into like three different levels so this low medium full evita spec and so this like the highest one you know has a secure code execution and coprocessor and everything like that so again soken vendors are like implementing stuff like that like we have one called ICM for that but other other silicon vendors like NXP has the CSC which is the cryptographic services engine and Finian's got their own stuff arm has the trust zone and you know there's there's been a bunch of talks on trust on hacking stuff so if you're interested in that there's lots information and trusts own stuff so it's it's a it's kind of a big challenge because because there are so many different varieties and there's no like just common you know API for okay here's the automotive API and spec for building this the secure hardware as a chip vendor so every OEM kind of just has their own their own flavor of how it works so again this is challenge but there's also you know committees that are working on kind of creating more common specs there's a SAE group for that and there's also a ISO group that's working on kind of like common security practices some more stuff so you see hardening this is just like general security good hygiene stuff but you know you'd be surprised how often this doesn't happen and most of the OEMs have
specs now that say like yeah you have to lock the JTAG or you know tamper protection things like if the tamper protection is detected it erases your keys of the HSM so even if somebody gains access they can't get the keys out or can't use the you know can't use the thing again good crypto hygiene don't use the same key across all of your cars like some OEMs have done but that you know this hardware stuff basically helps enable some of the higher level protocol level kind of security like doing authenticated can so there's a thing called AUTOSAR which is like a software and it's open standard it's offering Asia tip or something like I've had I'm forgetting what it stands for I should know that yeah but anyway it defines like a protocol for doing secure authenticated communication on can and also authenticating Diagnostics so there's not any kind of specification for this right now but OEMs this is all OEM proprietary stuff but you know what the industry is working on basically is enabling you know much better authentication for Diagnostics so instead of like having a tool that has all the symmetric key keys in it and you know being able to have access there you have to go out to like an actual server and it sends you know some signed piece of information that you can verify with a public key so I'm going to do it on time so on summary here boot loaders give you powerful access to automotive ECU's we started adding OTA to these things and it's making everyone's lives really difficult but it's keeping us all employed so that's good right yeah it really opens up the attack service for remote exploitation that's making a it's the enabler to be able to do updates and to push security patches and things like that but it makes make stuff extremely difficult I think automotive vehicles is one of the most difficult things to do OTA on because it's this big thing that's moving that could smash into something and then of course you know we're working on this where we're gonna securing the ECU's but are we're doing it fast enough are we ever there yet I mean of course the answer is no we're still working on still working on that it's it's improving all incrementally of course so thank you I really appreciate you guys taking your time to you know lose your happy hour drink prices and sit here and watch and listen to me so [Applause]