Vector35 / Vector35/binaryninja-api

Wrong register value displayed (PowerPC)

Open
#4,021 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Arch: PowerPC Component: Architecture Component: Core Impact: Medium
Dominant language
C++
Stars
1.3k
Forks
298
Avg merge
5d 5h
Merged PRs (30d)
19

Description

The value that Binary NInja assumes is in a register on PowerPC seems to be wrong sometimes. Is there anything I'm doing wrong, or is that a bug?

On PowerPC, registers r14-r31 are callee-saved, that means, when a function modifies them it needs to restore the original value at the end.

Still, I am seeing the following code in Binary Ninja:

Binary Ninja register bug

There's a lis-addi instruction pair that sets r30 to 808acc44.
Then there's a call to DrawTPLToObject which takes r30 + 0x70 as second parameter (r4). The value of r4 is correctly displayed as 808accb4.

Then, right after that function call is yet another call to DrawTPLToObject with similar parameters. It just adds a different constant to r30 (0x76 instead of 0x70).

But then BN assumes that r4 would be 808c0076, meaning, it believes that r30 would be 808c0000 instead of 808acc44. How does Binary Ninja get to that conclusion?

Sadly I am not allowed to share the binary (copyright), but if needed I can try to reproduce the issue in another self-made binary.

EDIT: The function DrawTPLToObject does indeed set r30 to 0x808c0000 during execution. But it also, definitely, sets it back to the proper original value, and BN seems to miss that.

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 with the PowerPC register-analysis behavior around the calls to DrawTPLToObject, using the reported r30 and r4 values as the expected and observed states. Reproduce the issue in a self-made binary if possible, then confirm that the displayed register value reflects r30 being restored after the call.

Written by the indexing model from the issue text.

Assessment

Domain
reverse-engineering
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.