Ghidra: Allow merging multiple datatypes together

Created on 13 Nov 2020 · 5Comments · Source: NationalSecurityAgency/ghidra

Is your feature request related to a problem? Please describe.
Often times, over the course of reversing structures, it's common to have multiple structures that can you find out are the same structure. This is also common if the Demangler accidentally creates a different symbol. There's no way to "alias" one data type to the other, as far as I know, or say "Replace all References with".

In my current codebase, this has happened because I have a Demangler/Foo type that is used sometimes, and a Foo type that is used other times. Choosing the right type is difficult, and I cannot delete one of the types without all usage going to "undefined".

Describe the solution you'd like
Be able to somehow say, "Replace all References To Type A with Type B".

Describe alternatives you've considered
The best I can come up with is to make one a field of the other, but this doesn't work well for function calls, and tends to confuse the decompiler, and it still makes it difficult to choose the correct, disambiguated type in any sort of Data Type chooser.

Data Types Enhancement

Source

magcius

Most helpful comment

Dragging seems to be reversed -- you drag onto the structure you want to replace, but it also moves the source into the folder of the thing you're replacing, so you have to drag it back out of the folder afterwards. I at least have a way to do what I want, but dragging is still very awkward if you have a large number of data types, as you have to sit there and wait for the list to slowly scroll. Keeping the bug open as a request to polish this.

magcius on 13 Nov 2020

👍3

All 5 comments

In the data type manager window you can drag one type onto another and it will prompt you to confirm if you wish to replace the type. It will replace all instances of the d one with the new one.

astrelsky on 13 Nov 2020

Oh my, that is a really awkward interface especially if the data types are folders apart, but it totally worked!

magcius on 13 Nov 2020

👍3

Dragging also doesn't work in all cases. If I have:

+ NamespaceA
  + Object
  + NamespaceA_Object
+ NamespaceB
  + Object

And I try to replace Object with NamespaceA_Object so I can have a cleaner, less ambiguous name, __thiscall-marked functions will Object will seemingly randomly pick another thing with the Object name. I'm guessing this stems from __thiscall matching heuristics, but it is annoying...

This also seems to be permanent. Even with undos and renames, I can't seem to get the __thiscall-marked methods back to their old objects.

magcius on 21 Nov 2020

Dragging also doesn't work in all cases. If I have:
+ NamespaceA
  + Object
  + NamespaceA_Object
+ NamespaceB
  + Object
And I try to replace Object with NamespaceA_Object so I can have a cleaner, less ambiguous name, __thiscall-marked functions will Object will seemingly randomly pick another thing with the Object name. I'm guessing this stems from __thiscall matching heuristics, but it is annoying...

This also seems to be permanent. Even with undos and renames, I can't seem to get the __thiscall-marked methods back to their old objects.

It isn't related to to the drag n drop it is due to how the datatype is determined by VariableUtilities.findOrCreateClassStruct. As highlighted in #1210 this occurs on its own and isn't very obvious to spot but is still a problem. At least it isn't as bad as how ghidra magically decides that a union's method's this parameter is a struct *

astrelsky on 22 Nov 2020

Was this page helpful?

0 / 5 - 0 ratings