حماية مساحة الملفات التنفيذية

📅 آخر تحديث: ٢٤ يوليو ٢٠٢٦
✍️ نُشر في: ٢٤ يوليو ٢٠٢٦
الموسوعة الحرة

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

طبّقت أنظمة بوروز الكبيرة ، بدءًا من بوروز 5000 الذي طُرح عام 1961، حماية مساحة التنفيذ باستخدام بنية مُوسومة . وكانت جميع عمليات الوصول إلى التعليمات البرمجية والبيانات تتم عبر مُعرّفات ، تحمل علامات ذاكرة تمنع تعديلها؛ فمُعرّفات التعليمات البرمجية لا تسمح بتعديلها، ومُعرّفات البيانات لا تسمح بتنفيذها كتعليمات برمجية.

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

تطبيقات نظام التشغيل

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

ستكون التقنية التي توفر محاكاة مستقلة عن بنية المعالج فعّالة على جميع المعالجات التي لا يدعمها الجهاز. يشير قسم "المعالجات الأخرى المدعومة" إلى المعالجات التي تسمح ببعض الطرق غير الواضحة، حيث لا يوجد بت NX صريح، ولكن يسمح الجهاز بمحاكاته بطريقة ما.

أندرويد

ابتداءً من نظام أندرويد 2.3 والإصدارات الأحدث، تحتوي البنى التي تدعم هذه الميزة على صفحات غير قابلة للتنفيذ افتراضياً، بما في ذلك مكدس الذاكرة وكومة الذاكرة غير القابلتين للتنفيذ. [ 1 ] [ 2 ] [ 3 ]

فري بي إس دي

ظهر الدعم الأولي لبت NX ، على معالجات x86-64 و IA-32 التي تدعمه، لأول مرة في FreeBSD -CURRENT في 8 يونيو 2004. وقد كان موجودًا في إصدارات FreeBSD منذ الإصدار 5.3.

لينكس

يدعم نواة لينكس بت NX على معالجات x86-64 و IA-32 التي تدعمه، مثل معالجات 64 بت الحديثة من إنتاج AMD و Intel و Transmeta و VIA. أُضيف دعم هذه الميزة في وضع 64 بت على معالجات x86-64 في عام 2004 بواسطة أندي كلين ، وفي وقت لاحق من العام نفسه، أضاف إنجو مولنار دعمها في وضع 32 بت على معالجات 64 بت. أصبحت هذه الميزات جزءًا من نواة لينكس الرئيسية منذ إصدار النسخة 2.6.8 في أغسطس 2004. [ 4 ]

إن توفر بت NX على نواة x86 ذات 32 بت، والتي يمكن تشغيلها على كل من وحدات المعالجة المركزية x86 ذات 32 بت ووحدات المعالجة المركزية المتوافقة مع IA-32 ذات 64 بت، أمر مهم لأن نواة x86 ذات 32 بت لا تتوقع عادةً بت NX الذي توفره AMD64 أو IA-64 ؛ وتضمن رقعة تمكين NX أن تحاول هذه النوى استخدام بت NX إذا كان موجودًا.

بعض توزيعات لينكس المكتبية ، مثل فيدورا وأوبونتو وأوبن سوزي ، لا تُفعّل خيار HIGHMEM64 افتراضيًا في نواة النظام، وهو خيار ضروري للوصول إلى بت NX في وضع 32 بت، لأن وضع PAE المطلوب لاستخدام بت NX يُسبب فشلًا في الإقلاع على معالجات ما قبل بنتيوم برو (بما في ذلك بنتيوم MMX) ومعالجات سيليرون إم وبنتيوم إم التي لا تدعم NX. ومن المعالجات الأخرى التي لا تدعم PAE: AMD K6 والإصدارات الأقدم، وترانسميتا كروسو ، و VIA C3 والإصدارات الأقدم، وجيود GX وLX. كما أن إصدارات VMware Workstation الأقدم من 4.0، وإصدارات Parallels Workstation الأقدم من 4.0، و Microsoft Virtual PC و Virtual Server لا تدعم PAE على نظام التشغيل الضيف. يوفر كل من فيدورا كور 6 وأوبونتو 9.10 والإصدارات الأحدث حزمة نواة PAE التي تدعم PAE وNX.

لطالما كانت حماية ذاكرة NX متاحة في أوبونتو لأي نظام يمتلك المكونات المادية اللازمة لدعمها ويعمل بنواة 64 بت أو نواة خادم 32 بت. كما توفر نواة سطح المكتب PAE 32 بت (linux-image-generic-pae) في أوبونتو 9.10 والإصدارات الأحدث، وضع PAE المطلوب للأجهزة المزودة بميزة NX CPU. أما بالنسبة للأنظمة التي تفتقر إلى مكونات NX، فتُقدم نواة 32 بت الآن محاكاة تقريبية لميزة NX CPU عبر محاكاة برمجية، مما يُساعد على منع العديد من الثغرات التي قد يستغلها المهاجمون من ذاكرة المكدس أو الكومة.

كما أن وظيفة عدم التنفيذ كانت موجودة أيضاً في معالجات أخرى غير x86 تدعم هذه الوظيفة منذ العديد من الإصدارات.

درع تنفيذي

أصدر إنجو مولنار، مطور نواة ريد هات، رقعةً لنواة لينكس باسم "إكسيك شيلد" لمحاكاة وظائف NX واستخدامها على معالجات x86 ذات 32 بت . نُشرت رقعة "إكسيك شيلد" على قائمة بريد نواة لينكس في 2 مايو 2003، ولكن رُفض دمجها مع النواة الأساسية لاحتوائها على بعض التغييرات الجذرية في الكود الأساسي لمعالجة الأجزاء المعقدة من المحاكاة. يدعم "إكسيك شيلد" المعالجات القديمة، مُحاكياً بذلك محاكاة NX من خلال تتبع الحد الأعلى لقطاع الكود. لا يُضيف هذا سوى بضع دورات من الحمل الزائد أثناء تبديل السياق، وهو حمل ضئيل للغاية. بالنسبة للمعالجات القديمة التي لا تحتوي على بت NX، يفشل "إكسيك شيلد" في حماية الصفحات أسفل حد قطاع الكود؛ إذ أن استدعاء الدالة mprotect() لتمييز الذاكرة الأعلى، مثل المكدس، على أنها قابلة للتنفيذ، سيؤدي أيضاً إلى تمييز جميع الذاكرة أسفل هذا الحد على أنها قابلة للتنفيذ. وبالتالي، في هذه الحالات، تفشل آليات "إكسيك شيلد". هذا هو ثمن انخفاض الحمل الزائد لـ Exec Shield. يتحقق Exec Shield من وجود علامتين في رأس ملف ELF ، تحددان ما إذا كان يجب أن يكون المكدس أو الكومة قابلاً للتنفيذ. تُسمى هاتان العلامتان PT_GNU_STACK و PT_GNU_HEAP على التوالي. يسمح Exec Shield بتعيين هذه الضوابط لكل من الملفات التنفيذية الثنائية والمكتبات؛ فإذا قام ملف تنفيذي بتحميل مكتبة تتطلب تخفيف قيد معين، فسيرث الملف التنفيذي تلك العلامة ويتم تخفيف ذلك القيد.

  • المعالجات المدعومة بالأجهزة: جميع المعالجات التي يدعمها نظام لينكس NX
  • المحاكاة: تقريب NX باستخدام حد مقطع الكود على IA-32 ( x86 ) والمتوافقة
  • دعم آخر: لا يوجد
  • التوزيعة القياسية: فيدورا كور وريد هات إنتربرايز لينكس
  • تاريخ الإصدار: 2 مايو 2003

PaX

تستطيع تقنية PaX NX محاكاة وظائف NX، أو استخدام بت NX المدمج في الجهاز. تعمل PaX على معالجات x86 التي لا تحتوي على بت NX، مثل معالجات x86 ذات 32 بت. لا تزال نواة لينكس لا تتضمن PaX (حتى مايو 2007)؛ لذا يجب دمج التصحيح يدويًا.

يوفر PaX طريقتين لمحاكاة بتات NX، تُسميان SEGMEXEC وPAGEEXEC. تفرض طريقة SEGMEXEC عبئًا إضافيًا ضئيلًا ولكنه قابل للقياس، عادةً أقل من 1%، وهو قيمة ثابتة ناتجة عن نسخ الذاكرة الافتراضية المستخدمة للفصل بين تنفيذ البرنامج والوصول إلى البيانات. [ 5 ] كما يؤدي SEGMEXEC إلى تقليل مساحة العناوين الافتراضية للمهمة إلى النصف، مما يسمح لها بالوصول إلى ذاكرة أقل من المعتاد. لا يُشكل هذا مشكلة إلا إذا احتاجت المهمة إلى الوصول إلى أكثر من نصف مساحة العناوين العادية، وهو أمر نادر الحدوث. لا يتسبب SEGMEXEC في زيادة استخدام البرامج لذاكرة النظام (أي ذاكرة الوصول العشوائي RAM)، بل يُقيد فقط مقدار الذاكرة التي يمكنها الوصول إليها. في وحدات المعالجة المركزية 32 بت، يصبح هذا المقدار 1.5  جيجابايت بدلًا من 3  جيجابايت.

يُوفّر PaX طريقةً مُشابهةً لتقريب Exec Shield في PAGEEXEC لتحسين السرعة؛ إلا أنه عند تحديد مساحة ذاكرة أكبر قابلة للتنفيذ، تفقد هذه الطريقة حمايتها. في هذه الحالات، يعود PaX إلى الطريقة القديمة ذات التكلفة المتغيرة التي يستخدمها PAGEEXEC لحماية الصفحات التي تقل عن حد CS، والتي قد تُصبح عمليةً ذات تكلفة عالية في بعض أنماط الوصول إلى الذاكرة . عند استخدام طريقة PAGEEXEC على وحدة معالجة مركزية تُوفّر بت NX مادي، يتم استخدام بت NX المادي، وبالتالي لا يتم تكبّد أي تكلفة إضافية تُذكر.

يُوفّر PaX قيودًا على وظيفة mprotect() لمنع البرامج من وضع علامات على الذاكرة بطرق تُنتج ذاكرةً مفيدةً لاستغلالها المحتمل . تُؤدي هذه السياسة إلى توقف بعض التطبيقات عن العمل، ولكن يُمكن تعطيلها للبرامج المتأثرة.

تتيح PaX التحكم الفردي في الوظائف التالية للتكنولوجيا لكل ملف تنفيذي ثنائي:

  • بيج إكسيك
  • سيجميكسيك
  • قيود mprotect()
  • محاكاة الترامبولين
  • قاعدة تنفيذية عشوائية
  • قاعدة بيانات mmap() العشوائية

يتجاهل PaX كلاً من PT_GNU_STACK وPT_GNU_HEAP. في السابق، كان PaX يوفر خيارًا لضبط هذه الإعدادات، ولكن تم حذفه لأسباب أمنية، حيث اعتُبر غير مُجدٍ. عادةً ما يُمكن تحقيق نفس نتائج PT_GNU_STACK بتعطيل قيود mprotect()، حيث يقوم البرنامج عادةً بحماية المكدس باستخدام mprotect() عند التحميل. قد لا يكون هذا صحيحًا دائمًا؛ في الحالات التي لا ينجح فيها ذلك، يكفي تعطيل كل من PAGEEXEC وSEGMEXEC لإزالة جميع قيود مساحة التنفيذ، مما يمنح المهمة نفس الحماية على مساحة التنفيذ كما في الأنظمة الأخرى غير PaX.

نظام التشغيل macOS

يدعم نظام macOS لمعالجات Intel بت NX على جميع وحدات المعالجة المركزية التي تدعمها Apple (بدءًا من Mac OS X 10.4.4 - أول إصدار من Intel - فصاعدًا). ​​كان Mac OS X 10.4 يدعم فقط حماية مكدس NX. أما في Mac OS X 10.5، فتتمتع جميع الملفات التنفيذية 64 بت بحماية مكدس NX وحماية الكومة (W^X). يشمل ذلك معالجات x86-64 (Core 2 أو أحدث) ومعالجات PowerPC 64 بت على أجهزة Mac G5 .

نظام التشغيل NetBSD

ابتداءً من NetBSD 2.0 وما بعده (9 ديسمبر 2004)، فإن البنى التي تدعمه تحتوي على مكدس وكومة غير قابلة للتنفيذ. [ 6 ]

تتكون البنى التي تتمتع بدقة لكل صفحة من: alpha و amd64 و hppa و i386 (مع PAE ) و powerpc (ibm4xx) و sh5 و sparc ( sun4m و sun4d ) و sparc64.

البنى التي يمكنها دعم هذه فقط بدقة المنطقة هي: i386 (بدون PAE)، و powerpc الأخرى (مثل macppc).

لا تستفيد البنى الأخرى من المكدس أو الكومة غير القابلة للتنفيذ؛ ولا يستخدم نظام NetBSD افتراضيًا أي محاكاة برمجية لتقديم هذه الميزات على تلك البنى.

أوبن بي إس دي

تُعرف تقنية W^X في نظام التشغيل OpenBSD بأنها تُصنّف الصفحات القابلة للكتابة افتراضيًا على أنها غير قابلة للتنفيذ على المعالجات التي تدعم هذه التقنية. في معالجات x86 ذات 32 بت ، يتم ضبط مقطع التعليمات البرمجية ليشمل جزءًا فقط من مساحة العناوين، وذلك لتوفير مستوى معين من الحماية لمساحة التنفيذ.

تم إصدار OpenBSD 3.3 في 1 مايو 2003، وكان أول إصدار يتضمن W^X.

  • المعالجات المدعومة بالأجهزة: Alpha ، AMD64 ، HPPA ، SPARC
  • المحاكاة: IA-32 (x86)
  • دعم آخر: لا يوجد
  • التوزيع القياسي: نعم
  • تاريخ الإصدار: 1 مايو 2003

سولاريس

يدعم نظام Solaris تعطيل تنفيذ المكدس عالميًا على معالجات SPARC منذ Solaris 2.6 (1997)؛ وفي Solaris 9 (2002)، تمت إضافة دعم لتعطيل تنفيذ المكدس على أساس كل ملف تنفيذي.

ويندوز

تم نشر أول تطبيق لمكدس غير قابل للتنفيذ لنظام التشغيل ويندوز (NT 4.0، 2000 و XP) بواسطة SecureWave عبر منتج SecureStack الخاص بهم في عام 2001، استنادًا إلى عمل PaX. [ 7 ] [ 8 ]

ابتداءً من حزمة الخدمة الثانية لنظام التشغيل ويندوز إكس بي (2004) وحزمة الخدمة الأولى لنظام التشغيل ويندوز سيرفر 2003 (2005)، تم تطبيق ميزات NX لأول مرة على بنية x86 . وتُعرف حماية مساحة الملفات التنفيذية في نظام ويندوز باسم "منع تنفيذ البيانات" (DEP).

في نظامي التشغيل ويندوز إكس بي وسيرفر 2003، كان يتم استخدام حماية NX بشكل افتراضي حصريًا على خدمات ويندوز الحيوية. إذا كان معالج x86 يدعم هذه الميزة في مكوناته المادية، فسيتم تفعيل ميزات NX تلقائيًا في ويندوز إكس بي/سيرفر 2003. أما إذا لم يكن معالج x86 يدعم هذه الميزة، فلن يتم توفير أي حماية.

لم توفر التطبيقات المبكرة لتقنية منع تنفيذ البيانات (DEP ) خاصية عشوائية تخطيط مساحة العناوين (ASLR)، مما سمح بشن هجمات العودة إلى مكتبة libc التي كان من الممكن استخدامها لتعطيل DEP أثناء الهجوم. [ 9 ] توضح وثائق PaX سبب ضرورة ASLR؛ [ 10 ] وقد تم تقديم دليل عملي يشرح بالتفصيل طريقة يمكن من خلالها تجاوز DEP في غياب ASLR. [ 11 ] قد يكون من الممكن تطوير هجوم ناجح إذا كان عنوان البيانات المُجهزة، مثل الصور التالفة أو ملفات MP3، معروفًا للمهاجم.

أضافت مايكروسوفت وظيفة ASLR في نظامي التشغيل ويندوز فيستا وويندوز سيرفر 2008. في هذه المنصة، يتم تطبيق DEP من خلال الاستخدام التلقائي لنواة PAE في أنظمة ويندوز 32 بت، والدعم الأصلي في أنظمة 64 بت. يعمل DEP في ويندوز فيستا عن طريق تحديد أجزاء معينة من الذاكرة على أنها مخصصة لتخزين البيانات فقط، والتي يفهمها المعالج المُفعّل بتقنية NX أو XD على أنها غير قابلة للتنفيذ. [ 12 ] في ويندوز، بدءًا من إصدار فيستا، يمكن معرفة ما إذا كان DEP مُفعّلاً أم مُعطّلاً لعملية معينة من خلال علامة التبويب "العمليات/التفاصيل" في " إدارة مهام ويندوز" .

تُطبّق ويندوز تقنية منع تنفيذ البيانات (DEP) البرمجية (دون استخدام بت NX ) من خلال تقنية " معالجة الاستثناءات المهيكلة الآمنة" (SafeSEH) من مايكروسوفت . بالنسبة للتطبيقات المُجمّعة بشكل صحيح، تتحقق SafeSEH من أن معالج الاستثناء، عند حدوثه أثناء تنفيذ البرنامج، هو المعالج المُعرّف من قِبل التطبيق عند تجميعه أصلاً. يتمثل أثر هذه الحماية في منع المُهاجم من إضافة معالج استثناءات خاص به، والذي قام بتخزينه في صفحة بيانات، من خلال إدخال برمجي غير مُدقّق. [ 12 ] [ 13 ]

عند دعم NX، يتم تفعيله افتراضيًا. يسمح نظام ويندوز للبرامج بالتحكم في الصفحات التي لا يُسمح بتنفيذها من خلال واجهة برمجة التطبيقات (API) الخاصة به ، وكذلك من خلال رؤوس الأقسام في ملف PE . في واجهة برمجة التطبيقات، يُتاح الوصول إلى بت NX أثناء التشغيل من خلال استدعاءات Win32 API، وهما VirtualAlloc[Ex] و VirtualProtect[Ex] . يمكن تحديد كل صفحة على حدة على أنها قابلة للتنفيذ أو غير قابلة للتنفيذ. على الرغم من عدم وجود دعم سابق لأجهزة x86، فقد تم توفير إعدادات الصفحات القابلة للتنفيذ وغير القابلة للتنفيذ منذ البداية. في وحدات المعالجة المركزية التي لا تدعم NX، لا يكون لوجود سمة "قابل للتنفيذ" أي تأثير. تم توثيقها كما لو كانت تعمل، ونتيجة لذلك، استخدمها معظم المبرمجين بشكل صحيح. في تنسيق ملف PE، يمكن لكل قسم تحديد قابليته للتنفيذ. كانت علامة التنفيذ موجودة منذ بداية هذا التنسيق، وقد استخدمتها الروابط القياسية دائمًا بشكل صحيح، حتى قبل ظهور بت NX بفترة طويلة. لهذا السبب، يستطيع ويندوز فرض بت NX على البرامج القديمة. بافتراض التزام المبرمج بأفضل الممارسات، من المفترض أن تعمل التطبيقات بشكل صحيح الآن بعد تفعيل NX. وقد ظهرت مشاكل في حالات قليلة فقط؛ إذ واجهت بيئة تشغيل .NET الخاصة بمايكروسوفت مشاكل مع NX وتم تحديثها.

  • المعالجات المدعومة بالأجهزة: x86-64 (AMD64 و Intel 64)، IA-64 ، Efficeon ، Pentium M (الإصدارات اللاحقة)، AMD Sempron (الإصدارات اللاحقة)
  • المحاكاة: نعم
  • دعم آخر: لا يوجد
  • التوزيع القياسي: ما بعد ويندوز إكس بي
  • تاريخ الإصدار: 6 أغسطس 2004

إكس بوكس

في جهاز إكس بوكس ​​من مايكروسوفت ، على الرغم من أن وحدة المعالجة المركزية لا تحتوي على بت NX، إلا أن الإصدارات الأحدث من XDK حددت حد مقطع التعليمات البرمجية عند بداية قسم .data في نواة النظام (لا ينبغي أن يكون هناك أي تعليمات برمجية بعد هذه النقطة في الظروف العادية). بدءًا من الإصدار 51xx ، تم تطبيق هذا التغيير أيضًا في نواة أجهزة إكس بوكس ​​الجديدة. وقد أدى ذلك إلى تعطيل الأساليب التي كانت تستخدمها الثغرات القديمة لإنشاء برنامج يبقى في النظام . ومع ذلك، سرعان ما تم إصدار ثغرات جديدة تدعم هذا الإصدار الجديد من النواة لأن الثغرة الأساسية في نواة إكس بوكس ​​لم تتأثر.

القيود

عندما يُكتب الكود ويُنفذ أثناء التشغيل - ويُعدّ مُترجم JIT مثالًا بارزًا على ذلك - يُمكن استخدام المُترجم لإنتاج كود استغلالي (مثل استخدام JIT Spray ) مُعلّم للتنفيذ، وبالتالي لن يتم اكتشافه. [ 14 ] [ 15 ]

يمكن أن تسمح البرمجة الموجهة نحو العودة للمهاجم بتنفيذ تعليمات برمجية عشوائية حتى عند فرض حماية مساحة التنفيذ.

انظر أيضاً

مراجع

  1. ↑ "تحسينات أمان إدارة الذاكرة"، نظرة عامة على أمان نظام Android ، تم الاطلاع عليه بتاريخ 29/07/2012.
  2. ↑ "تغيير في كود أندرويد يُفعّل NX افتراضيًا" . تغيير في مستودع مصدر أندرويد . تم الاطلاع عليه بتاريخ 27-08-2019 .
  3. ↑ "متطلبات توافق نظام أندرويد مع NX" . مراجعة كود أندرويد . تم الاطلاع عليه بتاريخ 27-08-2019 .
  4. ↑ "نواة لينكس 2.6.8" . kernelnewbies.org . 14-08-2004 . تم الاطلاع عليه بتاريخ 01-08-2015 .
  5. ↑ "وثائق PaX SEGMEXEC" (TXT) . pax.grsecurity.net . 10 سبتمبر 2004. تم الاطلاع عليه في 25 يناير 2015 .
  6. ↑ NetBSD، المكدس والكومة غير القابلين للتنفيذ ، تم استرجاعه في 2011/07/14.
  7. ↑ "SecureWave | SecureNT" . 31-03-2001. مؤرشف من الأصل في 31-03-2001 . تم الاطلاع عليه في 27-12-2023 .
  8. ↑ "الصفحة الرئيسية لـ PaX - تطبيق علامة PAGE_EXEC لـ IA-32" . 31-03-2001. مؤرشف من الأصل في 31-03-2001 . تم الاطلاع عليه في 27-12-2023 .
  9. ↑ "مدونة عن الإرهاب الإلكتروني" . مؤرشفة من الأصل بتاريخ 9 فبراير 2012. تم الاطلاع عليها بتاريخ 8 يناير 2008 .
  10. ↑ "عشوائية تخطيط مساحة العناوين" . مشروع PaX .
  11. ↑ "غير مطلع - المجلد 2، المقال 4" . مؤرشف من الأصل بتاريخ 12 مارس 2016. تم الاطلاع عليه بتاريخ 19 مارس 2010 .
  12. 1 2 "وصف تفصيلي لميزة منع تنفيذ البيانات (DEP) في Windows XP Service Pack 2 وWindows XP Tablet PC Edition 2005 وWindows Server 2003" . مايكروسوفت . 26-09-2006. مؤرشف من الأصل في 11-09-2014 . تم الاطلاع عليه في 11-07-2008 .
  13. ↑ جونسون، بيتر. "دليل مستخدم Yasm، ويندوز 32: معالجة الاستثناءات المنظمة الآمنة" . شبكات تورتال: برمجيات مفتوحة المصدر ومجانية . مؤرشف من الأصل في 2 يناير 2015. تم الاطلاع عليه في 27 سبتمبر 2015 .
  14. ↑ ديون بلازاكيس. "استغلال المترجم: استنتاج المؤشر ورش JIT" (PDF) .
  15. ↑ أليكسي سينتسوف (5 مارس 2010). "كتابة أكواد شل كود JIT-Spray للمتعة والربح" (ملف PDF) . مؤرشف من الأصل (ملف PDF) بتاريخ 4 مارس 2016.