OK, so now you have this massive assembly language listing staring you in the face. How do you go about reverse engineering it? This reminds me of a saying/joke a friend of mine told me: How do you eat an elephant? One bite at a time. So grab your knife and fork and get ready for a really big meal, because this is going to take a long time. All of the automated analysis has been done by your disassembler, so now it's up to you to figure out what this code actually does. But that's the fun of it, right? :)
Still, you have to start somewhere. Should you just start from the first instruction and go from there? That's pretty much what I did the first time. Don't make the same mistake. Reverse-engineering code is kind of like putting together a puzzle, except you don't know what the final picture will look like, at least not exactly. But in the case of an ECU, you do know some things that have to be there. You know what sensors and actuators it's talking to (O2 sensor, MAP and/or MAF sensor, coolant temperature sensor, injectors, etc). For OBDII cars, you also know that it's got to support certain standard Modes and PIDs, as well as Diagnostic Trouble Codes. And, you should know something about the design of your microcontroller, such as where the reset vector and interrupt vectors are located, and what special function registers control the ADC and serial ports.
In the case of the NB Miata, I originally thought that it would be much harder to reverse-engineer, since OBDII compliance meant that it had to support a lot more diagnostic functions than earlier cars, which I assumed would make the code much more difficult to figure out. In fact, the opposite is true. The reason is that, since so many diagnostic functions are mandated by law to work a certain way, all you need to do is to find the code that is responsible for processing and responding to OBD commands to figure out how this information is stored in the ECU. For example, take Mode $01, PID $05, Engine Coolant Temperature. SAE J1979 requires that the response contains a byte that corresponds to the car's engine coolant temperature in degrees Celsius, plus 40. So if you find the code that generates the response, you now know which memory location holds the engine coolant temperature.
So what would be the most likely place to find code that allows the microcontroller to communicate with the outside world? Perhaps through a serial port? That's a very logical guess. And, in the case of the Miata, it's also correct. By searching the code for any references to serial ports, and looking at the functions pointed to by the serial port interrupt vectors, it took very little time to find the code that generated responses to not only Mode 1 PID 5 but all OBD commands (including the non-standard, proprietary ones).
Once you know which memory locations hold important information (such as coolant temperature, RPM, ignition timing, etc), start looking at all the functions that reference those variables. For example, if you examine the functions that deal with ignition timing, you are likely to find that one or more of them refer to a lookup table (LUT) that is used to determine the timing. These are the tables that most "performance chips" modify, along with the fuel LUTs.
So, if you're reverse-engineering firmware from any OBDII compliant car, I would say that the absolute best place to start is to try to locate the code that generates the reply messages. Once you find it and figure out how each response is generated, you will have established a pretty significant beachhead from which you can venture out further in your understanding of the inner workings of your ECU. Happy trails!
I've been reverse-engineering ECUs since 2001. This blog is to share what I've learned about Honda and Mazda ECUs and to provide you with tips and advice if you would like to hack your own ECU.
Friday, December 31, 2010
Some disassembly required
(Happy New Year's Eve! Before I talk about reverse-engineering strategies, I thought I would explain to the uninitiated what a disassembler is, and recommend a good one. If you already know what a disassembler is and have a favorite, you can skip this post.)
Once you've successfully read out the firmware image from your ECU, you still only have a bunch of bytes. In order to make any sense out of it, you're going to have to change it into a more human-readable form: assembly language. You could try doing this manually, by looking up what instruction each byte corresponds to in the user manual for your ECU's microcontroller. You could, but that would be crazy. It would take forever. The right way is to use a disassembler, which is a program that does this (and usually a lot more) for you.
When I started with the Honda CRX, I was lucky that its ECU used an 8051. It's such a popular micro that there are free disassemblers available to download. The Integra, however, uses a much less common chip from Oki Semiconductor (66207), so I wasn't able to disassemble it until someone else (another Honda ECU hacker, I assume) wrote a disassembler for it. For the NB Miata, although I don't know the exact micro it's using, I at least know it's from the Motorola MC68HC16 family, and that's common enough that disassemblers exist for it. There are certain registers (memory locations with special functions) that are specific to the particular variant found in the NB that the disassemblers don't know about, but for the most part the assembly code they generate is quite usable.
So earlier I mentioned that most disassemblers do more than just transform bytes into assembly language instructions. What else do they do? A lot! Take IDA Pro, for example. This is probably one of the most well-known and best disassemblers out there. It's also freakin' expensive, so for most of us, we can only afford the free version. But even that is still really powerful. For example, the assembly language listing it generates is not just a text file, but it groups code into functions and subroutines, and you can follow the jump instructions by simply clicking on them. It also compiles lists of all functions, subroutines and variable names used, which can be renamed so that as you figure out what each one is for, you can rename it to something more meaningful. You can also specify which parts of your firmware image are instructions and which parts are data tables (or blank), so the disassembler translates it properly. In the expensive version, IDA Pro can also draw subroutines is flowcharts, which I'm sure makes untangling them even easier. I wish they had a cheaper version that had some of the Pro features in it. I would definitely consider buying it. Still, anyone interested in reverse-engineering binary code (whether it's from an ECU, any other firmware or even PC programs) should at least check out their free version. The Pro version supports many more processors than the free version, but sometimes people write modules that support other processors for the free version (including the one that works for the Miata, fortunately!).
Once you've successfully read out the firmware image from your ECU, you still only have a bunch of bytes. In order to make any sense out of it, you're going to have to change it into a more human-readable form: assembly language. You could try doing this manually, by looking up what instruction each byte corresponds to in the user manual for your ECU's microcontroller. You could, but that would be crazy. It would take forever. The right way is to use a disassembler, which is a program that does this (and usually a lot more) for you.
When I started with the Honda CRX, I was lucky that its ECU used an 8051. It's such a popular micro that there are free disassemblers available to download. The Integra, however, uses a much less common chip from Oki Semiconductor (66207), so I wasn't able to disassemble it until someone else (another Honda ECU hacker, I assume) wrote a disassembler for it. For the NB Miata, although I don't know the exact micro it's using, I at least know it's from the Motorola MC68HC16 family, and that's common enough that disassemblers exist for it. There are certain registers (memory locations with special functions) that are specific to the particular variant found in the NB that the disassemblers don't know about, but for the most part the assembly code they generate is quite usable.
So earlier I mentioned that most disassemblers do more than just transform bytes into assembly language instructions. What else do they do? A lot! Take IDA Pro, for example. This is probably one of the most well-known and best disassemblers out there. It's also freakin' expensive, so for most of us, we can only afford the free version. But even that is still really powerful. For example, the assembly language listing it generates is not just a text file, but it groups code into functions and subroutines, and you can follow the jump instructions by simply clicking on them. It also compiles lists of all functions, subroutines and variable names used, which can be renamed so that as you figure out what each one is for, you can rename it to something more meaningful. You can also specify which parts of your firmware image are instructions and which parts are data tables (or blank), so the disassembler translates it properly. In the expensive version, IDA Pro can also draw subroutines is flowcharts, which I'm sure makes untangling them even easier. I wish they had a cheaper version that had some of the Pro features in it. I would definitely consider buying it. Still, anyone interested in reverse-engineering binary code (whether it's from an ECU, any other firmware or even PC programs) should at least check out their free version. The Pro version supports many more processors than the free version, but sometimes people write modules that support other processors for the free version (including the one that works for the Miata, fortunately!).
Thursday, December 9, 2010
Preparation: Gather your tools and information
The obvious first step to hacking your car's ECU is to locate it, and remove it without damaging it. This usually involves a Google search or just looking around your car, and then removing a few nuts, bolts and/or screws. A flat head screwdriver helps to remove the wiring harness from the ECU. It's probably prudent to ground yourself so you don't damage the ECU with static discharge, as well as disconnecting the car battery first. (I usually don't do either, but don't say I didn't warn you).
Once the ECU is out of the car, you'll need to open it up. At least in the case of the Civic, Integra and Miata, all you need is a Phillips screwdriver. Most ECUs are pretty basic - a PCB enclosed in a metal box, with a large connector for the wiring harness. You'll probably need to remove the PCB from the case in order to work on it. If you have an anti-static mat (such as this one from Fry's http://www.frys.com/product/2807074), you might want to use it. Take a look at the board. Take pictures. Pay special attention to the largest ICs. Two of them are probably going to be the microprocessor and a memory chip. If you're lucky, the part numbers will be easily readable. If you're not so lucky, all you will have to go on is the package type and pin count. Either way, you'll be going back to Google to find out all you can about these two components.
Auto manufacturers aren't in the business of making their own microcontrollers and custom memory ICs, so it's likely these will be commonly available parts, and it won't be hard to find information on them. On the other hand, when you build thousands or millions of ECUs, you can probably afford to use some ASICs. For example, in the CRX ECU (commonly referred to as the PM6), an 8051 microcontroller is used, along with a standard 27C256 EPROM. However, the particular variant of 8051 implements a non-standard opcode - why, I don't know. In addition, the PM6 has an important IC on it that you won't find a datasheet for anywhere. That made some of the inner workings of the ECU a mystery, but a great deal could still be learned from disassembling the 8051 program on the EPROM.
Anyway, once you identify your ECU's microprocessor and memory, you'll want to look for the necessary software tools to disassemble the program. But of course you need to access the program first, which for ECUs that are more than about 5-10 year old usually means physically removing the memory chip and reading it with an EPROM programmer. You can probably reprogram most newer ECUs without even removing them from the car, but I'm talking about the older ones at the moment.
It's usually pretty easy to find an EPROM programmer that will be able to read the particular memory chip you have. Ebay is full of them. I got one from mcumall.com that works well and was reasonably priced. There may be even better deals out there. The harder part is non-destructively removing the chip from the PCB. For older ECUs, where the memory chips are through-hole mounted, a desoldering tool like this one works well (http://www.radioshack.com/product/index.jsp?productId=2062731). In the Miata, however, the flash memory is a surface mount part.
I have to admit that the idea of desoldering a surface mount part kind of scared me, but in fact it's actually easier than desoldering through-hole components! Check out this video, for example: (http://www.youtube.com/watch?v=FTQqjggeklo). It really is that easy, and reattaching is a snap, too. Still, you should practice a couple of times on similar components on scrap boards before you try it on the real thing. And you will need a multimeter so you can verify that you don't have any open or short circuits after you're done.
In addition to the ChipQuik kit, you'll need a good (i.e., temperature-controlled) soldering iron such as a Weller, with a screwdriver- or hoof-shaped tip, plenty of Q-tips and rubbing alcohol to clean off the PCB after the chip is removed, and of course solder to reattach the SMD.
Next time, I'll talk about what to do with the firmware image once it's been copied off the EPROM (and this applies to both newer and older ECUs): how to disassemble it, and some strategies to consider when reverse-engineering the code.
Once the ECU is out of the car, you'll need to open it up. At least in the case of the Civic, Integra and Miata, all you need is a Phillips screwdriver. Most ECUs are pretty basic - a PCB enclosed in a metal box, with a large connector for the wiring harness. You'll probably need to remove the PCB from the case in order to work on it. If you have an anti-static mat (such as this one from Fry's http://www.frys.com/product/2807074), you might want to use it. Take a look at the board. Take pictures. Pay special attention to the largest ICs. Two of them are probably going to be the microprocessor and a memory chip. If you're lucky, the part numbers will be easily readable. If you're not so lucky, all you will have to go on is the package type and pin count. Either way, you'll be going back to Google to find out all you can about these two components.
Auto manufacturers aren't in the business of making their own microcontrollers and custom memory ICs, so it's likely these will be commonly available parts, and it won't be hard to find information on them. On the other hand, when you build thousands or millions of ECUs, you can probably afford to use some ASICs. For example, in the CRX ECU (commonly referred to as the PM6), an 8051 microcontroller is used, along with a standard 27C256 EPROM. However, the particular variant of 8051 implements a non-standard opcode - why, I don't know. In addition, the PM6 has an important IC on it that you won't find a datasheet for anywhere. That made some of the inner workings of the ECU a mystery, but a great deal could still be learned from disassembling the 8051 program on the EPROM.
Anyway, once you identify your ECU's microprocessor and memory, you'll want to look for the necessary software tools to disassemble the program. But of course you need to access the program first, which for ECUs that are more than about 5-10 year old usually means physically removing the memory chip and reading it with an EPROM programmer. You can probably reprogram most newer ECUs without even removing them from the car, but I'm talking about the older ones at the moment.
It's usually pretty easy to find an EPROM programmer that will be able to read the particular memory chip you have. Ebay is full of them. I got one from mcumall.com that works well and was reasonably priced. There may be even better deals out there. The harder part is non-destructively removing the chip from the PCB. For older ECUs, where the memory chips are through-hole mounted, a desoldering tool like this one works well (http://www.radioshack.com/product/index.jsp?productId=2062731). In the Miata, however, the flash memory is a surface mount part.
I have to admit that the idea of desoldering a surface mount part kind of scared me, but in fact it's actually easier than desoldering through-hole components! Check out this video, for example: (http://www.youtube.com/watch?v=FTQqjggeklo). It really is that easy, and reattaching is a snap, too. Still, you should practice a couple of times on similar components on scrap boards before you try it on the real thing. And you will need a multimeter so you can verify that you don't have any open or short circuits after you're done.
In addition to the ChipQuik kit, you'll need a good (i.e., temperature-controlled) soldering iron such as a Weller, with a screwdriver- or hoof-shaped tip, plenty of Q-tips and rubbing alcohol to clean off the PCB after the chip is removed, and of course solder to reattach the SMD.
Next time, I'll talk about what to do with the firmware image once it's been copied off the EPROM (and this applies to both newer and older ECUs): how to disassemble it, and some strategies to consider when reverse-engineering the code.
Saturday, December 4, 2010
So you want to hack your ECU. Where do you start?
I've been reverse engineering automotive engine control units (ECUs) since 2001. Recently, an acquaintance encouraged me to write a blog about it. At first, I wasn't sure if anyone would really be interested about the internal details of ECUs, but then I thought, why not. So if you're reading this, I assume you are the curious type, are interested in cars and electronics, and aren't afraid to use a soldering iron. I plan to write about how I got into ECU hacking, the basics of how to do it, such as what tools you need, and some of what I've learned along the way. So let's start from the beginning.
I wasn't always interested in cars. In fact, growing up I never really thought of them as anything more than a form of transportation until one singular experience changed everything for me - playing Gran Turismo. I know, it sounds kind of silly, and it is, but that's really the reason why I got excited about cars, and why, in 2001, I bought a used Honda 1991 CRX Si (which had seen better days), bought a used Jackson Racing supercharger, which I installed myself to save money, and, finally, decided to crack open the CRX's ECU to see if I could hack it myself, because the only other option at the time was to pay someone else about $1000 to do it. So, what started out mainly as an attempt to go fast cheaply has turned into a long-term hobby, and since that time, I have had almost as much fun working on my cars and hacking their ECUs as I've had driving them.
In 2001, the conventional wisdom was that Honda ECUs couldn't be hacked, except by the few commercial outfits that were charging an arm and a leg for their services. But hey, if they could do it, why couldn't I? I decided to open up my ECU and see. What I found was a pleasant surprise: My CRX's ECU was powered by an 8051 microcontroller and used a standard 28-pin EPROM. It'd be hard to come up with a more common combination of parts. There were plenty of 8051 code disassemblers that could be downloaded for free, as well as datasheets. I was fortunate enough to have access to an EPROM programmer, so all I had to was desolder the EPROM, read it and disassemble it. If you're interested, you can read more about it here: http://forum.pgmfi.org/viewtopic.php?f=2&t=7&start=0
Since the CRX, I've owned a supercharged '93 Civic Si, a supercharged '94 Integra GS-R and now a 2001 Mazda Miata, and I've hacked the ECU in each one. I've also gone from having no kids to 4, so I don't have as much free time to devote to this as I used to, but I will try to post regularly about what you need to do to hack your own ECU, from the ground up, including what hardware and software tools you'll need and where to find them. Stay tuned.
I wasn't always interested in cars. In fact, growing up I never really thought of them as anything more than a form of transportation until one singular experience changed everything for me - playing Gran Turismo. I know, it sounds kind of silly, and it is, but that's really the reason why I got excited about cars, and why, in 2001, I bought a used Honda 1991 CRX Si (which had seen better days), bought a used Jackson Racing supercharger, which I installed myself to save money, and, finally, decided to crack open the CRX's ECU to see if I could hack it myself, because the only other option at the time was to pay someone else about $1000 to do it. So, what started out mainly as an attempt to go fast cheaply has turned into a long-term hobby, and since that time, I have had almost as much fun working on my cars and hacking their ECUs as I've had driving them.
In 2001, the conventional wisdom was that Honda ECUs couldn't be hacked, except by the few commercial outfits that were charging an arm and a leg for their services. But hey, if they could do it, why couldn't I? I decided to open up my ECU and see. What I found was a pleasant surprise: My CRX's ECU was powered by an 8051 microcontroller and used a standard 28-pin EPROM. It'd be hard to come up with a more common combination of parts. There were plenty of 8051 code disassemblers that could be downloaded for free, as well as datasheets. I was fortunate enough to have access to an EPROM programmer, so all I had to was desolder the EPROM, read it and disassemble it. If you're interested, you can read more about it here: http://forum.pgmfi.org/viewtopic.php?f=2&t=7&start=0
Since the CRX, I've owned a supercharged '93 Civic Si, a supercharged '94 Integra GS-R and now a 2001 Mazda Miata, and I've hacked the ECU in each one. I've also gone from having no kids to 4, so I don't have as much free time to devote to this as I used to, but I will try to post regularly about what you need to do to hack your own ECU, from the ground up, including what hardware and software tools you'll need and where to find them. Stay tuned.