question on how to fix incorrect output from "full analysis". #3363
-
Using the "Full Analysis" Mode yields worse output than using the "Basic Analysis" Mode and then manually enabling "full analysis" for specific functions. As an example, I am looking at insomnihack18's "onewrite" challenge (https://github.com/guyinatuxedo/nightmare/tree/master/modules/17-stack_pivot/insomnihack18_onewrite). This is the output for two functions when using "full analysis": But when I do "Basic Analysis" and then manually enable "Full Analysis" for only those two specific functions, the output is correct (matches the assembly more). A couple noticeable differences between the two:
This is the case for almost all of the binaries that I have tested with Binja. No one else seems to have this issue and I'm wondering why. Are there settings that aren't enabled by default that I should? I've tried experimenting with turning stuff on and off (like autorun signature matching), but nothing seems to help. I'm able to stick the same binaries into Ghidra and IDA Free with their default settings and get the correct output. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
This is a result of the analysis being too conservative about preserving possible arguments. Essentially, if any callee goes down a path that might observe lots of register state ( As of 3.2.3895-dev I've implemented two new sets of heuristics that are geared towards very aggressively rejecting suspect parameters from being propagated into a function's parameter list, as well as being much more selective about inferring arguments at call sites where we take the heuristic path (e.g. no type information for the callee, or callees with unresolved branches, or variadic callees). The test case you provided is now rejecting the arguments that were causing you issues before on dev. |
Beta Was this translation helpful? Give feedback.
This is a result of the analysis being too conservative about preserving possible arguments. Essentially, if any callee goes down a path that might observe lots of register state (
setjmp
, or some panic/assertion failed paths) would propagate the accesses of possible parameters up through all of the callers, recursively and to an extent that harmed analysis.As of 3.2.3895-dev I've implemented two new sets of heuristics that are geared towards very aggressively rejecting suspect parameters from being propagated into a function's parameter list, as well as being much more selective about inferring arguments at call sites where we take the heuristic path (e.g. no type information for the cal…