Can't resolve function call stack offsets with shared fixup instruction

[grokeus]

Describe the bug I've got x86 binary with following assembly code:

It seems that BN unable to deduce that last basic block (at the picture) always will have same stack offset, so it produces invalid HLIL at this point:

So, I can't see arguments for next function calls (even "Override Call Type" doesn't help)

there two files in attach:

1. test1.elf - files produced by compiler
2. wrong.elf -This file actually has the same behaviour as first one, but was manually patched in order to simulate real-world case from binarywhich unfortunately I can't share.

I'm unable at this moment to find out exact compiler option which will force to generate buggy code without my patch. All patch is just instead

   call t2_a2
   add esp, 0x10
   jmp a
   ...
   call t4
   add esp, 0x10
a:
   ...

make

   call t2_a2
   jmp b
   ...
   call t4
b:
   add esp, 0x10
a:
   ...

BN version - 2.3.2802-dev, Build ID 86543874

To Reproduce Steps to reproduce the behavior:

1. Download attached binaries
2. Open wrong.elf in BN
3. Goto test function
4. See at 0x139e

Expected behavior I guess we should deduce that stack offset will be same for all paths and have same HLIL for both binaries (this one from test1.elf):

Binaries: bins.zip

[CouleeApps]

This is partially mitigated in 2.4.2902-dev with the inclusion of the "Show Stack Pointer Usage" option in LLIL. While the underlying bug (two functions share their stack fix instruction) is not fixed, it will be easier to discover how to work around the issue and see where to override stack adjustments:

In the meantime, I'll retitle this issue to reflect the underlying bug

[saruman9]

I have the similar issue in 3.0.3233. I tried to set a value for the esp register for fixing stack frame offset and ran reanalyze of the function but it doesn't work. Are there any ways to fix this?

[saruman9]

FYI 4.1.5747 still has the bug and I can't find workaround...

[saruman9]

This problem is still present, correcting the offset of the stack depth (via User-Informed DataFlow) does not lead to anything. Version: 4.2.6455. Is there any information about fixing this issue?

[saruman9]

Sorry for spamming here, but this issue occurs in almost every binary file I analyze. I haven't come up with a solution or even a dirty hack yet, and I haven't received any response from the developers either.

In addition to the issue described in this ticket, I also frequently encounter cases where Binary Ninja fails to determine the value of the esp/rsp register. For example, after an operation like rsp = rsp - rax // rsp after: UndeterminedValue, all subsequent function calls appear as follows (with all stack arguments left undefined):

*(uint64_t*)((char*)rsp_1 - 0x10) = 0x36d;
*(uint64_t*)((char*)rsp_1 - 0x18) = "processing.c";
*(uint64_t*)((char*)rsp_1 - 0x20) = rax_66;
 __fprintf_chk(/* nop */, /* nop */)

[psifertex]

Very sorry for the delay with a proper response. We are all heading to RE//verse this week, I will try to get a response from someone sooner but worst case we will assign for triage and get a better response next week.

[plafosse]

The original binaries in this issue no longer exhibit and issue.

When the stack becomes unresolved you need to "Set Stack Adjust" to correct the issue:

For the example provided of

esp += eax

This is a stack allocation and we currently do not support this. Please follow https://github.com/Vector35/binaryninja-api/issues/1028 for more updates.