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.