教你如何使用分组密码对shellcode中的windows api字符串进行加密
字符串/模式匹配算法是当前最流行和最简单的检测shellcode方法。原理很简单：所有代码都有其独特的特征，可以根据这种特征去在内存中验证。即使没有事先分析shellcode，我们也可以得到一些有用的变量，或者至少看起来它是一串可疑代码，需要进一步分析。
我提到的有用变量是指API字符串以及hash值，它们已经在检测恶意代码历史上使用了20多年。如果想要绕过这种检测方法，编写shelcode过程中我们要考虑使用像C或C++这样的HLL语言，进行非常规的编程，保证shellcode中的内容是可以变换的，不固定的。
这一过程中不止可执行代码可以变换，任何内容都可以变换：代码，数据，常量，字符串等等。今天我要展示的是使用名为Maru的hash函数生成可排列的API散列。Maru使用分组密码生成字符串的hash值，当然你大可不必使用分组密码做此事，但是这样可以防止使用SMT进行hash碰撞攻击。
想要获取更多有关信息，你可以阅读：使用SAT和SMT消除简单的散列算法
签名检测
在MS-DOS病毒在30年前刚出现时，基于签名的检测是很容易的。为了隐藏恶意代码，攻击者使用八比特的变量对代码进行异或运算，举个例子，在1991年出现的Skism Rythem Stack Virus-808病毒，使用了感染时间时的毫秒数字进行异或运算，所以对于100个版本来说，每一个都是不同的。
这是该代码的入口，以及其解密过程:
jmp virus_start encrypt_val db 00h virus_start: call encrypt ; encrypt/decrypt file jmp virus ; go to start of code encrypt: push cx mov bx, offset virus_code ; start encryption at data xor_loop: mov ch, [bx] ; read current byte xor ch, encrypt_val ; get encryption key mov [bx], ch ; switch bytes inc bx ; move bx up a byte cmp bx, offset virus_code + virus_size ; are we done with the encryption jle xor_loop ; no? keep going pop cx ret
执行完这一串代码之后，病毒会使用当前时间值的毫秒数对'encrypt_val'进行更新:
; mov ah, 2ch ; get time int 21h mov encrypt_val, dl ; save m_seconds to encrypt val so ; theres 100 mutations possible
攻击者为做到隐蔽自己做了一些努力，但是解密器是可以被察觉到的，并且病毒很容易被杀掉。此外，杀毒软件可以模拟解密程序，通过验证签名，在病毒执行前阻止他。
在1997年Win32病毒出现时，已经不存在MS-DOS中断，相反，可以通过动态链接库dll对API函数进行访问，这使得检测恶意软件变得更加容易，当存在大量调用API函数的代码块时，系统就会发出警报。
攻击者最终使用了32位校验码，其中最受欢迎的就是CRC32。不久之后，LSD-PL首先使用了基于ADD-Rotate—Xor方法，在他们的WASM包中，代码如下：
i3: mov esi,[4*eax+ebx] ; ptr to symbol name add esi,edx ; rva2va push ebx ; hash: h=((h<<5)|(h>>27))+c push eax xor ebx,ebx i4: xor eax,eax ; hash loop lodsb rol ebx,5 add ebx,eax cmp eax,0 jnz i4 ror ebx,5 cmp ebx,ecx ; hash compare pop eax pop ebx je i5 ; same: symbol found inc eax jmp i3 ; different: go to the next symbol
大部分合法代码是不需要调用api的，也不会手动导入地址表或者导出地址表的。如果碰到这种行为代码，那么通常它会对你的计算机造成危害。
API散列是很有趣的，它不会被字符串签名验证给杀掉，所以如果杀毒软件只是对是否包含调用API的代码进行检测，那么这种检测方法是无效的。尽管现在很多攻击软件(BeEF,meterpreter，Veil)都会使用无熵或者随机化的散列算法。但是他们是不会被改变的，所以检测起来还是很容易的。
当然，这些工具都提供了像RC4、AES这样的加密算法，不过这样即使通过了杀毒软件和IDS进行的简单扫描，但是通过仿真器去解密主要代码，观察它的行为，对它防御是完全没有问题的。
字符串问题
在理想情况下，攻击者希望在编译过程中对所有代码进行混淆或者加密，并且在解密过程中不会使用冗余的代码和工具。
constexpr是使用c++代码的理想选择，不过对于C来说，则没有这样的功能，除非编译器在编译过程中对所有字符串进行修改和加密。
一些汇编程序比如MASM,NASM是支持基于宏的编译，但是工作过程中是基于很复杂的函数的(并不是你不能)。Z0MBiE已经在2002年在”Meta病毒中的编码“以及”在HLL中解决字符串问题“中对这一问题进行了讨论，但是如果进一步查看这些解决方法，这里只是使用很少的熵值而已。
使用熵对API字符串进行加密的目的很显然是增加检测有效载荷的难度。不过这不是一个长久之计，迟早会被发现，但是这种方法肯定比现有的没有熵的hash算法要好很多。
散列函数构造
我们可以从分组密码中构造新的hash算法，于是对于提供的不同key值，就会生成不同的API散列。但是，很少的分组密码是适用于shellcode生成的。
这里有三个可以使用的分组密码机制(其实有很多的， 只是目前发现了三个)。
1.Davies–Meyer
将每个块中的消息(mi)作为块密文的key，然后将先前的hash值(Hi-1)作为要被加密的明文。然后将输出的密文和之前的hash值(Hi-1)进行异或，生成下一个hash值（Hi）。在加密的第一轮中，之前并没有hash值产生，会使用我们预先设定的一个常量(H0)进行加密操作。
2.Matyas–Meyer–Oseas
将每块中的消息(mi)作为要被加密的明文。输出的密文同样和相同的明文块进行异或，产生下一组hash值(Hi)。前一组hash值会作为这一组加密的密钥。在第一轮中，并没有之前产生的hash值，所以使用之前设定的初始化变量H0.
3. Miyaguchi–Preneel
每一块消息都会作为要加密的明文，输出之后的密文和同样的明文进行异或运算，然后再和前一组产生的hash进行异或运算，产生这一组hash值(Hi)。前一组产生的hash值作为了加密的密钥。
在第一轮中，并没有之前产生的hash值，所以使用之前设定的初始化变量H0。这些是我认为使用的3种简单设计。对于Maru哈希，我使用Davies-Meyer与一些非标准填充。
选择分组密码
我们知道在加密过程中需要一些静态值，与加密常数相比，有什么更好的静态值吗？
你可以对这些静态值进行改变，不过可能会影响加密函数的安全性，所以最好使用一个不包含任何静态变量的密码。在查看可能使用的分组密码时，我选择的前三个是基于ADD-Rotate-Xor(ARX)设计实现的。
1. Speck
由NSA设计，于2013年进行发布（https://eprint.iacr.org/2013/404）。对于不同的架构，产生不同的密钥以及分组大小。成为大多数架构可用的最小的基于软件的块密码。
32位机器的参数为64位的分组大小以及128位的密钥长度。64位模式下的参数为128位的分组大小，以及256为的密钥长度。这两种加密代码长度分别为64字节以及86字节。
如下是x86代码：
2. Chaskey-LTS
在2015年发布(https://eprint.iacr.org/2015/1182),基于Even-Mansour加密方式，使用SipHash中的置换函数进行产生。参数为128位的密钥，和128位的分组大小。在x86机器上实现大小为90字节：
3.XTEA
拓展微加密算法。一种Feistel密码，在1997年发现微加密算法弱点之后发表(http://www.cix.co.uk/~klockstone/xtea.pdf).参数为128比特的密钥，分组大小为64比特。他有一个已知的常量，0x9E3779B9,这使他容易被基于签名检测出来，大小约80个字节:
Speck是轻量级应用程序更好的设计，不能通过签名轻松识别。 （至少不是从任何常数)所以我选择它生成hash。
Maru Hash
那么在关于需要消除shellcode中常量的讨论之后，我在这里介绍hash函数的一部分。在转换为整数之前，64位常数是137素数的乘法逆元。它是加密过程中的初始化参数H0。
进一步来说：
1. 0.00729927007299270072992700729927是137的乘法逆元。 2. 舍弃小数部分中的前两个0,将剩下的转换为64位整数。 3. 结果为：0x654C37754C5E9939
H是通过用Maru常数和64位密钥进行异或初始化的。然后将API字符串作为密钥重复使用Speck进行加密，直到达到终止符为止。
下方代码是C原型：
uint64_t maru(const void *str, const void *key);
str参数指向我们的API字符串，长度不应超过128字节(即使函数接受任意长度的字符串)。key参数应该指向我们唯一的64位值，这应该是理想的随机选择。
uint64_t maru(const void *str, const void *key)
{
uint8_t *s=(uint8_t*)str;
w64_t *k=(w64_t*)key;
w64_t h;
w128_t m;
uint32_t idx, end=0, i, t, k0, k1, k2, k3, x0, x1;
// set the initial hash which is 64-bit key xor 1/137
h.q = k->q ^ MARU_INIT_H;
// now update the hash using string as key
for (idx=0; !end; ) {
// if bytes remaining
if (*s != 0) {
// add byte to buffer
m.b[idx++] = *s++;
} else {
// this is last block
// pad with end bits
while (idx < MARU_BLK_LEN) {
m.b[idx] = (uint8_t)idx;
idx++;
}
end++;
}
// if m filled
if (idx == MARU_BLK_LEN) {
// copy 128-bit key to local registers
k0 = m.w[0]; k1 = m.w[1];
k2 = m.w[2]; k3 = m.w[3];
// copy H to local space
x0 = h.w[0]; x1 = h.w[1];
for (i=0; i<27; i++)
{
// encrypt block
x0 = (ROTR32(x0, 8) + x1) ^ k0;
x1 = ROTL32(x1, 3) ^ x0;
// create next subkey
k1 = (ROTR32(k1, 8) + k0) ^ i;
k0 = ROTL32(k0, 3) ^ k1;
XCHG(k3, k2);
XCHG(k3, k1);
}
// update previous hash
h.w[0] ^= x0; h.w[1] ^= x1;
// reset index
idx = 0;
}
}
// return 64-bit hash
return h.q;
}
hash举例
以下是对API以及潜在密钥的测试案例，他们不必是字符串。
从示例散列可以看出，一旦密钥被更改，生成的API哈希是完全不同的。通过选择不同的密钥，这使得我们的哈希值也会不同。
总结
设计自己的hash函数或者加密算法通常会很好的绕过杀毒软件。但是像Maru这样的hash算法并不适用于对防碰撞要求很高的场合。Maru hash真的是一个关于如何对shellcode中的字符串进行随机变换，进而绕过杀毒软件的字符串检测的方法。