Isso criará os arquivos de projeto necessários para compilar o código do tutorial do Packer. Em seguida, execute:```
$ cmake --build ./ --config Release

Se tudo correr bem, test\_pack e test_unpack devem ser concluídos com êxito. Se você quiser ver os resultados do empacotamento por si mesmo, deverá ver isto:```
$ ./packed.exe
I'm just a little guy!

Nosso main.cpp em cada pasta pode simplesmente ficar assim por enquanto:```cpp
#include <iostream>

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

Também queremos declarar nosso empacotador como "MultiThreaded" (ou seja, /MT) em vez de "MultiThreadedDLL" (ou seja, /MD) para não termos que nos preocupar com dependências de DLL em tempo de execução.```cmake
# this line will mark our packer as MultiThreaded, instead of MultiThreadedDLL
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

Aqui devo explicar que o CMake é mais precisamente descrito como um **sistema de make**. Ele cria o "sistema de make" adequado para o ambiente fornecido com base no compilador fornecido. No Linux, isso seria um makefile para os compiladores detectados (ou fornecidos). Para nós no Windows, isso produz um projeto do Visual Studio compatível com a nossa versão do Visual Studio, o que significa que, uma vez que você crie o sistema de make do MSVC, você pode simplesmente usar o Visual Studio para tudo, se assim desejar! Em última análise, você está usando o CMake para configurar o Visual Studio. Então, o que você está fazendo aqui é essencialmente criar as árvores de arquivos do seu projeto no Visual Studio que a GUI faz para você ao criar um projeto.

Em seguida, precisamos adicionar nossos projetos dependentes:```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` é a string que contém o seu diretório de build atual. O Visual Studio despeja os binários em pastas com base na sua configuração, então usamos a instrução de gerador `$<CONFIG>` para obter a configuração atual do build. Também usamos a instrução de gerador `$<TARGET_FILE:stub>` para gerar o nome do arquivo executável do binário stub depois que ele for compilado. Quando incluímos esses arquivos em nosso projeto -- o arquivo RC gerado e o cabeçalho gerado -- podemos integrar com sucesso nosso binário stub ao projeto packer.

Em seguida, declaramos um executável para nosso projeto packer com os arquivos coletados 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")

Em vez disso, você pode vincular apenas `zlib` se realmente quiser a DLL do zlib.

Como temos arquivos gerados (e o zlib também, como parte de sua etapa de build), precisamos incluir os diretórios dinâmicos nos cabeçalhos de inclusão do projeto. Devido a uma dependência de os projetos estarem na raiz de um projeto no CMake, também adicionamos os diretórios de inclusão do zlib para o nosso binário stub:```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"
)

Os arquivos CMake para [o stub](https://github.com/frank2/packer-tutorial/blob/main/stub/CMakeLists.txt) e [o dummy](https://github.com/frank2/packer-tutorial/blob/main/dummy/CMakeLists.txt) devem ser bem fáceis de entender agora!

O melhor é que o CMake pode gerenciar os testes por nós! E neste ponto, gerar testes para o nosso empacotador é um processo tranquilo: podemos simplesmente emitir um comando, e se o código de saída for 0, o teste passa. Para simplificar, digamos que empacotamos um binário passando-o como primeiro argumento do executável. Queremos algo assim:```
$ packer.exe dummy.exe

Finalmente, testar se o programa descompacta ou não é ainda mais simples: basta executar a saída! Não deveria ser surpreendente quantos erros você encontrará que travam o programa simplesmente ao executá-lo quando você está tentando emular o loader! Digamos novamente, por uma questão de simplicidade, que o binário deve gerar a saída para "packed.exe" para um binário compactado. Nesse caso, tudo o que você precisa fazer é isto:```cmake
add_test(NAME test_unpack
  COMMAND "packed.exe")

Com nossos dados em um vetor facilmente maleável, agora podemos analisar a imagem stub e adicionar novos dados a ela.

### Parsing a PE file

Um executável Windows, em seus componentes mais básicos, é dividido em duas partes: seus *cabeçalhos* e seus *dados de seção*. Os cabeçalhos contêm muitos metadados importantes para o processo de carregamento, e os dados de seção são apenas isso-- dados, que podem ser código executável (ou seja, a seção `.text`) ou dados arbitrários (ou seja, uma seção `.data`). O início de todo executável Windows começa com uma estrutura `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` é uma estrutura bastante grande no geral, então não vou documentar tudo aqui, mas você pode encontrar tudo o que precisa saber sobre ela na [documentação da Microsoft sobre o cabeçalho](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_nt_headers64). De qualquer forma, só precisaremos de alguns membros da estrutura desses cabeçalhos. Por enquanto, devemos comprimir nosso binário alvo para adicioná-lo aos dados do nosso stub.

Usar as funções `compress` e `decompress` do zlib é bastante direto. Se você realmente quiser se aprofundar no trabalho com o zlib, sugiro usar as funções `deflate`/`inflate`, que permitem trabalhar em fluxos de compressão em blocos por vez. Veja a seção "Advanced Functions" do [manual do zlib](https://www.zlib.net/manual.html). Para este exemplo, porém, `compress` e `decompress` serão suficientes.

Para começar, obtemos um valor de tamanho com a função `compressBound` do zlib com base no tamanho do nosso binário alvo. Esse valor de tamanho corresponde ao valor máximo necessário para armazenar um fluxo de dados compactado, dado o tamanho dos dados. Podemos então usar esse valor para alocar um vetor que conterá os dados compactados. A função `compress` eventualmente retorna o tamanho real do buffer compactado, para o qual podemos redimensionar nosso vetor para o tamanho adequado.```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 função essencialmente preenche um valor potencialmente desalinhado com o restante necessário para ser devidamente alinhado a um determinado limite.

Para adicionar corretamente dados arbitrários ao nosso arquivo PE, precisamos estar atentos, em particular, ao *alinhamento de arquivo* — podemos calcular os valores alinhados adequados para o arquivo PE quando ele estiver em memória mais tarde, mas por enquanto, ao adicionar nossos dados, precisamos alinhar nosso arquivo ao limite de alinhamento de arquivo. No código a seguir, obtemos os cabeçalhos, depois os limites de alinhamento de arquivo e de alinhamento de seção, e então prosseguimos para alinhar nossos dados de stub ao limite do arquivo e anexar nossa seção recém-empacotada.```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());

Em seguida, precisamos obter um ponteiro para a própria tabela de seções. Embora, tecnicamente, ela venha imediatamente após o cabeçalho opcional dos cabeçalhos NT, o tamanho do cabeçalho opcional é, na verdade, determinado pelo valor `SizeOfOptionalHeader` do cabeçalho de arquivo NT. Então, para chegar até ela, precisamos calcular um ponteiro do topo da struct `OptionalHeader` até o deslocamento fornecido pelo 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
);

As variáveis específicas que nos interessam para o nosso novo cabeçalho de seção são `Name`, `VirtualSize`, `VirtualAddress`, `SizeOfRawData`, `PointerToRawData` e `Characteristics`. Neste ponto, você deve estar ciente de que a razão pela qual você precisa conhecer dois tipos de alinhamento-- alinhamento de arquivo e alinhamento de memória-- é porque existem dois tipos diferentes de estados de memória para um determinado executável PE: como ele se parece no *disco*, e como ele se parece na *memória*, como resultado do processo de carregamento. É possível configurar um determinado arquivo PE para ter o mesmo layout de memória independentemente de ser carregado ou não, mas não é uma configuração frequente.

A variável `Name` é o rótulo de 8 bytes que você pode dar à sua nova seção. Escolhi `.packed`, pois é uma string ASCII de 7 bytes e cabe perfeitamente no buffer.

`VirtualAddress` refere-se ao deslocamento de uma determinada seção na memória. Também é conhecido como "endereço virtual relativo", ou RVA. `VirtualSize` refere-se ao tamanho da seção na memória. (Vale notar que o MSVC compila esse valor como o valor de tamanho não alinhado da seção, então seguimos essa convenção também em nossa seção.) `PointerToRawData` refere-se ao deslocamento de uma determinada seção no disco, e `SizeOfRawData` refere-se ao tamanho da seção no disco.

`Characteristics` é complicado e pode se referir a uma seção ser legível, gravável ou executável, além de outros indicadores; veja a seção de características da [documentação de `IMAGE_SECTION_HEADER`](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_section_header). Por enquanto, você deve saber que tudo o que precisamos é que a seção seja legível e marcada como contendo dados inicializados.

Com tudo isso em mente, agora podemos criar nossa nova seção!```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;

E é isso! Adicionamos com sucesso nosso binário compactado como uma nova seção para o nosso stub eventualmente descomprimir e carregar. Agora podemos simplesmente salvar a imagem do stub modificada em 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();

### Lendo nosso PE da memória

Primeiro, precisamos de alguma forma obter os dados da nossa seção criada pelo packer do binário em execução. É possível obter os cabeçalhos do binário em execução em tempo de execução? Sim, absolutamente! [`GetModuleHandleA`](https://learn.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-getmodulehandlea), com um argumento nulo, em última análise, retorna um ponteiro para os cabeçalhos do nosso PE em execução! Então, em tempo de execução, você tem acesso fácil à imagem como ela existe na memória. Isso é o que torna adicionar uma nova seção ao nosso binário tão atraente: podemos analisar muito facilmente nossa seção alvo do binário.

Com o que aprendemos sobre a análise da tabela de seções, esta seção de código deve 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 você pode ver, `get_image` era uma função relativamente simples no final das contas. Extraímos nosso binário alvo da seção anexada, então agora precisamos carregá-lo.

### Carregando nosso PE para execução

O carregador de executáveis do Windows faz muitas coisas diferentes nos bastidores e suporta muitas configurações diferentes de executáveis. É provável que você encontre uma variedade de erros com o empacotador que este tutorial produz se explorar mais do que o binário de exemplo, pois a configuração que construiremos hoje é tecnicamente muito mínima. Mas, para estabelecer esse mínimo absoluto para execução, precisamos fazer as seguintes coisas para carregar um executável Windows moderno:

* alocar a imagem que contém a representação em memória da imagem do executável
* mapear as seções da nossa imagem executável, incluindo os cabeçalhos, para essa imagem alocada
* resolver as importações em tempo de execução para outras bibliotecas que nosso binário precisa
* remapear a imagem do binário para que vários endereços na nossa imagem apontem para onde deveriam

Vamos começar com a função `load_image`. Para começar, precisamos obter nossa tabela de seções do binário empacotado. Isso eventualmente será mapeado na nossa imagem recém-alocada. Para um buffer de executável adequado, a alocação é muito simples: pegue o valor `SizeOfImage` dos nossos cabeçalhos de seção e crie um novo buffer com [`VirtualAlloc`](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc) que crie uma imagem legível, gravável e executável para mapearmos.```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);
}

Então a parte fácil do processo de carregamento acabou: recuperamos nosso binário da memória, desempacotamos e remapeamos suas seções para uma região de memória executável. Com nossa imagem preparada, podemos mergulhar nos detalhes minuciosos do processo de carregamento.

### Resolvendo importações de API

Dentro dos cabeçalhos opcionais há algo chamado *diretório de dados*. Esse diretório contém muitas informações diferentes sobre o executável, como símbolos exportados pela imagem e recursos como ícones e bitmaps. Neste tutorial, vamos analisar dois diretórios de dados: o **diretório de importação** e o **diretório de realocação**. Cada diretório é fixo (hardcoded), e seus índices podem ser encontrados [na documentação do cabeçalho opcional](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_optional_header32) (role para baixo até a descrição de `DataDirectory`). Um diretório de dados está presente se o valor de `VirtualAddress` for não nulo.```c
typedef struct _IMAGE_DATA_DIRECTORY {
    DWORD   VirtualAddress;
    DWORD   Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

Para resolver importações de API, o carregador analisa este diretório e, em seguida, carrega as bibliotecas necessárias e adquire as suas funções importadas. Felizmente, é um diretório relativamente fácil de analisar.

Começa com uma estrutura de descritor de importação:```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 estrutura de dados cobre tanto thunks de importação quanto de exportação, portanto `ForwarderString` pode ser ignorado. Um thunk de importação pode ser um `Ordinal` ou um RVA para outra estrutura, `IMAGE_IMPORT_BY_NAME`. Um *ordinal* é simplesmente um deslocamento na tabela de exportação da DLL fornecida. Uma estrutura `IMAGE_IMPORT_BY_NAME` tem esta aparência:```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, apesar de `GetProcAddress` ser tipada com uma C-string como argumento para a função, o Windows espera que você importe por ordinal simplesmente convertendo o valor ordinal como uma C-string. Vai entender.

Com essas explicações em mente, este loop while agora deve fazer 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;
}

Em seguida, precisamos calcular o *delta de endereço*. Isso é simplesmente a diferença entre a variável `ImageBase` da imagem e o endereço base da imagem virtual. É usado para ajustar rapidamente os valores de endereços fixos no binário.```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;

Observe o array `TypeOffset` comentado, na verdade ele é relevante aqui! Uma tabela de realocação consiste em blocos de offsets contendo endereços a ajustar, identificados pelo RVA `VirtualAddress`. O array `TypeOffset` contém valores de palavras codificados que contêm o tipo de realocação bem como o offset a partir de `VirtualAddress` a ajustar. No que diz respeito ao tipo de realocação, para binários de 64 bits, estamos preocupados apenas com um tipo de realocação. Infelizmente, essa estrutura não é realmente uma struct variádica, então temos que fazer alguma aritmética de ponteiros para obter o array `TypeOffset`.

Como mencionado, o array `TypeOffset` contém palavras codificadas. Os 4 bits superiores (máscara `0xF000`) contêm o tipo de realocação, que pode ser encontrado na [seção "base relocation types"](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format) da documentação do formato PE. Os 12 bits inferiores (máscara `0x0FFF`) contêm o offset a partir do argumento `VirtualAddress` a ajustar.

Explicar isso é uma tarefa árdua e acaba parecendo muito confuso no final. Obter um ponteiro para um endereço a realocar parece com isto:```cpp
auto ptr = reinterpret_cast<std::uintptr_t *>(image + relocation_table->VirtualAddress + offset);

Por mais complicado que seja explicar o diretório de realocação, as operações são, na verdade, muito simples de entender no código.

Avançar para o próximo bloco de dados de realocação é facilitado pela variável `SizeOfBlock`. Este bloco contém o tamanho do nosso cabeçalho *assim como* o tamanho do array `TypeOffset`. Se `TypeOffset` fosse, em vez disso, um array de tamanho estático, simplesmente avançaríamos para a próxima entrada de realocação adicionando a chamada a `sizeof` do cabeçalho de realocação.

Com tudo isso explicado, você deverá ser capaz de entender este código de realocação:```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 você pode ver, transferir a execução é muito simples, embora exija conhecimento de [ponteiros de função](https://en.wikipedia.org/wiki/Function_pointer). Estas são as nossas partes relevantes:```cpp
// acquire and call the entrypoint
auto entrypoint = loaded_image + nt_headers->OptionalHeader.AddressOfEntryPoint;
reinterpret_cast<void(*)()>(entrypoint)();

Portanto, nosso ponteiro de função para chamar nosso ponto de entrada-- sem ter tipo associado a ele-- fica assim:```c
void (*entrypoint)()

Juntando tudo, podemos simplesmente converter nosso entrypoint em um ponteiro de função e chamá-lo na mesma linha, assim:```cpp
reinterpret_cast<void(*)()>(entrypoint)();

Parabéns! Você terminou! Você acabou de escrever um packer para Windows!

## Exercícios adicionais

* **Ataca o analista**: Aprenda a implementar [algumas técnicas de anti-debug](https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf) e endureça o seu packer.
* **Expanda o seu suporte**: Aprenda a implementar um binário não realocável, ou aprenda a implementar outros diretórios, como o diretório de armazenamento local de thread (`IMAGE_TLS_DIRECTORY`) e o diretório de recursos (`IMAGE_RESOURCE_DIRECTORY`). Como a documentação é escassa neste nível, você pode ver as minhas implementações em [exe-rs](https://github.com/exe-rs).
* **Ofusque o seu stub**: Tente descobrir como o analista vai desempacotar o seu binário e dificulte o desempacotamento, como por exemplo [apagando os cabeçalhos](https://github.com/frank2/packer-tutorial/blob/main/stub/src/main.cpp#L84).