Weird structure accessor generated in HLIL when applying structure type to variable with consecutive 'adds' instructions

[jpenalbae]

Version and Platform:

• Binary Ninja Version: 5.2.8325-dev
• Edition: Commercial
• OS: macOS / Linux
• OS Version: 15.7.1 / Debian sid
• CPU Architecture: M2 / X86_64

Bug Description:

Weird structure accessor generated when applying the structure type. I'm not sure what is going on, but things start to get weird in MLIL once you apply the structure type. If you do not apply the structure type everything looks fine.

Here is the weird accessor generated by binary ninja.

uint32_t r1 = zx.d((&data_200430f8->__offset(0xff).d - 0xff)->:0x10c.b)

It all comes from this code. I suspect the two adds in a row are triggering this. If you nop one of the two the problem does not trigger.

00000002  a048       ldr     r0, [pc, #0x280]  {data_284}  {data_200430f8}
00000004  0068       ldr     r0, [r0]  {data_200430f8}
00000006  ff30       adds    r0, #0xff
00000008  0130       adds    r0, #1
0000000a  017b       ldrb    r1, [r0, #0xc]

Steps To Reproduce:

1. Open the binary provided as thumb2
2. Add new segment with start 0x20043000, length 0x1000 and rw-
3. run bv.reanalyze() or reanalyze the binary
4. Crete new structure named test with size 0x120
5. In HLIL view go to 0xa and change the type for data_200430f8 to test *
6. See the weird accessor at 0xa

Expected Behavior:

Just show the proper offset or the accessor if there was one assigned in the structure for the 0x10c offset.

&data_200430f8->__offset(0x10c).b

Screenshots/Video Recording:

MLIL without structure type applied:

MLIL with structure type applied:

HLIL weird accessor:

Binary:

The binary has been uploaded to the portal with reference phrase dream factor preprocesses promptly

Additional Information:

This was previously reported on slack #bugreports. @psifertex suggested it might be related to #7344 but it did not fix it, so I'm filling a new issue.

[xusheng6]

I can reproduce this -- database provided for simpler repro: dense captain flashes artfully

[jpenalbae]

I have found another similar occurrence of this that might be related... I'm using 5.4.9926-dev and ARM64 code this time.

This should be tmpstruct->destination = vers.b instead. Not terrible as you can see the right accessor, but a bit convoluted I would say...

Here is the code producing that HLIL output (x19 contains the base pointer to tmpstruct):

The strb instruction in here is the one causing the weird accessor:

And the structure layout:

[plafosse]

Fixed in 6.0.10468