Dependencies icon indicating copy to clipboard operation
Dependencies copied to clipboard

Crash when encountering invalid manifest

Open MarekKnapek opened this issue 5 years ago • 4 comments

Tested on Windows 7 64bit, Dependencies 64bit v1.10.0.0, inspecting MsiCofire.dll 64bit. This DLL has manifest ID 1 containing invalid XML, Dependencies crashes.

MarekKnapek avatar Jan 19 '20 05:01 MarekKnapek

DLL can be found in attachment. MsiCofire.zip

MarekKnapek avatar Jan 19 '20 05:01 MarekKnapek

I think 29b942f635195a3d0d27db67d9e03ffb58b42bd3 fix the crash you've seen.

However, this DLL which has two manifests is pretty trippy :

  • C:\Windows\System32\rundll32.exe .\MsiCofire.dll, DllMain loads C:\Windows\WinSxS\amd64_microsoft.windows.common-controls_6595b64144ccf1df_6.0.18362.592_none_e6c0b1911312be02\COMCTL32.dll
  • C:\Windows\SysWOW64\rundll32.exe .\issue115\MsiCofire.dll, DllMain does not

This is the manifests embedded :

ID1 :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    name=SXS_ASSEMBLY_NAME
    processorArchitecture=SXS_PROCESSOR_ARCHITECTURE
    version=SXS_ASSEMBLY_VERSION
    type="win32"/>
<description>Windows Corrupted File Recovery MSI reinstall dialog</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture=SXS_PROCESSOR_ARCHITECTURE
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

ID2 :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    name="Microsoft.Windows.base.MsiCofire"
    processorArchitecture="amd64"
    version="5.1.0.0"
    type="win32"/>
<description>Windows Corrupted File Recovery MSI reinstall dialog</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="amd64"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>

I'm pretty sure the Manifest ID1 is ignored, and only Manifest ID2 is used (which defines the comctl32 dependency only for amd64). If you've got some insight on how sxs manifests are parsed, you're more than welcome

In the meantime, I keep this issue opened

Lucas

lucasg avatar Feb 02 '20 17:02 lucasg

Hi Lucas,

I think your commit is too specific, you don't need to search for the exact phrases and handle them. Instead you should just fail parsing as the manifest is not valid XML.

Having multiple manifest is fine as you have only one manifest in range 1-16 (inclusive).

I think that for DLLs manifest ID 1 is always ignored, but I'm not sure.

I cannot reproduce your findings. I tested on Windows 7 64bit. Running 64bit version of rundll with 64bit version of msicofire.dll loads modern version (6.1) of comctl32.dll. And running 32bit version of rundll with 32bit version of msicofire.dll also loads modern version (6.1) of comctl32.dll. Note that I don't have 32bit version of msicofre.dll on my 64bit Windows 7 machine, I copied it from 32bit Windows 7.

How to parse SxS? I tried that and I abandoned it, I think you should do the same as Dependency Walker does. You can try to use APIMonitor tool (http://www.rohitab.com/apimonitor) to learn that Dependency Walker uses CreateActCtx, ActivateActCtx, FindActCtxSectionString functions to handle SxS. I already told you that in discussion about issue#3.

Marek

MarekKnapek avatar Feb 03 '20 14:02 MarekKnapek

I probably fixed this with the PR I have open: #150

chrdavis avatar Sep 15 '20 02:09 chrdavis