MLIL_ADDRESS_OF intended use

[rnui2k]

I would to preface with that I am still very much a novice in terms of using the BN API. So please forgive the misuse of terminology. It was the recommendation of @psifertex that I offer up my question to a Discussions thread.

During the analysis of various binaries, I'm constantly finding myself hitting the dreaded MLIL operation MLIL_ADDRESS_OF. As an example, while tracing some variable it will enviably be passed by reference to a function. At which point my analysis technique breaks due to not being able to programmatically trace the variable being passed. Which is quite frustrating because I am not sure if my technique is flawed or if I don't understand the API well enough to overcome this issue.

Doing a little bit of research, I see that @D0ntPanic says it was a design decision to have the (SSA) variables not included in uses/definitions ( #836 ) when a variable is being accessed by-reference. The explanation provided seems reasonable enough, but the problem still persist.

To be clear, I am neither for or against the design decision. My intended purpose for this discussion is to understand the design decision and figure out how to solve this common issue. As stated above I am still a novice, so I apologize if there is already a solution implemented and I overlooked it.

Somethings I have considered:

• Performing a mini-analysis upon entering a function to find all MLIL_ADDRESS_OF operations and creating new variables. Which doesn't seem very elegant and prone to throw off my variable tracing.
• Every instance of me "losing track" of a variable, analyze the entire function for MLIL_ADDRESS_OF operations and see if my variable is being consumed by that operation.

Hopefully I presented my question(s) clearly.

[rssor]

Just to clarify your use case: are you concerned with finding possible sites of the contents of the var being accessed, or are you interested in tracing where those references to the var spread?

Once the address is taken, the 'version' of such a variable is tied to the active memory version.

If you're just interesting in seeing where it could have been passed to you'd want to recursively follow the use chains for the results of the address taking expressions.

[rnui2k]

The specific case right now is I've traced a variable to a point where there are no more SSA definitions. Looking at the MLIL, I can see that it is passed by reference in two locations prior to my stopping point (by prior I mean the two MLIL_ADDRESS_OF instructions execute prior to where my script stopped tracing). Visually I can see the MLIL_ADDRESS_OF (i.e. rdi_7 = &mybuffer), but when I look at the use chain for mybuffer, those two instances of MLIL_ADDRESS_OF are not included.

My end goal is embarrassingly simple, I just want to print out that the variable is passed (by reference ) to a function 2-3 instructions below it. Overall however, this is a reoccurring problem for me that I have been struggling to handle.

[rssor]

Okay, I follow. In this case, your second option is above is what I'd do -- scan for instructions of MLIL_SET_VAR(_, MLIL_ADDRESS_OF(var_you_care_about)) to recursively find additional things to trace. Make sure to keep track of which vars you've already attempted to handle, and you're also going to have to figure out what to do about MLIL_VAR_PHI etc. ops. (Is the possibility of making it to a call site interesting, or do you only care about knowing definitely when a reference must have passed into a call site?)

It seems ugly, but the cost of the linear scan in an MLIL function pales in comparison to the cost of actually generating the MLIL function, so it shouldn't be more than a rounding error even using Python. If it's proving not workable even at that point, we could look into adding something along the lines of uses specifically for tracking alias sites, but I'd be surprised if the optimization is necessary.