`
tianshibaijia
  • 浏览: 1126669 次
文章分类
社区版块
存档分类
最新评论

关于R3下的自身进程守护

 
阅读更多

一大早的来到图书馆还把我的本本抗来了,就为了写一篇博客。

这个博客其实说来挺愧疚的,原理搞错了,却也实现了预期之外的功能,如题R3下的自身进程守护。

昨天下午和“列宁”交流了一下午,才发现原来我本来的构想就是错误的,我本想挂钩Terminateprocess的函数达到禁止制定进程被结束的,但是意外的把挂钩的原理搞错了,程序倒是写了一堆,就是不能实现功能。把我给急的,后来昨天下午偶遇高人“列宁”,探讨了一下午,我终于搞清楚我的错误在哪里,(其实是被探讨)我原先的构想是修改引入表中Terminateprocess的地址挂钩这个API函数的,我以为引入表是所有程序所公用,但是错了,每个程序有每个程序的引入表,甚至每个动态链接库调用其他函数的时候都有他自己的引入表,所以在本程序修改的引入表只能防止自身的进程使用Terminateprocess的函数结束自身,当然了这个也可以作为自身的进程守护(比如病毒),虽然实在R3的层面下很容易被反HOOK。

于是我又想了一下,如何做到挂钩其他进程API函数的使用?仔细想了想我就想到两种,毕竟是菜鸟嘛,也还没来得及去查阅相关资料。第一,我们可以直接修改动态链接库的Terminateprocess函数的入口地址,自己动手修改之后直接将原动态链接库覆盖。第二,我们可以向目标进程注入,这个我准备试一试,我自己的想法是用SetWindowsHookEx函数直接向目标进程注入我们的修改该进程引入表的代码。呵呵未经验证,菜鸟的个人想法,大牛请不要笑话,发现错误也欢迎直接提出。

下面附上我的代码片段:

除此之外,昨天下午和列宁的一番谈话中我也受教了,关于函数的调用约定,native API一般都是_stdcall,所以在定义函数类型的时候要注意了,最讨厌的地方就是这个错了编译不报错,运行时就会出现如图错误:

下面附上R3下使用NtQueryInformationProcess的用法:

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics