调用本机 C DLL 时尝试读取或写入受保护的内存
我有一个本机 C dll，除了 DllEntryPoint、FuncX 之外，它还导出一个函数。 我试图找出 FuncX 如何与其调用者通信，因为它有一个 void 返回类型并且没有参数。 当我从 C# 线束调用它时，我收到 AccessViolationException - 尝试读取或写入受保护的内存。
我有预感，它的客户端应用程序可能会分配一个缓冲区来发送或接收来自 dll 的值。 这是一个有效的预感吗？
我无法调试客户端应用程序，因为由于某种原因它没有运行，所以我无法启动它并附加到进程。 然而，我可以在 IDA Pro 中反汇编它，但不知道如何（如果可以的话）尝试在那里调试它。
I have a native C dll that exports one function besides DllEntryPoint, FuncX. I'm trying to find out how FuncX communicates with it's caller, because it has a void return type and no parameters. When I call it from a C# harness, I get an AccessViolationException - Attempted to read or write protected memory.
I have a hunch that its client application may allocate a buffer for sending or receiving values from the dll. Is this a valid hunch?
I can't debug the client application because for some reason it doesn't run, so I can't start it and attach to the process. I can, however, disassemble it in IDA Pro, but don't know how to, if I can, try and debug it in there.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果相关 DLL 具有任何静态或全局符号，则所有通信可能都是通过这些符号完成的。 您是否有任何 API 代码看起来可能会执行此操作？
DLL 不太可能使用客户端提供的缓冲区，因为客户端和服务器都需要知道该缓冲区的基地址，并且您不能在调用时向 calloc 或 malloc 询问“首选”地址。
您也可以尝试运行
link /dump /symbols并将其指向您的 DLL。 这将显示 DLL 中导出符号的列表。 祝你好运！If the DLL in question has any static or global symbols, it's possible that all communication is done via those symbols. Do you have any API code that looks like it might be doing this?
It is unlikely that the DLL is using a client supplied buffer, as both client and server would need to know the base address of that buffer, and you can't ask calloc or malloc for a "preferred" address at call time.
You might also try running
link /dump /symbolsand point it at your DLL. That will show you the list of exported symbols in your DLL. Good luck!我会尝试将 DLL 本身加载到 IDA Pro 中。 希望 C# 保留本机调用堆栈，并且您可以查看 DLL 崩溃位置周围的代码。
旁注：反编译器插件非常棒。
I would try loading the DLL itself into IDA Pro. Hopefully C# preserves the native call stack, and you can look at the code around where the DLL crashes.
Side note: the Decompiler plugin is pretty awesome.