 My talk is about flashing ECU firmware updates from a web browser. More specifically, I did some reverse engineering of the HONDA firmware update file format that they put out. So that's what I'm really talking about. So who am I? My name is Greg Hogan. You can follow me on Twitter. All the source code for the software that I'm going to show you is open source. You can find it in one or more of my GitHub repositories. And I work at comma AI on infrastructure, which, yes, if you're wondering, that has nothing to do with car hacking. So a couple of days ago, I got an email and it said defcon 27 talk. And I thought, oh, this is information on like my speaking gig here. I open up the email and no, it is from HONDA. So apparently they were interested in my talk and I'll summarize this for you. It basically says, don't do something that might kill somebody. That was never my intention. I won't be, for some reason, they thought that I was probably going to be releasing specific modifications about making firmware modifications to power steering controllers of HONDA vehicles. That's not the case. I never planned on talking about anything like that. So that doesn't change anything that I'm going to be talking about. Also, this is a completely legitimate thing to ask of someone to make sure you don't do something that could injure somebody. And I agree completely that trying to make changes to your electronic power steering firmware of your car could be very dangerous. If you screw something up, the best case might be that the steering wheel tries to break your arms. And the worst case is it'll flip over your car and kill you. So please don't do anything stupid. And I have no intention of enabling you to be able to do such things. What got me interested in flashing ECU firmware updates? So in 2017, George Hotz, he's actually the guy that started the company that I work for, he gave a talk at Code Blue at a conference where he kind of showed some information about how you can get these firmware updates from different vehicle manufacturers. And I looked at these tools that he was showing and I thought, wow, that software is garbage. It looks like it runs on Windows XP, and why hasn't anyone created anything better? So that's kind of what I set out to do. And I guess to do that, to enable that in a modern web development stack, that's why I decided to see if I could make this work where I could flash ECUs from web browsers. That's basically, what I'm going to show you how to do is basically similar to what, there's a whole community of people who go out there and they make changes to do engine tuning for their ECUs, change like gas fuel mixtures and stuff like that. They've basically done what I'm going to show you. They've figured out how the firmware updates work in what I'm going to show you here, Honda vehicles, and then they figure out how to flash their own firmware updates, essentially, without using the Honda software to do so that they distribute. So how do you get the software and firmware updates for these vehicles? So thanks to write to repair, vehicle manufacturers are basically required to provide at a reasonable cost the firmware updates for the tools basically that enable any maintenance shop to be able to do repair work so that you're not like locked into going to a Honda dealership and then like charging you an arm and a leg to do this kind of stuff. So anyone can sign up for these websites. Honda is really cheap, $10 for one day to download the software that they provide to their repair shops and anyone who's like a repair shop that repairs Honda vehicles. They'll subscribe to this also. If you subscribe for one day, interestingly, you actually get three days. So Toyota is a little more expensive and you know, there's other vehicle manufacturers, well, I guess just one that does like over-the-air updates and you don't have, you know, if you have the right access to your car, the firmware updates are actually pushed to your vehicle so you don't have to like pay to get them. So I signed up and I downloaded the software and I wish I could get that four hours of my life back that it took to install it. It's horrible just like from a UI perspective, usability perspective. It's not great software. The authentication is over HTTP. Like nobody's proud of themselves for like working on the software. I don't think this is the new version. This is new for like, I think like 2017 model year vehicles or something like that. The old version looked even sadder. It's called HDS for Honda. It's Honda Diagnostic System. In 2017 when this new version came out, they threw an I in the front of it. My guess is they're like trying to ride the Apple train, you know, a bandwagon or something like iOS and so forth. But using the software is nothing like using an Apple product. You also need a piece of hardware to interface with the car through the ODB2 port. So that hardware, there's, if you go to the Honda website, there's one like certified hardware package that you can buy. And it is almost $1,500. That's sad because like it just does like stuff that follows specifications that are open, you know, that anyone can implement because of right to repair basically. So one of those boxes on like that first window was something called the J2534 rewrite tool. So what is that thing? That's the software that actually does the firmware updates that actually flashes your ECUs. So the company I work for, they actually make an ODB2 dongle that has a USB port called a Panda. And it's a lot cheaper than the $1,500 product that Honda sells. It has an open source J2534 driver, which is basically the API that like the whatever for like emissions testing and so forth, they defined it so that, you know, to enable right to repair essentially. And the driver, like it's not perfect, but it at least works for CAN. And so I decided to go down this path since it's so much more cost effective and the Panda has a great Python library for interacting with your vehicle over the ODB2 port. And someone wrote a web USB driver for it. So I'll get into that a little bit more, but that's a big part of what enables me being able to flash an ECU from a web browser. So that four hours that I spent installing this software on a really fast machine, another thing that it drops alongside this executable is the actual firmware updates. So that's how you get the actual firmware update files. And they're in this folder here that I listed the button. So, okay, now we've got a flashing tool and we've got firmware updates. So now what we want to do is we want to reverse engineer, you know, whatever the process is so that I can replicate it and build my own software that actually does this. So the first thing that I found was this software called J2534 Logger. Basically what that does is it acts as a proxy to a real J2534 driver. The J2534 spec, so part of the reason that this software, I did guess I didn't mention this, this Honda software, it only runs on Windows. And the reason that it only runs on Windows is because the J2534 API specifies things like, use these registry keys to find a DLL and load it. So that's another reason that I was interested in creating my own software that flashes this because if you break out of that, you can make something that's like cross-platform that runs on a web browser, which would be cool. So basically you can fire up that J2534 rewrite tool that Honda puts out and fire up this, install this logger. And if you have a vehicle that has an ECU that has an update, you can apply it yourself with this software and you can record it. And it'll dump out this big log file that has all the J2534 API calls, as well as the raw data that was sent and received back and forth. So then to dig deeper into what the actual steps are that happen when you flash a Honda ECU firmware update, we need to start understanding some of these other specs, UDS, Unified Dynamics, that's like a big one. It has all the commands that J2534 uses to actually communicate with the ECU, make it through security access, key exchange and all these things, and send the firmware. The next layer down is ISOTP. I'm basically just mentioning these things because this is what I have to implement if I'm going to implement my own in a web browser because as far as I know, no one has written one in JavaScript. Alright, so after recording flashing an ECU from that J2534 rewrite tool that Honda distributes, here's what you come up with. It's basically more or less an eight-step process here. The first thing that you have to do is you have to... These are all the names on the right are the UDS message types essentially that you have to send to communicate with your car. So basically you need to send a session control message because you can't request a security access seed until you've gotten into that specific diagnostic session mode. Once you get there, you can request a seed. You'll then see the seed go back to the software. Software then does manipulation to that seed, sends back a key, and that key is what allows you to do the next step, which is enter a programming session. So this is what we want to get to, right? We want to get the ECU to the state where we can actually send and change the firmware on it. Then things get dangerous. From a, oh crap, I might brick my ECU perspective because the next thing that you do is you erase the memory that you want to write. After you erase it, you have to send this message that turns out what it is is you're sending it some keys that go to the firmware so that it can decrypt the firmware that you're going to send it. So it turns out that these Honda firmware update files, the firmware portion of the file, they actually encrypt it. And the J2534 rewrite tool, it doesn't decrypt it. It sends it to the ECU, and then the ECU decrypts it. So they haven't distributed, per se, any software that you can obtain that actually has the decryption algorithm in it. It's all in the ECU. Then you proceed to send the firmware. And then at the very end, you send a message that performs this validation, which I believe what it does is validates that the checksums in the firmware are correct. The checksums in the Honda firmware are extremely poor. They're actually just the sum of all the bytes across a few sections. So I don't know, that's kind of crappy, a couple bit flips. You might not have what you thought you had there. All right. So this firmware update file, I mentioned earlier on that there's a folder that gets dropped that has all these firmware update files in it. And those firmware update files have a certain format that I'm now going to go through and explain what the different pieces are. Because my ultimate goal here is to create a website that I choose one of these firmware update files and I then flash it to an ECU as if I was that J2534 rewrite tool without any software written by Honda. So the very first byte of the file is what I call the signature. It basically tells you the format of the rest of the file. There's a few different formats. I'm just going to focus on one, because I only care about one, which is CAN. There's also other formats, I think, like you flash over Lynn or other protocols. But I'm just going to focus on CAN because that's probably like the future, at least for any vehicle that I'm going to own. So CAN is this hex 5A value. All right. So now the next section, after that first byte, now we're in the CAN specific format of the firmware update. And there's six header fields. They basically have everything that you need to be able to look at one of these firmware update files, determine if the car that you're plugged into has an ECU that a specific firmware update file applies to, and if it's running a version of firmware that is supported as an update, or if the file is an update for the version of the firmware that's on the ECU. So you only need a few things. You need the CAN address of the ECU that you want to know if you can update with the specific firmware file. So there's one byte that specifies it. The reason it's a single byte is because, like if you look at the spec, 29-bit addresses, there's only one significant byte. So they just have that one byte in there. And then there's a few different values. They can change these security access keys per firmware update file. So they put the actual keys in the firmware update file because you have to send them to the ECU. So when the ECU receives the firmware, it knows how to decrypt it. And then there's also a key that I'll get into in a minute here that is an input to the security access key exchange. So what you need to do to get that ECU into programming mode essentially. After the headers is the actual firmware. This is the encrypted firmware that I talked about before. There's a start address and a length. That sequence that I laid out, a couple of the steps were saying, okay, what section of firmware do I want to flash on the ECU and how much data am I now going to send? That's part of that UDS sequence of messages that you have to send to the ECU. The Honda ECUs I've looked at, they actually only allow you to flash one section of the firmware. They did a pretty good job in terms of making it kind of hard to brick the device because the boot loader is outside of the area that they allow you to flash, so that's good. But yeah, the state is encrypted, so we can't really look at the firmware at this point. And then at the end of the file is a checksum, and it's just the sum of all the bytes except the checksum itself. And so that's the entirety of one of these canned format Honda firmware update files. All right, the encryption. So I mentioned that this firmware is like the data section of the update file for the firmware is encrypted. So I thought, okay, well it'd be interesting to see if we can decrypt that. And the talk that I mentioned at the beginning that got me kind of interested in this, George's Code Blue talk, he shows one algorithm that they used for encryption. And I thought to myself, oh, okay, well, maybe I'm lucky. Maybe they used the same encryption for every one of these updates. Turns out that's not the case. But there's these keys that we already found in the headers of each firmware update file. So I've got the keys. I've got an example, so what should I try? Okay, well maybe they just changed the operators. It turns out at least somewhat common, that's the case, and it's not too hard to write a piece of software in Python that just brute force tries every combination of operators that results in a full 256-value lookup table, where every value is, you know, the input is unique to the output. So utilizing that, I wrote this piece of software that I linked to at the top there called RWDXray. And that, it does that, exactly. You give it a firmware update file and it will try to find, it'll try to find a set of operators based on the keys in the RWD file to be able to decrypt the firmware. Yeah, so that's really fast. Most of these firmware updates are small and yeah, it takes like seconds to run this through and find the appropriate operators for a lot of them. It doesn't seem to work on all of them, they actually use like a different algorithm for some firmware updates, but it seems like there's a number of them that they actually use the same basic algorithm with just different operators. So this is just an example of running that tool. It just kind of, it ties everything together that I just talked through. Basically, you know, parses the file, spits out the headers. The way that it figures out if it has successfully decrypted the firmware is that there's a UDS message that you can send to request the software version of an ECU, to get the firmware version of an ECU. That returns something that looks like a part number for Honda with an extra few numbers at the end. All of these RWD files have a name that looks like a part number. So, what I do is I take the beginning portion of the RWD file and I say every time I try a set of operators, do I find in the decrypted firmware a string that matches that? And normally there's just one. Down at the bottom there are all those dots, is it trying every possible set of operators that existed and the X means it hit and it actually found the string that it was looking for in this brute force way of going through the different possibilities of all the algorithms. And then it spits out the decrypted firmware into a file at the end. Okay, so, my goal here is to flash an ECU from a web browser and I now completely understand this firmware update file that Honda has, that Honda publishes that anyone can get a hold of. It has everything in it, I guess, except the actual Security Access Key Exchange algorithm. So, now I figured out everything I need to figure out to flash an ECU myself, write my own software that does it, but I don't know how to make it through the Security Access Key Exchange. Their Security Access Key Exchange is okay. It generates a random two byte number and then you have to manipulate it and send back the corresponding response that is the correct response after you manipulate it with the Security Access Key Exchange algorithm. But we don't know what that is. So, brute force would take a long time. It's probably actually maybe doable, but if you do it, you now figure it out for one ECU for potentially one single firmware revision of that ECU. So, what else would have this Security Access Key Exchange that I already have access to? Well, how about that J2534 reflash tool? Turns out it's pretty easy to find the Security Access Key Exchange algorithm in that tool. And it looks like, as far as I can tell, they basically use the same algorithm to a similarly simple algorithm, just addition, multiplication, and modulo. So, basically the same algorithm, there's just like one variation, whether the key that's in the file is four bytes or six bytes. And so, yeah, great. Now we found how to get through the Security Access Key Exchange for probably any Honda ECU, at least that is flashed over can, most likely. And I guess like, all the people that do the engine tuning, ECU tuning, I guess they all know this, I don't know. I guess it's easy to find though, so I guess it makes sense that they would. All right, so, I've got everything I want, or I need to know now to build this website. So, I created this website, it's open source. autoecu.io is the URL. It's the autoecu GitHub repository that I have. It's open source. It only supports this Panda ODB2 dongle that I'm using here, because I don't know any other ODB2 dongle that supports the web USB driver that Chrome has so that you can interact with a USB device directly from a web browser. This website is just static content. You don't need an internet connection to use it. There's no API. You can totally just pull down the GitHub repo and run it locally. But for convenience, I just threw it up on autoecu.io. There are some problems, it's not perfect. This isn't like productionized code, so don't use it on something that you're not willing to replace if you end up bricking your ECU. I actually opened a Chrome issue because in their effort to curb people doing crypto mining in your web browsers like through ads and so forth, they don't let tabs that are in the background or don't have focus keep executing code indefinitely or maybe they only give it small time slices or something. For example, when you use this, you really want to keep the browser focused because you switch tabs and then basically the flashing process pauses. You really don't want that to happen in the middle. Generally, it's okay. If you cancel flashing one of these ECUs in the middle, you've potentially erased the ECU, but since the bootloader is at the beginning, if you haven't done anything really dumb and if you're not really unlucky, you can just cycle the power and start over and flash again. It's definitely possible that you'll brick an ECU if you use this. I have a little video here. I have a 2017 Honda CR-V. It has ECU updates for several ECUs. I'll just play this here. See if I can make it full screen here. If you watch the dash really close, things look pretty good right now. It looks normal. I'm picking the firmware file right now. It does a little validation. I'm going to start the flashing process here. Then, holy shit, every error code possible pops up on the dash. I don't know if I missed something. Maybe there's some way to prevent that from happening. It's kind of scary. I tested this on a bench before. I actually had bugs in my code. For example, when you plug into one ECU sitting on a bench, there's no other ECUs on the CAN bus. You can make a mistake where your software assumes, accidentally, that every message that's coming is intended for your software. The ECUs are throwing out messages all over the place all the time. It's easy to fix. Now, it works better. This successfully flashes the ECU. It looks like it's flashing right now. I'm actually applying the firmware. I think this is applying the radar, firmware update for my car, or something like that. I just took the RWD file. Honda names these firmware update files, but .RWD is the extension. I just took that, selected it in the software that I'll show you a live demo here in a minute, of an ECU on a bench, and picked it and flashed it. Then I just power-cycled the car, and all the errors went away. It's great. It worked. Thanks. That was fun. These ECU engine tuner guys, they don't just flash the updates that they get from Honda. They reverse engineered this, and they generate their own updates. Wouldn't that be more fun if we could figure out how to generate an update maybe for an ECU that doesn't even have an update, and then flash that. You don't need a whole lot of information. You just need whatever is in that RWD file. You can just make up some keys. You do have to be able to figure out how to get a firmware off of an ECU maybe, or you could start with one of those RWD files if you wanted to, just to play around with generating your own. But you've got to be able to get the firmware. You have to be able to encrypt it, since it's encrypted in these RWD update files. This is actually a pretty good format for updating an ECU, because it's a self-contained file, and it has everything in it you need to be able to flash an ECU, validate that the ECU that you're going to flash is running an expected version of firmware before you flash it, and so forth. In my RWD X-ray repo, there is a script that does just that. If you supply an encrypted firmware file like what you would find in one of the RWD files in the firmware section, and the appropriate headers, then it'll kick out for you an RWD file that you can flash using my website. All right, so let's do that. I have, just because out of convenience, I have an ECU here that I tore apart to play around with, and you can get, for example, a lot of ECUs on, you know, like LKQ online for really cheap. This is specifically an ECU for the electronic power steering for my 2017 Honda CR-V. I'm just using it because, like, that's what I have out of convenience. So let's do it. So yeah, so basically I just, I figured out how to extract the firmware from this ECU. I used that RWD builder to, what I did was just build, you know, for proof of concept. It does nothing. It literally just is the original firmware on the ECU. So that's what we're going to do. So this is, this is my web, oh, sorry. This is my website, autoecu.io, and right now it has a dropdown for manufacturer. Honda is the only manufacturer that is supported, but, you know, it's open source. If someone's interested, they could, you know, definitely add formats of other firmware update files distributed by other car manufacturers. I've looked a little bit at, like, Tesla's firmware update file format, and it's, like, so much simpler than the Honda, for example. It just has, like, I think it has, like, a header that says the start address and the length, and then it's just the firmware, just, you know, non-encrypted or anything. So you could definitely expand this, you know, if you wanted to. The other thing, too, is, like, you know, like I mentioned at the beginning, that Honda Diagnostics software that you can use and slow and a pain to install, you can do all kinds of cool stuff with this, too, right? Like, one of the great things about the Honda software is, like, you can get deep introspection into, if you get, like, check engine lights and so forth, what those things, you know, what are those check engine lights and being able to clear them and so forth. So, like, you could easily, you know, take this and, for example, build your own HDS that enabled you to, you know, more easily maybe check engine codes from a web browser. So there's all kinds of cool stuff you can do with this. So let me power this, it's powered on here. I don't know if anyone can really see this here, sorry, we didn't get a table. So this chair here is my, what's that? Oh, hey, I got a table. Let me go grab the table quick, thanks. All right, so this, maybe this setup deserves a little more explanation here. So this doesn't really look like electronic power steering because it's, like, all tore apart and, like, the controller in this situation is not separate from the motor, like they actually put the controller in the motor. So that's why it's, like, all tore apart and weird. I'm using one of those Panda OBD2 dongles that, comma, AI sells. And the red thing plugged in is just so that I have a long USB, a long enough USB cord that's called a panda paw. It's just in case, like, you brick your OBD2 dongle, you can actually, you actually can't really brick it because you can use this panda paw to get it into DFU boot mode. So that's plugged into another thing that we sell, which you don't need by any means at all. It's just like a development board that breaks out the OBD2 pins really conveniently. So I just use that to build an adapter to go from the ECU, from, like, the real ECU connector to the Panda and an OBD2 connector, so, or device. So, yeah. So, all right. Let's pull up. This is my fake firmware update that is just, like, the stock firmware that I generated a file for because there is no firmware update for this ECU. I pick that firmware update file and I say next. Now, this is where those headers that are in the RWD file come into play. It just went out and so I implemented that UDS protocol and the ISOTP I implemented in JavaScript. You can see it in one of my, in the GitHub repo for this for this website. So, like, it just went off and it just queried that can address 18DA30F1 and I think it might have sent, like, Tester present or something like that. Oh, no, I'm sorry. It didn't send that off yet. We still have to connect to the ECU. So, the way Web USB works for, like, security reasons is if you have a device that implements the Web USB protocol, when you plug it into your computer it doesn't just, like, get access to things. So, Chrome has this specification where there's a JavaScript call you can make to say, go, you know, go talk to this USB device and then it prompts the user to actually say, yes, you're allowed to talk to this USB device from a Web browser. So, I pick it. I say connect. Okay, now, now it actually went out and it actually, like, sent, like, Tester present to the ECU and said, like, are you there? Are you awake? And then there's another UDS message called, like, read memory by address. I think it's read memory by address and there's a specific code that's defined that there's, like, four of them that are, like, bootloader version, software version, application version. So, I think it's software version. It goes off and it queries the software version and it checks, does the software version that the ECU returned match what my RWD headers excuse me, what my RWD headers say are the supported software versions for this firmware update file. All right, so now we're connected. Next. Okay, this is the danger screen. Like I said, you can brick an ECU so don't do this with an ECU that you're not willing to pay to replace. Something could go wrong. I say, I agree and flash. It's erasing the memory and now it's flashing the firmware so it's basically just going through that sequence that I laid out at the very beginning to actually send the firmware update so you can, you can't really see the progress bar there really well but it's like 25% and moving along LEDs are, like, flashing different colors on the table over here. Um, yeah so, I don't know once you have this, I guess flashing a firmware update is pretty boring and it'll be done here in a second a few seconds about 80% and then I'll just pull something up like this ECU just constantly dumps out some messages, uh, on the CAN bus. Okay, it's complete so all right, let's talk to this ECU I've got to free up the USB device so the web browser doesn't have a hold of it and all right, so let's see if this, all right so it should be, now if I didn't hopefully this is where, like, the live demo doesn't go all wrong uh, if I try to connect to this ECU and read all the messages that it's dumping out on the CAN bus there you go so it's like five messages that it just dumps out, I think it's like a torque sensor that's on it and a bunch of other stuff so so yeah and, uh, I guess that's it that's my talk what's up yeah, sure so is there any signature on the firmware um, no, yeah, there's no signature um, it just like, there's that last step where they say um, they say basically uh, validate the firmware there's like a routine control message that gets called and that validation is just are the checks, do the checks do the sum of the bytes add up, so yeah, there's nothing like that um, did it, and then the other comment was I made some assumptions about like, I had something, I wanted to decrypt it and I didn't know you know, what the how do I know, like how would I make those assumptions so that I know when it was decrypted completely, or properly um, yeah, so I mean I just guessed, right, and then uh, in addition to guessing though this ECU here is tore apart, because then I have the decrypted firmware like I figured out how to dump the full firmware, so like these firmware update files they're you know, potentially not super useful to modify, because they're partial right, like important things that you want to modify or you need to like reverse engineer out of them they might not even be in the update section right, um so, like what I did was I got an ECU that I was able to dump the firmware off of and then I just had these ideas like okay well, I should be able to find this software version that you can request through read memory by address, um and maybe I was like, I just tried, like okay well maybe, how many times, I had no idea how many times, how many sets of um you know, combinations of operators and my brute force decryption would match, and it turned out like 99% of the time there was only one, and I had the real firmware from an ECU to compare it to, to then make 100% certain that at least sometimes I was decrypting it successfully. This one actually, this specific ECU is simpler than that, it's UART, it's serial, but a lot of them are JTAG that you have to dump them through, yep, yeah. No, I don't think so, I mean they don't publish any firmware updates, I think George has like said on our Discord multiple times that all firmware modifications are canceled, so um, yeah I mean this is just uh, you know, this is just me working on this stuff in my free time basically, so, uh, yeah, this is just stuff for fun, so yeah, go ahead. Yeah, so, uh, I haven't had that much time to like really work on it and make it awesome, um, so like I just tried it on a few ECUs that are actually in my car, but I haven't, like I haven't specifically tested it out on like what like the engine tuning ECU guys do, you know the where there's a lot more potential, I mean they all charge money for that stuff, right? Oh, not all of them, I think there's some free ones like ROM Raider or something like that, um, uh, but like I don't know, I think this is the future, I think, you know, it seems like web browsers are gonna be the, um, you know, the platform for building modern applications in the future and and so like, I don't know, I feel like I'm showing you the future of what these tools are gonna look like someday. Alright. Cool. Thanks guys. And, uh, I think, uh, someone gave me this, uh, adapter. Thanks a lot for the adapter so I could actually give my presentation. Thank you.