抗去除花指令(二)——有创意的花指令

转自 http://blog.csdn.net/yangbostar/article/details/6194159

一、概述

“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的插件想通过检测固定形态的方法,是无法穷举的。所以实际检测结果我不必说了吧。

你可能感兴趣的:(保护)