qiling
qiling copied to clipboard
qilingframework
libstdc++.so error
Hi,
I tried to emulate a ARM ELF binary with the qiling framework. The binary depends on the libstdc++.so library, which seems to branch to the address 0xffff0fc0 in several places. This seems to be a problem as qiling does also map the arm_tls memory from 0xffff0000 to 0xffff1000.
Of course I could try to patch the library, but I'm not sure if this breaks something. Did anyone had similar problems with qiling? Is there maybe a way to remap the arm_tls memory?
For example the library does branch to 0xffff0fc0 at the offset 0x0008cde8, qiling seems do be in a endless loop here (as there are some instructions at 0xffff0fc0 mapped which modify the value of r0) as seen in the qdb output:
Before BLX 0xffff0fc0:
(Qdb) s
[Registers]
=================================================================
r0: 0x00000000 r1: 0x00000100 r2: 0x775c1fd4 r3: 0x0000137c
r4: 0x00000000 r5: 0x00000000 r6: 0x775c1fd4 r7: 0xffff0fc0
r8: 0x00000100 r9: 0x00000000 sp: 0x7ff3c970 lr: 0x775a188c
pc: 0x775a7de8 sl: 0x774bf6d8 fp: 0x7ff3c9c4 ip: 0x775a184c
[Supervisor mode], Thumb: False, FIQ: True, IRQ: True, NEG: False, ZERO: True, Carry: True, Overflow: False
===========================================================================
[Stack] --------------------------------------------------------------------------------------------------
$sp+0x00|[0x7ff3c970]=> 0x775c1fd4 => 0x775c1fd4
$sp+0x04|[0x7ff3c974]=> 0x00000000 => 0x00000000
$sp+0x08|[0x7ff3c978]=> 0x775bf000 => 0x775bf000
$sp+0x0c|[0x7ff3c97c]=> 0x047c9008 => 0x047c9008
$sp+0x10|[0x7ff3c980]=> 0x047c8f70 => 0x047c8f70
$sp+0x14|[0x7ff3c984]=> 0x775a188c => 0x775a188c
$sp+0x18|[0x7ff3c988]=> 0x775c1fd4 => 0x775c1fd4
$sp+0x1c|[0x7ff3c98c]=> 0x00000001 => 0x00000001
----------------------------------------------------------------------------------------------------------
[Code]
===========================================================================
0x775a7dd8 bne #0x775a7df4
0x775a7ddc mov r0, r5
0x775a7de0 mov r1, r8
0x775a7de4 mov r2, r6
PC ==> 0x775a7de8 blx r7
0x775a7dec cmp r0, #0
0x775a7df0 bne #0x775a7dd0
0x775a7df4 mov r0, r4
0x775a7df8 pop {r4, r5, r6, r7, r8, pc}
===========================================================================
After BLX 0xffff0fc0:
(Qdb) s
[Registers]
===========================================================================
r0: 0x776b5800 r1: 0x00000100 r2: 0x775c1fd4 r3: 0x0000137c
r4: 0x00000000 r5: 0x00000000 r6: 0x775c1fd4 r7: 0xffff0fc0
r8: 0x00000100 r9: 0x00000000 sp: 0x7ff3c970 lr: 0x775a7dec
pc: 0x775a7dec sl: 0x774bf6d8 fp: 0x7ff3c9c4 ip: 0x775a184c
[Supervisor mode], Thumb: False, FIQ: True, IRQ: True, NEG: False, ZERO: True, Carry: True, Overflow: False
====================================================================================
[Stack] -------------------------------------------------------------------------------------------------------
$sp+0x00|[0x7ff3c970]=> 0x775c1fd4 => 0x775c1fd4
$sp+0x04|[0x7ff3c974]=> 0x00000000 => 0x00000000
$sp+0x08|[0x7ff3c978]=> 0x775bf000 => 0x775bf000
$sp+0x0c|[0x7ff3c97c]=> 0x047c9008 => 0x047c9008
$sp+0x10|[0x7ff3c980]=> 0x047c8f70 => 0x047c8f70
$sp+0x14|[0x7ff3c984]=> 0x775a188c => 0x775a188c
$sp+0x18|[0x7ff3c988]=> 0x775c1fd4 => 0x775c1fd4
$sp+0x1c|[0x7ff3c98c]=> 0x00000001 => 0x00000001
---------------------------------------------------------------------------------------------------------------
[Code] ================================================================================
0x775a7ddc mov r0, r5
0x775a7de0 mov r1, r8
0x775a7de4 mov r2, r6
0x775a7de8 blx r7
PC ==> 0x775a7dec cmp r0, #0
0x775a7df0 bne #0x775a7dd0
0x775a7df4 mov r0, r4
0x775a7df8 pop {r4, r5, r6, r7, r8, pc}
=======================================================================================
At 0xffff0fc0 the following instructions seems to be mapped:
[...]
0xffff0fd0 andeq r0, r0, r0
0xffff0fd4 andeq r0, r0, r0
0xffff0fd8 andeq r0, r0, r0
0xffff0fdc andeq r0, r0, r0
0xffff0fe0 add r0, pc, #4
0xffff0fe4 ldr r0, [r0]
0xffff0fe8 mov pc, lr
0xffff0fec strbvc r5, [fp, -r0, lsl #16]!
0xffff0ff0 andeq r0, r0, r0
[...]
I've already tried to map arm_tls manually (I thing this is specified in qiling/os/linux/utils.py)
But then qiling seems to fail immediately (after [+] Enable ARM VFP)
Qiling 1.1.3 and unicorn 1.0.2rc6
base os is arch linux, but I had the same issue on ubuntu...
A full log of which problem? The log if I try to map arm_tls to a different address or the log of the stdlibc++.so problem?
You should trace and see what is being mapped in 0xffff0fc0 on a actual arm (via qemu).
Please do take note it might be different for different arm version.
As far as i remember that is the EVT area and unless you have exception it will not be there. Its normal to have a branch there but did u check is that the actual cause of the crash ?