首页
社区
课程
招聘
[转帖]遇见这样变态的加密方法怎么办?以后不是要下岗了?
发表于: 2007-11-9 23:36 3773

[转帖]遇见这样变态的加密方法怎么办?以后不是要下岗了?

2007-11-9 23:36
3773
扭曲变换加密(目前防止软件被破解最好的方法)
755K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6h3S2S2j5$3E0W2M7W2)9J5k6h3y4G2L8g2)9J5k6h3y4F1i4K6u0r3 2007-11-6 1:53:25 黑客防线

一,一般来讲,加密就是加壳
我们经常考虑,一个可执行文件,怎么样加密才能安全呢?

一般用的手段,是加壳。加壳工具的工作原理,就是把可执行文件的代码与数据都进行加密变换,作为数据存放。生成的目标文件入口代码是加壳软件准备好的防跟踪代码。经过漫长的防跟踪代码后,会把原始可执行文件的代码与数据段恢复,然后跳转到原来的入口处,继续运行。这样做的缺点是,不管你的加密多强,防跟踪代码多牛,只要一运行,在内存中就全部恢复了。只要把内存映象dump下来,反汇编一下,就清清楚楚了。甚至有工具可以直接把dump下来的内存映象存为可执行文件。这样加密就彻底失败了。
简单加壳是不安全的,这大家都知道了。我们一般把上述简单的加壳方式叫“压缩壳”。所以现在的加壳软件都在上述“压缩壳”的基础上,多做了一些工作,比如:
* 防止内存被 dump 。这实际上是不可能做到的。因为Windows操作系统就不是一个安全系统,你怎么可能做到内存不被dump呢?曾有一个壳,我用了多种方法dump都不成功。但最后还是找到了一个方法成功dump了。我这才惊叹dump原来有这么多种方法,真是防不胜防。
* 修改文件入口代码。因为一般软件都是用常用的几种编译器编译生成的。如果加壳软件知道你是用什么编译器编的(这很容易),把入口代码破坏掉,用另外一段功能类似的代码替换它。这样dump下来的代码就比较难找到正确的入口,直接被存为一个EXE的可能性就小多了。但还是会被反汇编的。
* 还有一些加壳软件,支持对一个或几个重点函数加密。甚至使用了虚拟机。但他们都只能重点加密少数几个函数,不可能把所有函数都加密。而且对这个函数还有很多要求。这可以想象。如果用汇编写一个函数,不加ret它可能连函数结束地址都找不到,怎么可能加密呢
******
尽管加壳软件可以使用以上多种技术防止被跟踪,分析,还原,但我认为,它们仍然没没摆脱“壳”的这个中心思想。以上的这些技术不过是在“壳”的大前提下所做的一些小的插曲。它仍然是不安全的
二,扭曲编译的思想
做个比喻。加壳保护就好比是你桌上有宝贝,为了保护它,你在屋外围了一圈铁丝网。只要有人突破了这道铁丝网,进入你的屋子,一眼就看到了桌上的宝贝。这当然不安全。
重点函数加密的思想,就好比是,我屋外围了一圈铁丝网,我还把宝贝放进了保险箱里。如果有人突破了铁丝网,进入屋子,一眼就看到了保险箱。虽然保险箱不会被轻易打开,但他如果把保险箱搬走,慢慢分析呢?这也不够安全。
最安全的,就是进了屋子,却什么也找不着。没有目标,这才是最让人头疼的。
现在的编译器,都是追求生成高效率的运行代码。这些代码的模式基本一成不变。有经验的程序员看反汇编代码简单跟看源码一样,毫无秘密可言。如果我们有一个编译器,它的编译目标不是为了高效,而是为了防止被读懂,那该多好啊!我有C++源码,我能看懂。一旦编译,谁也别想通过反汇编看懂我想做什么,或者很难。遗憾的是,这样的编译器还没有。
如果我们自己编一个这样的编译器呢?不现实。工作量太大了。即使是找一个开源的C++编译器来改工作量也不得了。
直接做一个会加密的编译器行不通。而一旦编译连接生成EXE后,就只能加壳了。难道就没有办法了吗?我想出一个主意,就是加密编译的中间文件OBJ,输出ASM文件,用ML编译成OBJ,然后再link连接!
这个方法有几个好处:
* OBJ文件格式相对简单。不象处理C++源文件那么工作量大。* OBJ文件中保留了很多源文件的信息,比如符号名,代码与数据,标号等等。方便加密。这些信息很多在LINK的过程中被丢掉了。所以LINK为EXE后再处理就极不方便了。* 这是一个全新的思想!对代码的加密已经不限于加壳,而是加密每一个函数,每一条指令。再也没有一目了然的汇编了。* 可以很容易设定加密的强度。可以根据需要,对一部分代码轻量级加密,而对另一部分代码重点加密。* 可以嵌套加密。重复使用几种加密变换,无限制地使代码膨胀* 因为是加密OBJ文件,所以不管DLL还是EXE都可顺利加密,驱动程序也可以基于这个思想,我们的加密软件就要出台了!我们暂时叫它扭曲变换器 1.0三,扭曲变换器有了思想,就开始动手编码。原以为OBJ文件格式是有文档的,工程进度应该很快。没想到其中还是有很多内容需要考虑。每每说这是最后一个问题,解决了就没事了,却总是后延。前前后后居然写了差不多半年时间。主要遇到的技术问题:* 汇编器ML会把所有的代码放到一个段中,这是不可以的。CL则通常是一个函数一个段。* 汇编器ML不能生成 COMDAT 段。尽管文档中讲它支持COMMON,但加了这个关键字无效果。* 汇编器ML不支持 WEAKEXTERN* 汇编器ML只支持 defaultlib 这一个 drectve 关键字,其它 export, include 等关键字不支持.总之,CL编译的OBJ其中有很多属性是ML无法生成的。微软的masm真的该升级了。还有一些问题:* 分不清代码与数据。数据段中肯定是数据,但代码段中却有可能不是代码,是数据。这时如果你试图反汇编它,就会出错。* ?????不管怎样,这些问题都一一解决了(别问我怎么做的)。采用的代码扭曲方法:* 用 JMP 把代码打乱。这已经不是什么新鲜的招数了,但它依然有效。* 用 JMP 把多个函数缠绕在一起。这样可以让分析者找不到函数从什么地方开始,到什么地方结束。* 把 call 改掉。破解者对 call 是极敏感的,这举可以让他找不到一个 call。比如,我可以把 call sub1     改为: mov eax, offset sub1 + 3 push offset @1 sub eax, 3 jmp eax    @1:* 把 ret 改掉。破解者对 ret 是极敏感的,这举可以让他找不到一个 ret。比如,我可以把ret写作 push ecx mov ecx, [esp+4] add esp,8 jmp ecx* 改条件跳。条件跳也是极敏感的指令,比如我们可以把        cmp reg1, reg2        jge L_DST         L_NEXT:写作:        push eax        mov eax, reg1        sub eax, reg2        shr eax, 1fh        neg eax        and eax, L2 - L1        add eax, L1        jmp eax    L1:        pop eax        jmp L_DST    L2:        pop eax    L_NEXT: 再看这个,你能看懂是什么意思吗push offset @@L - offset L_3 + 23hjmp L_1L_2:        jz L_3        ret 4L_3:               add dword ptr [esp+4], offset L_3 - 23h        add esp,4         retL_1:call L_2        ... 这里出现了call和ret,但又不是一般所期望的那种。这里的call不代表你发现了一个函数调用。这里的ret不代表是一个函数的结束。* 使用堆栈代替寄存器。比如: MOV     EAX, DWORD PTR [ECX+0AD8h] PUSH    EAX MOV     ECX, DWORD PTR [EAX]可以写作: PUSH    EAX PUSH    ECX MOV     EAX, DWORD PTR [ESP] ADD     EAX, 0AD8h MOV     EAX, DWORD PTR [EAX] MOV     DWORD PTR [ESP+04h], EAX PUSH    DWORD PTR [ESP+04h] MOV     EAX, DWORD PTR [ESP] MOV     DWORD PTR [ESP+08h], EAX MOV     EAX, DWORD PTR [ESP] MOV     EAX, DWORD PTR [EAX] MOV     DWORD PTR [ESP+04h], EAX MOV     EAX, DWORD PTR [ESP] MOV     ECX, DWORD PTR [ESP+04h] ADD     ESP, 08h你能看懂吗?很明显,这个变换是不可逆变换。因为它本来使用了哪个寄存器,已经没有办法知道了。* ……还可以想出很多扭曲变换的方法。化繁为简只有一种方法,化简为繁可以有无穷多种方法。还有一些功能:* 在C语言中,使用 #pragma code_seg(".code$curve_NoChange") 来指示后面的代码不做任何加密。因为有时候有些代码含有大量的循环,加密它会严重影响效率。* 在C语言中,使用 #pragma code_seg(".code$curve_Max") 来指示后面的代码重点加密。比如后面是与注册算法相关。现在的扭曲变换器我叫它1.0版,已经非常稳定了。我用它把VC6的库文件LIB都处理了一遍,再用LIB.exe工具写回LIB文件中,我们就有了一套加密后的库。如果用这套库来LINK你的软件,分析者就很难从汇编中找到哪个是printf哪个是strcpy,IDA也无法识别MFC静态链接的库函数了。能把VC6的库都加密一遍不出错,我相信它已经很强壮很稳定了。用它来加密我们做的一个共享软件,就再也没人写出注册机了。去读懂大量的经过以上变换的代码是不可想象的。但还是有人暴破了,真佩服他。我会不断丰富加密方法,让暴破者都放弃。

[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课

收藏
免费 0
支持
分享
最新回复 (2)
雪    币: 200
活跃值: (10)
能力值: ( LV2,RANK:10 )
在线值:
发帖
回帖
粉丝
lly
2
这是哪位高手的文章啊?太NB了
2007-11-10 11:19
0
雪    币: 58782
活跃值: (21926)
能力值: (RANK:350 )
在线值:
发帖
回帖
粉丝
3
2007-11-10 11:43
0
游客
登录 | 注册 方可回帖
返回