这将创建构建 packer 教程代码所需的项目文件。然后运行：```
$ cmake --build ./ --config Release

如果一切顺利，test\_pack 和 test_unpack 应该会成功。如果你想亲自查看打包的结果，你应该会看到：```
$ ./packed.exe
I'm just a little guy!

每个文件夹中的 main.cpp 目前可以简单地写成这样：```cpp
#include <iostream>

int main(int argc, char *argv[]) {
    std::cout << "I'm just a little guy!" << std::endl;
    
    return 0;
}

我们还希望将我们的打包器声明为"MultiThreaded"（即 /MT）而不是"MultiThreadedDLL"（即 /MD），这样我们就不必担心运行时 DLL 依赖。```cmake
# this line will mark our packer as MultiThreaded, instead of MultiThreadedDLL
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

这里我应当说明，更准确地说，CMake 是一种 **构建系统**（make system）。它会根据给定的编译器，为当前环境生成相应的“构建系统”。在 Linux 上，这会为检测到（或指定）的编译器生成一个 makefile。而在 Windows 上，它会生成一个与我们所用 Visual Studio 版本兼容的 Visual Studio 工程，这意味着一旦你创建了 MSVC 构建系统，之后就可以直接使用 Visual Studio 完成一切操作——只要你愿意！归根结底，你是在用 CMake 来配置 Visual Studio。因此，你现在所做的，本质上就是在 Visual Studio 中创建项目里的文件树，就像 GUI 在创建项目时替你完成的那样。

接下来，我们需要添加我们所依赖的项目：```cmake
# this will add zlib as a build target
add_subdirectory(${PROJECT_SOURCE_DIR}/zlib-1.2.13)

# this will add our stub project
add_subdirectory(${PROJECT_SOURCE_DIR}/stub)

# this will add our test dummy project
add_subdirectory(${PROJECT_SOURCE_DIR}/dummy)

`CMAKE_CURRENT_BINARY_DIR` 是包含当前构建目录的字符串。Visual Studio 会根据配置将二进制文件转储到不同文件夹中，因此我们使用 `$<CONFIG>` 生成器表达式来获取当前构建配置。我们还使用 `$<TARGET_FILE:stub>` 生成器表达式来输出存根二进制文件编译后的可执行文件名。当我们将这些文件（生成的 RC 文件和生成的头文件）包含到项目中时，就可以成功地将存根二进制文件集成到打包器项目中。

接下来，我们为打包器项目声明一个可执行文件，并纳入前面收集的文件：```cmake
# this will create our packer executable
add_executable(packer ${HDR_FILES} ${SRC_FILES})
target_sources(packer PRIVATE ${RC_FILES} "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>/stub.rc")

你也可以只链接 `zlib`，如果你确实想要 zlib 的 DLL。

因为我们生成了文件（zlib 在其构建步骤中也是如此），我们需要在项目的包含头文件中包含动态目录。由于依赖 CMake 中项目位于项目根目录，我们也为我们的存根二进制文件添加了 zlib 包含目录：```cmake
# zlib, as part of its build step, drops a config header in the build directory.
# we do this too, so make sure to include everything for the build!
target_include_directories(packer PUBLIC
  "${PROJECT_SOURCE_DIR}/src"
  "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIG>"
  "${PROJECT_SOURCE_DIR}/zlib-1.2.13"
  "${CMAKE_CURRENT_BINARY_DIR}/zlib-1.2.13"
)

# also set the includes for the stub from here.
# we can't set this in the stub CMake file because CMake requires includes to be in the same
# directory as the build target. for this file, our build target is packer, so this sets
# up includes relative to the packer executable.
target_include_directories(stub PUBLIC
  "${PROJECT_SOURCE_DIR}/zlib-1.2.13"
  "${CMAKE_CURRENT_BINARY_DIR}/zlib-1.2.13"
)

现在，[stub](https://github.com/frank2/packer-tutorial/blob/main/stub/CMakeLists.txt) 和 [dummy](https://github.com/frank2/packer-tutorial/blob/main/dummy/CMakeLists.txt) 的 CMake 文件应该相当容易理解了！

更棒的是，CMake 可以为我们管理测试！而且到目前为止，为我们的 packer 生成测试是一个顺畅的过程：我们只需执行一条命令，如果退出码为 0，测试即通过。为了简单起见，我们假设通过将二进制文件作为可执行文件的第一个参数来打包它。我们希望得到类似这样的内容：```
$ packer.exe dummy.exe

最后，测试程序是否成功解包甚至更简单：直接运行输出文件即可！当您尝试模拟加载器时，仅仅运行就会导致程序崩溃，您会遇到多少错误，这不足为奇。再说一遍，为简单起见，假设该二进制文件应将输出命名为“packed.exe”以表示打包后的二进制文件。在这种情况下，您只需这样做：```cmake
add_test(NAME test_unpack
  COMMAND "packed.exe")

有了存储在易于操作的向量中的数据，我们现在可以解析存根镜像并向其中添加新数据。

### 解析 PE 文件

Windows 可执行文件最基本的组成部分分为两部分：其 *标头* 和其 *节数据*。标头包含许多对加载过程很重要的元数据，而节数据就是数据本身——它可以是可执行代码（即 `.text` 节）或任意数据（即 `.data` 节）。每个 Windows 可执行文件的起始处都以一个 `IMAGE_DOS_HEADER` 结构开始：```c
typedef struct _IMAGE_DOS_HEADER {      // DOS .EXE header
    WORD   e_magic;                     // Magic number
    WORD   e_cblp;                      // Bytes on last page of file
    WORD   e_cp;                        // Pages in file
    WORD   e_crlc;                      // Relocations
    WORD   e_cparhdr;                   // Size of header in paragraphs
    WORD   e_minalloc;                  // Minimum extra paragraphs needed
    WORD   e_maxalloc;                  // Maximum extra paragraphs needed
    WORD   e_ss;                        // Initial (relative) SS value
    WORD   e_sp;                        // Initial SP value
    WORD   e_csum;                      // Checksum
    WORD   e_ip;                        // Initial IP value
    WORD   e_cs;                        // Initial (relative) CS value
    WORD   e_lfarlc;                    // File address of relocation table
    WORD   e_ovno;                      // Overlay number
    WORD   e_res[4];                    // Reserved words
    WORD   e_oemid;                     // OEM identifier (for e_oeminfo)
    WORD   e_oeminfo;                   // OEM information; e_oemid specific
    WORD   e_res2[10];                  // Reserved words
    LONG   e_lfanew;                    // File address of new exe header
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

`IMAGE_NT_HEADERS` 整体而言是一个相当大的结构，因此我不会在此处完整记录它，但你可以在 [Microsoft 对该头文件的文档](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_nt_headers64) 中找到你需要了解的一切。无论如何，我们只需要这些头文件中的少数几个结构成员。现在，我们应该压缩目标二进制文件，以便添加到我们的存根数据中。

使用 zlib 的 `compress` 和 `decompress` 函数非常直接。如果你真的想在 zlib 上玩出花来，我建议使用 `deflate`/`inflate` 函数，它们允许你分块处理压缩流。参见 [zlib 手册](https://www.zlib.net/manual.html) 的“高级函数”一节。不过，对于这个示例，`compress` 和 `decompress` 就足够了。

首先，我们使用 zlib 的 `compressBound` 函数针对目标二进制文件的大小获取一个尺寸值。该尺寸值对应于在给定数据大小的情况下，容纳压缩数据流所需的最大值。然后我们可以使用这个值来分配一个 vector 以容纳压缩数据。`compress` 函数最终返回压缩缓冲区的真实大小，我们可以据此将 vector 调整为适当的大小。```cpp
// get the maximum size of a compressed buffer of the target binary's size.
uLong packed_max = compressBound(target.size());
uLong packed_real = packed_max;

// allocate a vector with that size
std::vector<std::uint8_t> packed(packed_max);
   
if (compress(packed.data(), &packed_real, target.data(), target.size()) != Z_OK)
{
   std::cerr << "Error: zlib failed to compress the buffer." << std::endl;
   ExitProcess(8);
}

// resize the buffer to the real compressed size
packed.resize(packed_real);

该函数本质上为可能未对齐的值补齐所需余量，使其正确对齐到给定边界。

为了正确地向我们的 PE 文件添加任意数据，我们需要特别留意 *文件对齐*——我们可以在稍后计算 PE 文件在内存中的正确对齐值，但目前添加我们的数据时，需要将文件对齐到文件对齐边界。在下面的代码中，我们先获取头部，再获取文件对齐边界和节对齐边界，然后将我们的存根数据对齐到文件边界，并追加新打包的节。```cpp
// next, load the stub and get some initial information
std::vector<std::uint8_t> stub_data = load_resource(MAKEINTRESOURCE(IDB_STUB), "STUB");
auto dos_header = reinterpret_cast<IMAGE_DOS_HEADER *>(stub_data.data());
auto e_lfanew = dos_header->e_lfanew;

// get the nt header and get the alignment information
auto nt_header = reinterpret_cast<IMAGE_NT_HEADERS64 *>(stub_data.data() + e_lfanew);
auto file_alignment = nt_header->OptionalHeader.FileAlignment;
auto section_alignment = nt_header->OptionalHeader.SectionAlignment;

// align the buffer to the file boundary if it isn't already
if (stub_data.size() % file_alignment != 0)
   stub_data.resize(align<std::size_t>(stub_data.size(), file_alignment));
      
// save the offset to our new section for later for our new PE section
auto raw_offset = static_cast<std::uint32_t>(stub_data.size());

// encode the size of our unpacked data into the stub data
auto unpacked_size = target.size();
stub_data.insert(stub_data.end(),
                 reinterpret_cast<std::uint8_t *>(&unpacked_size),
                 reinterpret_cast<std::uint8_t *>(&unpacked_size)+sizeof(std::size_t));

// add our compressed data.
stub_data.insert(stub_data.end(), packed.begin(), packed.end());

接下来，我们需要获取指向节表本身的指针。虽然从技术上讲，节表紧跟在NT头的可选头之后，但实际上可选头的大小是由NT文件头的 `SizeOfOptionalHeader` 值决定的。因此，为了到达那里，我们需要从 `OptionalHeader` 结构体的顶部开始，计算一个指向 `SizeOfOptionalHeader` 值所提供偏移量的指针。```cpp
// acquire a pointer to the section table
auto size_of_header = nt_header->FileHeader.SizeOfOptionalHeader;
auto section_table = reinterpret_cast<IMAGE_SECTION_HEADER *>(
   reinterpret_cast<std::uint8_t *>(&nt_header->OptionalHeader)+size_of_header
);

对于我们的新节区头，我们感兴趣的特定变量是 `Name`、`VirtualSize`、`VirtualAddress`、`SizeOfRawData`、`PointerToRawData` 和 `Characteristics`。此时，你应该意识到，之所以需要了解两种类型的对齐——文件对齐和内存对齐——是因为给定的 PE 可执行文件存在两种不同的内存状态：它在 *磁盘* 上的样子，以及它在 *内存* 中的样子，这是加载过程的结果。可以将某个 PE 文件配置为无论是否被加载都具有相同的内存布局，但这不是一种常见的配置。

`Name` 变量是你可以为新节区指定的 8 字节标签。我选择了 `.packed`，因为它是一个 7 字节的 ASCII 字符串，正好适合这个缓冲区。

`VirtualAddress` 指的是给定节区在内存中的偏移量。它也被称为“相对虚拟地址”（RVA）。`VirtualSize` 指的是节区在内存中的大小。（值得注意的是，MSVC 会将此值编译为节区的未对齐大小值，因此我们在自己的节区中也遵循这一约定。）`PointerToRawData` 指的是给定节区在磁盘上的偏移量，而 `SizeOfRawData` 指的是节区在磁盘上的大小。

`Characteristics` 比较复杂，除了其他标志外，它还可以表示节区是可读、可写还是可执行，请参阅 [`IMAGE_SECTION_HEADER` 文档](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_section_header) 的 characteristics 部分。目前，你只需要知道，我们需要的只是节区可读且标记为包含已初始化数据。```cpp
// get a pointer to our new section and the previous section
auto section = &section_table[section_index];
auto prev_section = &section_table[section_index-1];

// calculate the memory offset, memory size and raw aligned size of our packed section
auto virtual_offset = align(prev_section->VirtualAddress + prev_section->Misc.VirtualSize, section_alignment);
auto virtual_size = section_size;
auto raw_size = align<DWORD>(section_size, file_alignment);

// assign the section metadata
std::memcpy(section->Name, ".packed", 8);
section->Misc.VirtualSize = virtual_size;
section->VirtualAddress = virtual_offset;
section->SizeOfRawData = raw_size;
section->PointerToRawData = raw_offset;

// mark our section as initialized, readable data.
section->Characteristics = IMAGE_SCN_MEM_READ | IMAGE_SCN_CNT_INITIALIZED_DATA;

就这样！我们已成功地将压缩后的二进制文件作为新节区添加到存根中，以便存根最终解压并加载。现在，我们可以简单地将修改后的存根映像保存到磁盘。```cpp
std::ofstream fp("packed.exe", std::ios::binary);
   
if (!fp.is_open()) {
   std::cerr << "Error: couldn't open packed binary for writing." << std::endl;
   ExitProcess(9);
}
   
fp.write(reinterpret_cast<const char *>(stub_data.data()), stub_data.size());
fp.close();

### 从内存中读取我们的 PE

首先，我们需要以某种方式从正在运行的二进制文件中获取由加壳器创建的节的数据。是否有可能在运行时获取正在运行的二进制文件的头？是的，完全可以！[`GetModuleHandleA`](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulehandlea) 在传入空参数时，最终会返回一个指向我们正在运行的 PE 头的指针！因此，在运行时，你可以轻松访问内存中存在的映像。这就是为什么向二进制文件添加新节如此有吸引力：我们可以非常轻松地从二进制文件中解析出目标节。

结合我们关于解析节表的已学内容，以下这段代码应该很容易理解：```cpp
// find our packed section
auto base = reinterpret_cast<const std::uint8_t *>(GetModuleHandleA(NULL));
auto nt_header = get_nt_headers(base);
auto section_table = reinterpret_cast<const IMAGE_SECTION_HEADER *>(
   reinterpret_cast<const std::uint8_t *>(&nt_header->OptionalHeader)+nt_header->FileHeader.SizeOfOptionalHeader
);
const IMAGE_SECTION_HEADER *packed_section = nullptr;

for (std::uint16_t i=0; i<nt_header->FileHeader.NumberOfSections; ++i)
{
   if (std::memcmp(section_table[i].Name, ".packed", 8) == 0)
   {
      packed_section = &section_table[i];
      break;
   }
}

if (packed_section == nullptr) {
   std::cerr << "Error: couldn't find packed section in binary." << std::endl;
   ExitProcess(1);
}

如你所见，`get_image` 归根结底是一个相对简单的函数。我们已经从附加区段中提取出了目标二进制文件，现在需要将其加载。

### 加载我们的 PE 以供执行

Windows 可执行加载器在底层做了许多不同的事情，并支持多种不同的可执行配置。如果你不止于探索示例二进制文件，而是尝试更多内容，你很可能会遇到本教程所生成的打包器带来的各种错误，因为我们今天要构建的配置在技术上非常精简。但为了建立起能够执行的最基本配置，我们需要完成以下工作来加载一个现代的 Windows 可执行文件：

* 分配用于保存可执行映像内存表示形式的映像
* 将可执行映像的各个区段（包括头部）映射到该已分配的映像
* 解析我们的二进制文件所需的其他库的运行时导入
* 重新映射二进制映像，使映像中的各种地址指向它们本应指向的位置

让我们从 `load_image` 函数开始。首先，我们需要从加壳后的二进制文件中获取其节表。该节表最终会被映射到我们新分配的映像上。对于合适的可执行缓冲区来说，分配非常简单——从节头中取出 `SizeOfImage` 值，并使用 [`VirtualAlloc`](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc) 创建一个新的缓冲区，该缓冲区会为我们创建可读、可写且可执行的映像以进行映射。```cpp
// get the original image section table
auto nt_header = get_nt_headers(image.data());
auto section_table = reinterpret_cast<const IMAGE_SECTION_HEADER *>(
   reinterpret_cast<const std::uint8_t *>(&nt_header->OptionalHeader)+nt_header->FileHeader.SizeOfOptionalHeader
);

// create a new VirtualAlloc'd buffer with read, write and execute privileges
// that will fit our image
auto image_size = nt_header->OptionalHeader.SizeOfImage;
auto base = reinterpret_cast<std::uint8_t *>(VirtualAlloc(nullptr,
                                                          image_size,
                                                          MEM_COMMIT | MEM_RESERVE,
                                                          PAGE_EXECUTE_READWRITE));

if (base == nullptr) {
   std::cerr << "Error: VirtualAlloc failed: Windows error " << GetLastError() << std::endl;
   ExitProcess(3);
}

因此，加载过程中简单的那部分已经结束了：我们从内存中取回了二进制文件，将其解包，并将其各个节重新映射到可执行内存区域。在映像准备就绪后，我们就可以深入探讨加载过程的细枝末节了。

### 解析 API 导入

在可选头中有一个称为 *数据目录* 的结构。该目录包含大量关于可执行文件的不同信息，例如映像导出的符号以及图标、位图等资源。在本教程中，我们将解析两个数据目录：**导入目录** 和 **重定位目录**。每个目录都是硬编码的，其索引可以在 [可选头的文档](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32) 中找到（向下滚动到 `DataDirectory` 的说明）。如果某个数据目录的 `VirtualAddress` 值非 `null`，则该目录存在。```c
typedef struct _IMAGE_DATA_DIRECTORY {
    DWORD   VirtualAddress;
    DWORD   Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

要解析 API 导入，加载器会解析此目录，然后继续加载必要的库并获取它们导入的函数。幸运的是，这是一个相对容易解析的目录。

它以导入描述符结构开始：```c
typedef struct _IMAGE_IMPORT_DESCRIPTOR {
    union {
        DWORD   Characteristics;            // 0 for terminating null import descriptor
        DWORD   OriginalFirstThunk;         // RVA to original unbound IAT (PIMAGE_THUNK_DATA)
    } DUMMYUNIONNAME;
    DWORD   TimeDateStamp;                  // 0 if not bound,
                                            // -1 if bound, and real date\time stamp
                                            //     in IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (new BIND)
                                            // O.W. date/time stamp of DLL bound to (Old BIND)

    DWORD   ForwarderChain;                 // -1 if no forwarders
    DWORD   Name;
    DWORD   FirstThunk;                     // RVA to IAT (if bound this IAT has actual addresses)
} IMAGE_IMPORT_DESCRIPTOR;

该数据结构同时涵盖了导入与导出 thunk，因此可以忽略 `ForwarderString`。一个导入 thunk 既可以是 `Ordinal`，也可以是指向另一个结构 `IMAGE_IMPORT_BY_NAME` 的 RVA。*序号（ordinal）* 只是给定 DLL 导出表中的一个偏移量。`IMAGE_IMPORT_BY_NAME` 结构如下所示：```c
typedef struct _IMAGE_IMPORT_BY_NAME {
    WORD    Hint;
    CHAR   Name[1];
} IMAGE_IMPORT_BY_NAME, *PIMAGE_IMPORT_BY_NAME;

for every thunk:
    if ordinal bit set:
        import by ordinal
    else:
        import by name
        
    store import in first thunk

有趣的是，尽管 `GetProcAddress` 的参数类型被定义为 C 字符串，Windows 却期望你通过将序号值强制转换为 C 字符串来按序号导入。真奇怪。

有了这些解释，这个 while 循环现在应该就说得通了：```cpp
// when we reach an OriginalFirstThunk value that is zero, that marks the end of our array.
// typically all values in the import descriptor are zero, but we do this
// to be shorter about it.
while (import_table->OriginalFirstThunk != 0)
{
   // get a string pointer to the DLL to load.
   auto dll_name = reinterpret_cast<char *>(image + import_table->Name);

   // load the DLL with our import.
   auto dll_import = LoadLibraryA(dll_name);

   if (dll_import == nullptr) {
      std::cerr << "Error: failed to load DLL from import table: " << dll_name << std::endl;
      ExitProcess(4);
   }

   // load the array which contains our import entries
   auto lookup_table = reinterpret_cast<IMAGE_THUNK_DATA64 *>(image + import_table->OriginalFirstThunk);

   // load the array which will contain our resolved imports
   auto address_table = reinterpret_cast<IMAGE_THUNK_DATA64 *>(image + import_table->FirstThunk);

   // an import can be one of two things: an "import by name," or an "import ordinal," which is
   // an index into the export table of a given DLL.
   while (lookup_table->u1.AddressOfData != 0)
   {
      FARPROC function = nullptr;
      auto lookup_address = lookup_table->u1.AddressOfData;

      // if the top-most bit is set, this is a function ordinal.
      // otherwise, it's an import by name.
      if (lookup_address & IMAGE_ORDINAL_FLAG64 != 0)
      {
         // get the function ordinal by masking the lower 32-bits of the lookup address.
         function = GetProcAddress(dll_import,
                                   reinterpret_cast<LPSTR>(lookup_address & 0xFFFFFFFF));

         if (function == nullptr) {
            std::cerr << "Error: failed ordinal lookup for " << dll_name << ": " << (lookup_address & 0xFFFFFFFF) << std::endl;
            ExitProcess(5);
         }
      }
      else {
         // in an import by name, the lookup address is an offset to
         // an IMAGE_IMPORT_BY_NAME structure, which contains our function name
         // to import
         auto import_name = reinterpret_cast<IMAGE_IMPORT_BY_NAME *>(image + lookup_address);
         function = GetProcAddress(dll_import, import_name->Name);

         if (function == nullptr) {
            std::cerr << "Error: failed named lookup: " << dll_name << "!" << import_name->Name << std::endl;
            ExitProcess(6);
         }
      }

      // store either the ordinal function or named function
      // in our address table.
      address_table->u1.Function = reinterpret_cast<std::uint64_t>(function);

      // advance to the next entries in the address table and lookup table
      ++lookup_table;
      ++address_table;
   }

   // advance to the next entry in our import table
   ++import_table;
}

接下来，我们需要计算 *地址差值*。这仅仅是映像的 `ImageBase` 变量与虚拟映像基地址之间的差值。它用于快速调整二进制文件中硬编码地址的值。```cpp
// calculate the difference between the image base in the compiled image
// and the current virtually allocated image. this will be added to our
// relocations later.
std::uintptr_t delta = reinterpret_cast<std::uintptr_t>(image) - nt_header->OptionalHeader.ImageBase;

请注意被注释掉的 `TypeOffset` 数组，它实际上与此相关！重定位表由包含待调整地址的偏移量块组成，这些块通过 `VirtualAddress` RVA 标识。`TypeOffset` 数组包含编码后的字值，其中既包含重定位类型，也包含从 `VirtualAddress` 起需要调整的偏移量。就重定位类型而言，对于 64 位二进制文件，我们只需关注一种重定位类型。不幸的是，该结构实际上并不是一个变长结构体，因此我们必须进行一些指针运算才能获取 `TypeOffset` 数组。

如前所述，`TypeOffset` 数组包含编码后的字。高 4 位（掩码 `0xF000`）包含重定位类型，可在 PE 格式文档的[“基础重定位类型”部分](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format)找到。低 12 位（掩码 `0x0FFF`）包含从 `VirtualAddress` 参数开始的待调整偏移量。

解释起来很麻烦，最终只会让人感到非常困惑。获取指向待重定位地址的指针的方式如下：```cpp
auto ptr = reinterpret_cast<std::uintptr_t *>(image + relocation_table->VirtualAddress + offset);

所以，尽管解释重定位目录（relocation directory）很复杂，但在代码中，这些操作实际上非常容易理解。

通过 `SizeOfBlock` 变量，可以轻松推进到下一块重定位数据。该块包含我们头部的大小，*以及* `TypeOffset` 数组的大小。如果 `TypeOffset` 是一个静态大小的数组，我们只需通过调用重定位头部的 `sizeof` 来推进到下一条重定位条目。

解释完所有这些之后，你应该能够理解这段重定位代码：```cpp
// get the relocation table.
auto relocation_table = reinterpret_cast<IMAGE_BASE_RELOCATION *>(image + directory_entry.VirtualAddress);

// when the virtual address for our relocation header is null,
// we've reached the end of the relocation table.
while (relocation_table->VirtualAddress != 0)
{
   // since the SizeOfBlock value also contains the size of the relocation table header,
   // we can calculate the size of the relocation array by subtracting the size of
   // the header from the SizeOfBlock value and dividing it by its base type: a 16-bit integer.
   std::size_t relocations = (relocation_table->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(std::uint16_t);

   // additionally, the relocation array for this table entry is directly after
   // the relocation header
   auto relocation_data = reinterpret_cast<std::uint16_t *>(&relocation_table[1]);

   for (std::size_t i=0; i<relocations; ++i)
   {
      // a relocation is an encoded 16-bit value:
      //   * the upper 4 bits are its relocation type
      //     (https://learn.microsoft.com/en-us/windows/win32/debug/pe-format see "base relocation types")
      //   * the lower 12 bits contain the offset into the relocation entry's address base into the image
      //
      auto relocation = relocation_data[i];
      std::uint16_t type = relocation >> 12;
      std::uint16_t offset = relocation & 0xFFF;
      auto ptr = reinterpret_cast<std::uintptr_t *>(image + relocation_table->VirtualAddress + offset);

      // there are typically only two types of relocations for a 64-bit binary:
      //   * IMAGE_REL_BASED_DIR64: a 64-bit delta calculation
      //   * IMAGE_REL_BASED_ABSOLUTE: a no-op
      //
      if (type == IMAGE_REL_BASED_DIR64)
         *ptr += delta;
   }

   // the next relocation entry is at SizeOfBlock bytes after the current entry
   relocation_table = reinterpret_cast<IMAGE_BASE_RELOCATION *>(
      reinterpret_cast<std::uint8_t *>(relocation_table) + relocation_table->SizeOfBlock
   );
}

正如你所看到的，转移执行非常简单，尽管确实需要了解[函数指针](https://en.wikipedia.org/wiki/Function_pointer)。以下是我们相关的部分：```cpp
// acquire and call the entrypoint
auto entrypoint = loaded_image + nt_headers->OptionalHeader.AddressOfEntryPoint;
reinterpret_cast<void(*)()>(entrypoint)();

因此，我们用于调用入口点的函数指针——没有与其关联的类型——看起来像这样：```c
void (*entrypoint)()

Putting everything together, we can simply cast our entrypoint as a function pointer and call it in the same line, like so:

综上所述，我们可以简单地将入口点强制转换为函数指针，并在同一行中调用它，如下所示：```cpp
reinterpret_cast<void(*)()>(entrypoint)();

恭喜！你完成了！你刚刚编写了一个 Windows 加壳器！

## 进一步练习

* **攻击分析者**：学习实现[一些反调试技术](https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf)并强化你的加壳器。
* **扩展你的支持**：学习实现不可重定位的二进制文件，或学习实现更多目录，如线程局部存储目录（`IMAGE_TLS_DIRECTORY`）和资源目录（`IMAGE_RESOURCE_DIRECTORY`）。由于这一层面的文档比较缺乏，你可以在 [exe-rs](https://github.com/exe-rs) 中查看我的实现。
* **混淆你的存根**：尝试弄清楚分析者将如何解包你的二进制文件，并防止轻松解包，例如[擦除头部](https://github.com/frank2/packer-tutorial/blob/main/stub/src/main.cpp#L84)。