RomRaider

Guys, one question please:

i´m trying to disassemble a PowerPC (Siemens MS45) processor which has 448kb of internal flash and an additional flash of 1024kb. I start with opening the 448kb and when i try to load the additional binary, which should be loaded at 0xFFF00000, i set it up like this:

Unfortunally the loaded file lacks one digit of F and will be loaded at 0xFF000000. How do i get this fixed?

Segments are a concept that applies to PCs but not most embedded systems. I don't have any idea how they actually work. Its kind of annoying that IDA forces them on every processor type. I don't know the right thing to put in the segment field... it might not matter? Anyway, put the loading address into the "loading offset" field and you'll be set.

Thank you for the help! Looking a bit better... Base fuel map verfied at 0x10B14h in .mem file, names now making more sense in IDA... I think?

EDIT: Actually, wouldn't you drop the x10000 as the top 2 bits are subtracted to get the DPP?

Works! Thanks

The "Names" window looks right now, but you still have something weird going on on the left side... Only the top two bits of an immediate offset (inside an instruction) get decoded into DPPs. When an address is an actual address (like the list of subroutines) there are no DPPs involved. I think that's the issue on the left side of your screenshot. Those addresses are getting decoded incorrectly, they should just be non-DPP offsets.

So, that XML > IDC program is a lot more useful than I originally realized. It just occurred to me that if you have all the different axis and table pointers named in IDA, and you have the DPP registers set correctly (Under "Edit>Segments>Default Segment Registers" IIRC) you should be able to go to any given "table reader" function (that calls interpolation functions) and highlight the DPP-ized offsets and press O and get the table names.

I see that now

Can someone ELI5, the basics in the attached example? <See Attached> It appears the the processor is moving some data into registers, calls a couple subroutines, then does a jnb (Jump relative if direct bit is not set) to another sub. It's clear that one path would be for an AT car, the other an MT car. However I'm not so sure what the word_FD5C.7 is... is that a memory value that could be in use during runtime? How would I know what this value contains at a given moment? If I was missing the labels in this example, I'd be quite clueless as to what is going on. Thanks gents!

Edit: Just discovered the "E36 ECU Logic" thread

That is a byte in RAM that holds a bunch of "statuses." Bit 7 in particular represents if the ECU is currently running an auto or manual (I think) because it's loaded in a subroutine that also sets the CAN bus DTCs.

Hit X on that value and look at all the cross references (it only breaks it up by byte, but you can scan them for the right bit) and see where that particular bit gets loaded.

Hey guys,

I'm working on a different ECM but wanted to ask a question of you guys because maybe you have run into the same thing. I can find maps easily in wols for my ECM, but when I go to that maps start address in IDA there are no cross references to it. How is the code calling a map in this case?

My goal right now since I'm just starting is to simply identify RPM in the code. I am looking at a map that I know uses RPM as an axis.

Moderator: wols image removed, please read posting rules.

It might be that the code that loads that table just hasn't been disassembled yet by IDA. The disassembly that it does will sometimes miss things. I still run into this kind of thing in my ECU's disassembly once in a while, even though the initial disassembly found the majority of the code.

If you know the address you're looking for, try searching for that address as sequence of bytes. If you find the address sitting elsewhere in the ROM there might be code nearby that just hasn't been disassembled yet. Also try looking for slightly lower addresses, in case the ECU code actually refers to a structure that contains the table data, rather than just referring directly to the table data. For example the raw data might be prepended with a length value or something like that.

In the Subaru ECUs, the ECU code will refer to a structure that looks like...

4-byte value that describes the number elements in the table and the data types (float or int)
4-byte pointer to the input array
4-byte pointer to the output array
4-byte floating-point multiplier to scale the output value
4-byte floating-point offset to add to the output value

So if you find the arrays that contain the input and output curves, the only reference will be in that data structure. But if you look 4 or 8 bytes up from that reference, you get the start of the structure. The code will reference the address of that structure rather than referencing the arrays directly.

One of the issues seems to be that IDA is treating that table and some bytes before and after it as a single blob of data. If you press the "d" key it should convert that into an array of bytes, which should help a little bit. That probably also indicates that it didn't find the referencing code during the initial disassembly pass, otherwise it would have split up that blob at any addresses that are referenced.

Merry Christmas guys,

is there a way to tell IDA it should change a given section from byte to word?
I´ve tried marking a section and selecting D which gives an option to convert to array but haven´t had success with that.



Would save tons of time not having to manually define each line by pressing D twice.

To convert selected data to a different format I wrote some functions and added them to my ida.idc cfg file so they are available via a key stroke.

So i just add these lines to the end of my idc file?

Add the functions anywhere, but make sure the bindings to the keyboard shortcuts is in main(){}.

Uh, thats working phantastic! Awesome, thank you very much! Once you know that the file to change is called ida.idc and not the idc file that one can export, it´s working flawless