ReachingDefinitions wrong keys inside dep_graph.

When using the ReachingDefinitions analysis I’ve spotted an inconsistency between the keys we are trying to retrieve and the keys that are actually pushed in the dep_graph. To be more precise, while running the provided POC over the binary I’ve shared here, I have a KeyError exception while dumping the dep_graph using networkx.

KeyError: <Definition {Atom:<Reg 20<1>>, Codeloc:[External], Data:DataSet<32>: [<Param <Reg 20<1>>>]}>

This definition seems related to the definition regarding the arguments of the function under analysis The correct Definition would be:

KeyError: <Definition {Atom:<Reg 20<4>>, Codeloc:[External], Data:DataSet<32>: [<Param <Reg 20<4>>>]}>

So, maybe an incorrect definition is being pushed somewhere?

Environment Information. You will need to install the autoblob module to load the binary and reproduce this. (https://github.com/subwire/autoblob)

To Reproduce. Just do: python reach-def-bug.py You should see the KeyError exception.

Additional context. (I’m in sync with @Pamplemousse to solve this ). reach-def-bug-000.zip

[ltfish]

I git-blamed the code, and it was originally my line… it’s much easier for me to say “this is incorrect” when it was my fault.

All atoms are supposed to be 100% immutable. The correct fix is to change that line so that instead of modifying an existing atom, we create a new Register instance with the intended size. Therefore, PR #2089 is not a correct fix.

[degrigis]

So, we have discovered that there is a conversion happening here that is triggered by a <SimIROp Iop_32to8> operation. This is modifying the size parameter of the Register atom and since the __hash__ method was relying on mutable data, the hashes for these objects were mismatching later. @Pamplemousse already issued a PR to fix the hash problem, but we were wondering if this issue has been possibly caused by missing support for all the conversions of a LoadG operations.

@ltfish what do you think?