UEFI BIOS फ़ाइल डिवाइस, भाग दो: UEFI फर्मवेयर वॉल्यूम और इसकी सामग्री

इस लेख के पहले से ही डेढ़ ( पहले , डेढ़ ) भागों के पीछे, अब अंत में UEFI फर्मवेयर वॉल्यूम और UEFI फ़ाइल सिस्टम प्रारूप की संरचना के बारे में बात करने का समय है।

परिचय

मुझे तुरंत कहना होगा कि लेख के इस भाग में मैं संस्करण 2 के फ़ाइल स्वरूपों का वर्णन करूंगा, क्योंकि वे सभी मौजूदा BIOS में उपयोग किए जाते हैं। पीआई मानक के नवीनतम संस्करणों में, संस्करण 3 के स्वरूपों का विवरण जोड़ा गया है, लेकिन उन्हें 16 एमबी से बड़ी फ़ाइलों के लिए आवश्यक है, जो अभी तक किसी भी बोर्ड पर नहीं हैं, हालांकि गीगाबाइट पहले ही इसके Z87 बोर्डों पर इस बिंदु के करीब आ चुका है। सभी आधुनिक इंटेल मदरबोर्ड पर डिस्क्रिप्टर क्षेत्र 16 एमबी से अधिक की क्षमता के साथ 2 से अधिक चिप्स का समर्थन नहीं करता है, इसलिए अगली पीढ़ी के इंटेल चिपसेट में कम से कम होने तक संस्करण 3 प्रारूपों के उपयोग में देरी हो रही है।

एक उदाहरण के रूप में, Zotac Z77-ITX वाईफाई के लिए फ़ाइल संस्करण 229 से BIOS क्षेत्र लें।
हमें निम्नलिखित कार्यक्रमों की आवश्यकता होगी:

• अपने स्वाद के लिए हेक्स संपादक, मैं एचएक्सडी का उपयोग करूंगा
• उपयोगिता फीनिक्सटूल v2.xx, जिसे एमडीएल फोरम पर विषय से डाउनलोड किया जा सकता है

फर्मवेयर की मात्रा

फर्मवेयर वॉल्यूम संरचना और पीआई एफएफएस प्रारूप को यूईएफआई प्लेटफ़ॉर्म प्रिसिज़नटन प्रलेखन के वॉल्यूम 3 में वर्णित किया गया है।
फर्मवेयर वॉल्यूम फ्लैश सामग्री का एक तार्किक प्रतिनिधित्व है जिसमें निम्नलिखित विशेषताएं हैं:

1. नाम: FV और उसके सभी भागों का नाम उनके GUID है
2. आकार: सभी डेटा, हेडर और मुक्त स्थान शामिल हैं
3. स्वरूप: फ़ाइल सिस्टम प्रकार FV के अंदर, विभिन्न प्रकार के अलग GUID हैं
4. गठबंधन: FV के पहले बाइट को निर्दिष्ट सीमा पर संरेखित करने की आवश्यकता होती है, कई डिग्री 2। एफवी का संरेखण इसके अंदर सभी फाइलों के संरेखण से कमजोर नहीं होना चाहिए, जब तक कि EFI_FVB_WEAK_ALIGNMENT में EFI_FVB_WEAK_ALIGNMENT फ्लैग सेट न हो। इस मामले में, संरेखण 2 की किसी भी शक्ति के लिए किया जा सकता है, लेकिन इस FV को अब स्थानांतरित नहीं किया जा सकता है
5. पढ़ने, लिखने की सुरक्षा, स्व-अक्षम पढ़ने या लिखने की सुरक्षा के लिए विशेषताएँ
6. OEM विवेकाधीन विकल्प

FV के अंदर उपयोग किए जाने वाले फ़ाइल सिस्टम के बावजूद, FV हेडर को मानकीकृत किया जाता है और यह इस तरह दिखता है:

 typedef struct { UINT8 ZeroVector[16]; UINT8 FileSystemGuid[16]; UINT64 FvLength; UINT32 Signature; UINT32 Attributes; UINT16 HeaderLength; UINT16 Checksum; UINT16 ExtHeaderOffset; UINT8 Reserved[1]; UINT8 Revision; EFI_FV_BLOCK_MAP BlockMap[]; } EFI_FIRMWARE_VOLUME_HEADER; typedef struct { UINT32 NumBlocks; UINT32 Length; } EFI_FV_BLOCK_MAP 

ज़ीरोवेक्टर : एफवी की शुरुआत में, 16 बाइट्स प्रोसेसर के साथ संगतता के लिए आरक्षित होते हैं, जिसका रीसेट वेक्टर शून्य पते पर स्थित होता है। इस ब्लॉक में शून्य के अलावा कुछ और की उपस्थिति से, बूट फ़र्मवेयर वॉल्यूम को बाकियों से अलग पहचाना जा सकता है।
FileSystemGuid : इस FV के अंदर प्रयुक्त फाइल सिस्टम को परिभाषित करता है।
FvLength : सभी हेडर के लिए FV आकार।
हस्ताक्षर : एफवी की खोज करने के लिए उपयोग किया जाता है और मानक हमेशा 0x4856465F होता है, अर्थात {'_','F','V','H'} ।
विशेषताएँ : वही विशेषताएँ जिनके बारे में हमने ऊपर बात की थी। उनमें से बहुत सारे हैं, लेकिन हमारे लिए सबसे महत्वपूर्ण EFI_FVB_WEAK_ALIGNMENT , जो FV को नॉन- EFI_FVB_WEAK_ALIGNMENT बनाता है, यदि यह स्थापित किया गया है, तो EFI_FVB_ALIGNMENT से EFI_FVB_ALIGNMENT_1 से EFI_FVB_ALIGNMENT_1 से एक सेट करें शेष को कोड के लिए आवश्यक है जो FV के साथ मेमोरी क्षेत्र के रूप में काम करता है, और यह हमारे लिए बेकार है, इसलिए हम उन्हें सूचीबद्ध नहीं करेंगे।
शीर्षलेख : विस्तारित हेडर को छोड़कर हेडर का आकार, जिसके बारे में नीचे।
चेकसम : 16-बिट हेडर चेकसम। सही शीर्ष लेख को 0x0000 तक जोड़ना चाहिए।
ExtHeaderOffset : विस्तारित हैडर की शुरुआत की भरपाई। इसमें वर्णित FV का GUID, उनके GUID के साथ OEM फ़ाइल प्रकारों की एक सूची और एक इलेक्ट्रॉनिक हस्ताक्षर भी हो सकता है। फिलहाल, मैंने एक भरे हुए हेडर के साथ एक भी एफवी नहीं देखा है, इसलिए हम इस पर विचार नहीं करेंगे। यदि FV में अतिरिक्त हेडर नहीं है, तो 0x0000 इस क्षेत्र में है।
आरक्षित : आरक्षित क्षेत्र, हमेशा 0x00।
संशोधन : पीआई मानक केवल एक संशोधन की संरचना का वर्णन करता है - दूसरा, इसलिए यह फ़ील्ड हमेशा 0x02 है।
BlockMap : दोनों क्षेत्रों में शून्य के साथ एक ही संरचना में समाप्त होने वाली EFI_FV_BLOCK_MAP संरचनाओं की सूची के रूप में संग्रहीत ब्लॉक मैप। क्योंकि चूँकि सभी आधुनिक फ़्लैश माइक्रोकाइक्रेट्स सजातीय हैं (अर्थात, उनके पास समान आकार के ब्लॉक हैं), पूरी सूची में आमतौर पर केवल दो प्रविष्टियाँ होती हैं।

आइए उपरोक्त के अनुपालन के लिए हमारे उदाहरण की जांच करें।
हेक्स संपादक में हमारी BIOS फ़ाइल खोलें और BIOS क्षेत्र की शुरुआत में, 0x500000 को ऑफसेट करने के लिए जाएं।

हम देखते हैं कि शुरुआत में 16 शून्य हैं, एक फ़ाइल सिस्टम GUID है, इस FV का आकार 0x020000 है, हस्ताक्षर जगह में है, विशेषताएँ सेट हैं, हेडर 0x48 बाइट्स आकार में है, चेकसम की गणना की गई है, कोई विस्तारित हैडर नहीं है, आरक्षित फ़ील्ड जगह में हैं, और इसके अंदर हैं FV में प्रत्येक 0x1000 के 20 ब्लॉक हैं, जो कुल मिलाकर FvLength क्षेत्र में संकेतित आकार को वास्तव में देता है।
सबसे अधिक बार, BIOS में कई अलग-अलग FVs अलग-अलग उद्देश्यों के लिए डिज़ाइन किए गए हैं, हालांकि यह आवश्यक नहीं है और आप इसे एक में पैक कर सकते हैं। UEFI BIOS के सभी निर्माताओं के बीच एक दूसरे में FV और फ़ाइलों के घोंसले के शिकार की डिग्री में Intel है, जहां 12 स्तर तक का घोंसला पाया जाता है।
यद्यपि सैद्धांतिक रूप से अलग फाइल सिस्टम का उपयोग एफवी के लिए किया जा सकता है, व्यवहार में केवल एक का उपयोग किया जाता है - पीआई एफएफएस, जिसके बारे में हम अभी बात करेंगे।

फर्मवेयर फाइल सिस्टम

यह निर्देशिका और पदानुक्रम के बिना एक फ्लैट फ़ाइल सिस्टम है, जिनकी सभी फाइलें घोड़े की निर्देशिका में हैं। फ़ाइलों की एक सूची प्राप्त करना शुरू से अंत तक एफएस से गुजरना आवश्यक है। सभी फाइलों में एक मानक-परिभाषित हेडर होना चाहिए। फाइल को सिस्टम की शुरुआत के सापेक्ष आठ-बाइट सीमा पर संरेखित किया जाना चाहिए, बड़ी सीमाओं पर संरेखण के लिए एक विशेष फ़ाइल-प्लेसहोल्डर प्रदान किया जाता है।
मानक एक विशेष वीटीएफ फ़ाइल का भी वर्णन करता है, जो प्रत्येक एफवी के अंत में मौजूद होना चाहिए, लेकिन व्यवहार में यह केवल BIOS छवि में अंतिम एफवी के अंत में मौजूद है और यह स्थित है ताकि इसकी आखिरी बाइट भी पूरी चिप में अंतिम हो। इसमें SEC चरण के लिए आवश्यक बूटस्ट्रैप कोड होता है।

फ़ाइल हेडर

FFS फ़ाइल हेडर निम्नानुसार आयोजित किया जाता है:

 typedef struct { UINT8 Name[16]; UINT8 HeaderChecksum; UINT8 DataChecksum; UINT8 Type; UINT8 Attributes; UINT8 Size[3]; UINT8 State; } EFI_FFS_FILE_HEADER; 

नाम : नाम के रूप में कार्य करने वाली फ़ाइल का GUID। एक FV में एक ही GUID के साथ दो फाइलें नहीं हो सकती हैं, अगर ये PAD फाइलें नहीं हैं, जो नीचे वर्णित हैं।
हेडरचेकसम : डेटाचेकसम फील्ड को छोड़कर आठ-बिट हेडर चेकसम। सही हेडर को 0x00 तक जोड़ना चाहिए।
DataChecksum : हेडर को छोड़कर, फ़ाइल की सामग्री का आठ-बिट चेकसम। यह हमेशा गणना करने के लिए आवश्यक नहीं है, लेकिन केवल अगर FFS_ATTRIB_CHECKSUM विशेषता FFS_ATTRIB_CHECKSUM , अन्यथा यह फ़ील्ड FFS_ATTRIB_CHECKSUM पर सेट है।
प्रकार : फ़ाइल प्रकार। मानक 13 मानक फ़ाइल प्रकारों को परिभाषित करता है (0x01 - 0x0D), OEM फ़ाइलों के लिए 32 उपयोगकर्ता प्रकार (0xC0 - 0xDF), डिबगिंग के लिए 16 उपयोगकर्ता प्रकार (0xE0 - 0xEF) और 16 प्रकार FFS के वर्तमान संस्करण के लिए विशिष्ट (0xF0 - 0xFF) वर्तमान में केवल 0xF0 का उपयोग किया जाता है - प्लेसहोल्डर फ़ाइल के लिए EFI_FV_FILETYPE_FFS_PAD ।
इस विशेष फ़ाइल में कोई भी हो सकता है, जिसमें null GUID, null विशेषताएँ, मानक स्थिति और कोई भी आकार शामिल है। मानक के अनुसार, फ़ाइल खाली होनी चाहिए, अर्थात हेडर बिट्स को छोड़कर इसके सभी बिट्स को EFI_FVB_ERASE_POLARITY सेट किया जाना चाहिए। इसका उपयोग मानक 8 बाइट्स से अधिक सीमा के साथ फ़ाइल को संरेखित करने के लिए किया जाता है। PAD फ़ाइल का न्यूनतम आकार हेडर के आकार के बराबर है - 24 बाइट्स।
हम मानक फ़ाइल प्रकारों पर लौटेंगे।
विशेषताएँ : हमारे लिए महत्वपूर्ण विशेषताएँ FFS_ATTRIB_FIXED , यह दर्शाता है कि फ़ाइल को FV के अंदर नहीं FFS_ATTRIB_FIXED जा सकता है, और FFS_ATTRIB_DATA_ALIGNMENT का एक सेट, यह दर्शाता है कि फ़ाइल का डेटा (हेडर नहीं) किसी सीमा पर संरेखित है।
आकार : हेडर के साथ फाइल का आकार, 24-बिट UINT के रूप में संग्रहीत।
राज्य : फ़ाइल स्थिति। इस फ़ील्ड का उपयोग FV को मेमोरी में लोड करने और FV के अंदर फाइलों के साथ संचालन के दौरान किया जाता है। BIOS छवि के अंदर सभी मान्य फ़ाइलों की स्थिति 0xF8 है।

अब फ़ाइल प्रकारों पर वापस जाएं। उन लोगों के लिए जिन्होंने अभी तक इस लेख के डेढ़ भाग को नहीं पढ़ा है, मैं जाने और पढ़ने की सलाह देता हूं, अन्यथा आप कुछ भी नहीं समझने का जोखिम उठाते हैं।
जैसा कि हम पहले से ही जानते हैं, 13 मानक फ़ाइल प्रकार परिभाषित हैं, यहाँ वे हैं:

नाम	टाइप	विवरण
रॉ	0x01	ऐसी फ़ाइल की संरचना पूरी तरह से इसके उपयोगकर्ता द्वारा निर्धारित की जाती है, और इसके बारे में पहले से कुछ भी ज्ञात नहीं है
freeform	0x02	इस तरह की फ़ाइल में एक अनुभागीय संरचना होती है, लेकिन कुछ भी पहले से अनुभागों की सामग्री के बारे में नहीं पता है।
SECURITY_CORE	0x03	SEC चरण में सुरक्षा कर्नेल निष्पादन कोड
PEI_CORE	0x04	PEI कोर, उर्फ ​​PEI फाउंडेशन
DXE_CORE	0x05	डीएक्सई, उर्फ ​​डीएक्सई फाउंडेशन का मूल
PEIM	0x06	PEI मॉड्यूल
ड्राइवर	0x07	DXE ड्राइवर
COMBINED_PEIM_DRIVER	0x08	हाइब्रिड PEI / DXE मॉड्यूल
आवेदन	0x09	आवेदन। यह डीएक्सई चालक से अलग है कि यह डीएक्सई प्रबंधक नहीं है जो इसे लॉन्च करता है, लेकिन उपयोगकर्ता। एप्लिकेशन यूईएफआई सेटअप, यूईएफआई शेल, BIOS अपडेट आदि हैं।
एस एम एम	0x0A	SMM मॉड्यूल
FIRMWARE_VOLUME_IMAGE	0x0B	छवि FV। यह एक विशेष फ़ाइल है जो आपको एक FV को दूसरे में एम्बेड करने की अनुमति देती है
COMBINED_SMM_DXE	0x0C	एसएमएम / डीएक्सई हाइब्रिड मॉड्यूल
SMM_CORE	0x0D	कर्नेल एसएमएम, उर्फ ​​एसएमएम इनिट

हमारी फ़ाइल पर उपरोक्त जांचें:

एफवी हेडर के पहले 0x48 बाइट्स हमें अब और रुचि नहीं देते हैं, लेकिन जो तुरंत उनका अनुसरण करता है वह हमें रुचता है। यह देखा जा सकता है कि GUID CEF5B9A3-476D-497D-497F-EF14143E0422C, हैडर चेकसम 0x36, डेटा चेकसम 0xAA के साथ एक फाइल है, जो हटाए गए विशेषता FFS_ATTRIB_CHECKSUM , प्रकार RAW (0x01) के बिना, बिना किसी विशेषता के इंगित करता है। । सत्य जैसा लगता है।

अब वर्गों के बारे में। RAW को छोड़कर सभी FFS फ़ाइलों को फ़ाइल डेटा क्षेत्र की शुरुआत से 4 बाइट्स की सीमा पर संरेखित वर्गों में विभाजित किया जाना चाहिए। संख्या और प्रकार के अनुभागों के लिए प्रत्येक प्रकार की फ़ाइल की अपनी आवश्यकताएं होती हैं, लेकिन इस लेख में आवश्यकताओं की कोई सूची नहीं होगी - यह बहुत लंबा है और बहुत उबाऊ है। लेकिन अनुभाग शीर्षक, उनका उद्देश्य और प्रकार, अब हम विचार करते हैं।

अनुभाग शीर्ष लेख

न्यूनतम खंड शीर्षलेख इस तरह दिखता है:

 typedef struct { UINT8 Size[3]; UINT8 Type; } EFI_COMMON_SECTION_HEADER; 

आकार : फ़ाइल शीर्षलेख के समान स्वरूप में अनुभाग आकार।
प्रकार : अनुभाग का प्रकार।
अनुभागों को दो उपवर्गों में विभाजित किया जाता है - इनकैप्सुलेशन और लीफ। पूर्व में अन्य प्रकार के अनुभाग शामिल हो सकते हैं, जबकि बाद में सीधे डेटा होते हैं। कुछ प्रकार के अनुभागों ने हेडर बढ़ाया है, लेकिन शुरुआत हमेशा सामान्य से मेल खाती है।
इनकैप्सुलेशन अनुभागों के लिए 3 प्रकार की सामग्री परिभाषित की गई है:
0x01 - EFI_SECTION_COMPRESSION , इंगित करता है कि अनुभाग कुछ एल्गोरिथ्म के अनुसार संकुचित है।
पूर्ण शीर्षक EFI_COMPRESSION_SECTION (शीर्षक में शब्द मिश्रित नहीं हैं, यह ऐसा है):

 typedef struct { UINT8 Size[3]; UINT8 Type; UINT32 UncompressedSize; UINT8 CompressionType; } EFI_COMPRESSION_SECTION; 

असम्पीडित आकार: विघटित डेटा का आकार।
CompressionType : लागू संपीड़न एल्गोरिथम।
फिलहाल 2 कम्प्रेशन एल्गोरिदम हैं- टियानो (0x01) और LZMA (0x02)। यदि अनुभाग संरचना को बदलने के बिना अनपैक किया गया था, तो 0x00 को संपीड़न प्रकार के रूप में सेट किया गया है, और अनुभाग आकार पैक किए गए डेटा के आकार के साथ मेल खाता है। टियानो एल्गोरिथ्म LZ77 और इंटेल द्वारा हफमैन कोड का एक संयोजन है, संपीड़न और विघटन कोड BSDL के तहत TianoCore प्रोजेक्ट फाइलों से लिया जा सकता है। LZMA एल्गोरिथ्म बहुत अच्छी तरह से इसके बारे में फिर से बात करने के लिए जाना जाता है, संपीड़न और विघटन कोड LZMA SDK में है।

चलो एनकैप्सुलेशन अनुभागों के प्रकारों के बारे में जारी रखते हैं:
0x02 - EFI_SECTION_GUID_DEFINED , इंगित करता है कि अनुभाग की सामग्री को उसमें दर्ज GUID के अनुसार फ़ाइल के उपयोगकर्ता द्वारा देखा जाना चाहिए। यह ऐसे अनुभाग में है जिसमें विभिन्न ओईएम डेटा संग्रहीत किए जा सकते हैं, साथ ही साथ अनुभाग या संपूर्ण फ़ाइल का इलेक्ट्रॉनिक हस्ताक्षर भी किया जा सकता है।
0x03 - EFI_SECTION_DISPOSABLE , एक अनुभाग को इंगित करता है जिसमें डेटा फ़ाइल के संचालन के लिए महत्वपूर्ण नहीं है और अंतरिक्ष को बचाने के लिए reassembly के दौरान हटाया जा सकता है। वास्तविक फ़ाइलों में, BIOS नहीं मिला है।
पत्ती वर्गों के लिए, 12 सामग्री प्रकार परिभाषित किए गए हैं:

नाम	टाइप	विवरण
PE32	0x10	अपने सभी हेडर के साथ PE32 + प्रारूप में 64-बिट निष्पादन योग्य कोड। यूईएफआई में निष्पादन योग्य कोड के लिए मुख्य प्रारूप।
पीआईसी	0x11	64-बिट स्थिति-स्वतंत्र निष्पादन योग्य कोड। इसका उपयोग केवल कुछ PEI मॉड्यूल द्वारा किया जाता है, प्रारूप PE32 + के समान होता है, केवल स्थानांतरण जानकारी को काट दिया जाता है।
TE	0x12	64-बिट निष्पादन योग्य कोड का उपयोग मॉड्यूल और PEI कोर द्वारा किया जाता है। यह एक शीर्ष लेख द्वारा PE32 + से भिन्न होता है, जो प्रोसेसर कैश में स्थान बचाने के लिए कम हो जाता है। इस लेख के डेढ़ भाग में इसका वर्णन पढ़ें।
DXE_DEPEX	0x13	एक खंड जिसमें डीएक्सई चालक की निर्भरता है, जिसमें यह स्थित है। इस खंड का प्रारूप खंड 2 में वर्णित है
संस्करण	0x14	फ़ाइल के संस्करण में शामिल है और वैकल्पिक रूप से पूर्ण संस्करण के साथ एक यूनिकोड स्ट्रिंग है। यह काफी दुर्लभ है।
USER_INTERFACE	0x15	फ़ाइल नाम के साथ एक यूनिकोड-शब्द समाहित करता है। इस अनुभाग की सामग्री द्वारा फ़ाइलों की खोज करना बहुत सुविधाजनक है। इसका उपयोग अक्सर किया जाता है, लेकिन ऐसे अनुभाग के साथ एक फ़ाइल के बिना भी BIOS पाए जाते हैं।
COMPATIBILITY16	0x16	पुराने सिस्टम के साथ संगतता के लिए 16-बिट निष्पादन योग्य कोड।
FIRMWARE_VOLUME_IMAGE	0x17	FV छवि के साथ अनुभाग। इस FV के अंदर इस तरह के सेक्शन के साथ एक फाइल भी हो सकती है, और इसी तरह, जब तक कि माइक्रोक्रेसीट में जगह खत्म न हो जाए।
FREEFORM_SUBTYPE_GUID	0x18	अनुभाग में डेटा होता है, जिसकी व्याख्या दर्ज की गई GUID की शुरुआत पर निर्भर करती है। शायद ही कभी इस्तेमाल किया गया हो।
रॉ	0x19	कच्चे डेटा के साथ अनुभाग। उनके साथ क्या करना है यह इस फ़ाइल को खोलने वाले द्वारा निर्धारित किया जाता है।
PEI_DEPEX	0x1B	पीईआई मॉड्यूल की निर्भरता का वर्णन करने वाला एक खंड जिसमें वह रहता है। इस खंड का प्रारूप खंड 1 में वर्णित है।
SMM_DEPEX	0x1C	वह अनुभाग जो एसएमएम चालक की निर्भरता का वर्णन करता है जिसमें वह स्थित है, प्रारूप DXE_DEPEX के समान है।

हमारे उदाहरण के साथ ऊपर की जाँच करें। पिछली बार मानी जाने वाली रॉ प्रकार की फाइल में कोई खंड नहीं होता है, तो आइए एक और फाइल लेते हैं, जिसका नाम है PEI मॉड्यूल जिसका नाम PchUsb है जो ऑफसेट 0x7AD210 पर स्थित है:

यह देखा जा सकता है कि यह वास्तव में PEIM है (फ़ाइल प्रकार 0x06 है), जिसमें दो खंड हैं। आकार 0x3A के पहले खंड और प्रकार PEI_DEPEX (0x1B) में इसकी निर्भरता के बारे में जानकारी है। दूसरे खंड (4 बाइट्स की सीमा पर संरेखित) का आकार 0x31A है और टाइप COMPRESSED_SECTION (0x01), और इसमें डेटा LZMA एल्गोरिथ्म (0x02) द्वारा पैक किया गया है और अनपैक करने के बाद इसका आकार 0x558 है। यदि आप जानते हैं कि आपके मन में LZMA को कैसे हटाना है, तो आप पहले ही अनुमान लगा चुके हैं कि इस सेक्शन के अंदर क्या है, यदि नहीं, तो मैं आपको बताता हूँ। 2 और खंड हैं: PE32 मॉड्यूल के निष्पादन योग्य कोड और फ़ाइल नाम के साथ USER_INTERFACE के साथ। आप पूछते हैं, मुझे कैसे पता चलेगा कि मेरे दिमाग में LZMA नहीं है? उसके लिए एक ऐप है!

फीनिक्सटूल और निष्कर्ष

इस एप्लिकेशन को फीनिक्सटूल कहा जाता है और इसका मुख्य कार्य एसएलआईसी को यूईएफआई BIOS फाइलों में जोड़ना है, लेकिन हम कानून का पालन करने वाले लोग हैं और हम अपने BIOS में एसएलआईसी को नहीं जोड़ेंगे। कार्यक्रम के सभी कार्यों में से, हम संरचना बटन में रुचि रखेंगे, BIOS को निर्दिष्ट करने के बाद उपलब्ध होगा जिसके साथ हम काम करेंगे। संरचना एक अलग विंडो में खुलती है और एक पेड़ के रूप में यूईएफआई BIOS छवि प्रस्तुत करती है। प्रत्येक घटक के लिए, इस पर जानकारी और उपलब्ध क्रियाएं दाईं ओर प्रदर्शित की जाती हैं। इस विंडो में ऊपर दिए गए उदाहरण में माना गया फ़ाइल कुछ इस प्रकार है:

कार्यक्रम फ़ाइल संरचना के सीमित संपादन की अनुमति देता है, लेकिन इससे बचने के लिए इसे संशोधित नहीं करना सबसे अच्छा है।

यूईएफआई निष्पादन को बेहतर तरीके से कैसे संपादित किया जाए और यह क्या कर सकता है, इसकी जानकारी के लिए, अगला लेख पढ़ें।
आपका ध्यान देने के लिए धन्यवाद।

साहित्य

यूईएफआई प्लेटफॉर्म इनिशियलाइजेशन स्पेसिफिकेशन 1.2.1 इरेटा ए, यूईएफआई फोरम द्वारा दस्तावेज