Readable disassembly of object files

[Maijin]

Paste of @sheinz radareorg/radare2-book#36 (comment)

Hi,

I'm not sure where to ask questions regarding radare2 usage. So, I'll do it here.
I want to use radare2 for esp8266 RE, so I want it to produce as readable disassembly as possible.
The primary target for disassembly is object files extracted from library archives.

Is there radare2 configuration/settings that allow to have:

1. call function name resolution:

0x40215b31      0176b2         l32r a0,0x4020250c
0x40215b34      c00000         callx0 a0

to display something like:

0x40215b34      c00000         call sym.some_function

2. string literal resolution

0x40215b2c      21f8ff         l32r a2,0x40215b0c

to

0x40215b2c      21f8ff         l32r a2,str.some_string_literal

I noticed that when I load an executable function calls are resolved better. When I load an object file function calls are not resolved at all.

I also do not understand why the instruction l32r a2,0x000001d4 that should load a pointer to a string literal does not point to the string:

px @ 0x000001d4
- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF
0x000001d4  1400 0000 404b 4c00 4042 0f00 0006 0060  ....@KL.@B.....

ps @ 0x00000014
\x01

0x000001f4]> fs strings
[0x000001f4]> f
0x000004e8 15 str.arm_new__x__x_n

Thanks

[Maijin]

From @radare - I dont think theres varsub implemented for this arch. Can you provide some samples?

[sheinz]

Sorry for the long delay.

Here are the samples:

• ets_timer.o.gz - Single object file
• http_get.out.gz - Whole ELF application

The disassembly of ets_timers.o by xtobjdis:

ets_timer_arm_ms_us:
            addi         sp, sp, -16 /* (local0) */            #  114: 12c1f0
            s32i         a12, sp, 4 /* a12 -> [(local1)] */    #  117: c911
            s32i         a13, sp, 8 /* a13 -> [(local2)] */    #  119: d921
            mov          a12, a2 /* arg0 */                    #  11b: cd02
            mov          a2, a3 /* arg1 */                     #  11d: 2d03
            excw                                               #  11f: 000048
            slli         a0, a9, 32                            #  122: 000901
            beqi         a4, -1, .Lbr017                       #  125: 26040d
            movi         a2, .Lstr003                          #  128: 21f3ff
            mov          a3, a12 /* arg0 */                    #  12b: 3d0c
            call0        printf                                #  12d: 01f5ffc0

...

.Lstr003:   .asciz       "arm new %x %x\n"                     #   14: 61726d20

The current disassembly of ets_timer.o by r2:

│   sym.ets_timer_arm_ms_us ();
│           ; var int local_0h @ a1+0x0
│           ; var int local_4h @ a1+0x4
│           ; var int local_8h @ a1+0x8
│           ; var int local_ch @ a1+0xc
│           0x080001f4      12c1f0         addi a1,a1,-16              ; a1=0xfffffffffffffff0 -> 0xffffff00
│           0x080001f7      c911           s32i.n a12,a1,4
│           0x080001f9      d921           s32i.n a13,a1,8
│           0x080001fb      cd02           mov.n a12,a2                ; a12=0x0
│           0x080001fd      2d03           mov.n a2,a3                 ; a2=0x0
│           0x080001ff      000048         ssx f0,a0,a0
│           0x08000202      000901         slli a0,a9,32               ; a0=0x0
│       ┌─< 0x08000205      26040d         beqi a4,-1,0x08000216       ; pc=0x8000216 -> 0x2051500; likely
│       │   0x08000208      21f3ff         l32r a2,0x080001d4          ; a2=0x14
│       │   0x0800020b      3d0c           mov.n a3,a12                ; a3=0x0
│       │   0x0800020d      01f5ff         l32r a0,0x080001e4          ; a0=0x0
│       │   0x08000210      c00000         callx0 a0                   ; a0=0x8000213 -> 0x66ffff00 ; $jt=0x0 ; CALL: 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff

The current disassembly of http_get.out by r2:

│   sym.sdk_ets_timer_arm_ms_us ();
│           ; var int local_0h @ a1+0x0
│           ; var int local_4h @ a1+0x4
│           ; var int local_8h @ a1+0x8
│           ; var int local_ch @ a1+0xc
│           ; CALL XREF from 0x40215faf (sym.sdk_ets_timer_arm)
│           ; CALL XREF from 0x40215f9b (sym.sdk_ets_timer_arm_us)
│           0x40215f08      12c1f0         addi a1,a1,-16              ; a1=0xfffffffffffffff0 -> 0xffffff00
│           0x40215f0b      c911           s32i.n a12,a1,4
│           0x40215f0d      d921           s32i.n a13,a1,8
│           0x40215f0f      cd02           mov.n a12,a2                ; a12=0x0
│           0x40215f11      2d03           mov.n a2,a3                 ; a2=0x0
│           0x40215f13      3d04           mov.n a3,a4                 ; a3=0x0
│           0x40215f15      480c           l32i.n a4,a12,0
│           0x40215f17      0901           s32i.n a0,a1,0
│       ┌─< 0x40215f19      26040d         beqi a4,-1,0x40215f2a       ; pc=0x40215f2a -> 0x2051500; likely
│       │   0x40215f1c      21f8ff         l32r a2,0x40215efc          ; a2=0x40214f00 -> 0x206d7200
│       │   0x40215f1f      3d0c           mov.n a3,a12                ; a3=0x0
│       │   0x40215f21      0176b1         l32r a0,0x402024fc          ; a0=0x40106170 -> 0xd2c0c100
│       │   0x40215f24      c00000         callx0 a0                   ; (loc..locsz) ; ([24] va=0x00000000 pa=0x00000000 sz=52 vsz=52 rwx=m-rw- ehdr) ; 0x0 ; a0=0x40215f27 -> 

What would be nice is to see the function calls (like call0 printf) and strings (something like movi a2, str.arm_new_ or l32r a2,0x40215efc ; 0x40215efc -> "arm new %x %x\n"

[radare]

after the siol merge.. is this still an issue?

[radare]

@Maijin can u confirm that we can close this now?

[Maijin]

Not fixed

[Maijin]

• after the siol merge the http_get.out seems doesn't map correctly

[radare]

i see, the problem is worst than i expected and i think is related to those xtensa objects. i have tested on mac and linux and objects seems to be mapped properly, so maybe the elf header is not reporting the right data or we are missing the relocs. but i would prefer to move this to the next release.

[ret2libc]

This issue has been moved from radareorg/radare2 to radareorg/ideas as we are trying to clean our backlog and this issue has probably been created a long while ago. This is an effort to help contributors understand what are the actionable items they can work on, prioritize issues better and help users find active/duplicated issues more easily. If this is not an enhancement/improvement/general idea but a bug, feel free to ask for re-transfer to main repo. Thanks for your understanding and contribution with this issue.