Hi all,

I’ve seen a few people curious about this, so I wanted to put down some notes. It’s got a lot of pictures so hopefully it helps anyone who’s trying to get started I’m sure that there are many ways to go about this, probably some better but if it gets you interested then it’s done the job.

Start IDA (idaq.exe)



Select New



Select the bin you want to disassemble. Select Files of type ‘All Files (*)’ to see all possible files



From the Processor type drop down, select ‘PowerPC: ppc’ and click the Set button



Next click Processor options and enter the TOC and SDA (r13) addresses

TOC address: 0x5C9FF0
SDA (r13): 0x7FFFF0



Click OK and OK to bring up the next dialogue where you’ll create the RAM and ROM segments

RAM @ 0x600000 size 0x300000
ROM @ 0x400000 size 0x200000
Loading address 0x400000 size 0x200000

Note – this is not completely accurate, but it’s quite sufficient for disassembly. I wish I had a proper memory map  



Click OK and the next dialogue opens. This is where IDA begins the analysis.

Note - prj has written an AutoIT script. AutoIT is a tool that lets you automate actions like mouse clicks, menu selections and button presses. Highlighting one entry and clicking a few buttons is fine. Imagine doing it a few thousand times… prj’s script is for ME7.1 so you’d have to amend it somewhat for MED9.1.
Instead of the AutoIT script, I took a bit of a shortcut here. I just needed a basic disassembly so all I did was highlight all the code between 0x400000 and 0x600000 and press ‘C’. More about that in the next step.



Move the cursor to 0x400000 (by clicking there) and press ‘Alt L’ to mark the beginning of your selection.



Then move down to 0x600000 (by using the slider on the right hand pane or the page up/page down keyboard keys).  Click a second time to mark the end of your selection. Everything between 0x400000 and 0x600000 should now be blocked in grey, indicating it’s been selected.



Press ‘C’ and select Analyse. IDA will now work through your file.



You will get a warning – ‘mtfsfi, bad optype’.



Click OK, tick ‘don’t display message again’ and click OK again. IDA will continue with the analysis.



After a minute or so, the disassembly is finished and you’re ready to go  




OK, so what can you do with this?

Here’s how I go about locating a ram variable. In this example I’m going to look for the ram address of nmot_w (engine speed, 16 bit)

Start with a map you know the location of that makes reference to the variable of interest. Looking at the FR, I can see that the entry to KLPROV is nmot_w.



I also know the address of KLPROV (by comparing against a defined bin). The starting point of the whole map (including the axis) is 0x1D20C0.



The addresses in IDA have an offset of 0x40000. That means if your map is 0x1D20C0 in WinOLS, it’s 0x5D20C0 in IDA (0x1D20C0 + 0x400000).



Looking at address 0x5D20C0, you can see some blue text next to it. That’s called a cross-reference and clicking on it will take you to the segment of code that’s referring to that map address.



Basically the lookup of the map is a function. You pass it some variables, it does its thing and passes back the result.

So we pass r3 and r4 to the function 0x590434. It passes the result back in r3 again.

r4 is loaded with the map location, therefore by elimination r3 must be nmot_w – 0x7FD830

Basano!!
Really thanks!!
Wonderful work!!!

Correct,

I use Oracle VM VirtualBox.

I also got this advice from another member – legitimate versions of IDA won’t open idb files created by the knock-off versions of IDA. If you are using a knock-off, it’s fine while you are using it yourself or sharing projects with others using the same knock-off. But the real IDA has a blacklist to detect idb files created by the clones and doesn’t like them (understandably).

Hello
I think that memory map look like this:
ROM @ 0x000000 size 0x200000
Loading address 0x000000 size 0x200000

And i cut data from original file from 0x1C0000 to 0x1FFFFF,
then i load this data as additional binary file at 0x5C0000 size 0x40000

Now we have the correct addressing from beginning file, with correct subroutines address.
And correct addressing in data block.

Actually, that does match up.

I poked around with this a bit more. Take a look at this extract from a random 2.0 TFSI MED9.1 .a2l file. There’s a section near the beginning that actually lists the memory segment layouts. It describes both ROM and RAM. I'm not sure what the section at 0x900000 is , but the rest seems to align. You'll notice the bit in blue has a mapping from 0x1C -> 0x5C.

.a2l file attached

  /begin MOD_PAR "D915A_41W200"
    VERSION "MED91"
    ADDR_EPK 0x1C21F0
    EPK "55/1/MED91/5/4420.01//D915A_41W200/D915A_41W200/150904/"
    CUSTOMER_NO "5"
    USER "GS-ES/EAD1-Richard"
    PHONE_NO ""
    CPU_TYPE "GoldenOak"
    ECU "MED91"
    /begin MEMORY_SEGMENT Pst20000 "" CODE EPROM EXTERN 0x20000 0x1A0000 -1 -1 -1 -1 -1
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x20000 /*mapping_adr:*/0x20000 /*length:*/0x1A0000 /end IF_DATA
    /begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0x20000 /*mapping_adr:*/0x20000 /*length:*/0x1A0000 /end IF_DATA
    /begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0x20000 /*mapping_adr:*/0x20000 /*length:*/0x1A0000 /end IF_DATA
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Pst1F0000 "" CODE EPROM EXTERN 0x1F0000 0x10000 -1 -1 -1 -1 -1
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x1F0000 /*mapping_adr:*/0x1F0000 /*length:*/0x10000 /end IF_DATA
    /begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0x1F0000 /*mapping_adr:*/0x1F0000 /*length:*/0x10000 /end IF_DATA
    /begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0x1F0000 /*mapping_adr:*/0x1F0000 /*length:*/0x10000 /end IF_DATA
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Pst0 "" CODE EPROM EXTERN 0x0 0x20000 -1 -1 -1 -1 -1
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x0 /*mapping_adr:*/0x0 /*length:*/0x20000 /end IF_DATA
    /begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0x0 /*mapping_adr:*/0x0 /*length:*/0x20000 /end IF_DATA
    /begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0x0 /*mapping_adr:*/0x0 /*length:*/0x20000 /end IF_DATA
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Dst1C2000 "" DATA EPROM EXTERN 0x1C2000 0x2E000 -1 -1 -1 -1 -1
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x902000 /*length:*/0x2E000 /end IF_DATA
    /begin IF_DATA ASAP1B_CCP ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x5C2000 /*length:*/0x2E000 /end IF_DATA
    /begin IF_DATA ASAP1B_KWP2000 ADDRESS_MAPPING /*orig_adr:*/0x1C2000 /*mapping_adr:*/0x5C2000 /*length:*/0x2E000 /end IF_DATA
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT ExtRam900000 "" VARIABLES RAM EXTERN 0x900000 0x2000 -1 -1 -1 -1 -1
        /* AsapMLXFm - CCP_V2_1 */
    /begin IF_DATA ETK ADDRESS_MAPPING /*orig_adr:*/0x900000 /*mapping_adr:*/0x900000 /*length:*/0x2000 /end IF_DATA
        /* AsapMLXFm - KWP2000 */
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Ram7F8000 "" VARIABLES RAM INTERN 0x7F8000 0x8000 -1 -1 -1 -1 -1
    /end MEMORY_SEGMENT

    /begin MEMORY_SEGMENT Ram800000 "" VARIABLES RAM INTERN 0x800000 0x8000 -1 -1 -1 -1 -1
    /end MEMORY_SEGMENT

Looking at the checksum tables - clever! 

Again from the .a2l, perhaps 0x1C0000 is related to the e2p... Only a guess though. I know the e2p shows up in a ram mirror as well but that's slightly different.

        SERAM
            /* SERAM_A */ 0x1C0000
            /* SERAM_O */ 0x1C0000
            /* SERAM_U */ 0x1DFFFE
            /* SERAM_E */ 0x1DFFFE
           /* Flash address */ 0x000000
           /* RAM address   */ 0x000000
              /* Data Read   */ 1
              /* Code Verify */ 0
              /* Code Read   */ 0
              /* Load mode   */ 1

I tried to copy the lines, then create a new segment from 0x5C0000 to 0x600000, but IDA would not let me. It spit out an error that the segment is bad with negative entries.

epy