logic

iTrader: (2)

Right now, if you're really interested in getting started, the minimum software you'll need is a copy of IDA Pro. Someone can post a disassembly that IDA generates, but that's a really raw way to look at and work with the source, at least right now; you don't get all the tasty back-references, for example. (If you just want to see what we're looking at, here's a recent export of 88590015 that I've been working with, it's about 8MB; I guarantee that someone like mrfred could provide a much more complete/documented disassembly, though).

(I've been working on something that might reasonably work as an IDA replacement for people who can't afford it and aren't comfortable obtaining it by other means. Hopefully I'll be able to announce something in the next week or two.)

Danieln

iTrader: (1)

Hi guys.....

I will add the basic starting steps for IDA Pro

Big thanks to Tephra , mrfred , logic , AndyF, acamus and others who tried to explain a bit of ECU Disassembly process and how those hexadecimal numbers are converted into something more readable.


What I do is like fallows:

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.




If something was wrong interpreted please fell free to correct me.

logic

iTrader: (2)

Great idea, thanks for doing this! A couple of quick comments:

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

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

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

See above; you should repeat this action for every unique address in the interrupt vector table.

This is a good idea: relating the tables the reader knows in EcuFlash to tables they can find in the ROM.

One other thing I usually do is change the target assembler (under the "Options" dropdown) to "GNU Assembler", since most of us probably don't actually have access to the shasm assembler. It's not a big deal, but I find it helpful to have the code that IDA generates looking like the code you actually put through an assembler later.

There's another thread similar to this idea over here; maybe there's some stuff in there that can be incorporated?

Danieln

iTrader: (1)

Thanks for your updates mate...

Maybe for some people this looks like another language but this is the only way to accumulate much more informations about this.....

Let`s go further.....

In order to dig much further into this language we need a real example of how to use the software....

Again.....good idea for continue with this thread after tephra

I still believe that information about this is mixed at this moment.

I ask so many times help for finding some tables for my ROM ( big thanks to mattjin, deepnine, tephra for their help).

Danieln

iTrader: (1)

It`s anyway so nice to dig into the ECU`s if you know how to do it...
That's why I left the Hydra EMS in a box somewhere.....

chaotichoax

iTrader: (149)

added to important topics thread...interesting stuff

ziad

iTrader: (1)

thanks logic/ed... even a basic disassembly will give me an idea of what to do... i have already found a few tables (before the thread) and no i do not understand assembly yet.

mind you the experement with direct boost didnt work

acamus

I should post the autodisassembly script now
Anyway Ceddy has posted it already. Just follow the steps of installing it.
It works for H8,SH2 and partially m32r.
And jcsbanks wrote a review for SH2 part.
So you can enjoy it.

@logic, yes you can share it at your wiki together with cfg files,
I hope you have structure scripts for maps and axis, upload them as well.
Maybe I can send you corrected m32r analysis dll to upload.
If anything is missing please drop me a PM/mail.

03whitegsr

iTrader: (8)

Awesome thread. Thank you!

My programming knowledge is pretty weak. I get the basics though and am interested in learning more.

This thread has been able to fill in a lot of the gaps that other threads have left. I have fianlly got a ROM fully loaded into IDA and feel like it was done properly. I have been able to make sense out of locating tables and linking axis to the tables. Now I feel more motivated to read through the manual on the chip to get a better understanding of how the code that uses the tables works.

Now that I have the code broken down, what would be my next big step in getting a better understanding of all this?

You guys mention a GNU assembler? Is this a program that converts this file into C++ or something?

Once I have found a table, is there a way to display the table in IDA so it looks similar to ECUFlash, instead of just a long stream of bytes?

logic

iTrader: (2)

Good questions!

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.

Does that help?

Danieln

iTrader: (1)

Thanks for all the infos mate,

Cheers

Danieln

iTrader: (1)

logic what do you mean by *do that 254 more times from 0x4 to 0x3FC* ???

logic

iTrader: (2)

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".

Danieln

iTrader: (1)

Hi logic,

I try to complete my setup for direct boost control for a EDM 88840017 rom and the only missing table is SHLR->SHLL for EBC.

Seems that this address is located at 4A01 in few different roms so I assume that also into my rom it will be at the same address.

I just want to define correct this address so my question is how can I find the correct location of this into IDA?

If 88590015 has this address at "41B84" (<table name="SHLR->SHLL for EBC" category="Turbo" address="41B84") where I will find this for 88840017.

If I look into the code of 88590015 I get this result if I look for 41B84...



Can you please help me out with this or point me into the right direction in order to find into IDA the right location of this for 88840017?



Thanks

logic

iTrader: (2)

For me, this is typically a pattern recognition problem: look for duplicate code between the ROMs. There's surprising little code churn between various ROM IDs (even Evo VIII to IX), so you can usually find the code you're looking for with a little fuzzy screenful-by-screenful reading, or by looking at the graph overviews and looking for visual patterns.

Basically, open both ROMs side by side (two monitors or widescreen helps here), locate the code you're looking for in the ROM you know the location in, and take a look through the routine it's part of (since, in this case, we're talking about a code patch, not data like a table; for a table, we'd be more interested in locating the corresponding code first). Get a feel for what it is you're looking at; a helpful exercise is to trace the code back from where you are to the main loop or the interrupt that kicked it off.

Then, try to retrace your steps in the other ROM; if you traced back to the main loop in the other one, step forward through the new ROM following the same steps. Not everything is going to look the same, which is why it's handy to have both open at the same time; you can compare code at each step, and be able to tell visually whether or not you took an obviously wrong turn.

Another more brute-force approach (again, with both ROMs open) is to just jump to the location you're suspecting the code is at in your new ROM, and searching upwards and downwards from there 10-15 screenfuls, and compare what you see to the code in the original ROM.

This goes without saying, I think, but it's almost impossible to do this without identifying some known common pieces of the code you're looking at in both ROMs, so it's easier to locate the code you're after. For example, if the RAM addresses in the original ROM are "known locations" (ie. MUT entries, or things you can readily identify), give them names in IDA, and do the same thing for the addresses of those entries in your new ROM. Then, rather than seeing two chunks of code with a bunch of "FFFFXXXX" references, you'll see named references ("MUT_83", "STFT", etc), making it MUCH easier to compare things. Registers are another point of commonality, as are plenty of "known" routines (interrupts, the main loop, etc). These are all things that can significantly improve your chances of both understanding what you're looking at, and finding it again in another ROM.

Sorry for the poor explanation, but it's really a fuzzy kind of activity. This is one of those areas where people who like pattern puzzles (Sudoku, Sokoban, etc) do really well.