32位进程调用64位dll的问题

董督秀

讨论中涉及的exe和dll：
https://wwbeo.lanzouv.com/iZxSo3iyw3sj
我尝试在32位程序中使用wow64（详见有关GH开源库）调用64位dll，经测试在加载64位dll后，出现了一些问题：

步骤思路：通过切换cs进入到64位模式，并且从ntdll中取到线程创建函数进行创建线程，之后从取到ldr函数地址加载test.dll

如果使用64位调试器单独加载test.dll，可以看到入口点相对偏移0x1470：

01

用32位调试器运行JmpCall64.exe，通过控制台打印提示可以看到，已经将其加载到32位进程空间了（可以提前在ExitProcess设置断点），

02

存在问题：

1. 在64位的win10测试，当控制台打印输出结束后，偶尔会出现0xC0000005错误，或者异常崩溃。注册异常处理无法捕获；在64位的win7测试，直接崩溃，异常也无法捕获

2. 导出函数地址获取问题。假设给test.dll声明导出函数，那么该如何在32位进程中，获取该自定义模块（test.dll）的导出函数地址？

3. 如果在test.dll中使用user32.dll等模块中的函数，例如在dllmain中使用MessageBoxA会导致崩溃、使用OutputDebugString也是崩溃。但如果使用printf打印之类的函数却不崩溃？

4. 在32位调试器中，给Sleep设置断点，无法断下。
详见dll入口点简单写了一段代码进行打印测试：

03

5. 在test.dll打印输出过程中，尝试更名dll文件成功，未提示文件占用？dll会打印24秒，在24秒内，尝试给dll改名，发现可以更名，为什么？一般情况下，使用中的文件貌似无法进行更名？

fengshangren

为什么要做这种事情

BrutusScipio

最大的问题是数据类型长度不一致吧，可以用定长的简单函数试一试

beyondchampion

感觉很强，学习一下

plauger

这种奇葩的应用场景在做外挂的时候会遇到，不过一般是反过来，64位调用32位，因为现在很少新的软件发布32位版本了，整体是64位的，但外挂的对象是32位，这就涉及64位调用32位的问题了。直接去调用的方案是有，但一般要用内存加载的方式，就是仿loadlibrary的方式，把DLL加载到内存，然后处理符号表和重定位等，你所用的方式估计就是这种情况，因为不是直接映射这个DLL所以不会锁定，没有锁定就可以改名甚至删除。

从个人的经验来看这并不是优雅和稳定的方式，我会更偏向于用IPC或管道的方式，更WINDOWS的方案是将32位部分包装成系统服务来调用。开销或许比直接调用大一些，但兼容性和稳定性更有保障。

yuhu1123

主要还是宽度范围问题吧