我们知道 创建一条线程 可以有一个参数 这个参数 在不同的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

发表回复

后才能评论