Evo ECU Dissassembly


Evo 7/8 ECU SH7052F
256K ROM 12K RAM
Manual (3.5Mb)

Evo 9 ECU SH7055F
512K ROM 32K RAM
Manual (4.7Mb)

Evo7/8/9 SH2 Processor
Appendix A - CPU Instruction Set
Manual (2.5Mb)




Evo X ECU M32R
Instruction Set Manual (0.5Mb)

Evo X ECU M32R
Chipset Manual (0.5Mb)

Evo X ECU M32R
Registers Manual (0.4Mb)




Evo 5/6 ECU H8/300
Instruction Set Manual (1.4Mb)

IDA Pro - Keyboard Shortcuts
Quick Ref Sheet (0.1Mb)



DataRescue IDA Pro Advanced 5.5 + Hex-Rays 1.1 (87.5Mb)
IDA Pro Advanced supports SH...
Mitsubishi M32R(comes with source code) supported in IDA Pro Advanced & IDA Pro 64 bits
and Hitachi SH1, SH2, SH3, Hitachi SH4 - Dreamcast
Supported Processors List:  http://www.hex-rays.com/idapro/idaproc.htm

What is Hex-Rays 1.1 Decompiler?
Converts decompiled code into a human readable C-like pseudocode text

Hex-Rays IDA Pro Advanced SDK v5.6 [5.69 MB]
SDK has extra supported chipsets such as H8
Tutorial for using the IDA SDK can be found at this location:

The IDA Pro Book (32.5Mb)
Chapter 19: IDA Processor Modules

IDA Pro (4.0Mb)
Chapter 9: IDA Scripting and Plug-ins
Page 84: Graph View

As the most complex of IDA's modular extensions, processor modules take time to learn and even more time to create. However, if you are in a niche reverse engineering market, or you simply like to be on the leading edge of the reverse engineering community, you will almost certainly find yourself with the need to develop a processor module at some point. We cannot emphasize enough the role that patience and trial and error play in any processor-development situation. The hard work more than pays offwhen you are able to reuse your processor module with each new binary you collect.

Other documents and links:
Hitachi SH-1/SH-2 disassembler sh2d020.zip from http://www.trzy.org/
Good clean code, takes care of the boring part of the problem (transcribing and/or cut-and-pasting all the instructions from the software manual), if someone wanted a C-based starting point. :) But there's a lot more code needed: specifically, branch and delayed instruction handling, register tracking for register-relative branching, and some sort of memory model representation (so you can do a final output pass, rather that trying to print everything out in-line).
IDA Plug-In Writing in C/C++ idapw.pdf

Debugger - Lauterbach TRACE32
Target Interface

Logic's (Ed Marshall) Python SH2 Disassembler EvolutionM.net Forum Thread

3 webpage article on how basic mathematics in assembly code works

A Quick Introduction to Assembly Language Programming




H8 memory model:

The H8s are in Mode 4 Extended Max
ROM Enabled, with a 16-Bit External Bus
(You can check this by looking at Pins 81-83)

0 - 1FF Vector Table
200 - 3FFF On Chip ROM 16K
4000 - EE7F Unused
EE80 - FE7F On Chip RAM 4K
FE80 - FFFF On Chip Registers 384 Bytes
10000 - 1FFFF On Chip ROM 64K
20000 - 2FFFF On Chip ROM 64k

The ROM is Loaded to 10000-2FFFF.
Parts of 10000-13FFF are copied to 0-3FFF (Most single byte variables are referenced at 0-3FFF, maps are referenced 10000-13FFF.

Creating H8 Dis:

Using this method you end up with only one item in the Problems Window, an Out of Bounds jump to F290. This is where the kernel is loaded into memory and executed.

First Download -> idc.zip
h8_reg_names.idc -> Will rename all the registers.
onload.idc -> Is a modified version of Acamus's Auto Disassemblier. It will automatically create segments for you, convert the Interrupt Table addresses, and disassemble 90% of the code.

0) Put onload.idc in -> C:\Program Files\IDA\idc\

1) Start IDA and select New. In the New Disassembly Database window, select Cancel. Then Drag your ROM into the Window.

2) At the Top select Binary File. Processor Type select Hitachi H8/500. And deselect Rename DLL Entries. Then click OK.

3) In the next window, change ROM Start Address to 0x00010000.
And change Input File:Loading Address to 0x00010000.
Change nothing else. Then click OK.

4) When the Please Confirm:Perform Automatic Fixups Window appears click Yes. Then wait a few seconds.

5) Then File->Load File->Additional Binary File. And open your ROM.
Loading Seg = 0x0
Loading Offset = 0x0
File Offset in Bytes = 0x0
Number of Bytes = 0x4000
Then click OK.

6) File->IDC File. And open h8_reg_names.idc

All Done!


h8_reg_names.idc renames bytes. If the REG is a word it won't rename the tail byte.

The next step is to Cross Reference the MUT Table. For example the memory address at the MUT Table 0x06, rename TimingAdv

In the 2EB00 area there is a list of map addresses I call Ptr2Maps.
Each address will repeat 8 times. Most of the important maps can be found here. And the code will reference this pointer address instead of the maps actual address.

The Periphery Bits, Map Pointers, ROM Ids, etc. All come in a list of eight.
They are selected by a byte I call PeripherySelect, it is most always zero and selects the first item of the lists.

Starting at 20000 is the Flash code. It is identical in all H8s I've looked at.
But there must be some differences else where, an attempt to Flash the Evo5 ROM into my 98 DSM ECU, bricked the ECU.

For more info on H8 ecus, see my H8 Ecu Wiki -> http://ceddy.us/?page_id=161

Actually if you add some lines to the script you may get additional binary done automatically.

// ***********************************************
// ** load file into IDA database
// arguments: handle - file handle
// pos - position in the file
// ea - linear address to load
// size - number of bytes to load
// returns: 0 - error
// 1 - ok
success loadfile (long handle,long pos,long ea,long size);

Moreover the registry and interrupts shall reside in \IDA\cfg\H8.cfg


There is useful feature in IDA->Options->General->-Disassembly->Display Dissasembly Line parts-> Auto Comments
so at the start you do not have to cross-reference the manual.
extu.w r10, r10 ; Extend as Unsigned (Word)
shll8 r10 ; Shift Logical Left 8
mov r10, r4 ; Move Data

gdb supports m32r
in gdb, try: target m32r dev
what is gdb? gnu debugger. standard linux tool

create a linux virtual machine.

Evo8 ACD Dissassembly notes:

maps don't have a link connecting them to the sub-routines, in the SH4 disassembly's there would be a referance in the header part of the map, this is absent in the H8 from the ACD, and I really don't have the skill to work out how to get around this, so if one of you more able gents could let me know, that would be great.


Poking around in the maps section, there seems to be a large number of maps undefined. Are there any updated xmls for these? Reading a few threads, it is suggested that for example the Ralliart C1 ROM has three modes, but as all the maps I have defined are the same, there must be others influencing the behaviour of the ACD.

---End Quote---

The references are for manual go thru as of now, I have not had enough time to create some reasonable script. The problem is that references are 24bit values.


e.g. axis


mov:i.w #0x3454:16, fp

mov:i.w #0x3464:16, r5


press Ctrl+R while having cursor at 0x3454, select OFF32 radio button in Enter reference information dialog, select correct base either 0x10000 or 0x20000. Press OK.


You should get

mov:i.w #(unk_13454 - off_10000):16, fp

mov:i.w #(unk_13464 - off_10000):16, r5


Yes there are a lot of 2D maps that play role in the output.


Getting Started

What I do is like follows:
1.Open the program
2.Use "open" from file tab and open your hex file
3.One window will appear (load a new file)
4.Change the procesor type from "Intel 80x86 processors: metapc" to "Hitachi: SH4B" and press ok
5.A new window will appear called "Disassembly memory organization.Into the window you will have "Create RAM section. Change the RAM start address to 0xFFFF0000 and RAM size to 0xFFFF and press OK.
***At this moment another window will appear (chose the device name) thank press OK.
The hex will be shown on your idapro window.
6.Now you would need to go at the start so use keyboard "G" for jump to address. Press "G" insert 0000 and press OK.
***Now you are at the beginning of the code***
7.Press keyboard "D" 3 times and that reference will transform into another number
8.Double mouse click on that new number and you will be moved to that location.
9.Now you need to press keyboard "C" and wait. This will convert the code from binary into assembly.It will change to something like this.
From here you can search for ROM subroutines.
Use Keyboard "G" to jump to the location into the code.
For my MUT table I open my xml file and from there I see the address with is 37944.I press "G" and jump to 37944 location than on the right I will have the subroutines for that table.
My MUT 00 is 6A09.You will see it into the code also as FFFF6A09.
Just rename your 37944 with MUT TABLE for example in order to read it after.

Just FYI: the RAM segment for an VIII ECU is 0xFFFF8000 with a size of 0x3000, and IX ECUs are 0xFFFF6000 with a size of 0x8000.
Then there's a third segment that I usually create for the hardware registers, at 0xFFFFE400 with a length of 0x1460. (On the VIII ECU, it's FFFFE400 through FFFFF85F, while on the IX it's FFFFE400 through FFFFF83F; for simplicity, I just define it as the wider VIII range.) For details on this segment and what addresses are tied to what registers, see Appendix A of either the SH7052F manual (for VIII ECUs), or the SH7055S manual (for IX ECUs).
The reason I restrict the definitions down a bit is because when IDA encounters a longword, it tries to treat it as a reference to a memory address if it falls within one of the existing segments. This helps to filter out obviously bogus references to things like "0xFFFFFFFF" or "0xFFFF0000" (there's quite a few instances of the latter used as bitmasks).

7.Press keyboard "D" 3 times and that reference will transform into another number

I'd probably add another step right after this: do that 254 more times from 0x4 to 0x3FC.  If you don't have any vector addresses predefined (like in my configuration), you can usually do that automatically by hitting "*" on the first longword, then defining an array of 255 items, with one element per line and -1 for the element width (and the "Use "dup" construct" and "Create as array" checkboxes unchecked). My configuration doesn't allow for that, but I have a script to do it automatically for me.

Every one of the addresses in the 0x0-0x400 vector table is a potential location that new code can live in; each address in that table runs code related to a particular piece of hardware attached to the ECU (the serial ports, sensor inputs, etc). Unfortunately, what interrupt is tied to which vector is scattered all through the hardware manuals I linked to above; there's no nice, easy table of them. See the name_interrupts() function in this script for what I believe is a relatively complete version for VIII ECUs (I haven't gone through the SH7055 manual to compare; I think there's a few additional interrupts defined in there, like HCAN, but our ECUs don't use them anyway.)

Basically, you want to walk through each entry from 0x0 (the beginning of the ROM) to 0x400, turning each entry into a longword (".data.l", or ".long" if you've set the target assembler to GNU); basically click on the next ".data.b" (or ".byte") line, and press "d" three times. You should see a "unk_XXXXX" value appear; double-click on that, and you'll jump to that position in the ROM. Press "c", and IDA will start automatically converting the data at that location into code.
Once it finishes, go back to the beginning of the rom, pick the next ".data.b"/".byte" line, and do it again. If, when you convert the value to a longword, the value says "sub_XXXXX" instead of "unk_XXXXX", you can skip it: the "sub" means it refers to a subroutine, which means you (or IDA) has already converted that location to code.
Once you get to line 0x400, you're done; by the time you get that far, 0x400 should actually be "sub_400".

There's also the issue of jump tables that are used in a few places, although that's a bit out of scope for an introductory document. (Basically, there's a few tables of addresses that are jumped to based on certain conditions, and IDA can't automatically figure that code out for you; you have to manually (or with a script) run through that table just like the vector table, and mark each location as code. acamus' onload.idc script does a great job of this, along with quite a few other handy things.)

The next big step?
Read the manuals; those links are the SuperH software manual (documentation on the instruction set), SH7052F hardware manual (for the Evo VIII), and SH7055S (for the IX), respectively. You'll want those handy, so you can look up what various instructions actually do (the software manual), and how memory is laid out and what addresses are registers associated with various inputs and outputs (the hardware manuals).
The GNU assembler everyone's been using is available, pre-built, at Renesas' KPIT GNU Tools website. You'll need to register to download it; once you have, you want the GNUSH Tool Chain for your platform (Windows, Mac, or Linux). They also have a version of the Eclipse IDE, if you're planning on writing a lot of new code, but I find it to be pretty overkill for what we're doing. I have some outdated docs on the wiki about using the assembler, but it's old and pretty Linux-centric.
I should have mentioned a little trick for displaying the tables in IDA in a more "visual" manner. For a 3D table, go to the address that Ecuflash mentions (ie. the start of the table data itself). Hit "*" to create an array. You want the number of elements to be X*Y (ie. for a timing table, it's 19*20, or 380), and the number of items on a line should be the length of each row (ie. the byte, in hex, just before the start of the table; for timing tables, that's 0x14, or 20 in decimal), and an element width of "0" so everything lines up nicely. For 2D tables and axes, the number of items on a line can be whatever you want; either the height/width of the table itself, or whatever length floats your boat or fits on your screen.
(Once you do that, you'll immediately notice that EcuFlash is mangling the presentation of quite a few 3D tables in a very Subaru-esque manner.  That's the result of the "swapxy" option in the EcuFlash XML.)
There's no easy way to do "scalings" in IDA like EcuFlash has; you could probably do it with structs, but the result would probably be terribly ugly. Honestly, you really don't want to mangle the actual numbers in IDA; for disassembly purposes, it's pretty important to be able to quickly see the real values, rather than the "interpreted" version.
One other thing in IDA that everyone should be aware of is comments; you can add comments of your own all over the place, as crib notes for yourself. Just move over the instruction you want to attach a comment to, and press ":", and type your comment. It's a good way to give useful names and descriptions to tables and chunks of code, without the length limitations of a label.


Last Updated on Saturday, 18 November 2017 13:17
Copyright 2009 (c) Limitless Designs LLC.