स्टेटिक BIOS / UEFI विश्लेषण या एक निर्भरता ग्राफ कैसे प्राप्त करें

"मैंने कल फोर्जिंग पूरी की," मैंने दो योजनाएँ रचीं ... " ... वी.एस. व्योस्की गीत ...

लगभग 3 साल पहले (2016 की शुरुआत में), एक उपयोगकर्ता की इच्छा GitHub पर UEFITool परियोजना के मुद्दे पर दिखाई दी: BIOS / UEFI में शामिल निष्पादन योग्य मॉड्यूल के लिए "निर्भरता ग्राफ" बनाने के लिए।

यहां तक ​​कि एक छोटी सी चर्चा की गई, जिसके परिणामस्वरूप यह अंततः स्पष्ट हो गया कि यह कार्य किसी भी तरह से तुच्छ नहीं है, इसके समाधान के लिए उपलब्ध कार्यक्षमता पर्याप्त नहीं है, उस समय संभावनाएं धूमिल हैं ...

और यह सवाल अधर में रह गया, अनिश्चित भविष्य में एहसास की संभावना के साथ (लेकिन इच्छा शायद बनी रही, और आशा है, जैसा कि आप जानते हैं, मर जाता है!)।

एक सुझाव है: अंत में, इस समस्या का हल खोजें!

शर्तों को परिभाषित करें

यह आगे माना जाता है कि हम इंटेल 64 और आईए -32 आर्किटेक्चर के साथ काम कर रहे हैं।

यह निर्धारित करने के लिए कि हमने क्या बनाने का फैसला किया है, हमें BIOS / UEFI के व्यक्तिगत चरणों के कामकाज की अधिक विस्तार से जांच करनी होगी।

यदि आप एफएफएस फर्मवेयर वॉल्यूम में प्रस्तुत फ़ाइल प्रकारों को ध्यान से देखते हैं, तो यह पता चलता है कि अधिकांश मौजूदा फ़ाइलों में निष्पादन योग्य मॉड्यूल के साथ एक अनुभाग शामिल है।

यहां तक ​​कि अगर हम 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, फ्रीफ़ॉर्म और पैड के साथ फ़ाइलों को छोड़कर, इस सूची में सभी होंगे।

प्रत्यय "कोर" (SECURITY_CORE, PEI_CORE और DXE_CORE) के साथ फाइलें संबंधित "कर्नेल" (संबंधित चरण के प्रमुख मॉड्यूल) हैं जो अन्य चरणों से नियंत्रण प्राप्त करते हैं (या शुरुआत के बाद, SMM_CORE DXE चरण का एक उप-चरण है और इसे इस दौरान कहा जाता है। प्रदर्शन। आवेदन केवल उपयोगकर्ता के अनुरोध पर किया जा सकता है, चरणों के लिए एक विशिष्ट बंधन नहीं है।

सबसे आम फ़ाइल प्रकार सूचीबद्ध नहीं थे: PEIM (PEI- चरण मॉड्यूल), DRIVER (DXE- चरण मॉड्यूल) और SMM (DXE उप-चरण मॉड्यूल)। PEI और DXE चरणों के कोर मॉड्यूल में एक डिस्पैचर शामिल होता है, जो संबंधित चरण के लोडिंग / स्टार्टिंग मॉड्यूल के अनुक्रम को नियंत्रित करता है।

उपरोक्त उदाहरण में, कोई संयुक्त विकल्प नहीं हैं, हमें उनके बारे में याद नहीं है: हालांकि वे असली फर्मवेयर में पाए जाते हैं, यह काफी दुर्लभ है। अधिक विस्तृत और विस्तृत जानकारी प्राप्त करने के इच्छुक लोगों को कोडरश लेख 1 , 2 , 3 का उल्लेख करने के लिए आमंत्रित किया जाता है। और उनकी सलाह का भी हवाला देते हैं: "मूल दस्तावेज के प्रशंसकों के लिए, यूईएफआई पीआई विनिर्देश हमेशा उपलब्ध है, सब कुछ बहुत विस्तार से वर्णित है।"

प्रत्येक निष्पादन योग्य फर्मवेयर मॉड्यूल एक PE + (पोर्टेबल निष्पादन योग्य) प्रारूप मॉड्यूल या इसके व्युत्पन्न (प्रतिकूल निष्पादन योग्य: TE- प्रारूप) है। PE + प्रारूप निष्पादन योग्य मॉड्यूल मेमोरी से इस मॉड्यूल को मैप करने के लिए लोडर द्वारा आवश्यक जानकारी युक्त "थोड़ा" पैक संरचित डेटा का एक सेट है।

पीई + प्रारूप (संरचना) में व्यक्तिगत पीई + मॉड्यूल के बीच बातचीत का कोई तंत्र नहीं है। लोड करने और शुरू करने के बाद प्रत्येक निष्पादन योग्य मॉड्यूल एक स्वायत्त स्वतंत्र प्रक्रिया है, (ठीक है, यह ऐसा होना चाहिए!) , यानी। मॉड्यूल को इसके बारे में कुछ भी "अनुमान" नहीं करना चाहिए कि इसके बाहर क्या किया जा रहा है।

एक यूईएफआई चरण के अलग-अलग निष्पादन योग्य मॉड्यूल के बीच बातचीत का संगठन इसी चरण के कोर मॉड्यूल के माध्यम से आयोजित किया जाता है। अलग-अलग निष्पादन योग्य मॉड्यूल प्रोटोकॉल (अनुरोध) स्थापित कर सकते हैं, अनुरोध कर सकते हैं (पता लगा सकते हैं) और अन्य मॉड्यूल द्वारा घोषित प्रोटोकॉल का उपयोग कर सकते हैं, घटनाओं को सेट कर सकते हैं और घोषित कर सकते हैं (सूचित कर सकते हैं) इवेंट हैंडलर।

इस प्रकार, प्रत्येक निष्पादन योग्य फर्मवेयर मॉड्यूल के लिए, हम निम्नलिखित कलाकृतियों की उपस्थिति में रुचि रखते हैं:

1. इस मॉड्यूल को परिभाषित करने वाले प्रोटोकॉल की सूची। (प्रत्येक प्रोटोकॉल को एक अद्वितीय संख्या - गाइड द्वारा पहचाना जाता है)।
2. प्रोटोकॉल की सूची जो इस मॉड्यूल का उपयोग करता है (उपयोग करने की कोशिश करता है)।
3. उन घटनाओं की सूची जो इस मॉड्यूल की घोषणा करती है। (घटना की एक अद्वितीय संख्या है - मार्गदर्शिका)।
4. इस मॉड्यूल में मौजूद ईवेंट हैंडलर की एक सूची (कार्यान्वित और स्थापित / आरंभ की जा सकती है)।

किसी दिए गए BIOS / UEFI चरण के लिए एक स्टेटिक डिपेंडेंसी ग्राफ को परिभाषित किया जाता है, यदि प्रत्येक निष्पादन योग्य चरण मॉड्यूल के लिए, हम उपरोक्त सभी कलाकृतियों को 1-4 खंडों में जानते हैं। (दूसरे शब्दों में, यदि हमने सभी सूचनाओं को परिभाषित किया है जो मॉड्यूल के बीच अन्योन्याश्रितियों का वर्णन करता है)।

हम केवल स्थैतिक विश्लेषण के विकल्प पर विचार करेंगे, इसका मतलब है कि कोड के कुछ तत्व जो आइटम 1-4 को लागू करते हैं, अप्राप्य हो सकते हैं ("मृत" कोड के टुकड़े हैं) या इनपुट डेटा / मापदंडों के लिए कुछ विकल्पों के साथ ही प्राप्त होगा।

अब तक हमने जो कुछ भी सोचा है, वह केवल BIOS / UEFI विनिर्देश पर आधारित है। और प्रश्न में फर्मवेयर के मौजूदा निष्पादन योग्य मॉड्यूल के "रिश्तों" को समझने के लिए, हमें उनकी संरचना में गहराई से उतरना होगा, जिसका अर्थ है कि हमें कम से कम आंशिक रूप से उन्हें उल्टा करना चाहिए (मूल एल्गोरिदम को पुनर्स्थापित करना चाहिए)।

जैसा कि पहले ही ऊपर उल्लेख किया गया है, पीई + प्रारूप निष्पादन योग्य मॉड्यूल लोडर के लिए संरचनाओं का एक सेट है, स्मृति में निर्माण जिस पर नियंत्रण स्थानांतरित किया जाएगा, और इसकी प्रकृति द्वारा इस ऑब्जेक्ट में प्रोसेसर निर्देश, साथ ही इन निर्देशों के लिए डेटा भी शामिल है।

हम कहेंगे कि निष्पादन योग्य मॉड्यूल की एक पूर्ण गड़बड़ी बनाई गई थी यदि इस मॉड्यूल में प्रस्तुत कमांड और डेटा को अलग करने की समस्या को हल करना संभव था।

उसी समय, हम संरचना और डेटा प्रकारों पर कोई आवश्यकता नहीं लगाएंगे, यह पर्याप्त है यदि लोडर द्वारा प्राप्त निष्पादन योग्य मॉड्यूल की छवि से संबंधित प्रत्येक बाइट के लिए, हम स्पष्ट रूप से कह सकते हैं कि यह दो श्रेणियों में से किसके लिए है: कमांड बाइट या डेटा बाइट।

निष्पादन योग्य मॉड्यूल को पूरी तरह से अलग करने का कार्य आम तौर पर सामान्य रूप में तुच्छ नहीं है, इसके अलावा, यह एल्गोरिथ्म में नहीं है। हम इस मुद्दे के विवरण में नहीं जाएंगे, भाले को भी तोड़ देंगे, हम इस कथन को स्वयंसिद्ध मानते हैं।

मान लें:

1. हमने पहले से ही एक विशिष्ट BIOS / UEFI निष्पादन मॉड्यूल, यानी हम कमांड और डेटा को अलग करने में कामयाब रहे।
2. "सी" भाषा में मॉड्यूल के लिए स्रोत कोड है (वर्तमान BIOS / UEFI फर्मवेयर में, मॉड्यूल ज्यादातर "सी" भाषा में ही विकसित किए जाते हैं)।

इस मामले में भी, केवल प्राप्त परिणामों की तुलना करना ("सी" भाषा में स्रोत कोड के साथ कोडांतरक पाठ सिर्फ प्रोसेसर निर्देशों का एक शाब्दिक प्रतिनिधित्व है) बिल्कुल पतित मामलों को छोड़कर लगभग हमेशा एक अच्छे अनुभव / योग्यता की आवश्यकता होगी।

स्रोत कोड के साथ disassembly परिणामों की पहचान करने या तुलना करने में कठिनाइयों को दिखाने वाले उदाहरणों का एक पूरा अध्ययन हमारी वर्तमान योजनाओं का हिस्सा नहीं है।
एक उदाहरण पर विचार करें जब कोडांतरक सूची में हम "अप्रत्यक्ष कॉल" कमांड का सामना करते हैं - एक अंतर्निहित प्रक्रिया कॉल।

यह एक तालिका में संदर्भित प्रक्रिया कॉल का एक उदाहरण है। विभिन्न प्रक्रियाओं के लिंक वाली एक तालिका एक मनमाना प्रोटोकॉल के इंटरफेस की प्रस्तुति को लागू करने का एक विशिष्ट मामला है।

ऐसी तालिका में केवल प्रक्रियाओं के संदर्भों को समाहित करने की आवश्यकता नहीं होती है; इस संरचना में मनमाना डेटा संग्रहीत करने वाली कोई भी मनाही नहीं है (और यह एक विशिष्ट "C" संरचना का उदाहरण है)।

इस तरह की एक कॉल का एक रूप है (इकोक्स रजिस्टर के बजाय, 32-बिट प्रोसेसर रजिस्टरों के लगभग सभी वेरिएंट संभव हैं):

FF 51 18 कॉल ड्राफ्ट ptr [ecx + 18h]

प्राप्त होने के बाद, विश्लेषण पर, एक समान कमांड, यह पता लगाना संभव है कि किस तरह की प्रक्रिया को बुलाया जा रहा है, इसके मापदंडों की एक सूची, लौटे परिणाम का प्रकार और मूल्य, केवल तभी संभव है जब हम ऑब्जेक्ट (प्रोटोकॉल) के प्रकार को जानते हैं जिसका इंटरफ़ेस इस कमांड के लिए कहा जाता है।

यदि हम जानते हैं कि पिछले उदाहरण में "ecx" रजिस्टर में एक पॉइंटर (EFI_PEI_SERVICES तालिका की शुरुआत का पता) है, तो हम इस आदेश को निम्नलिखित और अधिक समझने योग्य और "सुखद" तरीके से प्राप्त कर सकते हैं:

FF 51 18 कॉल [exx + EFI_PEI_SERVICES.InstallPpi]

"इनडायरेक्ट कॉल" कमांड में भाग लेने वाले रजिस्टर की सामग्री के बारे में जानकारी प्राप्त करना अक्सर एक "विशिष्ट" डिस्सेम्बलर की क्षमताओं से परे हो जाता है, जिसका कार्य केवल प्रोसेसर के द्विआधारी कोड का मानव-पठनीय रूप में विश्लेषण और परिवर्तित करना है - संबंधित प्रोसेसर कमांड का एक शाब्दिक प्रतिनिधित्व।

इस समस्या को हल करने के लिए, अक्सर अतिरिक्त (मेटा) जानकारी का उपयोग करने की आवश्यकता होती है जो बाइनरी निष्पादन योग्य मॉड्यूल में उपलब्ध नहीं होती है (संकलन और लिंकिंग के परिणामस्वरूप खो जाती है - इसका उपयोग एल्गोरिदम के एक प्रतिनिधित्व से दूसरे में परिवर्तनों में किया जाता है, लेकिन प्रोसेसर को अब प्राप्त कमांड निष्पादित करने की आवश्यकता नहीं है)।

यदि यह मेटाडेटा अभी भी अतिरिक्त स्रोतों से हमारे लिए उपलब्ध है, तो उनका उपयोग करने और अतिरिक्त विश्लेषण करने के बाद, हमें "इनडायरेक्ट कॉल" कमांड का और अधिक समझने योग्य (और अधिक सटीक) प्रतिनिधित्व मिलता है।

वास्तव में, यह उन्नत विश्लेषण पहले से ही "अपघटन" प्रक्रिया की याद दिलाता है, हालांकि परिणाम "सी" भाषा में मॉड्यूल के स्रोत कोड की तरह नहीं दिखता है, फिर भी, भविष्य में हम इस प्रक्रिया को "अप्रत्यक्ष कॉल" या " आदेश " के अपघटन के रूप में संदर्भित करेंगे। आंशिक "विघटन ।

तो, हम दिए गए BIOS / UEFI चरण के लिए निष्पादन योग्य फर्मवेयर मॉड्यूल की अन्योन्याश्रयता के ग्राफ के निर्माण के लिए पर्याप्त परिस्थितियों को निर्धारित करने के लिए तैयार हैं:

स्टेटिक डिपेंडेंसी ग्राफ (किसी भी चरण - PEI या DXE) को प्राप्त करने के लिए, यह संबंधित चरण के सभी निष्पादन योग्य मॉड्यूलों को पूरी तरह से अलग करने के लिए पर्याप्त है (कम से कम सभी कमांडों को अलग करें), और असंतुष्ट मॉड्यूल में मौजूद "अप्रत्यक्ष कॉल" कमांड को डिकंपाइल करें।

"इनडायरेक्ट कॉल" टीमों का हमारा ज्ञान इंटर-मॉड्यूल इंटरैक्शन के साथ कैसे जुड़ा है, इस बारे में तुरंत कई सवाल हैं।
जैसा कि ऊपर उल्लेख किया गया है, संपूर्ण इंटरैक्शन प्रबंधन सेवा संबंधित चरण के "कोर" मॉड्यूल द्वारा प्रदान की गई है, और चरणों में सेवाओं को "मूल" सेवा तालिकाओं के रूप में डिज़ाइन किया गया है।

चूंकि पीईआई और डीएक्सई चरणों में मॉड्यूल के बीच बातचीत के मॉडल, हालांकि वैचारिक (संरचनात्मक रूप से) समान हैं, तकनीकी रूप से अभी भी अलग हैं, पीईआई चरण के लिए स्टेटिक डिपेंडेंसी ग्राफ के एक विशिष्ट प्रत्यक्ष निर्माण पर विचार करने के लिए कुछ औपचारिक विचारों से आगे बढ़ना प्रस्तावित है।

हम यहां तक ​​कि पीई चरण के लिए स्टेटिक डिपेंडेंसी ग्राफ के निर्माण की संभावना के लिए आवश्यक और पर्याप्त शर्तों को निर्धारित और तैयार करने में सक्षम होंगे।

पीईआई चरण के लिए एक स्टेटिक डिपेंडेंसी ग्राफ का निर्माण

पीईआई चरण के निष्पादन योग्य मॉड्यूल के पूर्ण विघटन और इन मॉड्यूल में मौजूद अप्रत्यक्ष कॉल आदेशों के अपघटन की समस्या के समाधान का वर्णन हमारे कथन के दायरे से बाहर है और इसमें नहीं दिया जाएगा - मात्रा में इस सामग्री की प्रस्तुति इस ओपस के आकार से अधिक हो सकती है।

यह संभव है कि समय के साथ यह एक अलग सामग्री के रूप में होगा, लेकिन अभी के लिए - पता है कि कैसे।

हम केवल ध्यान देते हैं कि मेटाडेटा का उपयोग, साथ ही द्विआधारी कोड के निर्माण के लिए एक निश्चित संरचना की उपस्थिति, निष्पादन योग्य BIOS / UEFI मॉड्यूल को पूरी तरह से अलग करना संभव बनाता है। इस तथ्य का औपचारिक प्रमाण अभी या भविष्य में नहीं माना गया है। कम से कम विभिन्न निर्माताओं से सौ (100) बीआईओएस / यूईएफआई के विश्लेषण / प्रसंस्करण में, ऐसे कोई उदाहरण नहीं थे, जहां पूर्ण विघटन संभव नहीं था ।

इसके अलावा, केवल विशिष्ट परिणाम (स्पष्टीकरण के साथ: क्या, कैसे और कितना ...)।

EFI_PEI_SERVICES संरचना PEI चरण की मूल संरचना है, जिसे प्रत्येक PEI मॉड्यूल के प्रवेश बिंदु के लिए एक पैरामीटर के रूप में पारित किया जाता है और इसमें PEI मॉड्यूल के कार्य करने के लिए आवश्यक बुनियादी सेवाओं के लिंक होते हैं।

हम संरचना के बहुत शुरुआत में स्थित क्षेत्रों में ही रुचि लेंगे:



आईडीए प्रो डिस्सेम्बलर में टाइप EFI_PEI_SERVICES की वास्तविक संरचना का एक टुकड़ा।

और यह "सी" भाषा में स्रोत कोड में कैसे दिखाई देता है (याद रखें, यह केवल संरचना का एक टुकड़ा है):

 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" से यह निर्धारित किया जा सकता है कि संरचना की कुल लंबाई 78h है (और यह हेडर की लंबाई नहीं है, जैसा कि नाम से पता चलता है, लेकिन EFI_PEY_SERVICES के पूरे ढांचे की लंबाई)।

इंटरफेस EFI_PEI_SERVICES को 7 श्रेणियों / वर्गों में विभाजित किया गया है। हम उन्हें सूचीबद्ध करते हैं:

1. पीपीआई सेवाएँ।
2. बूट मोड सेवाएँ।
3. HOB सेवाएँ।
4. फर्मवेयर वॉल्यूम सेवाएँ।
5. पीईआई मेमोरी सर्विसेज।
6. स्थिति कोड सेवाएँ।
7. सेवाएँ रीसेट करें।

सभी आगे का कथन सीधे पीपीआई सेवा श्रेणी / वर्ग से संबंधित प्रक्रियाओं से संबंधित होगा, जिसका उद्देश्य पीईआई-चरण निष्पादन योग्य मॉड्यूल के अंतर-मॉड्यूल इंटरैक्शन के संगठन के लिए है।

और पीईआई चरण के लिए केवल चार हैं।

सामान्य तौर पर, प्रत्येक इंटरफेस के उद्देश्य का अनुमान लगाने की आवश्यकता नहीं है: कार्यक्षमता पूरी तरह से इंटरफ़ेस के नाम से निर्धारित होती है, सभी विवरण विनिर्देश में हैं ।

इन प्रक्रियाओं के प्रोटोटाइप निम्नलिखित हैं:

 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); 

हम केवल ध्यान दें कि "इनडायरेक्ट कॉल" कमांड के अलावा, "पीपीआई सर्विसेज" क्लास की प्रक्रियाओं / इंटरफेस को इनवाइट करते हैं, इन प्रक्रियाओं के लिए एक स्पष्ट (डायरेक्ट - टेबुलर) कॉल संभव नहीं है, जो कभी-कभी कार्यकारी मॉड्यूल में होता है, जहां EFI_PEI_SERVICES स्ट्रक्चर परिभाषित / निर्मित होता है।

मैं आपको एक छोटा सा रहस्य बताता हूं: विचित्र रूप से पर्याप्त है, हालांकि यह पीईआई चरण के लिए सेवाओं की "बुनियादी" तालिका है, हालांकि, जैसा कि अभ्यास से पता चलता है, इसे न केवल 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] 

प्रमाणीकरण से पहले और बाद में अंतर्निहित इंटरफ़ेस कॉल के उदाहरण।

हम एक विशेषता पर ध्यान देते हैं: IA-32 वास्तुकला के लिए PEI चरण के मामले में, PPI सेवा वर्ग के इंटरफेस में 18h, 1Ch, 20h, और 24h के ऑफसेट हैं।

और अब हम निम्नलिखित बयान देते हैं:

पीईआई चरण के एक स्टेटिक डिपेंडेंसी ग्राफ का निर्माण करने के लिए, चरण के सभी निष्पादन योग्य मॉड्यूल (कम से कम अलग-अलग सभी कमांड) को पूरी तरह से अलग करना और ऑफ़सेट्स 18h, 1Ch, 20h, 24h के साथ "इनडायरेक्ट कॉल" आदेश को विघटित करने के लिए पर्याप्त है।

वास्तव में, हमने समस्या को हल करने के लिए पूरी तरह से एक एल्गोरिथ्म तैयार किया है, और जैसे ही हम पीपीआई सेवा वर्ग के इंटरफेस / प्रक्रियाओं को सभी कॉलों को अलग करने में कामयाब रहे, यह केवल यह निर्धारित करने के लिए रहता है कि इन कॉलों के लिए कौन से पैरामीटर पारित किए गए हैं। कार्य सबसे तुच्छ नहीं हो सकता है, लेकिन, जैसा कि अभ्यास ने दिखाया है, यह पूरी तरह से हल है, हमारे पास इसके लिए सभी डेटा हैं।

और अब वास्तविक पीईआई-चरण मॉड्यूल के लिए वास्तविक डेटा के वास्तविक उदाहरण हैं। हम जानबूझकर यह संकेत नहीं देते हैं कि किस कंपनी के BIOS / UEFI परिणाम प्राप्त किए गए, बस उदाहरण दें कि वे कैसे दिखते हैं।

इन मॉड्यूलों में PPI Services इंटरफेस का उपयोग करने पर पूरी जानकारी के साथ PEIM मॉड्यूल विवरण के दो उदाहरण

  -- 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 

प्रोटोकॉल के प्रकारों की सूची जिसमें वे उपयोग किए गए थे

स्पॉइलर के नीचे पीपीआई सेवा वर्ग के प्रत्येक इंटरफेस के लिए पीपीआईएम प्रोटोकॉल की सूचियों के संक्षिप्त उदाहरण हैं।

सूचियों का प्रारूप इस प्रकार है:

 |  क्रम संख्या |  name_PPI |  guide_PPI |  निष्पादन योग्य_नाम: उपयोगकर्ता नाम |

प्रोटोकॉल के सभी गाइडों की अंतिम सूची जो एक विशेष BIOS / यूईएफआई में संदर्भित हैं, जिसमें एक किंवदंती है जिसमें "पीपीआई सेवाएं" इन प्रोटोकॉल पाए जाते हैं।

नीचे 97 PPi-guids की स्पॉइलर सूची मिली है और एक विशिष्ट फर्मवेयर में स्पष्ट रूप से उपयोग किया गया है, जिसके लिए डेटा पहले दिया गया था।

सूची से प्रत्येक आइटम एक पौराणिक कथा से पहले है, जो किसी विशेष प्रोटोकॉल के सभी प्रकार के उपयोग को दर्शाता है।

 "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 मॉड्यूल के लिए "स्टेटिक डिपेंडेंसी ग्राफ प्राप्त करना" कार्य का सही समाधान द्विआधारी कोड के स्थैतिक विश्लेषण की आवश्यकता है, जिसमें निष्पादन योग्य मॉड्यूल का पूर्ण विघटन और इन मॉड्यूल के अप्रत्यक्ष कॉल आदेशों का आंशिक विघटन शामिल है ।