mips disasm losing xrefs to offsets from $gp

[bowserjklol]

Version and Platform (required):

• Binary Ninja Version: 3.5.4526
• OS: MacOS
• OS Version: 14.2.1
• CPU Architecture: x64

Bug Description:
It appears that the disassembler is losing track of xrefs based on offsets from $gp when the value in $gp is saved to the stack and later loaded back from the stack. This worked correctly in 3.4.4271 but no longer functions as expected in both 3.5.4526 (latest stable) and 3.6.4728 (latest dev).

It's of note that In opening other mips binaries in 3.5/3.6, when $gp is not manipulated in the function prologue (like it is here in the example program), binja continues to find and label xrefs as I've come to expect. It seems like this condition only appears when $gp gets a new value loaded from the stack (even if that value is the canonical $gp addr).

Steps To Reproduce:

1. Open the provided binary and navigate to http_parser_main.
2. Observe in 3.4.x, xrefs to fputs, fflush and others are identified correctly.
3. Observe in 3.5.x and 3.6.x, binja loses the xrefs.

httpd.zip

Expected Behavior:
When the analysis is complete, we should see xrefs to the referenced libc functions.

Screenshots:

Example of binja mapping the calls to fflush and fputs from http_parser_main in 3.4.

Example of binja failing to find and label these cross references in 3.5 and 3.6. Note how it's happy to label the xref for memset but then loses track after $gp gets a value from the stack.

3.5

3.6

[xusheng6]

@lwerdna could this be related to your recent changes?

[lwerdna]

The offending build number is 4469 (4468 works).

EDIT: offending commit: https://github.com/Vector35/binaryninja/commit/d71b9dcef50fc508392a3b29c6dc6febf769afb0

[bowserjklol]

Just updating the ticket to report 4.0.4911 continues to exhibit the issue.

[psifertex]

Unfortunately for now we don't have a clean solution to resolving this. The commit that broke this was an important fix in other situations and we don't yet have a good solution for how we can get both working. We did try hard to evaluate if we could fix it before we shipped 4.0 but didn't see any easy solutions. We will definitely re-visit it later but we need to make sure the fix doesn't cause more problems than it fixes!

[bowserjklol]

Copy all @psifertex. All good! On my end, it's just a matter of keeping some code pinned to the 3.4 build so patterns using BinaryView like get_symbols_by_name() then get_code_refs() continue to function as expected.

[bowserjklol]

Hey all just wanted to bump this issue. Obviously not as important as the various fixes in 4.0.5336 and 4.0.4958 that have come out since February. Am left wondering if this is something that will be addressed in a future build as the inability correctly map cross references is really degrading my workflow. Thanks!

[bowserjklol]

Pushed up a small script to annotate a bndb (via comments and user-defined data references) as a work around.

This is by no means professional grade and definitely not something anyone should take seriously. Rather, it merely serves as a (weak) stop-gap for my own triage pipelines. I can't imagine it'll help anyone else out who is awaiting resolution on this ticket, but wanted to link it just in case.