调用64位dll

SixRC

星期二的时候，突然有一个想法，就是32位程序调用64位dll，然后开始今天干到明天明天到后天balabala到现在
诸多收获 莫大伤感 最后爆炸 不干了 虽然是成功了 但是局限太多 根本没用啊我靠
不干了 但还是 留个纪念吧

最开始有这个想法，是因为我知道能用远跳转从32位的机器码执行转到64位去 （win下程序加载有两个代码段 0x23是32位 0x33是64位）
想想最大的问题莫过于此 之后的也应该还好吧..
然后的问题就是怎么加载dll了
直接加载肯定是不行的 起码也得用64位的 LoadLibraryA 去加载吧 但是怎么得到它的地址呢？
我就查呀 查到 PEB TEB 这些东西 然后边查边试   (PEB 进程环境块 包含进程的一些信息 比方加载的模块等等)
然后发现 32位程序确实有两个 PEB 一个32位一个64位
而从64位的PEB结构得到 程序加载了四个 dll
分别是 ntdll wow64 wow64cpu wow64win
然后接着查 知道了后面三个是微软特地拿来兼容32位程序做出来的
这意味着什么呢？
就是64位系统下所谓的32位程序 其实加载初始都是64位的 不过后来去了32位
这更坚定了我加载64位dll的想法 它本来就是64位的啊！！(以前从来不知道)
但没有 kernel32 也就没有 LoadLibraryA
不过没关系 反正加载dll 最终都是 ntdll 干的
我就跟了LoadLibraryA 发现了 LdrLoadDll 这个函数 搞清楚了它的调用方式
然后通过 PEB 里面得到的64位ntdll基址加上导入表结构知识得到了这个函数的地址
然后 耶！
成功加载了64位kernel32 也成功加载了我自己的dll

不过 接下来就是可怕悲伤的开端
我试图加载64位的 user32 不过程序挂了
加载 gdi32 也是  
任何依赖它们的dll理所当然都不行
不知道根源到底是什么 但肯定是某些user32和gdi32依赖的东西 大概不能在64位和32位共存 即使32位没加载这玩意
我想 好吧 可能因为一些 wow64 实现上的问题 不能存在两套东西 ?
那64位了 能不能申请大的内存呢?
试验发现 依旧是低于2G
然后查了 wow64
官方说一个功能就是限制内存的使用
但我是拿64位api去申请的啊！没天理啊没人性啊！
之后我知道了 内核的一个结构 EPROCESS 中有一个成员是 Wow64Process
我猜64位的api会检测一个进程是不是 wow64进程吧
然后据此进行作业
不过这是内核的东西 我没办法得知了 即使知道了 也无力修改

调用是成功了 可是没有user32 特别是没有大内存优势的64位dll 有个鬼用 调用还麻烦
心态爆炸
不知道的 无法实现的
乱七八糟的实在太多了


最后留个成果吧
用64位msvcrt的gets获取字符串
会弹出两个cmd框 不过只有第一个能输入
估计是第二个没初始化
第一个能输入是因为32位的函数实现还是在64位的ntdll吧大概
即使用64位printf也是输出在第一个框
64位gets.zip (7.56 KB, 下载次数: 62)

2017-12-17 00:08 上传

点击文件名下载附件

具体实现都在源码里了
有兴趣的可以自己拓展啦

SailCat

rgss里开个1w7大小的bitmap都会炸，调用64位的dll意义何在……

defisym

2GB内存限制是32位程序的锅
微软在MSDN上有说明
https://msdn.microsoft.com/zh-cn ... PPError=-2147217396

所有 32 位应用程序都有 4 GB 的进程地址空间（32 位地址最多可以映射 4 GB 的内存）。对于 Microsoft Windows 操作系统，应用程序可以访问 2 GB 的进程地址空间，称为用户模式虚拟地址空间。应用程序拥有的所有线程都共享同一个用户模式虚拟地址空间。其余 2 GB 为操作系统保留（也称为内核模式地址空间）。所有操作系统版本（从 Windows 2000 Server 开始，包括 Windows Server 2003）都有一个 boot.ini 开关，可以为应用程序提供访问 3 GB 的进程地址空间的权限，从而将内核模式地址空间限定为 1 GB

大概就和DX9的2^n一样吧……

fux2

没必要的话最好不要搞这样麻烦的事情（伤神还没好处也没用处