tobss8/gigabyte-h510m-k-v2-bios-smm-reverse-engineering-cve-2025-7026-7027-7028-7029-research
GIGABYTE H510M K V2 (`H510MKV2.F3`) BIOS छवि का स्थैतिक रिवर्स-इंजीनियरिंग: PI-स्पेक SMM Core मेमोरी आवंटक का पूर्ण UEFI फर्मवेयर-वॉल्यूम निष्कर्षण विश्लेषण और GIGABYTE/Binarly द्वारा 2025 में खुलासा की गई चार SMM मेमोरी-भ्रष्टाचार भेद्यताओं (CVE-2025-7026 CVE-2025-7027 CVE-2025-7028 CVE-2025-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 देखें।
यह n-day अनुसंधान है, कोई 0-day खुलासा नहीं। यहाँ संदर्भित सभी चार CVE पहले से ही GIGABYTE द्वारा सार्वजनिक रूप से खुलासा किए जा चुके थे और पैच किए जा चुके थे (पैच किया हुआ फर्मवेयर 2025-06-12 से जारी होना शुरू हुआ), CVE असाइन किए गए थे और Binarly तथा CERT/CC द्वारा इस अनुसंधान के शुरू होने से पहले दस्तावेजित किए गए थे। इस रिपॉज़िटरी में कुछ भी नई भेद्यता खोज नहीं है - यह एक स्वतंत्र स्थैतिक-विश्लेषण सत्यापन है कि पहले से खुलासा किए गए, पहले से पैच किए गए बग वर्ग एक विशिष्ट सार्वजनिक रूप से डाउनलोड करने योग्य BIOS बिल्ड में मौजूद हैं या नहीं।
| बोर्ड | GIGABYTE H510M K V2 (H510MKV2) |
| BIOS फ़ाइल | H510MKV2.F3 |
| फ़ाइल आकार | 16777216 बाइट्स (16 MB) |
| फ़ाइल दिनांक | 2023-12-20 |
| MD5 | a9bca8aeb55061824af1c3eedfb5c846 |
| SHA-256 | 934a935e5faba8d2cea4e1d51e9edb6aed86b32f412d0da5bae602bd9fd8f9f3 |
| चिपसेट | Intel H510 |
| विक्रेता पैच उपलब्धता | 2025-06-12 से (यह बिल्ड इससे ~18 महीने पहले का है) |
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 से बिल्कुल मेल खाता है।GenericComponentSmmEntry में सटीक भेद्य कोड पथ
खोजा और ट्रेस किया गया: एक NVRAM वेरिएबल (SetupXtuBufferAddress) को
GetVariable() के माध्यम से बिना किसी सत्यापन के प्राप्त किया जाता है और SW SMI
0xB2 के माध्यम से पहुँच योग्य राइट पॉइंटर के रूप में सीधे उपयोग किया जाता है -
यह Binarly के सार्वजनिक मूल-कारण विवरण से बिंदु-दर-बिंदु मेल खाता है।uefi_firmware
(uefi-firmware-parser -e) ने BIOS इमेज को पुनरावर्ती रूप से अनपैक किया: Intel
Flash Descriptor क्षेत्र → फर्मवेयर वॉल्यूम → FFS फ़ाइलें → अनुभाग,
मिले हर LZMA/Tiano-संपीड़ित फर्मवेयर वॉल्यूम को डीकंप्रेस करते हुए।.ui (ड्राइवर प्रदर्शन नाम) अनुभाग और .pe/.te इमेज
अनुभाग वाली हर FFS फ़ाइल को एक स्टैंडअलोन PE32+/TE बाइनरी के रूप में कॉपी किया गया,
जिसका नाम <DriverName>__<GUID8>.<pe32|te> रखा गया।ida-pro-mcp / idalib हेडलेस वर्कर
इंटरफ़ेस के माध्यम से), प्रति मॉड्यूल एक डेटाबेस। केवल ऑटो-विश्लेषण + Hex-Rays -
इस वातावरण में कोई FLIRT सिग्नेचर या EDK2 टाइप लाइब्रेरी उपलब्ध नहीं थी
(नीचे सीमा के रूप में उल्लेखित)।BIOS इमेज में चार Intel Flash Descriptor क्षेत्र हैं; केवल region-bios में
GIGABYTE/OEM कोड है (region-me.fd region-gbe.fd
region-pdr.fd Intel Management Engine / GbE / डिस्क्रिप्टर फर्मवेयर हैं -
अलग घटक, दायरे से बाहर, अन्वेषित नहीं किए गए)।
region-bios के भीतर चार फर्मवेयर वॉल्यूम पाए गए और निकाले गए:
| वॉल्यूम (कंटेनर FFS GUID) | सामग्री | निकाली गई फ़ाइलें |
|---|---|---|
file-9e21fd93-... → volume-ee4e5898-... | मुख्य DXE/SMM ड्राइवर वॉल्यूम - सभी Smm* ड्राइवर, प्लेटफ़ॉर्म DXE ड्राइवर | 302 |
file-f641ac56-... → volume-ee4e5898-... | उपरोक्त की डुप्लिकेट/PEI-चरण प्रति (छोटा सबसेट: PiSmmCommunicationPei IT8728FSmmFeaturesPei आदि) | 22 |
file-3417f275-... → volume-3417f275-... | प्रारंभिक PEI/DXE ब्रिंग-अप वॉल्यूम (DxeIpl FspS3Notify ...) | 21 (2 इमेज सहित) |
file-05ca020b-... → volume-05ca020b-... | छोटा सहायक वॉल्यूम - कोई निष्पादन योग्य इमेज नहीं | 2 |
चारों को निकाला गया और चिह्नक-स्कैन किया गया (देखें अपुष्ट 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 | Binarly ID | CVSS | सार्वजनिक मूल-कारण सारांश |
|---|---|---|---|
| CVE-2025-7026 | BRLY-2025-008 | 8.2 | SW SMI हैंडलर (SwSmiInputValue 0xB2) RBX रजिस्टर पर एक अनचेक किए गए पॉइंटर के रूप में भरोसा करता है, एक फ़ंक्शन के अंदर जिसे Binarly CommandRcx0 कहता है; यदि *RBX '$DB$'/'2DB$' से मेल खाता है तो हैंडलर एक मनमाना SMRAM राइट करता है। |
| CVE-2025-7027 | BRLY-2025-009 | 8.2 | डबल पॉइंटर डीरेफ़रेंस: एक अनवैलिडेटेड NVRAM वेरिएबल (SetupXtuBufferAddress) जो हमलावर-नियंत्रित RBX-व्युत्पन्न पॉइंटर के साथ संयुक्त होता है → मनमाना SMRAM राइट। |
| CVE-2025-7028 | BRLY-2025-010 | 8.2 | RBX/RCX से व्युत्पन्न फ़ंक्शन-पॉइंटर संरचनाओं (FuncBlock) के सत्यापन की कमी, जो ReadFlash/WriteFlash/EraseFlash/GetFlashInfo के माध्यम से पहुँच योग्य हैं। |
| CVE-2025-7029 | BRLY-2025-011 | 8.2 | पावर/थर्मल (ओवरक्लॉक) कॉन्फ़िगरेशन लॉजिक में RBX का अनचेक किया गया उपयोग हमलावर-प्रभावित OcHeader पॉइंटर को नियंत्रित करता है → मनमाना SMRAM राइट। |
चारों में समान सूत्र: एक सॉफ़्टवेयर SMI हैंडलर किसी रजिस्टर या NVRAM-स्रोत मान पर मेमोरी के पॉइंटर के रूप में भरोसा करता है, बिना यह सत्यापित किए कि वह वास्तव में SMRAM के बाहर है, जिससे ring-0 (प्रशासक/रूट) हमलावर एक सामान्य SW SMI ट्रिगर को SMM-विशेषाधिकार (ring -2) मनमाना रीड/राइट में बदल सकता है - पूर्ण फर्मवेयर समझौता, Secure-Boot बायपास और OS के नीचे स्थायित्व (persistence)।
यह कोई भेद्यता नहीं है - पृष्ठभूमि अनुसंधान जिसने बाकी काम को आधार दिया, यह साबित करके कि टूलचेन (निष्कर्षण → 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 के साथ खोलें।
मॉड्यूल: 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 ट्रिगर पोर्ट
को सीधे भेद्य डिस्पैच पथ से जोड़ता है।
SetupXtuBufferAddress) - शब्दशः।0xB2)।RBX रजिस्टर किस प्रकार
ComponentDispatch_KeymapOrXtu/a1[3] तक पहुँचने वाले घटक-चयन इनपुट को फीड
करता है - को कच्चे CPU-सेव-स्टेट रीड तक पूरी तरह ट्रेस नहीं किया गया। इसके लिए
GenericComponentSmmEntry के पंजीकृत कॉलबैक में कॉल करने से पहले पंजीकृत 0xB2
मान पर डिस्पैच करने वाले कोड का एक और पास आवश्यक होगा।यह स्थैतिक-विश्लेषण पुष्टि है कि CVE में वर्णित भेद्य पैटर्न इस BIOS बिल्ड में मौजूद है - नहीं कोई कार्यशील एक्सप्लॉइट या PoC। न तो SMRAM सामग्री, न सेव-स्टेट लेआउट, न ही रनटाइम व्यवहार सत्यापित किया गया।
इन तीन CVE के लिए Binarly के सार्वजनिक लेखों में नामित हर चिह्नक -
$DB$ 2DB$ SwSmi OcHeader FuncBlock CommandRcx0 ReadFlash
WriteFlash EraseFlash GetFlashInfo - को शाब्दिक बाइट अनुक्रम और (जहाँ लागू हो)
UTF-16LE स्ट्रिंग दोनों के रूप में खोजा गया:
flash.fd इमेज।all_modules/)।extra_volumes_modules/)।f641_pei_modules/)।ये चिह्नक कहीं भी नहीं मिले। केवल SetupXtuBufferAddress (CVE-2025-7027) और
सामान्य OverClock UI-टेक्स्ट स्ट्रिंग्स (असंबंधित BIOS सेटअप मेनू लेबल) मेल खाए।
SetupXtuBufferAddress को शाब्दिक स्ट्रिंग के रूप में प्रकट होना ही था क्योंकि यह
GetVariable() को दिया गया वास्तविक NVRAM वेरिएबल नाम है - स्ट्रिंग कार्यात्मक रूप से
आवश्यक है। इसके विपरीत CommandRcx0 OcHeader और FuncBlock उन अनाम/स्ट्रिप्ड
फ़ंक्शनों के लिए Binarly के स्वयं के आंतरिक लेबल प्रतीत होते हैं जिन्हें उन्होंने
रिवर्स-इंजीनियर किया - बाइनरी में अंतर्निहित पहचानकर्ता नहीं। स्ट्रिंग के रूप में उनकी
अनुपस्थिति इस बारे में कुछ साबित नहीं करती कि अंतर्निहित कोड मौजूद है या नहीं।
$DB$/2DB$ मैजिक कॉन्स्टेंट यदि मौजूद होते तो बाइट-स्तरीय मिलान के रूप में प्रकट
होते (वे संकलित तुलना में एक इमीडिएट ऑपरेंड के रूप में दिखाई देते या नहीं) - उनकी
अनुपस्थिति कुछ अधिक सार्थक है, फिर भी निर्णायक नहीं (एक भिन्न इमीडिएट एन्कोडिंग, एक
प्रति-मॉडल फर्मवेयर वैरिएंट, या थोड़ा भिन्न जाँच क्रम - ये सभी कच्चे सबस्ट्रिंग स्कैन से
बच सकते हैं)।
FlashSmiSmm (GUID 6c289241-...)
और FlashDriverSmm (GUID 0c375a90-...) सबसे प्रबल उम्मीदवार हैं -
उनके नाम ReadFlash/WriteFlash/EraseFlash/GetFlashInfo से लगभग
बिल्कुल मेल खाते हैं। दोनों को निकाला गया और ऑटो-विश्लेषित किया गया (.i64
डेटाबेस smm_modules_all/ में, Hex-Rays-तैयार) लेकिन मैन्युअल रूप से ट्रेस नहीं
किया गया - क्रमशः 174 और 243 फ़ंक्शन हैं, बिना किसी विशिष्ट स्थैतिक चिह्नक के,
जिसके लिए CVE-2025-7027 के लिए किए गए उसी प्रकार के मैन्युअल डिस्पैचर-ट्रेसिंग की
आवश्यकता है (SW SMI 0xB2-समतुल्य पंजीकरण खोजें, उसे फ़ंक्शन-पॉइंटर-तालिका
डिस्पैच तक अनुसरण करें, जाँचें कि तालिका पॉइंटर सत्यापित है या नहीं)।OcHeader)। अच्छे उम्मीदवार:
GenericComponentSmmEntry स्वयं (इसी मॉड्यूल में अनचेक-पॉइंटर बग का पहले से
सिद्ध स्रोत), PowerMgmtSmm, RealTimePowerSmm, ThermalFanCtrSmm,
PpamPlatformSmm - अभी तक किसी को मैन्युअल रूप से ट्रेस नहीं किया गया।$DB$/2DB$ सिग्नेचर जाँच)। चूँकि Binarly के लेखों के
अनुसार SwSmiInputValue 0xB2 कम से कम CVE-2025-7026 और CVE-2025-7027 में
साझा है, और इस डंप ने साबित किया कि 0xB2 GenericComponentSmmEntry में एक
वास्तविक सक्रिय रूप से उपयोग किया जाने वाला डिस्पैच मान है, अगला कदम मुख्य वॉल्यूम के
हर उस ड्राइवर की गणना करना है जो 0xB2 के विरुद्ध कॉलबैक पंजीकृत करता है (केवल
पहले से मिले एक को नहीं) और प्रत्येक में अनचेक-पॉइंटर-प्लस-मैजिक-वैल्यू पैटर्न की
जाँच करना।इसमें से कुछ भी इस पास में पूरा नहीं किया गया - इसे यहाँ स्पष्ट रूप से चिह्नित किया गया है ताकि अंतर दिखाई दे, न कि चुपचाप "जाँचा गया और स्वच्छ" मान लिया जाए।
यदि आपके पास यह बोर्ड है (या इस परामर्श से आच्छादित 240+ GIGABYTE मॉडलों में से
कोई): GIGABYTE की सपोर्ट साइट से वर्तमान BIOS में अपडेट करें। GIGABYTE ने
2025-06-12 से पैच किया हुआ फर्मवेयर जारी करना शुरू किया; यहाँ विश्लेषित बिल्ड
(H510MKV2.F3, दिनांक 2023-12-20) उससे लगभग 18 महीने पहले का है और अपैच्ड होने के
अनुरूप है। यह कोई सैद्धांतिक अनुशंसा नहीं है - इस अनुसंधान ने CVE-2025-7027 के लिए
वास्तविक भेद्य कोड पथ इस विशिष्ट बिल्ड में मौजूद पाया।
.til) उपलब्ध नहीं थी,
इसलिए SMM सिस्टम तालिका (gSmst)/निजी-डेटा संरचना फ़ील्ड को Hex-Rays द्वारा
स्वचालित रूप से मैप नहीं किया जा सका; विश्लेषण में कुछ स्ट्रक्चर-ऑफ़सेट व्याख्याएँ लागू
टाइप जानकारी के बजाय मैन्युअल ट्रेसिंग पर आधारित हैं।region-me.fd region-gbe.fd region-pdr.fd (Intel ME / GbE /
डिस्क्रिप्टर क्षेत्र) अन्वेषित नहीं किए गए - दायरे से बाहर (अलग फर्मवेयर घटक,
GIGABYTE/OEM SMM कोड नहीं)।CVE_ANALYSIS.md देखें।