voidsec/driverbuddyreloadedDriver Buddy Reloaded एक IDA Pro Python प्लगइन है जो विंडोज कर्नेल ड्राइवरों के कुछ थकाऊ रिवर्स इंजीनियरिंग कार्यों को स्वचालित करने में मदद करता है।
स्थापना विधि आपके IDA संस्करण पर निर्भर करती है, क्योंकि अंतर्निहित प्लगइन प्रबंधक (और इसलिए hcli
टूल और ida-plugin.json मेनिफ़ेस्ट) केवल IDA 9.0 और उससे ऊपर में मौजूद है। IDA 7.6 और 8.x में कोई प्लगइन
प्रबंधक नहीं है और वे केवल प्लगइन फ़ोल्डर के शीर्ष स्तर को स्कैन करते हैं।
hcli)रिपॉजिटरी एक ida-plugin.json मेनिफ़ेस्ट भेजती है, इसलिए IDA 9.0+ प्लगइन को अपनी उप-निर्देशिका से लोड करता है। इसे इस प्रकार स्थापित करें:```
hcli plugin install DriverBuddyReloaded
यह प्लगइन को आपके उपयोगकर्ता प्लगइन फ़ोल्डर के एक उपनिर्देशिका में डालता है (जैसे
`%APPDATA%\Hex-Rays\IDA Pro\plugins\DriverBuddyReloaded\` या `~/.idapro/plugins/DriverBuddyReloaded\`), `DriverBuddyReloaded.py` एंट्री पॉइंट को उस उपनिर्देशिका के *अंदर* रखता है। यह अभिप्रेत लेआउट है: IDA मैनिफेस्ट को पढ़ता है, उपनिर्देशिका से घोषित एंट्री पॉइंट को लोड करता है, और `sys.path` पर उपनिर्देशिका को डालता है ताकि एंट्री पॉइंट सहोदर `DriverBuddyReloaded` पैकेज को आयात कर सके। आपको `DriverBuddyReloaded.py` को शीर्ष स्तर पर ले जाने की **आवश्यकता** नहीं है।
`hcli plugin status` के साथ इंस्टॉलेशन सत्यापित करें, फिर IDA लॉन्च करें और पुष्टि करें कि प्लगइन `Edit -> Plugins` के अंतर्गत दिखाई देता है (शुरुआत में किसी भी पायथन त्रुटि के लिए आउटपुट विंडो देखें)।
परीक्षण के लिए स्थानीय चेकआउट से इंस्टॉल करने के लिए (जैसे अपने स्वयं के बदलावों के बाद), रिपॉजिटरी रूट से `hcli plugin install .` चलाएँ; `hcli plugin lint .` पहले मैनिफेस्ट/लेआउट को मान्य करता है।
### IDA 7.6 / 8.x (मैन्युअल कॉपी)
इन संस्करणों में कोई प्लगइन प्रबंधक नहीं है, इसलिए `hcli`-इंस्टॉल किया गया उपनिर्देशिका प्लगइन **नहीं** उठाया जाएगा। `DriverBuddyReloaded` फ़ोल्डर और `DriverBuddyReloaded.py` स्क्रिप्ट फ़ाइल को सीधे IDA प्लगइन फ़ोल्डर के **शीर्ष स्तर** पर कॉपी करें, उदाहरण के लिए:
- `%APPDATA%\Hex-Rays\IDA Pro\plugins\`
- `C:\Program Files\IDA Pro 8.4\plugins\`
- `~/.idapro/plugins/`
परिणामी लेआउट `plugins\DriverBuddyReloaded.py` के साथ-साथ `plugins\DriverBuddyReloaded\` (पैकेज फ़ोल्डर) है।
### नोट्स
यदि आपका IDA Python 2 के लिए कॉन्फ़िगर किया गया है, तो इसे Python 3 पर स्विच करने के लिए `idapyswitch` बाइनरी (IDA के फ़ोल्डर में स्थित) चलाएँ।
**नोट:** Driver Buddy Reloaded IDA 7.6+, 8.x (8.4 सहित) और 9.0+ पर Python 3 के साथ चलता है। सभी संस्करण-विशिष्ट IDA API अंतर (IDA 9.0 में `get_inf_structure`, `ida_struct` मॉड्यूल और `idc.*struc*` हेल्पर्स को हटाना, आदि) `DriverBuddyReloaded/ida_compat.py` संगतता परत द्वारा आंतरिक रूप से संभाले जाते हैं।
## त्वरित उपयोग
ऑटो-विश्लेषण सुविधा का उपयोग करने के लिए:
1. IDA प्रारंभ करें और एक विंडोज़ कर्नेल ड्राइवर लोड करें।
2. ऑटो-विश्लेषण शुरू करने के लिए `Edit -> Plugins -> Driver Buddy Reloaded` पर जाएँ या `CTRL+ALT+A` दबाएँ।
3. विश्लेषण परिणामों के लिए "आउटपुट" विंडो देखें, और **Driver Buddy Reloaded - Findings** विंडो जो रन के अंत में खुलती है (एक पंक्ति पर डबल-क्लिक करके उसके पते पर जाएँ)।
4. निम्नलिखित फ़ाइलें IDA के DB निर्देशिका के अंतर्गत लिखी जाती हैं (सभी `<DRIVER_NAME>-YYYY-MM-DD-TIMESTAMP-` से उपसर्गित):
- `findings.json` - मशीन-पठनीय निष्कर्ष (IOCTL, फ़्लैग किए गए फ़ंक्शन, डिवाइस नाम, pooltags, कॉल चेन, ह्यूरिस्टिक्स, डिवाइस ACL ऑडिट, सिम्बोलिक लिंक, एक्सपोर्ट ऑडिट, विशेषाधिकार प्राप्त opcodes)
- `report.html` - एक स्वतंत्र, गंभीरता-समूहीकृत HTML रिपोर्ट
- `pooltags.txt` - WinDbg के लिए `pooltags.txt` प्रारूप में डंप किए गए Pooltags
- `autoanalysis.txt` - पूर्ण टेक्स्ट विश्लेषण लॉग (आउटपुट विंडो को दर्पण)
IOCTL को डिकोड करने के लिए:
1. माउस कर्सर को संदिग्ध IOCTL कोड वाली पंक्ति पर रखें।
2. राइट-क्लिक करें और `Driver Buddy Reloaded -> Decode IOCTL` चुनें; वैकल्पिक रूप से, `CTRL+ALT+D` शॉर्टकट दबाएँ।
IOCTL विंडो या findings विंडो को किसी भी समय फिर से खोलने के लिए (विश्लेषण को फिर से चलाए बिना):
- IOCTL विंडो खोलने के लिए `CTRL+ALT+I` दबाएँ।
- findings विंडो खोलने के लिए `CTRL+ALT+F` दबाएँ।
### उन्नत उपयोग
- [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/main/DriverBuddyReloaded/vulnerable_functions_lists) निर्देशिका में संभावित रूप से खतरनाक/समस्याग्रस्त फ़ंक्शन, विंडोज़ API और opcodes की सूचियाँ हैं; किसी विशिष्ट फ़ंक्शन/API को सूचीबद्ध करने के कारण का संक्षिप्त विवरण दिया गया है। आप ड्राइवर-विशिष्ट फ़ंक्शन शामिल करने के लिए `custom` सूची को संपादित कर सकते हैं।
**नोट**: `winapi_function_prefixes` फ़ंक्शन नाम की शुरुआत से आंशिक मिलान करेगा (जैसे `Zw` `ZwClose`, `ZwCommitComplete` आदि से मेल खाएगा) जबकि `winapi_functions` केवल सटीक मिलान करेगा।
- [find_opcodes.py](https://github.com/voidsec/driverbuddyreloaded/blob/main/DriverBuddyReloaded/find_opcodes.py) में, `find_opcode_data` विकल्प (डिफ़ॉल्ट `False`) डेटा अनुभागों में आने वाले opcode मिलान को दबा देता है ([issue #11](https://github.com/VoidSec/DriverBuddyReloaded/issues/11))। इसे `True` पर स्विच करने से डेटा में रॉ बाइट मिलान भी सामने आते हैं; यदि इस तरह कोई वास्तविक opcode छूट गया था, तो रिपोर्ट किए गए पते पर जाकर बाइट्स को कोड के रूप में पुनः परिभाषित करने से आमतौर पर वह पुनर्प्राप्त हो जाता है। मिलान की रिपोर्ट हर दूसरे चरण की तरह दी जाती है (परिणाम विंडो, `findings.json`, `report.html`)।
**सावधान**: इसे `True` पर स्विच करने से अधिक गलत सकारात्मक उत्पन्न होते हैं!
## Driver Buddy Reloaded के बारे में
**Driver Buddy Reloaded** एक IDA Pro Python प्लगइन है जो विंडोज़ कर्नेल ड्राइवरों के कुछ थकाऊ रिवर्स इंजीनियरिंग कार्यों को स्वचालित करने में मदद करता है। इसमें कई उपयोगी सुविधाएँ हैं, जैसे:
* ड्राइवर के प्रकार की पहचान करना (WDM, KMDF, UMDF, WDF, Mini-Filter, Stream Minidriver, AVStream, PortCls)
* प्रत्येक ड्राइवर प्रकार के लिए `DispatchDeviceControl` / `DispatchInternalDeviceControl` फ़ंक्शन का पता लगाना (एक `MajorFunction[IRP_MJ_DEVICE_CONTROL]` स्टोर स्कैन हैंडलर को एक मिनीफिल्टर/WDF ड्राइवर में भी ढूंढता है जो एक लीगेसी कंट्रोल डिवाइस भी प्रदर्शित करता है, और तब भी जब असाइनमेंट एक हेल्पर में होता है न कि `DriverEntry` में)
* `WDF` और `WDM` ड्राइवरों के लिए सामान्य संरचनाओं को पॉप्युलेट करना
* `IRP` और `IO_STACK_LOCATION` जैसी संरचनाओं की पहचान और लेबलिंग का प्रयास करता है
* उन `WDF` फ़ंक्शनों के कॉल को लेबल करता है जो सामान्यतः अलेबल होंगे
* एक `IRP_MJ_FUNCTION` IDA एनम बनाता है और इसे `DriverEntry` (WDM) में `MajorFunction` ऐरे स्लॉट्स पर लागू करता है
* IOCTL कोड ढूँढना और डिकोड करना
* पहचाने गए डिस्पैचर फ़ंक्शनों का स्वचालित मल्टी-स्ट्रेटेजी स्कैन (कोई कर्सर प्लेसमेंट आवश्यक नहीं): डीकम्पाइलर ctree (जंप-टेबल या बाइनरी-सर्च डिस्पैच द्वारा छिपे कोड को पुनर्प्राप्त करता है जो कभी तत्काल के रूप में प्रकट नहीं होते), IDA स्विच-टेबल पुनर्प्राप्ति, और एक रॉ इमीडिएट-ऑपरेंड फॉलबैक (फॉलबैक केवल उस फ़ंक्शन पर चलता है जो वास्तव में IRP के IoControlCode को पढ़ता है, ताकि गलत पहचाना गया लाइब्रेरी हेल्पर गलत IOCTL के रूप में अपने आंतरिक स्थिरांक को लीक न कर सके)
* NTSTATUS मान IDA टाइप डेटाबेस (एक व्यापक हार्डकोडेड फॉलबैक के साथ) से गतिशील रूप से हल किए जाते हैं, और **आउटबाउंड** IOCTL जो ड्राइवर केवल डाउनस्ट्रीम भेजता है (`IoBuildDeviceIoControlRequest` / `ZwDeviceIoControlFile` / ...) को बाहर रखा जाता है ताकि वे ड्राइवर के स्वयं के हमले की सतह के रूप में गलत न समझे जाएँ
* दुरुपयोग की संभावना वाले फ़ंक्शनों को फ़्लैग करना
* संभावित `DeviceName` ढूँढना (mmap स्कैन + IDA Strings DB फॉलबैक, स्रोत पते के साथ)
* `Pooltags` डंप करना (आयात-आधारित प्राथमिक + पंजीकृत-प्रोपेगेटेड फॉलबैक उन टैग्स के लिए जो एक रजिस्टर में चरणबद्ध हैं)
* प्रत्येक डिस्पैचर और उसके द्वारा सकर्मक रूप से कॉल किए गए फ़ंक्शनों पर **ह्यूरिस्टिक भेद्यता जाँच**: अमान्य उपयोगकर्ता-कॉपी, TOCTOU/डबल-फ़ेच, उपयोग-पश्चात-मुक्त (इंट्रा-फंक्शन और एक फ्री किए गए ग्लोबल के माध्यम से क्रॉस-फंक्शन), गायब विशेषाधिकार गेट, IRQL बेमेल, असुरक्षित MDL मैपिंग, स्टैक-आवंटित बफ़र (`_alloca`), आकार सत्यापन के बिना पूल आवंटन, विशेषाधिकार प्राप्त CPU निर्देश (पोर्ट I/O `in`/`out`, `mov cr*`), आर्बिट्ररी-राइट (राइट-व्हाट-व्हेयर), और `\Device\PhysicalMemory` संदर्भ (BYOVD पैटर्न) - देखें [ह्यूरिस्टिक भेद्यता जाँच](#heuristic-vulnerability-checks)
* **डिवाइस ACL ऑडिट और सिम्बोलिक-लिंक ट्रैकिंग**: बिना सुरक्षा डिस्क्रिप्टर (दुनिया-सुलभ) / कमज़ोर `IoCreateDeviceSecure` SDDL वाले `IoCreateDevice` डिवाइसों को फ़्लैग करता है, और `IoCreateSymbolicLink` लक्ष्य पथों को डिकोड करता है
* **एक्सपोर्ट ऑडिट**: शून्य आंतरिक क्रॉस-रेफरेंस वाले ड्राइवर एक्सपोर्ट को फ़्लैग करता है (संभावित हमले की सतह)
* **जोखिम-स्कोरिंग** प्रति-IOCTL डिकोड किए गए IOCTL ( `METHOD_NEITHER` / `FILE_ANY_ACCESS` को प्राथमिकता देता है, और IOCTL को केवल उसके **अपने** केस हैंडलर से पहुंचने योग्य खतरनाक सिंक/opcodes के लिए बढ़ाता है - `MmMapIoSpace`, `memcpy`, `__writemsr`, पोर्ट I/O, PCI-कॉन्फ़िग एक्सेस - ताकि एक मोनोलिथिक डिस्पैचर में एक सौम्य कोड अब एक खतरनाक सिबलिंग के सिंक से दूषित न हो; जब एट्रिब्यूशन अप्रिसाइज होता है तो बढ़ावा सीमित होता है न कि CRITICAL पर बाध्य) और सभी निष्कर्षों को गंभीरता के अनुसार एक क्लिक करने योग्य परिणाम विंडो में प्रस्तुत करता है (पते पर जाने के लिए डबल-क्लिक करें)
* **कॉल चेन ट्रेसिंग** डिस्पैच / IOCTL हैंडलर से खतरनाक सिंक तक (ह्यूरिस्टिक, नाम-आधारित)
* परिणामों को मशीन-पठनीय **JSON** फ़ाइल और एक स्वतंत्र **HTML** रिपोर्ट के रूप में निर्यात करना
### DispatchDeviceControl ढूँढना
टूल स्वचालित रूप से `DispatchDeviceControl` रूटीन का पता लगा और पहचान सकता है। यह फ़ंक्शन सभी इनकमिंग `DeviceIoControl` कोड को उस कोड से संबद्ध विशिष्ट ड्राइवर फ़ंक्शन में रूट करने के लिए उपयोग किया जाता है। इस फ़ंक्शन की स्वचालित पहचान प्रत्येक ड्राइवर के लिए मान्य `DeviceIoControl` कोड ढूँढना बहुत तेज़ बनाती है। इसके अतिरिक्त, जब क्रैश के कारण ड्राइवर में संभावित भेद्यताओं की जाँच की जाती है, तो इस फ़ंक्शन का स्थान जानने से ध्यान को क्रैश करने वाले `DeviceIoControl` कोड से संबद्ध विशिष्ट फ़ंक्शन कॉल पर केंद्रित करने में मदद मिलती है।
जब विश्लेषण सफल होता है तो कुछ सब्स का नाम इस प्रकार बदल दिया जाएगा:
- `DriverEntry`: मूल पहला ड्राइवर-प्रदत्त रूटीन जो ड्राइवर लोड होने के बाद कॉल किया जाता है। यह ड्राइवर को प्रारंभ करने के लिए जिम्मेदार है।
- `Real_Driver_Entry`: आमतौर पर वह फ़ंक्शन जहाँ `DriverEntry` से निष्पादन स्थानांतरित किया गया है। यह आमतौर पर वह जगह है जहाँ `DeviceName` प्रारंभ किया जाता है।
- `DispatchDeviceControl`/`DispatchInternalDeviceControl`: यदि टूल कुछ विशिष्ट ऑफ़सेट पर फ़ंक्शन को पुनर्प्राप्त करने में सक्षम था, तो फ़ंक्शन का नाम उपयुक्त नाम से बदल दिया जाएगा।
- `Possible_DispatchDeviceControl_#`: यदि टूल `DispatchDeviceControl` या `DispatchInternalDeviceControl` को पुनर्प्राप्त करने में सक्षम नहीं था, तो यह एक प्रायोगिक खोज का उपयोग करता है, निष्पादन प्रवाह का अनुसरण करता है, और उन मामलों की जाँच करता है जहाँ फ़ंक्शन ज्ञात `IO_STACK_LOCATION` और `IRP` पतों को लोड कर रहा है; यह इंगित करता है कि फ़ंक्शन DispatchDeviceControl हो सकता है। चूँकि यह ह्यूरिस्टिक पर आधारित है, यह एक से अधिक परिणाम लौटा सकता है, और गलत सकारात्मक होने की संभावना है।
### WDM और WDF संरचनाओं को लेबल करना
कई ड्राइवर संरचनाएँ सभी `WDM`/`WDF` ड्राइवरों के बीच साझा की जाती हैं। टूल स्वचालित रूप से इन संरचनाओं की पहचान करने में सक्षम है, जैसे `IO_STACK_LOCATION`, `IRP`, और `DeviceObject` संरचनाएँ, और रिवर्स इंजीनियरिंग प्रक्रिया के दौरान समय बचाने और ड्राइवर के उन क्षेत्रों में संदर्भ प्रदान करने में मदद कर सकता है जहाँ ये फ़ंक्शन उपयोग में हैं।
### IOCTL कोड ढूँढना और डिकोड करना
ड्राइवरों को रिवर्स करते समय, विश्लेषण के भाग के रूप में IOCTL कोड का सामना करना सामान्य है। ये कोड, जब डिकोड किए जाते हैं, उपयोगी जानकारी प्रकट करते हैं और ड्राइवर के विशिष्ट भागों पर ध्यान केंद्रित कर सकते हैं जहाँ भेद्यता होने की अधिक संभावना है।
एक संभावित IOCTL कोड पर राइट-क्लिक करके, एक संदर्भ मेनू विकल्प प्रस्तुत किया जाता है (वैकल्पिक रूप से संदिग्ध IOCTL कोड वाली पंक्ति पर कर्सर होने पर `Ctrl+Alt+D` शॉर्टकट का उपयोग करके) और इसका उपयोग मान को डिकोड करने के लिए किया जा सकता है। यह सभी डिकोड किए गए IOCTL कोड के साथ एक तालिका प्रिंट करेगा। डिसअसेंबली व्यू में डिकोड किए गए IOCTL कोड पर राइट-क्लिक करके, इसे अमान्य के रूप में चिह्नित करना संभव है; यह किसी भी गैर-IOCTL टिप्पणी को बरकरार रखेगा।
- डिकोड किए गए IOCTL आउटपुट विंडो में प्रिंट किए जाते हैं और गंभीरता-रंगीन IOCTL विंडो में सूचीबद्ध होते हैं; ऑटो-विश्लेषण के बाद वे `findings.json` / `report.html` में भी दर्ज किए जाते हैं।
ऑटो-विश्लेषण अतिरिक्त रूप से पहचाने गए डिस्पैचर फ़ंक्शनों पर एक मल्टी-स्ट्रेटेजी स्कैन चलाता है ताकि IOCTL को स्वचालित रूप से खोजा जा सके, बिना मैन्युअल कर्सर प्लेसमेंट की आवश्यकता के। प्रत्येक डिस्पैचर के लिए यह Hex-Rays डीकम्पाइलर (जब उपलब्ध हो) का उपयोग करके स्विच-केस लेबल और `==`/`!=` तुलना स्थिरांक को सीधे पुनर्निर्मित नियंत्रण प्रवाह से पढ़ता है, IDA के स्विच-टेबल मेटाडेटा पर वापस आता है और फिर एक रॉ इमीडिएट-ऑपरेंड स्कैन पर। डीकम्पाइलर पथ उन कोड को पुनर्प्राप्त करता है जो डिसअसेंबली में कभी शाब्दिक रूप से प्रकट नहीं होते - जैसे ड्राइवर जिनके डिस्पैचर को कंपाइलर ने जंप टेबल (केवल तालिका आधार/बाउंड इमीडिएट के रूप में बचे हैं) या बाइनरी-सर्च तुलना ट्री (मध्यवर्ती कोड केवल डेल्टा के रूप में बचे हैं) के रूप में उत्सर्जित किया। एक प्रतिनिधि कॉर्पस पर इसने पुनर्प्राप्ति को 7/28 से 28/28 (HEVD) और 4/17 से 17/17 (ALSysIO64) तक बढ़ा दिया, बिना किसी गलत सकारात्मक के।
### फ़ंक्शनों को फ़्लैग करना
Driver Buddy Reloaded के पास C/C++ फ़ंक्शनों, opcodes और विंडोज़ API की सूचियाँ हैं (जो [vulnerable_function_lists](https://github.com/voidsec/driverbuddyreloaded/blob/main/DriverBuddyReloaded/vulnerable_functions_lists) निर्देशिका में परिभाषित हैं) जो सामान्यतः कमज़ोर होते हैं या बफर ओवरफ़्लो स्थितियों को सुविधाजनक बना सकते हैं। सभी पाए गए उदाहरण ऑटो-विश्लेषण के दौरान रिपोर्ट किए जाते हैं और संवेदनशील फ़ंक्शनों तक पहुँचने वाले संभावित उपयोगकर्ता-नियंत्रित कोड पथों की खोज करते समय मदद कर सकते हैं।
### DeviceName ढूँढना
टूल स्वचालित रूप से ड्राइवर के पंजीकृत डिवाइस पथों (`DeviceName`) को खोजने का प्रयास करता है, यदि बाइनरी के अंदर यूनिकोड स्ट्रिंग्स को देखकर कोई पथ नहीं मिलता है, तो विश्लेषक मैन्युअल रूप से Madiant के [FLOSS](https://github.com/mandiant/flare-floss/) का उपयोग करके अस्पष्ट पथों को खोजने का प्रयास कर सकता है।
### Pooltags डंप करना
ऑटो-विश्लेषण के दौरान, टूल बाइनरी द्वारा उपयोग किए जाने वाले `Pooltags` को एक प्रारूप में भी डंप करता है जो `pooltags.txt` के साथ काम करता है। आउटपुट को फ़ाइल के अंत में कॉपी-पेस्ट किया जा सकता है और बाद में WinDbg द्वारा उठाया जा सकता है।
- IDA के DB निर्देशिका के अंतर्गत एक `DriverName.sys-DATE-TIME_STAMP-pooltags.txt` फ़ाइल लिखी जाएगी, जिसमें सभी डंप किए गए Pooltags होंगे।
### ह्यूरिस्टिक भेद्यता जाँच
`heuristics.py` मॉड्यूल कॉल-चेन ट्रेसिंग के बाद चलता है और प्रत्येक डिस्पैचर **और इसके द्वारा सकर्मक रूप से कॉल किए गए फ़ंक्शनों** की जाँच करता है - इसलिए प्रति-IOCTL हैंडलर, न कि केवल डिस्पैचर प्रस्तावना, का विश्लेषण किया जाता है। कैली मिलान आयात-जागरूक है (एक आयातित `call cs:__imp_<Name>` उसी नाम से मेल खाता है जैसे एक स्थानीय कॉल)। यह **ह्यूरिस्टिक** श्रेणी में निष्कर्ष उत्सर्जित करता है (विशेषाधिकार-निर्देश निष्कर्ष **opcode** श्रेणी का उपयोग करते हैं):
| जाँच | क्या फ़्लैग किया गया है | गंभीरता |
|---|---|---|
| अमान्य उपयोगकर्ता कॉपी | `memcpy`/`RtlCopyMemory`/आदि जिसके पास `ProbeForRead`/`ProbeForWrite`/सुरक्षित-स्ट्रिंग गार्ड नहीं है | उच्च (हैंडलर), मध्यम (अन्य) |
| TOCTOU / डबल फ़ेच | एक उपयोगकर्ता-मोड पॉइंटर फ़ील्ड को एक नियंत्रण-प्रवाह पथ पर बिना बीच में `ProbeForRead` के पुनः पढ़ा जाता है (केवल METHOD_NEITHER हैंडलर पर, ताकि कर्नेल-बफर पुनः पढ़ने को फ़्लैग न किया जाए) | मध्यम |
| उपयोग-पश्चात-मुक्त | एक मुक्त किया गया पॉइंटर इंट्रा-फंक्शन (रजिस्टर CFG वॉक) पुनः उपयोग किया जाता है, या एक ग्लोबल को बिना शून्य किए मुक्त किया जाता है और फिर किसी अन्य फ़ंक्शन से डीरेफरेंस किया जाता है | उच्च |
| गायब विशेषाधिकार गेट | एक संवेदनशील op (`ZwOpenProcess`/`MmMapIoSpace`/PCI-कॉन्फ़िग/आदि) एक डिस्पैचर से पहुँच योग्य है जिसके पथ पर कहीं भी `SeAccessCheck`/`SeSinglePrivilegeCheck`/टोकन जाँच नहीं है | उच्च |
| IRQL बेमेल | पेजेबल / `Zw*` / `MmMap*` कॉल जब एक IRQL-बढ़ाने वाला फ़ंक्शन भी मौजूद है | मध्यम |
| असुरक्षित MDL मैपिंग | `MmMapLockedPages`/`MmProbeAndLockPages`/आदि जिसमें डिसअसेंबली में `UserMode` है | उच्च, अन्यथा मध्यम |
| स्टैक आवंटन | `_alloca`/`_malloca`/`_chkstk` कॉल (बड़ा या गतिशील स्टैक आवंटन) | निम्न |
| आकार सत्यापन के बिना पूल आवंटन | `ExAllocatePool*` कॉल जिसके पास सुरक्षित-अंकगणित गार्ड नहीं है (पूर्णांक-ओवरफ़्लो-पहले-आवंटन पैटर्न) | उच्च |
| विशेषाधिकार प्राप्त निर्देश | पोर्ट I/O (`in`/`out`), नियंत्रण/डीबग-रजिस्टर मूव (`mov cr*`/`mov dr*`), डिस्क्रिप्टर-टेबल लोड, `cli`/`sti`/`hlt` एक हैंडलर से पहुँच योग्य (BYOVD हार्डवेयर-एक्सेस प्रिमिटिव) | गंभीर (`out`) / उच्च (`in`) / मध्यम |
| आर्बिट्ररी राइट (राइट-व्हाट-व्हेयर) | एक डबल-डीरेफरेंस किए गए उपयोगकर्ता पॉइंटर `*(*p) = c` के माध्यम से एक स्टोर; एक नियंत्रित कॉपी `*p = *q` को कमज़ोर लीड के रूप में रिपोर्ट किया जाता है | उच्च / मध्यम |
| `\Device\PhysicalMemory` संदर्भ | भौतिक मेमोरी डिवाइस ऑब्जेक्ट स्ट्रिंग का क्रॉस-रेफरेंस (BYOVD पैटर्न `ZwOpenSection`/`ZwMapViewOfSection` के माध्यम से) | उच्च (हैंडलर), मध्यम (अन्य) |
ये **लीड जनरेटर** हैं, पुष्टि की गई भेद्यताएँ नहीं। उच्च/गंभीर निष्कर्षों को मैन्युअल समीक्षा के लिए प्रारंभिक बिंदु मानें।
## फीचर फ़्लैग
सभी वैकल्पिक विश्लेषण चरण `DriverBuddyReloaded/config.py` द्वारा नियंत्रित होते हैं। उन्हें सक्षम या अक्षम करने के लिए `Feature` वर्ग को संपादित करें:
| फ़्लैग | डिफ़ॉल्ट | विवरण |
|---|---|---|
| `IOCTL_SCAN` | `True` | IOCTL खोजें और डिकोड करें (डिस्पैचर स्कैन + `IoControlCode` फॉलबैक) |
| `IOCTL_DECOMPILER` | `True` | डिस्पैचर स्कैन में Hex-Rays ctree का उपयोग करें (जंप-टेबल / बाइनरी-सर्च कोड पुनर्प्राप्त करता है) |
| `HEURISTICS` | `True` | ह्यूरिस्टिक भेद्यता जाँच (ऊपर तालिका देखें) |
| `TOCTOU_CHECK` | `True` | डबल-फ़ेच / TOCTOU ह्यूरिस्टिक |
| `UAF_DETECT` | `True` | उपयोग-पश्चात-मुक्त ह्यूरिस्टिक्स (इंट्रा-फंक्शन रजिस्टर वॉक + क्रॉस-फंक्शन ग्लोबल) |
| `ACL_AUDIT` | `True` | दुनिया-सुलभ `IoCreateDevice` / कमज़ोर `IoCreateDeviceSecure` SDDL को फ़्लैग करें |
| `SYMLINK_TRACK` | `True` | `IoCreateSymbolicLink` लक्ष्य पथों को डिकोड करें |
| `CALLCHAIN` | `True` | हैंडलर से खतरनाक सिंक तक BFS कॉल-चेन ट्रेसिंग |
| `EXPORTS_AUDIT` | `True` | शून्य आंतरिक क्रॉस-रेफरेंस वाले ड्राइवर एक्सपोर्ट को फ़्लैग करें |
| `POOLTAG_FALLBACK` | `True` | रजिस्टर-प्रोपेगेटेड पूल टैग स्कैनर (जब आयात-आधारित स्कैन कुछ नहीं पाता है तो उपयोग किया जाता है) |
| `IRP_MJ_ENUM` | `True` | `IRP_MJ_FUNCTION` IDA एनम बनाएँ और `MajorFunction` स्लॉट्स पर लागू करें (केवल WDM) |
| `RISK_SCORING` | `True` | IOCTL जोखिम स्कोरिंग (METHOD/ACCESS भार + प्रति-हैंडलर सिंक बढ़ावा) |
| `RESULTS_WINDOW` | `True` | विश्लेषण के बाद Driver Buddy Reloaded findings विंडो दिखाएँ |
| `JSON_EXPORT` | `True` | `findings.json` लिखें |
| `HTML_REPORT` | `True` | `report.html` लिखें |
| `SEGMENT_OPCODE_SCAN` | `False` | रेखीय खंड-व्यापी opcode स्कैन (शोरगुल, डिफ़ॉल्ट रूप से बंद) |
## परीक्षण
तीन परतें, तेज़ से गहन तक:
- **शुद्ध-पायथन प्रतिगमन** (कोई IDA आवश्यक नहीं) - उस सभी तर्क को कवर करता है जो लाइव डेटाबेस को स्पर्श नहीं करता: ```
python tests/test_dbr.py
DBR_SDK=900 python tests/test_dbr.py # simulate the IDA 9.0 import paths
.sys फ़ाइलों के मैट्रिक्स पर पूर्ण पाइपलाइन चलाता है और पास/फेल तालिका प्रिंट करता है: pwsh tests/run_cross_version.ps1.pwsh tests/run_golden.ps1 tests/drivers/ में प्रत्येक संदर्भ ड्राइवर की एक मूल प्रति पर पूर्ण विश्लेषण पुनः चलाता है और निष्कर्षों की तुलना प्रतिबद्ध tests/drivers/<driver>.golden.json बेसलाइन से करता है (श्रेणी, शीर्षक, गंभीरता और IOCTL कोड/विधि/पहुंच पर क्रम-असंवेदनशील)। कोई भी जोड़ा गया निष्कर्ष (गलत सकारात्मक), लापता निष्कर्ष (गलत नकारात्मक) या गंभीरता में बदलाव रन को विफल कर देता है। गोल्डन को केवल तभी पुनर्जीवित करें जब कोई परिवर्तन जानबूझकर निष्कर्षों को बदलता है, और अंतर की समीक्षा करें। गोल्डन उस IDA डीकंपाइलर बिल्ड से बंधे होते हैं जिसके साथ वे कैप्चर किए गए थे (8.4), इसलिए उस संस्करण के साथ प्रतिगमन चलाएं।_is_valid_ctl_code() द्वारा CTL_CODE संरचना के विरुद्ध मान्य किया जाता है: DeviceType फ़ील्ड (बिट्स 31-16) शून्य नहीं होना चाहिए, और मान किसी ज्ञात NTSTATUS कोड या 0xFFFFFFFF (DWORD)-1 सेंटिनल (वास्तविक डिस्पैचर्स में देखा गया एक तुलना स्थिरांक, उदा. WinRing0) से मेल नहीं खाना चाहिए। यह लूप काउंटर, छोटे तत्काल मान और त्रुटि कोड को बाहर करता है, जबकि विक्रेता-परिभाषित डिवाइस प्रकारों (0x8000+) सहित सभी मान्य IOCTL को संरक्षित करता है। वही फ़िल्टर सभी चार खोज पथों पर लागू किया जाता है: IoControlCode xref स्कैन और तीन डिस्पैचर संग्राहक (डीकंपाइलर ctree, IDA स्विच-टेबल पुनर्प्राप्ति, और कच्चा तत्काल-ऑपरेंड स्कैन)।DriverBuddyReloaded/config.py में स्थित हैं।DispatchDeviceControl खोज केवल x64 ड्राइवरों के लिए काम करती हैfind_opcode_data विकल्प (डिफ़ॉल्ट False) डेटा अनुभागों में आने वाले ऑपकोड मैचों को दबा देता है। इसे True पर स्विच करने से डेटा में रॉ बाइट मैच भी सामने आते हैं, जो गलत सकारात्मकता के लिए प्रवण होते हैं; यदि कोई वास्तविक ऑपकोड छूट गया था, तो रिपोर्ट किए गए पते पर जाकर और बाइट्स को कोड के रूप में पुनर्परिभाषित करने से आमतौर पर यह पुनर्प्राप्त हो जाता है। मैच अन्य सभी चरणों की तरह रिपोर्ट किए जाते हैं (परिणाम विंडो, findings.json, report.html)।