Bad assembly generated on arm 32bits

[l0kh]

Environment

Sun Jan 15 10:12:17 AM CET 2023
Version: radare2 5.8.1 29834 @ linux-x86-64 git.5.7.4-1336-g8b544aff81
On Linux x86_64 (Kali)
Command used:
r2 -aarm -b32 blah

Description

Assembly code generated by r2 for instruction 14300be5 is wrong (bad offset)
The comment is good, but not the assembly.

Test

Code on radare2

Code on gdb

Disassembly expected

[trufae]

Can you share the binary or provide a way to repro without it?

$ r2 -a arm -b 32 -
 -- The stripping process is not deep enough
[0x00000000]> wx 14300b520301be5
[0x00000000]> pd 2
            0x00000000      14300b52       andpl r3, fp, 0x14
            0x00000004      0301be50       adcspl r0, lr, r3, lsl 2
[0x00000000]>

[l0kh]

It's at the start of main of this small ctf
blah.zip

[trufae]

For fine here:

[0x000083b8]> s main 
[0x00008470]> af
[0x00008470]> pd 20
┌ 484: int main (int argc, char **argv);
│           ; arg int argc @ r0
│           ; arg char **argv @ r1
│           ; var int32_t var_10h @ fp-0x10
│           ; var int32_t var_14h @ fp-0x14
│           ; var int32_t var_18h @ fp-0x18
│           ; var int32_t var_1ch @ fp-0x1c
│           ; var int32_t var_20h @ fp-0x20
│           ; var int32_t var_24h @ fp-0x24
│           0x00008470      10482de9       push {r4, fp, lr}
│           0x00008474      08b08de2       add fp, sp, 8
│           0x00008478      1cd04de2       sub sp, sp, 0x1c
│           0x0000847c      20000be5       str r0, [var_20h]           ; 0x20 ; 32 ; argc
│           0x00008480      24100be5       str r1, [var_24h]           ; 0x24 ; 36 ; argv
│           0x00008484      0630a0e3       mov r3, 6
│           0x00008488      10300be5       str r3, [var_10h]           ; 0x10 ; 16
│           0x0000848c      0030a0e3       mov r3, 0
│           0x00008490      14300be5       str r3, [var_14h]           ; 0x14 ; 20
│           0x00008494      20301be5       ldr r3, [var_20h]           ; 0x20 ; 32
│           0x00008498      020053e3       cmp r3, 2                   ; 2
│       ┌─< 0x0000849c      0300000a       beq 0x84b0

[trufae]

oh well its happening if i do aaaaaa, so its probably a bug in the type propagation .. ill look into that. if you do af it works fine

[l0kh]

I always do aaa (just FYI)

[trufae]

Its usually not recommended to do full analysis because of bugs like this that happen when combining different analysis at once. But it's a common practice and the default for most people. So there's nothing wrong with it, but it's usually good to try alternative ways to analyze the code to understand better the cause of the bug. i have some separate patches that fix and improve other issues i found in this binary, so i''ll push it to the testsuite and improve the analysis based on it.

thanks. i'll let you know when i merge the fixing pr

[l0kh]

Noted. I'll change this habit.
Thanks for your work.

[trufae]

so here's the bug

[trufae]

Fixed here #21257 ill close the issue when merged

[trufae]

that fix breaks other tests, but the logic behind this code is wrong . more summer of code crap that needs to be rewritten. i will try to massage the patch and try to get something working soon

[l0kh]

I'm currently using aa and it seems to work for now.
Good luck with your patch