Vector35 / Vector35/binaryninja-api
Ambiguous warning when a workflow makes a bad modification to MLIL
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 1.3k
- Forks
- 298
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 19
Description
Version and Platform (required):
- Binary Ninja Version: 5.3.8707-dev Ultimate (a74ed668)
- Edition: Ultimate
- OS: macOS
- OS Version: 15.6
- CPU Architecture: M1
Bug Description:
I have a function workflow activity thats removing instructions in MLIL. Previously it was working fine and then I made some changes and now I'm getting lots of the following warning:
[Default warn] Cannot find the source block of mlil@7 in function <address>. Did you forget to call MarkLabel() during lifting?
The problem with the warning is that it always says mlil@7 no matter what function it states the issue occurred in. Also I've gone to some of the functions it warns about and toggled the function workflow on and off for that function and for some of those functions the warning will be printed when I toggle the workflow back on but for some it won't. So I'm not convinced its even reporting for the correct functions. What also makes me feel this way is that I appear to be making valid changes (by comparing the before and after changes) to the function and I'm using the documented way of removing instructions.
Expected Behavior:
It's likely that my plugin workflow is doing something wrong but I think the warning information is also incorrect. At least it doesn't appear to make any sense.
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 workflow activity that removes MLIL instructions and compare its behavior with the documented BNIL modifying and copy-transformation guidance. Reproduce the warning while recording the function and MLIL location, then check whether the fixed mlil@7 and reported function are accurate. Done means the diagnostic identifies the actual source block and function, or the behavior is reduced to a minimal reproducible workflow.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers, reverse-engineering
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100