1. 组织代码同行评审 2. App Verifier (Driver Verifier) 审查 3. 既然能复现，最不济就挨个毙功能 + 毙代码，总能“毙”出来的。

呃.. 比较山寨，不建议在产品级代码里这么写，比如 Attach 的时候是否获取了 RundownProtect 等？ 呃.. 算了 never mind..

我用过。 新接口的第一参数是 _CodeInfo，上述特性在 features 域。 distorm_decompose64/32 和 distorm_decode64/32 等的区别之一在于 decode_internal 的调用方法，也就是新参数 supportOldIntr。详细的解释 ( backward compatibility ) 在代码里有。

这个不太难做。从起点开始反汇编，分析时记录所有转移指令，结合基本块形成图结构。 distorm3 标榜自己具有“所谓的” Basic Flow Control analysis support 能力，看实现也就是标记 / 提示 (终止于) 所有的 flow control instructions，如下： #define DF_STOP_ON_CALL 8 /* The decoder will stop and return to the caller when the instruction 'RET' (near and far) was decoded. */ #define DF_STOP_ON_RET 0x10 /* The decoder will stop ...

MmProbeAndLockPages 一下。 另外建议把 mov 改成 InterlockedExchange / InterlockedExchangePointer 的 xchg。

LZ 群里问完这里问，还注册小马甲..

嗯！ 要么借助内核或本地内核调试，要么借助带驱动的工具，如 Process Explorer、Handle(http://technet.microsoft.com/zh-cn/bb896655)、HandleMon(http://driverentry.com/resources/handlemon.htm)等。

Thomson 同学应该和边超同学是一个部门的 哈

呵呵，我还是觉得这个问题没什么。写驱动的人应该要很清楚自己发布驱动的二进制细节特征，从 Dump 的文件版本信息必须能唯一定位到自己的某个 Tag。再 IDA 兑一下那个 Tag 的 Free Build 版，也就几分钟的事情嘛。 另外就是 ls 同学的驱动应该不是对公众发布的 ( FXD.SYS )。某些众矢之的的公司驱动发出来，几天之内就可以被木马作者们逆成源码。到时被点杀会很惨的。

这很正常啊。如果在 release 版里还能 ?? 出变量，那就信息泄露大了。WDK 的优化还算好，不然连函数都给优化内联了才叫抓狂。 多数公司会编译完加签名，会导致偏移再次错位，加壳 / VM 的则更悲剧。我远程用户的时候，往往得 Local Debug 等一点点分析我的变量，这时，留一些“不经意”的定位“入口”（不违反信息保密 / 被攻击者利用 Patch 的前提下）会帮上大忙。 QQ 远程用户时，无法调试驱动。我给逼的只得写一堆栈回朔封装，内存打印封装，往驱动里整，给用户替换，定位问题。LZ 看看 dump 啥的，已经很幸福了呢。