__thiscall using stack and/or register for its pointer

[Wall-AF]

I have a 32-bit Windows PE DLL that has classes (recoverable by running RecoverClassesFromRTTIScript) where some calls place the this on the stack whilst others use a register (ECX). Is there some way to modify the __thiscall prototype to enable that pattern?

Adding an alternate prototype wouldn't help initially as the RecoverClassesFromRTTIScript will only use __thiscall!

[ghidra007]

@Wall-AF It is possible that the script is incorrectly applying the _thiscall prototype in the case where you are seeing it on the stack. Can you check to see what was there on freshly analyzed binary and verify that you are seeing the same behavior? Is this the same binary as in the ticket where you made changes to the program before the script ran?

[Wall-AF]

@ghidra007 I can confirm this occurs on a fresh binary. Also, on this paticular one. it is identiftying a constructor of sorts as a destructor (I know this because its body calls the Windows API InitializeCriticalSectionAndSpinCount), i.e.:

instead of

The binary was built around 2015 - if I can trust the install process!

[ghidra007]

@Wall-AF I think you might have put the same image twice. I am not noticing differences between them. Both show using ECX as the this.

[Wall-AF]

@ghidra007 the difference is a ~!

[ghidra007]

@Wall-AF right but both have the this as ECX. So can be the standard thiscall.

[Wall-AF]

@ghidra007 the __thiscall definition is using the register ECX from the .cspec file Ghidra is using for this import. How do I determine which .cspec file?

[ghidra007]

@Wall-AF You can look here: ghidra_\Ghidra\Processors\x86\data\languages and you will see various .cspec files. Depending on your specific use case you should be able to identify which one using the name, for example, there is a x86-64-win.cspec for 64-bit Windows.

[Wall-AF]

@ghidra007 I think I asked the wrong question! What I meant was maybe a feature request for the .cspecfile to be added to the "info page".

[ghidra007]

Do you mean when you do a Help->About Program you want to see the .cspec file listed there?

[Wall-AF]

Yep.

[Wall-AF]

@ghidra007 Aha, it's Microsoft! Some member functions are forced to use __stdcall!
So, in your RecoverClassesFromRTTIScript (or the appropriate sub-script) maybe, in your work to convert it into an analiser, the vfunctions could have that attriibute together with their names?

[Wall-AF]

@ghidra007 just a thought, could you implement a parser that could take the header files for different versions of the compilers (in this case, Micosoft's C++/VS) to allow method names etc to be picked up from them?

[ghidra007]

@Wall-AF For the first thing I'll take a look to see how feasible it would be to figure out this use case. It's possible the script is making bad assumptions here and changing the function signature. Have you looked at the function signature for the stdcall function before the script is run? Does the script change it or does something already assume it is thiscall before the script runs?

For the second, if I am understanding what you are asking for, if it wasn't c++ you could use the C parser to parse header files for the specific versions you are interested in and import the resulting function definitions into a new archive in the data type manager. You could then disable the analyzer that is taking function definition information from the existing parsed header files when you run initial analysis. Then you could run the apply function definitions action in the data type manager which will update the function signatures for functions with matching names as those definitions. This would get the function defintions from that specific version instead of the versions we include.

[Wall-AF]

@ghidra007 I was thinking that if the analyser (or the RE) could determine the compiler and roughly the version then, providing some source could be located, your script could then parse that to find all these things out. The sources I've found have things like the calling convention, class definitions, some parameter names, etc.. (Obviously you'll need a comprehensive C++ parser (in itself an awkward job) to pull this off!)

Not sure how the current C Parser could be used as a lot of this iss C++ related.

[ghidra007]

@Wall-AF All of that is beyond the scope of the RTTI script.

[Wall-AF]

Shame, thought it might be a good place even though it is complex!

[Wall-AF]

It seems that lots of these vtable entries use a macro STDMETHODCALLTYPE which is defined as __stdcall for x86 32-bit!

[ghidra007]

@Wall-AF It looks like the script is making them all thiscalls when processing them. I will add an update to not do this but it will probably not make the next version. To see if this helps you, you can Edit (via file system not the script manager since you can't edit Ghidra built in scripts and save back to the same file) the RecoverClassHelper.java file that is in the <ghidra_install>/Ghidra/Features/Decompiler/ghidra_scripts/classrecovery folder. Go to line 4774 which should be makeFunctionThiscall(vfunction); and just put // in front of it to comment it out. Then save it and refresh the scripts in the script manager in Ghidra. Then run the script and see if you get better results for your vftable entries.

[Wall-AF]

Thanks. I've already done something similar as I've been moving on.

[ghidra007]

@Wall-AF I don't think the best solution would be to change to not make them thiscalls because not doing so makes it worse the other way for those that are supposed to be thiscalls. Since you found a solution for your issue I will go ahead and close this ticket.

[Wall-AF]

@ghidra007 not sure that's the right decision. This script (/ potential analyser) will be providing incorrect results in some cases. Maybe it could ask the user about which version of the compiler they think was used and act accordingly. It would need some kind of compiler list that could easily be added to when new ones are found.

[ghidra007]

@Wall-AF For the script, I could add an option that the user could change to either make them thiscalls or not. For the future analyzer we could either do the same or add the compiler option if we can figure out how to behave for all compilers.

[Wall-AF]

@ghidra007 Sounds like a very good plan. Thank you.