RomRaider

Go easy on me fellas... First time...

I posted about learning to create definitions... But I really never delved into the defs to look at them... So did... And here is what I cam up with

at the top of the ecu def in romraider is
</rom>
<rom base="32BITBASE">
<romid>
<xmlid>AZ1G400Y</xmlid>
<internalidaddress>2004</internalidaddress>
<internalidstring>AZ1G400Y</internalidstring>
<ecuid>6642784007</ecuid>
<year>09</year>
<market>USDM</market>
<make>Subaru</make>
<model>Impreza</model>
<submodel>WRX</submodel>
<transmission>MT</transmission>
<memmodel>SH7058</memmodel>
<flashmethod>subarucan</flashmethod>
<filesize>1024kb</filesize>
</romid>
this defines the ECU, year and if the ecu is 16 or 32 bit. Then bellow are the individual addresses for the location of the tables in the memory... Does IDA also define the internal string and ecuid as well? Or is that a different process?
The listing of the 32 bit or 16 bit base in the rom is so a larger more universal area in the definitions can be referenced? OR is everything we need to define the rom listed per ecu in each rom? IE you could run this 09 wrx ecu with only whats listed between the </ROM> points?
If there is another part of the definitions referenced using the 32 or 16 bit base in the </romid> i cannot seem to find it...

Next it looks like defining the logger is as simple as placing the address of the area of memory you need under the the param. So you would have the param of say the map sensor.. This would be defined under the area in the logger for that sensor, then under the ecuid and then the location of that in the memory. And then to get the corrected boost you have the equation listed and written elsewhere int he definition. But you would only need one equation for the whole definition since you can reference the different areas of the memory using the ecuid right?
So really the equations could stay the same for all MY's just the ecuid and everything under it changes per parameter that needs referenced, if i am understanding this correctly... ALso it looks like the logger is referencing for code that is always changing rather then ROM the ecu def is looking at... Is this where IDA comes into play to tell the two apart?

Am I on a good start here or way off in left field? I have minor hex editing experience but nothing at this level... So go easy... flame lightly if im way off...

There's nothing wrong with asking basic questions, you gotta start somewhere...



If you look at 0x2004 in the ROM, you'll find the ASCII bytes for AZ1G400Y. I think you just have to stare at the ROM for a while and look for something that looks like an ID... There probably is no automated way to find the address, or EcuFlash/RomRaider wouldn't need it to be in the definition. My LGT's ID is at 0x2000 so you probably won't have to search a large area.

My ROM, A2WC522N, has base=A2WC521N since the two are almost identical. If a ROM is unique, the definition has to specify where all of the tables are. If a ROM is similar to another ROM, "base=" can be used. I assume that if base= specifies another ROM, you can still override the addresses for any specific tables that aren't at the same address, but I haven't actually tried that.

The XML you pasted is for ROM definitions, which contain addresses of tables in ROM. The logger only looks at information in RAM. Logger stuff is all in a separate file, logger.xml, which has a different format. The CPU itself supports a certain range of ROM addresses, and a certain range of RAM addresses, so that's information that has to come from the CPU data sheet. It's also in my how-to article about using IDA.

Logger.xml's format is a little bit simpler - the first section contains parameters that are common to all ECUs, and the rest contains parameters that are unique to each ECU, and there is no "base=" stuff. Each parameter has one or more scalings that convert the value in the ECU to something more readable.

i was wondering if looking for the id would be tedious like that or not... But i guess if they are usually in the same area or in same ball park its not too bad... What about differences in the XML id and the ECU id? Is the ecu ID something that is found on the ecu itself? (same question for memmodel)... Where as the xml ID is found by just knowing where to look?

At first I was thinking the romraider defs for logging and editing would be similar... But now I see the logger and editor are very different and ecu flash definition is more closely related to the editor... Almost identical...

With base=32bit where is the 32bit? If this is referencing something that is common to all ecu's then that definition is also located in the xml correct? I guess I just didnt see it.. It was alot to try to read over in the hour i spent with it... So it looks as it the base = is making life a little easier by only having one location for all the universal material? We could have no base= and list all the information per ecu correct? But then we would have much larger definition files and probably even a file for each ecu listed... Alot like ecu flash does right?

The logger is a constant stream of pids and the locations of each pid. Each Pid beginning with a conversion at the top and then below the individual locations of where the code is in the memory for each ecu ID when it is unique...

It looks like pids that are shared with all ecu's are at the top of the definition. This surprises me since the location in the ROM seem to change so much more. Is it just by sheer design that the code is shared in the same location across so many ecu's that we can use a universal definition at the top of the logger? I really expected to see something more like whats in the ecu def file in both ecu flash and romraider when I opened the logger file...

When starting to define a rom... You read the rom from the car with ecu flash and no definition... But what about flashing? Is it possible to flash without a definition? or is that asking for bricks without ecu flash knowing where what is supposed to be located?

Will have to read your IDA how to, im sure that will shed more light on things for me... Is there something I can use other then IDA? I has no 1k to spend... And this is more of a hobby for me then a job lol... I just dont have access to that kind of program... Any other suggested reading on this?

Edit- Im probably going to try first at my friends 08 LGT... Romraider defs are available for it in the ecu editor... But I cannot find ecu flash or logger defs... Only some params/pids log... but im missing on some I would like to have... And since the romraider editor is already good I can create the ecu flash with that... Just a little fuzzy on the creating from scratch part and logger part... But that probably wont become clear until I delve into IDA or like program..

The last word of the ROM is a pointer to the ID location.

The load order is:
For the matching ROM ID load the 'base' (if defined),
If the 'base' definition also has a 'base' parameter then load that, and so on.
So what happens is the logger builds a def tree of 'base' definitions starting with the matching ROM ID as a leaf and the final found base as the trunk. Then the tables are read in for each ROM ID listed and as the defs are read from the trunk to the leaf the various defined parameters are used to populate the tables.

The logger also reads the ECU defs listed in the Editor's def manager to build a cross-reference from ECU ID to CAL ID.

The ECU ID is in the ROM two, it is read out by the Logger when you connect to the ECU to log something.

Editor def and EcuFlash def are similar, but there are enough differences that they are not interchangeable.

Yes the 32BITBASE or 16BITBASE are the two common defs where all the detail, except for addresses are defined. Then when you create your specific ROM ID def you only list the table names that you need from the BASE def and add the specific address and size if they are different from the BASE. Look at one of the Experimental RR Editor defs to see what I mean.
You can build a def with no base but you will then need to define ALL of the required parameters for each and every table in your single def.

The Logger def has three sections, <parameters>, <switches> & <ecuparams>.

<parameters> & <switches> are lists of what we refer to as Standard parameters that are well known logging items. These items are filtered when the Logger connects to the ECU and reads the 'init' string. This init string tells the Logger which items are valid for this car and which are not (and hides those).
<ecuparams> are items that can only be found through ROM disassembly. They refer to the RAM location for items we wish to log that are not avaialbe as Standard parameters or where we wish to have higher resolution than we can get with the Standard parameters. These are ROM specific and can change from version to version and need to be found and validated with each ROM release.

EcuFlash needs a def, but it only needs to know the flash method and ROM size info, basically just the stuff you put in the first post.
You only need to define the tables if you what to edit them in EcuFlash.

Did you read through the links I put in my reply to your other post?
Pretty much everything that you will ask about the ECU is covered in some topic in the ECU Analysis forum already. After many months of reading and searching you will hit it all I'm sure. That's where I got all my info from.

Yes, it's in there...



EcuFlash has 16bitbase.xml and 32bitbase.xml files in a "bases" directory next to all the other Legacy/Baja/Impreza/etc directories.

I just noticed that it says Impreza STI in the base definition, even though it's re-used by the Legacy and Baja. Not that it matters, since the other definitions take precedence, but it's kind of funny.

I never noticed that. Thanks!

Identifying the ROM Cal ID

Wow... This is all great info guys...

NSFW: I didnt see the 32bit base since it was labeled as sti I just skipped right over it; thinking it was for an 04 sti lol... Thanks for that! Ill have to compare that to the rest of the definition...

dschultz: I noticed the biggest differences between the ecuflash and romraider logger is terminology... In most definitions I have looked at so far the layout is very similar and the def is also almost identical with a few very subtle differences that could almost be changed in whole... Such as "storageaddress" in the editor being labeled as "address" in ecuflash...

I DL'd the sh2 and compiled it using python 2.7 (the post reads to use 2.6 but thats not available for DL anymore)... After that im a little stuck... Do i need to compile python as well? There was not much in the way of a read me with SH2... Gets you to the point of running dis.py and thats it... I did not compile the python 2.7 only DL'd and installed it... (not sure if that was enough or not)...

I have a copy of a 2012 sti ROM I just pulled from my friends car... I was going to use SH2 to look for the ROM cal ID... Then use the 2011 def found on here and see how close we are... After that I will look through the rom using SH2 at the tables that are not defined or not defined correctly fixing them one by one... Then using the ecu editor create a definition for ecuflash... Then use SH2 for the definition of the logger... Sound about right in terms of progression?

Throttlehappy: I see your using a hex editor and not SH2 or IDA... How is using that in comparison to the others? Im not very familiar with python so is that a good place to start? What are the largest differences between using IDA and SH2 and using the hex editor in comparison to the IDA and SH2?

EDIT> used HxD to find the rom cal id... AE5K500V for 2012 sti... ... right at 00002000

AE5K500V is actually at 00002004(2004), the top row defines the final integer in the cell address

It now takes me around 3 to 5 hours to define all the common 2D and 3D tables, along with most of the single cell values as well. I know what I am looking for in finding the length of X axis values(say 12 values long), then the Y Axis values(say 12 values) then I know I have a 144 value long Z value. You will notice I use a comparison between a known ROM and the new ROM.

Can I also suggest, in HxD going to View> Bytes per row and change to 16 then View>Byte Group Size> choosing 4 as the 4 byte will make it much easier to see the values(and looks more like my posted picture)

To find the Ecu ID, use HxD and search for: F3FAC9(as a Hex Value, not Text String) which should be in the D3D00 region of the ROM and the Ecu ID will be the 10 values prior in Hex and will have 07 in front of the F3FAC9

For example, the Forester S Edition one I did was: 71325140 07F3FAC9 with the Ecu ID being 7132514007

Really comes down to what method you are comfortable with, I can handle Hex as I use it at work a fair bit

As an example:
Copy 3F660000 3F700000 3F7A0000 3F820000 and then do a HxD search, past in the values and do a Hex Search. It should be in the D3400 region and where ever the 3F8C8884 value appears(ie D3400, D3404, D3408 or D340C) is where the start of the MAF Scaling is. Then use 3F8C8884 3FA21A01 3FB9E4B0 3FD408EA to find the Storage Address
Forester S Edition one was:
<table name="MAF Sensor Scaling" storageaddress="D3530">
<table type="Y Axis" storageaddress="D3458" />
</table>
I would then modify the storage address values in my new Definition.

Did you post that stock ROM yet?

Throttlehappy: Where did you come up with the F3FAC9? Or is that just knowing where the ecuID would be from previous definitions?

When you say define the table 3d and 3d and even even the singles... Are you actually defining what each table is? Or are you just going through fidning which table is which? IE this is a 3d table since I see its 12x12 or 144 long so I will define it as such... Then when you can view the table in romraider is when you label what each table is...

Thanks for the hint on the hex editor... Searched F3FAC9 and found 11 81125950 ... However it was in the d9d10... attached is a screen shot...

dschultz: I did not post the rom since I wasnt making a request to have a definition written... However if you want to take a look I have attached it here (it is a stock 2012 sti sedan USDM rom)... If you would like I can make another post with the stock rom and request for the definition... However there is not huge rush. I have not seen anyone else make a request for this rom...

EDIT: Wow my screen shots are horrible... Is there a ss option in hxd that im missing? After I print screen and scale the image to upload it becomes to distorted for any use..

quick update... I was able to open the 2012 rom in romraider using the information you guys helped me to find... I defined the 2011 sti as the 2012 and opened it with all the 2011 definitions in hopes that at least most of the tables would be similar... No...

Looks like each table needs to be defined... Some tables look as though only the x and y are incorrect.. But the data for the ram is correct... IE in fueling im seeing propper fueling numbers just not in the correct spots with 0 in both x and y on the table...

The next step is then to define each table in the rom...

This comes into play by using the SH2 or IDA.. Correct? I see some guys are using the hxd... But I dont really see how... That must seem like an ignorant statement lol...

You'll probably get a kick out of this:
http://subdiesel.wordpress.com/ecu-anal ... -software/

It finds 2d and 3d tables in the ROM, but figuring out which tables do what is not easy. Timing, fueling, and boost are usually easy to recognize, though.

The ROM itself determines what the tables are for. Dschultz is talking about creating XML so that RomRaider (and whoever is using RomRaider) knows what's what. That XML is usually referred to as a 'definition' for the ROM in question.

For screenshots, try opening Windows' Start menu and typing 'snip' and see if the Snipping Tool comes up. I think it's been included with Windows since Vista but I'm not really sure. (And/or, it might be available as a download from Microsoft's site.)

Renesas (the manufacturer of the CPUs in the ECUs) makes a software package called High Performance Embedded Workstation (HEW) for developing software for those CPUs. It also has a debugger, and by loading a ROM into the debugger it will show you the disassembly. So that's another tool to be aware of. It's free, and my 'hacking with HEW' thread (in this subforum) has info about where to download it.

What really sets IDA apart is the way it helps you annotate and navigate a disassembled ROM - giving names to memory locations as you figure them out, adding comments etc, following references to and from locations in memory, and so on.

Ill have to go through the readme... It looks as though it will define the tables and you can export them into an xml... Then I guess its up to us to determine whats what...
From the looks of it that would save us (throttlehappy) about 3-5 hours of table consolidation into 2d and 3d sections right?

I wonder it there is a trial version of IDA somewhere...