Esto creará los archivos de proyecto necesarios para compilar el código del tutorial de packer. Luego ejecute:```
$ cmake --build ./ --config Release

Si todo va bien, test\_pack y test_unpack deberían tener éxito. Si quieres ver los resultados del empaquetado tú mismo, deberías ver esto:```
$ ./packed.exe
I'm just a little guy!

Nuestro main.cpp en cada carpeta puede simplemente verse así por ahora:```cpp
#include <iostream>

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

También queremos declarar nuestro packer como "MultiThreaded" (es decir, /MT) en lugar de "MultiThreadedDLL" (es decir, /MD) para no tener que preocuparnos por las dependencias de DLL en tiempo de ejecución.```cmake
# this line will mark our packer as MultiThreaded, instead of MultiThreadedDLL
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

Aquí debo explicar que CMake se describe con más precisión como un **sistema de make**. Crea el "sistema de make" apropiado para el entorno dado según el compilador proporcionado. En Linux, esto sería un makefile para los compiladores detectados (o proporcionados). Para nosotros en Windows, esto produce un proyecto de Visual Studio compatible con nuestra versión de Visual Studio, lo que significa que una vez que creas el sistema de make de MSVC, ¡puedes usar Visual Studio para todo si así lo deseas! En última instancia, estás usando CMake para configurar Visual Studio. Así que lo que estás haciendo aquí es esencialmente crear los árboles de archivos de tu proyecto en Visual Studio que la GUI hace por ti al crear un proyecto.

A continuación, necesitamos agregar nuestros proyectos dependientes:```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` es la cadena que contiene tu directorio de build actual. Visual Studio vuelca los binarios en carpetas según su configuración, por lo que usamos la declaración de generador `$<CONFIG>` para obtener la configuración actual del build. También usamos la declaración de generador `$<TARGET_FILE:stub>` para generar el nombre del archivo ejecutable del binario stub una vez compilado. Cuando incluimos estos archivos en nuestro proyecto-- el archivo RC generado y la cabecera generada-- podemos integrar con éxito nuestro binario stub en el proyecto del packer.

A continuación, declaramos un ejecutable para nuestro proyecto del packer con los archivos recopilados anteriormente:```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")

You can instead link just `zlib` if you really want the DLL of zlib.

Because we have generated files (and so does zlib as part of its build step), we need to include the dynamic directories in the include headers for the project. Because of a dependency on projects being in the root of a project in CMake, we also add the zlib include directories for our stub binary as well:```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"
)

¡Los archivos CMake para [el stub](https://github.com/frank2/packer-tutorial/blob/main/stub/CMakeLists.txt) y [el dummy](https://github.com/frank2/packer-tutorial/blob/main/dummy/CMakeLists.txt) deberían ser bastante fáciles de entender ahora!

¡Lo bueno es que CMake puede encargarse de las pruebas por nosotros! Y a estas alturas, generar pruebas para nuestro packer es un proceso sencillo: podemos simplemente ejecutar un comando y, si el código de salida es 0, la prueba pasa. Para simplificar, digamos que empaquetamos un binario pasándolo como primer argumento del ejecutable. Queremos algo así:```
$ packer.exe dummy.exe

Finalmente, probar si el programa se desempaqueta o no es incluso más sencillo: ¡simplemente ejecuta la salida! No debería sorprenderte cuántos errores encontrarás que hacen fallar el programa simplemente al ejecutarlo cuando intentas emular el cargador. Digamos de nuevo, por simplicidad, que el binario debería generar "packed.exe" para un binario empaquetado. En ese caso, todo lo que tienes que hacer es esto:```cmake
add_test(NAME test_unpack
  COMMAND "packed.exe")

Con nuestros datos en un vector fácilmente maleable, ahora podemos analizar la imagen stub y añadir nuevos datos a ella.

### Análisis de un archivo PE

Un ejecutable de Windows, en sus componentes más básicos, se divide en dos partes: sus *cabeceras* y sus *datos de sección*. Las cabeceras contienen mucha metadata importante para el proceso de carga, y los datos de sección son simplemente eso-- datos, que pueden ser código ejecutable (es decir, la sección `.text`) o datos arbitrarios (es decir, una sección `.data`). El inicio de todo ejecutable de Windows comienza con una estructura `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` es una estructura bastante grande en general, así que no documentaré todo aquí, pero puedes encontrar todo lo que necesitas saber sobre ella en la [documentación de Microsoft sobre el encabezado](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_nt_headers64). Solo necesitaremos unos pocos miembros de estas estructuras de todos modos. Por ahora, deberíamos comprimir nuestro binario objetivo para añadirlo a los datos de nuestro stub.

Usar las funciones `compress` y `decompress` de zlib es muy sencillo. Si realmente quieres ponerte elegante trabajando con zlib, te sugiero usar las funciones `deflate`/`inflate`, que te permiten trabajar con flujos de compresión por fragmentos. Consulta la sección "Funciones avanzadas" del [manual de zlib](https://www.zlib.net/manual.html). Para este ejemplo, sin embargo, `compress` y `decompress` son suficientes.

Para empezar, obtenemos un valor de tamaño con la función `compressBound` de zlib sobre el tamaño de nuestro binario objetivo. Este valor de tamaño corresponde al máximo necesario para contener un flujo de datos comprimidos dado el tamaño de los datos. Luego podemos usar este valor para asignar un vector que contenga los datos comprimidos. La función `compress` eventualmente devuelve el tamaño real del búfer comprimido, al cual podemos redimensionar nuestro vector al tamaño adecuado.```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);

Esta función esencialmente rellena un valor potencialmente no alineado con el resto necesario para alinearlo correctamente a un límite determinado.

Para agregar correctamente datos arbitrarios a nuestro archivo PE, debemos prestar especial atención a la *alineación de archivo* en particular-- podemos calcular los valores alineados correctos para el archivo PE cuando esté en memoria más tarde, pero por ahora, al agregar nuestros datos, necesitamos alinear nuestro archivo al límite de alineación de archivo. En el siguiente código, obtenemos los encabezados, luego los límites de alineación de archivo y de alineación de sección, y procedemos a alinear nuestros datos del stub al límite del archivo y anexar nuestra sección recién empaquetada.```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());

A continuación, necesitamos obtener un puntero a la propia tabla de secciones. Si bien técnicamente sigue inmediatamente al encabezado opcional de los encabezados NT, el tamaño del encabezado opcional está determinado en realidad por el valor `SizeOfOptionalHeader` del encabezado de archivo NT. Por lo tanto, para llegar allí, necesitamos calcular un puntero desde el inicio de la estructura `OptionalHeader` hasta el desplazamiento proporcionado por el valor `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
);

Las variables particulares que nos interesan para el encabezado de nuestra nueva sección son `Name`, `VirtualSize`, `VirtualAddress`, `SizeOfRawData`, `PointerToRawData` y `Characteristics`. En este punto, debes ser consciente de que la razón por la que necesitas conocer dos tipos de alineación-- alineación de archivo y alineación de memoria-- es porque hay dos estados de memoria diferentes para un ejecutable PE dado: cómo se ve en *disco* y cómo se ve en *memoria*, como resultado del proceso de carga. Es posible configurar un archivo PE determinado para que tenga el mismo diseño de memoria tanto si está cargado como si no, pero no es una configuración frecuente.

La variable `Name` es la etiqueta de 8 bytes que puedes asignar a tu nueva sección. He elegido `.packed`, ya que es una cadena ASCII de 7 bytes y cabe perfectamente en el búfer.

`VirtualAddress` se refiere al desplazamiento de una sección determinada en memoria. También se conoce como "dirección virtual relativa", o RVA. `VirtualSize` se refiere al tamaño de la sección en memoria. (Cabe señalar que MSVC compila este valor como el valor de tamaño no alineado de la sección, por lo que también seguimos esta convención en nuestra sección). `PointerToRawData` se refiere al desplazamiento de una sección determinada en disco, y `SizeOfRawData` se refiere al tamaño de la sección en disco.

`Characteristics` es complicado y puede referirse a que una sección sea legible, escribible o ejecutable, además de otros indicadores; consulta la sección de características de [la documentación de `IMAGE_SECTION_HEADER`](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_section_header). Por ahora, debes saber que todo lo que necesitamos es que la sección sea legible y esté marcada como contenedora de datos inicializados.

Con todo esto en mente, ¡ya podemos crear nuestra nueva sección!```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;

¡Y eso es todo! Hemos añadido con éxito nuestro binario comprimido como una nueva sección para que nuestro stub lo descomprima y cargue más adelante. Ahora simplemente podemos guardar la imagen modificada del stub en disco.```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();

### Leyendo nuestro PE desde la memoria

Primero, necesitamos obtener de alguna manera los datos de la sección creada por nuestro packer desde el binario en ejecución. ¿Es posible obtener los encabezados del binario en ejecución en tiempo de ejecución? ¡Sí, absolutamente! [`GetModuleHandleA`](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulehandlea), con un argumento nulo, en última instancia devuelve un puntero a los encabezados de nuestro PE en ejecución. Así que en tiempo de ejecución, tienes acceso fácil a la imagen tal como existe en memoria. Esto es lo que hace tan atractivo agregar una nueva sección a nuestro binario: podemos analizar muy fácilmente nuestra sección objetivo desde el binario.

Con lo que hemos aprendido sobre el análisis de la tabla de secciones, esta sección de código debería ser fácil de entender:```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);
}

Como puedes ver, `get_image` era una función relativamente simple al final del día. Conseguimos extraer nuestro binario objetivo de la sección añadida, así que ahora tenemos que cargarlo.

### Cargando nuestro PE para ejecución

El cargador de ejecutables de Windows hace muchas cosas diferentes bajo el capó y soporta muchas configuraciones de ejecutables diferentes. Es probable que encuentres una variedad de errores con el empaquetador que produce este tutorial si exploras más allá del binario de ejemplo, ya que la configuración que construiremos hoy es técnicamente muy mínima. Pero para establecer ese mínimo absoluto hasta la ejecución, necesitamos hacer lo siguiente para cargar un ejecutable moderno de Windows:

* asignar la imagen que contiene la representación en memoria de la imagen del ejecutable
* mapear las secciones de nuestra imagen ejecutable, incluidos los encabezados, a esa imagen asignada
* resolver las importaciones en tiempo de ejecución a otras bibliotecas que nuestro binario necesita
* remapear la imagen del binario para que una variedad de direcciones en nuestra imagen apunten a donde se supone que deben apuntar

Comencemos con la función `load_image`. Para empezar, necesitamos adquirir nuestra tabla de secciones del binario empaquetado. Eventualmente, esta se mapeará sobre nuestra imagen recién asignada. Para un búfer de ejecutable adecuado, la asignación es muy simple: toma el valor `SizeOfImage` de nuestros encabezados de sección y crea un nuevo búfer con [`VirtualAlloc`](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc) que cree una imagen legible, escribible y ejecutable a la que podamos mapear.```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);
}

Así que la parte fácil del proceso de carga ha terminado: hemos recuperado nuestro binario de la memoria, lo hemos desempaquetado y hemos reasignado sus secciones a una región de memoria ejecutable. Con nuestra imagen preparada, podemos profundizar en los pormenores del proceso de carga.

### Resolución de importaciones de API

Dentro de las cabeceras opcionales hay algo llamado *directorio de datos*. Este directorio contiene mucha información diferente sobre el ejecutable, como símbolos exportados por la imagen y recursos como iconos y mapas de bits. En este tutorial vamos a analizar dos directorios de datos: el **directorio de importaciones** y el **directorio de reubicaciones**. Cada directorio está codificado de forma fija, y sus índices se pueden encontrar [en la documentación de la cabecera opcional](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32) (desplázate hacia abajo hasta la descripción de `DataDirectory`). Un directorio de datos está presente si su valor de `VirtualAddress` no es nulo.```c
typedef struct _IMAGE_DATA_DIRECTORY {
    DWORD   VirtualAddress;
    DWORD   Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

Para resolver las importaciones de API, el cargador analiza este directorio y, a continuación, procede a cargar las librerías necesarias y adquirir sus funciones importadas. Por suerte, es un directorio relativamente fácil de analizar.

Comienza con una estructura de descriptor de importación:```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;

Esta estructura de datos cubre tanto thunks de importación como de exportación, por lo que `ForwarderString` puede ignorarse. Un thunk de importación puede ser un `Ordinal` o un RVA a otra estructura, `IMAGE_IMPORT_BY_NAME`. Un *ordinal* es simplemente un desplazamiento en la tabla de exportación del DLL dado. Una estructura `IMAGE_IMPORT_BY_NAME` se ve así:```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

Curiosamente, a pesar de que `GetProcAddress` está tipada con una cadena C como argumento de la función, Windows espera que importes por ordinal simplemente convirtiendo el valor ordinal en una cadena C. Vete a saber.

Con estas explicaciones en mente, este bucle `while` ahora debería tener sentido:```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;
}

A continuación, necesitamos calcular el *delta de direcciones*. Esto es simplemente la diferencia entre la variable `ImageBase` de la imagen y la dirección base de la imagen virtual. Se utiliza para ajustar rápidamente los valores de las direcciones codificadas en el binario.```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;

Observa el array `TypeOffset` comentado, ¡en realidad es relevante aquí! Una tabla de reubicaciones consiste en bloques de offsets que contienen direcciones a ajustar, identificados por el RVA `VirtualAddress`. El array `TypeOffset` contiene valores de palabra codificados que contienen el tipo de reubicación así como el offset desde `VirtualAddress` a ajustar. En cuanto al tipo de reubicación, para binarios de 64 bits, solo nos interesa un tipo de reubicación. Desafortunadamente, esta estructura no es realmente una struct variádica, así que tenemos que hacer algo de aritmética de punteros para obtener el array `TypeOffset`.

Como se mencionó, el array `TypeOffset` contiene palabras codificadas. Los 4 bits superiores (máscara `0xF000`) contienen el tipo de reubicación, que se puede encontrar en la [sección "base relocation types"](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format) de la documentación del formato PE. Los 12 bits inferiores (máscara `0x0FFF`) contienen el offset desde el argumento `VirtualAddress` a ajustar.

Explicarlo es una tarea pesada y al final resulta muy confuso. Obtener un puntero a una dirección a reubicar se ve así:```cpp
auto ptr = reinterpret_cast<std::uintptr_t *>(image + relocation_table->VirtualAddress + offset);

Por muy complicado que sea explicar el directorio de reubicación, las operaciones son en realidad muy simples de entender en el código.

Avanzar al siguiente bloque de datos de reubicación es fácil gracias a la variable `SizeOfBlock`. Este bloque contiene el tamaño de nuestro encabezado *así como* el tamaño del array `TypeOffset`. Si `TypeOffset` fuera en su lugar un array de tamaño estático, simplemente avanzaríamos a la siguiente entrada de reubicación añadiendo la llamada a `sizeof` del encabezado de reubicación.

Con todo esto explicado, deberías ser capaz de entender este código de reubicación:```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
   );
}

Como puedes ver, transferir la ejecución es muy sencillo, aunque requiere conocimiento de [punteros a función](https://en.wikipedia.org/wiki/Function_pointer). Estos son nuestros fragmentos relevantes:```cpp
// acquire and call the entrypoint
auto entrypoint = loaded_image + nt_headers->OptionalHeader.AddressOfEntryPoint;
reinterpret_cast<void(*)()>(entrypoint)();

Por lo tanto, nuestro puntero de función para llamar a nuestro punto de entrada—sin tener un tipo asociado—se ve así:```c
void (*entrypoint)()

Poniendo todo junto, podemos simplemente convertir nuestro punto de entrada en un puntero a función y llamarlo en la misma línea, así:```cpp
reinterpret_cast<void(*)()>(entrypoint)();

¡Felicitaciones! ¡Ya está! ¡Acabas de escribir un packer de Windows!

## Ejercicios adicionales

* **Ataca al analista**: Aprende a implementar [algunas técnicas anti-debug](https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf) y refuerza tu packer.
* **Amplía tu compatibilidad**: Aprende a implementar un binario no reubicable, o aprende a implementar más directorios como el directorio de almacenamiento local de subprocesos (`IMAGE_TLS_DIRECTORY`) y el directorio de recursos (`IMAGE_RESOURCE_DIRECTORY`). Dado que la documentación es escasa a este nivel, puedes ver mis implementaciones en [exe-rs](https://github.com/exe-rs).
* **Ofusca tu stub**: Intenta averiguar cómo va a desempaquetar tu binario el analista y dificulta el desempaquetado, por ejemplo [borrando las cabeceras](https://github.com/frank2/packer-tutorial/blob/main/stub/src/main.cpp#L84).