search

Vector35 / binaryninja-api

Public API, examples, documentation and issues for Binary Ninja
https://binary.ninja/
MIT License
842 stars 194 forks source link

mips disasm losing xrefs to offsets from $gp #4839

Open bowserjklol opened 6 months ago

bowserjklol commented 6 months ago

Version and Platform (required):

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.

httpd_3 4 4271

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

httpd_3 5 4526

3.6

httpd_3 6 4728
xusheng6 commented 6 months ago

@lwerdna could this be related to your recent changes?

lwerdna commented 5 months ago

The offending build number is 4469 (4468 works).

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

bowserjklol commented 4 months ago

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

image
psifertex commented 4 months ago

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 commented 4 months ago

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 commented 1 month ago

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!