pe-elf 文件加壳时的处理

 |=---------------------------------------------------------------------------=|
|=----------------------=[  pe/elf 文件加壳时的处理  ]=----------------------=|
|=---------------------------------------------------------------------------=|
|=---------------------------------------------------------------------------=|
|=--------------------------=[      By dummy     ]=--------------------------=|
|=-----------------------=[  <dummy_at_ph4nt0m.org>  ]=----------------------=|
|=---------------------------------------------------------------------------=|

               
前言：

    最初的壳是在感染型的病毒技术上发展出来的，加壳目的一般是压缩或加密。本文主要
就x86平台下win32 pe和linux elf 加壳程序的实现做简单介绍和总结，以自己以前写相关
程序做线索叙述，其中程序源码是开源的，有兴趣的朋友可以继续进行改进。

    ps: 其中有些地方很久没碰，可能有地方描述有误，还请见谅:)

正文：

    -------------------------------------------------------
    slm        x86 win32 r3 pe packer
    mimisys    x86 win32 r0 pe packer
    elfp       x86 linux r3 elf packer
    -------------------------------------------------------

一、一个壳的组成

    一个完整的壳程序主要由 2 个部分组成 packer 和 loader。它们具体的作用分别是：

    (1) packer
       
    负责将待加壳程序压缩和加密处理、把loader写到待加壳程序上。以slm的pakcer
    为例具体操作包括，pe有效性判断、优化可压缩数据、压缩和加密、添加loader、存放
    加壳参数和待加壳程序原数据（oep等等）、改写入口点等等。

    (2) loader
       
    主要工作是解压或解密被加壳的程序，以slm的loader为例具体的操作包括：获取自
    身位置、获取加壳参数、进行解压或解密、填充导入表、重定位、tls 初始化等等。

二、slm (x86 win32 r3 pe packer)

资料:
    http://www.microsoft.com/whdc/system/platform/firmware/PECOFF.mspx

工具：
    lordpe    pe 文件格式查看编辑工具
    dumpbin    vc 自带coff文件格式查看工具
    ollydbg    r3 调试工具

源码结构：
    ./slm/cm 公共头文件和模块
    ./slm/pk    packer 实现
    ./slm/sc    loader 实现

    在做这个时候对 pe 也是刚刚了解，所以 slm 很多地方现在看来有些问题:)。在第一
节已经简单描述 slm 的工作流程，下面主要就我当初做的时候遇到的问题做一些描述：

    (1) 资源的处理
       
    slm 的资源处理做的比较烦琐，当初目的是为了把可压缩资源数据归并到一起，进
    行一次压缩，不可压缩单独存放。下面简单介绍一下资源的目录数据格式，详细还是看
    看微软的文档和相关源码:)
       
        从IMAGE_NT_HEADERS.IMAGE_DATA_DIRECTORY[IMAGE_DIRECTORY_ENTRY_RESOURCE]
    取出资源数据的地址res_rva，经过转换后第一个结构体是IMAGE_RESOURCE_DIRECTORY

        IMAGE_RESOURCE_DIRECTORY:

            NumberOfIdEntries       目录下 id 名称入口项个数
            NumberOfNamedEntries    目录下 name 名称入口项个数

        紧跟着IMAGE_RESOURCE_DIRECTORY后面是IMAGE_RESOURCE_DIRECTORY_ENTRY结构
    数组，这个数组的元素个数是 NumberOfIdEntries + NumberOfNamedEntries。

        IMAGE_RESOURCE_DIRECTORY_ENTRY:

            Id                  目录id，只有NameIsString非真才有效
            NameIsString        目录名称是否是字符串，如果为真NameOffset有效
            NameOffset          目录名称串的偏移, 偏移是相对与res_rva*的。
            DataIsDirectory     如果为真 OffsetToData 有效，否则OffsetToDirectory
                                有效
            OffsetToData        指向资源数据，偏移类型rva
            OffsetToDirectory   指向子目录，偏移类型rva

        如果目录入口名称是字符串，通过NameOffset获取PIMAGE_RESOURCE_DIR_STRING_U
    的结构指针，目录名是unicode格式，并且不是以零结尾的字符串。如果目录名不是字符
    串而是id, 那么其值在winnt.h 定义。常见id有RT_ICON、RT_VERSION等等。

        结构大致简单描述完了，有点要注意OffsetToDirectory、OffsetToData修改时要
    进行 DWORD 对齐，否则会出现奇怪的现象。

    (2) 导入表处理

        从IMAGE_NT_HEADERS.IMAGE_DATA_DIRECTORY[IMAGE_DIRECTORY_ENTRY_IMPORT]
    取出导入表的地址imp_rva，经过转换后第一个结构体是IMAGE_IMPORT_DESCRIPTOR。
       
    IMAGE_IMPORT_DESCRIPTOR:

            Name               指向导入 dll 的名称，偏移类型 rva
            FirstThunk         指向 IMAGE_THUNK_DATA 结构体，偏移类型 rva
            OriginalFirstThunk 指向FirstThunk 的副本, 可以为空。偏移类型 rva
       
        导入由IMAGE_IMPORT_DESCRIPTOR结构数组组成，数组长度由一个Name域为空的结
    构表明。
       
        FirstThunk和OriginalFirstThunk都是指向以IMAGE_THUNK_DATA数组组成的数据
    结构，系统的加载器在进行导入表填充时，会把FirstThunk指向的结构修改掉。

    (3) TLS 处理

        这里说的tls是所谓的静态tls(在pe文件结构上进行实现)，关于什么是tls可以看看
    《windows 核心编程》线程那章。
       
        1、tls 是怎样的

        比如要在vc中声明一个tls变量需要这样__declspec(thread) int x = 0;在链接
    时这个变量会被链接器放入.tls的节中。这个节从外边看和其他的节没有什么不同，唯
    一的区别在IMAGE_DATA_DIRECTORY[IMAGE_DIRECTORY_ENTRY_TLS]指向的一个结构会对
    此节进行描述，这个结构是IMAGE_TLS_DIRECTORY。

        IMAGE_TLS_DIRECTORY:

            StartAddressOfRawData   tls数据开始地址类型va
            EndAddressOfRawData     tls数据结束地址类型va
            AddressOfIndex;         tls slot的地址，默认tls slot为0

            AddressOfCallBacks      指向一个PIMAGE_TLS_CALLBACK的数组，这个数组
                                    以0结尾，每个PIMAGE_TLS_CALLBACK都是va类型
           
            SizeOfZeroFill          数据区需要进行清 0 数据的大小
            Characteristics
       
        2、系统加载器怎样处理exe的tls

            系统加载器在完成重定位和输入表填充后，就开始处理tls。如果存在tls_dir，
    求出tls数据的大小EndAddressOfRawData - StartAddressOfRawData +
    SizeOfZeroFill, 按照大小分配一块内存，地址存入(PDWORD)fs:[0x2c] +
    tls_slot, 接着拷贝StartAddressOfRawData -> EndAddressOfRawData之间的数
    据到新分配的内存中，然后使用SizeOfZeroFill 清零剩下的数据，然后进行循环回
    调AddressOfCallBacks中的函数，PIMAGE_TLS_CALLBACK函数和DllMain原型很像，
    只是没有返回值。

        3、系统加载器怎样处理dll的tls

            首先明确dll是可以使用tls的，唯一的不同是AddressOfCallBacks调用方式会
    有些区别。如果目标dll是被静听链接到其他文件上，在进程创建完成时即被加载，
    那么他的tls callback会触发，而LoadLibrary方式加载不会触发。

    (4) rva & raw 转换

        pe 文件中许多结构域的指针类型是rva, rva是pe文件由系统加载后，方法相关数
    据的相对偏移量。而我们进行加壳处理时，是直接map的文件数据访问都是使用文件指
    针，这就需要rva进行转换。(每次做pe相关工具时，我都会习惯写一个这样的函数，现在
    不下10中版本，竟然没有一个可以保证是正确的 - -）

        下面这个是最新的rva2raw版本，不保证正确性。

三、mimisys (x86 win32 r0 pe packer)

资料：
    Windows Research Kernel
        wrk/base/ntos/mm/sysload.c:MmLoadSystemImage
工具:
    syser     内核调试器，你也可以选择其他的r0调试器
    vmware    如果不想频繁重启，需要一个虚拟机

    文件格式的一些处理参考slm, 这里主要就r0 pe和r3 pe区别做介绍：

    (1) 节和页

        r0空间的内存常常很紧张，就导致sys section属性有几个特殊地方

        1、可换出和禁止换出
           
        在内存不足时，系统内存管理器，会枚举已加载的section object, 如果存在
    pageout属性，那么系统内存管理器就会换出这个节对应的页（这个节经过系统页对
    齐后换出内存）节对齐原则VirtualAddress向上、VirtualSize向下。禁止换出如
    名字所名这个节将永驻内存。

        2、节对齐小于一页
           
        大多数sys的节对齐指数都是小于一页，系统加载器在处理这类文件时相当很
    简单。加载后文件和磁盘上的文件布局基本一致。当节对齐小于一页时，
    SizeOfRawData必须大于等于VirtualSize，即不支持未初始化节。mimisys通过增
    加SizeOfImage在文件加载后分配一个未初始化的缓冲区，保证解压过程。

    (2) checksum校验

        一句话: 只有正确的checksum sys文件才允许被加载。

    (3) win2k相关问题

        win2k的系统加载器和其他nt系统有几处不同，r3和r0都会有一些区别，比如r3 pe
    的必须要有导入表，否则拒绝加载，r0 pe必须要有重定位信息，否则也会拒绝加载。这
    种情况需要构造一个空的重定位目录即可。

        mimisys采取的是合并节，导致加壳后只剩下两个节，第一个节是loader, 存放
    loader和各种加壳参数，第二个节是原程序优化压缩后的数据（移动重定位，移动资源等
    等）。两个节的属性都是不允许换出的。

四、elfp (x86 linux r3 elf packer)

资料：
    Tool Interface Standard (TIS) Executable and Linking Format
        http://www.x86.org/ftp/manuals/tools/elf.pdf
    毛德操 《漫谈内核兼容》8,9 ELF映像的装入
        http://linux.insigma.com.cn/jszl.asp?docid=132762762
        http://linux.insigma.com.cn/jszl.asp?docid=133617926
    linux 内核源码
        linux/fs/binfmt_elf.c:load_elf_binary

工具:
    objdump    进行elf文件格式的结构查看
               http://www.gnu.org/software/binutils/binutils.html
               
    ald        汇编级调试器，gdb无法调试没有调试信息文件的。
               http://ald.sourceforge.net/
   
    elfp是在magiclinux完成的linux elf文件压缩壳。

    elf的格式是linux下主要的可执行文件格式，它也是在coff上基础上设计的，所以它和
pe文件的格式很相似，下面的叙述过程中会和 pe 文件以对比形式进行描述。

    elf文件的第一个数据结构是以Elf32_Ehdr开始

    typedef struct
    {
      unsigned char e_ident[EI_NIDENT];     /* Magic number and other info */
      Elf32_Half    e_type;                 /* Object file type */
      Elf32_Half    e_machine;              /* Architecture */
      Elf32_Word    e_version;              /* Object file version */
      Elf32_Addr    e_entry;                /* Entry point virtual address */
      Elf32_Off     e_phoff;                /* Program header table file offset */
      Elf32_Off     e_shoff;                /* Section header table file offset */
      Elf32_Word    e_flags;                /* Processor-specific flags */
      Elf32_Half    e_ehsize;               /* ELF header size in bytes */
      Elf32_Half    e_phentsize;            /* Program header table entry size */
      Elf32_Half    e_phnum;                /* Program header table entry count */
      Elf32_Half    e_shentsize;            /* Section header table entry size */
      Elf32_Half    e_shnum;                /* Section header table entry count */
      Elf32_Half    e_shstrndx;             /* Section header string table index */
    } Elf32_Ehdr;

    e_ident        在 elf.h 中对应的 ELFMAG 宏，长度是四个字节
    e_entry        入口点映像偏移(映像偏移即 pe 中所说的 rva)
    e_phoff        Elf32_Phdr 数组的文件偏移
    e_shoff        Elf32_Shdr 数组的文件偏移
    e_ehsize       Elf32_Ehdr 结构的大小
    e_phentsize    Elf32_Phdr 结构大小
    e_phnum        Elf32_Phdr 数组成员个数
    e_shentsize    Elf32_Shdr 结构大小
    e_shnum        Elf32_Shdr 数组成员个数
   
    在Elf32_Ehdr之后即Elf32_Phdr数组，Elf32_Phdr的地址通过Elf32_Ehdr.e_ehsize来
确定。Elf32_Ehdr数组（或叫段表)，你可以把phdr看做pe的节表。

    typedef struct
    {
      Elf32_Word    p_type;            /* Segment type */
      Elf32_Off     p_offset;        /* Segment file offset */
      Elf32_Addr    p_vaddr;        /* Segment virtual address */
      Elf32_Addr    p_paddr;        /* Segment physical address */
      Elf32_Word    p_filesz;        /* Segment size in file */
      Elf32_Word    p_memsz;        /* Segment size in memory */
      Elf32_Word    p_flags;        /* Segment flags */
      Elf32_Word    p_align;        /* Segment alignment */
    } Elf32_Phdr;
   
    p_type    描述这个段的加载行为属性
    p_offset  段数据在文件中偏移，类似pe节中的PointerToRawData
    p_vaddr   段数据加载后在映像中偏移, 类似pe节中的VirtualAddress
    p_filesz  段数据在文件中大小，类型pe节中的SizeOfRawData
    p_memsz   段数据加载后在映像中大小，类型pe节中的VirtualSize
    p_flags   描述这个段的内存属性，类似pe节中的节属性
    p_align   段对齐粒度

    p_type主要的类型有

        PT_LOAD      这个段需要装载到内存中
        PT_PHDR      这个段存放的是Elf32_Phdr数组
        PT_INTERP    这个段存放一个解释器名，请求系统加载器把映像装载需求转给这
             个解释器，关于elf的解释器问题，可以理解为windows下ntdll装载
     pe文件，elf文件的解释器主要负责重定位、导入表填充等操作

    p_flags 主要类型有

        PF_X         这个段可执行
        PF_W         这个段可写
        PF_R         这个段可读

    在Elf32_Ehdr(段表)之后便是Elf32_Shdr数组(节表)，你可能到这里很奇怪了，怎么这
个叫节表？如果你熟悉pe应该知道节表对pe文件的重要性，但这个可不是pe中的那个节表，你
应该把它看做nt header中data_dir[]结构，加载器或调试器等工具会通过节名确定节具体
用途，比如存储调试信息、版本信息、字符串表等等、elfp在加壳过程会丢弃节表。

    下面简单讲讲elfp的loader处理过程（加壳过程很简单），在一个elf文件被加载后，它的
入口点在执行之前，堆栈中会由系统加载器push的一些参数。

    //  堆栈结构：
    //  +-------------------+
    //  |   return address  |        返回地址
    //  +-------------------+
    //  |   argc            |        参数个数
    //  +-------------------+
    //  |   argv[?], NULL   |        参数表，以 NULL 结尾
    //  +-------------------+
    //  |   envp[?], NULL   |        环境表，以 NULL 结尾
    //  +-------------------+
    //  |   auxv[?]         |        中文不知道叫什么它，这个主要是给解释器使用,
    //  +-------------------+        存放这个elf的相关信息如果被加壳程序需要解
                                     释器，你需要重写正确填写这个参数，让解释器可
     以正确的找到相关数据的地址。
                                    
    elfp壳loader的执行流程大致如下:

        申请内存-->把每个段解压到指定的地址上-->获取被加壳程序原始信息-->检查原
    始段表、重写 auxv-->加载解释器-->调用解释器

    关于 elf 的解释器，可以参考资料链接上的文字，那里比我描述的完整。

五、附录

[1] 本文代码
    ./pstzine_0A_01.zip