Vector35 / Vector35/binaryninja-api

[API] Provide a way to get the originally intended qualified name from a qualified name or type ID

Open
#6,456 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

What is the feature you'd like to have?
Given a type ID, it would be useful to get the original qualified name intended for the type before it is changed to avoid conflicting type names. For instance, the following code generates 2 types with the qualified name Foo::Bar:

qname = QualifiedName([ "Foo", "Bar" ])

# Generates a type named `Foo::Bar`
bv.define_type(Type.generate_auto_type_id("baz", qname), qname, "typedef uint64_t")

# Different type ID - generates a type named `Foo::Bar_1`
bv.define_type(Type.generate_auto_type_id("quux", qname), qname, "typedef uint64_t")

The result is 2 types where the second one is called Foo::Bar_1 to avoid a naming conflict. The types having the following type IDs respectively:

  • baz:["Foo","Bar"]
  • quux:["Foo","Bar"]

It would be useful to be able to get the original qualified name given a named type with the qualified names Foo::Bar_1, or get it from either of the 2 type IDs specified above. All of which can be retrieved from a named type reference.

Its clear from the type IDs that they could be parsed to extract the original qualified name from them but its likely error prone under edge cases considering that things like the following can be done:

bv.define_type(Type.generate_auto_type_id("quux:[\"Foo\",\"Bar\"]quux:", QualifiedName([ "Foo", "Bar" ])), QualifiedName([ "Foo", "Bar" ]), "typedef uint64_t")

Resulting in a type ID of quux:["Foo","Bar"]quux::["Foo","Bar"]. Whilst this is unlikely it seems reasonable that the API could provide a robust way to get the originally intended qualified name for a type given it already keeps track of type IDs used to define a type in the first place.

Is your feature request related to a problem?
Plugin functionality might rely on the name of a type being used for a lookup. Whilst a plugin can track the deconflicted qualified names for types its created, it can't for other plugins, or types from type libraries that often get applied automatically. Guessing about whether Foo::Bar_1 is actually suppose to have that name or whether it really meant to be Foo::Bar is a tricky game thats error prone and the difference can be useful.

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 with the Type.generate_auto_type_id and define_type entry points and the named type reference API described in the issue. Trace how the original QualifiedName is retained for generated type IDs and deconflicted names; done means callers can retrieve that name robustly from either form, including the shown edge case.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp, python
Domain
api, reverse-engineering
Issue type
Feature
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.