ECU Hacking 101

I'm back!

2017-07-06T09:05:00.000-07:00

Hi, Everyone,

It has been way too long since I've posted anything on this blog. Too many other things going on. However, a couple of weeks ago I made the mistake of trying to read the EEPROM on my ECU. I don't mean the large flash (29F200), but the little L56R (sometimes its a 93C56 - they are basically equivalent) next to the microcontroller. This little guy holds immobilizer related information.

Sadly, I wasn't successful, and worse yet, when I reinstalled the ECU, my car wouldn't start! I don't know if I damaged the ECU somehow, but my guess was that I had inadvertently modified the contents of the EEPROM and the immobilizer system wasn't happy about it. When I say "immobilizer system" I mean the ECU + immobilizer, as they work together.

So what to do? I figured that restoring the contents of the 93C56 was pretty much out of the question, since I had probably already scrambled it and I had no copy of the original data. Plus I'd have to desolder it to reprogram it anyway, which I didn't feel like doing.

My only other option was to try to figure out how to bypass the immobilizer. Long story short (and with the details intentionally omitted!), I was able to do this with just firmware mods (no hardware changes necessary, other than unplugging the immobilizer). Yup, I can now start my car with no immobilizer. Not the best solution security-wise, but it sure beats having to buy a new ECU/immobilizer/keys/etc.

Do you have an immobilizer issue? Here are some things you can try:

If the ECU went bad and needs to be replaced, buy a used one of the same type, then swap out the little EEPROM with the one from the original ECU. Yes, you will have to desolder/solder a small surface mount IC. I highly recommend making a copy of the contents of this EEPROM while you're at it, just in case. From the immobilizer's point of view, the entire "identity" of the ECU resides in that EEPROM, so as far as it's concerned, after the chip swap, the replacement ECU will look just like the original one.
If the ECU is good and the immobilizer needs to be replaced, this is a bit more involved. First, buy a used (known good) immobilizer. Make sure you can read the serial number on it. Then, you'll need a way of getting the code word from the serial number. There are programs out there that can do this. Most are not free, but I know of at least one where the "demo" mode will do this for free! It will be an 8 digit number. You'll have to program this into the EEPROM. I'm still looking for a way to do this without having to desolder the chip. There must be a way, because the manufacturer does it - but until I find it, you'll have to remove the chip and program it that way. If you are actually going to do this, let me know and I can help you out with the details. Once the EEPROM's copy of the code word is made to match the immobilizer, then the new immobilizer should work with the ECU. You'll have to reprogram your keys, too (you can find the procedure online). Caveat - I haven't tried this myself, so YMMV.
If both ECU and immobilizer are replaced, and you don't have a matching set, do the same as if you replaced just the immobilizer, as I don't know how to change the code word in the immobilizer, or if it's even possible.

Anyway, I hope you never have a problem with your immobilizer system, and I'm glad my car came with one, but if you do, just know that there are cheaper ways to get up and running again than replacing the ECU/immobilizer/keys/locks.

Hello again

2014-02-19T22:27:00.000-08:00

Recently, I got an email from someone asking about the Miata ECU project. It turned out that he works very close by where I work, so we met and talked over coffee. I'd been so busy with other things (life, basically) that I hadn't really done anything with the project in a long time. That in itself really didn't (and doesn't) bother me, but our meeting made me realize that others have taken an interest in the project, and that I've been remiss in keeping up this blog. It's received a little over 10,000 page views, including over 500 last month, even though it's been over 2 years since I've written a project-related post. So I do feel like I owe you some new posts.

While I really have not done much in the last year or so, there is a lot that I've already learned over the past couple of years that I haven't shared, so just catching everyone up will take up quite a few posts.

I left off with a series of posts about OBD modes. I think next time, I'll just wrap up the remaining supported modes, so we can move on to more interesting topics. If you have suggestions for topics of particular interest you'd like me to cover, please leave a comment!

Shameless Panhandling

2012-05-29T23:52:00.000-07:00

Hello, again! I haven't posted for some time now, as you can see. I am still working on the reverse engineering project, when I have time. My latest crazy idea has been to port the code to C# so I can run and debug it on my PC. It's never going to actually run my car, but it is useful to be able to run it and trace the program flow, instead of just staring at static code. It also gives me a perverse sense of nerd joy knowing that I'm probably the only one that's ever run the NB code in C#. :P

Anyway, I'm writing today to (shamelessly) ask you to please click on an ad or two if you find any of this stuff interesting. It won't cost you anything, and it may net me a penny or two. To give you an idea of how little money we're talking about, to date the blog has been viewed about 2,000 times, and I've made less than $2 from the ads. So it's obviously not going to make me any real money, but think of it as your way of encouraging me to continue sharing with you what I'm finding out about the NB ECU. Thanks! And thank you especially for the handful of readers that have left an encouraging note. That's a great motivator for me!

NB Miata - OBD Mode 13

2012-01-14T00:45:00.000-08:00

Happy Friday the 13th! Are you superstitious? I'm not - especially not about the number 13. Speaking of which, we're talking about OBD Mode 13 today. OK, so 13 in this case is actually a hexadecimal number, but anyway...

The ECU subroutines that handle Mode 13 are also shared with Modes 3 and 7. It appears that, while the request messages for Modes 3 and 7 do not (actually, cannot) contain a PID, Mode 13 messages can contain extra bytes after the mode number. I wish I could tell you what they are used for, if anything, but at this point, I don't know.

What I can tell you is that mode 13 reports the same DTCs as Mode 3, plus:

P0605 - Internal Control Module ROM Error
P1602 - Immobilizer / ECM Communication Error
P1603 - ID Number Unregistered
P1604 - Code Word Unregistered
P1621 - Immobilizer Code Words Do Not Match
P1622 - Immobilizer ID Does Not Match
P1623 - Immobilizer Code Word/ID Number Write Failure
P1624 - Vehicle anti-theft system malfunction
P1631 - Alternator Regulator #2 Control Circuit
P1633 - Generator Control System - over charge
P1634 - Generator Control System - no charge

I could be wrong about the meaning of the last three. But what you can see from looking at the rest of the list is that they represent a class of errors that have more to do with the system electronics than the engine, so they are different. I'm particularly interested in how the immobilizer works, and will post more about it later.

It's been about 9 months since I have looked at the code, so it will take me a little bit of time to get back to where I was, but if I recall correctly, there may be some additional requirements that must be met in order to access Mode 13 (such as placing a jumper somewhere or something). As I get back into analyzing the code, I will update this post with any additional info I find.

Next up, Mode 14.

Season's Greetings

2011-12-20T23:23:00.000-08:00

Hi to everyone who's stumbled across this blog! As so often happens in life, you sometimes get busy doing other stuff and all of a sudden a few months have gone by. I was very surprised to see that there have been a lot more views than I expected since I last posted. I will resolve to continue posting in 2012! See you in the new year.

NB Miata - OBD Mode 8

2011-04-12T22:29:00.000-07:00

Today I'm going to talk about Mode 8. It's been a while since I posted, partly because I have been busy with other things, and partly because I was hoping to have a more complete picture of what Mode 8 does. Unfortunately, it's still mostly a mystery to me. But at least I can tell you what I know.

In general Mode 8 is used to control some on-board system, sometimes to create conditions necessary to test a component or subsystem. In my ECU, here's the quick summary:

In the NB Miata, it only applies to OBD-II vehicles. Any other flavor will simply respond to a Mode 8 request with an error reply.
Only two PIDs are supported: 00 and 01.
The request message must be 11 bytes long, so must be zero-padded. And the extra bytes cannot be anything other than zero.
PID 0 is just a PIDs supported request. Since I'm telling you now that only 0 and 1 are supported, this is no longer of any use to you.
If a PID 1 request is sent and bit 0 of 10055 is set at the time, then the ECU will set bit 0 of 108ED and respond with an affirmative OBD reply.

I think that the request is only honored if the engine is not running at the time, but I'm not 100% sure if that's the case. Anyway, while it may seem like a lot of trouble just to set one bit in memory, setting that bit has a pretty significant ripple effect. I'm not sure I've discovered all of the secondary effects, and I'm pretty much in the dark about what the ultimate purpose is, but it appears to temporarily put the ECU in an altered state, and there are literally dozens of places in the the code that are ultimately affected. Some of the affected subroutines are related to the short term fuel trim, but there are many others that I still have no idea what they are used for.

I hope to eventually unravel the complete story. In the meantime, if you are willing to try, you can see if you can get your car to accept a Mode 8 PID 1 command and see if you can tell how your car's behavior changes. I doubt very much that Mazda would build in a test that could potentially damage your car, but of course I can't guarantee it, so proceed at your own risk.

Next time, Mode 9? Sorry, but the NB Miata doesn't support Mode 9. In fact, the next higher supported mode is Mode 13.

NB Miata - OBD Mode 7, and Mode 3 update

2011-02-22T22:00:00.000-08:00

Mode 7 is similar to Mode 3, in that it does not take any PIDs, and reports on DTCs. They are so similar, in fact, that they share the same subroutines to generate responses to requests. However, while Mode 3 responds by reporting active DTCs, Mode 7 reports pending DTCs - that is, problems that have been detected but have not yet risen to the level of severity of an active DTC.

Another key difference between the two is that they support a slightly different set of DTCs. When I first listed the DTCs in the Mode 3 post, I thought that Mode 3 could report all of them. However, upon closer inspection, it turns out that only a subset of them will ever show up in a Mode 3 response. Similarly, the Mode 7 DTCs are a subset of the Mode 3 DTCs.

Rather than re-list the DTCs that are associated with Mode 7, I'll just list the numbers. You can refer to the previous Mode 3 post for more info.

Mode 7 DTCs
P0011, P0012, P0031, P0032, P0037, P0038, P0101, P0106, P0111, P0116, P0121, P0125, P0126, P0128, P0131, P0132, P0133, P0134, P0138, P0140, P0171, P0172, P0300, P0301, P0302, P0303, P0304, P0401, P0402, P0420, P0421, P0442, P0451, P0443, P0452, P0453, P0455, P0461, P0462, P0463, P0464, P0480, P0500, P0506, P0507, P0550, P0703, P0704, P0706, P0715, P0725, P0741, P0742, P0751, P0752, P0756, P0757, P0850, P1450, P1496, P1497, P1498, P1499, P1512, P1518, P1569, P1570

Mode 3 DTCs
(the above list), plus: P0010, P0102, P0103, P0107, P0108, P0112, P0113, P0117, P0118, P0122, P0123, P0222, P0223, P0327, P0328, P0335, P0340, P0505, P0720, P0743, P0753, P0758, P1562, P1601

Finally, there are a few other modes that report DTCs, and have their own subset of DTCs. More on these later. Up next: Mode 8.

NB Miata - OBD Mode 6, part 1

2011-02-20T03:25:00.000-08:00

There is some interest in Mode 6 because the information it provides can sometimes give "early warning" of problems, and also because it tends to be poorly documented (unless you pay for access to the information). Here's what I've been able to piece together from looking at the code. Although I prefer not to post before I think I fully understand a mode, in this case I decided to just write up what I've found so far, because it may be a while before I figure it out completely. Until then, perhaps this partial explanation may prove useful to someone.

Mode 6 supports the following TIDs (the request should only be the mode and the TID, with no other data bytes, which means a total request length of 6 bytes when you include the header and checksum byte):
00 - TIDs supported 01-20 (they are: 01, 02, 03, 04, 05, 06, 11, and 20)
20 - TIDs supported 21-40 (they are: 21, 22, 31, 32, and 40)
40 - TIDs supported 41-60 (only 41)
01 - for component ID (CID) 11, the test value stored at 10F56 needs to be less than 422
02 - for CID 11, the test value stored at 10D46 needs to be less than 62
03 - for CID 11, the test value stored at 10D4A needs to be less than 50
04 - for CIDs 01 and 02, the test value stored at 10970 needs to be greater than zero
05 - for CID 01, the test value stored at 10972 needs to be greater than zero
06 - for CID 01, the test value stored at 10974 needs to be greater than zero
11 - for CID 11, the test value stored at 10F5A needs to be greater than 40
21 - for CID 00, the test value stored at 10F6A needs to be less than the limit value stored at 10F6E
22 - for CID 00, the test value stored at 10F6C needs to be less than the limit value stored at 10F70
31 - for CID 00, the test value stored at 10F72 needs to be less than the limit value stored at 10F74
32 - for CID 00, the test value stored at 10F76 needs to be greater than the limit value stored at 10978
41 - for CID 00, the test value stored at 10F5C needs to be less than the limit value stored at 10F5E and greater than the limit store at 10F60

I got a little help by comparing the format of the reply message that the code puts together to the ISO 15031-5 spec. However, I don't yet know what each test value represents. I also don't know what components CIDs 0, 1, 2 and 11 refer to. I don't even know what the limit values are in some cases (although you could determine this pretty easily by simply plugging a scantool into the car and sending the appropriate Mode 6 requests). If anyone has this information and would like to share, please post a comment. I should eventually be able to figure it out on my own from looking at the code, but I would definitely appreciate it if someone could save me the time by telling me what the above tests are all about.

Next time, Mode 7, which is very similar to Mode 3.

NB Miata - OBD Mode 5

2011-02-17T23:46:00.000-08:00

If you thought Mode 4 was simple, Mode 5 is, in some ways, even simpler. At least a Mode 4 request causes something to happen. Mode 5 requests only return information, and that information never changes!

Mode 5 is meant to return information that is used for oxygen sensor monitoring. In the NB, only the following TIDs are supported:

00xx - this is the TIDs supported TID. It must be two bytes, but the second byte can be anything. The reply tells you that only TIDs 1 and 2 are supported
0101 - returns the rich-to-lean threshold voltage for O2 sensor 1
0102 - returns the rich-to-lean threshold voltage for O2 sensor 2
0201 - returns the lean-to-rich threshold voltage for O2 sensor 1
0202 - returns the lean-to-rich threshold voltage for O2 sensor 2

What makes this mode so uninteresting is that all you can do is request the above threshold voltages. What's more, they are all the same (0.445V) and never change. Yawn.

Next up, Mode 6.

NB Miata - OBD Mode 4

2011-02-05T09:48:00.000-08:00

This is a very simple mode. There are no PIDs. A mode 4 message tells the ECU to clear all DTCs.

Under the hood, the way it works is as follows. There are a slew of subroutines that periodically monitor the car's health and set DTCs as necessary. If you send a mode 4 message (with no PID - if you send a PID, it won't work), the ECU sets a bit (108E7, bit 2) to let these subroutines know that they should clear their associated DTCs. At the same time this bit is set, a countdown timer at 1094E is set to 30. When it counts down to zero, the "clear DTCs" bit is cleared, and the system returns to normal operation. I haven't yet worked out how long the ECU takes to countdown from 30 to 0.

Last time I said that I would post some details on the immobilizer system. I have been working on it, a lot, and have learned a lot, too, but I don't feel like I have enough of the big picture to share yet. So, maybe next time. Otherwise, the next post will be on OBD Mode 5.

NB Miata - OBD Mode 3 and DTCs

2011-01-19T02:27:00.000-08:00

Update: 2/22/11
I originally thought that Mode 3 could report any of the DTCs listed below. This is incorrect. The list below is actually the complete list of all DTCs the ECU can generate, but only some of the DTCs in the list are associated with Mode 3 (see my Mode 7 post for the list). The other DTCs are associated with other modes. More on these later.

OBD Mode 3 is used to return Diagnostic Trouble Codes (DTCs). It does not support any PIDs - a mode 3 request only consists of the mode (other than the 3 header bytes and final checksum byte). If any DTCs are active, the DTCs are returned as two-byte binary-coded-decimal numbers, in groups of three DTCs at a time.

I'm still trying to understand the details of how the code works that determines which DTCs are set and when, but for this post I'll just list the possible DTCs this ECU can report. I'll post more details on OBD Mode 3 at a later time.

All possible DTCs (see http://www.obd-codes.com/trouble_codes/ for details)

P0010 - "A" Camshaft Position Actuator Circuit (Bank 1)
P0011 - "A" Camshaft Position - Timing Over-Advanced or System Performance (Bank 1)
P0012 - "A" Camshaft Position - Timing Over-Retarded (Bank 1)
P0031 - HO2S Heater Control Circuit Low (Bank 1 Sensor 1)
P0032 - HO2S Heater Control Circuit High (Bank 1 Sensor 1)
P0037 - HO2S Heater Control Circuit Low (Bank 1 Sensor 2)
P0038 - HO2S Heater Control Circuit High (Bank 1 Sensor 2)
P0101 - Mass Air Flow Circuit Range/Performance Problem
P0102 - Mass Air Flow Circuit Low Input
P0103 - Mass Air Flow Circuit High Input
P0106 - Manifold Absolute Pressure/Barometric Pressure Circuit Range/Performance Problem
P0107 - Manifold Absolute Pressure/Barometric Pressure Circuit Low Input
P0108 - Manifold Absolute Pressure/Barometric Pressure Circuit High Input
P0111 - Intake Air Temperature Circuit Range/Performance Problem
P0112 - Intake Air Temperature Circuit Low Input
P0113 - Intake Air Temperature Circuit High Input
P0116 - Engine Coolant Temperature Circuit Range/Performance Problem
P0117 - Engine Coolant Temperature Circuit Low Input
P0118 - Engine Coolant Temperature Circuit High Input
P0121 - Throttle Position Sensor/Switch A Circuit Range/Performance Problem
P0122 - Throttle Position Sensor/Switch A Circuit Low Input
P0123 - Throttle Position Sensor/Switch A Circuit High Input
P0125 - Insufficient Coolant Temperature for Closed Loop Fuel Control
P0126 - Insufficient Coolant Temperature for Stable Operation
P0128 - Coolant Thermostat (Coolant Temperature Below Thermostat Regulating Temperature)
P0131 - 02 Sensor Circuit Low Voltage (Bank I Sensor I)
P0132 - 02 Sensor Circuit High Voltage (Bank I Sensor 1)
P0133 - 02 Sensor Circuit Slow Response (Bank 1 Sensor 1)
P0134 - 02 Sensor Circuit No Activity Detected (Bank I Sensor 1)
P0138 - 02 Sensor Circuit High Voltage (Bank I Sensor 2)
P0140 - 02 Sensor Circuit No Activity Detected (Bank 1 Sensor 2)
P0171 - System too Lean (Bank 1)
P0172 - System too Rich (Bank 1)
P0222 - Throttle/Petal Position Sensor/Switch B Circuit Low Input
P0223 - Throttle/Petal Position Sensor/Switch B Circuit High Input
P0300 - Random/Multiple Cylinder Misfire Detected
P0301 - Cylinder 1 Misfire Detected
P0302 - Cylinder 2 Misfire Detected
P0303 - Cylinder 3 Misfire Detected
P0304 - Cylinder 4 Misfire Detected
P0327 - Knock Sensor 1 Circuit Low Input (Bank I or Single Sensor)
P0328 - Knock Sensor 1 Circuit High Input (Bank I or Single Sensor)
P0335 - Crankshaft Position Sensor A Circuit Malfunction
P0340 - Camshaft Position Sensor Circuit Malfunction
P0401 - Exhaust Gas Recirculation Flow Insufficient Detected
P0402 - Exhaust Gas Recirculation Flow Excessive Detected
P0420 - Catalyst System Efficiency Below Threshold (Bank 1)
P0421 - Warm Up Catalyst Efficiency Below Threshold (Bank 1)
P0442 - Evaporative Emission Control System Leak Detected (small leak)
P0443 - Evaporative Emission Control System Purge Control Valve Circuit
P0451 - Evaporative Emission Control System Pressure Sensor Range/Performance
P0452 - Evaporative Emission Control System Pressure Sensor Low Input
P0453 - Evaporative Emission Control System Pressure Sensor High Input
P0455 - Evaporative Emission Control System Leak Detected (gross leak)
P0461 - Fuel Level Sensor Circuit Range/Performance
P0462 - Fuel Level Sensor Circuit Low Input
P0463 - Fuel Level Sensor Circuit High Input
P0464 - Fuel Level Sensor Circuit Intermittent
P0480 - Cooling Fan I Control Circuit Malfunction
P0500 - Vehicle Speed Sensor Malfunction
P0505 - Idle Control System Malfunction
P0506 - Idle Control System duty cycle Lower Than Expected
P0507 - Idle Control System duty cycle Higher Than Expected
P0550 - Power Steering Pressure Sensor Circuit Malfunction
P0605 - Internal Control Module Read Only Memory (ROM) Error
P0703 - Torque Converter/Brake Switch B Circuit Malfunction
P0704 - Clutch Switch Input Circuit Malfunction
P0705 - Transmission Range Sensor Circuit malfunction (PRNDL Input)
P0706 - Transmission Range Sensor Circuit Range/Performance
P0715 - Input/Turbine Speed Sensor Circuit Malfunction
P0720 - Output Speed Sensor Circuit Malfunction
P0725 - Engine Speed input Circuit Malfunction
P0741 - Torque Converter Clutch Circuit Performance or Stuck Off
P0742 - Torque Converter Clutch Circuit Stuck On
P0743 - Torque Converter Clutch Circuit Electrical
P0751 - Shift Solenoid A Performance or Stuck Off
P0752 - Shift Solenoid A Stuck On
P0753 - Shift Solenoid A Electrical
P0756 - Shift Solenoid B Performance or Stock Off
P0757 - Shift Solenoid B Stuck On
P0758 - Shift Solenoid B Electrical
P0850 - Neutral switch input circuit problem http://foxed.ca/rx7manual/2003mazdarx8/esicont/en/srvc/html/BHE010200800W01.html)
P1449 - Evaporative Check Solenoid Circuit (http://www.aboutautomobile.com/DTC/P1449)
P1450 - Unable to Bleed Up Fuel Tank Vacuum (this and the rest can be found at aboutautomobile.com)
P1487 - Exhaust Gas Recirculation Check Solenoid Circuit
P1496 - EGR Stepper Motor 1 Control Circuit Low/High
P1497 - EGR Stepper Motor 2 Control Circuit Low/High
P1498 - EGR Stepper Motor 3 Control Circuit Low/High
P1499 - EGR Stepper Motor 4 Control Circuit Low/High
P1512 - Intake Manifold Runner Control Circuit (IMRC) Bank 1 stuck closed
P1518 - IMRC stuck open
P1562 - PCM backup + terminal voltage low
P1569 - IMRC circuit malfunction
P1570 - IMRC circuit malfunction
P1601 - ECM/TCM Serial Communication Error
P1602 - Immobilizer/ECM Communication Error
P1603 - ID Number Unregistered
P1604 - Code word Unregistered
P1608 - PCM Internal Circuit
P1621 - Immobilizer Code Words Do Not Match
P1622 - Immobilizer ID Does Not Match
P1623 - Immobilizer Code Word/ID Number Write Failure
P1624 -Vehicle anti-theft system malfunction
P1631 - Alternator Regulator #2 Control Circuit
P1633 - Generator Control System - over charge
P1634 - Generator Control System - no charge

I'm interested in analyzing the code behind the immobilizer-related DTCs. I'll take a look and maybe post what I find next time.

NB Miata, OBD Mode 2

2011-01-09T23:50:00.000-08:00

Today's post is pretty brief, as I'm planning to do one post per OBD Mode, and there's not a lot to say about Mode 2.

OBD Mode 2 is similar to Mode 1. However, whereas Mode 1 is used to obtain current diagnostic data, Mode 2 PIDs return freeze frame data. That is, they report the state of the engine when the last DTC occurred.

For the NB, the following Mode 2 PIDs are supported (a few less than Mode 1):

00 - PIDs supported (01-20)
02 - Freeze DTC
03 - Fuel system status
04 - Calculated engine load value
05 - Engine coolant temperature
06 - Short term fuel % trim - Bank 1
07 - Long term fuel % trim - Bank 1
0C - Engine RPM
0D - Vehicle speed

PID 00 - PIDs supported (01-20)
The subroutine that creates the reply message is at address 2885C.
Return value indicates that 02-07, 0C-0D are supported.

PID 02 - Freeze DTC
The subroutine that creates the reply message is at address 28870.
Returns the DTC which the freeze data is associated with. If there is no DTC, it returns 0.
If the byte at RAM location 10EF4 is non-zero, it means there is a DTC.
The Freeze DTC value is stored as a word at RAM location 10F28.

PID 03 - Fuel system status
The subroutine that creates the reply message is at address 28886.
The freeze frame data for fuel system status is stored in a byte at RAM location 10F21.

PID 04 - Calculated engine load value
The subroutine that creates the reply message is at address 28894.
The byte at RAM location 10F18 is proportional to calculated freeze frame engine load value.

PID 05 - Engine coolant temperature
The subroutine that creates the reply message is at address 288A4.
The byte at RAM location 10F20 is proportional to (freeze frame engine coolant temperature + 40 degrees C).

PID 06 - Short term fuel % trim - Bank 1
The subroutine that creates the reply message is at address 288B4.
The word at RAM location 10F1C is related to short term fuel % trim.

PID 07 - Long term fuel % trim - Bank 1
The subroutine that creates the reply message is at address 288C4.
The word at RAM location 10F1E is related to long term fuel % trim.

PID 0C - Engine RPM
The subroutine that creates the reply message is at address 288D4.
The word at RAM location 10F1A is proportional to RPM.

PID 0D - Vehicle speed
The subroutine that creates the reply message is at address 288E4.
The byte at RAM location 10F1F is proportional to vehicle speed.

NB Miata Specifics, OBD Mode 1

2011-01-08T14:05:00.000-08:00

So far, I've given you some general guidelines for extracting your ECU's firmware image and some suggestions for how to begin analyzing it. I'll just mention a few other analysis tips, and then I want to switch gears to talk about the specifics of what I'm learning about the NB Miata ECU.

So, a few other analysis tips:

Try to find out which variables and functions are called most often. These are likely to be the most important.
Note where a variable is referenced. The subroutines that share common variables are related.
Take special note of where variables are modified. Often a variable that is referenced in a dozen or more places is only set in one place; therefore the code that sets this variable influences all of the other routines.

Now, on to the Miata. The first thing I want to talk about is the OBD modes it supports. Today, I'll only talk about Mode 1.

Mode 1 provides information about the current state of the engine. The '01 NB supports the following Mode 1 PIDs:

00 - PIDs supported (01-20)
01 - Monitor status since DTCs cleared
03 - Fuel system status
04 - Calculated engine load value
05 - Engine coolant temperature
06 - Short term fuel % trim - Bank 1
07 - Long term fuel % trim - Bank 1
0C - Engine RPM
0D - Vehicle speed
0E - Timing advance
0F - Intake air temperature
10 - MAF air flow rate
11 - Throttle position
13 - Oxygen sensors present
14 - Bank 1, Sensor 1: O2S Voltage, Short term fuel trim
15 - Bank 1, Sensor 2: O2S Voltage, Short term fuel trim
1C - OBD standards this vehicle conforms to
20 - PIDs supported (21-40)
21 - Distance traveled with MIL on

For details on how each reply message is encoded, see http://en.wikipedia.org/wiki/OBD-II_PIDs#Modes

You can get all of the above info with any generic OBD scantool. But the following additional details can only be determined from looking at the code:

PID 00 - PIDs supported (01-20)
The subroutine that creates the reply message is at address 285A6.
Return value indicates that 01, 03-07, 0C-11, 13-15, 1C and 20 are supported. However, PIDs 15 and 20 will only be indicated as supported if the ECU is configured to conform to OBD-II as defined by CARB or to EOBD (Europe).

PID 01 - Monitor status since DTCs cleared
The subroutine that creates the reply message is at address 285D8.
The subroutine that counts active DTCs is at 2866A. Not all DTCs are counted: only the ones that match a specified set of categories. More on this later.
If the 5th bit of RAM location 104C1 is set, this means the check engine light (MIL) is on. Alternatively, if the 1st and 3rd bits of 10000 are 0 and the 4th bit of 104C2 is 1, that also means the MIL is on.
If the ECU is configured to conform to OBD-II as defined by CARB, the following tests are available:

Misfire
Fuel System
Components
Catalyst
Evaporative System
Oxygen Sensor
Oxygen Sensor Heater
EGR System

Otherwise, if the ECU is configured to conform to EOBD, the following tests are available:

Misfire
Fuel System
Components
Catalyst
Oxygen Sensor
Oxygen Sensor Heater

Otherwise, only the Fuel System test is available.

PID 03 - Fuel system status
The subroutine that creates the reply message is at address 286D2.
If the 2nd bit of 10190 is 0, the fuel system is open loop due to engine load OR fuel cut due to deacceleration.
Otherwise if the 4th bit of 1028E is 0, the fuel system is open loop due to insufficient engine temperature.
Otherwise if the first bit of 1028E is 0, the fuel system is open loop due to system failure.
Otherwise if the 2nd bit of 0104E6 is 0, the fuel system is closed loop, using oxygen sensor feedback to determine fuel mix.
Otherwise the fuel system is closed loop, using at least one oxygen sensor but there is a fault in the feedback system.

PID 04 - Calculated engine load value
The subroutine that creates the reply message is at address 286E2.
The byte at RAM location 100D8 is proportional to calculated engine load value.

PID 05 - Engine coolant temperature
The subroutine that creates the reply message is at address 286F2.
The byte at RAM location 100FF is proportional to (engine coolant temperature + 40 degrees C).

PID 06 - Short term fuel % trim - Bank 1
The subroutine that creates the reply message is at address 28702.
The word at RAM location 10296 is related to short term fuel % trim.

PID 07 - Long term fuel % trim - Bank 1
The subroutine that creates the reply message is at address 28712.
The word at RAM location 102D8 is related to long term fuel % trim.

PID 0C - Engine RPM
The subroutine that creates the reply message is at address 28722.
The word at RAM location 10078 is proportional to RPM. This variable is almost certainly used with fuel and timing lookup tables. I haven't located them yet, but I hope to soon.

PID 0D - Vehicle speed
The subroutine that creates the reply message is at address 28732.
The byte at RAM location 10141 is proportional to vehicle speed.
The subroutine at 29F8E is used to calculate vehicle speed, and could probably be modified to account for different wheel/tire sizes.

PID 0E - Timing advance
The subroutine that creates the reply message is at address 28744.
The byte at RAM location 103BE is related to timing advance. This variable is likely calculated from lookup tables.

PID 0F - Intake air temperature
The subroutine that creates the reply message is at address 28764.
The byte at RAM location 1013B is proportional to intake air temperature.

PID 10 - MAF air flow rate
The subroutine that creates the reply message is at address 28774.
The word at RAM location 100CC is proportional to MAF air flow rate.

PID 11 - Throttle position
The subroutine that creates the reply message is at address 28780.
Throttle position % is stored in the byte at RAM location 10102.

PID 13 - Oxygen sensors present
The subroutine that creates the reply message is at address 2878C.
If the ECU is configured to conform to OBD-II as defined by CARB or to EOBD (Europe), it will report Bank 1 Sensors 1 and 2 present.
Otherwise, only Bank 1 Sensor 1 is reported as present.

PID 14 - Bank 1, Sensor 1: O2S Voltage, Short term fuel trim
The subroutine that creates the reply message is at address 287A4.
The reply "A" byte is proportional to the byte at RAM location 10160.
The reply "B" byte is a function of the word at RAM location 10296 (same as in PID 06).

PID 15 - Bank 1, Sensor 2: O2S Voltage, Short term fuel trim
The subroutine that creates the reply message is at address 287C2.
The reply "A" byte is proportional to the byte at RAM location 10172.
The reply "B" byte is #FF.

PID 1C - OBD standards this vehicle conforms to
The subroutine that creates the reply message is at address 287DA.
If the 4th bit of 10000 is set, this vehicle conforms to OBD-II as defined by the CARB.
Otherwise, if the 2nd bit of 10000 is set, this vehicle conforms to EOBD (Europe).
Otherwise, this vehicle is not meant to comply with any OBD standard.

PID 20 - PIDs supported (21-40)
The subroutine that creates the reply message is at address 287F4.
If the ECU is configured to conform to OBD-II as defined by CARB or to EOBD (Europe), it will report that PID 21 is supported. Otherwise, none.

PID 21 - Distance traveled with MIL on
The subroutine that creates the reply message is at address 28826.
The word at RAM location 104DE is the number of km traveled with the MIL on.

Whew - OK, that's all for Mode 1. Next time I'll describe Mode 2. The ECU supports standard modes 1-8 and a little over a dozen other non-standard modes, and I plan to describe all of them, in order.

Reverse engineering strategies

2010-12-31T08:46:00.000-08:00

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!

Some disassembly required

2010-12-31T08:04:00.000-08:00

(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!).

Preparation: Gather your tools and information

2010-12-09T02:06:00.000-08:00

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.

So you want to hack your ECU. Where do you start?

2010-12-04T15:59:00.000-08:00

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.