MLIL doesn't properly infer _guard_dispatch_icall_nop as taking rax as the first parameter.

[marpie]

Current Windows PE files (from Microsoft, on x64) contain (most of the time) CFG constructs (like _guard_dispatch_icall* functions) that are replaced by the loader to invoke control flow guard protections.

In current Binary Ninja versions (at least on the latest stable and 2.0.2201-dev) the CFG calls are not replaced by the targeted function, e.g.

which is translated to HLIL as:

The correct behavior would be to eliminate the guard call (which is just a call rax) and display it like:

RtlQueryRegistryValues(1, "NdisWan\Parameters", r8, 0, 0)

The following file can be used as an example that implements the CFG icall:

https://msdl.microsoft.com/download/symbols/ndiswan.sys/559f3aa835000/ndiswan.sys

• Function: NdisWanReadRegistry (0x1c002fd65)
• ical: 0x1c002fdff (to RtlQueryRegistryValues@IAT)

[joshwatson]

It's actually calling NdiswanDWORDQueryRoutine and RtlQueryRegistryValuesEx is a UNICODE_STRING being passed in, but the vast majority of the time, these types of calls are not going to have a clear cut symbol to call. So, it can't just be replaced. Instead, it's better to just annotate the call with its parameters.

[marpie]

It's actually calling NdiswanDWORDQueryRoutine and RtlQueryRegistryValuesEx is a UNICODE_STRING being passed in, but the vast majority of the time, these types of calls are not going to have a clear cut symbol to call. So, it can't just be replaced. Instead, it's better to just annotate the call with its parameters.

Oh ok, I thought as the _guard_dispatch_icall_nop is a jmp rax it would go to RtlQueryRegistryValues as that is placed in rax. I will look at it more closely.

[ccarpenter04]

It would be nice if this could be improved upon since I believe Microsoft turns this option on by default in msvc for release builds.

[plafosse]

This will likely be dependent on #1606 as we would need a platform specific analysis pass.

[plafosse]

One quick hack to get this analyzing better would be to on the dynamic dispatch call changed click 'E' and edit the instruction to be call [rax] this helps analysis be accurate.

[plafosse]

The problem actually doesn't appear to have anything to do with HLIL. The MLIL layer isn't properly inferring the parameters.

[plafosse]

Fixed in 3.1.3731 which adds a new feature to translate these calls to a call rax at the call site. This is controllable by the analysis.experimental.translateWindowsCfgCalls setting.