radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.66k stars 3k forks source link

Mode Detection is not right for ARM architectures #14223

Open valour01 opened 5 years ago

valour01 commented 5 years ago
Questions Answers
OS/arch/bits (mandatory) x86
File format of the file you reverse (mandatory) ELF
Architecture/bits of the file (mandatory) arm 32
r2 -v full output, not truncated (mandatory) radare2 3.5.0-git 21656 @ linux-x86-64 git.3.4.1-312-g45a9f84 commit: 45a9f8443157e162283cda61776b93c84a5d9ae1 build: 2019-05-04__13:25:18

Expected behavior

The binary is compiled with thumb mode. However, radare2 should disassemble the binary with Thumb mode

Actual behavior

Many bytes are disassembled as ARM mode but the actual mode should be thumb. For example, address 0x6d2a6, 0x698b2, 0xa45f4 Many inline data are not detected. For example, address "0x20dd8"

There are inconsistent between the command pd and pdj

Steps to reproduce the behavior

I use radare2 bin to load the binary. Then I use ahb 16 to set the mode at the entry point. Then I use aaa to conduct the analysis. After that I use pd(j) N @ addr to print out the disassembled bytes. For example Wrong Mode:

[0x0001290c]> pd 10 @ 0x698b2
            0x000698b2                    unaligned
            0x000698b3                    unaligned
            0x000698b4      132befd8       stmle pc!, {r0, r1, r4, r8, sb, fp, sp} ^
            0x000698b8      2000d840       sbcsmi r0, r8, r0, lsr 32
            0x000698bc      03003800       eorseq r0, r8, r3
            0x000698c0      9843e9d1       invalid
            0x000698c4      342aefd0       rscle r2, pc, r4, lsr sl
            0x000698c8      ab5c282b       blhs 0xa80b7c
        ,=< 0x000698cc      ecd0272a       bhs 0xa5dc84
       ,==< 0x000698d0      05d0322a       bhs 0xd1d8ec

Data to Code:

[0x0001290c]> pd 2 @0x20dd8
            ; DATA XREF from fcn.00020da4 (0x20db6)
            0x00020dd8      fffff9f9       invalid
/ (fcn) fcn.00020ddc 96
|   fcn.00020ddc (int32_t arg1, int32_t arg2, int32_t arg4);
| bp: 0 (vars 0, args 0)
| sp: 0 (vars 0, args 0)
| rg: 3 (vars 0, args 3)
|           ; CALL XREF from fcn.00020e3c (0x20e48)
|           ; CALL XREF from fcn.00021298 (0x213fa)
|           0x00020ddc      f0b5           push {r4, r5, r6, r7, lr}
[0x0001290c]> pd 2 @0x20db6
|           0x00020db6      084b           ldr r3, [0x00020dd8]        ; [0x20dd8:4]=0xf9f9ffff
|           0x00020db8      2268           ldr r2, [r4]

Inconsistent:

[0x0001290c]> pdj 1 @0x22850
[{"offset":141392,"esil":"2,r6,>>>>,r4,=,$z,zf,:=","refptr":false,"fcn_addr":0,"fcn_last":0,"size":2,"opcode":"asrs r4, r6, 2","disasm":"asrs r4, r6, 2","bytes":"b410","family":"cpu","type":"sar","reloc":false,"type_num":25,"type2_num":0,"refs":[{"addr":856244,"type":"UNKNOWN"}],"xrefs":[{"addr":141370,"type":"DATA"}]}]

[0x0001290c]> pd 1 @0x22850
            ; DATA XREF from aav.0x0002281d (+0x1d)
            0x00022850      .dword 0x000d10b4 ; aav.0x000d10b4

It is easy to see that the output is not right. The right mode should be thumb.

XVilka commented 4 years ago

Mentioned in this paper: