嘿嘿嘿 我来枚举部分86后的内核爱好者们： http://hi.baidu.com/mj0011 http://hi.baidu.com/killvxk http://hi.baidu.com/dummy24 http://hi.baidu.com/sudami http://hi.baidu.com/aegisys http://hi.baidu.com/breakinglove_ http://hi.baidu.com/iceboy_ http://hi.baidu.com/sysnap 等等等等

不恐怖~~ 已经实现了

呵呵，支持一把~ 这个是楼主的博客吧： http://hi.baidu.com/nightxie 楼主和Sudami同学有几分神似...

感谢张老师！张老师的做法叫“迂回”有时候真觉得写Hook引擎是一件没什么意义的事情钩子有风险 Hook需谨慎，“自动化”或者“干扰引擎”的想法都是比较疯狂的...

离 Alex 的水平还差十万八千里...  >_<我提出讨论的是一个大的问题，我先抛块砖。（恕我不会过多谈论代码，我只发两张截图）首先，我并不关心 Hook 的细节。nightxie 所说的“短跳+长跳”法，或者是常见的前 5 字节 Inline Hook，再或者是微点爱用的 Call Hook 都只是“论术”，OK 我们不回避，先“论术”：在我的 Hook 引擎DEMO 里可以自动选择 Hook 点（默认是 Call Hook），上述的都支持：/* ff15 Call Hook *//* 短跳 + 长跳 Hook */但是，这些伎俩有一个使用前提，就是如何 Patch 才是安全的？ 这是“论道”： 问题可以分两类：01. 你在 ...

有关于多核下安全地 N 字节 Patch 内核的问题。我们都知道 Patch 是有风险的，可有时候我们又不得不冒着风险。我想知道究竟这个风险有多大，又分为哪些情况，它们可不可以尽量避免，如何避免。请您谈谈您对此问题的理解，越深刻越好，越详细越好，谢谢您。为了不涉及公司的代码利益，我自主编写了我的 Patch 引擎，做法如下图（恕我不过多涉及细节）：简言之 即其它核空转（DISPATCH_LEVEL），本核操作（DISPATCH_LEVEL），本核完成（PASSIVE_LEVEL），其它核继续工作。请您参考讨论。

有些路，看似近实则远； 有些路，看似远实则近。 有些代码，看似浅显但实则需要逐字(节)调试； 有些书籍，看似无用但实则需要逐句品味。 祝 dbgsun 找个好工作，在工作中不断积累，不断进步。

回手语： 实在不好意思，我刚到北京不久，这两天在租房子(焦头烂额地 T_T)，又先垫付了XCON2008两个人的钱，钱不够了... >_<

马甲同学的意思就是在调试器里将Call之前的压栈参数手工由 1 改为 0。 楼主请看看我整理的这篇文章：《Nt vs. Zw - Clearing Confusion on the Native API》（http://advdbg.org/dfstore/zip/Nt%20vs.%20Zw%20-%20Clearing%20Confusion%20on%20the%20Native%20API.pdf） 里面有这么一段： The NtXxxx version of the native system service is the name of the function itself. Thus, when a Kernel Mode component calls ...

XCON 还“玩花样”呢 呵呵 连开四天会... WOW 周董 会准假吗？ http://www.xkungfoo.org/