Vector35
MSVC RTTI analysis
There is a plugin for it named MSVC that hasn't been updated since 2019. I believe this feature should be in the core.
I have created a plugin recently that symbolizes and parses msvc rtti information, it can be found here: https://github.com/emesare/binja-msvc. It is missing quite a few QoL features like a UI however the parsing and symbolizing is pretty much finished.
If msvc rtti analysis were to be included in the core I figure that some compromises would need to be made in terms of how "ownership" of a virtual function is dealt with, specifically when it comes to shared virtual functions.
edit: Also I had to use llvm's demangler instead of builtin ms_demangler due to builtin demangler failing to demangle, I think this is the relevant issue: #1653
There is a preliminary branch with MSVC RTTI analysis in the PE view. However it will cause the debug info (PDB's) to reference bare virtual function tables (if loader.pe.processRttiVtables is enabled), this is of course, undesirable. We really need workflows (specifically module level workflows) to solve this gracefully. Otherwise reanalysis will need to be triggered (this is a side effect of the debug info) which for larger binaries is not an option.
https://github.com/Vector35/binaryninja-api/tree/test_pe_rtti
Another solution would be to avoid naming types the same as the PDB, however this will lead to a lot of duplicate types which a user might confusingly choose over the more accurate and rich PDB types. We could also modify the PDB plugin to actually wipe the type, I think this would require only minimal changes however it could be that that behavior is relied on internally.
The current working MSVC RTTI analysis is being done as apart of https://github.com/emesare/binja-msvc/tree/test-2.0, this could be moved into the core, or kept as a separate plugin, pending further discussion.