2

I have a binary firmware that I'm trying to reverse engineer. I loaded it up on Ghidra, setting the file as raw binary, ARM Cortex, little endian. I used an address offset of zero for the file. And I seem to get good results. Here is the top of the file.

 // // ram // ram:00000000-ram:0005d37f // assume spsr = 0x0 (Default) MasterStackPointer 00000000 00 00 03 20 addr DAT_20030000 Reset XREF[1]: Entry Point (*) 00000004 d5 2b 03 08 addr DAT_08032bd5 NMI XREF[1]: Entry Point (*) 00000008 25 2c 03 08 addr DAT_08032c25 HardFault XREF[1]: Entry Point (*) 0000000c 25 2c 03 08 addr DAT_08032c25 MemManage XREF[1]: Entry Point (*) 00000010 25 2c 03 08 addr DAT_08032c25 BusFault XREF[1]: Entry Point (*) 00000014 25 2c 03 08 addr DAT_08032c25 UsageFault XREF[1]: Entry Point (*) 00000018 25 2c 03 08 addr DAT_08032c25

Notice how all the pointers point to DAT_08######? This is consistent with the well-known 0x08000000 offset typical on this architecture. But if I analyse the whole file with this offset, then this first part isn't "decoded" properly.

I guess I have to split the memory mapping of the file. Currently it's as a single block, as indicated by // ram:00000000-ram:0005d37f.

My question is where should I split the file, adding the offset from that point onward? Any good ways to have an educated guess? The first function, with the file as-is, appears at address 0x000001f0, after the IRQ block.

Improve this question

2 Answers 2

Reset to default
2

I recommend creating a memory map similar to the layout of the map of the processor where the code is dumped. It looks like this code was dumped from the flash of the device and should be mapped to that memory space 0x08000000. You can create a byte-mapped mirror to the 0x00000000 memory space if there are unresolved mappings to that memory region. I have not found creating the mirrored memory to be required.

You can re-create the interrupt block by referencing the data sheet for the processor and manually re-mapping. This is a good exercise since the interrupt block will vary from the Ghidra default to what the processor has available.

I recommend using a tool such as SVD-Loader to help fill in all the peripheral information.

Memory Map Screen shot

Improve this answer
1
  • Thank you. I did pretty much that in the end, but I did have to add the flash_mirror section at 0x0 to double map the flash. Commented Nov 23, 2022 at 23:46
1

To add to Ben's great answer, I double mapped the .bin file to both address 0x0 and 0x800000 (first two lines): enter image description here And it now works: enter image description here enter image description here

I learned it from this amazing video.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.