Bosch MED9.1.1

[kur4o]

Some vectors are jump to offset and don`t use absolute addressing mode. In that case use C button to convert to instruction->branch to vector.

[lgtmelo]

Some vectors are jump to offset and don`t use absolute addressing mode. In that case use C button to convert to instruction->branch to vector.

thanks, that worked!

[lgtmelo]

so after doing it all I went to options -> general -> reanalyze program. it ran through the whole thing and made a lot more of the top bar into blue area (regular function). then i did the reanalyze program thing again, and it turned even more area into blue. after this, it wouldnt change anymore by reanalyzing.

so i went and got some map addresses from IDA, for instance:
KLPROV is at 1D50B0. i subtract the offset 1c2000, which gives me 130B0. considering i loaded it at 5c2000, after adding it, it results in 5D50B0. but this is what i get (im now in a whole unexplored portion):

any tips to proceed?

[antus]

Just from eyeballing it, those repeated patterns @ 16 bit values make me think that's calibration data, not code. Also because the arrow in the map at the top shows no code around it. If you have an XDF see if that area or data around it in the non-code section is defined as calibration data.

The red bits are probably vector entry points and the landing point at the start of each one can be converted to subroutine, then they'll go from red to blue. Its also possible they're unused code that was linked in and left behind but because nothing is using it IDA didn't have a reason to call them functions. I've seen that in some of the GM operating systems when looking at flash code (just one possible example) where I can see flash chips that don't exist in the PCM have string references in unused code in the bin, and whole lot of them one after the other in the same area.

If you can find the code that is referencing that location, you'll probably be able to confirm they're 16bit words, and you can convert them to data words, if you want it to look nicer.

For pro level disassembling - and this is beyond most people including myself - it should be possible to write python or IDC code that can search for calibration segment references, figure it all out from logic you write, and update the data types programmatically. This is the type of thing pro reverse engineering shops would have written and keep private and use over and over again. Having said that a lot of reverse engineers share their idc / python. But this is not a road I have travelled for this purpose.

[lgtmelo]

Just from eyeballing it, those repeated patterns @ 16 bit values make me think that's calibration data, not code. Also because the arrow in the map at the top shows no code around it. If you have an XDF see if that area or data around it in the non-code section is defined as calibration data.

sorry to sound silly, but by calibration data do you mean maps area?

thanks!

[antus]

yes

[lgtmelo]

first of all, thanks for all the help, it was crucial!

i found ghidra to be easier to use than ida (maybe this is the case for ppc only, but this is what worked for me), so ill share how i did it. please forgive any dumbness i might say here, im not very familiar with most technical terms (even basic stuff).

here's how i did it:
1-open ghidra, load the 2mb file, under language select powerpc, default, 32, big. under options, you dont need to change anything for now. set the block name as "bin" if you want, just for organization. if it asks if you want to analyze, click no.
2-go to file, add to program, then add the 512kb file. language will already be selected. click options, then on base address, put 0x400000. dont change offset and length. set the block name as "mpc" if you want.
3-go to file, add to program, then add the 2mb file AGAIN. this is how the ECU sees the maps (calibration) area. the reason for that can be checked at basano's original thread, where he or someone else posted a portion of the damos file which references the memory map. under options, put base address as 0x5c2000 and offset 0x1c2000 and length 0x3e000. this means from the 2mb file, we are getting data starting at the address 0x1c2000 until 0x1c2000+0x3e000. this data is being then inserted into our project at the address 0x5c2000. call this block "calibration" if you want.
4-now we need to create the RAM block. go to window -> memory map. click the green + sign at the top right. under block name put "ram", start address is 0x600000, length is 0x300000. see to it that "read, write and execute" checkbox are marked.
5-now we need to define base registers for MPC. r2 and r13. these are important because they serve as references throughout the whole program. on ghidra's main text window, select all (ctrl+a), then type ctrl+R and in the dropdown menu, just type r2 and it will select r2 (r32). put 0x5C9FF0 as value. do the same for r13 and use 0x7FFFF0 as value.
6-now everything is set to begin decompiling. before doing the automatic stuff we will help ghidra by manually setting some stuff. go to 0 and manually decompile vectors using D button. usually vectors starts with 48 00 at 0x0 address and at 400000 address (go there by typing G button).

this just means you'll go to a line such as

Code: Select all

        00000008 48              ??         48h    H

and observe that the next line is

Code: Select all

        00000009 00              ??         00h

a.png (24.71 KiB) Viewed 222 times

so you can go to the first one that has the 48, and type D. this will turn it into LAB_address, an auto-generated label (usually a jump target within a function). you can also type D in the first lines of these sectors that show as 48 01 (this is how i did by mistake and it worked out. again, not a pro here).

now it should look like the screenshot below, so you can go to analysis -> auto analyze, or simply type A.

from this on, we can find the maps by comparing the addresses we have in WINOLS. for example, KLPROV (from the axis, not the actual map) is at 1D50A0. to find it in ghidra, i subtract the offset 1c2000, which gives me 130A0. then, considering i loaded it at 5c2000, we sum it, resulting in 5D50A0. type G to go to 5D50A0, which is where the actual map is (so you'll see some raw data that we dont care). by the right side, theres XREF[amount of references to this address]: FUN_function that calls it:line that contains it. double click it, and it will take you to the actual function which is what we are looking for.

hope this helps someone, someday.