Missing USER32.dll:wsprintfW from API database

[janbbeck]

Using the same file and methodology as #153
I get

APID[TRACE]: API Lookup: USER32:wsprintfW
APID[WHERE]: SQLite API database /usr/local/share/pharos/apidb/pharos-apidb.sqlite could not find function wsprintfW in USER32
APID[WHERE]: Decorated name parser has no data for DLL: USER32
APID[WARN ]: API database could not find function wsprintfW in USER32
OOAN[WARN ]: No stack delta information for: USER32.dll:wsprintfW

There is information for USER32.DLL, but the information for the wsprintfw call seems missing. I did just open that DLL and it does in fact export that function.

[sei-gwassermann]

I'll look into it.

[sei-eschwartz]

@sei-gwassermann Any news on this?

[YamamotoKaderate]

I suppose the problem is global to all variadic functions. I have the same problem with wsprintfA in USER32.DLL

[sei-gwassermann]

@YamamotoKaderate thanks for checking in! Apologies for such a delay here. Our API database supports variadic functions but we had some initial trouble with properly documenting functions this way. The upshot is that we should be able to fix this, I was looking into this a while back but unfortunately didn't quite finish the work. Hoping to get it out very soon!

[YamamotoKaderate]

Thank you. So, if API database support variadic functions, is it possible to describe them in an additional handmade apidb json?

[sei-gwassermann]

Yes @YamamotoKaderate it is possible to include custom apidb json to avoid any error messages. Update the additions file (see https://github.com/cmu-sei/pharos/blob/master/share/apidb/pharos-api-additions.json for an example of format) with whatever functions you want to add.

Reviewing, it appears that this method does not actually allow for marking variadic functions; that is only supported internally. I'm making a note to extend that feature to the custom user json too in a future release!

While this would help silence errors, the analysis may or may not be able to handle the variadic case correctly though either. So at the moment, I think adding variadic functions to user-written json would mostly only be useful about suppressing warnings and wouldn't add much to the analysis at this time. Thanks for alerting us though, something to look at for a future release!

[sei-ccohen]

I should add further that the real problem here is that the Pharos function analysis doesn't really support variadic functions very well. So even if you override the API database, it won't really improve the analysis. The goal of the API database was to answer a few important questions about functions that were outside the Pharos analysis because the functions aren't actually in memory for analysis. Specifically, the API database records the total stack delta for the function, what was the calling convention, and some type information that can be used for OO analysis if the symbol was a C++ mangled name.

By far the most important of these values was the "total stack delta". This value is critically important in 32-bit Windows program analysis because many operating system APIs are "callee cleanup" meaning that the stack would not be adjusted properly without knowing how many parameter bytes were pushed onto the stack by the caller. This is not easily determined by analyzing the calling function (it looks easy, but it's not). And without the correct stack delta, all subsequent stack analysis would be incorrect. That would be BAD!

Fortunately, in the case of variadic functions the calling convention is (of course) caller-cleanup, since only the caller knows how many bytes of parameters were pushed onto the stack. Thus, the "total stack delta" implied by the CALL instruction is zero for variadic functions meaning that there are no callee stack adjustments. A total stack delta of zero is the default assumption when there is no information in the API database. So, in some sense the right thing happens with or without the entry in the API database for variadic functions.

Regardless of what the API database says about the total stack delta, Pharos does NOT correctly handle variadic functions in the sense that it knows how many arguments were actually passed dynamically. In practice variadic parameters are treated as if the didn't exist or weren't passed. We've thought about writing an analysis in that would try to figure this out, but it's complicated, and it's never seemed quite worth the trouble.

I hope that helps clear up some of the "analysis" details.