سيؤدي هذا إلى إنشاء ملفات المشروع اللازمة لبناء كود البرنامج التعليمي الخاص بـ 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**. حيث يقوم بإنشاء "نظام make" المناسب للبيئة المحددة بناءً على المترجم المعطى. على Linux، سيكون هذا ملف makefile للمترجمات المكتشفة (أو المقدمة). أما بالنسبة لنا على Windows، فإنه ينتج مشروع Visual Studio متوافقًا مع إصدار Visual Studio الخاص بنا، مما يعني أنه بمجرد إنشاء نظام make الخاص بـ 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 المولَّد والملف الترويسي المولَّد—يمكننا دمج ملفنا الثنائي الوتد بنجاح في مشروع packer.

بعد ذلك، نُعلن عن ملف تنفيذي لمشروع packer باستخدام الملفات التي تم جمعها سابقًا:```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 كجزء من خطوة البناء الخاصة به)، فنحن بحاجة إلى تضمين الدلائل الديناميكية في ملفات الترويسة للمشروع. وبسبب اعتماد على كون المشاريع في جذر مشروع في 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"
)

من المفترض أن تكون ملفات CMake الخاصة بـ [الـ 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 يمكنه إدارة الاختبارات نيابةً عنا! وفي هذه المرحلة، أصبح توليد الاختبارات لأداة packer لدينا عملية سلسة: يمكننا ببساطة إصدار أمر، وإذا كان رمز الخروج هو 0، ينجح الاختبار. لأجل البساطة، لنفترض أننا نُغلف ملفًا ثنائيًا بتمريره كوسيطة أولى للملف التنفيذي. نريد شيئًا مثل هذا:```
$ packer.exe dummy.exe

أخيرًا، اختبار ما إذا كان البرنامج يفك التغليف أبسط من ذلك: فقط قم بتشغيل المخرجات! لن يفاجئك كم الأخطاء التي ستواجهها والتي تتسبب في تعطل البرنامج بمجرد تشغيله عندما تحاول محاكاة المُحمِّل! لنقل مرة أخرى، من باب التبسيط، أن الملف الثنائي يجب أن يُخرج إلى "packed.exe" بالنسبة لملف ثنائي مغلّف. في هذه الحالة، كل ما عليك فعله هو:```cmake
add_test(NAME test_unpack
  COMMAND "packed.exe")

مع بياناتنا في متجه سهل التشكيل، يمكننا الآن تحليل صورة الـ stub وإضافة بيانات جديدة إليها.

### تحليل ملف 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` هو هيكل كبير إلى حد ما بشكل عام، لذا لن أوثّق كل شيء هنا، لكن يمكنك العثور على كل ما تحتاج معرفته عنه في [وثائق مايكروسوفت للترويسة](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-image_nt_headers64). سنحتاج فقط إلى عدد قليل من أعضاء الهيكل من هذه الترويسات على أي حال. في الوقت الحالي، ينبغي علينا ضغط الملف الثنائي المستهدف لإضافته إلى بيانات stub الخاصة بنا.

استخدام دالتي `compress` و `decompress` من zlib أمر مباشر للغاية. إذا كنت تريد حقًا التوسع في العمل مع zlib، أقترح العمل مع دالتي `deflate`/`inflate`، اللتين تتيحان لك التعامل مع تدفقات الضغط على شكل أجزاء في كل مرة. راجع قسم "الدوال المتقدمة" في [دليل zlib](https://www.zlib.net/manual.html). ومع ذلك، في هذا المثال، ستكفي `compress` و `decompress`.

للبدء، نستحصل على قيمة حجم باستخدام دالة `compressBound` من zlib بناءً على حجم الملف الثنائي المستهدف. تتوافق قيمة الحجم هذه مع الحد الأقصى المطلوب لاحتواء تدفق بيانات مضغوطة بالنظر إلى حجم البيانات. يمكننا بعد ذلك استخدام هذه القيمة لتخصيص متجه (vector) لاحتواء البيانات المضغوطة. تُرجع دالة `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 الخاص بنا، يجب أن نكون حريصين على *محاذاة الملف* بشكل خاص-- يمكننا حساب القيم المتحاذاة الصحيحة لملف PE عندما يكون في الذاكرة لاحقًا، لكن في الوقت الحالي عند إضافة بياناتنا نحتاج إلى محاذاة ملفنا إلى حد محاذاة الملف. في الكود التالي، نحصل على الرؤوس، ثم حدود محاذاة الملف ومحاذاة الأقسام، ثم نتابع لمحاذاة بيانات الـ stub إلى حد الملف وإلحاق القسم المعبأ الجديد.

---```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 الاختياري من الناحية الفنية، إلا أن حجم الرأس الاختياري يتم تحديده فعليًا بقيمة `SizeOfOptionalHeader` في رأس ملف NT. لذا، للوصول إلى هناك، نحتاج إلى حساب مؤشر من أعلى بنية `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` هو التسمية ذات الثمانية بايتات التي يمكنك إعطاؤها لقسمك الجديد. اخترت `.packed`، لأنها سلسلة 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). في الوقت الحالي، ينبغي أن تعلم أن كل ما نحتاجه هو أن يكون القسم قابلاً للقراءة ومُعلَّمًا على أنه يحتوي على بيانات مُهيأة.

مع وضع كل هذا في الاعتبار، يمكننا الآن إنشاء قسمنا الجديد!```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;

وهذا كل شيء! لقد نجحنا في إضافة ملفنا الثنائي المضغوط كقسم جديد ليتمكن الـ stub من فك ضغطه وتحميله في النهاية. الآن يمكننا ببساطة حفظ صورة الـ stub المعدّلة على القرص.```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 بالكثير من الأمور المختلفة في الخلفية، ويدعم العديد من إعدادات الملفات التنفيذية المختلفة. من المرجح أن تواجه مجموعة متنوعة من الأخطاء مع أداة التغليف (packer) التي ينتجها هذا البرنامج التعليمي إذا استكشفت أكثر من الثنائي النموذجي، لأن الإعداد الذي سنبنيه اليوم هو تقنيًا حد أدنى للغاية. ولكن من أجل تأسيس ذلك الحد الأدنى المطلق للتنفيذ، نحتاج إلى القيام بالأشياء التالية لتحميل ملف Windows تنفيذي حديث:

* تخصيص الصورة التي تحمل تمثيل الذاكرة لصورة الملف التنفيذي
* تعيين أقسام صورة الملف التنفيذي لدينا، بما في ذلك الرؤوس، إلى تلك الصورة المخصصة
* حل الاستيرادات (imports) في وقت التشغيل إلى المكتبات الأخرى التي يحتاجها ثنائينا
* إعادة تعيين صورة الثنائي بحيث تشير مجموعة متنوعة من العناوين في صورتنا إلى حيث يفترض أن تشير

لنبدأ مع دالة `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` الخاصة به غير صفرية.```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;

هيكل البيانات هذا يغطي thunks الاستيراد وكذلك التصدير، لذلك يمكن تجاهل `ForwarderString`. يمكن أن يكون thunk الاستيراد إما `Ordinal` أو RVA إلى بنية أخرى، `IMAGE_IMPORT_BY_NAME`. *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-string كوسيطة للدالة، فإن Windows يتوقع منك الاستيراد بالترتيب العددي بمجرد تحويل قيمة الترتيب إلى C-string. يا للغرابة.

مع هذه التوضيحات في الاعتبار، يجب أن تكون حلقة 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` المعلّقة، فهي ذات صلة فعلاً هنا! يتكوّن جدول إعادة التوطين من كتل من الإزاحات التي تحتوي على العناوين المراد تعديلها، ويتم تحديدها بواسطة RVA الخاص بـ `VirtualAddress`. تحتوي مصفوفة `TypeOffset` على قيم كلمات مشفّرة تتضمن نوع إعادة التوطين بالإضافة إلى الإزاحة من `VirtualAddress` المراد تعديلها. فيما يتعلق بنوع إعادة التوطين، بالنسبة للملفات الثنائية 64-bit، لا يهمّنا سوى نوع واحد من أنواع إعادة التوطين. لسوء الحظ، هذا الهيكل ليس في الواقع بنية متغيّرة (variadic struct)، لذا يتعين علينا القيام ببعض حسابات المؤشرات للحصول على مصفوفة `TypeOffset`.

كما ذُكر، تحتوي مصفوفة `TypeOffset` على كلمات مشفّرة. البتات الأربع العليا (القناع `0xF000`) تحتوي على نوع إعادة التوطين، والذي يمكن العثور عليه في قسم ["أنواع إعادة التوطين الأساسية"](https://learn.microsoft.com/en-us/windows/win32/debug/pe-format) من توثيق تنسيق PE. أما البتات الاثنتا عشرة السفلى (القناع `0x0FFF`) فتحتوي على الإزاحة من وسيط `VirtualAddress` المراد تعديلها.

شرح ذلك مهمة شاقة وينتهي به الأمر إلى كونه مربكًا جدًا في النهاية. الحصول على مؤشر إلى عنوان لإعادة توطينه يبدو كالتالي:```cpp
auto ptr = reinterpret_cast<std::uintptr_t *>(image + relocation_table->VirtualAddress + offset);

لذلك بقدر ما هو معقّد شرح دليل إعادة التوطين (relocation directory)، فإن العمليات في الواقع بسيطة جدًا لفهمها في الكود.

الانتقال إلى الكتلة التالية من بيانات إعادة التوطين يصبح سهلاً بفضل متغير `SizeOfBlock`. تحتوي هذه الكتلة على حجم الترويسة (header) *بالإضافة إلى* حجم مصفوفة `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)();

تهانينا! لقد أنجزت! لقد كتبت للتو أداة packer لنظام Windows!

## تمارين إضافية

* **هاجم المحلل**: تعلّم كيفية تنفيذ [بعض تقنيات مكافحة التنقيح](https://anti-reversing.com/Downloads/Anti-Reversing/The_Ultimate_Anti-Reversing_Reference.pdf) وقوِّ packer الخاص بك.
* **وسّع دعمك**: تعلّم كيفية تنفيذ ملف ثنائي غير قابل لإعادة التوطين، أو تعلّم تنفيذ أدلة إضافية مثل دليل التخزين المحلي لمؤشرات الترابط (`IMAGE_TLS_DIRECTORY`) ودليل الموارد (`IMAGE_RESOURCE_DIRECTORY`). وبما أن التوثيق نادر على هذا المستوى، يمكنك الاطلاع على تطبيقاتي في [exe-rs](https://github.com/exe-rs).
* **عقّد الـ stub الخاص بك**: حاول معرفة الكيفية التي سيفك بها المحلل حزم ملفك الثنائي، وامنع سهولة فك الحزم، مثل [مسح الترويسات](https://github.com/frank2/packer-tutorial/blob/main/stub/src/main.cpp#L84).