RomRaider

Gidday Guys.

I am attempting to get the addresses from my Mitsubishi ECU so I can log from it with the Evoscan software.

My ECU;

Chip MH8302F
Rom id B3500005
Rom is as far as I know a SH7055

I paid to have the rom 'xml' file created for tuning with 'EcuFlash' I have most tables etc and a heap of other stuff i am still trying to learn.

I have opened the rom with IDA and done the basics as mentioned at the start of this thread.
From there I am a little more confused. The addresses mentioned in the xml file don't seem to relate to the IDA disassemble.

So I am assuming there is some offset but don't really know how to find it.

I did try and run the xmltoidc but nothing doing, I am assuming because the rom was not read by Romraider, xmltoidc did not recognize my xml ?

If I could get IDA to recognise the maps already defined in my xml then I would be streets ahead.......

Would like some pointers or advice as I am a total newbie in this field
Yes I have spent the past two months reading and trying different stuff....

Maybe interesting, maybe not My car is a 2009 AUDM 4X4 Mitsubishi Triton.....
Hence the lack of knowledge about my ECU, if it were an Evo.............

I am very patient and will eventually succeed in my quest, hopefully you guys can point me in the right direction, please

The addresses should line up for the SH7055. The ROM mapped from a base of 0x0 up to the top of 0x80000 (512kB). Can you post a copy of the stock ROM?

The XmlToIdc app will only work on an XML file that is written in RomRaider format. It doesn't parse EcuFlash format right now. So you could try to convert the EucFlash def you created to RomRaider format. It's not hugely different, only a few tags. Then XmlToIdc can at least create for you an IDA script to load which will mark the tables. This works best when you first have the ROM disassembled for the most part.

MH8302F is M32R based processor, not SuperH.

OK rom is here,




OK cool, I had thought M32R but the xml I had done (paid for) states the SH7055, so i assumed it to be correct, posting it below, would one of you be able to confirm ? I guess if all the info is correct then should work better with IDA. Anyway it would be good to clear this up !
ADMIN: DEF REMOVED AS IT IS INDICATED TO BE A COMMERCIAL PRODUCT.

Actually IDA does not give me an SH option when it loads the rom as I select the M32R option, then the M321764F.

I got the info from another xml another gent made for me (free) as below....

This ROM is for Mitsubishi MH8302F M32R family with Mitsubishi bootloader.
Command set, flash areas and registers correspond to M32170\32174\32176 family.

ecuFlash 1.43 has a bug and wipes out just 0x00000:0x5FFFF area and very often (probably always) stops writing after 0x4FFFF.

Do not erase\flash this ecu if you do not have another proved flash programming tool.

Thank you Sasha, yes I use the Russian program 'MMCFlasher'

Ecu Flash would not read the rom.....

Should I write the rom id info from the smaller xml above into the the larger (SH7055) xml ?

1 - It does not matter what processor is "defined" within .xml if you do not use ecuFlash for flashing.
2 - smb350 is Mitsubishi bootloader UserSecurityKey ( required for flash erase/write/write protect ) and is also a proper ID for this ROM.

OK so I am attempting to work out this rom.

My first task is to work out what a sub routine is doing. The first reference in the rom links to the sub 31E4.

I can track a couple of the references but stuck with some mnemonics, google revealing all sorts of stuff, I could read for hours and am still not clear one one mnemonic, here is a few I can't define as yet;
mvtc
psw
spi
nop

This all very confusing but I am determined to learn and benefit eventually

I can tell you that nop means 'no operation' and basically does nothing.

For the rest, check out the M32R docs here: http://www.evoscan.com/technical-vehicl ... ssassembly

Ah yes thank you, that is what I have been looking for

Typical I have been googling for hours on end and the manuals are right under my nose

Time for some reading now ......

I am yet to find a reference for ;

Attributes: thunk

As seen here ;



From what I have read it seems Ida puts it there to explain what the function is doing.

In the above case it seems to me that all sub_138 does is collects values from sub_1F3F0 and sub_66024
then it puts the values into sub_3678

Please tell me if I am on the right track, or not

You are correct.
This sub is called from sub_1F3F0 and calls( or branches to ) sub_3678.
The next time this sub is called from sub_66024 and calls ( or branches to ) sub_3678.

There is no word about values collected and transferred. You should investigate calls.

Thank you, that is good news as it means I am on the right track.

Yes I can see now that no values are exchanged, when the sub_138 is called it simply calls the next sub to probably provide values etc.

I have a bit more confidence now

Continuing my reading/research......

Oh what about the 'thunk' ?
Is it something Ida writes? and does 'thunk' just describe a sub routine that calls another sub ?
Obviously the rom is full of these to cover all operating conditions ?

'thunk' stands for a portion of code.
Here is a special case where the program code is not directly compilied from C code. It is optimized and provides some entries into the subroutine that is not usual for C.
In many other cases 'thunks' will be just the subroutine code partitions.

To be sure whether values are exchanged or not you need to review the calling code and the called code. When values are exchanged there is three possible ways this can be done.

1. calling code writes values to RAM and called code reads them from RAM
2. calling code loads the STACK with values and called code reads them from the STACK
3. calling code loads registers with values and called code reads the registers

When the called code returns it can use the same three methods to return values to the calling code.

Also note that the STACK pointer is usually register r15, but not always. The address of the STACK can be transferred into other registers and an index addressing method can be used to read/write values from the STACK just like they can be used this way by RAM read/write instructions.