作 者: bzhkl
以前想检测一个被隐藏的进程 后来用暴力枚举的方法解决了 但是HOOK SwapContext没有看到有完整的代码 所以搜集了点网上有用的模块 自己整合实现了下 确定支持XP3, XP2没测试 应该也能支持
附完整工程代码
难点:是得到SwapContext地址 还有一些细节问题~
原理:KiSwapContext调用SwapContext时候 ESI存放的是要换进线程的上下文 EDI存放的是要换出线程的上下文 然后截获ESI 即换进的ETHREAD 得到相应的EPROCESS 然后搜集
缺点:对系统性能影响非常大,因为系统线程调度很频繁, wrk的KiSwapContext用汇编写的就能体现出来对效率的要求高~.
另外有个有趣的问题
KiSwapContext 是fastcall调用方式 就是通过ECX EDX传 多出的按STDCALL传
WRK 是这样注释的
; BOOLEAN
; KiSwapContext (
; IN PKTHREAD OldThread
; IN PKTHREAD NewThread
; )
但是看下 WRK中的代码
mov edi, ecx ; set old thread address
mov esi, edx ; set next thread address
movzx ecx, byte ptr [edi].ThWaitirql ; set APC interrupt bypass disable
call SwapContext ; swap context
发现的确是两个参数
用WINDBG看
80545975 8bf1 mov esi,ecx
80545977 8bbb24010000 mov edi,dword ptr [ebx+124h]
8054597d 89b324010000 mov dword ptr [ebx+124h],esi
80545983 8a4f58 mov cl,byte ptr [edi+58h]
80545986 e8f5000000 call nt!SwapContext (80545a80)
发现KiSwapContext 是一个参数, esi是要换进的线程上下文 是通过ECX (第一个参数得到) edi 则不是
所以结论 KiSwapContext的参数现在是一个了,也许我WRK没更新 老版本。。
WRK KiSwapContext 代码
cPublicFastCall KiSwapContext, 2
.fpo (0, 0, 0, 4, 1, 0)
;
; N.B. The following registers MUST be saved such that ebp is saved last.
; This is done so the debugger can find the saved ebp for a thread
; that is not currently in the running state.
;
sub esp, 4*4
mov [esp+12], ebx ; save registers
mov [esp+8], esi ;
mov [esp+4], edi ;
mov [esp+0], ebp ;
mov ebx, PCR[PcSelfPcr] ; set address of PCR
mov edi, ecx ; set old thread address
mov esi, edx ; set next thread address
movzx ecx, byte ptr [edi].ThWaitirql ; set APC interrupt bypass disable
call SwapContext ; swap context
mov ebp, [esp+0] ; restore registers
mov edi, [esp+4] ;
mov esi, [esp+8] ;
mov ebx, [esp+12] ;
add esp, 4*4 ;
fstRET KiSwapContext ;
fstENDP KiSwapContext
windbg得到的 KiSwapContext 代码
lkd> uf KiSwapContext
nt!KiSwapContext:
8054595c 83ec10 sub esp,10h
8054595f 895c240c mov dword ptr [esp+0Ch],ebx
80545963 89742408 mov dword ptr [esp+8],esi
80545967 897c2404 mov dword ptr [esp+4],edi
8054596b 892c24 mov dword ptr [esp],ebp
8054596e 648b1d1c000000 mov ebx,dword ptr fs:[1Ch]
80545975 8bf1 mov esi,ecx
80545977 8bbb24010000 mov edi,dword ptr [ebx+124h]
8054597d 89b324010000 mov dword ptr [ebx+124h],esi
80545983 8a4f58 mov cl,byte ptr [edi+58h]
80545986 e8f5000000 call nt!SwapContext (80545a80)
8054598b 8b2c24 mov ebp,dword ptr [esp]
8054598e 8b7c2404 mov edi,dword ptr [esp+4]
80545992 8b742408 mov esi,dword ptr [esp+8]
80545996 8b5c240c mov ebx,dword ptr [esp+0Ch]
8054599a 83c410 add esp,10h
8054599d c3 ret
驱动运行后的效果是:
搜集到的进程是
0x81FE7768 svchost.exe
0x81EC6478 alg.exe
0x81F5E990 svchost.exe
0x81FE83E0 DrvLoader.exe
0x81CA7020 taskmgr.exe
0x81595D70 VMwareService.e
0x815C6608 VMwareTray.exe
0x815D9C08 svchost.exe
0x8159C528 ctfmon.exe
0x8158EB60 VisualTaskTips.
0x815E5DA0 winlogon.exe
0x81E96418 DrvLoader.exe
0x815F8BD8 lsass.exe
0x81FE5020 MSDEV.EXE
0x81EC0B28 mdm.exe
0x81EE0500 explorer.exe
0x81F13020 MSDEV.EXE
0x815523A8 DBGVIEW.EXE
0x81F74020 csrss.exe
0x821507C0 System
0x82009830 VMwareUser.exe
0x81F66DA0 services.exe
0x81F07B88 svchost.exe
搜集到的进程肯定是不全的 因为有的进程在休息 没有线程调度发生 也就没有搜集到= =