Why do some local variables have second numbers?

[seanthegeek]

I'm learning malware reverse engineering and currently working with this sample BB1730B09C6C47304CF71A902D006B80DCF6CA8FBC179856393073FAAFD68D55

at 00402efc, The address of the function InternetReadFile is stored as var_28_1, but when that address is called at 00402f40, the variable is labeled as var_28_2, which only shows up in those push and call operations.

Ghidra shows the variable and call correctly.

Is this a bug in Binary Ninja?

[fuzyll]

Hey Sean! I got your email about this as well. Sorry for the long wait for a response.

This isn't a "bug" - it's just a difference in how Binary Ninja did its analysis. (Although, we do currently lack the ability for you to manually merge them if this happens in HLIL instead of disassembly, which is a bug/missing feature: #1887.)

If you click on each version of var_28 and hit "y", you'll see they're typed differently: var_28 is an int32_t, var_28_1 is a void*, and var_28_2 is an HMODULE. (I'm not sure why var_28 is used after var_28_1, but it's probably related to the order in which types were applied while the function was being analyzed.) Because the type differs in each usage, Binary Ninja assumes these must be different variables that are simply aliased (unintentionally, by the compiler) to the same memory location, rather than a union of 3 different types.

You can see this a bit better with var_14. The var_14s you see on each push refer to the location ebp-0x014 and are used for the same function call (the call esi). These are all the same type (because esi is the same function pointer each time), so Binary Ninja assumes this is the same variable, even though they are different values for each call. But, later, at 0x00402ef3, that same memory location is being used in a different context (as an argument to the call dword [ebp-0x30] at 0x00402eff) with a different type. So, that usage gets the name var_14_1.

Ghidra says "these are the same thing" because they're at the same memory location and, quite possibly, have the same type. Binary Ninja says, "these are probably different things" because they're not being used the same way and have different types. Which one is "correct" will depend on the code in question and automatically determining this in all scenarios is a Hard Problem ™️.

In reality, it's probable that some/all of these aren't "variables" in the way you might understand them as a developer. This is why, for example, var_14 doesn't show up in the HLIL/Pseudo C decompiler output: It's just the compiler temporarily assigning/moving a value somewhere while it does what's required to make the function call.

Hopefully that made sense! (And, thanks for the discussion item. I'm pretty sure we do have a bug that this sample uncovered, but it's not the one you reported!)

[psifertex]

Note that the other thing we found there is described in: #3004