Show BSim/Version Tracking suggested names inline for unnamed functions

[plucia-mitre]

Is your feature request related to a problem? Please describe.

I'm always frustrated by how infrequently I find people using BSim, Version Tracker, or other code similarity tools. They are very useful, but the reality of using them at scale makes them impractical in many if not most cases. The need to use a different tool (version tracker) or switch to a new window/panel to lookup each "FUN_" function (BSim) for a possible match is too much context switching and not feasible when looking at a function which calls dozens of other functions, each of which is just shown as "FUN_" in the assembly and decompiler windows. Likewise, a "Function" or "Symbols" panel full of "FUN_" is not particularly useful.

Describe the solution you'd like

I would propose that everywhere "FUN_" is currently shown in the Ghidra interface (especially in the CodeBrowser and related tools), and that function has a VT or BSim match above a user-configurable similarity and confidence threshold, instead display something like "BSIM_82_strcmp" or "VT_98_memcpy". In these examples, BSIM and VT are where the match came from, and 82 and 98 are the similarities to the named function (which follows).

It's important to note that this would only be a DISPLAY of the best matched name, not an automatic renaming. The underlying binary database would keep its current unnamed state (unless a name is accepted, see below). What is considered best should probably be something like highest similarity * confidence, but there may have to be some normalization function across tools. Perhaps this could be configurable by the user with reasonable defaults.

This change would save context switching to check for matches and make available matches immediately useful.

Ideally, the user would be able to hover over this function name to see which binary the displayed match came from as well other top-similarity matches. Ideally there would be an easy (right click?) option to "accept/apply" a given function name, copying that name to the local binary's database (and ideally keeping provenance metadata somewhere... but this might be scope creep for this feature).

The less user-interaction needed to configure and use this feature the better. Ideally, it automatically pulls matches from all VersionTracker sessions where the current binary is the target and any appropriate matches from the currently configured BSim server. In all cases, matches to other functions that do not have a name should not be shown (i.e.: Don't show a match to a "FUN_" function; that's not helpful for this use case)

It's likely that a "cache" of matches will be needed locally to not hinder Ghidra's performance.

Describe alternatives you've considered
Using the tools as-is.

[ryanmkurtz]

Moved to Discussions so the idea can be further developed.

[dragonmacher]

As I'm sure you can imagine, this is a topic we have discussed quite a bit.

Version Tracking was designed to be a transient experience used to migrate data from a reversed binary in your project to a newer version of that same binary (e.g., a patched version of an existing binary). Using VT in this way allowed us to make the development process much easier, as we do not have to deal with the trappings of long-term database management of VT sessions. (That being said, we are aware that users do keep their VT sessions around long-term.)

Considering the transient nature of VT session information, it is not, in its current form, a good candidate for being used the way you request in this discussion.

Using BSim information would certainly make the RE experience much richer in Ghidra. The problem I see with that is there would be a lot of configuration (read: clunky and fiddly). Conceptually, we would probablyl make something like this into an analzyer. That analyzer would have to know how to access BSim databases. It would also have to allow the user to configure thresholds for how to make suggestions and optionally apply matches that pass some threshold. The last part, showing the BSim info in the Listing would probably be the easy part of this.

As with many of our more speculative analyzers, there is often no right answer, but more of a 'do some stuff and see how it looks' approach. I agree that there is an opportunity here to make better use of BSim for those users that have done the work to build the BSim data.

[plucia-mitre]

Thank you for the feedback!

A bit of perspective from what I've seen:

• VT sessions are kept around a LOT. The scale of many binaries makes it generally impractical to use VT as a one-and-done tool without a whole lot of trust in the tool.
• The ability to add new VT matchers makes it a lot more powerful in some ways than BSim. There's a LOT of research out there about binary similarity techniques, and I'd love more of those to get easily rolled into Ghidra. Doing so as VT matchers seems like the lowest hanging fruit most of the time.
  • This being said, I want to easily see these results in Ghidra's main interface(s) without having to live in VT all the time (as I've been known to resort to doing sometimes).

Maybe what I'm getting towards with these VT observations is that I'd like to see VT be much less transient than it is. I don't have a great understanding of what exactly the complication of "the trappings of long-term database management of VT sessions" is. Naively, it seems like a simple database of matches isn't too complicated, mostly just needing invaliding / refreshing when function boundaries change (especially if it's just the match and addresses stored in the db, leaving it to the caching layer to go ask the source binary what the function name / type is... though that could probably also be stored/invalidated). It seems to me like this is probably a separate discussion / idea, probably worthy of it's own thread. The relevance to this feature is just that we should perhaps try to keep the data-source somewhat modular to support future improvements.

About your BSim comments; would it be more clunky and fiddly than using BSim currently? At the moment I believe you have to configure a BSim server, but that's not too painful. Couldn't we use that same server config? Yes, we'd need a few thresholding settings, but those could probably have defaults and doesn't seem too clunky.

I'm personally not interested in auto applying matches. I do think this would add more clunkiness / complication.

Aside about why I don't like applying matches.

I like to keep the program database as cleanly "analyst verified" as possible. The match database (BSim, VT, others, and ideally a combo of all the proceeding) should be the sole source of "fuzzy truth". A big problem with auto-applying is that errors propagate By the time you're matching from binary # 10 to binary # 11, your much more likely to have drifted away from the function that was originally named whatever name you're propagating. Any mistake anywhere along the propagation chain now compounds. If i easily see matches in the interface, there's no reason to propagate unvalidated matches except if I want even fuzzier matches in later binaries. For the latter use case, eventually, another match source (probably outside of BSim/VT) could traverse back across multiple levels of unapplied matches to get a possible match containing a name.

Anyways... to focus again...

I'm heartened by the fact that you say "The last part, showing the BSim info in the Listing would probably be the easy part of this.". This is the part I most want. What more configuration would we need besides the existing BSim configuration, and a minimum similarly threshold and a minimum confidence threshold?

[dragonmacher]

You have presented a different way of thinking about VT than what we had when we built it. If I understand you correctly, you area really using VT to provide a basic matching tool. Further, and what I think the point of this discussion is, what's missing from the current VT is a way to then take those matches and use them as a reference while reversing a binary outside of VT.

I don't have a great understanding of what exactly the complication of "the trappings of long-term database management of VT sessions" is. Naively, it seems like a simple database of matches isn't too complicated,

The way I have always thought of VT is that it is a database of matches based on a snapshot of 2 programs at a given point in time. Once one or both of those programs change substantially, then the work done in the VT session quickly can become stale. It is the problem of keeping the session in sync with the source and destination programs that seemed like too much trouble when we made VT. You have suggested a simpler way of using VT that I had not considered, which is more about matching than it is about a one time transfer of Ghidra data. It seems to me that you can also think of VT a similarity data generator. As you suggested, that data can be as simple as a link between 2 different functions, perhaps with some scoring. Having a way to produce and use that data in the Code Browser seems like it would be super useful.

The ability to add new VT matchers makes it a lot more powerful in some ways than BSim

This makes sense to me in the context above. VT can be thought of as a similarity generator with many different ways of producing matches.

About your BSim comments; would it be more clunky and fiddly than using BSim currently?

The devil is in the details, so it is hard to say just how clunky the user experience would be. We would have to deal with how to connect to the server, how to query the server and how to display results, all in a reasonable time. The lookup delay of this approach would probably require asynchronous programming, which would add some complexity.

The approach of applying data would fix the speed issue and some of the complexity, I think. But, I believe I now understand that you do not want to markup the binary with potentially slightly off / fuzzy data. Rather, you are looking for visual clues as your are reviewing the binary.

I'm heartened by the fact that you say "The last part, showing the BSim info in the Listing would probably be the easy part of this.". This is the part I most want. What more configuration would we need besides the existing BSim configuration, and a minimum similarly threshold and a minimum confidence threshold?

Again, I really have no idea of what more would be required, but I have enough experience to know that it scares me a bit. I'm personally a big fan of improving workflows and, when possible, creating novel workflows that increase reverser productivity. The allure of this discussion is that it has the potential to change the reversing experience, at least for advanced reversers. That being said, my gut tells me that the changes needed to make something good are non-trivial and would likely require a handful of devs working for a few months to get something like this done. I'd love to hear from the community to gauge interest and to learn more about VT / BSim workflows.