ثابت BIOS / UEFI تحليل أو كيفية الحصول على الرسم البياني التبعية

"انتهيت تزوير أمس ، لقد خدعت خطتين ... " ... VS Vysotsky أغنية ...

منذ ما يقرب من 3 سنوات (في بداية عام 2016) ، ظهرت رغبة المستخدم في مسألة مشروع UEFITool على GitHub: لإنشاء "رسم تبعية" للوحدات القابلة للتنفيذ المضمنة في BIOS / UEFI.

تلا ذلك نقاش صغير ، ونتيجة لذلك أصبح من الواضح أخيرًا أن هذه المهمة ليست بأي حال من الأحوال تافهة ، فالوظائف المتاحة لحلها ليست كافية ، والآفاق في تلك اللحظة ضبابية ...

وظل هذا السؤال في طي النسيان ، مع احتمال إدراكه في المستقبل غير المحدد (لكن الرغبة ربما بقيت ، والأمل ، كما تعلمون ، مات أخيرًا!).

هناك اقتراح: أخيرًا ، ابحث عن حل لهذه المشكلة!

تحديد الشروط

من المفترض كذلك أننا نتعامل مع Intel 64 و IA-32 Architecture.

من أجل تحديد ما قررنا بناء بشكل لا لبس فيه ، علينا أن نفحص بمزيد من التفصيل سير المراحل الفردية من BIOS / UEFI.

إذا نظرت بعناية إلى أنواع الملفات المقدمة في وحدات تخزين البرامج الثابتة FFS ، اتضح أن معظم الملفات الموجودة تتضمن قسمًا يحتوي على وحدات قابلة للتنفيذ.

حتى إذا أخذنا في الاعتبار البرامج الثابتة الجديدة fangled الخاصة بـ ASUS أو ASRock ، والتي يمكنك من خلالها بسهولة العثور على ما يصل إلى مائة ملف من ملفات EFI_FV_FILETYPE_FREEFORM التي تحتوي على صور بتنسيقات مختلفة ، ومع ذلك ، فهناك ملفات أكثر قابلية للتنفيذ من ملفات الأنواع الأخرى.

+--------------------------------------------------------------------------+ | File Types Information | +--------------------------------------------------------------------------+ | EFI_FV_FILETYPE_RAW = 6 | | EFI_FV_FILETYPE_FREEFORM = 83 | | EFI_FV_FILETYPE_SECURITY_CORE = 1 | | EFI_FV_FILETYPE_PEI_CORE = 1 | | EFI_FV_FILETYPE_DXE_CORE = 1 | | EFI_FV_FILETYPE_PEIM = 57 | | EFI_FV_FILETYPE_DRIVER = 196 | | EFI_FV_FILETYPE_APPLICATION = 1 | | EFI_FV_FILETYPE_SMM = 60 | | EFI_FV_FILETYPE_SMM_CORE = 1 | | EFI_FV_FILETYPE_PAD = 4 | +--------------------------------------------------------------------------+ | Total Files : = 411 | +--------------------------------------------------------------------------+ 

مثال على تكوين بعض البرامج الثابتة العادية (العادية).

على الرغم من عدم تمييز الملفات التي تحتوي على وحدات قابلة للتنفيذ في هذا الجدول ، إلا أنها (حسب التعريف) ستكون جميعها في هذه القائمة ، باستثناء الملفات ذات اللواحق RAW و FREEFORM و PAD.

الملفات ذات اللاحقة "CORE" (SECURITY_CORE و PEI_CORE و DXE_CORE) هي "kernels" المقابلة (وحدات الرأس في المرحلة المقابلة) التي تستقبل التحكم من المراحل الأخرى (أو بعد البدء) ، SMM_CORE هي مرحلة فرعية من مرحلة DXE وفاء. لا يمكن تنفيذ التطبيق إلا بناءً على طلب المستخدم ؛ ولا يحتوي على رابط محدد للمراحل.

لم يتم سرد أنواع الملفات الأكثر شيوعًا: PEIM (وحدات طور PEI) و DRIVER (وحدات طور DXE) و SMM (وحدات طور DXE الفرعية). تشتمل وحدات CORE في مرحلتي PEI و DXE على مرسل ، والذي يتحكم في تسلسل وحدات التحميل / البداية للمرحلة المقابلة.

في المثال أعلاه ، لا توجد خيارات مشتركة ، لكننا لا نتذكرها: على الرغم من أنها موجودة في البرامج الثابتة الحقيقية ، إلا أنها نادرة جدًا. أولئك الذين يرغبون في الحصول على معلومات أكثر تفصيلا وتفصيلا مدعوون للإشارة إلى مقالات CodeRush 1 و 2 و 3 . واستشهد أيضًا بنصيحته: "لمحبي الوثائق الأصلية ، تتوفر مواصفات UEFI PI دائمًا ، ويتم وصف كل شيء بمزيد من التفصيل."

كل وحدة برامج ثابتة قابلة للتنفيذ هي وحدة تنسيق PE + (محمول قابل للتنفيذ) أو مشتقها (Terse Executable: TE-format). الوحدة القابلة للتنفيذ بتنسيق PE + عبارة عن مجموعة من البيانات الهيكلية المعبأة "قليلاً" التي تحتوي على المعلومات التي يحتاجها المحمل لتعيين هذه الوحدة للذاكرة.

لا يحتوي تنسيق PE + (بنية) نفسه على أي آلية للتفاعل بين وحدات PE + الفردية. كل وحدة قابلة للتنفيذ بعد التحميل وبدء التنفيذ هي عملية مستقلة ذاتيا ، (حسنا ، يجب أن تكون كذلك!) ، أي يجب ألا "تفترض" الوحدة أي شيء بشأن ما يجري خارجها.

يتم تنظيم تنظيم التفاعل بين وحدات قابلة للتنفيذ منفصلة من مرحلة واحدة UEFI عن طريق وحدة CORE من المرحلة المقابلة. يمكن للوحدات النمطية القابلة للتنفيذ الفردية تحديد (تثبيت) البروتوكولات ، وطلب (تحديد موقع) واستخدام البروتوكولات التي أعلنتها الوحدات النمطية الأخرى ، وضبط / إعلان الأحداث ، وإعلان (إعلام) معالجات الأحداث.

وبالتالي ، لكل وحدة برامج ثابتة قابلة للتنفيذ ، نحن مهتمون بوجود القطع الأثرية التالية:

1. قائمة البروتوكولات التي تحددها هذه الوحدة. (يتم تعريف كل بروتوكول برقم فريد - دليل).
2. قائمة البروتوكولات التي تستخدمها هذه الوحدة (تحاول استخدامها).
3. قائمة الأحداث التي تعلن هذه الوحدة. (الحدث له رقم فريد - دليل).
4. قائمة معالجات الأحداث موجودة (تم تنفيذها ويمكن تثبيتها / تهيئتها) في هذه الوحدة.

يُعتبر الرسم البياني للاعتماد الثابت لمرحلة BIOS / UEFI محددًا إذا كنا نعرف ، لكل وحدة نمطية قابلة للتنفيذ ، جميع القطع الأثرية المذكورة أعلاه في الأقسام 1-4. (بمعنى آخر ، إذا حددنا جميع المعلومات التي تصف الترابط بين الوحدات).

سننظر فقط في خيار التحليل الثابت ، وهذا يعني أن بعض عناصر الشفرة التي تنفذ العناصر 1-4 يمكن أن تكون غير قابلة للتحقيق (هي أجزاء من الشفرة "الميتة") أو لا يمكن تحقيقها إلا مع خيارات معينة لإدخال / معلمات الإدخال.

كل ما فكرنا فيه حتى الآن يعتمد فقط على مواصفات BIOS / UEFI . ولكي نفهم "العلاقات" الخاصة بالوحدات القابلة للتنفيذ الحالية للبرامج الثابتة المعنية ، سيتعين علينا أن نتعمق أكثر في بنيتها ، مما يعني أنه يجب علينا عكسها جزئيًا على الأقل (استعادة الخوارزميات الأصلية).

كما ذكرنا سابقًا ، فإن الوحدة القابلة للتنفيذ من نوع PE + هي مجرد مجموعة من الهياكل للمُحمِّل ، حيث تقوم في الذاكرة بنقل كائن سيتم نقل التحكم إليه ، ويتألف هذا الكائن بطبيعته من تعليمات المعالج ، بالإضافة إلى بيانات هذه التعليمات.

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

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

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

لنفترض:

1. لقد حللنا بالفعل مشكلة التفكيك الكامل لوحدة تنفيذ BIOS / UEFI محددة ، على سبيل المثال تمكنا من فصل الأوامر والبيانات.
2. هناك شفرة المصدر للوحدة النمطية في اللغة "C" (في BIOS / UEFI الثابتة الحالية ، يتم تطوير الوحدات في الغالب فقط في "C" اللغة).

حتى في هذه الحالة ، فإن مجرد مقارنة النتائج التي تم الحصول عليها (نص التجميع هو مجرد تمثيل نصي لتعليمات المعالج) مع الكود المصدري باللغة "C" سوف يتطلب دائمًا خبرة / مؤهلات جيدة تقريبًا ، باستثناء الحالات المتدهورة تمامًا.

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

هذا مثال على استدعاء الإجراء المشار إليه في جدول. يمثل الجدول الذي يحتوي على روابط لإجراءات مختلفة حالة نموذجية لتنفيذ عرض الواجهات لبروتوكول تعسفي.

لا يجب أن يتكون هذا الجدول من مجرد إشارات إلى الإجراءات ؛ فلا أحد يحظر تخزين البيانات التعسفية في هذه البنية (وهذا مثال على بنية نموذجية "C").

في ما يلي شكل من أشكال هذه المكالمة (بدلاً من سجل ecx ، جميع المتغيرات تقريبًا من سجلات المعالج 32 بت ممكنة):

FF 51 18 call dword ptr [ecx + 18h]

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

إذا علمنا أنه في المثال السابق ، يحتوي السجل "ecx" على مؤشر (عنوان بداية الجدول EFI_PEI_SERVICES) ، يمكننا استلام (تقديم) هذا الأمر في النموذج التالي المفهوم والممتع أكثر:

استدعاء FF 51 18 [exx + EFI_PEI_SERVICES.InstallPpi]

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

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

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

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

لذلك ، نحن على استعداد لتحديد الشروط الكافية لإنشاء الرسم البياني للترابط بين وحدات البرامج الثابتة القابلة للتنفيذ لمرحلة BIOS / UEFI المحددة:

للحصول على رسم تبعي ثابت (أي من المراحل - PEI أو DXE) ، يكفي تفكيك جميع الوحدات القابلة للتنفيذ تمامًا من المرحلة المقابلة (على الأقل فصل كل الأوامر) ، وإلغاء ترجمتها أوامر "الاتصال غير المباشر" الموجودة في الوحدات النمطية المفككة.

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

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

سنكون قادرين حتى على تحديد وصياغة الشروط الضرورية والكافية لإمكانية إنشاء رسم تبعي ثابت لمرحلة PEI.

بناء الرسم البياني للاعتماد الثابت لمرحلة PEI

إن وصف حل مشكلة التفكيك الكامل للوحدات القابلة للتنفيذ لمرحلة PEI وفك تجميع أوامر الاتصال غير المباشر الموجودة في هذه الوحدات النمطية يتجاوز نطاق قصتنا ولن يتم تقديمها فيه - قد يتجاوز عرض هذه المادة في الحجم حجم هذا التأليف.

من الممكن أن يحدث هذا بمرور الوقت كمادة منفصلة ، ولكن في الوقت الحالي - اعرف كيف.

نلاحظ فقط أن استخدام البيانات الوصفية ، بالإضافة إلى وجود هيكل معين لبناء الشفرة الثنائية ، يجعل من الممكن في الممارسة العملية تفكيك وحدات BIOS / UEFI القابلة للتنفيذ بشكل كامل . لا يفترض دليل رسمي على هذه الحقيقة الآن أو في المستقبل. على الأقل في تحليل / معالجة أكثر من مائة (100) BIOS / UEFI من مختلف الصانعين ، لم تكن هناك أمثلة على عدم التمكن من التفكيك الكامل .

علاوة على ذلك ، هناك نتائج محددة فقط (مع التفسيرات: ماذا وكيف وكيف ...).

بنية EFI_PEI_SERVICES هي البنية الأساسية لمرحلة PEI ، والتي يتم تمريرها كمعلمة إلى نقطة إدخال كل وحدة من وحدات PEI وتحتوي على روابط للخدمات الأساسية اللازمة لوحدات PEI لتعمل.

سنهتم فقط بالحقول الموجودة في بداية الهيكل:



جزء من بنية حقيقية من النوع EFI_PEI_SERVICES في أداة فك تجميع IDA Pro.

وهذه هي الطريقة التي تظهر بها في الكود المصدري باللغة "C" (تذكر ، هذه ليست سوى جزء من الهيكل):

 struct EFI_PEI_SERVICES { EFI_TABLE_HEADER Hdr; EFI_PEI_INSTALL_PPI InstallPpi; EFI_PEI_REINSTALL_PPI ReInstallPpi; EFI_PEI_LOCATE_PPI LocatePpi; EFI_PEI_NOTIFY_PPI NotifyPpi; //...      ... }; 

في بداية بنية EFI_PEI_SERVICES ، كما هو الحال في جميع جداول الخدمة "الأساسية" (جداول الخدمات) ، توجد بنية EFI_TABLE_HEADER. تتيح لنا القيم المعروضة في بنية الرأس هذه أن نذكر بشكل لا لبس فيه أنه إذا كانت بنية EFI_PEI_SERVICES نفسها موجودة فعليًا على الجزء من disassembler (راجع حقل "Hdr.Signature") ، فعندئذٍ على الأقل قالب هذا الهيكل!

 struct EFI_TABLE_HEADER { UINT64 Signature; UINT32 Revision; UINT32 HeaderSize; UINT32 CRC32; UINT32 Reserved; }; 

على طول الطريق ، يمكننا أن نثبت أن البرنامج الثابت كان قيد التطوير في وقت كانت فيه نسخة مواصفات UEFI PI هي 1.2 ، وكانت الفترة ذات الصلة من 2009 إلى 2013 ، ولكن في الوقت الحالي (أوائل عام 2019) ، نمت النسخة الحالية من المواصفات بالفعل (نمت حرفيًا في اليوم الآخر) إلى الإصدار 1.7.

من الحقل "Hdr.HeaderSize" ، يمكن تحديد أن الطول الإجمالي للهيكل هو 78 ساعة (وهذا ليس طول الرأس ، كما يوحي الاسم ، ولكن طول بنية EFI_PEI_SERVICES بأكملها).

واجهات EFI_PEI_SERVICES مقسمة إلى 7 فئات / فئات. نحن فقط نذكرهم:

1. خدمات PPI.
2. خدمات وضع التمهيد.
3. خدمات حب.
4. خدمات حجم البرامج الثابتة.
5. خدمات ذاكرة جزيرة الأمير إدوارد.
6. خدمات رمز الحالة.
7. إعادة ضبط الخدمات.

سيتم ربط جميع السرد الإضافي بشكل مباشر بالإجراءات التي تنتمي إلى فئة / فئة خدمات PPI ، والمقصودة لتنظيم التفاعل بين الوحدات النمطية للوحدات القابلة للتنفيذ في مرحلة PEI.

ولا يوجد سوى أربعة لمرحلة جزيرة الأمير إدوارد.

بشكل عام ، ليست هناك حاجة لتخمين الغرض من كل من الواجهات: يتم تحديد الوظيفة تمامًا حسب اسم الواجهة ، وكل التفاصيل في المواصفات .

فيما يلي نماذج أولية لهذه الإجراءات:

 typedef EFI_STATUS (__cdecl *EFI_PEI_INSTALL_PPI)( const EFI_PEI_SERVICES **PeiServices, const EFI_PEI_PPI_DESCRIPTOR *PpiList); typedef EFI_STATUS (__cdecl *EFI_PEI_REINSTALL_PPI)( const EFI_PEI_SERVICES **PeiServices, const EFI_PEI_PPI_DESCRIPTOR *OldPpi, const EFI_PEI_PPI_DESCRIPTOR *NewPpi); typedef EFI_STATUS (__cdecl *EFI_PEI_LOCATE_PPI)( const EFI_PEI_SERVICES **PeiServices, const EFI_GUID *Guid, UINTN Instance, EFI_PEI_PPI_DESCRIPTOR **PpiDescriptor, void **Ppi); typedef EFI_STATUS (__cdecl *EFI_PEI_NOTIFY_PPI)( const EFI_PEI_SERVICES **PeiServices, const EFI_PEI_NOTIFY_DESCRIPTOR *NotifyList); 

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

سأخبركم بسر واحد صغير: من الغريب أن هذا هو جدول الخدمات "الأساسي" لمرحلة PEI ، ومع ذلك ، كما تبين الممارسة ، يمكن تعريفه ليس فقط في وحدة PEI_CORE.

في الطبيعة الحقيقية ، توجد برامج ثابتة تم فيها تعريف / تكوين بنية EFI_PEI_SERVICES واستخدامها في عدة وحدات ، ولم تكن هذه بأي حال نسخًا من وحدة PEI_CORE.

وبالتالي ، خيارات التعليمات البرمجية التالية ممكنة:

 seg000:00785F0D B8 8C A6 78+ mov eax, offset ppiList_78A68C seg000:00785F12 50 push eax ; PpiList seg000:00785F13 57 push edi ; PeiServices seg000:00785F14 89 86 40 0E+ mov [esi+0E40h], eax seg000:00785F1A E8 70 FC FF+ call InstallPpi 

مثال على استدعاء صريح لإجراء "InstallPpi".

 seg000:00787CBB 8B 4D FC mov ecx, [ebp+PeiServices] seg000:00787CBE 50 push eax ; PpiList seg000:00787CBF C7 00 10 00+ mov dword ptr [eax], 80000010h seg000:00787CC5 C7 43 3C A8+ mov dword ptr [ebx+3Ch], offset guid_78A9A8 seg000:00787CCC 8B 11 mov edx, [ecx] seg000:00787CCE 51 push ecx ; PeiServices seg000:00787CCF FF 52 18 call [edx+EFI_PEI_SERVICES.InstallPpi] 

مثال على استدعاء ضمني لواجهة InstallPpi.

 FF 51 18 call dword ptr [ecx+18h] FF 51 18 call [ex+EFI_PEI_SERVICES.InstallPpi] FF 51 1 call dword ptr [ecx+1Ch] FF 51 1C call [ex+EFI_PEI_SERVICES.ReInstallPpi] FF 51 20 call dword ptr [ecx+20h] FF 51 20 call [ex+EFI_PEI_SERVICES.LocatePpi] FF 51 24 call dword ptr [ecx+24h] FF 51 24 call [ex+EFI_PEI_SERVICES.NotifyPpi] 

أمثلة لمكالمات الواجهة الضمنية قبل المصادقة وبعدها.

نلاحظ ميزة مميزة واحدة: في حالة مرحلة PEI لبنية IA-32 ، فإن الواجهات من فئة PPI Services لها إزاحات تبلغ 18 ساعة و 1 ساعة و 20 ساعة و 24 ساعة.

والآن نذكر البيان التالي:

لإنشاء رسم تبعية ثابت لمرحلة PEI ، من الضروري والكافي تفكيك جميع الوحدات القابلة للتنفيذ في المرحلة تمامًا (على الأقل فصل جميع الأوامر) ، وفك تجميع أوامر "الاتصال غير المباشر" مع إزاحة 18 ساعة و 1 ساعة و 20 ساعة و 24 ساعة في الوحدات النمطية المفككة.

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

والآن أمثلة حقيقية للبيانات الحقيقية لوحدات مرحلة PEI الحقيقية. لا نشير عن عمد إلى نتائج BIOS / UEFI التي تم الحصول عليها من الشركة ، ما عليك سوى تقديم أمثلة حول كيفية ظهورها.

مثالان لوصف وحدة PEIM بمعلومات كاملة عن استخدام واجهات PPI Services في هذه الوحدات

  -- File 04-047/0x02F/: "TcgPlatformSetupPeiPolicy" : [007CCAF0 - 007CD144] DEPENDENCY_START EFI_PEI_READ_ONLY_VARIABLE_ACCESS_PPI DEPENDENCY_END Install Protocols: [1] TCG_PLATFORM_SETUP_PEI_POLICY Locate Protocols: [2] EFI_PEI_READ_ONLY_VARIABLE_ACCESS_PPI 

 -- File 04-048/0x030/: "TcgPei" : [007CD160 - 007CF5DE] DEPENDENCY_START EFI_PEI_MASTER_BOOT_MODE_PEIM_PPI EFI_PEI_READ_ONLY_VARIABLE_ACCESS_PPI AND DEPENDENCY_END Install Protocols: [1] AMI_TCG_PLATFORM_PPI [2] EFI_PEI_TCG_PPI [2] PEI_TPM_PPI Locate Protocols: [1] EFI_PEI_TCG_PPI [1] EFI_PEI_READ_ONLY_VARIABLE_ACCESS_PPI [1] TCG_PLATFORM_SETUP_PEI_POLICY [5] PEI_TPM_PPI Notify Events: [1] AMI_TCM_CALLBACK ReInstall Protocols: [1] PEI_TPM_PPI 

قوائم البروتوكولات حسب أنواع الواجهات التي تم استخدامها فيها

أدناه تحت المفسدين هي أمثلة مختصرة لقوائم بروتوكولات PPIM لكل من واجهات فئة خدمات PPI.

تنسيق القوائم كما يلي:

 |  الرقم التسلسلي |  name_PPI |  guid_PPI |  قابل للتنفيذ: اسم المستخدم |

القائمة النهائية لجميع أدلة البروتوكولات التي يتم الرجوع إليها في BIOS / UEFI معين مع وسيلة إيضاح تشير إلى العثور على "PPI Services" لهذه البروتوكولات

أدناه قائمة المفسد من 97 دليل PPi وجدت واستخدامها بشكل صريح في البرامج الثابتة محددة ، والبيانات التي قدمت في وقت سابق.

يسبق كل عنصر من القائمة أسطورة ، والتي تعكس جميع أنواع استخدام بروتوكول معين.

 "D" - in DEPENDENCY section used "I" - in "InstallPpi" functions used "L" - in "LocatePpi" functions used "R" - in "ReInstallPpi" functions used "N" - in "NotifyPpi" functions used 

فترات قائمة البروتوكول التالية جديرة بالملاحظة في BIOS / UEFI:

1. رقم 38-50.
   تحديد البروتوكولات / الأحداث (InstallPpi) التي لا تستخدمها أي وحدة نمطية.
2. رقم 87-95.
   محاولة طلب البروتوكولات التي لم يتم تثبيتها بواسطة أي وحدة نمطية من هذه البرامج الثابتة.
   
3. رقم 96-97.
   حدثان "إعلام" ، لم تكلفهما أي وحدة نمطية عن إعلان الواجهة المقابلة ، على التوالي ، على الرغم من أن هذه الإجراءات قد أعلنت في وحدات قابلة للتنفيذ ، لكنها لن تعمل أبدًا.

الخاتمة

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

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