RomRaider

I also check the 'perform final pass' button in there for doing the vbr stuff.

My issue with adding a RAM section was some issue with virtual addressing, although it could just be operator failure .

EDIT: Attachment removed, better version here:
viewtopic.php?f=32&t=6234

--

I've attached a small executable that will convert ecu and logger definitions to an IDC file, which creates a bunch of names that will (I hope) make the code easier to follow. I'll post the source as soon as ".cs" becomes an allowed file extension.

Save a backup of your project before you apply these names. I think this works correctly but I'd like to hear some confirmation of that from people who know enough to say for sure.

It supports tables and extended parameters. I'd like it to support standard parameters too but I need to know more about how those work. I get the impression that there's probably a contiguous array where the ECU copies all of the standard SSM parameters, but I don't know where that array starts in memory. If I'm right about how that works, and if someone can explain how to find the base of the array, I can teach this utility to generate names for standard parameters as well.

You must have ecu_defs.xml, logger.xml, and logger.dtd in the current directory when you run this.

Usage: XmlToIdc.exe <ecu-id>
Where <ecu-id> is your ECU identifier, e.g. A2WC510N
You'll want to redirect stdout to a file. So, for example:



Notice the function name at the top of the .idc file.
Import the file into IDA (File, "IDC file..."), then invoke that function (File, "IDC command...").

let me know the rom id that are you running and I'll tell you the address of the SSM look-up table.

Great work!! Just got it running after installing .NET and it's working great!

One exception, when opening the A8DH201X, the rom inherits all tables from a A8DH200X, but the program didn't pick up on it, and the tables are blank. I can run it for the 200X to find them, but I thought you would want to know.

This will really make things much easier for patching.

Merch, how can one find the SSM base address for a particular rom? I'm working on a few 32bit roms, don't want to bug you every time I start a new one. If that doesn't bother you, a8dh201x a2zje11j a2zj710j.

find the ecu id and go to the xref of the start of the id. Then search for the address to the function. The first byte of the ecu id would be index position 0x1 in the SSM look up table.

For example, A8DH200X/201X, 0x56264 would be the SSM base address. Find the index position in the logger defs of a particular parameter (address node). So, for example, ECT is 0x8, so 0x56264+(0x8*0x4) = 0x56284.

Found it, thanks!

Thanks for the details merchgod, that's what I needed to know. I'll add the SSM vector address as a parameter to the utility, and then it'll generate names for standard parameters as well.

Thanks for the bug report, fujilin. My car inherits from 32bitbase, so I never ran into that. If it's sufficient to run the utility again with the 2nd ROM id, I'll just leave it as-is. I will see if I can print out the base id though so it will be easier to know when it needs to be re-run.

Merchgod, I'm having trouble following your description of how to find the SSM vector base. I'm looking at the A2WC510N image.

The ecuid string is in memory at address 0xC0000. There are three xrefs... One xref (off_48bc8) goes to an item in a list of about a dozen ".data.l" pointers in between two functions (I gather that sections like these are basically values used in the code above.) The other two xrefs are just a few bytes apart, 0x83350 and 0x8335C, which are floating in a sea of .data.l stuff.

The first xref seems the most promising, but as far as I can tell it's only used in a routine that copies the ID to a location near the end of RAM. What am I overlooking?

I should add that I looked at the A8DH200X image too, and other than both having the literal in the same place (0xC0000) they seem pretty different. But I don't see how to find the SSM base in that image either (without copying it from your post earlier - but that's cheating).

You are mixing up the cal id with the ecu id. The cal id (rom id) would be A2WC510N while the ECU ID would be 2F12785206

Yep, I found it by doing a binary pattern search for the ssm ecu id. Ex: on the a8dh201x, the id is listed as 431258410600. A search for 43125841 gives the location 0xCFB8C. Follow the first xref to 0x4E63C, which is used in sub_4E4A4. Follow the xref on that sub back to 0x56268 and you have the SSM address for the ecu id.

Here's a batch file for running the program:



Regarding the SSM stuff. I take it there's no way to determine the base address with the defs, so maybe just add it as an input option to the XmltoIdc.exe?

Thanks, guys. I found the ecu id in memory at CD7A0, xref'd to 48E84, used in sub_48CAA, which xrefs to 4ECD4, which seems to be the base of the SSM array.

I was assuming there would be an array of values in memory at that address, but apparently it's more like an array of function pointers. So the SSM code interprets the SSM parameter ID as an offset into this pointer array, then invokes the appropriate subroutine, and it's the subroutine that copies the desired data (or a pointer to it?) into a register before RTSing. I think I found the code that does array indexing and the subroutine call, but what puzzles me is that many of the entries in the SSM array have the same value (addresses of the same subroutine).

In other words, it looks like the names for the "(base + (4 * parameter_id))" addresses would be "GetParameterFoo" rather than "ParameterFoo."

Am I reading the code correctly?

spot on. Why are you puzzled by the usage of the same subroutine pointer It will be used to return a value for the UNsupported parameters

Remember, that the ECU performs a narrowing conversion on most of the SSM parameters (most are 1-byte, some are 2-byte like MAF and RPM). That is why it is a series of functions. Also, some are calculations based on two variables -> ex. manifold relative pressure (MAP - atmos. pressure) and IPW1 (ipw1 + latency). Not every parameter is supported by every ECU and some index positions are saved for future use which is why you'll see the same function repeated (returns 0xFF for example).

The ECU init is used by the SSM tool to determine which parameters are supported by the connected ECU (RR does the same thing).

Thanks guys, this makes sense now.