← أحدث الأبحاث
💻 computer science

Adding Compilation Metadata To Binaries To Make Disassembly Decidable

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

المؤلفون الأصليون: Daniel Engel, Freek Verbeek, Pranav Kumar, Binoy Ravindran

نُشر 2026-04-22
📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

المؤلفون الأصليون: Daniel Engel, Freek Verbeek, Pranav Kumar, Binoy Ravindran

البحث الأصلي مرخَّص بموجب CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

تخيل أنك اشتريت صندوقاً فاخراً ومغلقاً من قطع "ليغو" (LEGO) مع تعليمات البناء، ولكن بدلاً من كتيب واضح مليء بالصور، حصلت على كيس من القطع المتناثرة ومعها ورقة واحدة غامضة تقول: "ابنِ شيئاً ما".

هذا هو ما يحدث عندما توزع شركات البرمجيات الملفات التنفيذية الثنائية (ملفات .exe أو .elf التي يشغلها حاسوبك). بالنسبة للحاسوب، هي مجموعة مثالية من التعليمات. أما بالنسبة للإنسان الذي يحاول فهمها، أو إصلاحها، أو تأمينها، فهي صندوق أسود. وبدون "المخطط الأصلي" (الشيفرة المصدرية)، فإن محاولة الهندسة العكسية لبرنامج ما تشبه محاولة هندسة كعكة عكسياً عن طريق تذوق فتات صغيرة منها؛ قد تخمن أنها كعكة شوكولاتة، لكن لا يمكنك التأكد مما إذا كان بها ملح، أو ما إذا كانت خطوة معينة قد تم تخطيها.

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

المشكلة: كابوس "الصندوق الأسود"

حالياً، عندما يتم تجميع البرمجيات (تحويلها من كود بشري مفهوم إلى كود آلي)، يقوم المترجم (Compiler) برمي "الخريطة". هو يعرف بالضبط أين تبدأ كل تعليمات، وأين يعيش كل متغير، وكيف تتدفق المنطق. ولكن بمجرد "تجريد" الملف (تنظيفه للتوزيع)، تختفي تلك الخريطة.

على الباحثين الأمنيين والمطورين الذين يحاولون تحليل هذه الملفات أن يلعبوا لعبة التخمين:

  • "هل هذه الكتلة من الأرقام هي تعليمات تخبر الحاسوب بالقفز، أم أنها مجرد بيانات عشوائية؟"
  • "أين تنتهي هذه الدالة (Function)؟"
  • "هل كتلة الذاكرة هذه قائمة أسماء أم مكدس من الأرق؟"

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

الحل: "بطاقة الوصفة" (ELLF)

يقترح المؤلفان، دانيال إنجل وفريقه، حلاً وسطاً. هم لا يريدون إعطاء "الوصفة الأصلية" (الشيفرة المصدرية السرية)، لكنهم يريدون إعطاء "قصد المترجم" (بطاقة الوصفة).

لقد ابتكروا أداة تعمل مثل "كاتب ذكي" أثناء عملية البناء. قبل أن يتم إغلاق الملف الثنائي النهائي، يقوم هذا الكاتب بتدوين قائمة صغيرة وفعالة من "الحقائق" ويضعها داخل الملف. تتضمن هذه القائمة:

  1. خريطة التعليمات: "هنا يبدأ كل أمر بالضبط". (لا مزيد من التخمين فيما إذا كان الرقم عبارة عن كود أم بيانات).
  2. خريطة المؤشرات (Pointers): "هذا الرقم هو مؤشر إلى دالة؛ وذلك الرقم هو مجرد قيمة خام".
  3. خريطة الهيكل: "كتلة الذاكرة هذه هي متغير باسم 'user_id'؛ وتلك الكتلة هي مصفوفة مكونة من 50 عنصراً".

التشبيه: "الرافعة" (The Lifter)

تخيل أن لديك أحجية صور مقطوعة (Jigsaw Puzzle) تم لصق قطعها معاً، والصورة الموجودة على ظهرها قد خُدشت.

  • الطريقة القديمة: تحاول تخمين أين تذهب القطع بناءً على أشكالها. أحياناً تصيب، وغالباً لا تصيب.
  • الطالط الجديدة (ELLF): المصنع الذي صنع الأحجية وضع رمز (QR Code) صغيراً وغير مرئي على ظهر كل قطعة. عندما تمسحه، يخبرك الحاسوب بالضبط أين تذهب كل قطعة، وما هي الصورة، وكيف تتصل القطع ببعضها.

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

لماذا يعد هذا أمراً هاماً؟

  1. الأمان: يمكن للأدوات الأمنية الآن النظر إلى الملف الثنائي والقول: "أنا أعلم على وجه اليقين أن كتلة الذاكرة هذه هي مكدس من 10 عناصر"، بدلاً من التخمين. وهذا يجعل اكتشاف الثغرات الأمنية أسهل بكثير.
  2. الثقة: أثبت المؤلفون أنه إذا أخذت برنامجاً، وجردته، وأضفت "بطاقة الوصفة" الخاصة بهم، ثم حاولت إعادة بنائه، فإن النتيجة تعمل بشكل مثالي. إنها تتصرف تماماً مثل البرنامج الأصلي.
  3. الكفاءة: قارنوا "بطاقة الوصفة" الخاصة بهم بمعلومات التصحيح القياسية (DWARF) المستخدمة اليوم. نسختهم أصغر بنسبة 83%. إنها مجرد علامة صغيرة على الملف، وليست عبئاً ضخماً.

العقبة (والواقع المرير)

البحث صريح بشأن ما لا يفعله هذا النظام.

  • هو لا يعطيك الشيفرة المصدرية الأصلية. لن ترى كود C++ الجميل والمليء بالتعليقات الذي كتبه المبرمج. سترى نسخة نظيفة ومنظمة جداً من الكود الآلي، لكن سيتعين عليك القيام بالعمل الشاق المتمثل في معرفة ما الذي يفعله الكود فعلياً (المنطق).
  • هو لا يعمل على لغة التجميع المكتوبة يدوياً. إذا قام مبرمج بكتابة الكود الآلي يدوياً دون استخدام مترجم (Compiler)، فلن يكون هناك "كاتب" لكتابة بطاقة الوصفة. يعتمد النظام على المترجم لتوليد البيانات الوصفية (Metadata).

الخلاصة

يقترح هذا البحث معياراً جديداً لتوزيع البرمجيات. بدلاً من شحن "صندوق أسود" يستحيل تحليله، أو شحن "الشيفرة المصدرية" التي تكشف الأسرار التجارية، يمكننا شحن "صندوق شفاف".

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

غارق في أبحاث مجالك؟

تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.

جرّب Digest →