DLL Redirection Using Manifests

[Zorba the Geek]

I suppose most of you are familiar with the technique for extending the XP API for a particular program by inserting a custom system DLL in the same folder as the program and editing it's import table so that a file to which it is linked is renamed to that of the custom system DLL.  My custom DLL is xpspkernel32.dll from OneCore API 3.03 renamed to kernel32.dll along with it's dependencies ntext.dll and kernelbase.dll.  In the case of the McAfee Viruscan CLI scanner v7.02 for Windows 7 this technique cannot work because scan.exe performs an integrity check on itself, and closes with a message saying the executable has been modified.  An alternative approach that I thought I might try is to redirect API calls to the system DLL using manifests to make the local folder the top of the search order for loading the DLL

Here is the default search order for loading a DLL:

• The directory from which the application is loaded
• C:\Windows\System32
• C:\Windows\System
• C:\Windows
• The current working directory
• Directories in the system PATH environment variable
• Directories in the user PATH environment variable

Using information provided at this web page I was able to create experimental manifests to study how this can be done.  The secret appears to be using a dll-manifest and an exe-manifest that work together.  First you must run the Manifest Tool version 5.2.3790.2076 (mt.exe) which can be found in the Microsoft SDK 7.0A in Visual Studio 10 or as a separate download.  The path in Visual Studio is C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\mt.exe.  the command to be executed in the local folder containing the custom DLL is:

mt.exe -tlb:custom.dll -dll:custom.dll -out:custom.dll.manifest

In my example it would be

mt.exe -tlb:kernel32.dll -dll:kernel32.dll -out:kernel32.dll.manifest

The output has to cleaned up by adding linebreaks and indention.  Here is the finished result for kernel32.dll.manifest:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
 <file name="kernel32.dll" hashalg="SHA1">
  </file>
   </assembly>

using the example provided by Ove Halseth in the above mentioned article this is the scan.exe.manifest that I used:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="scan.exe" version="1.0.0.0" />
 <dependency>
  <dependentAssembly>
   <assemblyIdentity type="win32" name="kernel32.dll" version="5.1.2600.16384" processorArchitecture="x86"/>
  </dependentAssembly>
 </dependency>     
</assembly>

Executing scan.exe from the commandline causes it to open without error messages and then it closes, so I suppose the technique works, but scan.exe must have built in protection against DLL redirection which is a well known technique for virus writers.

Error Messages

The procedure entrypoint InitializeCriticalSectionEx could not be located in the dynamic link library KERNEL32.dll

This is the error message produced without modifications to the local folder due to kernel32.dll v5.1.2600.7682 not being able to supply the following imports:

CompareStringEx
GetLocaleInfoEx
InitializeCriticalSectionEx
LCMapStringEx

Generate Activation Context failed for F:\Internet Downloads\McAfee VirusScan CLI Scanner\cls-w32-702-l\scan.exe.Manifest. Reference error message: The operation completed successfully.

This is an entry in the eventlog caused by not entering the assemblyIdentity version of the dependency as the version of the custom DLL

The system cannot execute the specified program.

This error message results from incorrect syntax of the manifest files

Notes

• assemblyIdentity name can be anything
• assemblyIdentity version can be any four digit number separated by full stops
• assemblyIdentity name for the dependency must be the file name of the custom DLL
• assemblyIdentity version for the dependency must be the version number of the custom DLL
• The manifest files must be the name of the file they are linked to including it's ending 

Here is an article by Microsoft titled Assembly Manifests that goes into some detail of the syntax required.                                                                                                                                                                          

Edited December 14, 2024 by Zorba the Geek

[D.Draker]

12 hours ago, Zorba the Geek said:

In the case of the McAfee Viruscan CLI scanner v7.02 for Windows 7 this technique cannot work because scan.exe performs an integrity check on itself, and closes with a message saying the executable has been modified.

And what if you recalculate? Rebuild the header?

[Zorba the Geek]

18 hours ago, D.Draker said:

And what if you recalculate? Rebuild the header?

The Checksum does not appear to change from the value set in the Optional Headers section of the header, so this integrity check must be based on something else.

I have tried creating manifests to redirect API calls to the Windows kernel32.dll to the One Core API version in the local directory for mpc-hc v1.7.13.112, and the same thing happens.  The program begins to load and then it closes.

Here is the manifest named kernel32.dll.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity type="win32" name="kernel32.dll" version="6.0.6000.16386" processorArchitecture="x86"/>
 <file name="kernel32.dll" hashalg="SHA1">
  </file>
   </assembly>

Here is the manifest named mpc-hc.exe.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="mpc-hc.exe" version="1.7.13.112" />
 <dependency>
  <dependentAssembly>
   <assemblyIdentity type="win32" name="kernel32.dll" version="6.0.6000.16386" processorArchitecture="x86"/>
  </dependentAssembly>
 </dependency>     
</assembly>

 

[D.Draker]

When I modded Nvidia drivers, rebuilding with CFF was enough to pass the Windows check, without the rebuilding they simply didn't load.

Must be a more sophisticated check in your case.

[D.Draker]

Sorry to be the Cap. Obvious, I assume you did a CRC check after the modding?

[ED_Sln]

I do manifest a little differently, I have it in two parts, and the dlls that are loaded are in a separate folder. Using mpc-be as an example. The first file is called mpc-be.exe.manifest and is located next to mpc-be.exe its contents:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='share' version='1.0.0.0' processorArchitecture='x86' />
    </dependentAssembly>
  </dependency>
</assembly>

The second share.manifest is located in the "share" folder along with the dll, its contents:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <noInheritable/>
  <assemblyIdentity type="win32" name="share" version="1.0.0.0" processorArchitecture="x86" />
  <file name="advapi32.dll" />
  <file name="advapibase.dll" />
  <file name="bcrypt.dll" />
  <file name="dwmapi.dll" />
  <file name="dxva2.dll" />
  <file name="kernel32.dll" />
  <file name="kernelbase.dll" />
  <file name="ntext.dll" />
  <file name="propsys.dll" />
  <file name="shell32.dll" />
  <file name="shellbase.dll" />
  <file name="ws2_32.dll" />
  <file name="ws2_base.dll" />
  <file name="comctl32.dll" />
</assembly>

 

[ED_Sln]

But for example mpc-be as well as mpc-hc will not work this way, the problem is in user32.dll, with the file from OCA they still do not start, you have to edit dependencies through CFF Explorer.

[Andalu]

On 12/15/2024 at 9:48 AM, Zorba the Geek said:

The Checksum does not appear to change from the value set in the Optional Headers section of the header, so this integrity check must be based on something else.

I have tried creating manifests to redirect API calls to the Windows kernel32.dll to the One Core API version in the local directory for mpc-hc v1.7.13.112, and the same thing happens.  The program begins to load and then it closes.

Here is the manifest named kernel32.dll.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <assemblyIdentity type="win32" name="kernel32.dll" version="6.0.6000.16386" processorArchitecture="x86"/>
 <file name="kernel32.dll" hashalg="SHA1">
  </file>
   </assembly>

Here is the manifest named mpc-hc.exe.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity type="win32" name="mpc-hc.exe" version="1.7.13.112" />
 <dependency>
  <dependentAssembly>
   <assemblyIdentity type="win32" name="kernel32.dll" version="6.0.6000.16386" processorArchitecture="x86"/>
  </dependentAssembly>
 </dependency>     
</assembly>

I did not use the Manifest files method, but modified the files with a hex editor to allow loading of the OCA libraries v3.0.5 that I placed in the program folder.

This way MPC-HC v1.7.13.112 starts normally:

The program failed to start with the same kernel32.dll v6.0.6000.16386 reported in your previous post.

Edited December 18, 2024 by Dave-H
New content within quotation. Corrected by Admin.

[Andalu]

@Zorba the Geek

Using the two manifest files as you described, MPC-HC v1.7.13.112 does not start at all here.
The strange thing is that it starts when launched under Sandboxie.

 

Instead, with the method suggested by @ED_Sln MPC-HC v1.7.13.112 starts normally:

 

I have not had a chance to test it thoroughly, however, as can be seen in the image above, for example, the keys are not displayed correctly. Also, clicking on the 'Help' tab and then on 'About' does not display any screen. The same happens under Sandboxie. Therefore, there seems to be some problem when manifest files are used.

I would like to be able to find a way to use the manifest files also for codecs and libraries contained in the "LAVFilters" folder of MPC-HC. But I don't know if it is possible to do this.

Edited December 20, 2024 by Andalu

[ED_Sln]

7 hours ago, Andalu said:

I have not had a chance to test it thoroughly, however, as can be seen in the image above, for example, the keys are not displayed correctly. Also, clicking on the 'Help' tab and then on 'About' does not display any screen.

This is because of the file comctl32.dll, you need to try different versions, for MPC-BE I chose on the version from Server 2003 x86, with it the interface is displayed as correctly as possible, although the settings became with the classic theme. Here is this version, try to run with it. https://www.upload.ee/files/17540516/comctl32.zip.html

Control buttons is a skin, try to remove it from MPC-HC folder, then standard buttons should appear.

7 hours ago, Andalu said:

I would like to be able to find a way to use the manifest files also for codecs and libraries contained in the "LAVFilters" folder of MPC-HC.

Unfortunately you can't make separate dll and ax with manifest, you need to have an executable file.

[Andalu]

@ED_Sln

comctl32.dll v6.0.3790.16391 does its job, thank you

 

I noticed that different versions of the comctl32.dll are loaded for MPC-HC v1.7.13.112 if you use the manifest files or if you run the modified mpc-hc.exe file.

With the modified mpc-hc.exe file, the library comctl32.dll loaded is the version 6.0.2600.7660 contained in the directory

c:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.7660_x-ww_936580bb

and in this case both the control buttons and the 'Help' tab work correctly.

 

When manifest files are used, the loaded comctl32.dll library is the one contained in the C:\WINDOWS\system32 directory and in this case the control buttons are not correctly displayed and the 'Help' tab does not work.

The strange thing is that if comctl32.dll v6.0.2600.7660 is copied to the 'Share' folder (and consequently the share.manifest file is edited) the control buttons are correctly displayed while the 'Help' tab does not work.

Therefore in case of using the manifest files the fully working version of the comctl32.dll library for MPC-HC v1.7.13.112 is the one uploaded by @ED_Sln

 

P.S.: I did not use a skin other than the default one

[user57]

it is for MPC-HC ? then the question apears if it play the h.265 codec 

i do not know specific details as "CUDA" is closed source 

but if i get it right cuda makes: control input, control and output

so if the driver isnt doing that the grafic card isnt talked to 

 

it dont has to be a grafic card but, its a plain c code (both en and decoding) - the question raise how fast that actually runs

the code written with mmx-avx instructions are very fast but 

for a player only the decoder would be needed

https://openrepos.net/content/lpr/libde265-hevc-decoder

[ED_Sln]

8 hours ago, user57 said:

it is for MPC-HC ? then the question apears if it play the h.265 codec 

Software will play, but for hardware acceleration, you need to have a decoder that supports NVDEC and video card was Nvidia 700 or 900 series. I checked on GTX950, LAVFilters and MPC-BE and MPC-HC, on XP x32 h265 8bit plays, but there are artifacts, apparently the driver is such, but on XP x64 h265 8bit plays without problems. Hardware acceleration h265 10 bit is not supported by NVDEC in 700 and 900 series, appeared only in 1000, but there are no drivers for it on XP.

[Zorba the Geek]

On 12/21/2024 at 7:25 PM, Andalu said:

@ED_Sln

comctl32.dll v6.0.3790.16391 does its job, thank you

 

I noticed that different versions of the comctl32.dll are loaded for MPC-HC v1.7.13.112 if you use the manifest files or if you run the modified mpc-hc.exe file.

With the modified mpc-hc.exe file, the library comctl32.dll loaded is the version 6.0.2600.7660 contained in the directory

c:\windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.2600.7660_x-ww_936580bb

and in this case both the control buttons and the 'Help' tab work correctly.

This could be remedied by making an entry in mpc-hc.exe.manifest pointing to the correct comctl32.dll in the WinSxS folder.  I used Nirsoft's Search My Files to search for files named *.manifest for an example of how this could be done.  Here is such an entry in the file ncpa.cpl.manifest:

 <dependency>                              
  <dependentAssembly>                   
   <assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" publicKeyToken="6595b64144ccf1df" language="*" processorArchitecture="*"/>                                
  </dependentAssembly>                  
 </dependency> 

I assume that the file is searched for using it's public key token

Edited December 24, 2024 by Zorba the Geek

[Zorba the Geek]

On 12/16/2024 at 4:49 PM, ED_Sln said:

I do manifest a little differently, I have it in two parts, and the dlls that are loaded are in a separate folder. Using mpc-be as an example. The first file is called mpc-be.exe.manifest and is located next to mpc-be.exe its contents:

The second share.manifest is located in the "share" folder along with the dll, its contents:

I tried this with mpc-hc v1.7.14.x86 and to my utter amazement it actually worked!.  The Microsoft documentation does not disclose this approach, but you can read an answer to a question at Stackoverflow which does suggest this technique here.

Here is my mpc-hc.exe.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type="win32" name="share" version="1.0.0.0" processorArchitecture="x86" />
    </dependentAssembly>
  </dependency>
</assembly>

here is my share.manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">

  <assemblyIdentity type="win32" name="share" version="1.0.0.0" processorArchitecture="x86" />

  <file name="kernel32.dll" />
  <file name="kernelbase.dll" />
  <file name="ntext.dll" />  
</assembly>

It appears that the presence of an application manifest redirecting API calls to a custom version of a system DLL like kernel32.dll will override the entry for kernel32.dll in the registry key "KnownDLLs".

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs

which places System32 at the top of the search order for those DLLs listed there.  Therefore there is no need to place an entry for kernel32.dll in the registry value "ExcludeFromKnownDLLs".

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager]
"ExcludeFromKnownDlls"=hex(7):00,00

The next step could be to make the assembly a shared assembly available for all applications that may need it by placing it in the WinSxS directory, if that is permitted.  It could be that only GDIPLUs, Shell Common Controls, and Visual C++ Run-time Libraries are the only supported Side-by-side assemblies.

Edited December 26, 2024 by Zorba the Geek