GIGABYTE H510M K V2 BIOS SMM रिवर्स-इंजीनियरिंग और CVE-2025-7026/7027/7028/7029 अनुसंधान

GIGABYTE H510M K V2 (H510MKV2.F3) BIOS इमेज का स्थैतिक रिवर्स-इंजीनियरिंग: पूर्ण UEFI फर्मवेयर-वॉल्यूम निष्कर्षण, PI-spec SMM Core मेमोरी आवंटक का विश्लेषण, और चार SMM मेमोरी-भ्रष्टाचार भेद्यताओं के लिए एक लक्षित खोज, जिन्हें GIGABYTE/Binarly ने 2025 में खुलासा किया था (CVE-2025-7026 CVE-2025-7027 CVE-2025-7028 CVE-2025-7029)।

स्थिति: 4 में से 1 CVE की उपस्थिति की पुष्टि हुई (CVE-2025-7027)। अन्य 3 की सक्रिय रूप से संपूर्ण सुलभ फर्मवेयर में खोज की गई और वे नहीं मिले - इसका वास्तव में क्या अर्थ है और क्या नहीं, इसके लिए अपुष्ट CVE देखें।

अनुसंधान की सभी फ़ाइलें: GOOGLE DRIVE डाउनलोड: SMM_ALL

विषय-सूची

• अस्वीकरण / दायरा
• लक्ष्य
• TL;DR
• पद्धति और उपकरण
• फर्मवेयर लेआउट
• रिपॉज़िटरी लेआउट
• पृष्ठभूमि: सार्वजनिक CVE
• अतिरिक्त खोज: SMM मेमोरी आवंटक (PiSmmCore)
• पुष्टि: CVE-2025-7027
• अपुष्ट CVE CVE-2025-7026 / 7028 / 7029
• निवारण
• सीमाएँ
• संदर्भ

अस्वीकरण / दायरा

यह n-day अनुसंधान है, कोई 0-day खुलासा नहीं। यहाँ संदर्भित सभी चार CVE पहले से ही GIGABYTE द्वारा सार्वजनिक रूप से खुलासा किए जा चुके थे और पैच किए जा चुके थे (पैच किया हुआ फर्मवेयर 2025-06-12 से जारी होना शुरू हुआ), CVE असाइन किए गए थे और Binarly तथा CERT/CC द्वारा इस अनुसंधान के शुरू होने से पहले दस्तावेजित किए गए थे। इस रिपॉज़िटरी में कुछ भी नई भेद्यता खोज नहीं है - यह एक स्वतंत्र स्थैतिक-विश्लेषण सत्यापन है कि पहले से खुलासा किए गए, पहले से पैच किए गए बग वर्ग एक विशिष्ट सार्वजनिक रूप से डाउनलोड करने योग्य BIOS बिल्ड में मौजूद हैं या नहीं।

• कोई कार्यशील एक्सप्लॉइट या PoC शामिल नहीं है और न ही बनाया गया। यह केवल स्थैतिक-विश्लेषण है (निकाले गए फर्मवेयर मॉड्यूलों का डिसअसेंबली/डीकंपिलेशन); कुछ भी निष्पादित नहीं किया गया, कोई SMRAM पढ़ा/लिखा नहीं गया, किसी हार्डवेयर को छुआ नहीं गया।
• कोई नई भेद्यता का दावा नहीं। CVE-2025-7027 की उपस्थिति की पुष्टि Binarly द्वारा पहले से सार्वजनिक रूप से वर्णित भेद्य कोड पैटर्न का मिलान करके की गई है, न कि इसे स्वतंत्र रूप से खोजकर।
• शैक्षिक / रक्षात्मक-सुरक्षा उद्देश्यों के लिए प्रकाशित: यह समझने के लिए कि n-day फर्मवेयर बग व्यवहार में कैसे दिखते हैं, और इस विशिष्ट बोर्ड/BIOS संशोधन के लिए ठोस साक्ष्य के साथ GIGABYTE की स्वयं की अपडेट अनुशंसा को सुदृढ़ करने के लिए।
• यदि आपके पास यह बोर्ड है: अपना BIOS अपडेट करें। निवारण देखें।

लक्ष्य

TL;DR

• BIOS इमेज से पूर्ण UEFI फर्मवेयर वॉल्यूम ट्री निकाला गया (uefi_firmware / uefi-firmware-parser) - SMM/DXE वॉल्यूम में 356 FFS फ़ाइलें सूचीबद्ध की गईं, जिनमें से 302 के पास निकालने योग्य PE32/TE इमेज है।
• PiSmmCore (PI-spec SMM Core) को अलग कर पूरी तरह रिवर्स-इंजीनियर किया गया, जिससे वास्तविक SMM पूल/पेज आवंटक (SmmAllocatePool/SmmFreePool/SmmAllocatePages/SmmFreePages आंतरिक) की पुष्टि और नामकरण हुआ - इसके हार्ड-कोडेड "sphd"/"tail" गार्ड सिग्नेचर के माध्यम से, जो EDK2 के ओपन-सोर्स MdeModulePkg/Core/PiSmmCore/Pool.c से बिल्कुल मेल खाता है।
• ROM में पाए गए हर फर्मवेयर वॉल्यूम के हर निकालने योग्य मॉड्यूल (कुल 325+ मॉड्यूल) में Binarly के सार्वजनिक CVE-2025-7026/7027/7028/7029 लेखों के पहचान चिह्नकों की खोज की गई।
• CVE-2025-7027 - पुष्टि। GenericComponentSmmEntry में सटीक भेद्य कोड पथ खोजा और ट्रेस किया गया: एक NVRAM वेरिएबल (SetupXtuBufferAddress) को के माध्यम से बिना किसी सत्यापन के प्राप्त किया जाता है और SW SMI के माध्यम से पहुँच योग्य राइट पॉइंटर के रूप में सीधे उपयोग किया जाता है - यह Binarly के सार्वजनिक मूल-कारण विवरण से बिंदु-दर-बिंदु मेल खाता है।

पद्धति और उपकरण

1. निष्कर्षण - uefi_firmware (uefi-firmware-parser -e) ने BIOS इमेज को पुनरावर्ती रूप से अनपैक किया: Intel Flash Descriptor क्षेत्र → फर्मवेयर वॉल्यूम → FFS फ़ाइलें → अनुभाग, मिले हर LZMA/Tiano-संपीड़ित फर्मवेयर वॉल्यूम को डीकंप्रेस करते हुए।
2. मॉड्यूल पृथक्करण - .ui (ड्राइवर प्रदर्शन नाम) अनुभाग और .pe/.te इमेज अनुभाग वाली हर FFS फ़ाइल को एक स्टैंडअलोन PE32+/TE बाइनरी के रूप में कॉपी किया गया, जिसका नाम <DriverName>__<GUID8>.<pe32|te> रखा गया।
3. स्थैतिक विश्लेषण - Hex-Rays डीकंपाइलर के साथ IDA Pro (ida-pro-mcp / idalib हेडलेस वर्कर इंटरफ़ेस के माध्यम से), प्रति मॉड्यूल एक डेटाबेस। केवल ऑटो-विश्लेषण + Hex-Rays - इस वातावरण में कोई FLIRT सिग्नेचर या EDK2 टाइप लाइब्रेरी उपलब्ध नहीं थी (नीचे सीमा के रूप में उल्लेखित)।
4. चिह्नक खोज - Binarly के सार्वजनिक परामर्शों में नामित पहचानकर्ताओं (वेरिएबल नाम, मैजिक कॉन्स्टेंट, फ़ंक्शन लेबल) के लिए हर निकाले गए मॉड्यूल (और कच्ची 16 MB इमेज) पर Python बाइट/स्ट्रिंग स्कैन।
5. मैन्युअल ट्रेसिंग - हर चिह्नक हिट के लिए संदर्भित फ़ंक्शन को डीकंपाइल किया गया और उसके कॉल ग्राफ (कॉलर/कैली) को हाथ से ट्रेस किया गया ताकि वास्तविक कोड पथ का पुनर्निर्माण हो सके, जिसे सार्वजनिक मूल-कारण विवरण के विरुद्ध क्रॉस-चेक किया गया।
6. नामकरण - पुष्टि किए गए फ़ंक्शनों को उनके IDA डेटाबेस में नामांतरित किया गया ताकि निष्कर्ष को केवल गद्य में नहीं, बल्कि सीधे विश्लेषण-योग्य आर्टिफैक्ट में भी दर्ज किया जा सके।

फर्मवेयर लेआउट

BIOS इमेज में चार Intel Flash Descriptor क्षेत्र हैं; केवल region-bios में GIGABYTE/OEM कोड है (region-me.fd region-gbe.fd region-pdr.fd Intel Management Engine / GbE / डिस्क्रिप्टर फर्मवेयर हैं - अलग घटक, दायरे से बाहर, अन्वेषित नहीं किए गए)।

region-bios के भीतर चार फर्मवेयर वॉल्यूम पाए गए और निकाले गए:

चारों को निकाला गया और चिह्नक-स्कैन किया गया (देखें अपुष्ट CVE)।

रिपॉज़िटरी लेआउट

SMM/
├── README.md                    this file
├── CVE_ANALYSIS.md              full technical deep-dive (code-level detail confidence notes)
├── flash.fd                     copy of the extracted 16MB BIOS image
├── regions/                     raw recursive extraction (every FV/FFS/section as produced by uefi_firmware)
├── smm_modules/                 PiSmmCore isolated + fully analyzed (.pe32 + Hex-Rays .i64 renames applied)
├── smm_modules_all/             all 51 `Smm*`-named drivers as standalone PE32/TE + manifest.txt
│                                 (4 extra ones  PiSmmCpuDxeSmm SmmAccess SmmControl SmmLockBox
│                                  FlashSmiSmm FlashDriverSmm  have auto-analyzed .i64 databases)
├── all_modules/                 every extractable module from the main DXE/SMM volume (302 not just Smm*-named)
├── extra_volumes_modules/       modules from the two smaller auxiliary firmware volumes
└── f641_pei_modules/            modules from the duplicate PEI-phase volume copy

पृष्ठभूमि: सार्वजनिक CVE

चारों में समान सूत्र: एक सॉफ़्टवेयर SMI हैंडलर किसी रजिस्टर या NVRAM-स्रोत मान पर मेमोरी के पॉइंटर के रूप में भरोसा करता है, बिना यह सत्यापित किए कि वह वास्तव में SMRAM के बाहर है, जिससे ring-0 (प्रशासक/रूट) हमलावर एक सामान्य SW SMI ट्रिगर को SMM-विशेषाधिकार (ring -2) मनमाना रीड/राइट में बदल सकता है - पूर्ण फर्मवेयर समझौता, Secure-Boot बायपास और OS के नीचे स्थायित्व (persistence)।

अतिरिक्त खोज: SMM मेमोरी आवंटक (PiSmmCore)

यह कोई भेद्यता नहीं है - पृष्ठभूमि अनुसंधान जिसने बाकी काम को आधार दिया, यह साबित करके कि टूलचेन (निष्कर्षण → PE पृथक्करण → IDA/Hex-Rays → मैन्युअल RE) वास्तव में प्रामाणिक स्रोत-सत्यापन योग्य EDK2 आंतरिक को पुनर्प्राप्त करती है, इससे पहले कि इसे सुरक्षा बगों की ओर इंगित किया गया।

PiSmmCore (GUID e94f54cd-81eb-47ed-aec3-856f5dc157a9) PI-spec SMM Core है: यह SmmAllocatePool/SmmFreePool/SmmAllocatePages/SmmFreePages और SMI हैंडलर डिस्पैच तालिका का स्वामी है।

कॉल श्रृंखला (पते smm_modules/PiSmmCore.pe32.i64 के अंदर):

_ModuleEntryPoint (0x1184)
  -> SmmCoreEntryPointHelper (0x14D4)        writes the "SMST" table signature
     -> SmmInternalAllocatePool_wrapper (0x95EC)
        -> InternalAllocPoolByIndex_sphd_tail (0x57A8)     <- the allocator
     -> SmmAllocateZeroedPool (0x961C)        alloc + zero wrapper

SmmFreePool_wrapper (0x9714)
  -> SmmIsBufferInsideSmram (0x95A8)          decides SMRAM-resident vs not
  -> SmmInternalFreePool_sphd_tail (0x591C)   validates sphd/tail frees
     -> InternalFreePages (0x6A2C)            page-granularity free + coalesce
InternalFindFreePages (0x6820)                page-granularity alloc (mirror of InternalFreePages)

InternalAllocPoolByIndex_sphd_tail (0x57A8) की पुष्टि वास्तविक EDK2 MdeModulePkg/Core/PiSmmCore/Pool.c आवंटक के रूप में हुई: यह शाब्दिक ASCII सिग्नेचर "sphd" (SMM_POOL_HEAD_SIGNATURE) और "tail" (SMM_POOL_TAIL_SIGNATURE) हार्ड-कोड करता है - ओपन-सोर्स कार्यान्वयन के सटीक मैजिक कॉन्स्टेंट। ≤ 0x800 बाइट्स के अनुरोध एक साइज़-क्लास फ्री-लिस्ट सबआवंटक से गुजरते हैं; बड़े अनुरोध पेज फ्री-लिस्ट को ट्रेस करते हैं और लौटाए गए चंक को हेड/टेल गार्ड सिग्नेचर से लपेटते हैं। फ्री-पक्ष समकक्ष (SmmInternalFreePool_sphd_tail) मेमोरी को फ्री लिस्ट में लौटाने से पहले समान सिग्नेचर सत्यापित करता है।

सभी नामांतरण smm_modules/PiSmmCore.pe32.i64 में अंतर्निहित हैं - सीधे निरीक्षण के लिए इसे IDA में Hex-Rays के साथ खोलें।

पुष्टि: CVE-2025-7027

मॉड्यूल: GenericComponentSmmEntry (GUID 9caa3071-3459-4c5b-bbf0-ee68fe4dd46d) फ़ाइल: smm_modules_all/GenericComponentSmmEntry__9caa3071.pe32 (+ विश्लेषित .i64)

यह कैसे पाया गया

हर निकाले गए मॉड्यूल (पहले 51 Smm*-नामित, फिर मुख्य वॉल्यूम के सभी 302, फिर सहायक वॉल्यूम) को SetupXtuBufferAddress के लिए बाइट/स्ट्रिंग-स्कैन किया गया - वही सटीक NVRAM वेरिएबल नाम जिसे Binarly का CVE-2025-7027 लेख उद्धृत करता है। यह GenericComponentSmmEntry के अंदर एक UTF-16LE स्ट्रिंग के रूप में मेल खाया (और इसके DXE समकक्ष GenericComponentDxeEntry में, जो संभवतः इसे सेट/एक्सपोज़ करता है)।

भेद्य श्रृंखला

1. GetXtuBufferAddress_FromNvram (0x1F270) - gRT->GetVariable(L"SetupXtuBufferAddress" &Guid NULL &Size=8 &OutBuffer) को कॉल करता है (रनटाइम-सर्विस शैली तालिका में ऑफ़सेट +72 = GetVariable)। इस NVRAM वेरिएबल में संग्रहीत कच्चा 8-बाइट मान लौटाता है - इस बात का कोई सत्यापन नहीं कि वह मान वास्तव में क्या है।

2. SUSPECTED_CVE_2025_7027_UnvalidatedXtuPtrWrite (0x18400) - उपरोक्त को कॉल करके v3 (NVRAM-स्रोतित "पता") प्राप्त करता है, फिर (अपनी स्वयं की इनपुट संरचना a1[3] से ली गई गिनती द्वारा सीमित) लूप करता है:

*(WORD *)(v3 + 2 * v7 + 12) = v9;   // v3 = raw NVRAM value v9 = attacker-influenced data

v3 को राइट लक्ष्य के रूप में उपयोग करने से पहले कभी भी यह जाँच नहीं की जाती कि वह वास्तविक, सीमा-के-भीतर, गैर-SMRAM पता है। SetupXtuBufferAddress एक सामान्य (इस बिल्ड में गैर-SMM-लॉक) NVRAM वेरिएबल है - एक ring-0 हमलावर SMI ट्रिगर करने से पहले SetVariable() के माध्यम से इसे अपनी पसंद के किसी भी पते पर सेट कर सकता है (जैसे SMRAM पता या संवेदनशील कर्नेल/हाइपरवाइज़र संरचना), जिससे एक नियंत्रित SMM-विशेषाधिकार वाला write-what-where उत्पन्न होता है।

3. ComponentDispatch_KeymapOrXtu (0x18590) - डिस्पैच कॉलबैक: एक आंतरिक घटक डेटाबेस से घटक-प्रकार बाइट प्राप्त करता है और यदि type == 1 है तो उपरोक्त भेद्य फ़ंक्शन को कॉल करता है। Type 0 SetupVar_SafeKeymapWrite_bounded (0x18234) पर जाता है, जो तुलना के लिए एक वास्तविक Setup NVRAM वेरिएबल के विरुद्ध उचित साइज़-बनाम-क्षमता बाउंड्स जाँच करता है। यही अंतर XTU पथ को असामान्य अनचेक किए गए पथ के रूप में उजागर करता है।

4. sub_18698 - ComponentDispatch_KeymapOrXtu को डिस्पैच मान 0xB2 (178 दशमलव) के विरुद्ध पंजीकृत करता है - ठीक वही SwSmiInputValue 0xB2 जिसे Binarly का परामर्श इस बग वर्ग के लिए नामित करता है। यह सॉफ़्टवेयर-SMI ट्रिगर पोर्ट को सीधे भेद्य डिस्पैच पथ से जोड़ता है।

विश्वास स्तर: उच्च

• NVRAM वेरिएबल नाम का सटीक मिलान (SetupXtuBufferAddress) - शब्दशः।
• SW SMI ट्रिगर मान का सटीक मिलान (0xB2)।
• कोड पैटर्न (अविश्वसनीय पॉइंटर प्राप्त करना, उसके माध्यम से बिना सदस्यता/बाउंड्स जाँच के राइट करना) "डबल पॉइंटर डीरेफ़रेंस … मनमाना SMRAM राइट" मूल कारण से बिल्कुल मेल खाता है।
• स्वतंत्र रूप से पुष्ट नहीं: अंतिम कड़ी - SMI प्रवेश पर RBX रजिस्टर किस प्रकार ComponentDispatch_KeymapOrXtu/a1[3] तक पहुँचने वाले घटक-चयन इनपुट को फीड करता है - को कच्चे CPU-सेव-स्टेट रीड तक पूरी तरह ट्रेस नहीं किया गया। इसके लिए GenericComponentSmmEntry के पंजीकृत कॉलबैक में कॉल करने से पहले पंजीकृत 0xB2 मान पर डिस्पैच करने वाले कोड का एक और पास आवश्यक होगा।

यह स्थैतिक-विश्लेषण पुष्टि है कि CVE में वर्णित भेद्य पैटर्न इस BIOS बिल्ड में मौजूद है - नहीं कोई कार्यशील एक्सप्लॉइट या PoC। न तो SMRAM सामग्री, न सेव-स्टेट लेआउट, न ही रनटाइम व्यवहार सत्यापित किया गया।

अपुष्ट CVE CVE-2025-7026 / 7028 / 7029

क्या खोजा गया

इन तीन CVE के लिए Binarly के सार्वजनिक लेखों में नामित हर चिह्नक - $DB$ 2DB$ SwSmi OcHeader FuncBlock CommandRcx0 ReadFlash WriteFlash EraseFlash GetFlashInfo - को शाब्दिक बाइट अनुक्रम और (जहाँ लागू हो) UTF-16LE स्ट्रिंग दोनों के रूप में खोजा गया:

• कच्ची 16 MB flash.fd इमेज।
• मुख्य DXE/SMM वॉल्यूम के सभी 302 निकालने योग्य मॉड्यूल (all_modules/)।
• दोनों सहायक फर्मवेयर वॉल्यूम के सभी मॉड्यूल (extra_volumes_modules/)।
• डुप्लिकेट PEI-चरण वॉल्यूम प्रति के सभी 22 मॉड्यूल (f641_pei_modules/)।

ये चिह्नक कहीं भी नहीं मिले। केवल SetupXtuBufferAddress (CVE-2025-7027) और सामान्य OverClock UI-टेक्स्ट स्ट्रिंग्स (असंबंधित BIOS सेटअप मेनू लेबल) मेल खाए।

यह अनिर्णीत क्यों है - पूर्ण स्वच्छता प्रमाण नहीं

SetupXtuBufferAddress को शाब्दिक स्ट्रिंग के रूप में प्रकट होना ही था क्योंकि यह GetVariable() को दिया गया वास्तविक NVRAM वेरिएबल नाम है - स्ट्रिंग कार्यात्मक रूप से आवश्यक है। इसके विपरीत CommandRcx0 OcHeader और FuncBlock उन अनाम/स्ट्रिप्ड फ़ंक्शनों के लिए Binarly के स्वयं के आंतरिक लेबल प्रतीत होते हैं जिन्हें उन्होंने रिवर्स-इंजीनियर किया - बाइनरी में अंतर्निहित पहचानकर्ता नहीं। स्ट्रिंग के रूप में उनकी अनुपस्थिति इस बारे में कुछ साबित नहीं करती कि अंतर्निहित कोड मौजूद है या नहीं। $DB$/2DB$ मैजिक कॉन्स्टेंट यदि मौजूद होते तो बाइट-स्तरीय मिलान के रूप में प्रकट होते (वे संकलित तुलना में एक इमीडिएट ऑपरेंड के रूप में दिखाई देते या नहीं) - उनकी अनुपस्थिति कुछ अधिक सार्थक है, फिर भी निर्णायक नहीं (एक भिन्न इमीडिएट एन्कोडिंग, एक प्रति-मॉडल फर्मवेयर वैरिएंट, या थोड़ा भिन्न जाँच क्रम - ये सभी कच्चे सबस्ट्रिंग स्कैन से बच सकते हैं)।

यदि यह अनुसंधान जारी रखा जाए तो ठोस अगले कदम

1. CVE-2025-7028 (फ्लैश संचालन)। FlashSmiSmm (GUID 6c289241-...) और FlashDriverSmm (GUID 0c375a90-...) सबसे प्रबल उम्मीदवार हैं - उनके नाम ReadFlash/WriteFlash/EraseFlash/GetFlashInfo से लगभग बिल्कुल मेल खाते हैं। दोनों को निकाला गया और ऑटो-विश्लेषित किया गया (.i64 डेटाबेस smm_modules_all/ में, Hex-Rays-तैयार) लेकिन मैन्युअल रूप से ट्रेस नहीं किया गया - क्रमशः 174 और 243 फ़ंक्शन हैं, बिना किसी विशिष्ट स्थैतिक चिह्नक के, जिसके लिए CVE-2025-7027 के लिए किए गए उसी प्रकार के मैन्युअल डिस्पैचर-ट्रेसिंग की आवश्यकता है (SW SMI 0xB2-समतुल्य पंजीकरण खोजें, उसे फ़ंक्शन-पॉइंटर-तालिका डिस्पैच तक अनुसरण करें, जाँचें कि तालिका पॉइंटर सत्यापित है या नहीं)।
2. CVE-2025-7029 (पावर/थर्मल OcHeader)। अच्छे उम्मीदवार: स्वयं (इसी मॉड्यूल में अनचेक-पॉइंटर बग का पहले से सिद्ध स्रोत), , , , - अभी तक किसी को मैन्युअल रूप से ट्रेस नहीं किया गया।

इसमें से कुछ भी इस पास में पूरा नहीं किया गया - इसे यहाँ स्पष्ट रूप से चिह्नित किया गया है ताकि अंतर दिखाई दे, न कि चुपचाप "जाँचा गया और स्वच्छ" मान लिया जाए।

निवारण

यदि आपके पास यह बोर्ड है (या इस परामर्श से आच्छादित 240+ GIGABYTE मॉडलों में से कोई): GIGABYTE की सपोर्ट साइट से वर्तमान BIOS में अपडेट करें। GIGABYTE ने 2025-06-12 से पैच किया हुआ फर्मवेयर जारी करना शुरू किया; यहाँ विश्लेषित बिल्ड (H510MKV2.F3, दिनांक 2023-12-20) उससे लगभग 18 महीने पहले का है और अपैच्ड होने के अनुरूप है। यह कोई सैद्धांतिक अनुशंसा नहीं है - इस अनुसंधान ने CVE-2025-7027 के लिए वास्तविक भेद्य कोड पथ इस विशिष्ट बिल्ड में मौजूद पाया।

सीमाएँ

• इस विश्लेषण वातावरण में कोई EDK2/UEFI टाइप लाइब्रेरी (.til) उपलब्ध नहीं थी, इसलिए SMM सिस्टम तालिका (gSmst)/निजी-डेटा संरचना फ़ील्ड को Hex-Rays द्वारा स्वचालित रूप से मैप नहीं किया जा सका; विश्लेषण में कुछ स्ट्रक्चर-ऑफ़सेट व्याख्याएँ लागू टाइप जानकारी के बजाय मैन्युअल ट्रेसिंग पर आधारित हैं।
• केवल स्थैतिक विश्लेषण। कोई गतिशील परीक्षण, इम्यूलेशन या हार्डवेयर पहुँच नहीं - निष्कर्ष कोड की पहुँच योग्यता और आकृति का वर्णन करते हैं, वास्तविक हार्डवेयर पर पुष्ट रनटाइम एक्सप्लॉयटेबिलिटी का नहीं।
• region-me.fd region-gbe.fd region-pdr.fd (Intel ME / GbE / डिस्क्रिप्टर क्षेत्र) अन्वेषित नहीं किए गए - दायरे से बाहर (अलग फर्मवेयर घटक, GIGABYTE/OEM SMM कोड नहीं)।
• चार में से तीन CVE उपरोक्त विवरण के अनुसार अपुष्ट बने हुए हैं।

संदर्भ

• GIGABYTE Security Advisory 2302
• CERT/CC VU#746790
• Binarly BRLY-DVA-2025-008 (CVE-2025-7026)
• Binarly BRLY-DVA-2025-011 (CVE-2025-7029)
• NVD: CVE-2025-7026
• uefi_firmware / uefi-firmware-parser
• इस README द्वारा सारांशित पूर्ण कोड-स्तरीय तकनीकी गहन-विश्लेषण के लिए CVE_ANALYSIS.md देखें।