Version and Platform (required):
- Binary Ninja Version: [5.3.9434 (f7cf98e7)]
- Edition: Commercial
- OS: Windows 11
- OS Version: 10.0.26200 Build 26200
- CPU Architecture: x64
Bug Description:
When looking at the MLIL layer of analysis for byte assignments in the ssa_form, the source_operands includes where the existing destination variable was already defined as a variable use, when it is never read at this point, so isn't technically used.
Steps To Reproduce:
Have a register be assigned with a DWORD or QWORD mathematical operation.
Have the lower byte be overwritten by a BYTE write.
e.g.
183 @ 14003b984 rcx_50#51 = rcx_49#50 - 0x4e0853
184 @ 14003b98a rax_39#41 = rax_38#40 + 0x254307a9
185 @ 14003b98f rax_40#42 = rax_39#41 + rcx_50#51
186 @ 14003b991 rax_41#43 = rax_40#42 - 0x254307a9
187 @ 14003b996 var_4#1 = rax_41#43
188 @ 14003b99d rcx_50#52.cl = var_9#1 @ rcx_50#51
The use_sites for rcx_50#51 then shows 188 as a use_site.
But I would argue this is inaccurate, as the variable is never actually used at that address.
This then causes issues when trying to carry out taint analysis, as later on the binary does:
215 @ 14003ba02 cond:0#1 = (rcx_50#52.cl & 1) != 0
My taint analysis has tried relying on the use_sites, the get_ssa_var_uses, but both of these incorrectly show the register write prior to the byte write as a use.
As that instruction gets tainted, so too then does the 215 comparison, when actually both the byte write and the comparison are not part of the taint. The only way around this is to manually verify and track all the uses myself separately to the ssa, which is obviously not the way to go as it means doing SSA analysis again myself.
Expected Behavior:
At the point the rcx.cl 8 bit register is written with a new value, it should not record the previous write on the higher bits of the whole register as a use at this location, only if the whole register is later read.
Version and Platform (required):
Bug Description:
When looking at the MLIL layer of analysis for byte assignments in the ssa_form, the source_operands includes where the existing destination variable was already defined as a variable use, when it is never read at this point, so isn't technically used.
Steps To Reproduce:
Have a register be assigned with a DWORD or QWORD mathematical operation.
Have the lower byte be overwritten by a BYTE write.
e.g.
183 @ 14003b984 rcx_50#51 = rcx_49#50 - 0x4e0853
184 @ 14003b98a rax_39#41 = rax_38#40 + 0x254307a9
185 @ 14003b98f rax_40#42 = rax_39#41 + rcx_50#51
186 @ 14003b991 rax_41#43 = rax_40#42 - 0x254307a9
187 @ 14003b996 var_4#1 = rax_41#43
188 @ 14003b99d rcx_50#52.cl = var_9#1 @ rcx_50#51
The use_sites for rcx_50#51 then shows 188 as a use_site.
But I would argue this is inaccurate, as the variable is never actually used at that address.
This then causes issues when trying to carry out taint analysis, as later on the binary does:
215 @ 14003ba02 cond:0#1 = (rcx_50#52.cl & 1) != 0
My taint analysis has tried relying on the use_sites, the get_ssa_var_uses, but both of these incorrectly show the register write prior to the byte write as a use.
As that instruction gets tainted, so too then does the 215 comparison, when actually both the byte write and the comparison are not part of the taint. The only way around this is to manually verify and track all the uses myself separately to the ssa, which is obviously not the way to go as it means doing SSA analysis again myself.
Expected Behavior:
At the point the rcx.cl 8 bit register is written with a new value, it should not record the previous write on the higher bits of the whole register as a use at this location, only if the whole register is later read.