PE 文�g的字串表格式分析

溪流 — Wed, 23 Sep 2009 14:57:00 GMT

前几天公叔R��一个项目要�?MUI 支持�Q�于是要生成一�?XXX.dll.mui 的文件。如果这�?MUI DLL 的工�E�手动去建立、维护的话，那就�?@#@!#!了。当时是另外一个同事去做这斚w��的工作的�Q�后来他�l�了个工��P��按照它定义的��单格式来书写多语�a�字符�Ԍ��q�个工具�?x��)从一个已�l�设定好�?DLL ��目出发�Q�更�?RC 文�g里的字符�Ԍ��然后调用 VS �?IDE 来生�?DLL。再然后调用 MUIRCT.exe 来生�?MUI 文�g�?/p>

�q�可以节省很多时间。但是，�׃��是调�?VS IDE 来编译的�Q�一个带有近百个 Project �?Solution �~�译��h��q�不快，需要一��C��分钟。这让我有了另辟�y�径的念头�?/p>

何不自己来“编译”生�?DLL 呢？

不错�Q�后来我��往�q�个方向琢磨了。之前曾写过一个修�?PE 文�g版本��L(f��ng)��工��P��所以现在对�?PE 的资源格式有点�ƈ不那么恐惧了。但是，往�l�处做下去，问题��来了。现在网上的关于 PE 格式的文章，�?NTHeader 解释得很详细�Q�而资源段往往只讲到资源目录、资源项�Q�具体各��的存储�l�构却没有详�l�说明了�?/p>

�q�里�Q�关�?PE 头等��׃��多说了，请参考网上的文章�Q�特别是 http://bbs.pediy.com/showthread.php?threadid=21932。本文将着��g��资源�D�c�?/p>

首先来看一下几个数据结构（�q�些内容好多文章也有提及�Q�：(x��)

typedef struct _IMAGE_RESOURCE_DIRECTORY {
    DWORD   Characteristics;
    DWORD   TimeDateStamp;
    WORD    MajorVersion;
    WORD    MinorVersion;
    WORD    NumberOfNamedEntries;
    WORD    NumberOfIdEntries;
} IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;

�q�是资源目录�Q�共 16 字节�Q�其中最后两�?WORD 加�v来是紧跟在后面的子项的数目�?/p>

typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {
    union {
        struct {
            DWORD NameOffset:31;
            DWORD NameIsString:1;
        };
        DWORD   Name;
        WORD    Id;
    };
    union {
        DWORD   OffsetToData;
        struct {
            DWORD   OffsetToDirectory:31;
            DWORD   DataIsDirectory:1;
        };
    };
} IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;

�q�个��是紧跟在目录后面的资源目录��，�?8 字节。其中第一个成员�ؓ(f��)数据成员�Q�最高位 1 表示数据是字�W�串�Q�剩�?31 位是字符串的偏移�Q�否则就是数倹{��第二个成员最高位�?1 表示下一层仍然是目录�Q�后 31 位指向另一�?IMAGE_RESOURCE_DIRECTORY �l�构�Q�否则整个成员指向一�?IMAGE_RESOURCE_DATA_ENTRY �l�构�Q�这个马上会(x��)讲到�Q�。需要注意的是，�q�里的两�?Offset 都表�C�Z��资源�D�开头到目标位置的偏�U�R�?/p>

最后来�?IMAGE_RESOURCE_DATA_ENTRY�Q?/p>

typedef struct _IMAGE_RESOURCE_DATA_ENTRY {
    DWORD   OffsetToData;
    DWORD   Size;
    DWORD   CodePage;
    DWORD   Reserved;
} IMAGE_RESOURCE_DATA_ENTRY, *PIMAGE_RESOURCE_DATA_ENTRY;

�q�个�l�构是资源数据项�Q�也��是资源�?w��i)的叶子�Q�共 16 字节。其中第一个成�?OffsetToData 指向具体的数据，�q�个偏移是个 RVA�Q�跟前面两个不一栗��Size 表示具体数据的��d��节数。后两个成员可以�?0�Q�CodePage 不徏议��用�?/p>

PE 文�g中的资源��是通过�q�三个结构表�C�的�Q�它们都�?WinNT.h 中定义。通常�?x��)�?3 层结构，�W�一层表�C��源类型，�W�二层表�C?ID�Q�第三层标识语言�?/p>

以上所说的是我能查到的资料里能够提到的最大程度的内容了。但是具体的数据如何存储�Q�却几乎没有文章提及。于是，�׃��一两天旉��来慢慢的看、加上试验，我认为我对字�W�串资源的格式基本清楚了。（下面内容是我自己分析得出�Q�其正确性我�q�不保证�Q��?/p>

我们先来看一个具体的例子。这是一个资�?DLL�Q�用 Resource Hacker 查看如图�Q?/p>

其资源段数据如下�Q?/p>

我用桔色框�v来的是资源目录，用粉色框��h��的是资源目录��，用浅�l�色框�v来的是资源数据项�?/p>

先看�W�一行，�q�是�W�一层目录，最后两�?WORD �?0x0000 �?0x0001�Q�表�C�后面“命名”的目录��Ҏ(gu��)�� 0 个，使用 ID 的目录项�?1 个。第二行开头的 8 字节��是�q�个目录��，DWORD 0x00000006 表示资源�c�d��?6�Q�也��是字串表，后面的地址�?0x80000018�Q�最高位�?1�Q�表�C�指向的仍然是一个目录，其偏�U�L�� 0x00000018�Q�也��是 0218h 处�?/p>

0218h 处这个资源目录是�W�二层了。最后仍然是 0 �?1�Q�于是我们来�?0228h 处的目录��V��第一�?DWORD �?1�Q�这个跟 ID 有关�Q�稍候讨论。他的第二个 DWORD �?0x80000030�Q�仍然指向目录�?/p>

0230 处的目录是第三层目录。注意到最后是 0 �?2�Q�下面将有连�l�两个目录项。第一个目录项��gؓ(f��) 0x00000409�Q?033�Q�英�?��国)�Q�，偏移地址 0x00000050�Q�最高位 0�Q�表�C�指向的是数据项�Q�而不是目录了。第二个目录��gؓ(f��) 0x00000804�Q?052�Q�中�?中国)�Q�，偏移地址 0x0000009C�?/p>

�q�三层结构和 Resource Hacker 中显�C�的是一一对应的�?/p>

我们先来看英语的那个数据��，OffsetToData �?0x00001060�Q�RVA�Q�，Size �?0x0000003C。这�?DLL 文�g的资源段�?VirtualAddress �?1000h�Q?060h-1000h+200h = 260h�Q�我们来�?260h 处（其实��是紧接着的地方）。我�W�一�ơ看�q�段数据的时候也很奇怪，��Z��么前面空�?2 个字节，后面有多出好多字节。于是我改它�?ID�Q�试了好些次�Q�终于找到规律了。资源目录第二层�?ID�Q�下文称 ResID�Q�和最�l�的字符�?ID�Q�下文称 StrID�Q�有�q�么一个对应关�p�：(x��)ResID = StrID / 16 + 1。StrID 0 �?15 所对应�?ResID 都是 1�Q?StrID 16 �?31 对应 ResID 2�Q�……。反�q�来��_(d��)��资源目录中的 ResID 不能完全表达 StrID 的信息。所以，�?260h 开始的 3Ch 个字节的数据块里�Q�其实要存储 16 个字�W�串�Q�其 StrID 分别�?0�Q?�Q?�Q�……，15。这 16 个字�W�串是连�l�存储的�Q�结构是�Q�字�W�串长度�Q�WORD�Q?字符串内容（不含�l�束�W?0�Q�。那些空位就�׃��?WORD 0 来填充（也可理解为长度�ؓ(f��) 0 的字�W�串�Q�。我在图中用�U�褐色的竖线划出了这 16 个字�W�串的界限。后面那个中文的也是如此�Q�就不重复说了�?/p>

到现在�ؓ(f��)止，对于字串表的�l�构�Q�应该说差不多清楚了。于是拿�E�序�ȝ��成似乎不是难事了�Q�不�q�要注意的是�Q�目录项必须紧跟在目录后面，目录��Ҏ(gu��)��向的位置可以随意�?/p>

事实上上面这�?DLL 是我用程序生成的。我现在做到了从内部数据�l�构到资�?DLL �q�个�q�程的实现。如果这也可以被�U�Cؓ(f��)“编译”的话，现在是实��C��后端。至于前端，我还没想好原始资源格式。要惌��q�个工具有点用处�Q�原始资源格式必��要�Q?、��够简单（臛_��?RC 文�g��单）�Q��ƈ且维护方便；2、��够存储多语言字符丌Ӏ�这斚w��我希望大家能�l�我一些徏议�?/p>

当然�Q�本文的主要内容�q�是讨论字串表的格式�Q�这个已�l�讲完了�Q�所以，over~ bow~

溪流 2009-09-23 22:57 发表评论

久久99热只有频精品8,综合久久久久久中文字幕亚洲国产国产综合一区首 ,久久久久亚洲AV成人网人人网站

PE 文�g的字串表格式分析