360ini.dll注⼊explorer技术分析

前两天看了⽕绒安全实验室写的⼀篇分析360安全卫⼠极速版“诱导式”推⼴的⽂章，⾥⾯提到了⼀个下载安装模块360ini.dll会注⼊Windows资源管理器explorer.exe进程，利⽤系统进程下载360安装包，如下图所⽰。不过⽂章中仅仅只提到了360ini.dll模块会区分32位和64位的explorer进程进⾏注⼊，对于核⼼的注⼊技术细节没有再进⼀步深⼊，因此这篇⽂章尝试通过动静态等⽅式分析360选择的注⼊explorer的技术⽅式。

原⽂在这⾥：
360安全卫⼠极速版“诱导式”推⼴ 静默安装且对抗安全软件(https://zhuanlan.zhihu.com/p/576041265)

先说结论：

还是利⽤NtSuspendThread、NtSetContextThread、NtResumeThread等组合函数劫持 explorer负责消息处理的UI线程执⾏流，不过在shellcode执⾏结束后会将控制权返还给 explorer。

⽕绒已经分析出了x86、x64注⼊的核⼼函数，参数为⽬标进程pid。

跟进x64的函数看⼀下，⾸先是⼀堆栈上赋值操作，推测应该是⽤了编译时字符串混淆。这⼀⼤段数据猜测是后续⽤于注⼊的shellcode。

随后调⽤openprocess、openthread函数打开⽬标线程。

选择⽬标线程的时候则是利⽤GetThreadTimes函数获取线程创建时间，返回最早创建的线程tid。

之所以选择该线程可能是因为⼤部分时候都是处于WaitMessage等待事件消息的状态。

获取⽬标线程pid后两次调⽤常规函数跨进程申请内存、写内存。第⼀次写注⼊dll的路径，第⼆次写加载dll的shellcode1。

动态调试可以看到申请了地址0x3a20000⼤⼩64K的读写内存。

并向其中写⼊了注⼊dll的路径。

第二次申请了地址为0x2b2000⼤⼩64K的可执⾏内存。

向其中写⼊加载dll的shellcode1。

写完dll路径和shellcode1后，进⼊sub_10003D50核⼼注⼊函数。⾸先挂起⽬标线程、获取⽬标线程的寄存器等上下⽂。随后继续申请内存写shellcode2。最后在改写完 shellcode2和寄存器上下⽂之后设置线程将要执⾏的上下⽂，恢复⽬标线程。

下图可看到申请的shellcode2地址为0x3a30000，功能为创建到0x2b2000的shellcode1的线程。

这⾥可以看到原始的线程上下⽂EIP为0x773F932A指向user32.dll空间，将其修改为
0x3A30000即shellcode2的地址。

最后⼀步设置⽬标线程的上下⽂，恢复线程即完成x64的整个注⼊explorer进程操作。

最后看下两段shellcode，shellcode2也就是劫持了原始执⾏流的shellcode调⽤了
CreateThread函数，⽬标地址为shellcode1，参数为dll路径。

并在创建完成后返回到原始执⾏流也就是user32.dll空间下的0x773F932A地址。

shellcode1则直接调⽤LoadLibraryW在explorer中加载dll。

到这x64注⼊explorer进程的流程基本就结束了。下载的安装包证据如图。

不过最后还有⼀个疑点，shellcode2的地址申请的是读写权限的内存，不知道为啥执⾏的时候内存就变成读写可执⾏的了。这⼀点很疑惑，有没有⼤佬知道为啥的。

360ini.dll本⾝有反调试⼿段，如果后续想要动态调试的话需要patch或者动态过掉两个 TLS回调函数，并且在dllmain中过掉这两个反调试函数。

360ini.dll为了阻碍静态分析，系统api⼤部分都是在dll加载时动态获取动态调⽤的，单纯
⽤ida很难分析，并且某些关键api函数还利⽤了类似于wrapper层去调⽤ntdll的系统调
⽤。不过好在静态代码还能看，没有上花⾥胡哨的混淆或者壳之类的。

sha256:f3690fae9bec82693a771f5f5839239ca18f90624a6aef631dcd0f19820eb38a