 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
| Evo ECU Dissassembly |
|
What is Hex-Rays 1.1 Decompiler?
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.
http://www.geekmapped.com/forums/showthread.php?t=853
H8 memory model: Actually if you add some lines to the script you may get additional binary done automatically.
There is useful feature in IDA->Options->General->-Disassembly->Display Dissasembly Line parts-> Auto Comments create a linux virtual machine.
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. What I do is like follows: 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.