Analysis loop caused by noreturn analysis due in part to approximated stack variable type

[ConnorBP]

Version and Platform (required):

• Binary Ninja Version: 5.4.9815-dev Personal, 25052627 (affects 5.2 and up)
• OS: windows
• OS Version: 10
• CPU Architecture: x86_64

Bug Description:
This certain function (sub_180acefa0) is unable to ever complete

Steps To Reproduce:
open client.dll in binary ninja, attempt to read vfunc5 (sub_180acefa0).

Expected Behavior:
It should finish analysis, but instead it flickers the stack variables indefinitely

Screenshots:
https://gyazo.com/970ad2ff083b8ca3a1ad2f7b14d48b4a.gif

Binary:
If applicable, please provide us with the binary to help us work with the issue faster. Here are a few options:

binary access phrase:
autumn kernel bonds knowingly

Additional Information:

This has been a problem for quite a while now and it remains the same on different builds of the same dll I am analyzing also. This one function refuses to finish analysis. It is really quite annoying. So annoying that I just spent 400$ just to hope i can finally read this function lol. Anyways I hope it's not too crazy of a bug to find.

[emesare]

Called functions also exhibit erroneous zmm registers in param and return positions like in #7673 (unrelated to analysis loop)

[ConnorBP]

Ah yes, I think those boiled all the way up from an unresolved virtual table call which filled in a guess of ZMM register usage based on zero info. I think this might have possibly been introduced in a previous fix from when ZMM registers were not able to be used in unresolved virtual or inter module calls at all

[emesare]

The issue which causes an analysis loop is due to an indirect call (at 0x180acfdbd) typed as no return (based on the base vtable), because the indirect call gets marked noreturn we rerun analysis but this time we do not correlate the call with the typed function pointer (with the noreturn) so then we update for a third time, and so forth.

The type information flows through a few stack slots, and is first assigned at 0x180acf075.

If you look at the above screenshot you will notice the stack slot (var_108) is assigned multiple times, all with different vtable pointers, the first assignment is the base vtable, which contains the following:

And if we zoom into one of the vfuncs marked no return:

In this scenerio what has occurred is our singular stack variable chooses to carry the type of the base vtable pointer, rather than the one which is actually observable during the time in which the indirect call occurs.

For this case the ideal analysis would be to assign the type of the last assignment in that block.

The user can prevent this noreturn by doing a few things:

1. Retype the stack variable var_108 to that of the CCSGOUserCmd::CUserCmd::VTable*, this will correct the vfunc pointer in vtable structure to not have a noreturn
2. Adjust the call type for the indirect call so that it cannot use the inferred no return call type

For 2 you can do the following assuming you have selected the function in the view:

current_function.set_call_type_adjustment(0x180acfdbd, "void(int*)")