-
Notifications
You must be signed in to change notification settings - Fork 259
Description
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:
- Open the binary provided as thumb2
- Add new segment with start
0x20043000
, length0x1000
andrw-
- run
bv.reanalyze()
or reanalyze the binary - Crete new structure named
test
with size0x120
- In HLIL view go to
0xa
and change the type fordata_200430f8
totest *
- 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:
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.