[blueroadster]

DetachmentBravo (also a member here) posted this a while back on the pgmfi forum when we were working together...Unfortunately, no reply was received:

About the 2006 model year ECUs:

A backdoor is NOT possible. Why you might ask? Well before I tackled the ungodly mess that Teradyne calls a Diagnostic System I tried to get an idea of the hardware I was dealing with. Remember I chose to be a Computer Engineer instead of a Computer Scientist, I like working with micro controllers. Well guess what, the ECUs in the FG1 and FG2 Civics are now sealed shut with an epoxy with similar characteristics to JB Weld. I broke my favorite screwdriver trying to pry the two halves apart. The strength of the epoxy is actually greater than that of the aluminum the case is made out of. What progress I did make in trying to remove the cover was mostly from deforming the metal. I stopped short of cutting the ECU open with an abrasion wheel because I would still like to drive my car when all this is done.

Time to break down the front door:

With the back door securely barricaded I think it is high time we kicked in the front door. Being a Free Software Foundation zealot (I should show you all my pictures of me protesting the launch of Vista) I am more than willing to put in the time and effort necessary to free ourselves of corporate software.

I am not focusing on the inner workings of HIM or of any other interface device because we already have a universal data transmission protocol in J2534. Additionally, my research so far has uncovered that the HIM is actually a J2534 compliant device and J2534 API dlls are included in the HDS install. My goal is to reverse engineer Honda's proprietary system for distributing ECU firmware updates. As some have already discovered, this is done through the .rwd file type. Reverse engineering these files will allow us instant access to firmware for all Honda ECUs. It will also allow us to use Honda's software to help us speed up the development process. If we can create our own .rwd files, then we can use the existing libraries and hardware to transfer these changes to the ECU.

How the .rwd system works:

Honda distributes their firmware in what they call "Program File Databases". Each database contains several master database files that contain listings of each "Program File" (a .rwd file) and information concerning its intended application. This includes car model, year, engine, transmission, ECU revision, etc. To be honest I have spent very little time studying the master database files so far. Once I fully crack the .rwd format I will spend more time looking at them.

The .rwd headers:

There are two types of .rwd files handled by the software. One appears to be a legacy version and the other a more recent version. I have only focused on the more recent version for now.

As of this week I have successfully identified the format of most of the .rwd file headers for the more recent version. It is as follows:


Code:
All newer .rwd begin with the same three byte magic number:

0x5A, 0x0D, 0x0A

Following these three bytes are exactly 7 structures of the following format:

Byte 0: Number of structure members
Byte 1: Size of first member
Byte 2,x: Data of first member
Byte x+1: Size of second member
Byte (x+1),y: Data of second member
...etc.

Each of the 7 structures carries a specific set of data. I am not sure as to the exact contents of each at this time as not all of them are referenced by the software but these are my best guesses:

Structure 1: 1 member of null length (reserved or not used at this time)
Structure 2: 1 member of length 0x04 (unknown)
Structure 3: 1 member of length 0x01 (unknown)
Structure 4: multiple members of length 0x10 (ProgramIDs *char)
Structure 5: multiple members of length 0x06 (SystemIDs int)
Structure 6: 1 member of length 0x03 (RevisionID? *char)
Structure 7: null

There are always the same number of ProgramIDs and SystemIDs. They are the only two values I have seen referenced by the software so far and are used to ensure that the proper Program File has been selected.

This is where my knowledge of the .rwd format comes to an end. In the headers there are two more values that are common to all files of the newer type but I have not yet identified their use. The two vales are both QUADWORDS that begin with 0x8000. The first QUADWORD is usually 0x8000000F but I have also seen 0x80000007. The second QUADWORD is different for every file but always begins with 0x8000. An example value is 0x80006E4E. There is a possibility that these are encryption keys or file offsets. Which brings me to my final point.

Encrypted or not encrypted:

When I first began working on these files I immediately dismissed the claims that these files were encrypted in any way. Having dabbled in cryptography and read several books on the subject I knew that files were not encrypted in a modern form of cryptography because too many patterns were easily visible. However, the most recent batch of code I have looked at has made me changed my mind. I'm still working on exactly what it does, but it appears to take data from the file heap and process it in a very simple way. The code contains a large number of compiler optimizations and advanced opcodes that I have to look up so it could take some time to completely decipher, but there is the possibility that the .BIN is encrypted with a basic substitution cypher (like a Cesarean shift).

More to come. Any input is greatly appreciated.