Infinite Loop in Emulation with HeapFree Hook (Binee/Speakeasy Behavior) (unicorn versions 1.0.2, 1.0.3, 2.0.1)

[JoJoAbdellatif]

Description:
While emulating GoogleUpdateSetup.exe using Unicorn in conjunction with Binee and Speakeasy, the emulation gets stuck in an infinite loop at a specific point. This happens despite the HeapFree hook being implemented and invoked multiple times before the loop starts. The issue is reproducible in both Binee and Speakeasy and occurs at the exact same spot.

Steps to Reproduce:
- Use GoogleUpdateSetup.exe as the target binary.
- Set up emulation with the necessary hooks, including HeapFree.
- Start the emulation in Binee or Speakeasy (both Unicorn-based).
- Observe the infinite loop occurring after several HeapFree calls.

Expected Behavior:
- The emulation should proceed beyond the infinite loop, and the HeapFree hook should work consistently.

Actual Behavior:
- The emulation enters an infinite loop, and the HeapFree hook is not invoked for subsequent heap operations.

Debugging Details:
Binary Behavior (Real Environment):
- On a real machine, GoogleUpdateSetup.exe runs without entering an infinite loop.
- Observed memory states and API call sequences do not match emulated behavior.
Emulation Logs:
- Logs show repeated instructions without progressing beyond the loop.
- Hook calls (HeapFree and others) are consistent before the issue arises.

Environment:
- Unicorn Version: 1.0.2, 1.0.3, 2.0.1
- Host OS: Windows 11
- Emulators: Binee and Speakeasy
- Target Binary: GoogleUpdateSetup.exe

The following screenshot is where it enters an infinite loop. This just shows the instructions it executes:

When I log the things that happen behind the scenes, such as the current address and ticks, after the third RtlAllocateHeap at the very bottom of the screenshot above, this is what it shows:

Same addresses, but the ticks are advancing. The more I leave this going, the more the ticks are incremented, but it's stuck in the same addresses.

This is the file in question
google update.zip

[wtdcode]

As far as I can see, you shall send the issue to the two projects you mentioned, no?

[JoJoAbdellatif]

well it seems it might be coming from unicorn since both projects are having the exact same behavior, right?

[wtdcode]

well it seems it might be coming from unicorn since both projects are having the exact same behavior, right?

No. The behavior you described so far could be expected for Unicorn, though not for these wrappers. That's why you should ask them instead of here.

[JoJoAbdellatif]

So when I first encountered the issue, I left it for 30 minutes and it was still stuck in the same area. Would it still be expected from Unicorn to do that?

If it still could be expected, is it possible to share maybe some of the circumstances in which this behaviour is expected? Maybe by understanding more in this part I'll be able to understand a better picture of what's actually going on

[wtdcode]

For instance, the easiest loop (in x86) is something like: lbl: jmp lbl and if you let Unicorn emulate this instruction, it definitely will get stuck here. This is not Unicorn's fault.