이렇게 하면 packer 튜토리얼 코드를 빌드하는 데 필요한 프로젝트 파일이 생성됩니다. 그런 다음 실행하세요:```
$ cmake --build ./ --config Release

If all goes well, test\_pack and test_unpack should succeed. If you want to see the results of the packing yourself, you should see this:

모든 것이 잘 진행된다면, 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;
}

또한 패커를 "MultiThreadedDLL"(즉, /MD) 대신 "MultiThreaded"(즉, /MT)로 선언하여 런타임 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)**으로 설명된다는 점을 짚고 넘어가야겠습니다. CMake는 주어진 컴파일러를 기반으로 해당 환경에 맞는 적절한 "메이크 시스템"을 생성합니다. Linux에서는 감지된(또는 지정된) 컴파일러용 makefile이 생성됩니다. Windows에서 우리는 이 과정을 통해 우리가 사용하는 Visual Studio 버전과 호환되는 Visual Studio 프로젝트가 생성되며, 즉 MSVC 메이크 시스템을 한 번 만들어 두면 원한다면 이후의 모든 작업을 Visual Studio에서 바로 수행할 수 있습니다! 결국 여러분은 CMake를 사용해 Visual Studio를 구성(configuring)하는 것입니다. 따라서 여기서 하는 작업은 본질적으로 프로젝트를 만들 때 GUI가 자동으로 만들어 주는 Visual Studio 내 프로젝트 파일 트리를 직접 생성하는 것과 같습니다.

다음으로, 우리의 종속 프로젝트들을 추가해야 합니다:```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는 구성(configuration)에 따라 이진 파일을 폴더에 덤프하므로, `$<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의 DLL이 필요하다면 `zlib`만 링크할 수도 있습니다.

생성된 파일(그리고 zlib도 빌드 단계의 일부로 생성)이 있기 때문에 프로젝트의 include 헤더에 동적 디렉터리를 포함해야 합니다. CMake에서 프로젝트가 프로젝트 루트에 있어야 하는 종속성 때문에 스텁 바이너리에도 zlib include 디렉터리를 추가합니다:```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"
)

이제 [the stub](https://github.com/frank2/packer-tutorial/blob/main/stub/CMakeLists.txt)와 [the dummy](https://github.com/frank2/packer-tutorial/blob/main/dummy/CMakeLists.txt)용 CMake 파일은 꽤 이해하기 쉬울 것입니다!

훌륭한 점은 CMake가 테스트를 관리해 준다는 것입니다! 그리고 이 시점에서 우리 패커에 대한 테스트를 생성하는 것은 간단한 과정입니다. 명령어 하나를 실행하기만 하면 되고, 종료 코드가 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)의 "Advanced Functions" 섹션을 참조하십시오. 하지만 이 예제에서는 `compress`와 `decompress`로 충분합니다.

우선, 대상 바이너리의 크기에 대해 zlib의 `compressBound` 함수로 크기 값을 얻습니다. 이 크기 값은 데이터 크기가 주어졌을 때 압축된 데이터 스트림을 담는 데 필요한 최대 값에 해당합니다. 그런 다음 이 값을 사용하여 압축된 데이터를 담을 벡터를 할당할 수 있습니다. `compress` 함수는 결국 압축 버퍼의 실제 크기를 반환하며, 그 값으로 벡터를 적절한 크기로 조정할 수 있습니다.```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 파일에 임의의 데이터를 제대로 추가하려면 특히 *파일 정렬(file alignment)*에 유의해야 합니다. 나중에 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)에 null 인수를 전달하면 궁극적으로 실행 중인 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 imports 해석

선택적 헤더 안에는 *데이터 디렉터리*라고 하는 것이 있습니다. 이 디렉터리는 실행 파일에 대한 다양한 정보(예: 이미지가 내보내는 심볼, 아이콘이나 비트맵 같은 리소스)를 포함합니다. 이 튜토리얼에서는 **import 디렉터리**와 **재배치 디렉터리**라는 두 데이터 디렉터리를 파싱할 것입니다. 각 디렉터리는 하드코딩되어 있으며, 해당 인덱스는 [선택적 헤더에 대한 문서](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 import를 해석하기 위해 로더는 이 디렉터리를 파싱한 다음, 필요한 라이브러리를 로드하고 import된 함수들을 획득합니다. 다행히도 이 디렉터리는 파싱하기 비교적 쉬운 편입니다.

이는 import 디스크립터 구조로 시작합니다:```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;

이 데이터 구조는 import 및 export thunk를 모두 포함하므로 `ForwarderString`은 무시해도 된다. import thunk는 `Ordinal`이거나 다른 구조체인 `IMAGE_IMPORT_BY_NAME`에 대한 RVA일 수 있다. *ordinal*은 단순히 해당 DLL의 export 테이블에 대한 오프셋이다. `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 문자열로 캐스팅하기만 하여 서수(ordinal)로 가져오도록 요구합니다. 참 이상하죠.

이러한 설명을 염두에 두면, 다음 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 형식 문서의 ["base relocation types" 섹션](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);

재배치 디렉터리를 설명하는 것은 복잡하지만, 실제 코드에서의 동작은 이해하기 매우 간단합니다.

`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)()

모든 것을 종합하면, 엔트리포인트를 함수 포인터로 캐스팅하고 같은 줄에서 호출하기만 하면 됩니다. 다음과 같이:```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)와 같은 방법으로 언패킹을 쉽게 하지 못하도록 방지해 보세요.