最简单的方法是简单地重新定位原始dll,并使用相同的导出创建自己制作的新dll。此dll将从备用位置加载旧dll的LoadLibrary。
这在这里并不完全适用-dll正在导出c++类成员,这有两个后果:c++类必须静态加载,因为没有c++机制将c++函数指针(通过GetProcAddress获得)粘合到类实例中。
这意味着您的填充程序dll将处于不幸的位置,必须同时导入和导出相同的符号集。
解决这一问题的唯一方法是将您的填充程序dll分为两部分:
垫片1:
其中一部分将获得原始dll的名称,并将导出与导出的原始dll相同的类定义:
class __decldpec(dllexport) CCPCompressor {
...
依赖可以破解名称装饰,或者Undname.exe随Visual Studio一起分发。
这部分将使用位于其他文件夹中的shimdll2.dll的显式路径以及原始dll来加载库()。需要GetProcAddress()才能导入shimdll2.dll导出的函数
垫片2:
另一个填充程序dll将位于您试图拦截的dll所在的文件夹中。此dll必须从原始压缩器dll导入类:
class __declspec(dllimport) CCPCompressor {
...
You can use the dll import library made by the first dll to actually link the symbols.
Then its a case of exporting functions from shim2.dll that shim1.dll will call whenever a CCPCompressor method is called.
注:。其他事项:CCPCompressor类的版本至少需要一个大的伪数组,因为你无法从dll导出中知道应用程序期望该类有多大(除非你碰巧有一个描述该类的实际头文件)。
To decompose the exported names to build a class definition:
Open up the Visual Studio 20XX Command Prompt from the Start > Programs > Visual Studio 20XX -> Tools menu.
c:...VC>undname ?Clear@CCPCompressor@@QAEHXZ
Microsoft (R) C++ Name Undecorator
Undecoration of :- "?Clear@CCPCompressor@@QAEHXZ"
is :- "public: int __thiscall CCPCompressor:Clear(void)"
c:...VC>_
对从原始dll导出的每个函数执行此操作(undname接受某种文本文件以加快此过程),以了解如何声明匹配的类def。