يوضح هذا المقال كيف يمكن لأدوات التنفيذ التخميني TIKTAG تسريب علامات ذاكرة ARM MTE، مما يتيح هجمات عملية لإفساد الذاكرة ضد Chrome ونظام Linuxيوضح هذا المقال كيف يمكن لأدوات التنفيذ التخميني TIKTAG تسريب علامات ذاكرة ARM MTE، مما يتيح هجمات عملية لإفساد الذاكرة ضد Chrome ونظام Linux

دراسة تفصّل هجمات عملية تتجاوز حماية MTE في Chrome وLinux

نبذة مختصرة

1. المقدمة

2. الخلفية

  • امتداد وضع علامات الذاكرة
  • هجوم التنفيذ التخميني

3. نموذج التهديد

4. العثور على أدوات تسريب العلامات

  • قالب تسريب العلامات
  • اختبار تسريب العلامات الضبابي

5. أدوات TIKTAG

  • TIKTAG-v1: استغلال انكماش التخمين
  • TIKTAG-v2: استغلال إعادة التوجيه من التخزين إلى التحميل

6. هجمات العالم الحقيقي

6.1. مهاجمة Chrome

7. التقييم

8. الأعمال ذات الصلة

9. الخلاصة والمراجع

\

هجمات العالم الحقيقي

لإثبات قابلية استغلال أدوات TIKTAG في التخفيف القائم على MTE، يطور هذا القسم هجومين من هجمات العالم الحقيقي ضد Chrome ونواة Linux (الشكل 9). هناك عدة تحديات لإطلاق هجمات العالم الحقيقي باستخدام أدوات TIKTAG. أولاً، يجب تنفيذ أدوات TIKTAG في مساحة العنوان المستهدفة، مما يتطلب من المهاجم إنشاء أو العثور على أدوات من النظام المستهدف. ثانياً، يجب على المهاجم التحكم في حالة الذاكرة المؤقتة ومراقبتها لتسريب نتائج فحص العلامات. في ما يلي، نوضح هجمات العالم الحقيقي باستخدام أدوات TIKTAG على نظامين من أنظمة العالم الحقيقي: متصفح Google Chrome (§6.1) ونواة Linux (§6.2)، ونناقش استراتيجيات التخفيف.

\ 6.1. مهاجمة Chrome

المتصفح متصفح الويب هو سطح هجوم أساسي للهجمات القائمة على الويب لأنه يعالج محتوى ويب غير موثوق به، مثل JavaScript و HTML. نقدم أولاً نظرة عامة على نموذج التهديد (§6.1.1) ونوفر أداة TIKTAG مُنشأة في محرك V8 JavaScript (§6.1.2). ثم نوضح فعالية أدوات TIKTAG في استغلال المتصفح (§6.1.3) ونناقش استراتيجيات التخفيف (§6.1.4).

\ ==6.1.1. نموذج التهديد.== نتبع نموذج التهديد النموذجي لهجمات متصفح Chrome، حيث يهدف المهاجم إلى استغلال ثغرات تلف الذاكرة في عملية العرض. نفترض أن المستخدم الضحية يزور موقع الويب الذي يسيطر عليه المهاجم، والذي يقدم صفحة ويب ضارة. تتضمن صفحة الويب HTML و JavaScript مُصممة، والتي تستغل ثغرات تلف الذاكرة في عملية عرض الضحية. نفترض أن جميع تقنيات التخفيف المتطورة في Chrome موجودة، بما في ذلك ASLR [18]، CFI [15]، عزل الموقع [53]، و V8 sandbox [56]. بالإضافة إلى ذلك، كدفاع متعامد، نفترض أن عملية العرض تمكّن وضع علامات MTE عشوائية في PartitionAlloc [2].

\ ==6.1.2. إنشاء أداة TIKTAG.== في بيئة V8 JavaScript، تم إنشاء TIKTAG-v2 بنجاح وتسريب علامات MTE لأي عنوان ذاكرة. ومع ذلك، لم نجد أداة TIKTAG-v1 قابلة للإنشاء، حيث لم يكن قيد التوقيت الضيق بين BR و CHECK ممكناً في تقنية الهروب من V8 sandbox التخمينية الخاصة بنا (§A).

أداة V8 TikTag-v2. الشكل 8 هو أداة TIKTAG-v2 المُنشأة في محرك V8 JavaScript وكود C الزائف الخاص بها بعد تجميع JIT. باستخدام هذه الأداة، يمكن للمهاجم معرفة ما إذا كانت العلامة المخمنة Tg تطابق العلامة Tm المعينة لـ target_addr. يُعد المهاجم ثلاث مصفوفات، slow و victim و probe، وقيمة idx. slow هي Unit8Array بطول 64 ويتم الوصول إليها في BR لتشغيل التنبؤ الخاطئ للفرع. victim هي Float64Array بطول 64، والتي يتم الوصول إليها لتشغيل إعادة التوجيه من التخزين إلى التحميل. probe هي Uint8Array بطول 512، ويتم الوصول إليها في

\ TEST لتسريب نتيجة فحص العلامة. يتم استخدام قيمة idx من نوع Number في الوصول خارج الحدود لـ victim. يتم اختيار قيمة idx بحيث يشير victim[idx] إلى targetaddr بعلامة مخمنة Tg (أي، (Tg«56)|targetaddr). للوصول بشكل تخميني إلى target_addr خارج V8 sandbox، استفدنا من تقنية الهروب من V8 sandbox التخمينية التي اكتشفناها أثناء بحثنا، والتي نفصلها في §A. السطر 8 من الشكل 8a هو كتلة BR من أداة TIKTAG-v2، مما يؤدي إلى تشغيل التنبؤ الخاطئ للفرع بـ slow[0].

\ السطر 12-13 هو كتلة CHECK، التي تؤدي إعادة التوجيه من التخزين إلى التحميل مع victim[idx]، والوصول إلى target_addr بعلامة مخمنة Tg. عند تجميع هذا الكود بـ JIT (الشكل 8b)، يتم إجراء فحص حدود، ومقارنة idx مع victim.length. إذا كانت idx فهرساً خارج الحدود، يعيد الكود undefined، ولكن إذا استغرق حقل victim.length وقتاً طويلاً للتحميل، فإن وحدة المعالجة المركزية تنفذ تخمينياً تعليمات التخزين والتحميل التالية.

\ بعد ذلك، ينفذ السطر 17 كتلة TEST، التي تصل إلى probe بالقيمة المُعاد توجيهها val كفهرس. مرة أخرى، يسبق فحص حدود على val مقابل طول probe، لكن هذا الفحص ينجح حيث أن PROBEOFFSET أصغر من طول مصفوفة probe. نتيجة لذلك، يتم تخزين probe[PROBEOFFSET] مؤقتاً فقط عندما تنجح إعادة التوجيه من التخزين إلى التحميل، وهي الحالة عندما يطابق Tg Tm.

\ ==6.1.3. هجوم تجاوز Chrome MTE.== يوضح الشكل 9a هجوم تجاوز MTE الشامل على متصفح Chrome مع بدائي تسريب العلامات التعسفي لأدوات TIKTAG. نفترض وجود ثغرة تجاوز سعة المخزن المؤقت في عملية العرض، حيث يكون استغلال ثغرة زمنية (على سبيل المثال، use-after-free) هو نفسه إلى حد كبير. تُجاوز الثغرة مؤشراً (أي، vuln_ptr) إلى كائن ضعيف (أي، objvuln)، مما يفسد الكائن المجاور (أي، objtarget).

\ مع فرض MTE من PartitionAlloc، يكون للكائنين علامات مختلفة باحتمال 14/15. لتجنب رفع استثناء، يحتاج المهاجم إلى التأكد من أن علامات objvuln و objtarget هي نفسها. يمكن استخدام TIKTAG-v2 لتسريب علامة objvuln ( 1 ) و objtarget ( 2 ). إذا كانت كلتا العلامتين المُسربتين متماثلتين، يستغل المهاجم الثغرة، والتي لن ترفع خطأ فحص علامة ( 3 ). وإلا، يحرر المهاجم ويعيد تخصيص objtarget ويعود إلى الخطوة الأولى حتى تتطابق العلامات.

\ ==تشغيل قناة جانبية الذاكرة المؤقتة.== لاستغلال أداة TIKTAG بنجاح، يحتاج المهاجم إلى تلبية المتطلبات التالية:

i) تدريب الفرع،

ii) التحكم في الذاكرة المؤقتة، و

iii) قياس الذاكرة المؤقتة. يمكن تلبية جميع المتطلبات الثلاثة في JavaScript.

أولاً، يمكن للمهاجم تدريب متنبئ الفرع عن طريق تشغيل الأداة مع slow[0] غير صفري و idx داخل الحدود، وتشغيل التنبؤ الخاطئ للفرع في BR بقيمة صفر في slow[0] و idx خارج الحدود.

ثانياً، يمكن للمهاجم طرد خطوط الذاكرة المؤقتة لـ slow[0] و victim.length و probe[PROBE_OFFSET] باستخدام تقنيات طرد الذاكرة المؤقتة JavaScript [8، 21، 70].

ثالثاً، يمكن للمهاجم قياس حالة الذاكرة المؤقتة لـ probe[PROBE_OFFSET] باستخدام مؤقت عالي الدقة يعتمد على SharedArrayBuffer [16، 58].

\ ==استغلال ثغرات تلف الذاكرة.== نظراً لعلامات MTE المُسربة، يمكن للمهاجم استغلال ثغرات تلف الذاكرة المكانية والزمانية في العارض. استراتيجية الهجوم هي نفسها إلى حد كبير هجمات تلف الذاكرة التقليدية ولكن يجب التأكد من أن الثغرة لا ترفع خطأ فحص علامة باستخدام العلامات المُسربة. نفصّل استراتيجية الهجوم بشكل أكبر في §C.

\ ==6.1.4. التخفيف.== للتخفيف من هجمات تجاوز MTE القائمة على أدوات TIKTAG في عملية عرض المتصفح، يمكن استخدام التخفيفات التالية:

i) بيئة حماية واعية بالتنفيذ التخميني: لإيقاف المهاجمين من إطلاق هجمات قائمة على TIKTAG من بيئة محمية مثل V8 sandbox، يمكن تعزيز بيئة الحماية من خلال منع أي وصول تخميني للذاكرة خارج منطقة ذاكرة بيئة الحماية. بينما تستخدم متصفحات الويب الحديثة بيئة حماية لعزل محتويات الويب غير الموثوق بها عن العارض، فإنها غالباً ما تتجاهل المسارات التخمينية.

\ على سبيل المثال، Chrome V8 sandbox [56] و Safari Webkit sandbox [1] لا يتوسطان بشكل كامل في المسارات التخمينية [27]. بناءً على تقنيات ضغط المؤشر الحالية [64]، يمكن تقييد المسارات التخمينية إلى منطقة بيئة الحماية من خلال إخفاء البتات العالية للمؤشرات.

\ ii) حاجز التخمين: كما هو مقترح في §5، يمكن أن يؤدي وضع حاجز تخمين بعد BR لأدوات TIKTAG المحتملة إلى منع هجمات تسريب العلامات التخمينية. ومع ذلك، قد لا ينطبق هذا التخفيف في بيئة المتصفح الحرجة للأداء، حيث قد يقدم عبئاً كبيراً على الأداء.

\ iii) منع إنشاء الأداة: كما هو مقترح في §5.2، يمكن تخفيف أداة TIKTAG-v2 عن طريق حشو التعليمات بين تعليمات التخزين والتحميل. يمكن تخفيف أداة TIKTAGv1، على الرغم من أننا لم نجد واحدة قابلة للاستغلال، عن طريق حشو التعليمات بين الفرع والوصول إلى الذاكرة، كما هو موضح في §5.1.

\ 6.2. مهاجمة نواة Linux

تُستخدم نواة Linux على ARM على نطاق واسع للأجهزة المحمولة والخوادم وأجهزة IoT، مما يجعلها هدف هجوم جذاب. يمكن أن يؤدي استغلال ثغرة تلف الذاكرة في النواة إلى تصعيد امتياز المستخدم، وبالتالي فإن MTE هي آلية حماية واعدة لنواة Linux. تشكل الهجمات القائمة على TIKTAG ضد نواة Linux تحديات فريدة تختلف عن هجوم المتصفح (§6.1).

\ هذا لأن مساحة عنوان المهاجم معزولة عن مساحة عنوان النواة حيث سيتم تنفيذ الأداة. في ما يلي، نقدم أولاً نظرة عامة على نموذج التهديد لنواة Linux (§6.2.1) ونقدم أداة TIKTAG لإثبات المفهوم اكتشفناها في نواة Linux (§6.2.2). أخيراً، نوضح فعالية أدوات TIKTAG في استغلال ثغرات نواة Linux (§6.2.3).

\ ==6.2.1. نموذج التهديد.== نموذج التهديد هنا هو نفسه إلى حد كبير نموذج هجمات تصعيد الامتيازات النموذجية ضد النواة. على وجه التحديد، نركز على نواة Android Linux القائمة على ARM، المُعززة بحماية النواة الافتراضية (على سبيل المثال، KASLR و SMEP و SMAP و CFI). نفترض كذلك أن النواة مُعززة بحل وضع علامات MTE عشوائي، مشابه لحلول MTE الجاهزة للإنتاج، Scudo [3].

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

\ علامات غير متطابقة إلى رفع خطأ فحص علامة، وهو أمر غير مرغوب فيه لاستغلالات العالم الحقيقي. أحد التحديات الحرجة في هذا الهجوم هو أنه يجب إنشاء الأداة عن طريق إعادة استخدام كود النواة الموجود وتنفيذها بواسطة استدعاءات النظام التي يمكن للمهاجم استدعاؤها. نظراً لأن بنية ARMv8 تفصل جداول صفحات المستخدم والنواة، لا يمكن لأدوات مساحة المستخدم الوصول بشكل تخميني إلى ذاكرة النواة. هذا الإعداد مختلف جداً عن نموذج التهديد لمهاجمة المتصفح (§6.1)، والذي استفاد من الكود المقدم من المهاجم لإنشاء الأداة. استبعدنا أيضاً إنشاء الأداة القائمة على eBPF [17، 28]، لأن eBPF غير متاح لعملية Android غير المُمتازة [33].

\ ==6.2.2. أداة Kernel TikTag==. كما هو موضح في §4.1، يجب أن تلبي أدوات TIKTAG عدة متطلبات، وكل متطلب يستلزم تحديات في بيئة النواة.

أولاً، في BR، يجب تشغيل تنبؤ خاطئ للفرع مع cond_ptr، والذي يجب أن يكون قابلاً للتحكم من مساحة المستخدم. نظراً لأن معالجات AArch64 الحديثة تعزل تدريب التنبؤ بالفرع بين المستخدم والنواة [33]، يحتاج تدريب الفرع إلى أن يتم من مساحة النواة.

Second, in CHECK, guessptr should be dereferenced. guessptr should be crafted from the user space such that it embeds a guess tag (Tg) and points to the kernel address (i.e., target_addr) to leak the tag (Tm). بخلاف بيئة JavaScript للمتصفح (§6.1)، يتم تطهير البيانات المقدمة من المستخدم بشكل كبير في استدعاءات النظام، لذلك من الصعب إنشاء مؤشر نواة تعسفي.

\ على سبيل المثال، يضمن accessok() أن المؤشر المقدم من المستخدم يشير إلى مساحة المستخدم، ويمنع ماكرو arrayindexnospec الوصول التخميني خارج الحدود مع الفهرس المقدم من المستخدم. وبالتالي، يجب أن يكون guessptr مؤشر نواة موجود، وتحديداً المؤشر الضعيف الذي يسبب تلف الذاكرة. على سبيل المثال، يمكن استخدام مؤشر معلق في use-after-free (UAF) أو مؤشر خارج الحدود في تجاوز سعة المخزن المؤقت. أخيراً، في TEST، يجب إلغاء الإشارة إلى testptr، ويجب أن يكون testptr قابلاً للوصول من مساحة المستخدم. لتسهيل قياس حالة الذاكرة المؤقتة، يجب أن يكون test_ptr مؤشر مساحة مستخدم مقدم من خلال معامل استدعاء نظام.

\ ==الأدوات المكتشفة.== قمنا بتحليل الكود المصدري لنواة Linux يدوياً للعثور على أداة TIKTAG التي تلبي المتطلبات المذكورة أعلاه. ونتيجة لذلك، وجدنا أداة TIKTAG-v1 واحدة قابلة للاستغلال المحتمل في sndtimeruserread() (الشكل 10). تفي هذه الأداة بمتطلبات TIKTAG-v1 (§5.1). في السطر 10 (أي، BR)، يؤدي بيان switch إلى تشغيل تنبؤ خاطئ للفرع بقيمة قابلة للتحكم بواسطة المستخدم tu->tread (أي، condptr). في الأسطر 14-17 (أي، CHECK)، يتم إلغاء الإشارة إلى tread (أي، guessptr) بواسطة أربعة تعليمات تحميل. يشير tread إلى كائن struct sndtimer_tread64 الذي يمكن للمهاجم تخصيصه وتحريره بشكل تعسفي.

\ إذا حولت ثغرة زمنية tread إلى مؤشر معلق، يمكن استخدامه كـ guessptr. في السطر 20، (أي، TEST)، يتم إلغاء الإشارة إلى مؤشر مساحة المستخدم buffer (أي، testptr) في copytouser. نظراً لأن هذه الأداة غير قابلة للوصول مباشرة من مساحة المستخدم، قمنا بإجراء تعديل طفيف على كود النواة؛ قمنا بإزالة الإرجاع المبكر للحالة الافتراضية في السطر 6. يضمن هذا الوصول إلى المخزن المؤقت فقط في المسار التخميني لمراقبة فرق حالة الذاكرة المؤقتة بسبب التنفيذ التخميني.

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

\ خاصة، يعتمد TIKTAG-v1 على انكماش التخمين في أحداث المسار الخاطئ، والتي قد تتضمن أيضاً أخطاء ترجمة العنوان أو استثناءات أخرى في مسار التنبؤ الخاطئ للفرع. نظراً لأن استدعاءات النظام تتضمن تدفقات تحكم معقدة، قد لا يتم تشغيل انكماش التخمين كما هو متوقع. بالإضافة إلى ذلك، قد تصبح عدة أدوات قابلة للاستغلال عند تغيير كود النواة. على سبيل المثال، لم تظهر أداة TIKTAG-v1 في ip6mr_ioctl() سلوك تسريب علامة MTE عند استدعائها من مسار استدعاء النظام الخاص بها (أي، ioctl). ومع ذلك، كان للأداة تسريب علامة عندما تم نقلها إلى استدعاءات نظام أخرى (على سبيل المثال، write) مع تدفق تحكم بسيط.

\ ==6.2.3. هجوم تجاوز Kernel MTE.== يوضح الشكل 9b هجمات تجاوز MTE على نواة Linux. أخذ ثغرة use-afterfree كمثال، نفترض أن المهاجم حدد أداة TIKTAG المقابلة، SysTikTagUAF()، قادرة على تسريب نتيجة فحص علامة المؤشر المعلق الذي أنشأته الثغرة. على سبيل المثال، يمكن لأداة TIKTAG-v1 في sndtimeruser_read() (الشكل 10) تسريب نتيجة فحص علامة tread، والتي يمكن أن تصبح مؤشراً معلقاً بواسطة ثغرة use-after-free أو double-free.

\ يستمر الهجوم كما يلي: أولاً، يحرر المهاجم كائن نواة (أي، objvuln) ويترك مؤشره (أي، vuln_ptr) كمؤشر معلق ( 1 ). بعد ذلك، يخصص المهاجم كائن نواة آخر (أي، objtarget) في عنوان objvuln مع SysAllocTarget() ( 2 ). ثم يستدعي المهاجم SysTikTag() بمخزن مؤقت لمساحة المستخدم (أي، ubuf) ( 3 )، ويسرب نتيجة فحص العلامة (أي، Tm == Tg) عن طريق قياس زمن انتقال الوصول لـ ubuf ( 4 ). إذا تطابقت العلامات، يشغل المهاجم SysExploitUAF()، استدعاء نظام يستغل ثغرة use-after-free ( 5 ). وإلا، يعيد المهاجم تخصيص objtarget حتى تتطابق العلامات.

\ ==تشغيل قناة جانبية الذاكرة المؤقتة.== كما في §6.1.3، يتطلب استغلال أداة TIKTAG الناجح i) تدريب الفرع، ii) التحكم في الذاكرة المؤقتة، و iii) قياس الذاكرة المؤقتة. بالنسبة لتدريب الفرع، يمكن للمهاجم تدريب متنبئ الفرع وتشغيل التخمين بشروط فرع يسيطر عليها المستخدم من مساحة المستخدم. للتحكم في الذاكرة المؤقتة، يمكن للمهاجم مسح مخزن مساحة المستخدم المؤقت (أي، ubuf)، بينما يمكن طرد عنوان ذاكرة النواة عن طريق ارتداد خط الذاكرة المؤقتة [25]. لقياس الذاكرة المؤقتة، يمكن قياس زمن انتقال الوصول لـ ubuf باستخدام العداد الافتراضي (أي، CNTVCT_EL0) أو مؤقت قائم على عداد الذاكرة (أي، دقة دورة CPU القريبة).

\ ==استغلال ثغرات تلف الذاكرة.== تمكّن أدوات TIKTAG من تجاوز MTE واستغلال ثغرات تلف ذاكرة النواة. يمكن للمهاجم استدعاء أداة TIKTAG في النواة لتشغيل تلف الذاكرة بشكل تخميني والحصول على نتيجة فحص العلامة. ثم يمكن للمهاجم الحصول على نتيجة فحص العلامة، وتشغيل تلف الذاكرة فقط إذا تطابقت العلامات. نفصّل عملية هجوم تجاوز MTE لنواة Linux في §D.

\ ==6.2.4. التخفيف.== للتخفيف من أداة TIKTAG في نواة Linux، يجب على مطوري النواة النظر في التخفيفات التالية:

i) حاجز التخمين: يمكن لحواجز التخمين التخفيف بشكل فعال من أداة TIKTAG-v1 في نواة Linux. لمنع المهاجمين من تسريب نتيجة فحص العلامة من خلال مخزن مساحة المستخدم المؤقت، يمكن تعزيز وظائف النواة التي تصل إلى عناوين مساحة المستخدم، مثل copytouser و copyfromuser، بحواجز التخمين. كما هو موضح في §5.1، يمكن تخفيف تسريب نتائج فحص العلامات بوصول التخزين عن طريق وضع حاجز تخمين قبل وصول التخزين (أي، TEST).

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

\ ii) منع إنشاء الأداة: للقضاء على أدوات TIKTAG المحتملة في نواة Linux، يمكن تحليل الكود المصدري للنواة وتصحيحه. نظراً لأنه يمكن أيضاً إنشاء أدوات TIKTAG عن طريق تحسينات المترجم، يمكن إجراء تحليل ثنائي. لكل أداة مكتشفة، يمكن إعادة ترتيب التعليمات أو يمكن إدراج تعليمات إضافية لمنع إنشاء الأداة، باتباع استراتيجيات التخفيف في §5.1 و §5.2.

:::info المؤلفون:

  1. Juhee Kim
  2. Jinbum Park
  3. Sihyeon Roh
  4. Jaeyoung Chung
  5. Youngjoo Lee
  6. Taesoo Kim
  7. Byoungyoung Lee

:::

:::info هذا البحث متاح على arxiv بموجب ترخيص CC 4.0.

:::

\

فرصة السوق
شعار KernelDAO
KernelDAO السعر(KERNEL)
$0.06854
$0.06854$0.06854
-2.57%
USD
مخطط أسعار KernelDAO (KERNEL) المباشر
إخلاء مسؤولية: المقالات المُعاد نشرها على هذا الموقع مستقاة من منصات عامة، وهي مُقدمة لأغراض إعلامية فقط. لا تُظهِر بالضرورة آراء MEXC. جميع الحقوق محفوظة لمؤلفيها الأصليين. إذا كنت تعتقد أن أي محتوى ينتهك حقوق جهات خارجية، يُرجى التواصل عبر البريد الإلكتروني service@support.mexc.com لإزالته. لا تقدم MEXC أي ضمانات بشأن دقة المحتوى أو اكتماله أو حداثته، وليست مسؤولة عن أي إجراءات تُتخذ بناءً على المعلومات المُقدمة. لا يُمثل المحتوى نصيحة مالية أو قانونية أو مهنية أخرى، ولا يُعتبر توصية أو تأييدًا من MEXC.