RomRaider

This started out as a PM conversation with Turbofied, whose Outback ROM isn't yet defined. I have a theory that might make it possible to create a definition for that ROM, based on a similar ROM, using a hex editor rather than IDA. At least, a partial definition should be possible - maybe not the whole thing.

His ROM is D2UH001T, and there's a definition available for D2UH001M that doesn't quite match up. Creating a new definition by simply inheriting from D2UH001M shows a lot of garbage in a lot of table. But amid the garbage in the fuel table, you can see some familiar sequences of numbers.

So here's the sequence of steps that I propose:
1. Get copies of D2UH001M (the "known" ROM) and D2UH001T (the "new" ROM).
2. Open both in a hex editor.
3. Open EcuFlash's definition for the known ROM, and for each table of interest, find the corresponding data in that ROM's hex editor, for the table rows, columns, and data.
4. Search for the same sequences of bytes in the new ROM. If you find an exact match, cool. If not, search for similar sequences of bytes instead - this will take some creativity and judgement.
5. Repeat for all tables of interest.
6. Post results here for a sanity check.

I can't promise anything, but I suspect that you'll be able to find most of the critical tables this way - fueling, timing, boost control, probably quite a few others.

See the "common patterns in the code" section of "Getting started with IDA and a 32-bit ROM" for more information about how tables are defined:
viewtopic.php?f=25&t=6303

More recommended reading:

Ordered list of free hex editors: http://www.techsupportalert.com/best-fr ... editor.htm
Un-ordered list of hex editors: http://www.tech-faq.com/hex-editor.html

I didn't think about that until you mentioned it. Don't need to find all the tables just one for now!!

Im desperate to view the primary fueling table, other tables not so much.

edit seems there is a and b fueling so will need to find 2 tables!

<table name="Primary Open Loop Fueling B_" address="c696c">
<table name="X" address="c690c" elements="14" />
<table name="Y" address="c6944" elements="10" />
</table>

that seems closeer 50% of table values are 14.7-13.9 which is the afr's we found on the dyno

Using the hex editor will get a few tables pretty quick. I used that method to find the dwell table in my ROM. NotePad++ is a very nice tool and has a HexEditor plugin.

My last venture into ROM defs was the 2010 STi SE.
Here's the steps I took as I wanted to learn rather than just copy stuff.

1. I obtained a copy of the 2008 STi ROM as it was already defined
2. I opened that ROM up in IDA and used XmlToIdc to mark the existing tables and the SSM routines
3. I ran an IDC script I made to mark, format and dump all the existing table, defined or not
4. I then opened the 2010 ROM and again ran my IDC script to mark, format and dump all the tables
5. Then I went through a comparison process starting with the RR Editor def for the 2008 model

One by one I went through each table and parameter and found it in the 2010 ROM. I double checked that the table was referenced by the same routines in both ROMs just to make sure I identified the tables correctly. As I did this I made the 2010 def. I estimate that it took me about 30 hours at the computer over a couple of weeks to complete this process. What I gained was a much better understanding of the ROM layout. And also the need for a process or system to manage all the ROM data def so it can be reproduced, corrected and added to.
I was thinking of putting a SQL relational database together to do that and a few little apps to parse the data out to XML format for the apps that use the defs.

I am doing this right now with the usdm 2011 wrx rom. I am a total n00b to IDA but am using this technique to make defs for the 2011 wrx. I actually have gone through half the rom an I only am running across a few tables that I couldn't find for sure. Also Wastegate duty appears to have been changed for the 2011 compared to the 2009 and 2010. I haven't pulled it up in romraider yet to do a little error checking. I did however find an issue with the 2010 rom def's relating to WGDC compensation for IAT and turbodynamics compensation for IAT. I will review them later and talk to the creator about them. I just trust Merchgod's def's of the 09 a bit more.

It works better to get the table pointers then look for common trends in table size. Well maybe not better but for someone starting out that wants a quick definition

I.E you find 5 tables that are 3d and 16x20. you notice the 09 wrx has that same trend.

Test out the locations if everything appears right in romraider then thats good enough confirmation for me!

The table that has 40+ rows is generally maf haha

ect

I've noticed that sometimes tables get jumbled around so that they aren't in the same order. The single scalar values (e.g. InjectorScaling) can be surrounded by different values as well which makes a simple binary search very annoying.

I've been spending my time working on a tool that builds signatures for subroutines and compares them. The challenge is that exact matches aren't always possible since the references to data offsets for tables/scalars (that appear in the data tables) are sometimes in a different order, which throws off the offsets in the code, making direct signature comparisons tricky. The logic also sometimes uses different registers and since the register number is encoded in the opcode, building a signature becomes tricky. My general idea is to try for an exact match first, then try for a match using "register and offset insensitive" comparison. It's tricky because our brains are so good at resolving small differences like this but expressing that in code can be tough.

My hope for the tool is that I'll be able to use it for definition validation, tracking table usage, and eventually RAM usage (indirect addressing is a bitch to follow sometimes.) Eventually, I'd like the tool to be able to find all the known RAM parameters.

I've still got a LONG way to go before I can demonstrate anything but it's fun building a decompiler

Two things:
1) Would using Python which is well integrated into IDA help as IDA knows the instruction set and Python can do the logical tests?

2) There's some work being done here too.

I've thought about this a lot but haven't even started to develop anything. As you say our brains are so much faster at reconciling the differences (once you start to see the ROM in code de-compiled format i.e.: Matrix style )

Where would one find a list of stock ROMs to download so they can attempt this? Assuming a list exists.

For example I'd like to compare E2ZJ121G (defined) to E2ZJ121B (undefined).

I couldn't find the .hex file for it by searching.

A few places:
The Base Maps Forum...
Buried in the definition forum... searching required
In the Tasks...
And Scoobypedia...