Version and Platform (required):
- Binary Ninja Version: 6.0.10489-dev
- Edition: Ultimate
- OS: macOS
- OS Version: 26.6
- CPU Architecture: arm64
Bug Description:
One of the common types of Delphi function prologue uses a loop to allocate a fixed amount of stack space, causing LLIL's stack recovery to break.
Steps To Reproduce:
- Open binary, dogbolt corpus sha256 60bdc2d5e9728214d5c5cf43e9abb62d62c0afbeecdc737a7f482e09b5c773e1
- Navigate to 0x004180f4
- Observe broken stack recovery
Expected Behavior:
I expected stack recovery to work
Screenshots/Video Recording:
Binary:
See dogbolt corpus 60bdc2d5e9728214d5c5cf43e9abb62d62c0afbeecdc737a7f482e09b5c773e1 or on internal slack under caesar_cipher.exe
Additional Information:
On public slack Michael F reported the same issue with a different (unknown) binary. The binary in this issue is compiled with Delphi ~2010 and uses this pattern in a number of places to set up a stack frame, and seems like it has the identical prologue and behavior.
We already have support for patterns nearly identical to this one, see Vector35/binaryninja@1f93de3128bc086aedc4c7f5580ab98632fef568, but due to this using x86's dec ecx causing a spill to a temporary register during the loop, this specific pattern is not handled.
I had Codex generate a workflow plugin that attempts to handle this case, which seems to work for exactly this function but unconfirmed in the general case. That is available here: wf_delphi_intro.py
Version and Platform (required):
Bug Description:
One of the common types of Delphi function prologue uses a loop to allocate a fixed amount of stack space, causing LLIL's stack recovery to break.
Steps To Reproduce:
Expected Behavior:
I expected stack recovery to work
Screenshots/Video Recording:
Binary:
See dogbolt corpus 60bdc2d5e9728214d5c5cf43e9abb62d62c0afbeecdc737a7f482e09b5c773e1 or on internal slack under caesar_cipher.exe
Additional Information:
On public slack Michael F reported the same issue with a different (unknown) binary. The binary in this issue is compiled with Delphi ~2010 and uses this pattern in a number of places to set up a stack frame, and seems like it has the identical prologue and behavior.
We already have support for patterns nearly identical to this one, see Vector35/binaryninja@1f93de3128bc086aedc4c7f5580ab98632fef568, but due to this using x86's
dec ecxcausing a spill to a temporary register during the loop, this specific pattern is not handled.I had Codex generate a workflow plugin that attempts to handle this case, which seems to work for exactly this function but unconfirmed in the general case. That is available here: wf_delphi_intro.py