Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BinDiff GUI does not show merged ranges in the correct order #53

Open
Muirey03 opened this issue Sep 11, 2024 · 1 comment
Open

BinDiff GUI does not show merged ranges in the correct order #53

Muirey03 opened this issue Sep 11, 2024 · 1 comment
Labels
question Further information is requested

Comments

@Muirey03
Copy link

Describe the bug
BinExport will merge basic blocks on unconditional branches, however if these blocks are not in increasing order of address, the UI will simply show the instructions in completely the wrong order. This can cause problems in lots of programs, but specifically causes major issues when combined with plugins like FunctionInliner that add unconditional branches to new segments.

To Reproduce
I have attached (report.zip) two programs to diff against to demonstrate the issue. The programs are compiled with: cc -o a -O0 a.S. If you diff them with BinDiff in IDA and compare the flow graphs in the BinDiff GUI, you will see that the following instructions appear at the end of the function, instead of their correct place before the ret:

mov x3, #0x43
mov x4, #0x44

Expected behavior
These two mov instructions should appear before the ldp x29, x30, [sp], 16 instruction. When the BinDiff backend iterates over the instructions in this function from BinExport, it does indeed iterate over it in the correct order, it is just the GUI that incorrectly sorts the instructions rather than leaving them in the same order from the backend.

Screenshots
Function flow graph from IDA
Function flow graph from BinDiff GUI

Environment (please complete the following information):

  • OS and version: Windows 11
  • Locale: British English
  • Disassembler and version: IDA Pro 8.4

Additional context
N/A

@cblichmann cblichmann added the question Further information is requested label Sep 16, 2024
@cblichmann
Copy link
Member

Hi! Thanks for your report.

What you're seeing is expected behavior - if a bit confusing. We treat every straight line program as a basic block (i.e. any sequence of instructions that "flows" into the next). This means that unconditional jumps do not introduce new basic block boundaries. About the only time we break up a basic blocks is when parts of its instructions are shared with other basic blocks (like a different part of the program jumping into it).
Thus, the UI renders this as a single basic block and show the instructions as they are laid-out in memory.

I agree that this can look odd and it would probably be useful to render exactly like IDA Pro does to avoid such confusion. Ideally, this could be switched with a config option, but the UI itself has no concept of instructions or basic blocks - it just renders the graph.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants