4

I'm attempting to compare this binary bootloader to a slightly different C version of some boot code. My initial approach is to look at the msg() calls and the strings they use. I can dump the strings, and most of the strings in the binary are also in the C code. However, Ghidra shows only one or two strings as being referenced anywhere.

Disassembly seems to be working since it's matching relatively closely between the binary and the repository code.

Binary disassembly

Repository Code repository code

Note that the file in question isn't an ELF or PE/COFF. It's a boot loader image where the very first address is the first instruction (that jumps down past some header info to 00000338). Supposedly it gets loaded into SRAM at address 0x00000000. I believe that since the jump at address 0x00 does seem to go to the correct location (0x00000338).

I suppose as part of the setup code, the strings could get copied elsewhere...

4
  • Did you use any loader for this binary? It might be that the sections are not correctly constructed and thus memory addresses do not match for it to be correctly referenced. Commented Feb 8, 2022 at 17:12
  • No. I didn't use a loader. This file isn't an ELF or PE--it's some proprietary format. I'll add more information to the question.
    – watkipet
    Commented Feb 9, 2022 at 1:09
  • Are you sure it should start at 0x0? In the linked source code you can find lines like this #define UBOOT_BASE 0x4a000000 and similar that defines much higher addresses. Commented Feb 9, 2022 at 7:50
  • Yes. I'm sure it starts at 0x0. At 0x0, you can see a jump to the instructions in my screenshot. U-boot gets loaded after this code (boot0).
    – watkipet
    Commented Feb 10, 2022 at 1:17

1 Answer 1

3

My problem was that the boot loader code gets loaded into SRAM, which has a base address of 0x20000. So that means the code can access data based at 0x0 and also the same data starting at offset 0x20000 (which it does for strings). So I added an entry, "SRAM A", to my Memory Map: memory map

As you can see, the source of the data comes from the same binary file.

Then I went hunting for all the pointers to the strings which pointed out past 0x20000 and converted them to string pointers. Here's one: pointer to SRAM

Here's the string in SRAM (it's referenced): SRAM string

Here's the same string based at 0x0 (it has no references): 0x0 string

I suspect there are many other reasons that strings won't show up as referenced in Ghidra--this is just one possible reason.

1
  • This is exactly what a custom loader should do. Build memory maps. Commented Feb 10, 2022 at 6:49

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.