# النهج

نعتمد على الفكرة الأساسية القائلة إن أثرًا مبهمًا T' (من الكود المبهم P') يجمع بين
تعليمات أصلية من الكود الأصلي P (الأثر T المقابل لـ T' في الكود الأصلي) و
تعليمات الآلة الافتراضية VM بحيث يكون T' = T + VM(T). إذا تمكنا من التمييز بين
هاتين التتابعتين الفرعيتين من التعليمات T و VM(T)، فسنتمكن عندئذٍ من إعادة بناء مسار واحد من
البرنامج الأصلي P من أثر T'. وبتكرار هذه العملية لتغطية جميع مسارات البرنامج
الافتراضي، سنكون قادرين على إعادة بناء البرنامج الأصلي P. في مثالنا العملي، الكود
الأصلي له عدد محدود من المسارات القابلة للتنفيذ، وهو ما يحدث في العديد من الحالات التي تتضمن حماية
الملكية الفكرية. للقيام بذلك، نتبع الخطوات التالية:

1. تحديد الدالة الافتراضية ووسائطها
2. إنشاء أثر لـ VMProtect للهدف
3. إعادة تشغيل أثر VMP وبناء تعابير رمزية للحصول على العلاقة بين المدخلات والمخرجات
4. تطبيق تحسينات على التعبيرات الرمزية لتجنب قدر الإمكان تعليمات من VM
5. رفع تمثيلنا الرمزي إلى LLVM-IR لبناء نسخة جديدة غير محمية من الهدف

## مثال 1: عملية بت بسيطة

لنأخذ كمثال أول الدالة التالية: تأخذ مدخلين وتعيد `x ^ y` وهي محمية بواسطة VMProtect.```cpp
int secret(int x, int y) {
  VMProtectBegin("secret");
  int r = x ^ y;
  VMProtectEnd();
  return r;
}

يمكنك رؤية النتيجة [هنا](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/vmp_traces/sample2.vmp.trace). يستخدم تنسيق التتبع ثلاثة أنواع من العمليات: `mr` و `r` و `i`.
`mr` هو وصول قراءة للذاكرة يتم بواسطة التعليمات `i`، و `r` هي سجلات وحدة المعالجة المركزية. على سبيل المثال:```
mr:0x7ffda459d718:8:0x227db4f8
r:0x40200a:0x0:0x7ffda459f571:0x2:0x40200a:0x0:0x0:0x7ffda459d688:0x0:0x0:0x7feee9b80ac0:0x7feee9b8000f:0xad1c3e:0x0:0x0:0x0
i:0x89173e:8:488BB42490000000

بمجرد إنشاء أثر VMP، نقوم بإعادة تشغيله باستخدام السكريبت [attack_vmp.py](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/attack_vmp.py). يستخدم هذا السكريبت [Triton](https://github.com/jonathansalwan/Triton) لبناء مسند المسار للأثر. لاحظ أن جميع التعبيرات التي تتضمن متغيرات رمزية (مدخلات الدالة) تبقى رمزية بينما يتم تجسيد جميع تعبيرات المدخلات غير المرتبطة. بعبارة أخرى، لا تحتوي تعبيراتنا الرمزية على أي عملية متعلقة بالآلة الافتراضية (الآلية نفسها لا تعتمد على المستخدم) ولكن فقط عمليات متعلقة بالبرنامج الأصلي.

على سبيل المثال، فيما يلي مثال على التجسيد. على اليسار لدينا شجرة AST تحتوي على تعبيرات فرعية لا تتضمن متغيرًا رمزيًا (`1 + 2` و `6 ^ 3`). لذا يتم تجسيد هذه الفروع واستبدالها بثوابت `3` و `5` مما يؤدي إلى شجرة AST على اليمين. **هذه هي الطريقة التي نلغي بها الافتراضية عن الكود.**

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/8096/857ed50cfe9cb2347f816ece1d8dc4c13174c971dcb65ebc5621be14269a5ca8.png">
</p>

**ملاحظة حول القطع العكسي على مستوى الصيغة**: كما هو شائع في التنفيذ الرمزي، يتم أولاً حساب التمثيل الرمزي بطريقة تقدمية على طول المسار، ثم تتم إزالة جميع العمليات المنطقية والتعريفات التي لا تؤثر على النتيجة النهائية ولا على المسار المتبع من التعبير الرمزي (قطع الصيغة، المعروف أيضًا بتقليم الصيغة). يتبين أن هذا يؤدي على الصيغة ما يعادل تحليل قطع عكسي للكود من مخرجات البرنامج. وبالتالي، عند عودة دالة `secret`، يكون لدينا تعبير للعلاقة بين المدخلات والمخرجات بدون تعليمات VMProtect.

يأخذ السكريبت `./attack_vmp.py` كمعاملات ملف الأثر وحجم المتغيرات الرمزية. تذكر، كانت `edi` و `esi`، لذا فإن طولهما 4 بايت. نتيجة السكريبت هي التالية:```
$ ./attack_vmp.py --trace1 ./vmp_traces/sample2.vmp.trace --symsize 4
[+] Replaying the VMP trace
[+] Symbolize inputs
[+] Instruction executed: 12462
[+] Emulation done
[+] Return value: 0x3
[+] Devirt expr: (bvor (bvnot (bvor (bvnot (bvnot x)) (bvnot y))) (bvnot (bvor (bvnot x) (bvnot (bvand (bvnot y) (bvnot y))))))
[+] Synth expr: (bvxor x y)

[+] LLVM IR ==============================

; ModuleID = 'tritonModule'
source_filename = "tritonModule"

define i32 @__triton(i32 %SymVar_0, i32 %SymVar_1) {
entry:
  %0 = xor i32 %SymVar_0, %SymVar_1
  ret i32 %0
}

[+] EOF LLVM IR ==============================

مع ذلك، لم نتمكن من استعادة التعبير الأصلي الذي كان عبارة عن عملية `XOR` بسيطة. يبدو أن `XOR` قد تُرجمت إلى عمليات بتية. لحسن الحظ، أصدرنا مؤخرًا ميزات جديدة في مشروع Triton وهي [أداة توليف](https://github.com/JonathanSalwan/Triton/issues/1074) ورافع إلى [LLVM-IR](https://github.com/JonathanSalwan/Triton/issues/1078). وبالتالي، يمكننا توليف التعبير الذي يعطينا التعبير `(bvxor x y)`. إنه فوز جيد ويمكننا الآن المضي قدمًا عن طريق رفع هذا التعبير إلى LLVM-IR ثم تجميع كود ثنائي جديد منزوع الظاهرية.


## مثال 2: عملية MBA محمية

حسنًا، لنلقِ نظرة على مثال آخر يحاول إخفاء عملية MBA. كود المصدر الأصلي هو التالي:```cpp
// This function is an MBA that computes: (x ^ 92) + y
// We will protect this MBA with VMProtect and see if we can recover "(x ^ 92) + y"
char secret(char x, char y) {
  VMProtectBegin("secret");
  int a = 229 * x + 247;
  int b = 237 * a + 214 + ((38 * a + 85) & 254);
  int c = (b + ((-(2 * b) + 255) & 254)) * 3 + 77;
  int d = ((86 * c + 36) & 70) * 75 + 231 * c + 118;
  int e = ((58 * d + 175) & 244) + 99 * d + 46;
  int f = (e & 148);
  int g = (f - (e & 255) + f) * 103 + 13;
  int r = (237 * (45 * g + (174 * g | 34) * 229 + 194 - 247) & 255) + y;
  VMProtectEnd();
  return r;
}

بمجرد إنشاء [VMP trace](https://github.com/jonathansalwan/vmprotect-devirtualization/blob/HEAD/vmp_traces/sample3.vmp.trace)، دعنا نشغّل النص البرمجي `./attack_vmp.py`.```
$ ./attack_vmp.py --trace1 ./vmp_traces/sample3.vmp.trace --symsize 1
[+] Replaying the VMP trace
[+] Symbolize inputs
[+] A potential symbolic jump found on CF flag: 0x821dac: popfq - Model: {0: x:32 = 0xa3, 1: y:32 = 0xff}
[+] A potential symbolic jump found on CF flag: 0x87f437: popfq - Model: {0: x:32 = 0xa3, 1: y:32 = 0xff}
[+] Instruction executed: 25085
[+] Emulation done
[+] Return value: 0x5f
[+] Devirt expr: In: (bvadd (bvadd (bvshl (bvadd (_ bv1 32) (bvnot (bvlshr (concat (_ bv0 8) (_ bv0 8) ((_ extract 15 8)  ...
[+] Synth expr: In: (bvadd (bvadd (bvshl (bvadd (_ bv1 32) (bvnot (bvlshr (concat (_ bv0 8) (_ bv0 8) ((_ extract 15 8)  ...

[+] LLVM IR ==============================

; ModuleID = 'tritonModule'
source_filename = "tritonModule"

define i32 @__triton(i8 %SymVar_0, i8 %SymVar_1) {
entry:
  %0 = xor i8 %SymVar_0, 92
  %1 = and i8 %SymVar_0, 0
  %2 = zext i8 %1 to i32
  %3 = or i32 0, %2
  %4 = shl i32 %3, 8
  %5 = zext i8 %0 to i32
  %6 = or i32 %4, %5
  %7 = and i8 %SymVar_1, 0
  %8 = zext i8 %7 to i32
  %9 = or i32 0, %8
  %10 = shl i32 %9, 8
  %11 = zext i8 %SymVar_1 to i32
  %12 = or i32 %10, %11
  %13 = zext i8 %7 to i32
  %14 = or i32 0, %13
  %15 = shl i32 %14, 8
  %16 = zext i8 %SymVar_1 to i32
  %17 = or i32 %15, %16
  %18 = lshr i32 %17, 7
  %19 = xor i32 %18, -1
  %20 = add i32 1, %19
  %21 = shl i32 %20, 8
  %22 = add i32 %21, %12
  %23 = add i32 %22, %6
  ret i32 %23
}

[+] EOF LLVM IR ==============================

باستخدام تحسينات LLVM، تمكنا من إزالة الضوضاء من المخرجات المفككة وبالتالي كسر الـMBA. نرى عملية `XOR` مع ثابت (`%0 = xor i8 %SymVar_0, 92`) و `+ y` (`%6 = add nsw i32 %5, %1`). التعليمات بينهما تتعلق فقط بالعلامة. لتلخيص هذا المثال، قمنا بفك التظليل الكامل لوظيفة `secret` باستخدام نص `attack_vmp.py` ثم كسرنا الـMBA بالكامل باستخدام تحسينات LLVM.

## مثال 3: أكثر من كتلة أساسية واحدة

لقد حصلنا على نتائج جيدة جدًا إذا كانت وظيفة `secret` تحتوي على كتلة أساسية واحدة فقط بغض النظر عن حجمها. لذا عند هذه النقطة، نحن قادرون على فك التظليل لمسار واحد. لإعادة بناء سلوك الوظيفة بالكامل، علينا فك التظليل للمسارات التي يمكن الوصول إليها تباعًا. للقيام بذلك، يجب إجراء تغطية مسار على الفروع المعتمدة على المستخدم. في النهاية، نحصل على شجرة مسار تمثل المسارات المختلفة للوظيفة الأصلية. يتم الحصول على شجرة المسار عن طريق إدخال بناء if-then-else من تتبعين T1 و T2 بنفس البادئة متبوعين بشرط C في T1 و not(C) في T2. بمجرد بناء شجرة المسار، يمكننا ترك LLVM لتوليد CFG.

<p align="center">
  <img src="https://assets.kitploit.com/production/public/readmes/8096/fc5d1bf9a1544b9b44ef164247f3fc38d04bf45d7c2d7a3c0b21ea3d6636cd39.png">
</p>

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

حسنًا، لننظر إلى العينة التالية:```cpp
int secret(int x, int y) {
  VMProtectBegin("secret");
  int r = 0;
  if (x + y == 1001)
    r = x + 1;
  else
    r = y - 1;
  VMProtectEnd();
  return r;
}

يخبرنا السكربت أنه قد يكون هناك قفز رمزي محتمل موجود على العلم `AF` عند العنوان `0x80d905`. كما يوفر نموذجًا جديدًا (باستخدام التنفيذ الرمزي) والذي يجب أن يأخذ المسار الآخر. لذا دعنا ننشئ تتبعًا ثانيًا باستخدام هذا النموذج (إذا ألقيت نظرة على النموذج، فهو صحيح فيما يتعلق بكود المصدر الخاص بنا).```
$ ./pin/pin -t ./pin/source/tools/VMP_Trace/obj-intel64/VMP_Trace.so -start 4198848 -end 4198928 -- ./vmp_binaries/binaries/sample5.vmp.bin 0 1001 &> ./vmp_traces/sample5.vmp.trace.2

في هذه الخطوة، قمنا بإزالة الافتراضية (devirtualized) للتتبعين ودمجناهما في تعبيرات `if-then-else`.
بعد رفع التعبير إلى LLVM-IR، نحصل على CFG يحتوي على 480 تعليمة LLVM فقط، وهو
مكسب جيد مقارنة بآلاف التعليمات التي يتم تنفيذها بواسطة الآلة الافتراضية.
لكن يمكننا القيام بما هو أفضل إذا استخدمنا تحسينات LLVM:```llvm
$ opt -S -O3 ./devirt/sample5.ll
; ModuleID = './devirt/sample5.ll'
source_filename = "tritonModule"

; Function Attrs: mustprogress nofree norecurse nosync nounwind readnone willreturn
define i32 @__triton(i32 %SymVar_0, i32 %SymVar_1) local_unnamed_addr #0 {
entry:
  %0 = add i32 %SymVar_0, 1
  %1 = add i32 %SymVar_1, -1
  %2 = add i32 %SymVar_1, %SymVar_0
  %.not = icmp eq i32 %2, 1001
  %3 = select i1 %.not, i32 %0, i32 %1
  ret i32 %3
}

attributes #0 = { mustprogress nofree norecurse nosync nounwind readnone willreturn }