🏘️ 👾 🗻 सिस्टम प्रबंधन मोड कोड को ट्रेस करने के लिए इंटेल प्रोसेसर ट्रेस का उपयोग करना 🎅🏾 🕉️ 🚻

यह आलेख सिस्टम प्रबंधन मोड (SMM) मोड में ट्रेस रिकॉर्ड करने के लिए Intel प्रोसेसर ट्रेस (Intel PT) तकनीक का उपयोग करने की संभावना के परीक्षण के लिए समर्पित है। यह काम समर ऑफ हैक 2019 के हिस्से के रूप में किया गया था। @sysenter_eip ने पोस्ट किया था ।

उपयोग किए गए अधिकांश उपकरण अन्य लोगों द्वारा लिखे गए हैं (विशेष रूप से @d_olex , @aionescu )। परिणाम एक विशिष्ट मदरबोर्ड के लिए एसएमएम मोड में कोड निष्पादन पथ प्राप्त करने के लिए उपलब्ध साधनों का एक संयोजन है। हालांकि, सामग्री उन लोगों के लिए दिलचस्प हो सकती है जो अपने मंच के लिए इसे दोहराना चाहते हैं या एसएमएम के काम में रुचि रखते हैं।

सिस्टम प्रबंधन मोड

एसएमएम x86 आर्किटेक्चर प्रोसेसर का एक विशेष, विशेषाधिकार प्राप्त मोड है, जो ऑपरेटिंग सिस्टम के चलने के दौरान उपलब्ध है, लेकिन इसके लिए पूरी तरह से अदृश्य है। यह लोहे, बिजली प्रबंधन, विरासत उपकरणों के उत्सर्जन, स्लीप मोड (एस 3) के लिए संक्रमण, टीपीएम तक पहुंच और अधिक के साथ निम्न-स्तरीय बातचीत के लिए डिज़ाइन किया गया है। यह ओएस से पूरी तरह से अलग है। एसएमएम निष्पादन की अवधि के लिए, ओएस पूरी तरह से बंद हो जाता है। इस मोड में चलने वाले प्रोग्राम कोड को मदरबोर्ड की SPI- फ्लैश मेमोरी में संग्रहीत किया जाता है और यह UEFI BIOS फर्मवेयर का हिस्सा है।

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

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

इंटेल प्रोसेसर ट्रेस

विभिन्न अत्यधिक लोड किए गए अनुप्रयोगों के लिए डिबगिंग प्रक्रिया के नुकसान में से एक ओवरहेड है - डिबगिंग टूल की लागत। उन्हें हार्डवेयर-सक्षम समाधान के साथ कम किया जा सकता है।

इंटेल (ब्रॉडवेल) से प्रोसेसर की पांचवीं पीढ़ी ने इंटेल प्रोसेसर ट्रेस जैसी तकनीक के साथ दुनिया को पेश किया है। यह कैसे उपयोगी है? इंटेल पीटी आपको डीबग किए गए एप्लिकेशन के पूर्ण प्रवाह (नियंत्रण प्रवाह) को न्यूनतम ओवरहेड (<5%) के साथ प्राप्त करने की अनुमति देता है। एक ही समय में, यह मल्टीथ्रेडिंग का समर्थन करता है और एप्लिकेशन ट्रेस रिकॉर्ड करते समय समय टिकटों के कारण "दौड़ की स्थिति" जैसी त्रुटियों को ठीक करने में मदद कर सकता है। निस्संदेह, इंटेल पीटी प्रौद्योगिकी अनुप्रयोगों में भेद्यता खोज उपकरण लिखने के लिए शानदार अवसर प्रदान करती है।

आज, इस तकनीक का उपयोग विभिन्न उपकरणों में ट्रेसिंग, डिबगिंग और कोड कवरेज का मूल्यांकन करने के लिए किया जाता है - दोनों उपयोगकर्ता और कर्नेल-स्तरीय अनुप्रयोगों में। उपकरण के उदाहरण इंटेल वेबसाइट पर पाए जा सकते हैं। एक AFL फ़्यूज़र विकल्प जो Intel PT का लाभ उठाता है वह PTfuzzer रिपॉजिटरी में उपलब्ध है। हाल की परियोजनाओं में, iptanalyzer पर ध्यान दें ।

हालाँकि, हमने SMM मोड में Intel PT के उपयोग पर कोई काम नहीं देखा है। चूंकि इस संदर्भ में कुछ भी हमें इंटेल पीटी का उपयोग करने से रोकता है, इसलिए हमने यह पता लगाने का निर्णय लिया कि क्या इसके साथ सिस्टम प्रबंधन मोड कोड का पता लगाना संभव है।

काम की तैयारी

यह इंटेल डेवलपर मैनुअल से निम्नानुसार है कि नियमित साधनों का उपयोग करके बाहर से एसएमएम में इंटेल पीटी ट्रेसिंग को सक्रिय करना असंभव है। यदि यह SMI ट्रिगर होने के समय सक्रिय था, तो प्रोसेसर SMI हैंडलर प्रविष्टि बिंदु पर नियंत्रण स्थानांतरित करने से पहले इसे निष्क्रिय कर देगा। केवल सक्रियण विधि ही कोड द्वारा SMI हैंडलर का स्वैच्छिक समावेश है।

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

सबसे पहले, आपको एसएमआरएएम (रैम का क्षेत्र जिसमें एसएमएम मोड में निष्पादित कोड स्थित है) तक पहुंचने की आवश्यकता है। चूंकि यह रैम क्षेत्र संरक्षित है, इसलिए हम इसे ऑपरेटिंग सिस्टम से एक्सेस नहीं कर सकते हैं (यहां तक कि यह डीएमए के साथ नहीं किया जा सकता है)। कई परिदृश्य हैं:

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

फर्मवेयर में अपना कोड एम्बेड करें

इस तथ्य के बावजूद कि विभिन्न निर्माताओं के कोड में एसएमएम कमजोरियां समय-समय पर पाई जाती हैं, यह बेहतर होगा कि हम उन पर भरोसा न करें। हमारे लिए नए फर्मवेयर पर कोड का पता लगाना अधिक दिलचस्प है और तदनुसार, उनमें कमजोरियों को खोजने का प्रयास करें। हमारे पास पहले से ही इंटेल बूट गार्ड के साथ GIGABYTE GA-Q270M-D3H मदरबोर्ड था, इसलिए हमें केवल एसएमएम के लिए एक पिछले दरवाजे को जोड़ना था।

चित्र 1. टेस्ट बेंच

एसएमएम को "संक्रमित" करने और पिछले दरवाजे के साथ काम करने के लिए पहले से ही एक रूपरेखा है । इसमें तीन घटक होते हैं: C में UEFI ड्राइवर, "इंफ़ेक्टर", और पायथन में क्लाइंट स्क्रिप्ट। इसके संचालन के लिए, आपको एक मनमाने ढंग से डीएक्सई चालक को निकालने की जरूरत है (आप यूईईफिटूल का उपयोग करके ऐसा कर सकते हैं) और इसे एक इन्फ़ेक्टर के साथ संसाधित करें। मूल मॉड्यूल को "सुधार" द्वारा बदल दिया गया था, और फर्मवेयर को एसपीआई मेमोरी में अपलोड किया गया था (एसपीआई फ्लैश ड्राइव को चमकाने की सुविधा के लिए बोर्ड से हटा दिया गया था)।

चित्रा 2. एसपीआई-फ्लैश मेमोरी चिप

सिस्टम सफलतापूर्वक शुरू हुआ, और अब हमारे पास पायथन से एसएमआरएएम तक पूर्ण पहुंच है (पिछले दरवाजे से उपयोग का एक उदाहरण प्रदान किया गया है)। चूँकि पिछले दरवाजे के लिए क्लाइंट स्क्रिप्ट CHIPSEC पर आधारित है, इसलिए आपको इसे कर्नेल मोड तक पहुँच प्रदान करने की आवश्यकता है (हमने RWEverything ड्राइवर का उपयोग किया है; यह किसी के लिए सुविधाजनक होगा कि वह अपने CHIPSEC ड्राइवर का उपयोग सिस्टम में हस्ताक्षर सत्यापन बंद कर दे)।

आप SMRAM डंप का अनुरोध करके पिछले दरवाजे की जांच कर सकते हैं।

$ python SmmBackdoor.py -d

इस आदेश को निष्पादित करने के बाद, SMRAM_dump_cb000000_cb7fffff.bin फ़ाइल वर्तमान SMRAM स्थिति वाले बनाई जाएगी। मान cb000000 और cb7fffff, क्रमशः, SMRAM की शुरुआत और अंत के भौतिक पते हैं।

डंप SMRAM के साथ काम करें

SMRAM डंप को एक disassembler में लोड किया जा सकता है या smram_parse.py स्क्रिप्ट पर विश्लेषण के लिए पारित किया जा सकता है, जो हमारे लिए बहुत सारी उपयोगी जानकारी निकाल देगा। हमारे लिए सबसे महत्वपूर्ण एसएमआई प्रवेश बिंदुओं के पते होंगे। ये उन कार्यों के पते हैं जिन पर एसएमआई ट्रिगर होने पर नियंत्रण स्थानांतरित किया जाएगा। प्रत्येक CPU का अपना प्रवेश बिंदु होता है।

चित्रा 3. smram_parse स्क्रिप्ट का आउटपुट

आइए उनके कोड को देखें। चूंकि एसएमएम 16-बिट रियल मोड (वर्चुअल स्पेस में पहले 4 जीबी रैम परिलक्षित होता है) में इसका निष्पादन शुरू होता है, पहली चीज जो कोड करती है वह 64-बिट मोड पर स्विच होती है। उसी समय, संपूर्ण SMRAM राइट और एक्ज़ीक्यूट राइट्स के साथ उपलब्ध है, क्योंकि केवल एक सेगमेंट बनाया गया था (क्या कोई विक्रेता हैं जो इसे अलग तरीके से करते हैं?)।

हम 16-बिट कोड लिखना नहीं चाहते हैं या 64-बिट मोड पर स्विच करने के लिए आवश्यक सब कुछ अपने दम पर तैयार करना चाहते हैं, इसलिए हम SMI प्रबंधक फ़ंक्शन को कॉल करने से पहले अपने इंटरसेप्टर को सही जगह देंगे (यह फ़ंक्शन निर्धारित करता है कि एसएमएम मॉड्यूल को निष्पादन के आधार पर स्थानांतरित किया जाना चाहिए) क्या सेवा कहा जाता था या क्या घटना हुई थी)।

चित्रा 4. हुकिंग के लिए प्लेसमेंट

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

नोट: इंटरसेप्टर कोड के स्थान के बारे में। चूंकि SMRAM की संरचना हमारे लिए पूरी तरह से ज्ञात नहीं है, हमने प्रवेश बिंदुओं में से एक के पास शून्य मेमोरी का एक यादृच्छिक टुकड़ा चुना, जहां हमने इंटरसेप्टर कोड रखा। सबसे अच्छा विकल्प फर्मवेयर में अपने एसएमएम मॉड्यूल को जोड़ना होगा, जो यूईएफआई कानूनी रूप से एसएमआरएएम में होगा, ताकि चिंता न करें कि हमारे कोड के साथ कुछ महत्वपूर्ण ओवरराइट हो जाएगा।

एक SMI प्रबंधक इंटरसेप्टर को लागू करना

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

चित्र 5. SMBASE लेआउट

हम इंटेल पीटी की स्थिति निर्धारित करते हैं

सेव स्टेट एसएमएम में, MSR रजिस्टर IA32_RTIT_CTL का मान, जो Intel PT अनुरेखण के प्रबंधन के लिए जिम्मेदार है, को बचाया जाना चाहिए। दुर्भाग्य से, इंटेल मैनुअल यह संकेत नहीं देता है कि एसएमएम के संक्रमण के समय प्रोसेसर IA32_RTIT_CTL.TraceEn की स्थिति को बचाता है (चाहे ट्रेसिंग सक्षम है, शून्य बिट)। हालाँकि, हम इसे स्वयं सेव स्टेट एसएमएम को दो बार डंप करके निर्धारित कर सकते हैं: सक्षम किए बिना ट्रेसिंग के साथ और बिना।

हमने पायथन इंटरप्रिटर प्रक्रिया (pid 1337 ) पर ट्रेसिंग को सक्रिय करने के लिए WinIPT टूल का उपयोग किया, ट्रेस बफर को 2 ^ 12 (4096) बाइट्स आवंटित किया और फिर इंटरप्रेटर के अंदर SmmBackdoor.py स्क्रिप्ट को निष्पादित किया (तर्क 0 एक ध्वज है, हमारे लिए वे हमारे लिए नहीं हैं महत्वपूर्ण, क्योंकि SMM में आपको अभी भी अपनी ट्रेस सेटिंग को बाध्य करना पड़ता है)।

$ ipttool.exe --start 1337 12 0

SMRAM स्नैपशॉट की तुलना करके, हमने SMM सहेजें राज्य संरचना में IA32_RTIT_CTL रजिस्टर का स्थान निर्धारित किया। इसे ऑफसेट SMBASE + 0xFE3C पर संग्रहीत किया जाता है। IA32_RTIT_CTL.TraceEn बिट की स्थिति SMM के अंदर Intel PT फिर से सक्रिय होने की मुख्य स्थिति है। इस ऑफसेट पर फ़ील्ड को इंटेल डेवलपर मैनुअल में आरक्षित के रूप में चिह्नित किया गया है।

चित्र 6. फ़ील्ड को आरक्षित करना चिह्नित करना

शेलकोड लिखना

हम अपने दम पर एसएमएम के अंदर इंटेल पीटी को कॉन्फ़िगर नहीं करना चाहते थे, क्योंकि यह हमारे शेलकोड को जटिल करेगा (उदाहरण के लिए, एसएमएम में होने के नाते, रैम का एक बड़ा हिस्सा आवंटित करना मुश्किल होगा, ताकि यह स्वयं ऑपरेटिंग सिस्टम द्वारा उपयोग न किया जाए)। इसलिए, हमने पहले से ही कॉन्फ़िगर किए गए ट्रेसर का उपयोग करने का निर्णय लिया और एसएमएम के अंदर इसे "सीधे" छोड़ दिया, खासकर जब से इसमें पहले से ही किसी फ़ाइल को ट्रेस सहेजने का कार्य है।

चूंकि हमने इस उद्देश्य के लिए WinIPT का उपयोग किया था, जो उस समय कर्नेल कोड (CPL == 0) के अनुरेखण का समर्थन नहीं करता था, यह स्पष्ट था कि जब SMM में ट्रेस शामिल किया गया था, तब भी लॉग में कुछ भी नहीं दिखाई देगा, क्योंकि SML कोड CPL = 0 पर निष्पादित किया गया था। । हमें कुछ फिल्टरों को संशोधित करने की आवश्यकता है ताकि अनुरेखक एसएमएम में पूरे समय काम कर सके। हम उन सभी को सूचीबद्ध करते हैं जिन्हें जाँचने और स्थापित करने की आवश्यकता है:

CPL = 0 के साथ अनुरेखण सक्षम होना चाहिए।
CPL> 0 के लिए अनुरेखण सक्षम होना चाहिए (वैकल्पिक)।
रिकॉर्डिंग की घटनाओं के लिए वैध आईपी पर्वतमाला को निष्क्रिय किया जाना चाहिए।
IA32_RTIT_STATUS.PacketByteCnt रीसेट होना चाहिए।
CR3 फ़िल्टरिंग अक्षम होना चाहिए।

PacketByteCnt के बारे में कुछ शब्द कहा जाना चाहिए। यह काउंटर निर्धारित करता है कि आपको किस बिंदु पर ट्रेस में सिंक्रोनाइज़ेशन पैकेट (कई PSB कमांड का एक क्रम) डालना है। हमें इस काउंटर को रीसेट करने की आवश्यकता है, अन्यथा, ट्रेस के प्रसंस्करण के दौरान, एसएमएम में प्रवेश करने का क्षण चूक जाएगा, और ट्रेस एक यादृच्छिक स्थान से शुरू होगा जब पीएसबी स्वाभाविक रूप से उत्पन्न होता है।

नीचे वह शेलकोड है जिसका हमने उपयोग किया है:

  sub rsp, 0x18 ; this will align stack at 16 byte boundary (in case SMM ; code uses align dependent instructions) mov qword ptr ss:[rsp+0x10], rcx ; need to save rcx for SMI_Dispatcher mov ecx, 0x9E ; MSR_IA32_SMBASE rdmsr test byte ptr ds:[rax+0xFE3C], 0x1 ; Save State area contains saved ; IA32_RTIT_CTL.TraceEn je short @NoTrace call @Trace_Enable mov rcx, qword ptr ss:[rsp+0x10] ; SMI_Dispatcher is __fastcall ; (first argument in rcx) mov eax, 0xCB7DDAA4 ; original SMI_Dispatcher !!!!!!!!!!!!!!!!!!!!! call rax call @Trace_Disable add rsp, 0x18 ret @NoTrace: mov rcx, qword ptr ss:[rsp+0x10] ; SMI_Dispatcher is __fastcall mov eax, 0xCB7DDAA4 ; original SMI_Dispatcher !!!!!!!!!!!!!!!!!!!!! call rax add rsp, 0x18 ret @Trace_Disable: mov ecx, 0x570 ; IA32_RTIT_CTL rdmsr mov rax, qword ptr ss:[rsp+0x10] ; restore IA32_RTIT_STATUS wrmsr mov ecx, 0x571 ; IA32_RTIT_STATUS rdmsr mov rax, qword ptr ss:[rsp+0x8] ; restore IA32_RTIT_CTL wrmsr ret @Trace_Enable: mov ecx, 0x571 ; IA32_RTIT_STATUS rdmsr mov qword ptr ss:[rsp+0x8], rax ; save IA32_RTIT_STATUS and edx, 0xFFFF0000 ; IA32_RTIT_STATUS.PacketByteCnt = 0 wrmsr mov ecx, 0x570 ; IA32_RTIT_CTL rdmsr mov qword ptr ss:[rsp+0x10], rax ; save IA32_RTIT_CTL and eax, 0xFFFFFFBF ; IA32_RTIT_CTL.CR3Filter = 0 or eax, 0x5 ; IA32_RTIT_CTL.OS = 1; IA32_RTIT_CTL.User = 1; and edx, 0xFFFF0000 ; IA32_RTIT_CTL.ADDRx_CFG = 0 wrmsr ret

इस कोड को SMRAM में रखा जाना चाहिए, और SMI प्रबंधक को संक्रमण हमारे कोड पर जाने के लिए पैच किया जाना चाहिए। यह सब SmmBackdoor का उपयोग करके किया जाता है।

ट्रैक के साथ काम करें

SMI प्रबंधक इंटरसेप्टर ने हमें SMM से पहला कोड ट्रेस लिखने की अनुमति दी। निम्न कमांड WinIPT से फाइल को ट्रेस बचाने के लिए कह सकती है:

$ ipttool.exe --trace 1337 trace_file_name

किसी प्रक्रिया पर अनुरेखण अक्षम करना:

$ ipttool.exe --stop 1337

आप टकटकी से डम्प्ट उपयोगिता का उपयोग करके ट्रेस को अलग करने की कोशिश कर सकते हैं।

$ ptdump.exe --no-pad ./examples/trace_smm_handler_33 > ./examples/trace_smm_handler_33_pt_dump.txt

आउटपुट उदाहरण:

चित्रा 7. पहला एसएमएम अनुदेश पथ

हम कुछ पते देख सकते हैं, हालांकि इस जानकारी का उपयोग करना बेहद मुश्किल है, क्योंकि यह बहुत निम्न स्तर का है।

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

$ ptxed.exe --pt tracesmm_12 --raw SMRAM_dump_cb000000_cb7fffff.bin:0xcb000000 > tracesmm_12_ptasm

चित्रा 8. आईपीबी लॉग के लिए असेंबलर लिस्टिंग

यह पहले से बहुत बेहतर लग रहा है, लेकिन यदि कोड में लूप होता है, तो आउटपुट समान निर्देशों के साथ भरा जाएगा।

ट्रेस का उपयोग करके कोड कवरेज को परिभाषित करें

कवरेज विज़ुअलाइज़ेशन प्राप्त करने के लिए, हमने आईडीए प्रो के लिए लाइटहाउस प्लगइन चुना, जो ड्रकोव प्रारूप का उपयोग करता है।

कोई तैयार उपकरण नहीं मिला, इसलिए हमने ptxed को संशोधित किया ताकि यह प्रक्रिया में एक कवरेज फ़ाइल भी उत्पन्न करे। पैचेड ptxed रिपॉजिटरी में उपलब्ध है । वास्तव में क्या जोड़ा गया था यह निर्धारित करने के लिए प्रतिबद्ध इतिहास पर एक नज़र डालें।

Ptxed पूर्ण होने के बाद, SMRAM_dump_cb000000_cb7fffff.bin.log फ़ाइल दिखाई देती है, जिसमें ड्रकोव प्रारूप में कवरेज जानकारी होगी।

नोट: पहले PSB पर डिस्सेम्बलर सिंक्रोनाइज़ेशन के साथ थोड़ी समस्या है। पूरी तरह से स्पष्ट कारण के लिए, यदि पीएसई पीजीई से पहले उत्पन्न होता है (काउंटर को फिर से सक्रिय होने से पहले शून्य पर रीसेट किया जाता है), तो उस पर ptxed को सिंक्रनाइज़ नहीं किया जा सकता है। इस समस्या के आसपास काम करने के लिए, हमने एक छोटा सा पैच बनाया। यह स्पष्ट नहीं है कि यह खुद ptxed के लिए एक समस्या है, या क्या हम IA32_RTIT_STATUS.PacketByteCnt को रीसेट करके कुछ गलत कर रहे हैं।

चित्र 9. एक पैच जो आपको PGE के ठीक सामने स्थित PSB का उपयोग करने की अनुमति देता है

जनरेटेड कवरेज फ़ाइलों को आईडीए प्रो में डाउनलोड किया जा सकता है और सुंदर हाइलाइटिंग के साथ-साथ प्रत्येक फ़ंक्शन के लिए प्रतिशत कवरेज पर आंकड़े मिल सकते हैं।

चित्र 10. कोड कवरेज जानकारी के साथ आईडीए प्रो लाइटहाउस प्लगइन

नोट: प्रकाशस्तंभ प्लगइन अपूर्ण विश्लेषण किए गए डेटाबेस पर थोड़ा अजीब तरीके से काम करता है (निष्पादन योग्य कोड लेबल नहीं है, फ़ंक्शन नहीं बनाए गए हैं)। हमने इस "समस्या" को get_instructions_slice फ़ंक्शन के लिए \ lighthouse \ metadata.py फ़ाइल में खोजा, जहाँ यह उस पते के लिए भी 0 निर्देश देता है जहाँ फ़ंक्शन मैन्युअल रूप से बनाया गया था। प्लगइन कैश का उपयोग करता है और नए विशिष्ट कोड को अनदेखा करता है। यह कार्यक्रम पर रीनालीज़ को कॉल करके और आईडीबी को फिर से खोलने के द्वारा दरकिनार किया जा सकता है। उसके बाद ही प्लगइन नया कोड देख पाएगा और उस पर विचार करना शुरू कर देगा। चूंकि यह समस्या SMRAM डंप के मामले में बहुत असुविधाजनक है (जो पहले बूट पर लगभग पूरी तरह से अपरिभाषित कोड से बना है), हमने लाइटहाउस कोड में एक छोटा बदलाव किया ताकि हम मैन्युअल रूप से नए कोड को तेजी से परिभाषित कर सकें।

चित्रा 11. नए कोड की पहचान करने में मदद करने के लिए लॉग संदेश जोड़ा गया

लिनक्स समर्थन

चूंकि हमारे सभी परीक्षण विंडोज 10 x64 पर किए गए थे (हमें ipt.sys की आवश्यकता थी, जो विंडोज अक्टूबर क्रिएटर्स अपडेट 2018 में दिखाई दी थी), आइए लिनक्स में इसे लागू करने की संभावना के बारे में कुछ शब्द कहते हैं।

एक लिनक्स कर्नेल परफेक्ट मॉड्यूल है जो कर्नेल मोड में कोड को ट्रेस करने की क्षमता सहित एक ही WinIPT (ipt.sys) क्रिया कर सकता है।
चूंकि पिछले दरवाजे SMM इंटरफ़ेस क्रॉस-प्लेटफॉर्म CHIPSEC फ्रेमवर्क पर आधारित है, इसलिए हमारा पैच बिना किसी संशोधन के लिनक्स सिस्टम पर काम करेगा।

निष्कर्ष

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

हमें उम्मीद है कि यह लेख एसएमएम कोड में कमजोरियों की जांच और खोज के लिए दूसरों को इंटेल पीटी तकनीक का लाभ उठाने में मदद करता है। अन्य मदरबोर्ड में हमारे काम को अपनाने से कठिनाइयों का कारण नहीं होना चाहिए (इंटेल बूट गार्ड के बारे में मत भूलना)। मुख्य बात यह है कि यह कैसे काम करता है, इसे पूरी तरह से समझना है। सबसे कठिन हिस्सा यह निर्धारित करना है कि एसएमआई डिस्पैचर को कैसे इंटरसेप्ट करना है और इंटरसेप्टर के लिए एक शेलकोड लिखना है। हमारे संस्करण में, "वायर्ड" पते का उपयोग किया गया था, इसलिए आपको शेलकोड को सावधानीपूर्वक किसी अन्य सिस्टम में स्थानांतरित करना चाहिए।

सभी उपयोग किए गए उपकरण और स्क्रिप्ट GitHub पर भंडार में उपलब्ध हैं।

सिस्टम प्रबंधन मोड कोड को ट्रेस करने के लिए इंटेल प्रोसेसर ट्रेस का उपयोग करना