The instruction attempted to execute from unmapped memory
joelreymont opened this issue · comments
It seems that the plugin is not mapping memory correctly for some reason.
I'm using IDA 8.2 and the plugin bombs on the following instruction when I start from cursor
ROM:0004B2DA LDR R6, [R3,#(off_13D584 - 0x13D578)] ; START_3_DATA1
I would assume that ROM would be mapped automatically but it doesn't look so.
I start with these segments in IDA
ROM 0000000000000000 000000000013FFFF R W X . . byte 00 stack CODE 32 00 00
RAM 0000000000140000 00000000FFFFFFFF R W X . . byte 01 public 32 00 01
and I end up with
ROM 0000000000000000 000000000013FFFF R W X . . byte 00 stack CODE 32 00 00
debug003 000000000013FFFF 0000000000140000 R W X D . byte 00 public CODE 32 01 01
RAM 0000000000140000 00000000FFFFFFFF R W X . . byte 01 public 32 00 01
The IDA output shows
reading file of 1307757 bytes
map_mem_zero(0xffefe000, 0xffffe000, 0x7)
Allocated at 0xffefe000 in map_mem_zero
map_mem_zero(0x0, 0x13ffff, 0x7)
Allocated at 0x0 in map_mem_zero
map_mem_zero(0x140000, 0xffffffff, 0x7)
Failed to allocate at 0x140000 in map_mem_zero
PC was set previously to 0x4b2da
0: process flyctrl.img.FCFW.f4000000 has started (pid=20822)
segm_added mapping, 0x13ffff:0x140000
segm_added already mapped
13FFFF: created segment debug001, end: 140000
4B2DA: The instruction at 0x4b2da attempted to execute from unmapped memory -> 0004B2DA (exc.code b, tid 29644)
13FFFF: deleted segment debug001, end: 140000
segm_added mapping, 0x13ffff:0x140000
segm_added already mapped
13FFFF: created segment debug002, end: 140000
13FFFF: deleted segment debug002, end: 140000
segm_added mapping, 0x13ffff:0x140000
segm_added already mapped
13FFFF: created segment debug003, end: 140000
I redid my segments to avoid the failed allocation but get the same error.
Segments
ROM 0000000000000000 000000000013F46D R W X . . byte 00 stack CODE 32 00 00
RAM1 0000000010000000 000000001FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAM2 0000000020000000 000000002FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAM3 0000000030000000 000000003FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAM4 0000000040000000 000000004FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAM5 0000000050000000 000000005FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAM6 0000000060000000 000000006FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAM7 0000000070000000 000000007FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAM8 0000000080000000 000000008FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAM9 0000000090000000 000000009FFFFFFF ? ? ? . . byte 01 public 32 00 01
RAMA 00000000A0000000 00000000AFFFFFFF ? ? ? . . byte 01 public 32 00 01
RAMB 00000000B0000000 00000000BFFFFFFF ? ? ? . . byte 01 public 32 00 01
RAMC 00000000C0000000 00000000CFFFFFFF ? ? ? . . byte 01 public 32 00 01
RAMD 00000000D0000000 00000000DFFFFFFF ? ? ? . . byte 01 public 32 00 01
Output
reading file of 1307757 bytes
map_mem_zero(0xffefe000, 0xffffe000, 0x7)
Allocated at 0xffefe000 in map_mem_zero
map_mem_zero(0x0, 0x13f46d, 0x7)
Allocated at 0x0 in map_mem_zero
map_mem_zero(0x10000000, 0x1fffffff, 0x0)
Allocated at 0x10000000 in map_mem_zero
map_mem_zero(0x20000000, 0x2fffffff, 0x0)
Allocated at 0x20000000 in map_mem_zero
map_mem_zero(0x30000000, 0x3fffffff, 0x0)
Allocated at 0x30000000 in map_mem_zero
map_mem_zero(0x40000000, 0x4fffffff, 0x0)
Allocated at 0x40000000 in map_mem_zero
map_mem_zero(0x50000000, 0x5fffffff, 0x0)
Allocated at 0x50000000 in map_mem_zero
map_mem_zero(0x60000000, 0x6fffffff, 0x0)
Allocated at 0x60000000 in map_mem_zero
map_mem_zero(0x70000000, 0x7fffffff, 0x0)
Allocated at 0x70000000 in map_mem_zero
map_mem_zero(0x80000000, 0x8fffffff, 0x0)
Allocated at 0x80000000 in map_mem_zero
map_mem_zero(0x90000000, 0x9fffffff, 0x0)
Allocated at 0x90000000 in map_mem_zero
map_mem_zero(0xa0000000, 0xafffffff, 0x0)
Allocated at 0xa0000000 in map_mem_zero
map_mem_zero(0xb0000000, 0xbfffffff, 0x0)
Allocated at 0xb0000000 in map_mem_zero
map_mem_zero(0xc0000000, 0xcfffffff, 0x0)
Allocated at 0xc0000000 in map_mem_zero
map_mem_zero(0xd0000000, 0xdfffffff, 0x0)
Allocated at 0xd0000000 in map_mem_zero
PC was set previously to 0x4b2da
0: process flyctrl.img.FCFW.f4000000 has started (pid=40093)
segm_added mapping, 0x13f46d:0x23fffe
segm_added already mapped
13F46D: created segment debug001, end: 23FFFE
segm_added mapping, 0xffefe000:0xffffdffe
segm_added already mapped
FFEFE000: created segment debug002, end: FFFFDFFE
4B2DA: The instruction at 0x4b2da attempted to execute from unmapped memory -> 0004B2DA (exc.code b, tid 24815)
13F46D: deleted segment debug001, end: 23FFFE
segm_added mapping, 0x13f46d:0x23fffe
segm_added already mapped
13F46D: created segment debug003, end: 23FFFE
FFEFE000: deleted segment debug002, end: FFFFDFFE
segm_added mapping, 0xffefe000:0xffffdffe
segm_added already mapped
FFEFE000: created segment debug004, end: FFFFDFFE
13F46D: deleted segment debug003, end: 23FFFE
segm_added mapping, 0x13f46d:0x23fffe
segm_added already mapped
13F46D: created segment debug005, end: 23FFFE
FFEFE000: deleted segment debug004, end: FFFFDFFE
segm_added mapping, 0xffefe000:0xffffdffe
segm_added already mapped
FFEFE000: created segment debug006, end: FFFFDFFE
@cseagle How do I set the registers before starting debugging?
Other than the stack and instruction pointers, you pretty much get the unicorn defaults for register values which I believe is mostly zeros. When I need to set initial register values I try to break at the entry point then set the register values I need before continuing
Are trying to emulate ARM or AARCH64? It looks like you have ARM code loaded in ida64. Is sk3wldbg reporting the correct architecture in its log messagtes?
I'm trying to emulate ARM, e.g. my debug view shows ARM registers (Rxx, not Xxx). I don't see sk3wldbg reporting the architecture in the log messages. I'm using ida64 but I tried ida32 and it didn't make a difference.
Also, if I try to map the ROM memory again, after the exception, sk3wldbg crashes in the idc_mmap call.
@cseagle I'm willing to fix or improve sk3wldbg if necessary, e.g. I was gonna attach a debugger to IDA to figure out the idc_mmap crash. Also, I'm trying to reverse drone firmware and I'm in this for the long haul. Last but not least, I'm willing to share my IDA database if it helps.
@cseagle Please ping me at cotton.nickels-0r@icloud.com if you want my IDA database.
Invoking sk3wl_mmap(0x0, 0x13F46D, 7) after the exception crashes in idc_mmap on line 136.
The code is seg_name.sprnt("mmap_%p", mb->guest); so mb must be null.
Is mapping after an exception a valid thing to do? Should mb be null in this case?