PPC Switch Case identification

[sprout42]

I'm looking at some PPC code that has a curious location-agnostic switch case style using the link register that seems to prevent correct detection and identification of the switch

bl <next instruction>
slwi r11, r26, 2
mflr r12
addi r11, r11, 0x18
add r11, r11, r12
mtctr r11
bctr
<table of branch instructions>

[rssor]

What does the IL at the bl wind up being? If I remember correctly that should be lifted as just moving the address into LR and not as a call, and the rest of the pattern looks like we should be solving it correctly.

Can you look at dataflow in LLIL/MLIL and see where it’s losing track?

[sprout42]

so the LLIL for this type of operation shows up with the switch block belonging to a new function in addition to the block being in the original function:

call(sub_<next_address>)
r11 = r26 << 2
r12 = lr
r11 = r11 + 0x18
r11 = r11 + r12
ctr = r11
jump(ctr)

int32_t sub_<next_address>(int32_t arg1 @ r26)
r11 = r26 << 2
r12 = lr
r11 = r11 + 0x18
r11 = r11 + r12
ctr = r11
jump(ctr)

[sprout42]

I double checked and the branch instruction used in this case is just a normal PPC bl so there are no hint flags available:

48000005   bl

[sprout42]

double checked with the latest dev release (3.0.3261-dev) and it looks like the HLIL is showing a little bit cleaner of an analysis but it isn't yet resulting in anything that I can manipulate manually with UDIF (https://binary.ninja/2020/09/10/user-informed-dataflow.html#jump-table-example).

In the interests of obfuscating this a bit I've removed the addresses.

Disassembly:

  548b063e   clrlwi  r11, r4, 0x18
  280b0006   cmplwi  r11, 0x6
  41810040   bgt     <bl instr address>

  48000005   bl      data_<slwi instruction address>
  556b103a   slwi    r11, r11, 0x2
  7d8802a6   mflr    r12
  396b0018   addi    r11, r11, 0x18
  7d6b6214   add     r11, r11, r12
  7d6903a6   mtctr   r11
❓4e800420   bctr    

LLIL:

17  r11 = r4 & 0xff
18  if (r11 u> 6) then 21 @ <address> else 24 @ <bl instr address>

24  call(data_<slwi instruction address>)
25  r11 = r11 << 2
26  r12 = lr
27  r11 = r11 + 0x18
28  r11 = r11 + r12
29  ctr = r11
30 ❓jump(ctr)

MLIL:

7   r11 = zx.d(arg2)
8   if (r11 u> 6) then 11 @ 0x8147b0 else 12 @ <address>

12  lr = data_<slwi instruction address>(arg1)
13  r11_1 = r11 << 2
14  r12 = lr
15  r11_2 = r11_1 + 0x18
16  r11_3 = r11_2 + r12
17  ctr = r11_3
18 ❓jump(ctr)

HLIL:

     uint32_t r11 = zx.d(arg2)
     if (r11 u<= 6)
❓        jump((r11 << 2) + 0x18 + (&data_<slwi instruction address>)(arg1))

[xusheng6]

From my understanding this is an issue with the switch-case detection in the core. The lifting of the PPC seems correct and nothing obviously wrong