首页 > 技术点滴 > something about burneye

something about burneye

2013年6月8日 baoz 阅读评论

CoolQ的经典之作,突然发现自己以前收藏的burneye没了,赶紧copy一份。

作者:CoolQ <qufuping@ercist.iscas.ac.cn
出处:http: //www.linuxforum.net/forum/showflat.php?Cat=&Board=security&Number
日期:2005-01-06

 

|=———————–=[ Something about burneye ]=———————-=|
|=————————————————————————–=|
|=—————–=[ CoolQ <qufuping@ercist.iscas.ac.cn> ]=—————-=|
|=————————————————————————–=|

–[ 内容

0 – 前言

1 – 使用篇
1.1 下载
1.2 试用
1.3 patch

2 – 分析篇
2.1 源代码的结构
2.2 burneye加密的原理
2.2.1 patch 1
2.2.2 流程分析
2.2.3 patch 2
2.3 burneye的anti-debugger
2.4 burneye的loader

3 – 破解篇
3.1 加密算法
3.2 对策

4 – 几个问题

5 – 参考

–[ 0 – 前言

linuxforum上madsys的ABFrag放了好久了,也没有人感兴趣,看来Burneye还挺很神奇.
ABFrag有人说是一个假的Exploit,但我对Burneye产生了兴趣.
Burneye是Unix/Linux下少见的几个加密ELF的软件之一, 作者是TESO的成员scut.

本文共分三个部分:使用篇,分析篇,破解篇.

我使用的环境是RedHat FC2, kernel 2.6.8.1, gcc 3.3

–[ 1 – 使用篇

–[ 1.1 下载

packetstormsecurity.nl上Burneye的下载共有3个[1]:
burneye-1.0-linux-static.tar.gz, (静态编译可执行文件)
burneye-1.0.1-src.tar.bz2,       (源代码包)
burneye-stripped.tar.gz
其中后两个的差别只是是否有ELF的标准文档,因此我们先把前两个都弄下来.

–[ 1.2 试用

先试着使用静态编译的Burneye
[root@localhost]# ./burneye
[root@localhost]#
[root@localhost]# strace ./burneye
execve(“./burneye”, [“./burneye”], [/* 20 vars */]) = 0
_exit(73)

看来burneye的二进制程序在我们的系统上不能使用,退出码73为EDOTDOT,并不常见.

接着我们编译一下源代码:
[root@localhost]# tar jvxf burneye-1.0.1-src.tar.bz2
[root@localhost]# cd src && make
….
gcc -Wall  -o burneye burneye.c common.o cipher-glfsr.o cipher-rc4.o
cipher-sha1.o fingerprint.o rs.o

好,编译成功,我们来试用一下

[root@localhost]# ./burneye
usage: ./burneye [options] <program>

banner options
-b file                display banner from ‘file’ before start
-B file                display banner from ‘file’ on tty before start

password protect options
-p pass                use password encryption with ‘pass’ as password
-P env                first try to read password from environment ‘env’,
will use password from ‘env’ now, too, if its there
-i                ignore invalid entered password and execute junk
not recommended (default: off)

fingerprinting options
-S                SEAL mode (options F,f,t are ignored)
-f file                use fingerprint from ‘file’ to protect binary
-F                use fingerprint of current host (do not use -f and -F)
-t num                tolerate ‘num’ deviations in fingerprint
-q                be quiet about wrong fingerprint, just exit
(default: 0)
-E                do tolerance even if erasure warning is given
-l                list fingerprint tests that can be done
-e test                enable fingerprint test ‘test’
-d test                disable fingerprint test ‘test’

generic options
-o out                specify another output file name (default: output)
….

burneye中的README给出了几个典型的例子:(详细介绍请参见doc/DIST-README)

burneye -o ls /bin/ls                   # 只作代码的obfuscate,不作加密
burneye -p “secret” -o ls /bin/ls       # 使用密码’secret’加密
burneye -B warning.txt -o ls /bin/ls    # 启动时显示warning.txt的信息
burneye -F -t 1 -B warning.txt -o ls /bin/ls        # 使用本地主机的指纹,启动时
# 显示warning.txt的信息, 测试时允许有一项失败
fingerprint -d procpartitions -f foohost.fp
burneye -f foohost.fp -t 2 -p “hidden” -o ls /bin/ls
# 使用fingerprint产生指纹文件,允许两项失败,启用密码保护
burneye -p puke -S -o ls /bin/ls
./ls  # 将会把信息封存并保存到二进制文件中
OLDHOSTNAME=hostname
./ls  # 正常运行
hostname moo
./ls  # 运行环境与封存设置不符,失败

下面我们也按照README的例子试用一下:

[root@localhost] ./burneye -p 123 -o ls.new /bin/ls
burneye – TESO ELF Encryption Engine
version 1.0.1
——————————————————————————-

loaded 24768 bytes @ 0x08caf170
doing pre-stub encryption (@ 0x05371000) from offset 0x0000007f
next entry point is 0x05371080
end of segment 1: 0x0000563
bogus bytes at the end, i.e. something between segments end and file end.

并没有加密的ls.new生成,看来编译的源代码也不可用!

在网上搜索了一下,好像没有人遇到过这种情况,奇怪了,难道是系统的问题?

找了一个RedHat 9, kernel 2.4.20-8, gcc 3.2.2
原样不动做了一遍,结果发现静态二进制文件可以运行,而源代码包虽然能编译,
却仍然不能加密。

–[ 1.3 patch

既然我的FC2上不能运行,那就只能自力更生了,通过阅读源代码,发现了原因,自己写了
一个patch, 一切OK。(至于这个Patch是怎么来的,请参考分析篇)

source code patch:
————————— stub.lds.diff ————————————
— new/src/stub/stub.lds        2001-07-15 06:20:18.000000000 -0400
+++ old/src/stub/stub.lds        2004-12-11 18:11:13.000000000 -0500
@@ -19,6 +19,7 @@
*(.text)
*(.data)
*(.rodata)
+                *(.rodata.str1.1)
*(.bss)
callgate.o(.text)
—————————– stub.diff ————————————–
— new/src/stub/stub.c        2002-04-07 11:13:16.000000000 -0400
+++ old/src/stub/stub.c        2004-12-11 23:04:16.000000000 -0500
@@ -715,12 +715,14 @@

/* now insertion-sort the given array */
for (n = 0 ; n < auxc ; ++n) {
–                if (auxv[n].a_type >= 32) {
+                if (auxv[n].a_type >= 42) {
be_printf (“FATAL: invalid AT_* entry detected\n”);
_exit (73);
}

if (auxv[n].a_type != AT_NULL) {
+                        if(auxv[n].a_type >= 32)
+                                continue;
a_copy[auxv[n].a_type].a_type = auxv[n].a_type;
a_copy[auxv[n].a_type].a_un.a_val = auxv[n].a_un.a_val;
be_printf (“AUXV: 0x%08lx : 0x%08lx\n”, auxv[n].a_type

2.6 kernel patch:
———————— binfmt_elf.c.diff ———————————–
— /usr/src/linux/fs/binfmt_elf.c        2004-05-08 08:56:42.000000000 -0400
+++ binfmt_elf.c        2004-12-15 20:40:36.145239824 -0500
@@ -171,7 +171,7 @@
* ARCH_DLINFO must come first so PPC can do its special alignment of
* AUXV.
*/
–        ARCH_DLINFO;
+        //ARCH_DLINFO;
#endif
NEW_AUX_ENT(AT_HWCAP, ELF_HWCAP);
NEW_AUX_ENT(AT_PAGESZ, ELF_EXEC_PAGESIZE)

注意:如果你从源代码编译burneye,只需要打源代码的patch即可,如果你手头上有
burneye加密的程序,并且该程序一定要在2.6内核上运行,你需要打上内核源代码的补丁
并重新编译内核。当然,你也可以为二进制的加密程序打patch,不过由于加密程序的
生成环境比较复杂,这种patch也不容易制作。

–[ 2 分析篇

–[ 2.1 源代码的结构

src/burneye.c               命令行主程序
stub/callgate.asm       -+
stub/cgate.c             |
stub/cipher-glfsr-c.c    |  加密解密相关程序,其中glfsr是整个解密程序的入口,
stub/cipher-glfsr.asm    +->由glfsr完成对加密程序的de-obfuscate,之后,转入
stub/cipher-rc4.c        |  init.asm的be_entry处
stub/cipher-sha1.c       |
stub/rs.c               -+
stub/fingerprint.c          生成机器的特征指纹
stub/help.c                 常用函数
stub/init.asm               程序初始化入口,分配好ELF32_auxv_t结构后,转入
stub.c的burneye函数
stub/stub.c                 这是加密程序运行的主函数
stub/stub.lds               这是一个连接脚本,以后还要讨论
stub/unlink_stub.asm        删除文件的程序
stub/utils/hdump.c          将二进制文件以十六进制形式打出
stub/utils/sstrip.c         处理ELF文件,使得ELF只保留ELF文件头,PHDR和所有的
Segment,其余的无用Section和Section Header一律抛弃

–[ 2.2 burneye加密的原理

burneye类似与Windows下一般的加壳工具,但是又有自己的特色,先来分析一下用
burneye加密后文件的结构:

[ELF头][程序头][Burneye常用例程][stub头][加密后的程序]

其中前三部分,Burneye使用了一个技巧,在编译Burneye命令时,生成了一个很大的数组
stub_bin[],其实就是一个通用的ELF头+程序头+Burneye常用例程,加密程序时,只需要对
数组里的某些字段稍作修改即可.

–[ 2.2.1 patch 1

下面我们来看一下stub_bin[]是怎么生成的,这样我们才能明白为什么原来的源代码无法
使用.

src/stub/Makefile:

stub.bin.h:        stub.bin
echo “unsigned char        stub_bin[] =” > stub-bin.h
utils/hdump < stub.bin >> stub-bin.h
egrep “\.text.+0x.+0x.+cipher-glfsr.o” stub.map | \
awk ‘{ printf (“#define BE_LAYER0_START %s\n”, $$2); }’ \
>> stub-bin.

stub.bin:        buildtools $(OBJS) stub.lds
sed s/entry_point/$(ENTRY_POINT)/ < stub.lds > stub-bin.lds
ld -Map stub.map -s -T stub-bin.lds -o stub.bin $(OBJS)
rm -f stub-bin.lds
ifeq ($(rel),on)
strip stub.bin
utils/sstrip stub.bin
endif

可见,stub.bin.h实际上就是stub.bin的十六进制形式,然后添加几个宏构成的。而
stub.bin则是由ld将所有的目标文件按照stub-bin.lds的内容连接而成,并将结果
去除符号表并抛弃多余的Section/Section header。

问题的关键就是这个连接脚本,为什么原来的burneye编译以后无法加密呢?我们先看
一下stub.lds

PHDRS
{
text PT_LOAD FILEHDR PHDRS FLAGS (0x0007);        /* PF_R | PF_W | PF_X */
data PT_LOAD FLAGS (0x0006);                        /* PF_R | PF_W */
}

SECTIONS
{
. = 0x05371000 ;
.text : {
cipher-glfsr.o(.text)
init.o(.text)
*(.text)
*(.data)
*(.rodata)
*(.bss)
callgate.o(.text)

PROVIDE (be_stubhdr_u = ABSOLUTE(.)) ;
LONG (0x41012345) ;
} : text

/* dummy segment to set fixed brk(0) value in kernelspace */
. = 0x08048000 ;
.data : {
} : data

/* save calls to objcopy, huh */
/DISCARD/ : {
*(.eh_frame)
*(.comment)
*(.note)
}
}
用这个脚本生成的stub.bin应该只有两个程序段,第一个段应该把原来所有目标文件
的大部分节都整合在一起,包括所有OBJS的.text, .data, .rodata, .bss.

再看一下原来加密出错时的源代码:
if (stub_len != phdr[0].p_offset + phdr[0].p_memsz) {
fprintf (stderr, “bogus bytes at the end, i.e. something ”
“between segments end and file end.\n”);
exit (EXIT_FAILURE);
}
其中stub_len就是stub_bin[]的长度,注意到phdr[0]中的0了么?这是指第一个程序段,
也就是说,程序期望stub.bin的第二个程序段的长度是0! 否则应该写成
if (stub_len != phdr[1].p_offset + phdr[1].p_memsz)

但实际上,我们生成的stub.bin,第二个程序段大小并不为0,我们修改Makefile文件,
将strip和sstrip的步骤省略,然后readelf一下stub.bin,发现了:
[root@localhost]# readelf -l stub.bin

Program Headers:
Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
LOAD           0x000000 0x05370000 0x05370000 0x05630 0x05630 RWE 0x1000
LOAD           0x006000 0x00000000 0x00000000 0x000c1 0x000c1 RW  0x1000

Section to Segment mapping:
Segment Sections…
00     .text
01     .rodata.str1.1   <—- 看见了吧? 加密不成就是多出来的这个Section.
出现.rodata.str1.1是编译器的原因,当然这是GCC 3.3的结果,我在Redhat 7.2上
还出现了.rodata.str1.32。
因此,我们需要在lds中把.rodata.str1.1也添加进去(当然如果有.32,也需要加上)。

这里还有一个问题,为什么不只用一个段呢?第二个空段是做什么用的呢?
你可以看一下doc/README的内容。

–[ 2.2.2 流程分析

接下来按照Burneye的代码,把整体流程简要描述一下

加密过程:(主要是burneye.c的wrap函数)
burneye首先以加密的文件作为对象,将stub_bin[]作为加密后文件的ELF头+程序头+
Burneye常用例程,然后按照burneye的命令选项,对文件进行逐层的处理,顺序是:
tag – banner – password – fingerprint – glfsr(obfuscate)
每层处理,都会在stub头中保存相应的标志和信息(例如加密时的随机序列,sha1哈希值)
,然后将结果放到最后一部分中。

解密过程:(主要是cipher-glfsr.asm,init.asm和stub.c中的burneye函数)
加密程序的入口是cipher-glfsr.asm的glent,负责de-obfuscated程序,去掉第一层保护,
接下来由init.asm处理一下运行程序的栈结构,并将系统控制权交给stub.c的burneye。
burneye是最主要的部分,会按照顺序处理Tag并显示Banner(如果有的话),接下来,是
fingerprint的检测,然后会提示你输入加密时设定的密码,如果一切OK,就将加密的
程序解密,然后调用burneye中自带的Loader,将解密后的程序映射到内存中,如过解密
的程序需要interpreter,loader也会负责将interpreter装入到内存中,最后将控制权交
给interpreter或者解密后的ELF。至此,一切恢复正常.

–[ 2.2.3 patch 2

打完了patch1,用burneye加密程序没有错误信息,但是问题依然存在:
[root@localhost]# ./burneye -p 1234 -o ls.new /bin/ls
XXX: stub_len = 0x00005720
phdr 1 @ 0x05370000
phdr 2 @ 0x00000000
burneye – TESO ELF Encryption Engine
version 1.0.1
——————————————————————————

loaded 22256 bytes @ 0x094d2170
doing pre-stub encryption (@ 0x05371000) from offset 0x0000007f
next entry point is 0x05371080
end of segment 1: 0x000056f0
brk(0) to force is 0x0805bff3
obfuscation layer: key = 0x52e8b1d3

——————————————————————————
[root@localhost]# ./ls.new
[root@localhost]#
[root@localhost]# strace ./ls.new
execve(“./ls.new”, [“./ls.new”], [/* 20 vars */]) = 0
_exit(73)
加密的程序不能运行! 跟前面的结果一样。通过程序的Debug选项,我们找到了出错的
位置:
for (n = 0 ; n < auxc ; ++n) {
if (auxv[n].a_type >= 32) {
be_printf (“FATAL: invalid AT_* entry detected\n”);
_exit (73);
}
这里的auxv是一个ELF32_auxv_t的结构,一般人可能不太接触,这里从[2]上偷一段:

When the userspace receives control, the stack layout has a fixed format.
The rough order is this:

<arguments> <environ> <auxv> <string data>

The detailed layout, assuming IA32 architecture, is this (Linux kernel
series 2.2/2.4):

position            content                     size (bytes) + comment
————————————————————————
stack pointer ->  [ argc = number of args ]     4
[ argv[0] (pointer) ]         4   (program name)
[ argv[1] (pointer) ]         4
[ argv[..] (pointer) ]        4 * x
[ argv[n – 1] (pointer) ]     4
[ argv[n] (pointer) ]         4   (= NULL)

[ envp[0] (pointer) ]         4
[ envp[1] (pointer) ]         4
[ envp[..] (pointer) ]        4
[ envp[term] (pointer) ]      4   (= NULL)

[ auxv[0] (Elf32_auxv_t) ]    8
[ auxv[1] (Elf32_auxv_t) ]    8
[ auxv[..] (Elf32_auxv_t) ]   8
[ auxv[term] (Elf32_auxv_t) ] 8   (= AT_NULL vector)

[ padding ]                   0 – 16

[ argument ASCIIZ strings ]   >= 0
[ environment ASCIIZ str. ]   >= 0

(0xbffffffc)      [ end marker ]                4   (= NULL)

(0xc0000000)      < top of stack >              0   (virtual)
————————————————————————
auxv主要是为内核与用户程序(主要是Loader)协同而设置的。2.4内核构造的auxv,
其类型最多不超过32(其实最大也就是23 - AT_SECURE),但是到了2.6内核,又出了
几种新的类型,因此,程序到这一步就出错了。通过GDB调试一个普通的程序,发现
栈中确实有类型为32(AT_SYSINFO)和33(AT_SYSINFO_EHDR)的auxv存在。
解决的方法就是将大于等于32的auxv跳过去(其实Loader只需五种类型的auxv)。
patch 2就这么产生了。

–[ 2.3 burneye的anti-debugger

主要有两种,一种是反编译,一种是反跟踪

反编译是通过对代码进行obfuscate(glfsr),使objdump等工具失效。
反跟踪使用了int3,并在程序里自己截获SIGTRAP,具体的代码是:(参考[3])

antistrace ();

if (nottraced == 0)
killme ()

void be_sigtrap (int signum)
{
nottraced++;
}
static inline int antistrace(void)
{
long ret;

__asm__ __volatile__ (“int $0x03\n\t”
:”=a” (ret)
: );
return (ret);
}
static inline int killme()
{
long ret;

__asm__ __volatile__ (“xorl        %%eax, %%eax\t\n”
“xorl        %%ebx, %%ebx\t\n”
“xorl        %%ecx, %%ecx\t\n”
“xorl        %%edx, %%edx\t\n”
“xorl        %%esi, %%esi\t\n”
“xorl        %%edi, %%edi\t\n”
“xorl        %%ebp, %%ebp\t\n”
“xorl        %%esp, %%esp\t\n”
“jmp        %%esi”
:”=a” (ret)
: );
}        return ret;

–[ 2.4 burneye的loader

由于解密以后的程序与burneye的例程函数是位于同一进程空间的,因此如果想要执行
解密后的程序,例程就需要自己装载程序(普通情况下,程序是由内核来完成装载任务的)
,burneye是通过be_remap来实现的,如果加密之前的程序是动态链接的,还需调用
be_mapinterpreter来装载interpreter。因此,即使你file ls.new结果是statically
linked, 你查看/proc/PID/maps发现多个.so时,也不要惊奇。

–[ 3 破解篇

–[ 3.1 加密算法

burneye的保护主要有三层,最外层的是通过glfsr算法对代码进行的obfuscate,第二层
和第三层以主机的某些特征(fingerprint)和密码作为密钥KEY,首先算出密钥的SHA1哈希
值DIG,然后从随机发生序列器中获得160位的随机数RAN,并与SHA1哈希值异或,得到
KEY2,然后用KEY2对需要程序进行RC4加密。burneye还将加密之前的明文SHA1哈希值保存
到stub头的相应部分,这样做密码验证时,能够判断密码的正确性。

–[ 3.2 对策

最外层的glfsr,虽然比XOR加密要好得多,但是仍然是相对较弱的加密,很容易对付。
第二/三层的加密,算法是比较强的,只能用暴力方法解决,但是如果方法得当,能够大大
提高解密的速度。来看看如何提高解密速度:
原来的加密程序
SHA1HashLen (pw_pass, strlen (pw_pass), pw_hash);
for (key_n = 0 ; key_n < sizeof (pw_hash) ; ++key_n)
pw_hash[key_n] ^= xor_hash[key_n];
SHA1HashLen (pw_hash, sizeof (pw_hash), pw_hash);
rc4_prepare_key (pw_hash, sizeof (pw_hash), &key_r);
rc4_cipher (exe_data, exe_len, &key_r);
其中,pw_pass就是密码字符串,exe_data就是需要加密的整个文件.
解密的时候使用的还是上边的代码,pw_pass是你输入的密码,而xor_hash保存在加密文件的
stub头中。

是不是需要将所有的exe_data都解密,然后判断密码的正确性呢?不是的,burneye在这一
方面有欠缺。exe_data其实就是待加密的整个ELF文件,因此,前面一部分必定是ELF头,
这样,我们只须解密exe_data的前几个字节,看是不是合法的ELF文件头即可,无须解密
整个exe_data,例如:

static char ELF_HEADER[] = “\x7f\x45\x4c\x46\x01\x01\x01”
“\0\0\0\0\0\0\0\0\0\x02\0\x03\0”;

rc4_cipher (exe_data, sizeof(ELF_HEADER), &key_r);
if(!strncmp(exe_data, ELF_HEADER, sizeof(ELF_HEADER))
printf(“Match!!\n”);

互联网上能够找到几个暴力破解Burneye加密的工具包:
[http://www.rootshell.be/~ioc/releases/ioc6-final.tar.gz]
[http://66.230.171.10/releases/Crypto/UNFburninhell/UNFburninhell1.0c.tar.gz]
其中ioc6使用了上面的方法,破解的速度比较快。

–[ 4 几个问题

在研究Burneye的过程中,发现了几个问题,目前还没解决,如果哪位高人知道原因,请
给我回信,不甚感激。

o 问题一
用GDB对加密的程序进行调试,断点设置在ELF头entry point时无效:
根据Fenris的README,Fenris似乎可以设置断点[4]
[root@localhost]# readelf -l ./ls.new | grep entry
Entry point address:               0x5371035
[root@localhost]# gdb -q ./ls.new

(gdb) b *0x5371035
Breakpoint 1 at 0x5371035
(gdb) r
Starting program: /burneye/src/ls.new
warning: shared library handler failed to enable breakpoint

o 问题二
用strace时,结果如下:
execve(“./ls.new”, [“./ls.new”], [/* 20 vars */]) = 0
signal(SIGTRAP, 0x5371991)              = ? ERESTARTNOINTR (To be restarted)
signal(SIGTRAP, 0x5371991)              = ? ERESTARTNOINTR (To be restarted)
signal(SIGTRAP, 0x5371991)              = ? ERESTARTNOINTR (To be restarted)
signal(SIGTRAP, 0x5371991)              = ? ERESTARTNOINTR (To be restarted)

无限循环

这两个问题,用我在Burneye中看到的antistrace都无法解释。

–[ 5 参考

[1] [http://www.packetstormsecurity.nl/groups/teso/index2.html]
[http://www.packetstormsecurity.nl/groups/teso/burneye-1.0-linux-static.tar.gz]
[http://www.packetstormsecurity.nl/groups/teso/burneye-1.0.1-src.tar.bz2]
[http://www.packetstormsecurity.nl/groups/teso/burneye-stripped.tar.gz]
[2] [http://www.phrack.org/show.php?p=58&a=5]
[3] [http://vx.netlux.org/lib/vsc04.html]
[4] [http://lcamtuf.coredump.cx/fenris/be.txt]

  1. 本文目前尚无任何评论.