Vector35
demangled function type parameters are resolved incorrectly
Version and Platform (required):
- Binary Ninja Version: 4.2.6204-dev
- OS: macOS
- OS Version: 15.1 Beta (24B5077a)
- CPU Architecture: M3
Bug Description: getting the demangled function type and assigning it doesn't always work correctly. it doesn't matter if the type is defined or not.
Steps To Reproduce:
>>> demangle_gnu3(bv.arch, current_function.symbol.raw_name, bv)[0].parameters[0].type.target.type_id
'demange:[]'
>>> demangle_gnu3(bv.arch, current_function.symbol.raw_name, bv)[0].parameters
[IOMFB::AppleRegisterStream* ]
>>> current_function.type = demangle_gnu3(bv.arch, current_function.symbol.raw_name, bv)[0]
>>> current_function.type.parameters[0]
IOMemoryCursor::PhysicalSegment* arg1
this is happening even though IOMFB::AppleRegisterStream is defined and IOMemoryCursor::PhysicalSegment doesn't even exist in the bndb, I have no idea where it is pulling that from.
Expected Behavior:
current_function.type.parameters[0] should've been IOMFB::AppleRegisterStream* arg1.
Additional Information: working with a bndb that was opened before iOS typelib was introduced, however I am uncertain of its relevancy to the issue.
>>> bv.types.get("IOMemoryCursor::PhysicalSegment") is None
True
>>> bv.type_names.index("IOMemoryCursor::PhysicalSegment")
7540
another variant: shows correct name, but actually points to different type
What's the value of current_function.symbol.raw_name? The type name may be coming from that, or could be some artifact of the id being empty.
What's the value of
current_function.symbol.raw_name? The type name may be coming from that, or could be some artifact of the id being empty.
Sorry, I didn't get a notification for this comment somehow.
The value is __ZN27AMDRadeonX6000_AmdHdcpProxy12initWithInfoERKNS_12HdcpInitInfoE.
The type name displayed is correct, but the type it points to is the wrong one. It must be a problem with the id I would guess.
Yeah, looks like the demangler doesn't assign a type id to it properly:
>>> (t,n) = demangle_generic(Architecture["aarch64"], "__ZN27AMDRadeonX6000_AmdHdcpProxy12initWithInfoERKNS_12HdcpInitInfoE")
>>> t
<type: immutable:FunctionTypeClass 'int64_t(AMDRadeonX6000_AmdHdcpProxy::HdcpInitInfo const&)'>
>>> t.parameters
[AMDRadeonX6000_AmdHdcpProxy::HdcpInitInfo const& ]
>>> t.parameters[0]
AMDRadeonX6000_AmdHdcpProxy::HdcpInitInfo const&
>>> t.parameters[0].type
<type: immutable:PointerTypeClass 'AMDRadeonX6000_AmdHdcpProxy::HdcpInitInfo const&'>
>>> t.parameters[0].type.target
<type: immutable:NamedTypeReferenceClass 'unknown'>
>>> t.parameters[0].type.target.name
'AMDRadeonX6000_AmdHdcpProxy::HdcpInitInfo'
>>> t.parameters[0].type.target.type_id
'demange:[]'
Thanks for the report, looks like this has been causing some pretty nasty mistyped symbols when you only have the demangler for type information.
Fixed in ~>=4.3.6467-dev~ >= 4.3.6468
Yeah, it's the one going through CI right now, should include commit 74779826
That CI sure took a while, maybe you should look into improving that :^) Anyways, while it does not resolve into a random other type now, if the type already exists, it does not resolve into that type; Binary Ninja thinks it's a different one, just named the same.
no "struct" keyword, so it doesn't know what the type is
pressing S shows struct creation dialogue
>>> bv.get_type_id("AMDRadeonX6000_AmdHdcpProxy::HdcpInitInfo")
'98f6cd73-660d-45ea-aad2-1069d3a43d90'
>>> demangle_generic(bv.platform, current_symbol.raw_name)[0].parameters[0].type.target.type_id
'demange:["AMDRadeonX6000_AmdHdcpProxy","HdcpInitInfo"]'
CI took a while cause it actually took two builds before it succeeded :P
Looks like this part of the issue is fixed for you, just what remains is what is described in #4551, namely that of actually lining up the types the demangler creates with the types that exist in the view. I detailed a couple of the problems with this being fully solved in a comment on that issue.
CI took a while cause it actually took two builds before it succeeded :P
Looks like this part of the issue is fixed for you, just what remains is what is described in #4551, namely that of actually lining up the types the demangler creates with the types that exist in the view. I detailed a couple of the problems with this being fully solved in a comment on that issue.
Well, no, it's not that issue. Like with the previous issue details, it only happens to specific types and not all.
This type resolves, for example:
The only difference I see with the previous and this one, is that the other is behind a namespace and this one not
Haha yep, that's the second problem I detailed in there:
There's also a secondary problem of QualifiedName and The Great QualifiedName Flattening of 202X (v35: see internal wiki page) where the names returned by the demangler are structurally different than those entered by users, and need some post-processing to be correct. This is probably not required for this issue but it came up again because the demanglers started making types with those names that technically don't conflict with user types, but actually yes they do.
When a type has a namespace its qualified name is teeeechnically different than the one you have created (it is split into two components versus one component which includes the double-colon). I can look into mitigating this but it's going to be a pain to solve completely.
Ah, okay, I was going off memory and didn't remember this existing in the issue.