Reversing uboot on an aarch64 Hi3559AV target problems

Question

I am trying to reverse uboot for an ARM aarch64 Hi3559AV target.

I've dumped the binary uboot.bin.gz, and have loaded it in IDA at the correct address. IDA seems to see a lot of strings (and potentially some data) at an offset of 0x10 from where it should be.

I've dumped RAM from the target, and confirmed that indeed the code is at the correct address as are the strings/data. This is position independent code so everything is at an offset as opposed to hardcoded addresses. So this confuses me. Still very learning so I am sure more experienced people know exactly why this might be.

I could work around this, but I am running parts of the code on qemu debugging with gdb-multiarch. Not the full uboot code from entry point of course as it will fail on hardware accesses etc. So I am using gcc to make a stub program ensuring uboot data ends up at the right memory address, and I can call the target function with the right data/params.

This is fine for some functions, but the one I am looking at doesn't produce the expected data output in memory just blank. Additionally just like IDA, when it prints strings, they are offset by 0x10 so are wrong.

Any suggestions why this might be?

This is a SHA function, and though the board does support hardware crypto (which won't work on qemu) the code shows no sign of using it. Nor does that explain the string/data offset issue.

Is there some kind of hardware addressing modes that the target board is using than I am not replicating?

I can't do things like this in the uboot start code WriteStatusReg(ARM64_SYSREG(3, 0, 4, 0, 1), v29); (not saying this is relevant to memory just an example).

Or perhaps it's some kind of .text segment or align thing which IDA doesn't do correctly, nor does qemu given I'm just jumping directly to a function. This is a baremetal binary image after all.

Any advice or pointers welcome. If I've not phrased the question properly or not included needed info please accept my apologies - happy to clarify as needed.

Cheers

Answer 1

OK I think i finally figured it out in that there is a partial code relocation routine in the uboot blob that copies a small part of it to another area of memory, with a different alignment.

This is called from the startup code of uboot before we get going. Init function of this additional code called, though in execution looks like elements of both code areas are used (and not just from the call table). In this case we've already had an earlier stage at boot, so this is the third section of uboot code that executes.

This is likely not news to uboot experts.

So whilst I did correctly verify the code + data were indeed where I expected them, some it the code isn't running at that memory location after all. Target is an embedded device I can't debug so that wasn't clear before.

Once performing this step manually in IDA (by creating a new code segment and manually loading an additional file), the string references in this new segment work correctly.

I am yet to try this out with my qemu adventures, but it certainly seems to be a big step in the right direction.

If anyone in the future sees this and it helps - great :) A few things for searchers to find it:

"IDA strings in the wrong place" "uboot disassembly strings" "uboot memory reallocation"

UPDATE: And indeed it did work in qemu - code executed correctly generating the hash the target would. This very much helps understand the crypto routines this target employs and provided the decryption I needed. Stepping through the virtual code execution in gdb was quite enlightening.

Which gives rise to even more challenging work on this device - more coffee supplies ordered from Internet.....