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:
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.
To understand whats going on here we'd need to see what's happening in DrawTPLToObject if you can reproduce the issue in another binary that would be very helpful.
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:
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.