Vector35 / Vector35/debugger

Rebasing severly limits the effectiveness of analysis hold during launch

Open
#755 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

binaryninja enhancement functionality Impact: Low
Dominant language
C++
Stars
331
Forks
33
PR merge metrics
No merged PRs in 30d

Description

A useful feature of the debugger is to "analysis hold" on during debugging. This way, the analysis is limited to the currently visible functions which significantly reduce the likely unnecessary analysis updates. However, when we need to rebase the input binary, the effect is severely limited during launch

To start with, during launch, if we have previously enabled analysis hold, we will have to disable it temporarily (https://github.com/Vector35/debugger/blob/a046bcd862b46d0db280ef6bf292c9443b581bcc/core/debuggercontroller.cpp#L1156). This is because if we do not do so, all of the basic blocks of the function would not be created, and when we pause inside of a function, the debugger is unaware of it (because basic blocks are gone), and it will create a new function at the location.

As a result, we can only turn analysis hold back on after the analysis completes (https://github.com/Vector35/debugger/blob/a046bcd862b46d0db280ef6bf292c9443b581bcc/core/debuggercontroller.cpp#L1171). This works fine, but it kinda goes against the original motivation of introducing the analysis hold -- to suppress as much as re-analysis as possible

I know this probably would not be easy not fix -- a potential improvement is to ensure that during rebasing, "basic" analysis info like basic blocks are not discarded. But that means they need to be updated in place (to account for the new base), which may or may not be easy to do. Also, while having the basic blocks info definitely helps the debugger, the lack of complete analysis info may lead to subtle debugger behavioral differences, e.g., the missing of variables could affect how the debugger annotate them. So it sounds like this couldn't really be resolved until we have a complete overhaul of the rebase? Well I dunno, just dumping my observations and thoughts here for later reference

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 in core/debuggercontroller.cpp around the analysis-hold handling at lines 1156 and 1171, and trace how launch rebasing discards or recreates basic blocks. Determine whether rebasing can preserve the basic analysis information while keeping debugger state correct. Done would avoid unnecessary full re-analysis without losing function or variable awareness during debugging.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
devtools, reverse-engineering
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.