Vector35 / Vector35/binaryninja-api

`BNGetTypeReferenceId` returning incorrect reference for type with definitions from debuginfo and platform types

Open
#5,185 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Component: DebugInfo Effort: Medium Impact: High
Dominant language
C++
Stars
1.3k
Forks
298
Avg merge
5d 5h
Merged PRs (30d)
19

Description

Version and Platform (required):

  • Binary Ninja Version: 4.1.4959-dev, 9475ceaa
  • OS: macos
  • OS Version: 14.4
  • CPU Architecture: arm64

Bug Description:
Using NamedTypeReferenceType.target(bv) fails to get a reference to the correct type.

Steps To Reproduce:

  1. Have a type that is defined in both the platform types and the debug information. (platform.windows-kernel-x86_64 has multiple placeholder types such as _EPROCESS. The imported PDB will cause a _EPROCESS_1 to be defined.)
  2. Attempt to follow the target of a NamedTypeReferenceType that should reference a type from the debug information that is renamed with _1 using the .target(bv) method.
  3. See that the returned type is not the correct type.

Expected Behavior:
When a NamedTypeReferenceType's name is '_ETHREAD_1' I would expect the .target(bv) method to return the type object for _ETHREAD_1, instead of _ETHREAD.

Screenshots:
A console session showing the incorrect behavior:

>>> e1 = bv.get_type_by_name('_EPROCESS_1')
>>> e1
<type: immutable:StructureTypeClass 'struct _EPROCESS_1'>
>>> e1.members[18]
<struct _ETHREAD_1* RotateInProgress, offset 0x4d8>
>>> e1.members[18].type
<type: immutable:PointerTypeClass 'struct _ETHREAD_1*'>
>>> e1.members[18].type.target
<type: immutable:NamedTypeReferenceClass 'struct _ETHREAD_1'>
>>> e1.members[18].type.target.target(bv)
<type: immutable:StructureTypeClass 'struct _ETHREAD'>
# The above returned type is not the _ETHREAD_1 Type

>>> e1.children[18].children[0].target(bv)
<type: immutable:StructureTypeClass 'struct _ETHREAD'>
>>> e1.children[18].children[0].name
'_ETHREAD_1'
# The above name is the correct name, but the type returned from target is _ETHREAD not _ETHREAD_1

>>> e1.children[18].children[0].type_id
'platform.windows-kernel-x86_64:["_ETHREAD"]'
# The above type_id is not the type_id that is expected. The _ETHREAD_1 should be from the debuginfo

>>> bv.get_type_by_name('_ETHREAD_1').width
2200
>>> e1.children[18].children[0].target(bv).width
1
>>> bv.get_type_by_name('_ETHREAD').width
1

A console session showing that target does not work when working directly on a type from debuginfo:

>>> dbge1 = bv.debug_info.get_type_by_name('PDB', '_EPROCESS')
... 
>>> dbge1
<type: immutable:StructureTypeClass 'struct'>
>>> dbge1.children[18].children[0]
<type: immutable:NamedTypeReferenceClass 'struct _ETHREAD'>
>>> dbge1.children[18].children[0].target(bv) == None
True

Additional Information:
A workaround is to use bv.get_type_by_name or bv.debug_info.get_types_by_name with the name, instead of using .target(bv) on a NamedTypeReferenceType

https://github.com/Vector35/binaryninja-api/issues/5083
The above issue is related.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue with NamedTypeReferenceType.target(bv), using the platform and debug-information type lookups shown in the report. Compare the resolved type and type_id with bv.get_type_by_name and bv.debug_info.get_types_by_name; done means _ETHREAD_1 resolves to the debug-information type rather than the platform placeholder.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
api, reverse-engineering
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.