2012年11月TP的debugport清零

本文写给想过TP却卡在清零上的盆友，ID暴露了我的水平，所以只介绍方法，原理上一概不知，我接触驱动也不到1个月，本文能带给你的最大收获就是即使你不懂内核，也能过清零。
我介绍的是在XP版本下的开发，之前我使用win7X64，跟着某部视频学就装了xp虚拟机，苦于不会用windbg双机调试，又装了xp双系统，最终是用syser调试的。等终于搞定之后回到win7X64下体验成果时发现根本不用驱动过TP，dnf可以OD随意附加，ce随便查找，od可以下断点，ce也可以写脚本，半个多月白忙活。现在可以回血秒怪，但总出小三，听说这里牛X人脾气都不太好，如果哪位大神来喷，请喷过之后顺便赠送我一下第三方检测原理，您喷的也值，我挨喷也有收获。
先说个过TP最简单的方法，装个64位win7,。
开个玩笑，debugport清零之所以难倒新手，我的经历是网上资料太少，一共就那么几篇帖子，一看日期我就湿了。我跟着学的视频里的方法是bc改0x70，后果不言而喻。
其实TP这么多年来都没啥大的改动，从玩家的体验来说，我觉得是第三方的检测比2年前严格多了，那时可以秒过图，现在就秒掉线了。
目前清零一共有3处，检测2处，还有我就不知道了，因为我只修改这5处就好用。
前两处清零几年没变，我给出2012年11月tessafe.sys的硬编码，以后的人就特征值搜吧。
清零地址1.T+0x5f7f
清零地址2.T+0X2276
第三处我是没有在网上找到资料，会的人都偷着用呢。
清零地址3.T+0x1C47F
之后是2处检测，第一处检测是检测清零1,2代码的，代码修改后重启电脑。开始我不知道啥是CRC，傻傻的把清零1,2直接nop，重启了，函数头c3，又重启了，那时我还分不清蓝屏与重启，以为这个清零是不能动的。其实整个编写驱动过程中我也很少蓝屏，只是无数次重启，终于苦寻到一篇文章说了向64端口写FE的故事，我才发现第一处检测：把清零函数代码从头开始每字节进行一次运算，存在某一地址中，与T中给定值比较，不一样就向64写FE（啥是端口其实我也没整明白）。
检测地址1：T+0x3E3c（函数头）
另一处检测是与清零3成对的，清零3将栈中0弹出到debugport，这句无检测，直接杀死就行。我要说的这处检测是个push，将debugport当前值入栈，之后干啥我就不知道咧，应该是检测是否为0，因为无视这句话后果还是重启。
检测地址2：T+0x1e494
知道是谁在作怪，就好办了。
检测1有一句cmp eax, dword ptr [esi+4]，eax里的值就是校验值，下一句je跳改成jmp就行
当然，正规的还是找到代码头，之后ret。（这个函数无返回值。找到函数尾巴，如果有返回值还要返回一个值）
杀死检测1，清零1,2函数头返回（无返回值）就行。
检测2，push dword [edx],[edx]是debugport值，我们hook为直接压入0.这里的hook要注意先判定edx是否为debugport地址，是就push 0，不是就push [edx]。因为这一句代码还有别的用处，全改为push 0就悲剧了。
最后过清零3，方法类似于检测2，判定若edx为debugport地址，直接抬高堆栈即
add esp，4，否则pop [edx]。
说下debugport地址找法，翻阅各大网页，看到n长代码，不想去学，内核级编程太深奥，就巧妙的借用TesSafe.sys中清零代码，必然有debugport值，我用的是这一句代码
“DebugportEprocess=(ULONG)(*(int*)(*(int*)(Tbase+0x12dd8)-0x48)+0xbc);  ”
Tbase是TesSafe.sys基址。
这个方法找的debugport地址在DNF也就是游戏启动之前（即登陆界面）时是DNFchina的debugport，别搞错了，先启动游戏再加载驱动吧。
什么，你不会找T的基址？！那你可以辍学了，我是直接复制别人的代码找的T基址，你要实在不会，就每次启动游戏手动用KD查吧，悲催的孩子！
这个硬编码在TP人员看到之前一般不会变，要是哪一天加载失败了就再特征码吧。不过我相信那时的你要么不再研究这个了，要么写这个已经不在话下了。