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)
        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.

2 Answers 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

  • 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. Nov 23, 2022 at 23:46

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.

Your Answer

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

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