[Tips] maxthon2(遨游2) mxsafe.dll对网页木马的防护以及绕过

maxthon2(遨游2) mxsafe.dll对网页木马的防护以及绕过
-----------------------------------------------------------------------
maxthon2启动的时候装载mxsafe.dll对一些api进行了hook.在浏览器里运行程序,如果这些程序不在其信任列表里面,就会蹦个框,要求允许/禁止.所以,大部分下载木马在启动的时候就被检测到了.

要知道mxsafe hook了哪些api. od maxthon.exe, bp WriteProcessMemory, F9看改了哪些地址.或者启动maxthon.exe,用rooktit unhooker扫下code hooks就知道了.

hook啥 (maxthon.exe v2.0.3.4643, mxsafe.dll v1.0.0.477)
---------------------------
修改ntdll.dll 导出表hook:
[1] ZwCreateProcessEx/ZwCreateProcess // 检测winxp,2003/2000创建进程
[2] ZwWriteVirtualMemory // 为检测代码注入

kernel32.dll iat hook:
[3] ZwCreateProcessEx(xp 2003)/ZwCreateProcess(2000)// 检测winxp,2003/2000创建进程
[4] ZwWriteVirtualMemory // 为检测代码注入

kernel32.dll inline hook:
[5] LoadLibraryExW // 检测LoadLibraryA/W调用
[6] CreateProcessInternalW // 检测CreateProcessA/W调用


咋绕过
------------------------------
要做到偷偷的进城,打枪的不要,就要在shellcode里unhook掉上述的[3],[4],[6].
unhook掉[6]的inline好办,mxsafe.dll只修改了CreateProcessInternalW的头几个字节做relative jmp,改回原始的就行了.
unhook掉[3],[4]在shellcode里要稍微麻烦点,因为内存ntdll.dll映像导出表里面的ZwCreateProcess (Ex),ZwWriteVirtualMemory已经被mxsafe改掉了,所以通过手工解析导出表来获取原始的native api地址,进而恢复iat hook的路就堵上了.但是天无绝人之路嘛,还是有几种办法可以得到真实的地址:
1. 读取原始的ntdll.dll文件,手工解析导出表得到真实地址.
2. 搜索内存ntdll.dll映像的.text段,用特征匹配找到native api的地址.

1方法实现起来麻烦.2方法简单点,需要注意的是一些细节问题:
先看下ntdll.dll里面的ZwCreateProcess(Ex)代码.

win 2003 sp1 ZwCreateProcessEx 0x32
------------------------------------------
7C9512A7      90                NOP
7C9512A8 >    B8 32000000       MOV       EAX,32 // syscall id
7C9512AD      BA 0003FE7F       MOV       EDX,7FFE0300
7C9512B2      FF12              CALL      DWORD PTR DS:[EDX]
7C9512B4      C2 2400           RETN      24

win xpsp2 ZwCreateProcessEx    0x30
------------------------------------------
7C92D74E      90                NOP
7C92D74F      90                NOP
7C92D750      90                NOP
7C92D751      90                NOP
7C92D752      90                NOP
7C92D753      90                NOP
7C92D754 >    B8 30000000       MOV       EAX,30 // syscall id
7C92D759      BA 0003FE7F       MOV       EDX,7FFE0300
7C92D75E      FF12              CALL      DWORD PTR DS:[EDX]
7C92D760      C2 2000           RETN      20

win 2000    ZwCreateProcess
--------------------------------------------
77F88306        8BFF            MOV EDI,EDI
77F88308 >/$    B8 29000000     MOV EAX,29 // syscall id
77F8830D    |.    8D5424 04       LEA EDX,DWORD PTR SS:[ESP+4]
77F88311    |.    CD 2E           INT 2E
77F88313    /.    C2 2000         RETN 20

发现什么了? 同一个ZwCreateProcessEx的syscall id在xp,2000是不一样的,并且2000只有ZwCreateProcess,所以想一个特征通杀2000/xp/2003是不行的.
所以, 在xp要匹配0x000030B8,在2003要匹配0x000032B8,找到真实地址后,再到内存kernel32.dll映像的导入表里搜索 NtCreateProcessEx.(因为xp/2003的CreateProcessA/W不用NtCreateProcess创建进程),然后修复 iat hook.
在2000要匹配0x00029B8,kernel32.dll搜索NtCreateProcess,修复.
NtWriteVirtualMemory的类似,就不多说了.
示例代码就不提供了,有兴趣的,折腾几下就出来了.


咋防护
---------------
ring3是靠不住的,既然shellcode都运行起来了,还不是你hook啥,我unhook啥的体力劳动.要深度防御,还是进ring0吧.


最后
---------------
对于win2003,如果CPU支持DEP,boot.ini里面又是/noexecute=optout,毋须mxsafe.dll劳神,heap spray就挂了.
没测试vista,不过估计UAC也不是吃素的.