Why is this particular conditional not being shown or only showing if (true)?

[psifertex]

This question has come up privately several times recently so I wanted to write up a longer explanation here.

Here's a good public example of the issue:

https://dogbolt.org/?id=ef01886f-417a-4194-9b99-a58d1e900605

Note that Binary Ninja's decompilation does not show a conditional branch in main that the other decompilers show but rather hides it entirely. First, let me just show the opposite case where the same dataflow system produces a far more useful result:

https://dogbolt.org/?id=24804c7a-b097-4933-bbbd-1c3f447e660c

Notice in that case, BN is able to produce a much better decompilation around the success/failure comparison. Ironically, it's even better than the original source code which had the changes to that variable split across the source intentionally and compiler optimizations disabled.

So what is this system and how do we change up the analysis in situations where we don't want it to be active?

This optimization step occurs even earlier than HLIL which might surprise you. Even in MLIL you'll see the conditional is merely if (true).

If we look at the Low Level IL you can notice that a local variable is created, initialized and then never changed. At least, under normal operation. We know that the call to gets can violate all sorts of assumptions here and that's what happens. You're expected to use this vulnerability to overflow an otherwise constant stack-value.

We're discussing some longer-term solutions to making our analysis be a bit more careful around potentially problematic calls (not so dissimilar from compiler protections trying to analyze where stack cookies should be applied, ironically!) but in the meantime, you have a few options.

The first is that you can enable the Keep Dead Code Branches setting:

With that enabled, you can at least see the otherwise unreachable section of code:

However if you want to keep the system from converting the comparison to a simple if (true) or if (false), there are two options. First, you can Patch/NOP where the local variable is initialized:

This prevents the analysis from seeing the variable as a constant 0 and produces:

The other option is to create a struct or array that encompasses both the local var_10 and the larger var 118. One way to do that is to just select var_118, press * and then use y to add 8 to the calculated length.

This works because it allows the analysis to understand that the call to gets with var_118 as a parameter can also be tainting var_10 as well.

[psifertex]

Asked... and answered... 😉