DLL重定向使用清单

问题描述

我需要可靠地重定向一个特定DLL的应用程序查找。使用app.exe.local方法不起作用，因为如果应用程序具有清单（嵌入式或单独文件），则会忽略本地文件。所以我试图通过将DLL定义为在清单中的私有程序集来执行DLL重定向。

我有一个测试应用程序，LoadDll.exe只需调用

  LoadLibrary（C：\\EmptyDll.dll）; 
  

LoadDll.exe具有清单（作为单独的文件，LoadDll.exe.manifest） p>

 <？xml version =1.0encoding =UTF-8standalone =yes？> 
< assembly xmlns =urn：schemas-microsoft-com：asm.v1manifestVersion =1.0> 
< assemblyIdentity 
 version =1.0.0.1
 processorArchitecture =x86
 name =LoadDll
 type =win32
 / > 
<依赖关系> 
< dependentAssembly> 
< assemblyIdentity 
 type =win32
 name =EmptyDll
 version =1.0.0.1
 processorArchitecture =x86
 / > 
< / dependentAssembly> 
< / dependency> 
< / assembly> 
  

包含LoadDll.exe（NOT c：\）的应用程序文件夹包含EmptyDll.dll，嵌入式清单

 <？xml version ='1.0'encoding ='UTF-8'standalone ='yes'？& ; 
< assembly xmlns ='urn：schemas-microsoft-com：asm.v1'manifestVersion ='1.0'> 
< assemblyIdentity 
 type =win32
 name =EmptyDll
 version =1.0.0.1
 processorArchitecture =x86
 / > 
< / assembly> 
  

但是，LoadDll.exe会继续加载C：\EmptyDll.dll，而不是EmptyDll应用程序文件夹中的.dll。

如果您中断了任何一个清单（例如更改EmptyDll.dll清单标识中的版本号），LoadDll.exe将不会加载，所以清单文件正在被Windows读取和处理，但被忽略。

任何人都有任何想法？

谢谢！

Toby

解决方案

所以似乎不可能重定向通过使用清单的绝对路径调用LoadLibrary。

经过大量的清单播放后，似乎一旦你过去了，所有的坏文档清单实际上是愚蠢的简单。

基本上当可执行文件加载时，windows会收集所有使用身份和依赖关系元素链接的相关清单。然后对于清单文件中包含的每个文件元素，它会在激活上下文中添加一个条目：

 '文件元素的name属性' - > '清单文件的绝对路径'+'文件元素的名称属性'
  

现在加载库调用在激活上下文映射中搜索与加载库的路径参数匹配的密钥，然后使用该密钥的值对该loadlibrary进行搜索。

所以如果我的应用程序c：\foo\foo.exe具有与c：\foo\baa\baa.manifest中的清单的依赖关系，而baa.manifest包含一个文件元素< file name =empty.dll/> ，则激活上下文将具有映射：empty.dll - > c：\foo\baa\empty.dll

所以任何调用 LoadLibrary（ empty.dll）将重定向到 LoadLibrary（C：\foo\baa\empty.dll）。 p>

但是， LoadLibrary（c：\anotherpath\empty.dll）不会被重定向！ p>

现在来证明我的愚蠢简单的清单文件和激活上下文的意思。如果baa.manifest的文件元素为< file name =c：\anotherpath\empty.dll/> ，并且您创建了一个 LoadLibrary（C：\anotherpath\empty.dll）调用，LoadLibrary调用将被重定向到 LoadLibrary（C：\foo\baa \C：\anotherpath\empty.dll），是的，格式错误的路径...

文件元素有一个称为loadFrom的无证属性，它的作用是什么，它似乎是完美的解决这个问题。使用loadFrom，我能够重定向一个绝对路径loadlibrary调用，但它似乎以奇怪的方式解决可执行文件中的其他依赖关系。如果有人更了解loadFrom的工作原理，我会非常感兴趣。

那么我最近如何解决我的问题？通过使用描述的DLL Trojaning的令人难以置信的沉重的方法。基本上，您创建一个虚拟的kernel32.dll，将所有调用重定向到原始的kenerl32.dll，除了LoadLibrary调用，您可以在其中放置自己的重定向逻辑。然后在应用程序清单中，放置一个将kernel32.dll重定向到您的虚拟机的文件元素。乐趣。

所有这一切描述了我在Windows Xp Sp2上的实验。为了更多的乐趣，我被带领相信，几乎每个版本的Windows都会有不同的表现。

I need to reliably redirect an applications look up of a specific DLL. Using the app.exe.local approach does not work because local files are ignored if the application has a manifest (embedded or separate file). So I am trying to do DLL redirection by defining the DLL as a private assembly in the manifests.

I have a test application, LoadDll.exe which simply calls

LoadLibrary("C:\\EmptyDll.dll");

The LoadDll.exe has the manifest (as a separate file, LoadDll.exe.manifest)

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

The Application folder containing LoadDll.exe (NOT c:\) contains the EmptyDll.dll with the embedded 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="EmptyDll"
   version="1.0.0.1"
      processorArchitecture="x86"
    />
</assembly>

However, LoadDll.exe goes ahead and loads C:\EmptyDll.dll, and not the EmptyDll.dll in the application folder.

If you break either manifest (e.g. change the version number in the EmptyDll.dll manifest identity), LoadDll.exe does not load, so the manifest files are being read and processed by windows, but just ignored.

Anyone got any ideas?

Thanks!

Toby

解决方案

So it seems its impossible to redirect calls to LoadLibrary with absolute paths using manifests.

After a lot of playing around with manifests, it seems that once you get past all the bad documentation manifests are actually stupidly simple.

Basically when the executable is loaded windows collects all the related manifests that are linked using the identity and dependency elements. Then for each file element contained in the manifest files, it adds an entry into the activation context:

'name attribute of file element' -> 'absolute path of manifest file' + 'name attribute of file element'

Now when a load library call is made, it searches the activation context map for a key that matches the path argument of load library, and then does the loadlibrary with the value for that key.

So if my application c:\foo\foo.exe has a dependency to the manifest in c:\foo\baa\baa.manifest, and baa.manifest contains a file element <file name="empty.dll"/>, then the activation context will have a mapping: "empty.dll" -> "c:\foo\baa\empty.dll"

So any calls to LoadLibrary("empty.dll") will be redirected to LoadLibrary("C:\foo\baa\empty.dll").

However, LoadLibrary("c:\anotherpath\empty.dll") Will not be redirected!

Now to prove my point of how stupidly simple manifest files and activation contexts are. If the file element of baa.manifest was <file name="c:\anotherpath\empty.dll"/> and you made a LoadLibrary("C:\anotherpath\empty.dll") call, the LoadLibrary call will be redirected to LoadLibrary("C:\foo\baa\C:\anotherpath\empty.dll"), yes, a malformed path...

The file element does have an undocumented attribute called "loadFrom", which does what it sounds like, and seems like its perfect to solve this problem. Using loadFrom, I was able to redirect an absolute path loadlibrary call, but it seemed to screw up other dependencies in the executable in weird ways. If someone knows more about how "loadFrom" works I would be very interested.

So how did I solve my problem in the end? By using an incredibly heavy handed approach of DLL Trojaning described at Ethical Hacker. Basically you create a dummy kernel32.dll that redirects all calls to the original kenerl32.dll, except for the LoadLibrary calls, in which you place your own redirection logic. Then in the applications manifest, you place a file element that redirects the kernel32.dll to your dummy. Fun.

All this describes my experiments on Windows Xp Sp2. For extra fun I'm led to believe manifests behave differently on almost every version of Windows.

这篇关于DLL重定向使用清单的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！