最近看了看windows的脱壳大致的理解了脱壳的原理,之前没有怎么接触脱壳,通常只是选择没有壳的软件看看。在linux下的壳没有找到几个。只找到了一个upx的壳,在windows下是个弱壳。实际上在linux下面也是弱壳,完全可以使用"upx -d"的命令解决问题。但我总是喜欢自己手动的。呵呵....纯属于自娱自乐。
ok,开始我们的linux的upx的脱壳之旅.........
我在选择工具的时候花了很多时间,忽然发现GDB在upx面前是那么的苍白无力...也终于知道为什么有人说GDB不适合做逆向了...虽然软件在调试器里可以正常于运行,正常下断。但是根本无法查看反汇编的代码.......。
无奈无奈....使用传说中最好的工具 IDA 为此我特地简单的学习了一下IDC脚本的使用方法...
没有什么资料可以参考,是一件很不愉快的事情,因为不知道能不能成功。不管了,一步一步来吧...
我用“upx -d“ 脱出了原来的文件,发现文件是全的,没有任何部分丢失,所以我相信这些文件会出现在进程空间的某个时间的某个角落,这个很大的坚定了我手动脱壳的信心(但是实际上到这篇文章的结尾我也没有能够在找到完整的程序文件,但我相信理论上内存空间中应该会出现完整的文件的...)。
对我们目标软件加壳,命令如下,的确是个好用的压缩壳软件,直接有54%的压缩律。
[jun@beijihuCom dumpupx]$ ./upx mines
Ultimate Packer for eXecutables
Copyright (C) 1996 - 2008
UPX 3.03 Markus Oberhumer, Laszlo Molnar & John Reiser Apr 27th 2008
-------------------- ------ ----------- -----------
13960 -> 7556 54.13% linux/elf386 mines
[jun@beijihuCom dumpupx]$
好了,我们开始调试他了,加了壳以后,一般的调试软件已经对他无能为力了...
实验一下GDB 和 DDD 的效果...以及objdump
readelf还可以正常使用,(仅限于一部分功能.呵呵,不详谈了...)
[jun@beijihuCom dumpupx]$ readelf -e ./mines
ELF Header:
Magic: 7f 45 4c 46 01 01 01 03 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - Linux
ABI Version: 0
Type: EXEC (Executable file)
Machine: Intel 80386
Version: 0x1
Entry point address: 0xc02598
Start of program headers: 52 (bytes into file)
Start of section headers: 0 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 2
Size of section headers: 40 (bytes)
Number of section headers: 0
Section header string table index: 0
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000000 0x00c01000 0x00c01000 0x01d60 0x01d60 R E 0x1000
LOAD 0x0002fc 0x0804b2fc 0x0804b2fc 0x00000 0x00000 RW 0x1000
上面的输出,我们可以发现他的入口点是0xc02598 这个入口点已经和GCC编译出来的程序大不一样了。实际上重“upx -d“脱出来的效果来看,原来的入口点基本上是不会改变的,也就是说我们的手动脱壳的时候软件的入口点,加载方式都是和未加壳的软件是一样的...这一点又为我们的脱壳成功,增加了砝码..
继续....gdb 调试一下
(gdb) b *0xc02598
Breakpoint 1 at 0xc02598
(gdb) r
Starting program: /home/jun/Crack/dumpupx/mines
warning: shared library handler failed to enable breakpoint
(no debugging symbols found)
(gdb) disassemble
No function contains program counter for selected frame.
(gdb)
gdb看不反汇编代码,晕了都不知道下一步的操作是什么....看来是没有什么用了
祭起传说中的逆向利器IDA.学西习了一下,简单操作,我开始了调试之旅.
[jun@beijihuCom dumpupx]$ idal ./mines
等到加载完成,会停在入口处,呵呵在光标在call上直接按F4,程序运行,停到了入口出
这边我是这么想的,upx是压缩壳,当他把执行权交给原目标程序的时候,必定会有一个大的跳转,好多新手在windows脱壳,都是以这个为oep的标准的。linux应该也不会例外的...
F8单步到0xc025c8 跳到 oxc025d1 在 0xc025d3 又会跳回来。显然是个循环。不在循环里浪费时间了。我们向下找找,下面有个retn返回。光标移到上面F4。实际上没有什么把握。只是蒙的,结果很好,没有飞走.F8单步到了这里
单步一下,跳到了这里。
用来dump映像的idc脚本
#include
#define PT_LOAD 1
static main(void)
{
auto ImageBase,StartImg,EndImg;//基址 08048000
auto e_phoff;
auto e_phnum,p_offset;//paddr 0xc 地址,pmemsz ox14大小,p_offset 0x4
auto i,dumpfile;
ImageBase=0x08048000;
StartImg=0x08048000;
EndImg=0x0;
Message("%8x ",Dword(ImageBase));
if (Dword(ImageBase)==0x7f454c46 || Dword(ImageBase)==0x464c457f )
{
if(dumpfile=fopen("./dumpfile","w+"))
{
e_phoff=ImageBase+Word(ImageBase+0x1c);
e_phnum=Word(ImageBase+0x2c);
for(i=0;i
if (Dword(e_phoff)==PT_LOAD || Dword(e_phoff)==PT_DYNAMIC)
{ p_offset=Dword(e_phoff+0x4);
StartImg=Dword(e_phoff+0xc);
EndImg=Dword(e_phoff+0xc)+Dword(e_phoff+0x14);
dump(dumpfile,StartImg,EndImg,p_offset);
Message("dump LOAD%d ok. ",i);
}
e_phoff=e_phoff+0x20;
}
fseek(dumpfile,0x30,0);
fputc(0x00,dumpfile);
fputc(0x00,dumpfile);
fputc(0x00,dumpfile);
fputc(0x00,dumpfile);
fclose(dumpfile);
}else Message("dump err.");
}
static dump(dumpfile,startimg,endimg,offset)
{
auto i;
auto size;
size=endimg-startimg;
fseek(dumpfile,offset,0);
for ( i=0; i < size; i=i+1 )
{
fputc(Byte(startimg+i),dumpfile);
}
}
改变文件的属性,让他可以运行。
[jun@beijihuCom dumpupx]$ su
口令:
[root@beijihuCom dumpupx]# chmod 755 ./dumpfile
[root@beijihuCom dumpupx]# ./dumpfile
程序运行的很好..
另外,我之调试的时候,实际经过很多挫折...没有足够的经验嘛...不过些文章,截图的时候都很顺利..呵呵.共勉........