细数恶意代码对抗技术之加密(一)-字符串加密

By | 2014年3月3日

随着这两年Android恶意代码数量的爆炸式增长,恶意代码与逆向工程师之间的猫捉老鼠游戏也愈演愈烈。恶意代码为了防止被反编译,采用了各式各样的对抗手段,总的来说可以总结为三大类:

  • 混淆
  • 加密
  • Native实现

这篇文章主要列举了恶意代码当前采用的加密类对抗技术,特别是对代码中的明文字符串信息加密。

早期的加密技术

早期的恶意代码通常会采用某种字符串变换方式或者简单的加密函数来隐藏关键的字符串信息(例如上传服务器的URL信息等):

49072BEA-B060-4942-831D-3C3491766DA28673DB7C-7ACF-4507-9E05-3F2E550C74A9

这类加密方式最早出现在Spy类样本中,其只对部分关键URL信息进行加密处理,分析人员能够很快通过其解密函数得到明文信息。从现在看来,那个时候的加密技术“看起来还是个孩子”。

单一的加密函数

这类加密方式在早期出现的加密方式上做了加强,对恶意代码中广泛出现的明文字符串信息都调用同一加密方法加密,这里加密方法有时候直接采用JAVA提供的标准加密库,例如DES,AES,Base64等。

调用标准库:

使用单一自定义的加密方法,其中mzhengDS.DecryptString为解密函数:

这种类型的加密对抗技术通常可以采用dex2jar的Decrypt String脚本进行解密,并且一直被部分恶意代码家族所采用,直至2013年最强木马obad的出现。

DexGuard加密混淆

在obad出现之前,恶意代码中采用的加密方式通常对于逆向分析人员的影响是极其有限的,直到这个被称为Android史上最强木马的出现。其采用了DexGuard的加密混淆技术,不仅对整个样本中的所有明文信息进行加密,而且对库函数调用的类名方法名也做了同样的加密,并通过反射方式调用。这类加密方式有个很鲜明的特点,就是每个类的clinit中初始化一个byte数组,其中存储了该类所需的所有明文信息的加密结果。

5748C460-CFF0-4D81-BD49-21B7F49E2B5F

并且加密方法的实现不再单一,而是每个类的加密过程都不相同:

这类加密方式后来也陆续被某些恶意家族所采用,例如Fakeinst等:

4080DBE0-9CB3-4083-B107-69920124C0CE

从此字符串加密对抗技术开始广泛的在各类恶意代码家族中使用,极大的阻碍了样本工程师的逆向分析。

其他的加密对抗形态

  • 在某类恶意扣费家族发现的加密形态,其每个类的解密方法名和实现都不一样,并且解密方法中库函数的调用过程也被加密了:

EFCEAD03-4BCC-4630-9A72-2F7DB2CFF2DC

3F9026C0-48F3-4EA4-A5CD-59EF3A4FC80E

  • 解密过程引入运行时参数:

A688DEF2-397F-4F73-AC1D-96D8E0AB92ED

4771E636-2684-4966-B355-20FD6E614C79

  • 更为复杂的加密形态,其将代码中出现的Class、Method、String、Constructor等信息提取为类的静态成员,并采用多次加密变化手段:

BCAC638C-299B-47B5-80CF-08990C7F601D

拿其中一段代码为例,该方法返回一个Method对象,其获取的是类xvbrscb中的以cogst.cogst(“qoiBtwqqswao”)解密结果命名的方法,参数1类型为mrvxkb,参数2类型为cogst

而参数1的定义为:

结果嵌套了另一层加密变换:

小结

上述加密对抗技术基本涵盖了当前恶意代码中出现的所有加密形态。

从其发展时间来看,从2012年开始,恶意代码就开始采用一些加密方式以对抗静态分析,一直到2013年上半年,恶意代码的加密形态都没有发生根本性的改变,采用的技术也相对简单;从obad出现开始,恶意代码开始尝试使用一些更为复杂的加密对抗方式,并且更为广泛的运用,并且在2013年下半年开始,以加密方式对抗静态分析的手段开始不断变形,变得更加复杂、更加有效,方式和方法也更加多样化。

发表评论

电子邮件地址不会被公开。 必填项已用*标注