能力值:
( LV9,RANK:230 )
|
-
-
2 楼
一、概述
“jmp/call/ret+垃圾数据”这样的花指令已经是相当“老掉牙”了,OD的插件对付它们基本是“秒杀”,所以本文想说点“有点创意”的花指令,至少能对付OD的插件。
二、创意的核心
[2.1]花指令因何被发现
“jmp/call/ret+垃圾数据”的方法之所以容易被检测,原因是“意图太明显”,具体说任何一种检测手段,都是基于以下两点:
①检测跳转结构的固定形态特征,当然这不是绝对的,如果检测机制没能预见到这种形态特征,此点可以忽略,本文后边会提到一些这样的情况。
②用可靠的方法直接证明,垃圾数据部分在任何情况下都不会被执行。应该说该点是对“不可执行花指令”的无敌检测手段,然而却难在“可靠”二字上,目前已知的实践,只是做到“可供参考”的程度。
[2.2]创意的策略
通过[2.1]的分析,我们知道要想编写“有创意的花指令”,火力应集中在①上,因此我们通过以下策略对抗:
①采用新的固定结构,许多插件还没有检测,比如下文提到的xor-cmp的结构。
②非固定结构的“伪条件跳转”替代“强制跳转” 三、一步一步学创意
[3.1]一次幼稚的实践——互补条件跳转
首先,我们来尝试一种用“伪条件跳转”替代“强制跳转”的方法,称作“互补条件跳转法”,即用两个互补的条件跳转指令替代一个强制跳转指令。比如,用jz和jnz跳转到同一地址,和一个jmp是等价的。
举例:
……
Jz Label
Jnz Label
Db thunkcode;垃圾数据
Label:
……
除了jz和jnz,还有许多互补跳转指令,如表1。
经过测试,只有一少部分OD插件没能识别这类花指令,究其原因还是这种方法形态太过固定,一旦形态特征广为人知,检测就相当容易。
[3.2]上面方法的改进版——用随机值获得确定性标志位
上面的方面采用两个互补的条件跳转还是明显,连普通程序都不会使用。所以,我们应该试图只用一个条件跳转。具体方法是这样的:
通过某些隐蔽的手法,使得某个标志位有确定性的值,然后利用这个确定值,进行确定性条件跳转。比如下面的手法
Xor reg,value1
Cmp reg,value1
Jnz Label
Db thunkcode
Label:
……
该手法的优点是,无论value为何值,经过了xor reg,value1和cmp reg,value这两句指令,,ZF位一定不会置位,所以jnz一定跳转。该方法有相当多的变体,该方法的核心是使用随机值,使得某标志位有确定性值。
经过测试,OD的大部分插件都不能检测,这类花指令变种较多,插件编写容易遗漏或者未预见到某些形态,但是这种方法的形态特征还是相对固定的,只是某些还未广泛熟知,但随着时间推移,该方法的效力会越来越弱。
[3.3]利用API返回确定值
大部分API函数的返回值是不确定的,只要有方法使得API返回确定值,那么后面接续的条件跳转,就是等价的。比如说CreateFile返回文件句柄,句柄可能是任意值且有不确定性,然而我们可以使得函数CreateFile返回值是确定的。
1)令CreateFile返回错误码,比如故意向CreateFile传入错误参数,还可以使用类似inc esp,使得堆栈不4字节对齐,即使传入正确参数,也会返回错误码。
2)由于句柄值实际上是句柄表索引,所以CreatFile返回的正确句柄值都是4的倍数,我们把句柄值取4的模,得0是一定的。
类似的方法可以说是数不胜数,所以OD的插件想通过检测固定形态的方法,是无法穷举的。所以实际检测结果我不必说了吧。
|
能力值:
( LV2,RANK:15 )
|
-
-
3 楼
感谢分享,学习了!
|
能力值:
( LV8,RANK:130 )
|
-
-
4 楼
讲的不错。。可惜太少了。。讲多点,呵呵。。。 我觉得,就算是再多花样,也是可以识别的出来。。最难的是那种单条垃圾指令。。就是操作空闲寄存器的指令。。你没办法判断哪些寄存器是空闲寄存器,也就没有办法判断哪些单条垃圾指令。。。
|
能力值:
( LV9,RANK:230 )
|
-
-
5 楼
同意楼上的观点,任何花指令都是可以被识别的。不过还好,目前去花指令的方法都挺“傻”的
|
能力值:
( LV9,RANK:230 )
|
-
-
6 楼
任何技术都有被攻破的一天,没有包打天下的方法。再强的花指令也是有可能被清除的,这时我们也要想办法应对。所以我们经常需要检测花指令是否被清除,加以应对。
一、花指令被清除后的痕迹
我们来看一下,下面一段简单花指令被清除后的结果:
代码:
jmp @F
byte 08eH
@@:
ret
清除后:
二、检测 从上文我们可以看到,花指令被替换指令NOP,这样就不必重构代码,就能够使代码正常运行。显然,我们只要检测NOP就行了。
举例:
.386
.model stdcall,flat
option casemap:none
include windows.inc
include kernel32.inc
includelib kernel32.lib
include user32.inc
includelib user32.lib
.data
Context byte "Junkcode has been cleaned",0
Tip byte "Tip",0
.code
start:
JunkCode:
jmp @F
byte 8eH
@@:
mov al,byte ptr[$-1]
cmp al,90H
jnz Pro_End
invoke MessageBox,NULL,addr Context,addr Tip,MB_OK
Pro_End:
invoke ExitProcess,0
end start
|
能力值:
( LV3,RANK:30 )
|
-
-
7 楼
这就是你上段时间说的比VM更油菜的东西吗 ? 我忘了你上次开贴是怎样说的了。
|
能力值:
( LV2,RANK:10 )
|
-
-
8 楼
实际这三篇完全可以编辑到一起,
|
能力值:
( LV9,RANK:230 )
|
-
-
9 楼
??什么意思,我上段时间说,我要写关于代码迷惑方向的文章,这个系列就是其中的一部分。
|
能力值:
( LV9,RANK:230 )
|
-
-
10 楼
还有第四篇呢,把它们编在一起,就有点长了,所以拆开来发。
|
能力值:
( LV3,RANK:20 )
|
-
-
11 楼
别人照样可以去掉你检测花指令的代码啊。。。
把cmp al,90和下面的给nop掉
|
能力值:
( LV3,RANK:20 )
|
-
-
12 楼
利用API返回确定值 这个挺有意思的。呵呵。。
网上有很多的花指令,我一般是直接用。。。稍做修改。
|
能力值:
( LV3,RANK:20 )
|
-
-
13 楼
用花指令做免杀,很容易逃过金山毒霸,所以我觉得毒霸非常垃圾。
|
能力值:
( LV9,RANK:230 )
|
-
-
14 楼
我们欺骗是花指令检测程序,而不是人,花指令对于人来说都是延长了破解时间。
|
能力值:
( LV8,RANK:130 )
|
-
-
15 楼
花指令检测程序还不是人写出来的。。。。
|
能力值:
( LV3,RANK:20 )
|
-
-
16 楼
我的意思是检测也要多种手法吧。像单纯依靠这种的话,用脚本照样直接去掉。
或搜索二进制神马的也可以找到。
本人完全菜鸟,不对的请多包涵,期待后面更多精彩内容!
|
能力值:
( LV9,RANK:230 )
|
-
-
17 楼
花指令检测程序还没有强大到使用人工智能的层次。
|
能力值:
( LV9,RANK:230 )
|
-
-
18 楼
|
能力值:
( LV9,RANK:230 )
|
-
-
19 楼
去年金山四次VB100%的检测全部失败了,真是中国杀软的耻辱
|
能力值:
( LV13,RANK:260 )
|
-
-
20 楼
菜菜来学习了。。。。
通过定义花指令组结合使用,通常更加方便
下面是看雪的大大们曾经提到过的。。。好像是这么写的。。
#define _FLOWER //此开关控制编译器是否使用花指令
#ifndef _FLOWER
#define _XX0 __asm nop
#else
#define _XX0 __asm{\
定义自己的小花
..... }
#endif
.......继续
#ifndef _FLOWER
#define _XX1 __asm nop
#else
#define _XX1 __asm{\
定义自己的小花
..... }
.......
.........
#endif
若需在程序中使用 ,定义开关,插入_XX 就可以,希望lz 能接着出更加灵活的花。。。守候学习ing。。
|
能力值:
( LV13,RANK:260 )
|
-
-
21 楼
还有,有时候还是觉得 当未被检测的花在关键区域里使用达不到一定的数量,很是恼火的,起到的作用也不会很大。
最终,还是自己在写东西的时候,既得重视花的质量,也得重视种类和数量的使用。。。。
菜菜自己的理解。。主要是来学习的,交流的。。。
|
能力值:
( LV15,RANK:670 )
|
-
-
22 楼
一起整个 pdf 吧。
|
能力值:
( LV2,RANK:10 )
|
-
-
23 楼
再花的指令也能检测出来吧,毕竟是人写的。
|
能力值:
( LV9,RANK:230 )
|
-
-
24 楼
被人识别不要紧,本来花指令就是为了浪费人的时间。被程序检测出来才是要紧的,不被程序“秒杀”才是文章关注的重点
|
能力值:
( LV2,RANK:10 )
|
-
-
25 楼
不管啥花指令都逃不过特征码的定位 不过还是很有用的
|
|
|