Vector35 / Vector35/binaryninja-api
[API] Provide a way to get the originally intended qualified name from a qualified name or type ID
Nobody has claimed this yet.
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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