حاليًا، تُدرج جميع أدوات التعتيم المعروفة من نوع bin2bin قسمًا في نهاية الملف الثنائي لوضع الكود أو البيانات المعتمة داخله. وذلك للحفاظ على التخطيط الأصلي للملف الثنائي دون الحاجة إلى تغيير محتويات الأقسام الموجودة مسبقًا. هذا أسهل بكثير في الإدارة لأنه يُبقي معظم RVAs (العناوين النسبية) صالحة.

يتخذ هذا المشروع نهجًا فريدًا في bin2bin، حيث يتم إدراج أي كود أو بيانات معتمة ضمن الأقسام الأصلية للملف الثنائي. يتطلب ذلك تتبع كل عنوان RVA في التطبيق. فوائد هذا النهج هي:

• أقل إثارة للشكوك في تحليل البرمجيات الخبيثة حيث لا توجد أقسام تنفيذية إضافية تُضاف إلى الملف الثنائي. ملاحظة: تم اختبار ذلك لأغراض تعليمية وبحثية فقط.
• حجم أصغر للملف الثنائي القابل للتنفيذ الناتج. وذلك لأن الكود الأصلي غير المعتم يمكن محوه من الملف الثنائي حيث يمكن تغيير حجم الأقسام.
• صعوبة أكبر في التحليل، إذ لن يتمكن المهندس العكسي من فصل الكود المعتم عن غير المعتم بالاعتماد على الأقسام فقط، بل يجب فحص كل دالة لمعرفة ما إذا كانت معتمة.

ستصف هذه الوثيقة كلاً من إعادة كتابة الملف الثنائي القابل للتنفيذ وتقنيات التعتيم المطبقة. تم تنفيذ تقنيات التعتيم التالية:

• آلة افتراضية.
• مسندات معتمة.
• تسطيح تدفق التحكم.
• استبدال خطي.
• حساب مختلط للقيم المنطقية.

علاوة على ذلك، يدعم هذا المشروع الاستثناءات (استثناءات C++ وSEH) ويمكنه تعتيم الدوال التي تحتوي على معالجة استثناءات.

للمساعدة في التفكيك واكتشاف الكود في الملف الثنائي، يتم قبول ملفات الرموز (سواء PDB أو MAP) بشكل اختياري. توفير ملفات الرموز ليس ضروريًا ولكنه يساعد في التفكيك في الملفات الثنائية المعقدة. تتطلب بعض الميزات مثل دعم الاستثناءات وتسطيح تدفق التحكم توفير ملف رموز.

2. إعادة كتابة الثنائيات

أداة إعادة كتابة الثنائيات تأخذ ملفًا ثنائيًا قابلاً للتنفيذ وتغيّر الكود أو البيانات بداخله لإنتاج ملف ثنائي ناتج مع تطبيق التغييرات.

2.1. تتبع العناوين النسبية

بما أن الكود المعتم يُدرج مباشرة داخل الأقسام الأصلية للملف الثنائي، يجب تتبع العناوين النسبية في البرنامج بحيث يمكن تعديل جميع المراجع إليها. والهدف من ذلك أن تظل المراجع تشير إلى نفس الموقع بعد إدراج الكود والبيانات. وإلا فسيتم الوصول إلى البيانات أو الكود في موقع خاطئ، مما يغيّر سلوك الملف الثنائي الناتج ويسبب عدم استقرار شديد.

عندما يتم العثور على أي مرجع لعنوان نسبي (مثل تعليمة تحتوي على معاملات نسبية لـ rip أو أدلة بيانات PE)، يُضاف إلى قائمة تتبع ليتم تحديثه في نهاية إعادة الكتابة. يتم تتبع RVA حيث يقع المرجع (لمعرفة أين يتم تحديث المرجع) وكذلك RVA المُشار إليه (لمعرفة العنوان الذي سيتم تحديث المرجع به).

عندما يجد المفكك تعليمة نسبية لـ rip، سيضيفها إلى قائمة مراجع ليتم تحديثها في نهاية التعتيم. يضمن ذلك أن جميع هذه التعليمات لا تزال تشير إلى الموقع الذي كانت تشير إليه أصلاً. كما تُضاف حالات أخرى من التعليمات النسبية مثل جداول القفز كمراجع يجب تحديثها.

يجب تعديل جميع RVAs المتتبعة كلما تم إدراج أي بايتات أو إزالتها من الملف الثنائي. على سبيل المثال، هذا هو معالج إدراج البايتات:```cpp
void binwrite::binary_t::insert(const rva_t rva, const std::span data, const bool inclusive)
{
buffer_.insert_range(buffer_.begin() + rva.value(), data);

}

هذا هو تنفيذ wcslen، الذي يحصل على طول سلسلة عريضة. عندما يتم تفكيك التعليمات الأولى 'or rax, FFFFFFFFFFFFFFFF' كبداية لكتلة أساسية، فإنها ستستمر في التفكيك حتى 'retn'.

تقفز التعليمات 'jnz loc_140001078' إلى الأعلى لتشكيل حلقة. ستتم إضافة هذا كمرجع، وسيتم إضافة هدف jnz إلى قائمة انتظار التفكيك بالإضافة إلى فرع التتابع (التعليمة التالية). تقفز التعليمات في منتصف الكتلة التي تم تحليلها بالفعل، لذا لا يمكنها ببساطة تشكيل كتلة جديدة والتفكيك مرة أخرى حتى 'retn' لأن ذلك سيمثل تكرارًا.

ستأخذ 'jnz' (القفزة الشرطية) أيضًا فرع التتابع لإنشاء كتلة أساسية جديدة أيضًا. الآن سيكون هناك 4 كتل أساسية تبدو كالتالي:

Block A:```asm
or rax, 0FFFFFFFFFFFFFFFFh
loc_140001078:
inc rax
cmp word ptr [rcx+rax*2], 0
jnz short loc_140001078

الكتلة ج:```asm
retn

هذا تمثيل خاطئ للكتل الأساسية، لأنه يكرر نفس التعليمات عبر 4 كتل. يمكن إصلاح ذلك بتقسيم أي كتل أساسية تتداخل مع التفكيك الحالي. لن تكون هناك أي تعليمات مكررة بعد الآن لأنه بدلاً من إنشاء تمثيل مكرر للتعليمات عند كل تداخل، سيتم نقل التعليمات الموجودة إلى الكتلة الأساسية الجديدة. التمثيل الصحيح باستخدام التقسيم هو كما يلي:

Block A:```asm
or rax, 0FFFFFFFFFFFFFFFFh

الكتلة C:```asm
retn

يتم تجميع عبارة switch هذه إلى كود التجميع التالي:```asm
; ecx = a1
cmp ecx, 3 ; check if above bounds, must be default case
ja short def_140004097 ; goto default if a1 above 3
mov ecx, ecx
mov eax, ecx
lea rcx, jpt_140004097
movsxd rax, ds:(jpt_140004097 - 140004100h)[rcx+rax*4] ; select correct index of jump table for a1
add rax, rcx
jmp rax ; goto index specified - the case handler

jpt_140004097:
dd offset loc_140004099 - 140004100h ; address of handler for first case
dd offset loc_1400040D5 - 140004100h ; address of handler for second case
dd offset loc_1400040BD - 140004100h ; address of handler for third case
dd offset loc_1400040C9 - 140004100h ; address of handler for fourth case

يستخدم LLVM جدولاً يحتوي على إزاحات نسبية إلى قاعدة الجدول. من خلال إضافة عنوان قاعدة الجدول إلى الإزاحة الموصوفة في المدخل، يمكن حساب عنوان المعالج.

جدول القفز الخاص بـ GCC هو مصفوفة من عمليات إعادة التوطين من نوع DIR64. تشير كل عملية إعادة توطين إلى عنوان تعليمة case. عمليات إعادة التوطين مُتتبَّعة بالفعل، لذا فإن مدخلات جدول القفز هذه مُصحَّحة بالفعل. في وقت التشغيل، ستتم إزاحة مدخلات إعادة التوطين هذه بمقدار العنوان الأساسي، بحيث يمكن إلغاء الإشارة إلى كل مدخل للحصول على عنوان تعليمة case.

2.2.2.2. الحالات الحدّية

هناك بعض الأشكال الأخرى من تدفق التحكم غير المباشر التي يجب دعمها. على سبيل المثال، في الملفات الثنائية لـ CLANG التي تستخدم استثناءات C++ من نوع FuncInfo3، يتم تحميل عنوان الاستمرار في السجل rax ثم يُعاد إلى المستدعي. سيقفز المستدعي إلى عنوان الاستمرار.```asm
lea rax, [rip+X]
retn

على سبيل المثال، في استدعاء _CxxThrowException من نوع noreturn هذا، أدخل المترجم حشوًا على شكل تعليمات INT3، والتي سيتم التقاطها كحشو وكتعليمة إنهاء في الوقت نفسه. وهناك حالات أخرى مثل إدراج تعليمات UD2 بعد استدعاء noreturn ويتم التعامل معها أيضًا.

هذه ليست طريقة مضمونة للكشف عنها، كما يناقش فريق CodeDefender أيضًا، لكن توجد إجراءات مضادة لتصحيح أي تفكيك تجاوز الحد المطلوب. إذا وُجدت أي مدخلات لجدول القفز داخل كتلة أساسية، يتم تقسيم الكتلة الأساسية بحيث تُعطى الأولوية لجدول القفز. ويمنع هذا تفكيك مدخلات جدول القفز كتعليمات بعد استدعاء noreturn. إذا كانت التعليمات التالية شيفرة صالحة، فسيتم تقسيم الكتلة الأساسية على أي حال عند تفكيك/معالجة الكتلة الأساسية للعنوان التالي.

2.3. دعم الاستثناءات

2.3.1. دعم التراجع

تستخدم أداة التعتيم تخصيصات المكدس في مسارات التعتيم الخاصة بها. يتيح لها ذلك حفظ قيم السجلات التي تستخدمها (مثل push rax) واستعادتها بعد اكتمال مسار التعتيم حتى لا تتلف السجلات. مؤشر الإطار هو سجل يشير إلى موقع محدد على المكدس.

يجب توثيق جميع تخصيصات المكدس بواسطة رموز التراجع الخاصة بالدالة (في حال عدم وجود مؤشر إطار)، مما يسمح لمعالج استثناءات النظام بالتراجع عبر المكدس إلى عنوان العودة والبحث عن معالج استثناءات التطبيق. يجب أن تكون هذه التخصيصات في مقدمة الدالة (بداية الدالة) بسبب قيد على مدى بُعدها عن بداية الدالة. إذا تم إجراء تخصيصات المكدس خارج مقدمة الدالة، فلن تستطيع رموز التراجع وصفها ولن يتمكن النظام من التراجع، مما يكسر دعم الاستثناءات.

إذا تم استخدام مؤشر إطار، فلن يحتاج النظام إلى القدرة على التراجع عبر المكدس من سجل rsp، بل يمكنه التراجع عبره من مؤشر الإطار بدلاً من ذلك. وهذا يعني أن أداة التعتيم يمكنها إجراء تخصيصات للمكدس خارج مقدمة الدالة دون الحاجة إلى توثيقها في رموز التراجع.

2.3.1.1 التنفيذ

سيدرج مُعيد الكتابة سجل مؤشر إطار في كل دالة وقت تشغيل لا تمتلك واحدًا بالفعل. يتيح ذلك للنظام التراجع عبر المكدس حتى بعد أن تقوم أداة التعتيم بتخصيصات للمكدس خارج مقدمة الدالة.

فيما يلي مثال على التغييرات التي تُجرى على مقدمة وخاتمة الدالة:

مقدمة الدالة الأصلية:```asm
DriverEntry proc
sub rsp, 38h

خاتمة الدالة الأصلية:```asm
add rsp, 38h
ren
DriverEntry endp

الشكل 3. تخطيط المكدس قبل إدراج مؤشر الإطار.

يُستخدم السجل غير المتطاير rbp كمؤشر إطار بواسطة المُعيد الكاتب (rewriter). يجب الحفاظ على السجلات غير المتطايرة، لذلك تُدفع قيمة rbp في المقدمة (prologue) ويتم وصفها برموز فك الالتفاف (unwind codes) حتى يتمكن مُفكك الالتفاف في نظام التشغيل من استعادة القيمة الأصلية لـ rbp. يُدفع السجل rbp مرتين لإعادة محاذاة المكدس إلى 16 بايت، وتكون الدفعة الثانية لأغراض إعادة المحاذاة فقط.

بما أن قيمة rbp تُدفع مرتين في المقدمة، فيجب أيضًا إخراجها (pop) في نهاية الدالة لإعادة مؤشر المكدس إلى قيمته الأصلية. وذلك ليكون عنوان العودة عند [rsp] لتعليمة الإرجاع.

تُدرج رموز فك الالتفاف المناسبة لتعليمات الدفع هذه حتى يعرف نظام التشغيل أن هناك المزيد من تخصيصات المكدس في المقدمة (ليفك منها مؤشر الإطار). ولهذا توجد عمليتا إخراج (pop) في الخاتمة (epilogue).

للعثور على تلك الكتل الأساسية الخارجة/الخواتم (epilogues)، يتم البحث في جميع الكتل الأساسية داخل الدالة عن تعليمة 'ret' أو قفزة تخرج خارج الدالة الحالية. كما تُعد القفزات غير المباشرة (مثل jmp rcx) خروجًا خارج الدالة الحالية، باستثناء جداول القفز. ومع تجميع جميع الكتل الأساسية الخارجة معًا، يمكن إدراج تعليمتي الإخراج (pop) فيها لضمان إلغاء تأثيرات الدفع في المقدمة عند مغادرة الدالة.

تعليمة 'lea rbp, [rsp]' في نهاية المقدمة موجودة لإخبار نظام التشغيل بموقع ملموس للمكدس يمكنه فك الالتفاف منه بدلاً من فك الالتفاف من rsp. وتُدرج معلومات ورموز فك الالتفاف المناسبة لتعليمة ضبط مؤشر الإطار هذه.

الشكل 4. تخطيط مكدس خاطئ بعد إدراج مؤشر الإطار.

الاعتبار الآخر هو وسائط المكدس، التي تقع قبل مؤشر المكدس. إذا تم الوصول إلى المكدس في دالة ما بعد التخصيص المحلي (عند فتحة عنوان العودة أو بعدها)، فيجب تحديث تلك المراجع. وذلك لأن عمليات الدفع تُعدّل المكدس بمقدار 16 بايت، لذلك يجب أيضًا إزاحة جميع البيانات المُشار إليها بعدها بمقدار 16 بايت. يوضح الرسم البياني أعلاه كيف تصبح مراجع المكدس غير محاذية وتحتاج إلى تصحيح.

على سبيل المثال، ستحصل التعليمة 'mov rax, [rsp+0x90]' على إضافة 0x10 (أي 16 بالنظام العشري) إليها بحيث تظل تصل إلى نفس فتحة المكدس بعد تنفيذ عمليات الدفع. ستكون التعليمة المصححة: 'mov rax, [rsp+0xA0]'.

إذا وصلت تعليمة إلى ما بعد التخصيص المحلي للمكدس، فسيتم تعديلها بمقدار 16 لتتخطى عمليات الدفع التي تتم على المكدس. في بعض الأحيان يُنقل مؤشر المكدس إلى سجلات مختلفة ويتم الوصول إليه عبر سجل مختلف، وفي هذه الحالة تتم مراقبة ذلك السجل وتعديله بنفس الطريقة المتبعة مع مؤشر المكدس.

هناك حالة أخرى وهي معالجات الالتقاط (catch handlers) للاستثناءات، إذ تحصل في rdx على عنوان إطار المُنشئ (EstablisherFrame) (المساوي لقيمة سجل مؤشر الإطار لدينا وقت حدوث الاستثناء). وستصل معالجات الالتقاط إلى مكدس دالة الاستثناء من خلال rdx، وبالتالي يجب أيضًا تتبع rdx وتعديله.

يوجد أدناه مخطط تخطيط المكدس بعد تصحيحه باستخدام تعديلات مراجع المكدس.

الشكل 5. تخطيط المكدس بعد التصحيح عقب إدراج مؤشر الإطار.

يتطلب دعم الاستثناءات توفير ملف رموز (symbol file) لأداة التمويه (obfuscator) لأنه يتطلب أكبر قدر ممكن من المعلومات حول رموز الملف الثنائي.

2.3.2. تحليل معلومات الاستثناء

يقوم المُعيد الكاتب بتحليل معلومات فك الالتفاف للملف الثنائي للعثور على معلومات معالج الاستثناء. كما يتم تتبع أي عناوين RVA يتم العثور عليها. أنواع معلومات معالج الاستثناء المدعومة هي:

• SEH/C_SCOPE_TABLE (استثناءات بأسلوب C).
• استثناءات C++ من نوعي FuncInfo3 وFuncInfo4.

2.3.2.1. SEH/C_SCOPE_TABLE

تنسيق هذا النوع هو مصفوفة من إدخالات الجدول التالية:```cpp
struct c_scope_table_entry_t
{
std::uint32_t begin_rva; // where exception-throwing range begins
std::uint32_t end_rva; // where exception-throwing range ends
std::uint32_t handler_rva; // the handler type/rva (normally 1)
std::uint32_t target_rva; // the catch handler rva
};

struct c_scope_table_t
{
std::uint32_t entry_count;
c_scope_table_entry_t table[1];
};

يتم العثور على ذلك من خلال فحص أقسام البيانات للبحث عن إعادة التوطين DIR64 في حقل العضو 'vftable_address'، والذي يُفحص للتأكد من كونه جدول دوال افتراضية حقيقياً.

بالنسبة للفئات التي تحتوي على دوال افتراضية، يتم إنشاء محدد موقع الكائن الكامل وواصف التسلسل الهرمي للفئة. يحتوي واصف التسلسل الهرمي للفئة على مصفوفة من الفئات الأساسية.```cpp
struct complete_object_locator_t
{
std::uint32_t signature;
std::uint32_t offset;
std::uint32_t constructor_offset;
std::uint32_t type_rva;
std::uint32_t hierarchy_rva;
std::uint32_t self_rva;
};

struct hierarchy_descriptor_t
{
std::uint32_t signature;
std::uint32_t attributes;
std::uint32_t base_class_count;
std::uint32_t base_class_list_rva;
};

struct base_class_array_t
{
std::uint32_t class_rvas[1];
};

struct base_class_descriptor_t
{
std::uint32_t type_rva;
std::uint32_t element_count;
std::uint32_t member_displacement;
std::uint32_t unk;
std::uint32_t unk1;
std::uint32_t attributes;
std::uint32_t hierarchy_rva;
};

3. التعتيم

3.1. الآلة الافتراضية

تأخذ هذه التقنية تعليمات بنية x86-64 وتترجمها إلى بنية وحدة معالجة مركزية افتراضية. وهذا أصعب بكثير في التحليل، إذ يتعين على مهندس الهندسة العكسية أولاً فهم بنية المعالج الافتراضي قبل تحليل ما تفعله التعليمات الأصلية.

يستخدم هذا التنفيذ نهجًا عامًا لتوليد معالجات الآلة الافتراضية بحيث يمكن تعتيم مجموعة واسعة من التعليمات دون الحاجة إلى ترميز معالجات ثابتة لكل تعليمة من تعليمات x86-64.

الشكل 6. بنية الآلة الافتراضية.

يتم استبدال تسلسل التعليمات الأصلي الذي تتم افتراضيته باستدعاء إلى الكتلة الافتتاحية للآلة الافتراضية.

عند الدخول إلى الآلة الافتراضية، يتم دفع جميع سجلات الأغراض العامة (باستثناء rsp) إلى المكدس. كما يتم دفع سجل rflags إلى المكدس. تُستخدم هذه الفتحات في المكدس كسجلات افتراضية، يتوافق كل منها مع سجله الأصلي (لذا يتم استخدام الفتحة الخاصة بـ rax بدلاً من rax). يتم ترتيب هذه السجلات الافتراضية في المكدس بشكل عشوائي، بحيث يتغير تخطيط السجلات في كل معالج من معالجات الآلة الافتراضية.

تعليمات الدفع التي تضع سجلات الأغراض العامة في تخطيط المكدس الافتراضي هي أيضًا عشوائية، ويمكن أن تكون 'sub rsp, 8; mov [rsp] reg' أو 'push reg'. يُفعل ذلك لجعل بناء التواقيع الخاصة بمدخل الآلة الافتراضية أكثر صعوبة.

السجلات المادية هي سجلات الأغراض العامة من بنية x86-64. الآن وبعد أن تم حفظ السجلات المادية في حالتها الافتراضية على المكدس، أصبحت حرة ليتم استخدامها والكتابة فوقها. تتتبع حالة الآلة الافتراضية قائمة بالسجلات المادية المتاحة حاليًا والتي يمكن استخدامها من قبل أجزاء الآلة الافتراضية. وبمجرد اكتمال الجزء، تُعاد تلك السجلات المادية إلى القائمة ليُعاد استخدامها.

الآن أصبح التطبيق داخل الآلة الافتراضية وحان الوقت لتسليم التنفيذ إلى المعالجات الخاصة بالتعليمات المستهدفة. التعليمات المستهدفة هي تعليمات x86-64 التي يتم تحويلها إلى هذه البنية الافتراضية.

أولاً، يجب تحميل معاملات التعليمات المستهدفة إلى المكدس. يتم تحميل قيم المعاملات في سجل مادي حر. ثم يتم تعتيم قيم المعاملات ودفعها إلى المكدس. يتم ذلك من الكتلة السابقة إلى معالج التعليمات (المعالج السابق أو كتلة دخول الآلة الافتراضية إذا كان هذا هو المعالج الأول).

التعتيم المطبق على قيم المعاملات هو كما يلي:

• عملية xor برقم عشوائي 16-بت على قيمة المعامل.
• عملية نفي بتكملة الواحد على قيمة المعامل.

بالنسبة للمعاملات المباشرة، يمكن إجراء هذا التعتيم في وقت التعتيم لأن القيمة معروفة، لذلك لا يتم الحساب في وقت التشغيل، وبالتالي يصبح عكسه أصعب.

المعاملات المخفية التي تتطلب سجلات محددة (مثل rsi و rdi من أجل 'rep movsb') يتم تحميلها في تلك السجلات المحددة بدلاً من سجل مادي عشوائي.

في كتلة معالج التعليمات، يتم إخراج المعاملات من المكدس وفك تعتيمها. يتم تنفيذ العملية العكسية للحصول على القيم الأصلية للمعاملات.

إذا كانت التعليمات الأصلية تقرأ من سجل rflags، فسيتم تحميل rflags من سياق المكدس قبل تنفيذ التعليمات.

إذا كانت التعليمات الأصلية تكتب إلى سجل rflags، فسيتم تحميل rflags من سياق المكدس قبل تنفيذ التعليمات. وبعد تنفيذ التعليمات الأصلية، تتم كتابة rflags المحدّثة مرة أخرى إلى سياق المكدس.

يضمن ذلك أن تكون لتعليمات الآلة الافتراضية نفس سلوك الأعلام تمامًا مثل التعليمات الأصلية.

داخل كتلة معالج التعليمات، يتم ترميز تعليمة x86-64 الأصلية لاستخدام معاملات مفكوكة التعتيم. وبمجرد تنفيذ التعليمات الأصلية، يتم تعتيم معاملات النتيجة ودفعها إلى المكدس.

إذا كان هذا هو آخر معالج للتعليمات، فستكون الكتلة الأساسية التالية هي كتلة خروج الآلة الافتراضية. إذا لم يكن كذلك، فستكون الكتلة التالية من المعالج التالي.

تخرج الكتلة الأساسية التالية معاملات النتيجة المعتّمة من المكدس وتطبق نفس عملية فك التعتيم. تُكتب قيم النتيجة إلى وجهتها الأصلية. يمكن أن يكون ذلك سجلًا افتراضيًا في سياق المكدس أو موقعًا محددًا في الذاكرة تصفه التعليمات الأصلية.

تتكرر هذه العملية حتى تعذر تحويل إحدى التعليمات في الكتلة الأساسية إلى صيغة افتراضية (مثل تعليمة تستخدم سجل rsp).

ثم يجب تفريغ سياق الآلة الافتراضية للانتقال مرة أخرى إلى الكود غير الافتراضي. يتم إخراج جميع السجلات الافتراضية من المكدس إلى سجلات الأغراض العامة المقابلة لها. كما يتم استعادة سجل rflags المعدّل بإخراجه من المكدس. الآن، تعود كتلة خروج الآلة الافتراضية إلى المُستدعي.

3.3.1 دعم فك المكدس

إذا أثارت إحدى تعليمات الآلة الافتراضية استثناءً، فيجب أن يتمكن نظام التشغيل من فك المكدس خارج سياق الآلة الافتراضية ليكون قادرًا على العثور على معالج استثناء مناسب في المتصلين.

لتمكين حدوث ذلك، يجب إضافة معلومات فك المكدس إلى الملف الثنائي بحيث يكون تخطيط المكدس الخاص بوظيفة الآلة الافتراضية معروفًا لنظام التشغيل.

يتم تحميل مؤشر إطار في rbp لأن معالجات الآلة الافتراضية تستخدم تخصيصات مكدس خارج المقدمة (prologue). وهذا يعني أنه لا يُسمح لمعالجات الآلة الافتراضية باستخدام rbp كسجل مادي 'متاح'.

جميع السجلات المادية المستخدمة في الآلة الافتراضية يتم دفعها إلى سياق المكدس، لذلك يتم إدراج أكواد فك المكدس المقابلة لتلك الدفعات.

ثم يتم إدراج وظيفة التشغيل (runtime function) الخاصة بوظيفة الآلة الافتراضية في دليل الاستثناءات. أصبحت الآلة الافتراضية الآن قابلة لفك المكدس.

3.2. كتل المسندات المعتمة

تنشئ هذه التقنية فروعًا إلى كتل أساسية زائفة ذات تدفق بيانات غير صحيح لإرباك مهندس الهندسة العكسية.

المسندات المعتمة هي عبارات تُقيَّم إلى صواب أو خطأ فقط.

يتم تكرار الكتل الأساسية ولفها في جملة if ذات مسند معتم. ستكون إحدى الكتل ذات تدفق بيانات منحرف بحيث تكون مشابهة ولكنها غير صحيحة.```cpp
if (opaque_statement_always_true)
{
… original basic block
}
else
{
… incorrect but similar basic block
}

3.3. تسطيح تدفق التحكم

تدفق التحكم هو مسارات التنفيذ التي يسلكها البرنامج (مثل 'عبارات if'). التغيير في تدفق التحكم يحدث عندما تقفز كتلة أساسية إلى أخرى. يمكن تجميع هذه التغييرات في تدفق التحكم معًا في كعب موزّع واحد ثم خلطها لجعل فهمها أكثر صعوبة. سيكون كعب الموزّع مسؤولًا عن تغيير تدفق التحكم إلى الكتلة الأساسية التالية بدلاً من أن يتم ذلك مباشرة.

الشكل 7. تسطيح تدفق التحكم.

يتم تجميع جميع الكتل الأساسية للدالة (باستثناء المقدمة) معًا في قائمة، ويتم جمع جميع فروعها (الشرطية وغير الشرطية). تُعطى كل كتلة أساسية معرّفًا فريدًا. يأخذ كعب الموزّع جميع الفروع المحتملة ويبني جملة switch مع جميع المعرّفات كحالات. تقفز عبارات case إلى الكتلة الأساسية الهدف. يتم استبدال جميع القفزات إلى الكتل الأساسية الأصلية/تدفق التحكم الأصلي بقفزة إلى جملة switch مع المعرّف الصحيح (معرّف الكتلة الهدف).

يتم خلط التوزيع الفعلي للكتل الأساسية بحيث لا يعطي موقعها في الذاكرة أي تلميحات حول تدفق التحكم الأصلي.

3.4. الاستبدال الخطي

تأخذ هذه التقنية أي أرقام مشفّرة في تعليمة (إزاحات معاملات الذاكرة، المعاملات المباشرة) وتخفي قيمتها الحقيقية عن طريق حسابها وقت التشغيل.

في وقت التمويه، يتم توليد قيمة رقم عشوائي بنفس عرض البت للرقم الأصلي. يُضاف هذا الرقم إلى الرقم الأصلي ويُحمَّل في سجل غير مستخدم كمعامل مباشر.

في وقت التشغيل، يُطرح الرقم العشوائي من السجل، مما ينتج عنه الرقم الأصلي.

إذا كان R هو الرقم العشوائي و N هو الرقم الأصلي، فإن التعبير يكون فعليًا ((R+N) - R).

لإعادة ترميز معاملات الذاكرة، يتم إدراج السجل في معامل القاعدة. إذا كان هناك بالفعل معامل قاعدة، تُضاف قيمته فوقه.

بالنسبة لمعاملات الذاكرة في المكدس التي يتم استبدالها، هناك إزاحة تُضاف إلى القيمة لمراعاة إزاحة المكدس الناتجة عن عمليات الدفع. تُستخدم عمليات الدفع لحفظ سجل rflags بالإضافة إلى السجل غير المستخدم.

فيما يلي مثال على استبدال معامل الذاكرة في 'mov [rsp+24h], 0':```asm
push r11
pushfq ; save flags for now
mov r11, rsp
add r11, 1D4D9F71h
sub r11, 1D4D9F3Dh
popfq ; restore flags, the original instruction will now execute and populate flags with the correct values
mov dword ptr [r11], 0 ; original instruction substituted (r11 == rsp+24h)
pop r11

3.5. الحساب الثنائي المختلط (Mixed boolean arithmetic)

تأخذ هذه التقنية التعبيرات الحسابية العادية (مثل x+y) وتحوّلها إلى تعبيرات أكثر تعقيداً تُنتج النتيجة نفسها. وهي تفعل ذلك عن طريق استبدال التعبيرات بمطابقات خطية متساوية.

على سبيل المثال، (x+y) لها المطابقة المتساوية ((x & y) + (x | y)). عندما يعالج المُبهم (obfuscator) التعبير (x+y)، فإنه يستبدله بإحدى تلك المطابقات التي يصعب هندستها عكسياً.

توجد قائمة بالمطابقات لتعليمات الحساب التالية: 'add'، 'sub'، 'and'، 'or'، 'xor'. وهذا يعني أنه لكل واحدة من هذه التعليمات يتم اختيار بديل أكثر تعقيداً وعشوائياً ليحل محلها. اختيار المطابقات عشوائياً من قائمة يضمن أن يكون كل ناتج إبهام مختلفاً.

لجعل فك الإبهام أكثر صعوبة، يتم تطبيق هذا بشكل تكراري (recursively). وينتهي هذا الأمر بكل مطابقة مستبدلة يُعاد استبدالها عدة مرات، مما يضاعف التعقيد بشكل كبير. فيما يلي مثال على تحويل (x+y) بعد مرتين من تمرير هذه التقنية:

الشكل 8. الحساب الثنائي المختلط.

جانب يجب أخذه في الاعتبار هو نتيجة حساب الأعلام (flags) للتعليمات. التعليمات الأصلية كانت ستطبّق سلوك أعلام محدداً على سجل الأعلام، وهو لن يكون نفسه بسبب تقسيم التعبير إلى عمليات/تعليمات مختلفة. لحل هذا، يحاكي المُبهم سلوك الأعلام عن طريق إدراج كعب (stub) يحسب الأعلام الصحيحة ويطبّقها.

بالنسبة لـ 'and' و 'or' و 'xor'، فإن سلوك الأعلام هو نفسه سلوك تعليمة 'test'؛ بإدراج تعليمة test مع نفس المُعامَلات (operands)، سيتم محاكاة الأعلام بشكل صحيح لهذه التعليمات الثلاث المستبدَلة.

بالنسبة لـ 'sub'، فإن تعليمة 'cmp' لها نفس سلوك الأعلام، ويمكن إدراجها مع نفس المُعامَلات لحساب الأعلام.

بالنسبة لـ 'add'، يمكن حساب SF و ZF و PF بواسطة 'test'، لكن CF و AF و OF تحتاج إلى حساب يدوي. ثم يتم إدراج كعب يحسب يدوياً CF و AF و OF لتعليمة add.

كعوب محاكاة الأعلام هذه تلمّح إلى ما كانت عليه التعليمات الأصلية، لذا لا يتم ذلك إلا عند الضرورة القصوى. يتم فحص الكتلة الأساسية بأكملها بحثاً عن التعليمات التي تقرأ الأعلام وتكتب الأعلام. شروط إضافة محاكاة الأعلام هي كما يلي:

• تعليمة MBA هي آخر تعليمة تكتب الأعلام قبل تعليمة تقرأ الأعلام.
• تعليمة MBA هي آخر تعليمة تكتب الأعلام في الكتلة الأساسية.

يضمن هذا أنه كلما تم الوصول إلى نهاية كتلة أساسية أو تمت قراءة الأعلام، تبقى محدَّثة بواسطة كعب محاكاة الأعلام. ويمنع ذلك الجمل الشرطية (مثل if statements) من اتخاذ الفروع الخاطئة.

4. البناء (Building)

فيما يلي أوامر مثال لبناء المشروع باستخدام CMake. ابدأ تنفيذ هذه الأوامر من الدليل الجذري للمشروع.```
cmake -B build cmake --build build