Does Ghidra's type system directly support inheritance, polymorphism, and/or multiple inheritance?

[RolfRolles]

I'm conducting a comparative analysis of IDA vs. Ghidra for C++ reverse engineering. I want the comparison to be fair, and not marred by my own ignorance of Ghidra. Hence, I have a few questions to ensure I haven't overlooked anything.

Roughly speaking, if I have a C++ class with a few data items and virtual functions, e.g.:

class Base { 
  int b;
  virtual int f_b();
};

It's easy to create a structure for Base's VTable (containing one function pointer), and for Base itself (containing a pointer to the VTable type, as well as the integer b).

Now let's suppose I have a derived class, as follows:

class Derived : public Base { 
  int d;
  virtual int f_d();
};

One might imagine trying to "simulate" inheritance by creating a Derived structure, whose first element is an instance of the Base structure type, and including an additional integer d.

However, the problem with this is that the VTable type for Derived is not the same as the one for Base: it has two function pointers instead of one. Therefore, the type system would presumably represent the virtual function call as something like d->B.vtable[1].f_b, i.e., wrapping around the end of the B_vtbl structure. This was the case in IDA prior to 7.2.

IDA 7.2 added the ability to change the VTable type in derived classes, thus solving this issue. We could represent the situation above using these declarations:

struct Base_vtbl { int (__thiscall *f_b)(Base *); };
struct Base {
  Base_vtbl *__vftable;
  int b;
};

struct Derived_vtbl : Base_vtbl { int (__thiscall *f_d)(Derived *); };
struct Derived : Base { int d; };

As you can see, IDA 7.2+ offers true support for polymorphism in inheritance, using familiar syntax (:), and relying upon a naming convention for Derived's VTable type.

Does Ghidra support something akin to the above -- direct specification of inheritance relationships, with the ability to override VTable types in derived objects?

IDA 7.2 also added support for multiple inheritance (struct C : A, B), and the ability to override the VTable type for subobjects (struct C_0020_vtbl : B_vtbl). Another new feature was "shifted pointers", which can be used to model how the MSVC situates the this pointer for multiple inheritance.

For overridden virtual functions in B, MSVC assumes that the this pointer points to a B object within a C object. Thus, all structure offsets will be calculated relative to offsetof(B,C). I.e., fields in A require negative displacements. Fields in C have positive displacements, shifted by offsetof(B,C). Shifted pointers solve this problem. In particular, we can write B *__shifted(C,0x20) to describe an instance of a B object within a C object at offset 0x20. Having done so, IDA/Hex-Rays can resolve the negative/shifted displacements to the proper fields within C.

Does Ghidra have anything comparable for multiple inheritance?

[astrelsky]

Not yet. The type system doesn't directly support virtual multiple inheritance yet.

There is an open pull request for shifted pointers. If given the ability to have the decompiler assume a struct member is a constant value, coupled with the shifted pointers, I could make all of this work with my plugin.

[RolfRolles]

Virtual inheritance was the one form of inheritance I hadn't mentioned in my questions above. (To be clear we're using the same terminology: virtual inheritance is not the same thing as virtual functions; it refers to sharing the data from common base classes during multiple inheritance.) Although I did write a virtual inheritance plugin for Hex-Rays, I don't think it's very realistic for any reverse engineering tool's type system to support it directly, given the vastly different implementations across compilers.

Or did you mean "inheritance of virtual functions" rather than "virtual inheritance"?

[astrelsky]

I did indeed mean virtual inheritance.

For the vftable a pointer to a structure full of function definitions does a good job.

Virtual inheritance could be handled. Both the visual studio and gcc/clang implementations strip each virtual base of their virtual bases and then append them to the end of the class in order. The dynamic virtual base lookup is different as visual studio utilizes a separate _vbptr whilegcc/clang use just one _vptr. I don't think it is too absurd to support.

I have written a plugin which leverages rtti to rebuild the class structure. Most of it is hacky due to the lack of support in the type system but it does a fairly decent job. The only thing really holding it back is that the virtual base offset doesn't get resolved because there is no way to tell the decompiler the constant value being read from the vbtable even though it only needs to assume the value based on index.

[RolfRolles]

Okay. Yes, your last paragraph describes roughly how my Hex-Rays plugin for virtual inheritance worked. I'll publish it eventually; for now, here's a screenshot. (There was a similar idea underlying another plugin I wrote for virtual function resolution).

In any case, this is going adrift of my original intention, which was to get an authoritative answer from the Ghidra developers on the current status of direct type-system support for single inheritance, polymorphism, and multiple inheritance. Thank you for your comments.

[emteere]

@RolfRolles we currently don't support true inheritance as well as mixing structure definitions with class methods directly as a Class data type. They have been on the books to do for quite a while. There have been various attempts to add general support for a class mostly in the form of namespaces as Classes, and Class folders in the datatypes with various definitions for class components. These generally fall short because they are conventions and are not enforced nor do they affect things like the debugger in the correct way. In addition, conventions don't work well if you are trying to RE something where you are recovering the hierarchy where methods signatures will be edited, new class relation ships discovered. Cross references would also need to be addressed. There have been many folks using Ghidra to recover RTTI type information and apply them. There is a script we will be including soon that creates classes probably very similarly to what is described above. However it will suffer from really a static view of the classes.

There is a fairly big refactor of the datatype model to support this sort of thing, among others, that has also been on the books for quite a while. The re-design was scheduled to start last April. That said, we are hoping to get some support in 9.3 and 9.4.

One necessary change "shifted pointers" in a pull request for shifted pointers that we have looked. Support for pointers declared as pointing to an offset into a larger structure will be necessary. The idea is a good idea but we need to study how it would fit with the other changes we are designing. The biggest issue is a database refactor to support this type of change and others in a general fashion, which is really all I can say at this point on support for shifted pointers.

Function signatures as first class type objects handled as structures are an issue. Meaning function signatures exist as a definition in the type system and as an entry in the data type manager and both reflect the same information.

This isn't as satisfying an answer as I'd like to provide. We've had many of these ideas for quite a while, however some of the features we currently support with the data type archives, merging, version tracking, program diffing, and general database extensions require a careful design to support. Expect to see some type model changes towards this end in the near future.

[0xBEEEF]

Currently, I am also failing precisely because of the above-mentioned problems. The creation of classes + simple inheritance works quite smoothly with the release of the new version. But now I fail in various places with the virtual inheritance. Here in particular with shifted this pointers, no matter if positive or negative. So far these still pose a few problems. Is it already foreseeable when we can expect a general and better solution here? The topic of OOP is a bit more fun since version 10, but unfortunately it is still not really satisfying. Here we urgently need better solutions.

[AAH20]

would like to know more about your results with this