Bug Description:
While working on an AArch64 project, I found that the variables would start to show _offset(...) at random places for some struct member accesses. Some places it would also show a write to two int32_t members as a single int64_t write instead.
I was able to determine that this only happened with members tagged as __inherited, and removing that tag would make it show up as expected in the High Level IL/Pseudo C View of the function.
The first problem seems to be fixed in 3.5.4514, but the second one remains.
I have managed to re-produce this problem with a minimal C++ x64 project, and have attached the compressed bndb.
Steps To Reproduce:
Open the attached bndb
Go to the main function and observe the construction of the "Heap" class.
Note how the value writes to rax_2->childList's count and offset are combined, and also show the __offset(Address 0x14000122f)
Remove the __inherited tags from the Heap and OffsetList structs and observe everything now looks as expected.
Expected Behavior:
It's expected that the behavior with inherited members should be the same with non-inherited members.
In this case it's expected to individually show the value being assigned to ChildList.ListImpl::count = 0, and childList.offset = 0xffffffff.
Screenshots:
Problem with __inheritedin structs:
After removing __inheritedtag:
Additional Information:
Part of the problem seems to have been fixed in latest dev, but other part remains. Attached BNDB shows both problems on old version for context.
Restarting, Re-analyzing or changing things in the Struct doesn't seem to fix the problem.
Pressing 'S' while hovering over the __offset(...) causes it to remove my __inheritedmember.
D0ntPanic
commented
8 months ago
Version and Platform (required):
Bug Description: While working on an AArch64 project, I found that the variables would start to show
_offset(...)at random places for some struct member accesses. Some places it would also show a write to two int32_t members as a single int64_t write instead. I was able to determine that this only happened with members tagged as__inherited, and removing that tag would make it show up as expected in the High Level IL/Pseudo C View of the function. The first problem seems to be fixed in 3.5.4514, but the second one remains.I have managed to re-produce this problem with a minimal C++ x64 project, and have attached the compressed bndb.
Steps To Reproduce:
rax_2->childList's count and offset are combined, and also show the__offset(Address 0x14000122f)__inheritedtags from theHeapandOffsetListstructs and observe everything now looks as expected.Expected Behavior:
It's expected that the behavior with inherited members should be the same with non-inherited members. In this case it's expected to individually show the value being assigned to
ChildList.ListImpl::count = 0, andchildList.offset = 0xffffffff.Screenshots: Problem with
__inheritedin structs:After removing
__inheritedtag:Additional Information:
__offset(...)causes it to remove my__inheritedmember.BNDB: BinaryNinja_Inherited_Bug.zip