C APIs sufficient to copy IL functions
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Domain
- compilers, reverse-engineering
Research direction
Start with the modifying IL documentation and the BN*LevelILAddExprWithLocation C API, then compare how copy_to is implemented in the Python and C++ bindings. The work is complete when the C API exposes a stable way to support copying IL expressions, such as operand-type information or an equivalent copy operation, without requiring callers to hardcode instruction details.
Written by the indexing model from the issue text.
Description
What is the feature you'd like to have?
The documentation for modifying ILs recommends using the copy_to function for all expressions you don't want to change. copy_to is implemented in the Python and C++ bindings. But what if I want to do it with just the C API?
To actually add expressions to the new IL function, I can use the same C API functions used by copy_to, BN*LevelILAddExprWithLocation. The problem is knowing what operands to pass. I can't just copy the operands directly from the old BN*LevelILInstruction, because some of the operands are expression indexes, and those need to be replaced with their corresponding indexes in the new IL function. The mapping from operand index to the type/meaning of the operand depends on the instruction type and, as far as I can tell, is not exposed in the C API in any way (except indirectly through rendering to text). The Python and C++ bindings make copy_to work by hardcoding this information for every possible instruction. But I don't want to hardcode it in my own code, since it would make my code very fragile in the face of changes to the ILs.
So I'd like to see a "get operand type" function, where you pass an expression and operand index and get back an enum (something like the *LevelILOperandType enums in the C++ API).
Are any alternative solutions acceptable?
Any API sufficient to implement copy_to would work. Some alternative possibilities:
- The API could be designed to go through "usage" values like the C++ bindings do.
- Or the API could just be a C version of
copy_toitself, rather than exposing the lower-level type information needed to implement it. But this would be less useful since operand types have other uses besides copying.
Also, since I'm using Rust, adding copy_to to the Rust bindings would satisfy my need to some extent. But I've started using my own bindings for IL manipulation rather than the official Rust bindings, so having the functionality in the C API would be better for me.
- Dominant language
- C++
- Stars
- 1.3k
- Forks
- 298
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 19
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.
More from Vector35/binaryninja-api
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Vector35/binaryninja-api#8540 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Vector35/binaryninja-api#8516 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Vector35/binaryninja-api#8503 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Vector35/binaryninja-api#8446 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Vector35/binaryninja-api#8444 ·
All issues in Vector35/binaryninja-api
Similar issues
-
Website Doc Typo Open
Difficulty 1/5 Under an hour Newbie friendliness 92/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 92/100
autowarefoundation/autoware_universe#13413 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
automated-analysis bug memory-safety
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100