DLL监控
是否有一个应用程序可以让我查看从进程发送到 DLL 的内容？
我有一个进程和一个 DLL，我想监视发送到函数的参数，以便我可以自己使用该 DLL。
DLL 的 EXPORT 是。
??0CCP压缩机@@AAE@XZ
??0CCPExpandor@@AAE@XZ
??1CCP压缩机@@AAE@XZ
??1CCPExpandor@@AAE@XZ
?清除@CCPCompressor@@QAEHXZ
?清除@CCPExpandor@@QAEHXZ
..压缩@CCPCompressor..
..删除@CCPCompressor..
..删除@CCPExpandor..
..扩展@CCPExpandor..
..免费@CCPCompressor..
..免费@CCPExpandor..
..初始化@CCPCompressor..
..Init@CCPExpandor..
..新@CCPCompressor..
..新@CCPExpandor..
Is there an application which allows me to see what is being sent to a DLL from a process?
I have a process and I have a DLL and I would like to monitor the parameters that are being sent to the functions so that I can use the DLL myself.
The EXPORT of the DLL is.
??0CCPCompressor@@AAE@XZ
??0CCPExpandor@@AAE@XZ
??1CCPCompressor@@AAE@XZ
??1CCPExpandor@@AAE@XZ
?Clear@CCPCompressor@@QAEHXZ
?Clear@CCPExpandor@@QAEHXZ
..Compress@CCPCompressor..
..Delete@CCPCompressor..
..Delete@CCPExpandor..
..Expand@CCPExpandor..
..Free@CCPCompressor..
..Free@CCPExpandor..
..Init@CCPCompressor..
..Init@CCPExpandor..
..New@CCPCompressor..
..New@CCPExpandor..
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一般来说，这是一个坏主意。即使您有一些捕获的参数集，如果不深入分析 DLL 代码，您也不知道如何处理这些参数以及某些方法接受哪些参数范围。示例：如果我调用方法 DoMathOperation(Add, 1, 2)，您可以模仿此调用，但您将无法执行 DoMathOperation(Multiply, 2, 2)，因为您不知道这是可能的。
In general, this is a bad idea. Even if you have some set of captured parameters, without deep analysis of the DLL code you don't know what to do with those parameters and what ranges of parameters are accepted by certain methods. Example: if I call a method DoMathOperation(Add, 1, 2), you can mimic this call, but you won't be able to do DoMathOperation(Multiply, 2, 2) as you don't know that this is possible.
最简单的方法是简单地重新定位原始 dll，并创建一个您自己制作的新 dll，并具有相同的导出。该 dll 将从备用位置加载旧 dll 的库。
这在这里不太适用 - dll 正在导出 c++ 类成员，这会产生两个后果：c++ 类必须静态加载，因为没有 c++ 机制将 c++ 函数指针（通过 GetProcAddress 获得）“粘合”到类实例中。
这意味着您的 shim dll 将处于必须导入和导出以及相同的符号集的不幸位置。
解决这个问题的唯一方法是将 shim dll 分成两部分编写：
Shim1：
一部分将获取原始 dll 的名称，并导出与原始 dll 导出的相同的类定义：
Depends 可以破解名称装饰，或者Undname.exe 随 Visual Studio 一起分发。
这部分将 LoadLibrary() 使用位于其他文件夹中的 shimdll2.dll 的显式路径以及原始 dll。需要 GetProcAddress() 来导入由 shimdll2.dll
Shim2 导出的函数：
另一个 shim dll 将位于您尝试拦截的 dll 所在的文件夹中。该 dll 必须从原始压缩器 dll 中导入类：
您可以使用第一个 dll 生成的 dll 导入库来实际链接符号。
然后是从 shim2.dll 导出函数的情况，只要调用 CCPCompressor 方法，shim1.dll 就会调用该函数。
注意。其他事项：您的 CCPCompressor 类版本至少需要一个大的虚拟数组，因为您无法从 dll 导出中知道应用程序期望该类有多大（除非您碰巧有一个实际的头文件描述类）。
要分解导出的名称以构建类定义：
从“开始”>“打开 Visual Studio 20XX 命令提示符”节目> Visual Studio 20XX ->工具菜单。
对从原始 dll 导出的每个函数执行此操作（undname 接受某种文本文件以加快此过程），以了解如何声明匹配的类 def。
The simplest approach has been to simply relocate the original dll, and create a new dll that you make yourself, with the same exports. This dll would LoadLibrary the old dll from the alternate location.
This doesn't quite apply here - the dll is exporting c++ class members which has two consequences: c++ classes have to be statically loaded as there is no c++ mechanism to 'glue' c++ function pointers (obtained via GetProcAddress) into a class instance.
This means your shim dll would be in the unfortunate place of having to both import, and export, and identical set of symbols.
The only way around this is to write your shim dll in two parts:
Shim1:
One part would get the name of the original dll, and would export the same class defintion the original dll exported:
Depends can crack the name decoration, or Undname.exe is distributed with Visual Studio.
This part would LoadLibrary() using an explicit path to shimdll2.dll located in some other folder, along with the original dll. GetProcAddress() would be needed to import functions exported by shimdll2.dll
Shim2:
The other shim dll would be located in a folder with the dll you are trying to intercept. This dll would have to import the class from the original compressor dll:
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.
NB. Other things: your version of the CCPCompressor class will need to have, at least, a large dummy array as you can't know from the dll exports how big the application expects the class to be (unless you happen to have an actual header file describing the class).
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.
Do that for each function exported from the original dll (undname accepts some kind of text file to speed this process up) to find out how to declare a matching class def.
使用detours 是否符合您的要求？
来自网站：
概述
创新系统研究取决于轻松检测和扩展现有操作系统和应用程序功能的能力。通过访问适当的源代码，通过重建操作系统或应用程序来插入新的工具或扩展通常很简单。然而，当今世界系统研究人员很少能够访问所有相关的源代码。
Detours 是一个用于在 x86、x64 和 IA64 计算机上检测任意 Win32 函数的库。 Detours 通过重写目标函数的内存中代码来拦截 Win32 函数。 Detours 包还包含将任意 DLL 和数据段（称为有效负载）附加到任何 Win32 二进制文件的实用程序。
Detours 保留未检测的目标函数（可通过蹦床调用）作为子例程以供检测使用。我们的蹦床设计可以对现有二进制软件进行大量创新扩展。
我们使用 Detours 创建了一个自动分布式分区系统，来检测和分析 DCOM 协议栈，并为基于 COM 的操作系统 API 创建了一个 thunking 层。 Detours 在 Microsoft 和业界得到广泛使用。
Is using detours compatible with your requirements?
From the site:
Overview
Innovative systems research hinges on the ability to easily instrument and extend existing operating system and application functionality. With access to appropriate source code, it is often trivial to insert new instrumentation or extensions by rebuilding the OS or application. However, in today's world systems researchers seldom have access to all relevant source code.
Detours is a library for instrumenting arbitrary Win32 functions on x86, x64, and IA64 machines. Detours intercepts Win32 functions by re-writing the in-memory code for target functions. The Detours package also contains utilities to attach arbitrary DLLs and data segments (called payloads) to any Win32 binary.
Detours preserves the un-instrumented target function (callable through a trampoline) as a subroutine for use by the instrumentation. Our trampoline design enables a large class of innovative extensions to existing binary software.
We have used Detours to create an automatic distributed partitioning system, to instrument and analyze the DCOM protocol stack, and to create a thunking layer for a COM-based OS API. Detours is used widely within Microsoft and within the industry.
唯一可靠的方法是调试程序（使用 OllyDBG 等任何调试器）并在所需的导出函数上设置断点。然后您可以简单地跟踪发送到调用函数的堆栈参数。这只是开始，您需要在调试器或反汇编器中全面分析函数指令，以查看每个参数的作用及其类型。
The only reliable way is to debug your program (using any debugger like OllyDBG) and set breakpoint on required export function. Then you can simply trace the stack parameters sent to the calling function. This is only the start, you need to fully analyze function instructions within a debugger or disassembler to see what each parameter is doing and its type.