I like extracting data from many samples because this way I often discover new things. Combing through a set of manifest files I have extracted from a large sampleset of good samples was an interesting exercise and brought a few interesting findings.
Manifest files I came across were saved as plain text, Unicode 16 LE, and utf8. Some were malformed, some used incorrect data, others included commented out manifest sections and sometimes the commented out parts would use HTML entities to represent opening and closing brackets. Quotation marks vs. apostrophes, boilerplate values (e.g. name = “CompanyName.ProductName.YourApplication”, name = “YourCompanyName.YourDivision.YourApp”, etc.), and typos (e.g. “schema-microsoft-com:asm.v3”, or “urn:schemas-microsoft.com:asm.v3”).
I tried to see if I can find any publicKeyToken outliers — these are often used to reference a specific library version – the most popular being comctl32.dll v6.0 enabling visual styles back in the days when it still mattered (publicKeyToken=”6595b64144ccf1df”).
Quick histogram of publicKeyToken values shows a small number of unique values, some of which are kinda questionable (e.g. empty, zeroed, or using a reference):
Another target of these analysis were URIs. These constantly pop up during memdump analysis and knowing a list of clean ones can save us some time. Here’s a list I extracted (including these prefixed with ‘urn’):
Finally, attributes (note, some may only exist within comments, that is, between <!–…-> not the actual manifest XML):
name iid version clsid progid hash description proxyStubClsid32 tlbid Id numMethods publicKeyToken task message language value xmlns processorArchitecture uiAccess level type class file standalone inType encoding mask flags manifestVersion threadingModel keywords size chid runtimeVersion guid xmlns:asmv3 company optional outType helpdir xmlns:co.v2 copyright allowDelayedBinding opcode xmlns:asmv2 length xmlns:ms_asmv3 buildType hashalg parameters xmlns:adlcp xsi:schemaLocation xmlns:cmp culture xmlns:ms_asmv1 profile xmlns:ms_windowsSettings xmlns:xsi baseInterface majorVersion face xmlns:xsd miscStatusContent resourceFileName xmlns:asmv1 isolation dependencyType servicePackMajor xmlns:co.v1 channel xmlns:lom assemblyname xmlns:ms_asmv2 messageFileName xmlns:ms_compatibility template xmlns:mssv2 minorVersion miscStatus enabled asmv2:product product
And last, but not least… this classic paper [PDF warning] from 2006 on manifest file abuse was yet another reason I looked at manifest files en masse. I speculated that maybe, maybe, maybe, maybe there are some signed executables that take advantage of manifest’ file tag as described in the document:
and inadvertently may become a vehicle for a ‘by design’ manifest-based DLL side-loading. The scenario would play like this: you run a signed executable that uses a manifest leveraging the file tag and you provide it the malicious DLL named as the manifest expects and place it in a current directory. Should work?
After grepping the manifest files for <file tag I found quite a few of them. So many that I can’t paste it here. But you can view them here.
