On Thu, 30 Sept 2021 at 12:34, abhijeet inamdar <abhijeetinamdar3...@gmail.com> wrote: > Actually the ELF generates the .bin file which is being used to run on the > target (hardware). It's address starts from zero when I see the starting > frames of it. As follows: > > IN: > 0x00000002: c0de stm r0!, {r1, r2, r3, r4, r6, r7} > 0x00000004: 0003 movs r3, r0 > 0x00000006: 0000 movs r0, r0 > 0x00000008: 0001 movs r1, r0 > 0x0000000a: 0000 movs r0, r0 > 0x0000000c: 0002 movs r2, r0 > 0x0000000e: 0000 movs r0, r0 > 0x00000010: 0168 lsls r0, r5, #5 > 0x00000012: 0000 movs r0, r0 > 0x00000014: 5838 ldr r0, [r7, r0]
This clearly isn't code; it's some kind of data. It's not a vector table, because it starts 0xc0deXXXX 0x00000003 0x00000001 0x00000002 0x00000168 and those aren't plausible looking addresses. The guest CPU loads the reset SP and PC. The reset PC is 0x00000003, so we start at address 0x00000002 in Thumb mode. The data at that address is not a sensible instruction (it's that "stm r0!..."), but we execute it. r0 is 0, so this is going to store new random data all over the existing data that we were incorrectly executing. The inevitable result is that we take an exception, and this time the vector table is full of zeros, so now we try to execute from 0x0 in non-Thumb mode, which means we take another exception, which is Lockup. The solution remains the same: you need to load a guest image which puts a valid vector table in guest memory at the address where the CPU expects it (which looks like 0x0 in this case). Until you do this, your guest code will crash in mysterious-looking ways because you are not running what you think you are running. -- PMM