eWOW64Ext v1.2 - 加载任意 32/64 模块|动态调用|64 位汇编|64 位进程读写

npzs · 发表于 2019-3-12 18:33:14

版本更新：

更新内容不大，但修复了个重大 BUG，建议及时更新，具体参考最后的更新日志

模块原理：

wow64 是在 64 位操作系统上允许 32 位程序（比如易编译的程序）执行的模拟器子系统；在 64 位操作系统中，不管你的程序是 32 还是 64 位的，其实都存在两个地址空间，正常情况下 32 位程序访问的自然是 32 位的地址空间，而 64 位程序访问其 64 位地址空间。
但是这两个空间是同时存在且可以切换的，本模块就是通过该原理切换到 64 位地址空间获取 ntdll.dll 相关函数进行调用（注：此基址是 64 位的，与平常获取的 32 位模块基址截然不同）；
也就是：wow 环境 -> 进入 x64 环境 -> x64 函数调用或 x64 汇编代码 -> 退出 x64 环境 -> wow 环境，以上必须在一个子程序内完成；
部分实现代码借鉴 c++ 开源代码：wow64ext，在此感谢作者 rewolf。

模块功能：

实现易语言纯 64 位汇编置入代码；
允许调用易程序 64 位 ntdll.dll 的所有函数，也就是你虽然开发的是 32 位程序，但可以实现很多 64 位函数所能实现的功能；
直接使用 64 位函数自由读写（注入） 64 位进程，与很多模块调用 NtWow64xxx 系列函数实现的方式有本质不同；
部分常用 ntdll.dll 函数已在模块直接提供，或以模拟 kernel32 函数的调用形式提供，v1.1 新增多个函数；
未提供函数获取地址后，可使用 X64Call 这个通用函数调用即可；
大部分提供的 64 位功能也同时提供了 32 位版本，以便兼容不同需求（模块在 32 位系统中不会开启 64 位功能引起异常，但 32 位功能依然可用）；
支持加载任意 32/64 位 DLL，从此易语言可以调用外部 64 位 DLL 了（包括加载 kernel32.dll），v1.1 新增功能；
除了动态加载外，还支持 32 位 DLL 的内存加载，但 64 位只能加载本地 DLL 文件，v1.1 新增功能；
如有 BUG，请提供错误重现代码及执行环境，如非不可抗因素我都会及时更新的；

模块部分命令简述：

以下只是适用于 64 位的部分函数，模块中以相同命令形式实现的 32 位命令，这里就不列举了；

辅Zhu函数
fn_WOW64Enabled	如果你在代码中需要使用 64 位汇编或者操作 64 位进程，则初始化时应确保本函数返回真。实际只要是 64 位操作系统，均应返回真
fn_ProcessIsX64	检测指定进程是否为 64 位进程
fn_CalcModOrFuncHash	使用过动态调用DLL的都清楚取模块基址和函数指针，微软默认使用字符串对比，本模块可使用哈希对比效率和易用上相对提升，本函数用于计算模块或函数哈希

易内部命令
X64Call	调用 64 位函数通用版本
X64CallArr	调用 64 位函数通用版本，数组方式传参，支持无限个数参数；【v1.2新增】
X64MemCopy	同类还有 X64MemCmp 函数；从 64 地址复制数据或 64 位地址与 32 位地址数据对比，但仅限进程内部
X64GetLong64	获取 64 位地址数值，同类函数还有：X64GetLong32、X64GetWord、X64GetByte
X64GetTEB	取当前易程序 64 位 TEB，通过 TEB 再取 PEB，则进程和线程信息以及模块等一览无余了
GetNtdll64	ntdll.dll 在 64 位环境下的内存基址
GetModuleHandleEx64	通过模块哈希值获取其 64 位地址空间的内存基址（易进程而不是外部进程哦）；同类还有 GetModuleHandle64
GetProcAddressEx64	通过函数哈希值或函数索引序号获取其 64 位调用地址；同类还有 GetProcAddress64
NtQuerySystemInformation64	cha询系统信息，可获取很多类别信息。这个 API 微软已不推荐使用并给出部分替代 API，但其个别功能十分好用且没用可替代品。cha询系统进程也是最全面的
OpenProcess64	打开进程句柄，关闭进程句柄时使用 CloseHandle64；【v1.1新增】
HeapAlloc64	堆管理函数，同类还有 GetDefaultHeap64/HeapReAlloc64/HeapFree64/HeapSize64；【v1.1新增】
malloc64	简化版默认堆管理函数，同类还有 realloc64/free64
RtlUnicodeToAnsi64	内核实现的 Unicode、Ansi 结构（不是数据指针）管理函数，同类还有：RtlInitAnsiString64/RtlFreeAnsiString64、RtlInitUnicodeString64/RtlFreeUnicodeString64、RtlAnsiToUnicode64；【v1.1新增】
LoadLibraryEx64	可加载任意 64 位 DLL 到当前进程，获取基址及函数地址后进行调用即可；其释放函数为：FreeLibrary64 另，本函数 32 位版本 LoadLibraryEx86/FreeLibrary86 还支持加载 32 位的内存 DLL；【v1.1新增】

外部进程命令
NtQueryProcessPEB64	获取外部 64 位进程PEB
VirtualAllocEx64	在外部 64 位进程分配内存，释放函数为 VirtualFreeEx64
VirtualQueryEx64	cha询外部 64 位进程指定内存区域的状态，一个地址是否能写入最好先测试一下，禁止写的话要更改内存属性才能开始写入
VirtualProtectEx64	更改外部 64 位进程指定内存区域的保护属性
ReadProcessMemory64	读取外部 64 位进程指定区域的内存数据
WriteProcessMemory64	向外部 64 位进程指定内存区域写入数据
NtQueryInformationProcess64	cha询外部 64 位进程信息
GetThreadContext64	获取线程上下文，多用于 SEH，仅供高级用户使用；相应设置函数为 SetThreadContext64

编写 64 位汇编（供汇编爱好者使用）：

模块公开了几个汇编代码常量：
#X64_Start - 进入 x64 环境
#X64_End - 退出 x64 环境

子程序名	返回值类型	公开	备注
编写x64汇编框架			返回值不限制，同 x86 相同

' 如果本子程序中需要调用 64 位函数，则此时应保存 fs 寄存器及对齐栈顶，可参考源码中的 #X64_SaveFs
置入代码 ( #X64_Start )
' 在此区域内可使用 64 位纯汇编代码
置入代码 ( #X64_End ) ' #X64_End 与 #X64_Start 必须在同一个子程序中成对使用
' 如果本子程序中需要调用 64 位函数，则此时应恢复 ss/fs 寄存器，可参考源码中的 #X64_RestoreFs
' 然后就是 x86 中的平栈返回或者由易子程序返回

其他：

由于本模块并非提供给初级用户使用，因此没有写太详尽的 demo，只提供了一份编写测试时用于测试的 test，参考其代码可获得模块使用方法；

开源协yi：

本模块源代码核心来源于 rewolf-wow64ext，为尊重其劳动成果，沿用其 LGPL 3.0 开源许可证；
你可以将本模块源代码随意用于免费或商业软件；你也可以自由修改源代码，但公开发布应予以保留原作者署名；

关于赞助：

本人近期希望可以有更多时间将近 15 年易语言学习中汇总的各类源代码重新整理优化，全部以开源、高效的易模块形式发布，为易语言略尽绵力；
如果这份源码您用的上并且也给您带来部分利益，我接受任何形式的打赏与赞助（点击下方“ 赏” 按钮选择适合您的方式即可），以便我有更多时间和精力整理余下的源码；
微信/zfb打赏的易友可私信索取我的联系方式，包括但不限于本模块范围之内我们可以互相交流帮助；
当然如果您只希望无偿使用，或者您认为这没什么价值，随手能点个赞，我也倍感欣慰！
enjoy it!

npzs(shier2817) 2019-02-22 于大连

更新日志：

v1.2 - 2019.03.12

添加：添加了一个 X64CallArr 函数，使用数组方式调用 64 位函数，这样就相当于无限参数数量了，应易友 @开始学易语言的需求；
更新：极大优化了 X64Call 的代码，现在的通用调用性能损失几乎可忽略不计，实际上本模块的所有代码都是一句句汇编写出来的，本身比起依赖 VC 编译器自动优化的代码都要效率很多倍；
更新：修正加载本模块后无法使用易语言 “运行” 命令的 BUG，实际还有 CreateProcess API 也一同修复，感谢易友 @scgs3178 发现的问题；

v1.1.1 - 2019.03.03

没有任何功能上的更新，只是内部接口预留了空间，便于派生模块使用，后期我如果发布以本模块为基础的功能模块时，至少要更新到该版本！

v1.1 - 2019.03.01

添加：ntdll 实现的 LoadLibraryEx64/FreeLibrary64 及其 32 位版本，从此开始你的易语言可以随意加载 64 位 DLL 啦（包括 64 位的 kernel32.dll），只要你会调用 ^_^，这应该是革命性的首创吧。(要是有前辈已经公布了算我孤陋寡闻了；64 位函数没多难，只要注意参数类型、堆栈对齐和结构对齐就可以了)
添加：原创的内存 DLL 加载函数，集成在 LoadLibraryEx32/FreeLibrary32 之中，不要高兴的太早，只能加载内存中 32 位的 DLL（不管是字节集还是数据指针均可）；64 位的短期内实现不了了，因为 WOW64 环境切换的 64 位环境实际上除了 ntdll 就没啥了，想手动实现 Peloader 处理 DLL 所有导入库难度太大了；其实意义也不大，能加载本地 64 位 DLL 够用了；该代码参考诸多前辈开源项目，由本人综合而成，与网上流传的诸多版本最大的不同是除了 DLL 存储空间外没有申请任何额外的内存；返回的基址就是标准的 PE 格式，当然没有zc到进程加载列表，所以 API 方式的 GetProcAddress 无法获取函数，只能用本模块提供的 GetProcAddressEx（也就是传递函数哈希值）的方法获取调用函数地址，其实这也是属于隐藏加载 DLL 了；
添加：OpenProcess64/CloseHandle64 及其 32 位版本，用于打开关闭进程句柄；实际上通过进程标识符打开进程句柄时 32/64 位版本是通用的；
添加：ntdll 实现的 GetDefaultHeap64/HeapAlloc64/HeapReAlloc64/HeapFree64/HeapSize64 及其 32 位版本，实话说从堆申请内存而言，64 位意义不大，只是随着 32 位版本一起提供了
添加：ntdll 实现的简化版默认堆申请函数 malloc64/realloc64/free64 及其 32 位版本，省的每次都得获取默认堆句柄了
添加：ntdll 实现的 RtlInitAnsiString64/RtlFreeAnsiString64、RtlInitUnicodeString64/RtlFreeUnicodeString64、RtlAnsiToUnicode64/RtlUnicodeToAnsi64 字符串处理函数及其 32 位版本，虽然这些函数重要程度不高，但较多 NT-API 均需使用，因此模块予以提供；
添加：绝大部分函数模拟 Windwos 机制，在调用失败后会自动设置错误码，以便调用 GetLasterror 函数可以获得错误原因
更新：修正 GetProcAddressEx 系列函数针对转向 DLL 函数地址获取错误的 BUG；
更新：修正 VirtualQueryEx86 函数参数 4 的描述错误（仅仅是描述而已），结构长度应为 28 而不是 24；
更新：优化模块共享机制，作为底层模块，即使再多扩展模块加载本模块也只会共享相同接口，而不会占用更多资源；
更新：优化了部分代码，提升了几个时钟周期的效率（( ╯□╰ )，没办法，本就是底层的东西，效率提升不了多少了）