-
-
arm3.78版以后的CC修复方案讨论[讨论]
-
发表于: 2005-5-22 10:46
-
欢迎你加入CC修复方案讨论，本人已经想到了修复方案，绝对是原创的，不过如有雷同，实属巧合！
由于此方案本人还未实行，第一时间想到了就打算公开了，会有不稳定性的可能，如果你采用了带来什么后果，本人一概不负责，也很希望大家能验证一下。
当然在做 CC 的修复前，你必须会脱壳，并修复iat，还原Code节等，否则是空谈！
原理是这样的：
如果你用过arm3.78以后的版本加壳 Nanomites + CopyMemII，你会发现（当然我e文很差，要左碰或撞，碰很久才明白过来）Nanomites 是为软件开发定做的，也就是说一般随手拿来的Notepad.exe已经编译好exe是不能加的，除非你愿意将它特别改造！
Nanomites需要你在要求保护的程序里加入 SecuredSections 宏，那么壳会根据你程序的 SecuredSections 宏扫描整个Code节，将真假的CC做成表放到壳里面。
这里说一下真假CC：
我并没有跟踪到加壳器是如何工作的，猜说一下吧，壳大概会先将SecuredSections 宏里面的跳转做成CC，再遍历一次 Code 节， 将找到的 CC 都随机或全部做到表里（当然先前做出来的CC是不会再改动的），因此，我们可能会用强制遍历CC修复时，遇上原来指令是“mov ecx,esp”或“mov eax,4010CC”，它们都含有CC字节码，查表后它们是“应该修复的”，但我们人脑可以很肯定 say no！这就是真假CC给我们强制修复带来了麻烦，很容易出错修复；实时修复，能准确修复，但会很烦，不知要经过 X 次数点击或重来，漏修的可能性很大，因为脱壳和未脱壳是两回事来的！
那么说，完整CC修复是个不可能的事吗？答案是否定的！但可以说，若然未做，是时辰未到而已！
当然，世上有成千个破解组织和热爱挑战难度的人，或者早就有人成功解决掉了，但我个人不太活跃，孤陋寡闻！
我下面的修复方案有个前提条件，壳不会把真正在程序 SecuredSections 宏 内的 int3 指令做到表里，否则是不安全的修复！
不过，我相信壳不会这么智能，它应该不能分析出SecuredSections 宏内int3是安装哪个异常入口地址的，另外它还要想法还原 int3 的下一条或多条指令，否则如果做到表里，那是个可怕的行为！我个人觉得这个条件不用去担心，如它能这样做，呵呵，这个壳已经很可怕了！
方案：
1.你必须已经做好判断跳转类型及修复的函数（这个我相信不少人已经会做了，事实上在前人破文中早就放出来了，岩唔岩心水就不得而知了，我就自己来一个）。
2.找出 SecuredSections 宏 的位置，将它们记录成表。（arm3.78主程序有64个）
3.做一个指令分析器函数GetPreviousOperateAddress(InputAddr:dowrd ): dword; ，要求能在给出输入地址后，计算出下一条指令的地址，这个我不会，也没资料；我无意间，翻到 luocong 的 OllyMachine API 有这么一条 GetPrevOpAddr address, 1（利用这个，我们可以避开错误的CC修复，也就是假CC修复），不过它的脚本不好写，可能是人“懒”人“赖”的原故，硬着头皮还是值得一用的。
4.查2.出来的表在每个 SecuredSections 宏内，配合指令分析和跳转修复函数 修复 CC!
这个是讨论帖，希望你回贴时，请不要回复无意义的东西，如“支持”，“顶”，“我不会”，“闪人”...等等，如你不明白我说的内容请举，如果你有更好的修复方案或改良方案请大方放出来，我很期代...我很期代有人能做个指令分析器函数，它应该能分析指令的类型，长度。。。
由于此方案本人还未实行，第一时间想到了就打算公开了，会有不稳定性的可能，如果你采用了带来什么后果，本人一概不负责，也很希望大家能验证一下。
当然在做 CC 的修复前，你必须会脱壳，并修复iat，还原Code节等，否则是空谈！
原理是这样的：
如果你用过arm3.78以后的版本加壳 Nanomites + CopyMemII，你会发现（当然我e文很差，要左碰或撞，碰很久才明白过来）Nanomites 是为软件开发定做的，也就是说一般随手拿来的Notepad.exe已经编译好exe是不能加的，除非你愿意将它特别改造！
Nanomites需要你在要求保护的程序里加入 SecuredSections 宏，那么壳会根据你程序的 SecuredSections 宏扫描整个Code节，将真假的CC做成表放到壳里面。
这里说一下真假CC：
我并没有跟踪到加壳器是如何工作的，猜说一下吧，壳大概会先将SecuredSections 宏里面的跳转做成CC，再遍历一次 Code 节， 将找到的 CC 都随机或全部做到表里（当然先前做出来的CC是不会再改动的），因此，我们可能会用强制遍历CC修复时，遇上原来指令是“mov ecx,esp”或“mov eax,4010CC”，它们都含有CC字节码，查表后它们是“应该修复的”，但我们人脑可以很肯定 say no！这就是真假CC给我们强制修复带来了麻烦，很容易出错修复；实时修复，能准确修复，但会很烦，不知要经过 X 次数点击或重来，漏修的可能性很大，因为脱壳和未脱壳是两回事来的！
那么说，完整CC修复是个不可能的事吗？答案是否定的！但可以说，若然未做，是时辰未到而已！
当然，世上有成千个破解组织和热爱挑战难度的人，或者早就有人成功解决掉了，但我个人不太活跃，孤陋寡闻！
我下面的修复方案有个前提条件，壳不会把真正在程序 SecuredSections 宏 内的 int3 指令做到表里，否则是不安全的修复！
不过，我相信壳不会这么智能，它应该不能分析出SecuredSections 宏内int3是安装哪个异常入口地址的，另外它还要想法还原 int3 的下一条或多条指令，否则如果做到表里，那是个可怕的行为！我个人觉得这个条件不用去担心，如它能这样做，呵呵，这个壳已经很可怕了！
方案：
1.你必须已经做好判断跳转类型及修复的函数（这个我相信不少人已经会做了，事实上在前人破文中早就放出来了，岩唔岩心水就不得而知了，我就自己来一个）。
2.找出 SecuredSections 宏 的位置，将它们记录成表。（arm3.78主程序有64个）
3.做一个指令分析器函数GetPreviousOperateAddress(InputAddr:dowrd ): dword; ，要求能在给出输入地址后，计算出下一条指令的地址，这个我不会，也没资料；我无意间，翻到 luocong 的 OllyMachine API 有这么一条 GetPrevOpAddr address, 1（利用这个，我们可以避开错误的CC修复，也就是假CC修复），不过它的脚本不好写，可能是人“懒”人“赖”的原故，硬着头皮还是值得一用的。
4.查2.出来的表在每个 SecuredSections 宏内，配合指令分析和跳转修复函数 修复 CC!
这个是讨论帖，希望你回贴时，请不要回复无意义的东西，如“支持”，“顶”，“我不会”，“闪人”...等等，如你不明白我说的内容请举，如果你有更好的修复方案或改良方案请大方放出来，我很期代...我很期代有人能做个指令分析器函数，它应该能分析指令的类型，长度。。。
[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
arm3.78客户版 已经修复了，如果没有存在修复错误结果如下：
SecureSections总块数：0x0000006C / 2 = 54块（上面帖子写错了） 应该修复的 CC 数量为 ：0x0000095A = 2394（十进制）个 上面 GetPrevOpAddr address, 1 写错了 应该是 GetNextOpAddr address, 1 （用这个才是）  看来此帖可以关闭了，没人愿意发表问题和见解，有请 fly 关了，有劳！ 
|
|
|
|
|
|
烦归烦，总是可以拆的！fly可以关了此帖，反正要做的话工作量不少！
车谈： 主程序脱壳和修CC后不能加壳，因为Key系统完全被破坏，我也不测试了，求祈塞 个 Key 到预定的位置就算了，能加壳了。。。功能全不全就不知了，反正没报警... 修复全部的 CC ，对于每个被加壳的程序都要度身订做一次才能修复，所以就。。。很少人干！我也决定学 fly ，以后见了就闪人..呵呵，保证细胞死亡率不能偏低...
|
