返回信息流标准的做法是
Get/SetThreadContext，可以获取/设置目标线程的任何寄存器。
其内核实现是向目标线程排队一个内核APC，然后这个内核APC
运行在目标线程环境下，通过handle->ethread->ktrap_frame,然后
把相关的context写到这个frame里。
于是，我写了个自己的SetThreadContext，
在内核里直接定位到目标线程，改写它的ktrap_trame。
被日的那个线程，就是test.exe的主线程，里面就是一个while(1)
不停地Get自己的Context并print出来。
上我自己模拟的SetThreadContext，如果试图改写调试寄存器，
test的线程的print显示没有变化。改写其他寄存器，如eip,则能改变test
的线程的执行流程。
如果先用系统的SetThreadContext设置一下目标线程的调试寄存器，后面
再用我模拟的SetThreadContext设置目标线程的调试寄存器，就能成功。
所以，问题是，直接使用自己实现的SetThreadContext，能设置除调试寄存器以外
的其它寄存器，但不能设置调试寄存器，而只要调用一次系统的SetThreadContext，
我自己实现的SetThreadContext就一切正常。为什么呢？
现在只能把系统的NtSetContextThread原封不动的实现一下，看能否正常。
搞了一天，头大。
这是一条镜像帖。来源：北邮人论坛 / security / #20985同步于 2009/1/21
该镜像源已超过 30 天没有更新，可能在源站已被删除。
Security机器人发帖
开个贴吧:直接设置线程的ktrap_frame的调试寄存器的值，有问题
flyingkisser
2009/1/21镜像同步3 回复
订阅后，新回复会通过你的通知中心匿名送达。
3 条回复
基本搞明白了，不管是通过内核APC，还是直接写线程的context，
需要设置线程的DebugActive，才能让Drx寄存器从frame里恢复到context中。
但其它寄存器用不着。
这一块工作，应该是内核线程调度来做的，包括APC的调度。
虽然逆向分析过内核线程调度的大部分函数，但没有看到相关的地方。看来
还是分析的不够仔细。
不管怎样，是一个不错的anti-debug的小技巧。
另外，这个和PEB的BeingDebuged没有关系。
【 在 flyingkisser (齐天大猫) 的大作中提到: 】
: 标准的做法是
: Get/SetThreadContext，可以获取/设置目标线程的任何寄存器。
: 其内核实现是向目标线程排队一个内核APC，然后这个内核APC
: ...................