-
-
[原创]做了个生成DLL导入库的工具（1月28日更新）
-
发表于: 2014-1-26 22:23
-
题外话：不喜欢这个账号名了想换个，结果注册完“空雪梦见”以后发现一时半会儿死活搞不成正式会员，放弃挣扎了……
使用此工具需要对链接过程中导入DLL中的函数会遇到的几种符号有基本常识，举个例子就是要知道 Sleep、_Sleep@4、__imp__Sleep@4 是什么。
来个应用场景。
Windows API里有时会遇到输入流要求送一个IStream*进去的情况。此时经常会有调用SHCreateStreamOnFileEx或者CreateStreamOnHGlobal。我当年在公司实习的时候，就看到很多创建一个HGLOBAL然后把手头一块内存拷过去然后创建Stream的代码。实际上shwapi.dll里是有SHCreateMemStream的但是在Windows Vista之前，甚至连shwapi.h里都没有，要调用的话只能LoadLibrary然后GetProcAddress。
为了能直接通过导入表方式导入这个函数，就可以使用这个工具。
写一个如下的XML：
<ImportLibrary>
<DllName>Shlwapi.dll</DllName>
<Import>
<LinkName>__imp__SHCreateMemStream@8</LinkName>
<Ordinal>12</Ordinal>
</Import>
</ImportLibrary>
保存成shcms.xml，然后
MakeImpLib.exe shcms.xml shcms.lib
就得到了一个shcms.lib，链接的时候链上去就可以了。
Import节点里支持这几种子节点：
LinkName：必须要，指向IAT里函数地址的符号
StubName：可选，导出的函数（不是函数指针）符号，没有__declspec(dllimport)的时候可以链接
Ordinal：DLL中导出函数的序号
ImportName：DLL中导出函数的名称，和Ordinal两者任选一个，同时存在则优先ImportName
然后就只要写个函数声明，带__declspec(dllimport)的，就可以链接了（必要时候别忘了extern "C"）
GCC生成的C++的DLL拿给VC用大概也是一种应用场景，但是GCC的修饰名转换到VC的修饰名到底有什么规则我搞不清楚，于是也就作罢了。大概等到链接的时候出错了从出错信息里获取修饰名是一种办法？……
1月27日傍晚更新：
头文件加了点注释，DLL资源里打包了Readme进去
1月28日上午更新：
可以支持同时使用Ordinal和Name的方式导入，实际上导入还是靠Name，Ordinal作为hint，具体看不带参数时makeimplib的输出
ImpGen和LibGenHelper的接口添加了新方法
使用此工具需要对链接过程中导入DLL中的函数会遇到的几种符号有基本常识，举个例子就是要知道 Sleep、_Sleep@4、__imp__Sleep@4 是什么。
- 目的
- 现状
- 相关工作
- 设计与实现
- 经验
- LIB文件里各个成员的顺序，按照 导入描述符——空白描述符——导入函数1——导入函数2——……——空白Thunk 的顺序下来。其实是不是这个顺序我没测试过，因为最初不知道Member Name必须一样的时候，我就已经尝试过顺序了。到后来成功了也就没测试过其他顺序。
- Object文件中符号表里，Section的定义要在它里面的符号出现之前，特别是COMDAT的Section（不是COMDAT的还没遇上过它出错，没测试）。不然链接的时候报错。
- LIB里的Object文件似乎起始位置（文件指针）都是偶数，遇上奇数的会加上0x0a补成偶数。这个在微软给出的参考资料里貌似没说明（或者我没找到）？但是我看它自己（ImpLib SDK也）是这么做的
- FirstLinkMember虽然文档中说可以不要，但是我弄个空的FirstLinkMember进去它就什么符号也不给我出来了。是我实验的时候其他地方错了吗？还是说其实它本来就不能省略的？
- FirstLinkMember里Offset表要递增排序，SecondLinkMember里Offset表要递增排序，字符串表也要递增排序。没有递增排序会怎么样？没实验但是有一点，ImpLib SDK生成的FirstLinkMember貌似Offset表没有递增排序诶！
- 参考资料
- 附加说明
- 关于源代码
.
还有个方法是自己写个空白的DLL，里面导出这些函数，然后写个DEF，链接以后能得到一个LIB。感觉这个方法很山寨啊，一点都不高端。而且说不出的总觉得它是不是哪里会不够灵活……
.
再就是我以前做过的某种事情，利用NASM汇编器生成OBJ文件，达到重命名链接符号的目的。原理不能更简单，就是JMP。同样是方法很山寨，然后要怎么把它塞入LIB文件，塞入GCC的LIB还好，塞入VC的LIB总之我是没成功。虽然可以单独生成一个LIB，链接的时候和导入库一块儿，但是……更山寨了！
然后，然后就是我没再找到能干这种事的东西了。
.
最早从COFF文件入手，分析了一下VC搞出来的LIB，发现它就是 .idata$2 塞了个IMAGE_IMPORT_DESCRIPTOR，然后 .idata$3 塞了个空白的描述符（代表导入描述符数组的结束），在 .idata$4 和 .idata$5 里塞着OriginalFirstThunk和FirstThunk指向的东西，.idata$6就存放DLL的文件名和PE加载器加载的时候查找函数要用的IMPORT_BY_NAME。因为链接的时候会按照Section名的$后的数字进行排序，所以很容易就组成了数组。
现在想想，我简直太乐观了……
对VC生成的LIB一分析，后面有十分诡异的Obj文件，一看说明，是特别的导入格式。最终我没有采用这种方式……
然后我参考GCC生成的LIB，做了好久，一直没有成功。到某天脑子一抽，用VC去链接这个GCC生成的LIB，呸，这不是明摆着失败了吗，囧了个囧。
之后参考ImpLib SDK，我也照着做，感觉都快要成功了，弄了一堆OBJ文件然后用LINK.EXE /LIB来生成LIB文件，DumpBin出来的信息和ImpLib SDK生成的LIB几乎完全一致！但是，它的可以用我的不能用。呸
直到某天早上起来，又脑子一抽，把ImpLib SDK生成的LIB里的每个Object都拆出来，再用LINK.EXE /LIB弄回去，嘿小样儿这回你也不能用了吧（殴
于是我大概知道问题出在LIB里的Member name了。
再然后我做出来的LIB也能用了。
.
.
ebdK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3u0D9L8$3N6Q4x3X3g2K6L8%4u0S2i4K6u0W2K9h3&6X3L8#2)9J5k6i4c8E0i4K6u0r3i4K6y4r3M7q4)9K6c8o6x3%4x3R3`.`.
.
COFF和LIB的格式
56bK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3#2K6k6r3&6Q4x3X3g2E0K9h3y4J5L8%4y4G2k6Y4c8Q4x3X3g2U0L8$3#2Q4x3V1k6D9K9h3u0J5j5i4u0&6i4K6u0r3N6$3W2F1k6r3!0%4M7#2)9J5c8X3S2S2M7X3c8%4j5i4u0W2i4K6u0r3k6$3M7@1y4U0x3I4x3e0W2Q4x3X3g2S2M7%4m8^5
.
链接时导入表的构成
84cK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3#2A6j5%4u0G2M7$3!0X3N6q4)9J5k6h3y4G2L8g2)9J5c8X3#2K6K9W2)9J5c8U0l9@1z5e0S2Q4x3V1k6Z5L8$3!0V1x3o6b7&6z5q4)9J5k6h3q4K6M7s2R3`.
.
ImpLib SDK工具
657K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4y4G2N6i4u0U0k6h3k6G2M7X3N6W2i4K6u0W2L8X3g2@1i4K6u0r3M7s2u0G2K9X3g2U0N6s2y4Q4x3V1k6A6L8i4m8D9K9h3t1`.
.
.
开发环境是Visual Studio 2013 Express，ATL 7.1（从Windows Driver Kit里来的）
编译工具集用了支持Windows XP的设置。
这个工具生成的LIB是给X86架构用的，X64下貌似没有这种修饰名的问题，没有的话直接从DEF生成LIB就能用了。
.
.
来个应用场景。
Windows API里有时会遇到输入流要求送一个IStream*进去的情况。此时经常会有调用SHCreateStreamOnFileEx或者CreateStreamOnHGlobal。我当年在公司实习的时候，就看到很多创建一个HGLOBAL然后把手头一块内存拷过去然后创建Stream的代码。实际上shwapi.dll里是有SHCreateMemStream的但是在Windows Vista之前，甚至连shwapi.h里都没有，要调用的话只能LoadLibrary然后GetProcAddress。
为了能直接通过导入表方式导入这个函数，就可以使用这个工具。
写一个如下的XML：
<ImportLibrary>
<DllName>Shlwapi.dll</DllName>
<Import>
<LinkName>__imp__SHCreateMemStream@8</LinkName>
<Ordinal>12</Ordinal>
</Import>
</ImportLibrary>
保存成shcms.xml，然后
MakeImpLib.exe shcms.xml shcms.lib
就得到了一个shcms.lib，链接的时候链上去就可以了。
Import节点里支持这几种子节点：
LinkName：必须要，指向IAT里函数地址的符号
StubName：可选，导出的函数（不是函数指针）符号，没有__declspec(dllimport)的时候可以链接
Ordinal：DLL中导出函数的序号
ImportName：DLL中导出函数的名称，和Ordinal两者任选一个，同时存在则优先ImportName
然后就只要写个函数声明，带__declspec(dllimport)的，就可以链接了（必要时候别忘了extern "C"）
GCC生成的C++的DLL拿给VC用大概也是一种应用场景，但是GCC的修饰名转换到VC的修饰名到底有什么规则我搞不清楚，于是也就作罢了。大概等到链接的时候出错了从出错信息里获取修饰名是一种办法？……
1月27日傍晚更新：
头文件加了点注释，DLL资源里打包了Readme进去
1月28日上午更新：
可以支持同时使用Ordinal和Name的方式导入，实际上导入还是靠Name，Ordinal作为hint，具体看不带参数时makeimplib的输出
ImpGen和LibGenHelper的接口添加了新方法
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
谢谢回复。我拿一个现成的DLL来测试，用ImpLib-1.8生成的LIB能正常使用，而用你的工具生成时编译错误。
另外，你的工具不能自动生成XML文件，手工写比较麻烦。 不好意思，挑剔了 
|
|
|
|
|
|
|
|
|
我用OD看了一下，这个DLL里导出的两个函数都是没有参数的，而且还没有返回值，作为stdcall或者cdecl都行。我当作stdcall处理。
 我可以从cpp代码生成exe文件，导入你的dll里的两个函数。 截图质量很差是在想大概可以给看雪省点附件空间（何？） 我想你应该没有误解这个工具的作用吧……它是生成导入库，就是vc生成dll的时候会配给你的那个lib，生成和那个功能一样的lib，供弄丢lib的人（或者网上下的dll没有lib，或者其他编译器生成的dll所以lib不能给vc用，等情况）开发时候使用，不是给exe的导入表添加导入项之类。 哦对了有个问题我还没解释就是为什么输入是xml，因为我发现解析输入文件很麻烦（锤锤锤）文件编码问题，之类之类。所以最后发现xml比较省事。如果需要其他前端的话，可以自己写一个，我的libgenhelper.dll的资源里可以拆出一个readme和两个头文件，然后coffgen.dll里可以拆出前两个头文件依赖的另一个头文件（这个你可以不看），提供的接口我觉得应该是非常简单了，作为生成lib文件用的后端自己配一个前端就好。 现在暂时没有太好的想法要把前端做成什么样，就先暂时用xml…… |
