没有导出函数的DLL？
我对 MS-Office DLL 进行了一些窥探，发现有些 DLL 没有任何导出函数。我不太明白，应用程序如何在不导出任何函数的情况下使用这些 DLL？！
我的意思是，dllmain() 确实在 LoadLibrary() 上执行，但这有什么意义呢？为什么有人会创建一个没有导出函数的 DLL？
谢谢！ :-)
I've snooped around a little bit in MS-Office DLLs, and I noticed that some of the DLLs don't have any exported functions. What I don't quite understand, how an application can use these DLLs without any functions exported ?!
I mean, the dllmain() does get executed on LoadLibrary(), but whats the point? Why would anyone create a DLL without exported functions?
thanks! :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当您调用 LoadLibrary 时，DLL 会调用其 DllMain。
那是DLL入口点。它在进程附加和线程附加上调用。
所以你确实有切入点。
一旦它至少有一个入口点，它就可以创建某个接口（例如工厂）的实例，并将其设置在例如 TLS 变量中，其他模块将在其中拾取它们。
因此，您可以拥有类似于 COM 的接口系统，除了应用程序之外，不会向外部公开这些接口。类似的事情——许多过度的变化是可能的。
When you call LoadLibrary the DLL gets call of its DllMain.
That is DLL entry point. It is called on process attach and thread attach.
So you do have entry point.
As soon as it has at least one entry point then it can create instance of some interface (e.g. factory) an set it in e.g. TLS variables where other modules will pickup them.
So you can can have COM alike system of interfaces that are not exposed outside except to the application. Something like that - many over variations are possible.
处理针对不同语言的程序版本的一种方法是将所有资源放入语言 DLL 中。该 DLL 不包含任何代码，仅包含已翻译为目标语言的资源。当主程序启动时，它所需要做的就是加载适当的语言DLL。
One way of dealing with versions of a program destined for different languages is to put all of the resources into a language DLL. The DLL doesn't contain any code, just resources that have been translated to a target language. When the main program starts up, all it needs to do is load the proper language DLL.
我没有看过相关的 DLL；但在像 MSOffice 这样的东西中，微软可能这样做是为了混淆 DLL，使其更难以调试/逆向工程。
但是，当你问你如何使用这样的 DLL 时？如果应用程序知道 DLL 的布局，那么它可以使用已知函数的地址创建一个函数指针并调用它。
如果您确实想进一步挖掘，您可以 objdump DLL 并查找标准 C / C++ ABI 函数序言和文件。尾声并可能找出功能的开始位置。
I haven't looked at the DLLs in question; but it's possible in something like MSOffice Microsoft have done this to obfuscate the DLL to make it more difficult to debug / reverse engineer.
However, as you ask how would you use such a DLL? Well if the application knows the layout of the DLL then it can create a function pointer with the address of a known function and call it.
If you really want to dig further you could objdump the DLL and look for standard C / C++ ABI function prologues & epilogues and possibly work out where the functions start.
资源
DLL 可能具有供 Office 其余部分使用的资源，例如字符串表、图像、图标等。
Resources
The DLL likely has resources, like string tables, images, icons, etc., used by the rest of Office.
他们总是可能不将它们导出为 C 接口。 DLL 并不神奇，它只是位和字节，并且没有任何说法表明如果您不向 Windows 请求就无法从 DLL 中获取代码。我相信 .NET 采用了这种方法 - 它们将元数据保存在 DLL 中，告诉 CLR 其中的内容，而不是通过正常的 GetProcAddress 方法使 .NET 函数可用。除非你明确要求。
Always possible that they just don't export them as C interfaces. A DLL isn't magic, it's just bits and bytes, and nothing says that you can't get code out of a DLL if you don't ask Windows for it. I believe that .NET takes this approach- they save metadata in the DLL that tells the CLR what's in it, instead of making .NET functions available by the normal GetProcAddress approach. Unless you explicitly ask for it.