|
[原创]开原自写磁盘还原
果然A了很多代码....不过这种还原太容易被穿透了. |
|
|
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
你说的几点,第一点明显要拦截到的几率太小,也就是基本可以忽略. 第二点特殊位置的扫描其实无所谓,全段扫描都行,但是没用.有卯就有盾,反过来也是 ....为什么?你看NP的CRC HS的CRC TP的CRC就知道了. 第三白名单.既然是白名单 就有一个名单列表.曾几何时是过游戏保护都是往白名单里加调试器..现在很多游戏保护都把白名单当做一份参考而已..自从CSRSS变成外挂的跳板后... 第四.越是公开 不一定越容易被针对..为什么?比如输入法注入..请问有几个游戏保护能拦截..??? 第五 对抗越底越好?明显不是..别忘了X64你只能用OBJCALLBACK从驱动层保护游戏进程.游戏保护驱动也是爱莫能助.....当然游戏要是把X64抛弃了,我也就没话说了. 你所说的是很久以前的老思想了.....顺便提下,在底层耍流氓最厉害的,曾经是NP....就是耍的太狠了,结果NEXON这个大单就飞了...现在游戏公司很多是把数据挖掘用到反外挂上,,其强悍,让人忘而却步... 骚年....重载内核吧.又或者强行切换吧.调试而已.又不是要你放出去给千千万万用户. |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
明显就是不合理检查,比如游戏加速器.杀毒软件.甚至其他的游戏保护.都有可能在游戏进程内申请内存...而进入的模块有可能在内存块申请一个内存来使用...你说的方法太肤浅了.游戏保护是保护游戏,不是毁了游戏...现在游戏保护的出错率都是控制在千分之一的机率...如果按照你的思路....赶脚十分之一的出错率都算低了.. 建议你还是先把基础弄懂吧.....游戏保护考虑的其实第一个不是保护游戏....而是稳定.兼容,然后是保护, |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
哇哈哈.模块加载出来最多几M ,跟游戏资源比起来简直是小巫见大巫.要监视,代价太大...再说..跑一年.正常三月就跑路...你还一年...骚年...意识不行啊. |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
这要看你怎么写了.....内存映射.抹PE头.基本上模块就是一内存块了. 被逮住小...太小了....比中五百万还难.特别是计算机CPU配置越高,几率越小.现在每秒NNNN亿次的浮点运算不是浪的虚名的.代码运行速度越快,几率越小...不信你可以试下..检查那太操多余的心了..... |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
定时检查很看到啥?我又不是平凡的去调用函数去读.注入模块完就用指针操作.调试器的话.也是瞬间完成.这赶脚程序员是要有中五百万的心才这样搞.... 你下咯...看谁死的比较快.....下内存断就得HOOK 1号中断...瞬间工程量倍增...吃力不讨好. |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
根本没可能,你在内核写个线程循环SLEEP(10)试下....不管你是什么CPU 瞬间让你90%.这程度,别说开游戏了.你开个网页都开不起. HOOK来HOOK去没啥意思啊...再说X64 HOOK不起了 重载吧.还有重载是绝对不会被杀的.为什么.....因为....卡巴斯基等等一票杀毒软件都重载内核了. |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
DeAttach 完我再断链...从KiAttachProcess到DeAttach 到我断链,整个过程就几毫秒的时间..怎么跟踪?别说跟踪 你连发现都发现不了,除非你想把用户机器卡死. |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
根本就预知不了,除非他想系统卡死.切换过程那么快..而且你切换完后直接把ReadyListHead清了不就可以了...检查这个就类似伸手去打人家屁股 再摸自己的脸一样. 读取内存->附加到进程上->拷贝读取->抹除ReadyListHead->返回 整个过程是以毫秒计算的.他要怎么检查? |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
不安全.为什么?因为别忘了用户的机器上有各种杀毒,然手输入法什么的,系统消息机制等等,检查这个太过危险,稍不小心就会引发误杀. 而且你切换完后直接把ReadyListHead清了不就可以了...检查这个就类似伸手去打人家屁股 再摸自己的脸一样 |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
重载足够对付现有的安全保护软件了.个人感觉对ReadyListHead的担心完全是瞎操心. http://bbs.pediy.com/showthread.php?p=413757 |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
我都说了...这些其实都是操作很快的事情,他进程线程本身切换都会触发这些东西,稍微有点脑子的程序员都不敢在这地方做检测,,,,再说你就不能用重载?重载下什么都OK了.重新确定下函数的位置 就直接调用了...后面拍拍屁股什么事都没. |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
我在帖子里已经说了...就是一个保存SavedApcState的保存跟设置啊,关键是这个怎么会留下痕迹?再者切换进程到目标进程系统SYSTEM也有可能会发生切换切换啊.这样的话检查这个是非常不明智的.而且也不是切换以后SavedApcState就会发生改变.别忘了.SavedApcState不一样他是会恢复回去的,退1W步说,这个切换过程速度极快.如果想要能检测到.就要有心里准备把系统卡死... 个人感觉你有点杞人忧天...... |
|
一些关于R0读写进程内存的问题(APC?附加?换出?)欢迎拍砖
nt!KeStackAttachProcess: 804f8802 8bff mov edi,edi 804f8804 55 push ebp 804f8805 8bec mov ebp,esp 804f8807 56 push esi 804f8808 57 push edi 804f8809 64a124010000 mov eax,fs:[00000124]//currentThread 804f880f 8bf0 mov esi,eax 804f8811 64a194090000 mov eax,fs:[00000994]//_FX_SAVE_AREA unknown param ;不过可以通过下面KeBugCheckEx 分析出来 应该是地址空间, 而且bugCode是5.... 804f8817 85c0 test eax,eax 804f8819 741c jz nt!KeStackAttachProcess+0x35 (804f8837) nt!KeStackAttachProcess+0x19://BSOD 804f881b 64a194090000 mov eax,fs:[00000994] 804f8821 50 push eax 804f8822 0fb68665010000 movzx eax,byte ptr [esi+0x165] 804f8829 50 push eax 804f882a ff7644 push dword ptr [esi+0x44] 804f882d ff7508 push dword ptr [ebp+0x8] 804f8830 6a05 push 0x5 804f8832 e89d120000 call nt!KeBugCheckEx (804f9ad4) nt!KeStackAttachProcess+0x35: 804f8837 8b7d08 mov edi,[ebp+0x8]//参数 目标进程KPEB 804f883a 397e44 cmp [esi+0x44],edi//目标进程与当前进程比较 804f883d 750c jnz nt!KeStackAttachProcess+0x49 (804f884b) nt!KeStackAttachProcess+0x3d://相等 804f883f 8b450c mov eax,[ebp+0xc]//输出参数 804f8842 c7401001000000 mov dword ptr [eax+0x10],0x1//将APCstate->KPEB设为1 804f8849 eb39 jmp nt!KeStackAttachProcess+0x82 (804f8884) nt!KeStackAttachProcess+0x49://不相等 804f884b ff1514874d80 call dword ptr [nt!_imp__KeRaiseIrqlToDpcLevel (804d8714)]//提高到DPC 804f8851 80be6501000000 cmp byte ptr [esi+0x165],0x0//ApcStateIndex?=OriginalApcEnvironment 当前线程是否处于挂接状态 804f8858 884508 mov [ebp+0x8],al//...竟然用函数参数空间来放IRQL 804f885b 740f jz nt!KeStackAttachProcess+0x6a (804f886c) nt!KeStackAttachProcess+0x5b://不等 804f885d ff750c push dword ptr [ebp+0xc] 804f8860 ff7508 push dword ptr [ebp+0x8] 804f8863 57 push edi 804f8864 56 push esi 804f8865 e898fdffff call nt!KiAttachProcess (804f8602) 804f886a eb18 jmp nt!KeStackAttachProcess+0x82 (804f8884) nt!KeStackAttachProcess+0x6a://相等 804f886c 8d864c010000 lea eax,[esi+0x14c]//用curthread->saveApcstate进程不处于挂接状态, 需要将存下来以便恢复时候还原,你可能会问为什么上面不用saveState,原因是windows内核中线程只有两个ApcState来使用, 一个存储当前的,一个用来存储原来的,当当前进程已经是挂接状态时,其saveApc已经被使用 所以需要提供一个apcstate来存储, 至于这个apcstate是否被用来存储当前的apcstate还是存储saveapc中的就要看 KiAttachProcess 怎么处理了. 804f8872 50 push eax 804f8873 ff7508 push dword ptr [ebp+0x8] 804f8876 57 push edi 804f8877 56 push esi 804f8878 e885fdffff call nt!KiAttachProcess (804f8602) 804f887d 8b450c mov eax,[ebp+0xc] 804f8880 83601000 and dword ptr [eax+0x10],0x0//返回值里设为0 nt!KeStackAttachProcess+0x82: 804f8884 5f pop edi 804f8885 5e pop esi 804f8886 5d pop ebp 804f8887 c20800 ret 0x8 这会留下什么痕迹啊....求解释....KeStackAttachProcess主要的核心功能只是安全的切换CR3啊 除非他把缺页给干了....那我就无奈了.真是高端的黑.... |
操作理由
RANk
{{ user_info.golds == '' ? 0 : user_info.golds }}
雪币
{{ experience }}
课程经验
{{ score }}
学习收益
{{study_duration_fmt}}
学习时长
基本信息
荣誉称号:
{{ honorary_title }}
能力排名:
No.{{ rank_num }}
等 级:
LV{{ rank_lv-100 }}
活跃值:
在线值:
浏览人数:{{ visits }}
最近活跃:{{ last_active_time }}
注册时间:{{ user_info.create_date_jsonfmt }}
勋章
兑换勋章
证书
证书查询 >
能力值