Describe the bug
When analyzing object-oriented programs, it would be helpful to be able to draw on the strength of Ghidra as well as Pharos + Kaiju. Unfortunately, the same does not work fully so far, because the rules used by Ghidra itself are different from those used when importing analyses with Kaiju. Here, an adaptation to the new Ghidra standard should definitely be made.
To Reproduce
Use a simple program with a medium to large inheritance hierarchy. It is important that there is a lot of RTTI data. Can't provide an example on the fly unfortunately, so I'll try to describe it as best as I can. If I find time, I will post it.
In the first step, run the new RecoverClassesFromRTTIScript.java script provided with Ghidra. This will automatically create many classes, name functions, etc.
Then analyze the binary file with Ghidra. The default settings are sufficient.
Now try to import the file into Ghidra. Because the Ghidra own script RecoverClassesFromRTTIScript.java was already executed before, this can lead to some problems:
For example Ghidra marks class data in a separate struct with the name ClassName_data. This is not done by kaiju. The existing class is rebuilt by kaiju and the encapsulated data is discarded. Here it would be to continue using the structures already created by Ghidra. By the way, this also applies to function names and so on.
Expected behavior
The above described applies generally to the creation or adaptation of existing classes. My suggestion here would be to follow the conventions that the script RecoverClassesFromRTTIScript.java adheres to. This would also have the charm that one could use other scripts provided by Ghidra such as ApplyClassFunctionDefinitionUpdatesScript.java and ApplyClassFunctionSignatureUpdatesScript.java in the further analysis.
Then one could proceed in the future as follows:
- RecoverClassesFromRTTIScript.java
- pharos
- kaiju
- manual post analysis