Microsoft Name Demangler does not handle memberfn thisptr or return-via-pointer

[Kharos102]

Binary Ninja Version: 3.1.3524-dev Personal, f927c3fa
Platform: Windows 10 Version 2009

Hi,

When analysing the file "C:\windows\system32\wevtsvc.dll" without a PDB, we get an accurate count of the parameters for the "GetLogObj" function, see the three args:

However once we load the public PDB for this, we lose two arguments and instead see R8 being used instead of arg3 (function prototype gets corrupted):

[CouleeApps]

This is less of a bug in the PDB Parser and more of a limitation in the public PDBs available for wevtsvc. Looking at the PDB using microsoft's tools, the symbols do not have parameter information beyond a mangled name, which demangles correctly to what you see in your screenshot:

PublicSymbol: [000AC69C][0001:000AB69C] ?GetLogObj@EventService@@AEAA?AV?$AutoRef@VLog@@@wmi@@PEB_W@Z(private: class wmi::AutoRef<class Log> __cdecl EventService::GetLogObj(wchar_t const * __ptr64) __ptr64)
PublicSymbol: [000AD014][0001:000AC014] ?OpenExternalLog@EventService@@AEAA?AV?$AutoRef@VLog@@@wmi@@PEB_W@Z(private: class wmi::AutoRef<class Log> __cdecl EventService::OpenExternalLog(wchar_t const * __ptr64) __ptr64)
PublicSymbol: [000ACD1C][0001:000ABD1C] ?OpenExternalLegacyLog@EventService@@AEAA?AV?$AutoRef@VLog@@@wmi@@PEB_W@Z(private: class wmi::AutoRef<class Log> __cdecl EventService::OpenExternalLegacyLog(wchar_t const * __ptr64) __ptr64)

Considering how these are explicitly marked cdecl (not thiscall), I'm not even sure this is a bug. I think the analysis just guessed there were more parameters and the (mildly accurate) demangled name in the PDB corrected that down to just one. So I'm closing this unless you have reason to believe those extra parameters are correct.

[Kharos102]

So I'm a bit unsure about C++ templating stuff that's going on here, but both the following are true:

• The function takes one parameter and RDX/R8 usage in assembly here are from the first parameter in source using some c++ templating methods
• RDX/R8 are actual parameters in the assembly, but in source (as noted via the PDB) theres only one parameter with const methods that seem to be compiled to use RDX/R8 here

So really, RDX/R8 from the point of analyzing the assembly are parameters

[CouleeApps]

I think I see what you mean: since the return type is class wmi::AutoRef<class Log>, the x64 calling convention places a pointer to it (the returned value) in a parameter slot, therefore RDX is a correct "parameter" that the demangler (pdb plugin? i'm not sure what is responsible for making this) should have handled. I'm not sure where r8 would come from though.

[Kharos102]

This may be because the first parameter is actually a form of string_view and not a regular wchar_t* string, this may be from an incomplete PDB.

In this case then we could just follow what the PDB says or add the extra parameter based on detected usage (as we do when we analyze without any symbols)

[CouleeApps]

I'm more inclined to follow what the PDB says, just because it's a source of truth even if it's not very precise truth. I'll wire up making the return value into a pointer in the first argument slot, but I don't know how/if r8 should be handled.

[CouleeApps]

Ok actually I'm pretty sure I do know what r8 is. This looks like a member function call (private and not static), so it's likely RCX is thisptr and the rest of the parameters follow from there. This is a demangler issue.