Refactor: Track IDA Function Changes outside Function Header about binsync HOT 16 OPEN

@mahaloz

from binsync.

p/arameters for changing_ti (before changing the type, which requires you to extract the old type) are:

def changing_ti(ea :identifier, new_type :tinfo_t, new_name :str)`

parameters for ti_changed (after the "new_type" has been applied) are:

def ti_changed(ea :identifier, result_type :tinfo_t, fnames :maybe(str?)`

So you're going to need to correlate these two callbacks to determine the source type being changed in "changing_ti", to when the type actually gets applied in "ti_changed". There's a few of the event hooks that use this changing/changed methodology so if you're interested in tracking changes through hooks, you'll likely be using the same logic for all of them. But, essentially it's up to you to distinguish the type of address you get and use it on the correct api.

The "ea" parameter (your "reference") is always an integer which really represents 1 of 2 things. One is an address in the database and the other is an identifier to the "structure/whatever" (structure view). To distinguish these, I'll use "address" to refer to an address that's visible in the database (and thus associated with a function or other visible address), and "identifier" to refer to an address that's actually one of the private addresses (used for structures, enums, etc. and are hence non-visible).

In most cases, though, it's okay to treat it just like an address (you can verify it by comparing against the bounds of the database. Outside of its bounds will make it an identifier). Iff you plan on using that or tracking changes to the types/structures themselves (not prototypes), just keep in mind that all the private identifiers can be translated when rebasing the database similar to addresses (meaning that they change w/ the db and you shouldn't store them). (This should be out-of-scope for binsync, since your goals are just for monitoring tinfo_t when it's applied to a function address).

The "proper" (and probably most robust) way to distinguish the integer reference (ea) from either an "address" or an "identifier", is by checking the reference using all of the identifier APIs (idaapi.get_struc, idaapi.get_enum_idx, etc.). However, if you only care about names/xrefs/etc associated with a function, I believe that checking against the database boundaries should be more than enough. (Although, there's also another way by comparing the integer against one of the fields in idainfo, namely INF_PRIVRANGE_*).

So, in the future if you end up deciding to handle the events for both identifiers and addresses, don't track them by identifier (i.e. don't store it in your type database and make sure you use names) or if you do, then make sure you test by rebasing things.

from binsync.

This worked 1/3 times, the other times it did not show up. I made multiple changes (e.g. changing to a different type, then changing back), but they still did not show up. Is there some time delay between action + revert before it gets picked up? e.g. i changed the type, and change it back within a second. Could this be why it does not show up?

from binsync.

@Lukas-Dresel yeah it can be around 5 seconds before the change gets picked up for committing. After that, it can be another 10 seconds before you see in your GUI. Total trip: 15 seconds max.

from binsync.

huh okay
let me try with waiting in between then

from binsync.

Okay, yeah, still does not appear to sync it for me, even after waiting 20+ seconds, so definitely a bug

from binsync.

Hmm, so it's a bit weirder than that? If i set the argument type to void* it does not appear to sync? but if i set it to person_t* then it does? that makes no sense

from binsync.

@mahaloz Oh okay, so here's what it seems to be

It does not update when the type is changed. It only updates once you actually enter the changed function in the decompiler view!

from binsync.

I did the above to change the type, waited for a minute or so just watching the repo to see if new commits show up. They did not.

But the second I then entered the function manually, the change showed up.

from binsync.

@Lukas-Dresel wait wait wait, you changed a type in a function in IDA without actually being in the function? How tf did you do that.

from binsync.

i changed the function signature in the function where the target function is referenced

from binsync.

just hit y on the function name

from binsync.

I changed the argument type.

from binsync.

Problem

If you take a look at @Lukas-Dresel GIF above, you will notice that he changes the prototype of a function without actually being in that function. With the current way we hook decompilation, its not possible to change this. The only way to fix this behavior is to find some new hook in ida that allows us to catch prototype changes, which we have still not been able to find.

from binsync.

        ui.hook.idb.add('changing_ti', typeinfo.changing, 0)
        ui.hook.idb.add('ti_changed', typeinfo.changed, 0)

those're in IDB_Hooks.

from binsync.

@arizvisa Oh shnappers. Does the hook pass a reference to the actual object being changed? Or is just saying literally any object with a type is changing?

from binsync.