哈哈 这么好玩啊，MJ真是流氓，以后流氓都用这个方法

我试过了，还找不到好的关闭方案，在PID替换之后，我先另外插了个内核apc到那个mj那个KeDelayExecutionThread线程里，然后掉pspexitthread，总算把顽固线程关了。然后在zwterminate 关闭进程，zwterminate返回成功，用！process命令看，发现EPROCESS还没被替换出链表，但是mj进程里所有线程都被关闭了。F5后，虽然没线程，但是那个命令行窗口依然在.那叫一个汗啊。尝试terminate后调pspprocessdelete，掉完后，eprocess的确也被替换出链表了，但是F5就兰.

引用第24楼powerboot于2008-04-07 14:03发表的  :
不知道这个答案是不是一个让人信服的结果啊

信服的结果就是拿个另外进程的PID,TID替换到MJ的进程里,因为在CALLBACK里只能收到PID和TID之类的信息,即使去查EPROCESS也是错的,总而言之就是欺骗.可惜的是CALLBACK里没把EPROCESS也传进去.

不知道这个答案是不是一个让人信服的结果啊

当然是故意安排了，PspExitThread和PspExitProcess都要走notify,因此只要你用这两条路退出，基本就必然走notify
一个进程当然至少有一个线程，sleep只是把线程切换出去而已

汗，的确是我看错题目了。难怪驱动加载不起。
要过他的call back 不难。Terminate之前：
到pspCidTable表里把把psxx的 eprocess地址拷贝到自己的在pspCidTable的偏移地址，然后用你的PID覆盖psxx eprocess中的PID和 psxx 线程ethread 里头的PID。
然后通过自己的PID zwopenprocess，这时获得句柄其实就是psxx进程的句柄了。这时再 Terminate ，是可以绕过他的call back的，但是依然无法终止进程。唉。因为这个程序实在太强了。sys启动后，notify函数里只判断当前进程及线程的创建是否与psxx PID相同，只要相同不管创建还是终止，直接KeDelayExecutionThread。而psxxxexe在sleep的也不知咋滴就创建了一个线程，不是人为代码创建，系统自己创建的，虽然是自身创建，但由于它在psxx里头，因此自己的线程在notify的时候直接就被自己的驱动直接KeDelayExecutionThread。
所以你在zwterminate哪怕过了notify，也只能关闭ring3 sleeep那个线程。整个进程无法被关闭，因为在等待自己另一个线程从KeDelayExecutionThread中返回。而这个函数不返回。就这样保护了自己的进程。就不知道是故意安排还是歪打正着？？？
 

只要把你那个清了就都清了，，他们都省事了。。。

主要是提供一种想法，而且很多人动不动就清ＣＡＬＬＢＡＣＫ例程，经过我这么一折腾，他再要清我的ＣＡＬＬＢＡＣＫ就没那么容易了．至于２Ｋ同样的处理更简单，不过考虑靠ＭＳ从今年６月以后就放弃ＸＰ了，所以不考虑也罢．

WOW老牛出手了 ：）  膜拜先


方法似乎是先取到所有的notify,然后把他们保存下来，最后都干掉
然后自己注册一个，替他们来执行，所以就可以过滤掉指定的PID了（或者TID~）

但是似乎只能执行在XP下 ，首先2K没有REMOVE那个函数，其次2k上就是一张地址表，而XP后则是CallBackObject了
PS：终于看到WOW牛发出的SYS没有CV了，F5好开心~~~

- - ！不过大家为啥都只盯着可怜的notify不放呢。。。
 

引用第17楼wowocock于2008-04-06 11:27发表的  :
放个测试程序，环境是XPSP2
用法是先加载驱动，然后执行PsNotifyMrgApp.exe选择\.PsNotifyMrgDevice,open handle
Operation Type,选择IOCT_800
Input Size :4  Input Pattern:你进程的PID
点击Execute Transfer,以后你指定的PID就可以避开所有的PROCESS， THREAD CALLBACK的监视，不过其他的调用还是会经过所有的CALLBACK。主要是针对特定进程避开监视而又不影响其他进程的监视。不过也只是个想法而已。

wowo老大的驱动是拿什么编译的,这么大?
他的意思是根本不让你干扰他的routine,必须让它执行...

PsNotifyMrg.zip

类型：

售价：0

大小：50KB

下载：81次

描述：PsNotifyMrg

[下载]

放个测试程序，环境是XPSP2
用法是先加载驱动，然后执行PsNotifyMrgApp.exe选择\\.\PsNotifyMrgDevice,open handle
Operation Type,选择IOCT_800
Input Size :4  Input Pattern:你进程的PID
点击Execute Transfer,以后你指定的PID就可以避开所有的PROCESS， THREAD CALLBACK的监视，不过其他的调用还是会经过所有的CALLBACK。主要是针对特定进程避开监视而又不影响其他进程的监视。不过也只是个想法而已。

给点提示....

本身这就是个保护挑战，恶意不恶意，不知道从哪里说起
摘链无疑不现实，因为如果这是个恶意程序，那么它可能根本不用这种一眼就能出来的钩子，试问你怎么摘？

至于什么删除程序，更是可笑，这是进程保护挑战，与文件何干？

说实话，这个程序本身就存在类似于恶意软件的行为，所以，如果非要用某种通用的方法去实现针对某种特定的方法的确意义不大。

不管摘练是否犯规，但是这是一个很通用的方法，基本上你的驱动只要没有根本性的机制改变，也可以被杀掉。

如果说有更通用的方法，那么就是通过其他系统引导本身硬盘，删除程序而已。
MoveFileEx 或者类似的方法可以轻松搞定，呵呵。

都是标准函数，有啥不能加载的，仔细看好了，你要先手动加载驱动！偷懒没写加载代码，什么残废版，说话小心点

日啊，xpsp2虚拟机，sys无法加载，拜托mj你下次别弄残废版来消遣我等啊

越来越发现内核不好玩了；—<

EP_X0FF

楼上的两个办法都算是作弊

1.hook kexxx,实际是干扰了保护驱动程序本身的工作流程，试想，如果我不用kedelay呢？这只能算只针对性的攻击


2.给DEVICE发请求改PID，是修改了保护驱动本身的数据，试想，我换一个IOCTL，或者干脆用随机的呢？

不知道  Hook KeDelayExecutionThread 这个算不算作弊。