4

I'm working on disassembling a flash dump from a TriCore TC1766 which came from a car (an MT86 ECU). My goal is to identify tables and scalars in the data area, and determine what they are used for. I used a heat map analysis to locate 200+ potential tables based on a pattern I found and I verified my results were (mostly) valid based on some known table locations. The table dimensions are known as well.

Since i'm working blind with only a disassembler (IDA Pro), I'm finding it difficult to even get started. I know the addresses for a few tables and 2 scalars but I cannot find any references to them in the disassembled code.

I know that each of the table values and the scalers need to be converted in some way to get the correct values. For example, A scalar located at 0x30D4C has the following bytes F8 D9 and when reversed, are an integer of 55,800 which is then multiplied by 0.125 to get the target value of 6975 which is the maximum RPM that the ECU will let the engine spin to.

I was thinking if I could find where the operations were that did this conversion, i'd have a place to start navigating. But, I'm not really sure how the operations would be done, would it be a multiply opcode or would it be bit shifting? I have no idea what compiler options were used or what optimizations were used when the code was built.

What are some techniques I can use to find where these memory locations are referenced?

Heat map of a known table that is 13x19 enter image description here

Same table in IDA before the analysis enter image description here

Same table in IDA after the analysis enter image description here

If I look for any XREFs on dword_208C8 there aren't any

enter image description here

Improve this question
9
  • Doesn't IDA do that for you? You should be able to navigate back from your scalar to code that access it, or loads the address into a register. It doesn't always do a brilliant job with large tables or buffers so you may need to look at nearby addresses, but there's probably something there.
    – Rup
    May 31, 2019 at 16:54
  • @Rup IDA provides SOME references, but they're not all accurate and it doesn't get them all. In fact, there are no XREFs to/from any of the items in the data area, otherwise I'd be well on my way. I don't know if i need to define the data in certain ways first or not, but i've tried a few things with no results. I defined the scalars as data and it does disassemble differently, but still no XREFs
    – Dustin Davis
    May 31, 2019 at 17:16
  • @Rup I updated my question with some screen shots for you
    – Dustin Davis
    May 31, 2019 at 17:27
  • 1
    If you have loaded the binary into IDA and the data has no references, I would suggest, you have loaded the binary into the wrong address space.. Or it's referenced in a relative fashion and you have not decoded the code that references it.. depending on the CPU and how does references, aka something like a FR only does absolute references, so you can workout that address space via function calls, where-as ARM uses a lot of relative calls, this is where using the issues to find out of bound memory accesses can help to identify the correct base address.
    – Simeon Pilgrim
    Jun 6, 2019 at 22:39
  • 2
    In general I load a file at zero, then looking for memory address offset, jmps to addresses that don't make sense. Then I open a new project and load the image at the "new offset" that I think it now correct, and go from there.. I find that each model camera the code is loaded into a new location/address for Nikon camera's, it's a matter of finding the correct one, and when you do it makes more sense. The next thing is if code is copied into RAM to allow for updating of the firmware, Nikon does this, or load it's RTOS at different locations. All which might be the code accessing this data.
    – Simeon Pilgrim
    Jun 8, 2019 at 3:56

1 Answer 1

Reset to default
3

If you have loaded the binary into IDA and the data has no references, I would suggest, you have loaded the binary into the wrong address space.. Or it's referenced in a relative fashion and you have not decoded the code that references it.. depending on the CPU and how does references, aka something like a FR only does absolute references, so you can workout that address space via function calls, where-as ARM uses a lot of relative calls, this is where using the issues to find out of bound memory accesses can help to identify the correct base address.

In general I load a file at zero, then looking for memory address offset, jmps to addresses that don't make sense. Then I open a new project and load the image at the "new offset" that I think it now correct, and go from there.. I find that each model camera the code is loaded into a new location/address for Nikon camera's, it's a matter of finding the correct one, and when you do it makes more sense. The next thing is if code is copied into RAM to allow for updating of the firmware, Nikon does this, or load it's RTOS at different locations. All which might be the code accessing this data.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.