前言:
这其实是一个困扰我许久的一个奇怪想法而引出的.
期初是因为在封装x64远程hook时希望64位进程可以向32位进程远程线程传递8字节参数.
当时搜遍互联网似乎也没有发现关于此类问题的讨论或解决方案的产生.
大家似乎都默认了这件事情的合理性 是的它看上去的确是那么的合理.
立案:
我们知道 创建一条线程 可以有一个参数 这个参数 在不同的bit环境 拥有不同的长度
在x86 API中 它是4字节的,在x64 API中 它是8字节的,这看上去很合理本身它也没有什么问题
也就是说:
32位进程之间 创建线程 参数大小保持在4字节
64位进程之间 创建线程 参数大小保持在8字节
32位进程-->64位进程 创建线程 时 由于wow64虚拟环境的存在 这个时候可以分为两种情况了
1:32位进程使用x86API创建线程 由于bit受限 只能传递4字节参数
2:32位进程使用x64API创建线程 可以传递8字节参数
以上没有什么问题很合理合法 那么当:
64位进程-->32位进程 创建线程 时 似乎出现了一点问题,合法的8字节被高位截肢,而且显得那么的平均
也就是说 使用x64API创建线程 接收方是32位进程时 线程参数只能收到下半身 上半身被截去了
喜欢破案的兄弟免不了会在线程执行入口下断寻找线索
可惜 不论从寄存器还是栈中 似乎都找不到线索 这截上半身消失的无影无踪
为此本案只能暂时搁置封存,直到某一天再次翻阅本案产生新的感悟
我们知道 创建一条线程 由内核态转入应用层 x86 与 x64 进入R3层的第一条指令位置是不同的
而32位进程由于其具备得天独厚的wow64天赋神通,同时具备以上天赋
由此我们在 x64的 ntdll.LdrInitializeThunk 函数下断,果不其然,这截消失的上半身在栈中存在遗留
当它经过wow64环境的切换 和 线程环境的初始 后 这截上半身又会消失的无影无踪
破案:
为了让这截上半身不丢失,为此不得不构造一个钩子,勾住 x64.ntdll.LdrInitializeThunk
并且把这截上半身复制到另外一处不会丢失的栈RVA中
这样就能在转入 线程执行入口 后 栈中依然存留有这截上半身的信息
比如这样:
为了让这截上半身能找得到原来的主人
我们还需要在 "线程执行入口"的第一句代码执行类似这样的内联汇编
' push eax
' push edi
' push esi
' mov edi,ebp
' xor esi,esi
' xor eax,eax _循环1
' mov eax,dword ptr ss:[edi]
' test eax,eax
' jz _为0跳
' add esi,1
' mov edi,eax
' jmp _循环1
' _为0跳
' mov edi,ebp
' sub esi,2
' test esi,esi _循环2
' jz _为0跳2
' mov edi,dword ptr ss:[edi]
' sub esi,1
' jmp _循环2
' mov eax,[edi+0x14] _为0跳2
' mov [ebp+0xc],eax
' pop esi
' pop edi
' pop eax
题外:
看上去这好像并没有多少用处,是的看上去的确如此
但是在某些时候,这又显得无比重要
附件:含 X64_安装线程长参数钩子.e
以及
wow64_hook_3.0.2模块源码.e 的一次修复性更新
' 2023/3/11 模块源码3.02 修正
' 1:修正 X64_劫持环境ShellCode 的遗漏对齐问题,该问题可能导致 绑定线程情况下调用函数时偶发性导致目标进程崩溃
' 2:修正了已知BUG
(回复可见)
