RecoverClassesFromRTTIScript with library types

[Ik0ri4n]

Hi there,

Can the RecoverClassesFromRTTIScript recover classes whose base classes are defined in libraries? I am not sure whether this is already supported in part or should be discussed as a feature request for future development.

I found a few references to potential external code in the script but as far as I know, the script cannot access library types that are defined in a different file directly. When the imported typeinfo is included as an uninitialized block, that works, kind of, but the script still cannot create the vtables because they are defined in the library file. When the typeinfo is instead referenced via an uninitialized pointer to the library, the script may even fail because the parent classes aren't recovered when trying to update classes with base class info.

[ghidra007]

No, it will not recover classes defined in external libraries. It needs the rtti information found in the program and if that information is in a different program then it can't find it. If the typeinfos you are talking about are the three main typeinfo's that are referenced by all the other class typeinfos then the script should work but it is possible you have another use-case that cannot identify them correctly. Can you clarify?

[Ik0ri4n]

I haven't had any issues when all the RTTI information was available in the program file. So far the script has been working very well in this regard. Thanks for the great work on that, by the way.

The only use-case I'm struggling with is indeed the case where code is organized across multiple library files. As all the type information is available in those library files and can be recovered there, I wondered whether it would be possible to import those into the script. Would that be worth a discussion as a feature request or something? I mainly opened this question because I didn't understand the whole script and its utility classes and thought I missed something

[astrelsky]

No, it will not recover classes defined in external libraries. It needs the rtti information found in the program and if that information is in a different program then it can't find it. If the typeinfos you are talking about are the three main typeinfo's that are referenced by all the other class typeinfos then the script should work but it is possible you have another use-case that cannot identify them correctly. Can you clarify?

This can unfortunately be more common than you may think. I think I most commonly saw it with exception classes. I think there are some in boost but it's been a long time.

This is one of the reasons I went the route of making DB classes in my plugin and making them saveable to a data type archive.

[ghidra007]

I haven't had any issues when all the RTTI information was available in the program file. So far the script has been working very well in this regard. Thanks for the great work on that, by the way.

The only use-case I'm struggling with is indeed the case where code is organized across multiple library files. As all the type information is available in those library files and can be recovered there, I wondered whether it would be possible to import those into the script. Would that be worth a discussion as a feature request or something? I mainly opened this question because I didn't understand the whole script and its utility classes and thought I missed something

I'm glad to hear the script is working well when all rtti is in the program. For the case where some is in an external library, are you looking to just see the information from the other program or do you want it integrated into the decompiler results and such? Have you tried importing the library and running the script on it? Do you think having external links from the main program to the library vtables and typeinfos would give you the information you need?

[Ik0ri4n]

For the case where some is in an external library, are you looking to just see the information from the other program or do you want it integrated into the decompiler results and such? Have you tried importing the library and running the script on it? Do you think having external links from the main program to the library vtables and typeinfos would give you the information you need?

Ideally, I'd want rtti information from library files imported or referenced in some way that enables further analysis in the main program. I have tried importing the library and recovering types there. That works well as a basis. If I could somehow reference the results in the main program and import them into the script I imagine it would enable analysis of class hierarchies spread across multiple program/library files.

[Ik0ri4n]

Now, I am not completely sure how that could be done. Of course, importing base types via type archives or something or adding missing external links for typeinfos and such would help as well. But I guess the script would need more information than that, wouldn't it?

[ghidra007]

Now, I am not completely sure how that could be done. Of course, importing base types via type archives or something or adding missing external links for typeinfos and such would help as well. But I guess the script would need more information than that, wouldn't it?

For the case where some is in an external library, are you looking to just see the information from the other program or do you want it integrated into the decompiler results and such? Have you tried importing the library and running the script on it? Do you think having external links from the main program to the library vtables and typeinfos would give you the information you need?

Ideally, I'd want rtti information from library files imported or referenced in some way that enables further analysis in the main program. I have tried importing the library and recovering types there. That works well as a basis. If I could somehow reference the results in the main program and import them into the script I imagine it would enable analysis of class hierarchies spread across multiple program/library files.

Can you give me a bit more of an idea about which analysis you want furthered?
Are you mostly interested in it getting the class structures correct in the data type manager or to be able to see the actual typeinfo/vtable contents? There are external references that can be added that would allow you to navigate to the external program. There are also project/file data type archives that could be created so that you could share data types between the programs. What else besides these are currently missing in this use-case?

[Ik0ri4n]

I am interested in recovering the class structures as if the rtti information was available in the file. In the case where it is simply spread over several files I think that would be very useful. And I think, it would be a common use-case with larger projects.

For larger projects, it is especially useful to have those class types when they are used as interfaces, for example for inter-process communication, web services and such.

[ghidra007]

I think in this case the best way to proceed would be to make a shared project data type archive in the libraries that you import into Ghidra and analyze with the rtti script. You could copy the missing class structures into that shared archive and that archive would show up in all other programs in your project. Then you can apply the correct data types where needed. I would be curious to know if you tried this manually on one or two cases how it goes and if there are any issues.

[astrelsky]

I think in this case the best way to proceed would be to make a shared project data type archive in the libraries that you import into Ghidra and analyze with the rtti script. You could copy the missing class structures into that shared archive and that archive would show up in all other programs in your project. Then you can apply the correct data types where needed. I would be curious to know if you tried this manually on one or two cases how it goes and if there are any issues.

The vtables are in the shared libraries too so all the offsets and stuff are missing.

[ghidra007]

I think in this case the best way to proceed would be to make a shared project data type archive in the libraries that you import into Ghidra and analyze with the rtti script. You could copy the missing class structures into that shared archive and that archive would show up in all other programs in your project. Then you can apply the correct data types where needed. I would be curious to know if you tried this manually on one or two cases how it goes and if there are any issues.

The vtables are in the shared libraries too so all the offsets and stuff are missing.

True. So maybe the best way is to have users import and associate and analyze the external libraries then have the script try to link up and follow the external ones when processing.

[astrelsky]

I think in this case the best way to proceed would be to make a shared project data type archive in the libraries that you import into Ghidra and analyze with the rtti script. You could copy the missing class structures into that shared archive and that archive would show up in all other programs in your project. Then you can apply the correct data types where needed. I would be curious to know if you tried this manually on one or two cases how it goes and if there are any issues.

The vtables are in the shared libraries too so all the offsets and stuff are missing.

True. So maybe the best way is to have users import and associate and analyze the external libraries then have the script try to link up and follow the external ones when processing.

It makes more sense to me to store the information in something like a fidb or datatype archive. The only variations you would see would be per compiler and per library version, just like types and function instruction hash things. You can determine what functions are what just from the rtti information and the function pointers in the tables.