use of OOAnalyzer result in Ghidra

[wothke]

I am trying to recover a C++ based library (its respective source has been lost) from a small Win32 executable. This is the first time I am using the respective tools so there are probably many point that I don't know how to do properly yet. By manual inspection in Ghidra I already had a rough idea that the respective code is probably located in the 0x407000 to 0x40fffff address range.

I then ran the ooanalyzer and imported its json output via the Kaiju plugin into Ghidra. It seems that ooanalyzer indeed detected classes which include functions that I had manually identified to be part of the library functionality. I am not familiar with the low level memory representation of respective C++ classes/objects and my below questions might be due to that lack of understanding:

1. example: ooanalyzer reports a class "cls_0x407db0" and it also reports 6 methods that this class supposedly has. The address of the first of these methods "meth_0x407db0" seems to coincide with the address used to name the class. Does this "same address" imply anything special regarding role that this "first" function plays in the class, or is is just coincidentially the first detected method?

2. In the above example fewer methods were reported than I would have expected, e.g. the last reported method was "meth_0x409350" and that method is called from the first detected "meth_0x407db0". However that first "meth_0x407db0" also calls "FUN_00409370" which gets the same type "cls_0x407db0 *" this-pointer as its first argument but which has NOT been detected to be another method of "cls_0x407db0". This seems suspicious to me, given that the function is even located in memory right after the last deteced method, I would suspect that it too should be a method of the "cls_407db0" class. Is it to be expected that certain methods might not be detected (maybe due to be using a low 30-sec-per-function detection timeout? ) - or are there other ooanalyzer settings that I should use to get a "more complete" result (is there no in-memory function-table representation that would allow to derive a complete list of a class's methods?)?

3. Most of the code in my example executable probably is boilerplate Windows MFC stuff that I am not interested in at all. I imagine that the library parts that I am interested in might be limited to a certain continuous area of the executable (my manual code inspection seems to support that theory but I am not sure if there might be execeptions where code could get spread around during linking/optimizing..). Is there a way to target the ooanalyzer to a specific subset of the excutable? (In my example code I found a table that looks like entry points to the respective library that I am interested in and it might ease/speed up the analysis if I could specifically supply those entry points for the analysis - is there a feature that allows me to do that?)

[sei-eschwartz]

1. example: ooanalyzer reports a class "cls_0x407db0" and it also reports 6 methods that this class supposedly has. The address of the first of these methods "meth_0x407db0" seems to coincide with the address used to name the class. Does this "same address" imply anything special regarding role that this "first" function plays in the class, or is is just coincidentially the first detected method?

There is some logic to identify a "representative" address for a class here. In the worst case, a class identifier can just be a method address though.

2. In the above example fewer methods were reported than I would have expected, e.g. the last reported method was "meth_0x409350" and that method is called from the first detected "meth_0x407db0". However that first "meth_0x407db0" also calls "FUN_00409370" which gets the same type "cls_0x407db0 *" this-pointer as its first argument but which has NOT been detected to be another method of "cls_0x407db0". This seems suspicious to me, given that the function is even located in memory right after the last deteced method, I would suspect that it too should be a method of the "cls_407db0" class. Is it to be expected that certain methods might not be detected (maybe due to be using a low 30-sec-per-function detection timeout? ) - or are there other ooanalyzer settings that I should use to get a "more complete" result (is there no in-memory function-table representation that would allow to derive a complete list of a class's methods?)?

It sounds like 0x409370 was (incorrectly) not detected to be a method at all. This can be caused by a variety of things. The best advice is probably to look at the log when generating the .facts and .serialize files. You can also see the instructions here. If you can't find anything obvious, we can look into it more. It could be a bug.

There is generally no simple list of methods. If the method is virtual, it will be present in a virtual function table which we can find.

3. Most of the code in my example executable probably is boilerplate Windows MFC stuff that I am not interested in at all. I imagine that the library parts that I am interested in might be limited to a certain continuous area of the executable (my manual code inspection seems to support that theory but I am not sure if there might be execeptions where code could get spread around during linking/optimizing..). Is there a way to target the ooanalyzer to a specific subset of the excutable? (In my example code I found a table that looks like entry points to the respective library that I am interested in and it might ease/speed up the analysis if I could specifically supply those entry points for the analysis - is there a feature that allows me to do that?)

In general, it's best if you can run the analysis on everything. @sei-ccohen might have some advice here.

[cfcohen]

You wrote:

However that first "meth_0x407db0" also calls "FUN_00409370" which gets the same type "cls_0x407db0 *" this-pointer as its first argument but which has NOT been detected to be another method of "cls_0x407db0". This seems suspicious to me, given that the function is even located in memory right after the last deteced method, I would suspect that it too should be a method of the "cls_407db0" class. Is it to be expected that certain methods might not be detected (maybe due to be using a low 30-sec-per-function detection timeout? )

One way you can understand what went wrong here is to look in the facts file for callingConvention lines for that function. If there are lines in addition to the one containing "__thiscall", that's ok. But if if there's no "__thiscall" line, it means that OOAnalyzer explicitly decided that function was not of the correct calling convention to be a method.

That in turn can be caused by several factors, either correctly detected by OOAnlayzer or not, such as which registers are used for parameters, and whether the stack is caller or callee restored. A known "bug" in OOAnalyzer in that regard is that OO methods using the varargs (e.g. printf) calling convention are not detected correctly, and OOAnalyzer will incorrectly say that those functions are not OO methods, when in the source they are.

Most of the code in my example executable probably is boilerplate Windows MFC stuff that I am not interested in at all.

Yes, identifying which parts of the OO-program are "interesting" and which parts are not is a significant problem, and unfortunately not one that we've found an easy solution for. I think you're on the right track with the contiguous memory thing. It has been my experience that the compiler usually links library functions into contiguous memory after the main program. So if you can keep track of a couple of addresses (main code before here, library code after here) you might be able to divide the program up that way.

As for OOAnalyzer and its analysis you absolutely want to analyze everything. OOAnalyzer relies heavily on propagating known facts about one class to another, and more data is always better for getting correct information for the classes that you actually care about.

[wothke]

Thanks for the feedback everyone :-) I like the tool but my HW is probably underpowered..

As for OOAnalyzer and its analysis you absolutely want to analyze everything.

Admittedly I lack the background regarding the tradeoffs involved with regard to the scope of the ooanalysis. But my very limited user experience is this (I am using a Win10 PC with only 32GB RAM and an older generation 4-core i7-3770 CPU; I run the ooanalyzer via Ubuntu in a VirtualBox - I don't know how much of the 4-CPUs/24GB RAM that I allocated to the respective VirtualBox VM actually are made available to the analyzer process); For the example 300kB Win32 executable the ooanalysis on my machiche quite quickly reaches the 75% completion mark but from there on basically all the additional function-analysis steps abort with a timeout (I first used a 1min/per-function timeout that I reduced to 30secs on my 2nd attempt since the VM completly crashed after hours in the 1st try). I'd guess that the result that I got after 100% completion might be identical to the one I would have gotten at the 75% mark. However I had to wait ~2 additional hours (that's when I went to sleep to come back in the morning) for those additional 25% to complete (aka timeout) which probably provided no added-value whatsoever to the analysis result (quite possibly some of the method detection failures were due to respective timeouts..). I'd be in favor of any measures that allow to focus the analysis on the code that I am actually interested in and to thereby not only have a quicker but also a potentially more thorough analysis of the parts that I care about.

PS: I guess that my "Linux in VirtualBox" setup is a major reason for my slow execution time: It seems that the maximum CPU load (see Win10 taskmanager) that my VirtualBox/Linux VM can actually achieve running "stress" is about 44% (i.e. VirtualBox is obviously throttling) And the highest CPU load that ooanalyzer will actually trigger is about 16% (the program is probably more memory bandwidth than CPU bound..)

I guess I'll have to install a separate linux boot partition :-(