今天在Sandboxie中运行TM 2009，结果bugreport.exe蹦出来了。调了一下，发现是Sandboxie的实现机制和TM 2009新增的安全模块功能冲突导致的。 Sandboxie中运行的每个进程都会加载SbieDll.dll，这个模块会Inline Hook一堆API。而TM 2009的TSSafeEdit.dat（其实是一个dll）会检测一些API有没有被Inline Hook，一旦发现就试图进行恢复。 但是TSSafeEdit.dat中的代码在恢复Inline Hook时为了能顺利写入，先调用VirtualProtec给目标内存设置了PAGE_READWRITE（0x04）属性，但是恢复结束后并没有设置回原始的PAGE_EXECUTE_READ（0x20）属性。在开启了DEP的系统上，PAGE_READWRITE的区域自然是不可执行的，于是就异常了。 TSSafeEdit.dat用upx压缩过，解开后可以找到如下两处设置属性的代码： .text:100019CD                 push    eax .text:100019CE                 push    4              ; PAGE_READWRITE .text:100019D0                 push    edi .text:100019D1                 push    esi .text:100019D2                 call    dword_1000A168 ; kernel32!VirtualProtec .text:10001CF7                 push    eax .text:10001CF8                 push    4              ; PAGE_READWRITE .text:10001CFA                 push    ebx .text:10001CFB                 push    edi .text:10001CFC                 call    dword_1000A168 ; kernel32!VirtualProtec 把那两个push 4改成push 0x20就可以让TM 2009正常在Sandboxie中运行了。 需要注意，TM 2009运行后会检查TSSafeEdit.dat是否被修改，如果被修改则会试图获取原始文件恢复之。要避免被恢复可以借助Sandboxie的相关机制来进行限制，如禁止SelfUpdate.exe进程运行等。 细心的朋友可能还会有疑问：改成push 0x20不是就等于没改内存属性PAGE_EXECUTE_READ（0x20）么，那么这部分内存仍然是不可写的，后面恢复Inline Hook时不会出异常么？答案是不会。 因为TSSafeEdit.dat恢复Inline Hook时写内存用的是WriteProcessMemory()而不是memcpy()之类直接内存访问的方式。对WriteProcessMemory()这种血腥暴力的API来说，只读内存属性是不影响写入的。换句话说，TSSafeEdit.dat中那两个 VirtualProtec()调用其实是不必要的，全改成nop也一样能正常工作。 QQ 2009和TM 2009的情况相同。