Mora-HWBP — हार्डवेयर ब्रेकपॉइंट्स के माध्यम से AMSI / WLDP / ETW टेलीमेट्री हुकिंग

एक सुरक्षा-अनुसंधान प्रूफ-ऑफ-कॉन्सेप्ट (POC) जो पारंपरिक इन-मेमोरी कोड पैचिंग के विकल्प के रूप में हार्डवेयर-ब्रेकपॉइंट (CPU डिबग रजिस्टर) आधारित फ़ंक्शन हुकिंग को प्रदर्शित करता है।

उद्देश्य और दायरा

यह रिपॉजिटरी Windows इंटरनल के केवल रक्षात्मक सुरक्षा अनुसंधान, red-team/purple-team शिक्षा, डिटेक्शन इंजीनियरिंग, और शैक्षणिक अध्ययन के लिए प्रकाशित की गई है। यह प्रदर्शित करती है कि कैसे एक हमलावर यूज़र-मोड सुरक्षा टेलीमेट्री को निष्क्रिय करने के लिए प्रोसेसर डिबग रजिस्टरों का दुरुपयोग कर सकता है — और, उतना ही महत्वपूर्ण, रक्षकों को किस पर नज़र रखनी चाहिए ताकि ऐसी तकनीकों का पता लगाया जा सके। लेखक इस कोड के किसी भी दुरुपयोग के लिए जिम्मेदार नहीं है। स्पष्ट प्राधिकरण के बिना सिस्टम के विरुद्ध इस तकनीक का उपयोग अवैध है और अधिकांश क्षेत्राधिकारों में प्रासंगिक कंप्यूटर-धोखाधड़ी और दुरुपयोग कानूनों का उल्लंघन करता है। इसे किसी भी ऐसे वातावरण में तैनात न करें जिसके स्वामी आप नहीं हैं या जिसके परीक्षण के लिए आपके पास स्पष्ट लिखित अनुमति नहीं है।

विषय-सूची

1. अवलोकन
2. पृष्ठभूमि — हार्डवेयर ब्रेकपॉइंट्स क्यों?
3. लक्षित सुरक्षा घटक
4. आर्किटेक्चर
5. तकनीकी गहराई से विश्लेषण
   • 5.1 x64 पर हार्डवेयर ब्रेकपॉइंट्स
   • 5.2 डिबग रजिस्टर लेआउट (DR0–DR7)
   • 5.3 वेक्टरेड एक्सेप्शन हैंडलर (VEH)
   • 5.4 प्रति-घटक इंटरसेप्शन तर्क
   • 5.5 थ्रेड प्रबंधन और हुक स्थिरता
6. निर्यात किए गए API
7. बिल्ड निर्देश
8. इंजेक्शन और उपयोग उदाहरण
9. पहचान और शमन (ब्लू टीम)
10. ज्ञात सीमाएँ
11. संदर्भ

अवलोकन

mora_hwbp.c एक DLL लागू करता है जो, एक बार किसी लक्षित प्रक्रिया (जैसे PowerShell होस्ट) में लोड/इंजेक्ट हो जाने पर, प्रक्रिया के हर थ्रेड के आर्किटेक्चरल डिबग रजिस्टर (DR0–DR7) में संग्रहीत CPU हार्डवेयर ब्रेकपॉइंट्स के माध्यम से विशेष रूप से चार यूज़र-मोड फ़ंक्शनों को हुक करता है:

एक प्रति-प्रक्रिया वेक्टरेड एक्सेप्शन हैंडलर (VEH) डिबग रजिस्टरों द्वारा उठाए गए EXCEPTION_SINGLE_STEP (0x80000004) फॉल्ट्स को प्राप्त करता है, एक्सेप्शन कॉन्टेक्स्ट को पुनः लिखकर मूल फ़ंक्शन के सफल रिटर्न पथ का अनुकरण करता है, और निष्पादन फिर से शुरू करता है — यह सब निष्पादन योग्य मेमोरी के एक भी बाइट को संशोधित किए बिना।

यह तकनीक को आक्रामक और रक्षात्मक दोनों दृष्टिकोणों से विशेष रूप से दिलचस्प बनाता है:

• आक्रामक रूप से, यह संशोधित .text अनुभागों की तलाश करने वाली EDR/HIPS अखंडता जाँचों को बायपास करता है (क्लासिक इनलाइन हुकिंग, EAT/IAT पैचिंग, या Etwp* स्टबिंग)।
• रक्षात्मक रूप से, हार्डवेयर ब्रेकपॉइंट्स अत्यधिक विशिष्ट फोरेंसिक कलाकृतियाँ छोड़ते हैं (डिबग रजिस्टर सामग्री, सिंगल-स्टेप एक्सेप्शन घनत्व, VEH पंजीकरण, GetThreadContext/SetThreadContext सिस्कॉल पैटर्न) जिनका उपयोग पहचान के लिए किया जा सकता है।

पृष्ठभूमि — हार्डवेयर ब्रेकपॉइंट्स क्यों?

पारंपरिक यूज़र-मोड हुकिंग दृष्टिकोण — इनलाइन डिटोर्स (5–14 बाइट ओवरराइट), इम्पोर्ट एड्रेस टेबल (IAT) हुकिंग, और एक्सपोर्ट एड्रेस टेबल (EAT) हुकिंग — एक सामान्य कमज़ोरी साझा करते हैं: वे उस मेमोरी को संशोधित करते हैं जिसे अखंडता स्कैनर और ETW देख सकते हैं।

आधुनिक AV/EDR उत्पाद निम्नलिखित लागू करते हैं:

• PowerShell और .NET CLR बफ़र्स की मेमोरी स्कैनिंग / AMSI स्कैन;
• ETW-आधारित टेलीमेट्री (Microsoft-Windows-PowerShell, .NET ETW, थ्रेट इंटेलिजेंस प्रोवाइडर);
• कर्नेल कॉलबैक और यूज़र-मोड अखंडता जाँच जो pageguard/guard-page ट्रिक्स, VirtualProtect द्वारा PAGE_EXECUTE_READWRITE में ट्रांज़िशन, और सेक्शन हैश मिसमैच का पता लगाती हैं।

हार्डवेयर ब्रेकपॉइंट्स इन सबको दरकिनार कर देते हैं:

1. वे CPU रजिस्टर हैं, मेमोरी नहीं — .text में स्कैन करने के लिए कुछ भी नहीं है।
2. वे Windows API SetThreadContext के माध्यम से प्रति-थ्रेड आधार पर सेट किए जाते हैं, जो अखंडता स्कैनर द्वारा उपयोग किए जाने वाले क्लासिक "मेमोरी संशोधित" सिग्नल को ट्रिगर नहीं करता है।
3. इंटरसेप्शन बिंदु पूरी तरह से प्रोसेसर के एक्सेप्शन डिस्पैच द्वारा संभाला जाता है, जो किसी भी यूज़र-मोड लक्षित फ़ंक्शन के निष्पादन से पहले प्रक्रिया की VEH श्रृंखला से होकर गुजरता है।

यह POC इस तकनीक की प्रभावकारिता और पहचान-क्षमता की खोज करता है AMSI (एंटीमैलवेयर स्कैन इंटरफ़ेस), WLDP (Windows लॉकडाउन पॉलिसी), और ETW (Windows के लिए इवेंट ट्रेसिंग) के विरुद्ध — आधुनिक Windows सुरक्षा स्टैक में सबसे अधिक भरोसेमंद तीन यूज़र-मोड सुरक्षा प्राइमिटिव।

लक्षित सुरक्षा घटक

AMSI — एंटीमैलवेयर स्कैन इंटरफ़ेस

AMSI Windows प्लेटफ़ॉर्म एकीकरण बिंदु है जो अनुप्रयोगों (PowerShell, Office, VBScript, .NET होस्ट, आदि) को पंजीकृत एंटीमैलवेयर प्रदाताओं से सामग्री स्कैनिंग का अनुरोध करने की अनुमति देता है। प्राथमिक रुचि के दो एंट्री पॉइंट हैं:

• AmsiScanBuffer(HANDLE hamsiContext, PVOID buffer, ULONG length, LPCWSTR contentName, HANDLE hamsiSession, AMSI_RESULT *pResult)
• AmsiScanString(HANDLE hamsiContext, LPCWSTR string, LPCWSTR contentName, HANDLE hamsiSession, AMSI_RESULT *pResult)

लौटाए गए AMSI_RESULT को AMSI_RESULT_CLEAN (0) पर बाध्य करके, स्क्रिप्ट इंजन मानता है कि सामग्री का निरीक्षण किया गया और वह हानिरहित पाई गई, इसलिए निष्पादन बिना रुकावट जारी रहता है।

WLDP — Windows लॉकडाउन पॉलिसी

WLDP Windows डिफेंडर एप्लिकेशन कंट्रोल (WDAC / Device Guard) के लिए पॉलिसी मूल्यांकन लागू करता है। WldpIsClassInApprovedList उत्तर देता है कि क्या वर्तमान पॉलिसी के तहत कोई दिया गया COM क्लास (GUID द्वारा पहचाना गया) अनुमत है। AMSI आंतरिक रूप से यह तय करने के लिए WLDP से परामर्श करता है कि क्या कुछ स्क्रिप्ट/सामग्री क्लास "विश्वसनीय" हैं (अनुमोदित सूची में)। यदि फ़ंक्शन क्लास को अनुमोदित बताता है, तो AMSI उस सामग्री प्रकार के लिए अतिरिक्त जाँच को छोड़ सकता है।

DLL isApproved आउटपुट पैरामीटर (RDX) को TRUE पर सेट करता है और S_OK लौटाता है, जिससे मूल्यांकित क्लास विश्वसनीय प्रतीत होती है।

ETW — Windows के लिए इवेंट ट्रेसिंग

ntdll.dll में EtwEventWrite सिस्टम पर लगभग सभी ETW इवेंट उत्सर्जन के लिए मुख्य यूज़र-मोड सिंक है। इसे दबाने के सुरक्षा निगरानी से संबंधित व्यापक दुष्प्रभाव हैं:

• PowerShell पाइपलाइन और स्क्रिप्ट-ब्लॉक लॉगिंग इवेंट
• .NET असेंबली लोड इवेंट (Microsoft-Windows-DotNETRuntime)
• AMSI स्कैन-परिणाम टेलीमेट्री
• थ्रेट-इंटेलिजेंस प्रोवाइडर इवेंट जो EDR एजेंटों द्वारा उपभोग किए जाते हैं

DLL वास्तविक फ़ंक्शन को निष्पादित किए बिना केवल ERROR_SUCCESS (0) लौटाता है।

आर्किटेक्चर```

┌──────────────────────────────────────────────────────────────────────────┐ │ Target Process (e.g. powershell.exe) │ │ │ │ ┌──────────────────────────┐ ┌──────────────────────────────────┐│ │ │ mora_hwbp.dll │ │ CPU / Windows ││ │ │ │ │ ││ │ │ DllMain / InstallHook │ │ Thread A Thread B ││ │ │ │ │ │ ┌────────┐ ┌────────┐ ││ │ │ ▼ │ │ │ DR0..3 │ │ DR0..3 │ ││ │ │ Resolve exports │ │ └────────┘ └────────┘ ││ │ │ (amsi/wldp/ntdll) │ │ ││ │ │ │ │ │ #DB (single-step) ││ │ │ ▼ │ │ exception ──► Windows Dispatch ││ │ │ AddVectoredException │ │ │ ││ │ │ Handler(VEH) │ │ ▼ ││ │ │ │ │ │ ┌─────────────────────────────┐ ││ │ │ ▼ │ │ │ VectoredHandler (ours) │ ││ │ │ SetHwbpOnThread(ALL) │ │ │ • match #DB address │ ││ │ │ │ │ │ │ • rewrite context (RIP/RSP)│ ││ │ │ ▼ │ │ │ • spoof return value (RAX) │ ││ │ │ MonitorThread ◄──┐ │ │ │ • continue execution │ ││ │ │ (re-hook every │ │ │ └─────────────────────────────┘ ││ │ │ 500ms) └──────┘ │ ││ │ └──────────────────────────┘ └──────────────────────────────────┘│ └──────────────────────────────────────────────────────────────────────────┘

**उच्च-स्तरीय प्रवाह:**

1. DLL को लक्षित प्रक्रिया में लोड किया जाता है (किसी भी इंजेक्शन तकनीक के माध्यम से — देखें [उपयोग](#injection--usage-example))।
2. `DLL_PROCESS_ATTACH` पर (या निर्यात किए गए `InstallHook` के माध्यम से), लक्षित एक्सपोर्ट्स को `GetProcAddress` के साथ हल किया जाता है (वैकल्पिक रूप से `LoadLibraryW` के माध्यम से मॉड्यूल लोड को बाध्य करके)।
3. एक **Vectored Exception Handler** को प्रक्रिया में **पहले** हैंडलर के रूप में पंजीकृत किया जाता है (`AddVectoredExceptionHandler(1, ...)`)।
4. **वर्तमान थ्रेड** को तुरंत हुक किया जाता है, फिर प्रक्रिया में **सभी मौजूदा थ्रेड्स** की गणना `CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, 0)` के माध्यम से की जाती है और उन्हें हुक किया जाता है।
5. एक **मॉनिटर थ्रेड** हर 500 ms पर जागता है और ब्रेकपॉइंट्स को हर थ्रेड पर पुनः लागू करता है — जिसमें **नव निर्मित थ्रेड्स** भी शामिल हैं — जिससे हुक की स्थिरता सुनिश्चित होती है, भले ही हुकिंग के बाद कोई थ्रेड बनाया जाए या ब्रेकपॉइंट्स को बाहरी रूप से साफ़ कर दिया जाए।
6. जब किसी भी थ्रेड पर कोई हुक किया गया फ़ंक्शन कॉल किया जाता है, तो CPU एक `#DB` सिंगल-स्टेप अपवाद उठाता है; Windows इसे VEH को भेजता है, जो एक सामान्य रिटर्न का अनुकरण करता है और निष्पादन जारी रखता है।

### नमूना डिबग आउटपुट

![Sysinternals DebugView में कैप्चर किए गए HWBP इंजन हुक स्थिति निदान](https://assets.kitploit.com/production/public/readmes/50594/5cf99fadc07272ff598cbb9486ff7803a3234eb6aeaa8202684c27e97bd7e161.png)

*चित्र 1 — Sysinternals DebugView से कैप्चर किया गया नमूना निदान आउटपुट। प्रत्येक पंक्ति संबंधित डिबग रजिस्टर के लिए हल किया गया लक्ष्य पता और लाइव हिट काउंटर दर्शाती है।*

---

## तकनीकी गहन विवरण

### 5.1 x64 पर हार्डवेयर ब्रेकपॉइंट्स

x86/x64 पर, प्रत्येक CPU **चार हार्डवेयर डिबग-एड्रेस रजिस्टर** (`DR0`–`DR3`) और एक कंट्रोल रजिस्टर (`DR7`) प्रदान करता है। `DR0`–`DR3` में गैर-शून्य ब्रेकपॉइंट के साथ निष्पादित होने वाला कोई भी थ्रेड तब फॉल्ट करेगा जब इंस्ट्रक्शन पॉइंटर उस पते पर पहुँचता है (या डेटा एक्सेस कॉन्फ़िगर की गई शर्तों से मेल खाता है)। स्टेटस रजिस्टर `DR6` रिकॉर्ड करता है कि कौन सा ब्रेकपॉइंट फायर हुआ।

हार्डवेयर ब्रेकपॉइंट **संदर्भ-संवेदनशील** होते हैं: वे थ्रेड की `CONTEXT` संरचना में संग्रहीत होते हैं और केवल उसी थ्रेड पर लागू होते हैं जिस पर वे सेट किए गए हैं। यही कारण है कि एक मजबूत कार्यान्वयन को प्रक्रिया के **हर थ्रेड** पर ब्रेकपॉइंट सेट करने चाहिए (और नए थ्रेड्स के लिए उन्हें लगातार पुनः लागू करना चाहिए)।

### 5.2 डिबग रजिस्टर लेआउट (DR0–DR7)

`DR7` एक बिटफ़ील्ड है जो ब्रेकपॉइंट सक्षमता और व्यवहार को नियंत्रित करता है:

| बिट्स | फ़ील्ड | अर्थ                                             |
|--------|--------|-----------------------------------------------------|
| `0`    | `L0`   | ब्रेकपॉइंट 0 (DR0) के लिए लोकल सक्षम                 |
| `2`    | `L1`   | ब्रेकपॉइंट 1 (DR1) के लिए लोकल सक्षम                 |
| `4`    | `L2`   | ब्रेकपॉइंट 2 (DR2) के लिए लोकल सक्षम                 |
| `6`    | `L3`   | ब्रेकपॉइंट 3 (DR3) के लिए लोकल सक्षम                 |
| `8`    | `LE`   | लीगेसी लोकल सक्षम (संगतता के लिए रखा गया)        |
| `9`    | `GE`   | लीगेसी वैश्विक सक्षम (संगतता के लिए रखा गया)       |
| `16–17`| `R/W0` | BP0 के लिए एक्सेस प्रकार (`00` = इंस्ट्रक्शन निष्पादन)  |
| `18–19`| `Len0` | BP0 के लिए लंबाई (`00` = 1 बाइट)                      |
| `20–21`| `R/W1` | BP1 के लिए एक्सेस प्रकार (`00` = इंस्ट्रक्शन निष्पादन)  |
| `22–23`| `Len1` | BP1 के लिए लंबाई (`00` = 1 बाइट)                      |
| `24–25`| `R/W2` | BP2 के लिए एक्सेस प्रकार (`00` = इंस्ट्रक्शन निष्पादन)  |
| `26–27`| `Len2` | BP2 के लिए लंबाई (`00` = 1 बाइट)                      |
| `28–29`| `R/W3` | BP3 के लिए एक्सेस प्रकार (`00` = इंस्ट्रक्शन निष्पादन)  |
| `30–31`| `Len3` | BP3 के लिए लंबाई (`00` = 1 बाइट)                      |

सभी चार ब्रेकपॉइंट **एकल बाइट पर निष्पादन (इंस्ट्रक्शन-फ़ेच)** के लिए कॉन्फ़िगर किए गए हैं, जो फ़ंक्शन-एंट्री हुक्स के लिए उपयुक्त स्थिति है।

### 5.3 वेक्टर्ड एक्सेप्शन हैंडलर (VEH)

जब ब्रेकपॉइंट ट्रिगर होता है, तो प्रोसेसर एक `#DB` अपवाद उठाता है। x64 Windows पर `ntdll` डिस्पैच रूटीन इसे थ्रेड की Structured Exception Handler (SEH) श्रृंखला से पहले प्रक्रिया-व्यापी **VEH श्रृंखला** से गुज़ारती है। इस प्रोजेक्ट में हैंडलर:

1. **फ़िल्टर** — केवल `EXCEPTION_SINGLE_STEP` (`0x80000004`) को संभालता है; बाकी सब `EXCEPTION_CONTINUE_SEARCH` पर छोड़ दिया जाता है।
2. **मिलान** — `ExceptionAddress` की तुलना चार ज्ञात फ़ंक्शन पतों से करता है।
3. **संदर्भ को फिर से लिखता है**:
   - `RIP = *(RSP)` → मूल कॉलर पर "वापसी" करने के लिए रिटर्न पता पॉप करता है।
   - `RSP += 8` → एक `ret` का अनुकरण करता है (x64 सिंगल-इंस्ट्रक्शन अनवाइंड)।
   - `RAX = 0` → `S_OK` / `ERROR_SUCCESS` (सफल रिटर्न कोड) का दिखावा करता है।
   - `DR6 &= ~0xF` → ब्रेकपॉइंट स्टेटस बिट्स को साफ़ करता है ताकि इंस्ट्रक्शन को बाद में बिना गलत स्थिति के पुनः निष्पादित किया जा सके।
4. **आउट-पैरामीटर बदलता है** (देखें [5.4](#54-per-component-interception-logic))।
5. **`EXCEPTION_CONTINUE_EXECUTION` लौटाता है**, जो Windows को संशोधित संदर्भ के साथ थ्रेड को पुनः आरंभ करने के लिए कहता है — अर्थात, निष्पादन *कॉलर* पर फिर से शुरू होता है, और वास्तविक लक्ष्य फ़ंक्शन **कभी नहीं चलता**।

प्रत्येक इंटरसेप्शन साइट को अतिरिक्त रूप से एक SEH `__try/__except` गार्ड में लपेटा जाता है ताकि एक विकृत या अप्रत्याशित स्टैक लेआउट प्रक्रिया को क्रैश न कर सके — यह प्रतिकूल/कठोर (हार्डन्ड) लक्ष्यों के लिए एक मजबूती संबंधी विचार है।

### 5.4 प्रति-घटक इंटरसेप्शन लॉजिक

**DR0 — `AmsiScanBuffer`** (x64, पहले 6 आर्ग्स `RCX, RDX, R8, R9, [RSP+0x28], [RSP+0x30]` में):```
HRESULT AmsiScanBuffer(HANDLE, PVOID, ULONG, LPCWSTR, HANDLE, AMSI_RESULT* pResult);
                                                        [RSP+0x28]  [RSP+0x30]

• AMSI_RESULT_CLEAN (0) को छठे पैरामीटर (pResult, [RSP+0x30] पर) में लिखता है।
• RAX में S_OK (0) लौटाता है।

DR1 — AmsiScanString (x64, पहले 5 आर्ग्युमेंट RCX, RDX, R8, R9, [RSP+0x28] में):``` HRESULT AmsiScanString(HANDLE, LPCWSTR, LPCWSTR, HANDLE, AMSI_RESULT* pResult); [RSP+0x28]

- `AMSI_RESULT_CLEAN (0)` को 5वें पैरामीटर (`pResult`, `[RSP+0x28]` पर) में लिखता है।
- `RAX` में `S_OK (0)` लौटाता है।

**DR2 — `WldpIsClassInApprovedList`** (`RCX, RDX, R8` में पहले 3 तर्क):```
HRESULT WldpIsClassInApprovedList(const GUID* classId, PBOOL isApproved, DWORD evalCriteria);
                                         RCX             RDX             R8

• TRUE को *isApproved में लिखता है (RDX के माध्यम से)।
• RAX में S_OK (0) लौटाता है।
• परिणाम: मूल्यांकित सामग्री वर्ग को lockdown नीति द्वारा "अनुमोदित" माना जाता है, और AMSI उस वर्ग के लिए उस निर्णय पर भरोसा करता है।

DR3 — EtwEventWrite (RCX, RDX, R8, R9 में पहले 4 तर्क):``` ULONG EtwEventWrite(HANDLE RegHandle, PCEVENT_DESCRIPTOR EventDescriptor, ULONG UserDataCount, PEVENT_DATA_DESCRIPTOR UserData);

- `RAX` में `ERROR_SUCCESS (0)` लौटाता है, बिना किसी आउटपुट पैरामीटर को छुए।
- परिणाम: हुक किए गए प्रोसेस से ETW प्रोवाइडरों को **कोई** इवेंट प्राप्त नहीं होते, जिससे स्क्रिप्ट निष्पादन, मॉड्यूल लोड, प्रोसेस निर्माण और AMSI टेलीमेट्री की लॉगिंग दब जाती है।

### 5.5 थ्रेड प्रबंधन और हुक निरंतरता

क्योंकि डीबग रजिस्टर प्रति-थ्रेड होते हैं, इंजन को हुकों को निरंतर बनाए रखना चाहिए:

1. **तत्काल हुकिंग** — `DllMain` (या `InstallHook`) कॉल करने वाले थ्रेड को `SetHwbpOnThread(GetCurrentThread())` के साथ हुक करता है।
2. **सभी-थ्रेड स्वीप** — `HookAllThreads()` `TH32CS_SNAPTHREAD` स्नैपशॉट के माध्यम से प्रोसेस में हर थ्रेड की गणना करता है, प्रत्येक बाहरी थ्रेड को निलंबित करता है (`SuspendThread`), ब्रेकपॉइंट लागू करता है (`SetHwbpOnThread`), फिर उसे फिर से शुरू करता है और हैंडल बंद करता है। निलंबन उस रेस स्थिति को रोकता है जिसमें थ्रेड `GetThreadContext` और `SetThreadContext` के बीच कॉन्टेक्स्ट-स्वैप के दौरान फॉल्ट कर सकता है।
3. **निरंतरता मॉनिटर** — `MonitorThreadProc` `Sleep(500)` के साथ लूप करता है और हर 500 मिलीसेकंड में `HookAllThreads()` को कॉल करता है। यह **किसी भी हटाए गए ब्रेकपॉइंट को फिर से सक्रिय करता है** (जैसे, बाहरी `SetThreadContext` कॉल, डीबगिंग टूल, या थ्रेड टियरडाउन/निर्माण के कारण) और **प्रारंभिक हुक के बाद बनाए गए थ्रेड्स को कवर करता है**।
4. **सिंक्रनाइज़ेशन** — `HookAllThreads` एक `CRITICAL_SECTION` (`g_HookLock`) के अंतर्गत चलता है ताकि मॉनिटर थ्रेड और प्रारंभिक हुकिंग रूटीन कभी भी कॉन्टेक्स्ट स्विच को आपस में न मिला सकें।
5. **स्वच्छ टियरडाउन** — `UninstallHook` मॉनिटर को रोकता है, हर थ्रेड पर `DR0–DR7` साफ़ करता है, और VEH का पंजीकरण रद्द करता है।

> **"हुक निरंतरता" प्रश्न का स्पष्ट उत्तर:** हाँ — यदि किसी भी थ्रेड से ब्रेकपॉइंट हटा दिए जाते हैं (किसी अन्य एजेंट, डीबगर, या EDR द्वारा), तो मॉनिटर थ्रेड **उन्हें 500 मिलीसेकंड के भीतर पुनः लागू कर देता है**। इसके अलावा, DLL लोड होने के बाद बनाया गया कोई भी थ्रेड एक मॉनिटर चक्र के भीतर हुक हो जाता है। इस विशिष्ट इंजन को हराने का एकमात्र विश्वसनीय तरीका मॉनिटर थ्रेड को समाप्त करना *और* VEH को साफ़ करना *और* रजिस्टरों को उसी समय-विंडो में हटाना है — या एंटी-डीबगिंग का उपयोग करना जो शुरू से ही `SetThreadContext` को अस्वीकार कर दे।

---

## निर्यातित API

| निर्यात            | सिग्नेचर                          | व्यवहार                                                              |
|-------------------|------------------------------------|-----------------------------------------------------------------------|
| `InstallHook`     | `BOOL WINAPI InstallHook(void)`    | लक्ष्यों को हल करता है, VEH पंजीकृत करता है, सभी थ्रेड्स को हुक करता है, मॉनिटर शुरू करता है। |
| `UninstallHook`   | `BOOL WINAPI UninstallHook(void)`  | मॉनिटर रोकता है, सभी थ्रेड्स पर ब्रेकपॉइंट साफ़ करता है, VEH हटाता है। |
| `GetStats`        | `void WINAPI GetStats(void)`       | वर्तमान हुक स्थिति जारी करता है (`OutputDebugStringA` के माध्यम से) — पता, हिट काउंटर। |

हिट काउंटर (`g_HaveAmsiBuf`, `g_HaveAmsiStr`, `g_HaveWldp`, `g_HaveEtw`) को `InterlockedIncrement` के साथ बनाए रखा जाता है और डीबग आउटपुट में प्रदर्शित किया जाता है, जो यह सत्यापित करने के लिए उपयोगी है कि प्रयोगशाला वातावरण में इंटरसेप्शन वास्तव में हो रहा है।

ध्यान दें कि `DllMain` स्वयं `DLL_PROCESS_ATTACH` पर पूर्ण हुकिंग अनुक्रम निष्पादित करता है, इसलिए निर्यात रनटाइम (अन)लोडिंग परिदृश्यों के लिए वैकल्पिक सुविधाएँ हैं।

---

## बिल्ड निर्देश

**आवश्यकताएँ:** Windows 10/11 x64, Visual Studio Build Tools (`icx.exe`), SDK.

DLL संकलित करें (x64):```bat
icx.exe /nologo /O3 /MT /EHsc "mora_hwbp.c" /link /DLL /out:"mora_hwbp.dll" /LIBPATH:"C:\Program Files (x86)\Intel\oneAPI\compiler\latest\lib"

फ़्लैग्स की व्याख्या:

परिणाम mora_hwbp.dll है, जिसे लक्षित प्रक्रिया में लोड किया जा सकता है।

इंजेक्शन और उपयोग उदाहरण

DLL को ऐसी प्रक्रिया में लोड किया जाना चाहिए जो AMSI/WLDP/ETW का उपयोग करती है — PowerShell होस्ट इसका प्रामाणिक परीक्षण मंच है। लोडिंग किसी भी मानक DLL-इंजेक्शन तकनीक से की जा सकती है। रिफ्लेक्टिव/LoadLibrary इंजेक्शन का उपयोग करते हुए एक न्यूनतम, स्व-निहित प्रदर्शन एक छोटे C लोडर द्वारा किया जा सकता है:```bat rem Run from an x64 developer prompt (example with a generic loader) loader.exe mora_hwbp.dll powershell.exe

या, मैन्युअल लैब जांच के लिए, अपने पसंदीदा टूल के साथ इंजेक्ट करें और फिर PowerShell से सत्यापित करें:```powershell
# 1. Inject mora_hwbp.dll into the PowerShell process (via external tool).
# 2. Verify that classic AMSI test vectors now return clean.
"AmsiTestSample:7e72c3ce-861b-4339-8740-0ac1484c1386"

केवल प्रयोगशाला सत्यापन। डीबगर या GetStats/OutputDebugString से अवलोकन करें कि स्क्रिप्ट सामग्री निष्पादित होते ही सभी चार ब्रेकपॉइंट हिट की रिपोर्ट करते हैं।

पहचान और शमन (ब्लू टीम)

यह POC दोहरे उद्देश्य वाला है: जो विशेषताएँ इसे आक्रामक रूप से प्रभावी बनाती हैं, वे ही ठीक वही हैं जिन्हें रक्षकों को खोजना चाहिए।

समझौता संकेतक (IOCs)

अनुशंसित शमन उपाय

1. वॉचडॉग/सेल्फ-मॉनिटरिंग एजेंट — उच्च-मूल्य वाले प्रोसेस पर GetThreadContext(CONTEXT_DEBUG_REGISTERS) को पोल करें और स्वीकृत डीबगर प्रोफाइल के बाहर किसी भी गैर-शून्य DR0–DR3 वाले थ्रेड का ऑडिट करें।
2. कर्नेल ETW ऑडिटिंग — Microsoft-Windows-Kernel-Process + थ्रेड ट्रेसिंग सक्षम करें और सुरक्षा-संबंधित प्रोसेस को लक्षित करने वाले NtGetContextThread/NtSetContextThread पर अलर्ट करें।
3. EDR यूज़र-मोड हुक अखंडता — चूँकि हार्डवेयर हुक मेमोरी जाँचों को बायपास करते हैं, केवल .text अखंडता के बजाय व्यवहारिक पहचान पर भरोसा करें (EtwEventWrite के नीचे ETW कंज़्यूमर हुक, कर्नेल ETW, AMSI कंज़्यूमर पुनः-जाँच)।
4. मॉनिटर की सुरक्षा करें — वास्तव में शत्रुतापूर्ण वातावरण में, अन्य प्रोसेस पर प्रति-थ्रेड SetThreadContext को एक स्पष्ट उच्च-गंभीरता संकेत के रूप में मानें।
5. एंडपॉइंट हार्डनिंग — WDAC सक्षम करें (जिसे यह POC क्लास अनुमोदन के लिए स्पष्ट रूप से बायपास करता है — WDAC को इन-मेमोरी टूलिंग के विरुद्ध एक स्वतंत्र सुरक्षा के रूप में न मानें), Credential Guard, और जहाँ लागू हो, LSASS सुरक्षा।

ज्ञात सीमाएँ

• केवल x64 — स्टैक-ऑफसेट पुनर्लेखन x64 कॉलिंग कन्वेंशन मानते हैं (आर्ग्युमेंट RCX/RDX/R8/R9 फिर [RSP+0x20…])। x86 वैरिएंट के लिए [EBP+…]-शैली पैरामीटर पुनर्निर्माण की आवश्यकता होगी।
• केवल चार स्लॉट — x64 आर्किटेक्चर बिल्कुल चार ब्रेकपॉइंट रजिस्टर प्रदान करता है; आप इस अकेली विधि से प्रति थ्रेड चार से अधिक फ़ंक्शन हुक नहीं कर सकते।
• मॉनिटर रेस विंडो — Sleep(500) पुनरावृत्तियों के बीच एक (जानबूझकर छोटी) विंडो होती है; अत्यंत तेज़ थ्रेड स्पॉनिंग और आक्रामक स्ट्रिपिंग के संयोजन से सैद्धांतिक रूप से कुछ सौ मिलीसेकंड के लिए मॉनिटर से आगे निकला जा सकता है।
• एंटी-डीबग हस्तक्षेप — कोई भी घटक जो सक्रिय रूप से डीबग रजिस्टरों की निगरानी या सफाई करता है (एक वास्तविक डीबगर, कुछ सैंडबॉक्स, कुछ EDRs) तकनीक में हस्तक्षेप करेगा।
• OutputDebugStringA-आधारित स्थिति — निदान एक डीबग आउटपुट चैनल पर निर्भर करता है; पूरी तरह से स्ट्रिप्ड/हेडलेस वातावरण में आपको प्रयोगशाला अवलोकन के लिए एक डीबगर संलग्न करना चाहिए या आउटपुट को पुनर्निर्देशित करना चाहिए।
• मेमोरी-पर्सिस्टेंस प्रिमिटिव नहीं — यह केवल रनटाइम, इन-प्रोसेस तकनीक है। यह अपने आप में कोई डिस्क/रजिस्ट्री पर्सिस्टेंस, कोई विशेषाधिकार वृद्धि, और कोई क्रॉस-प्रोसेस पार्श्व संचलन प्रदान नहीं करती। इसका संपूर्ण उद्देश्य एक इंटरसेप्शन प्रिमिटिव का नियंत्रित अध्ययन है।

संदर्भ

• Microsoft Learn — एंटीमैलवेयर स्कैन इंटरफ़ेस (AMSI)
• Microsoft Learn — Windows लॉकडाउन पॉलिसी (WLDP)
• Microsoft Learn — विंडोज़ के लिए इवेंट ट्रेसिंग (ETW)
• Microsoft Learn — CONTEXT संरचना और डीबग रजिस्टर
• Intel® 64 and IA-32 Architectures Software Developer's Manual, Vol. 3B — डीबग रजिस्टर (Dr0–Dr7, #DB अपवाद)

लाइसेंस और जिम्मेदार प्रकटीकरण

यह प्रोजेक्ट MIT लाइसेंस के अंतर्गत लाइसेंस प्राप्त है - विवरण के लिए LICENSE फ़ाइल देखें।

यह प्रोजेक्ट केवल शैक्षिक और रक्षात्मक अनुसंधान उद्देश्यों के लिए जारी किया गया है। यदि आप एक सुरक्षा विक्रेता, ब्लू टीम, या डिटेक्शन इंजीनियर हैं, तो आपको हार्डवेयर-ब्रेकपॉइंट-आधारित एवेशन के लिए अपनी डिटेक्शन कवरेज बेहतर बनाने हेतु इस रिपॉज़िटरी की सामग्री का उपयोग करने के लिए प्रोत्साहित किया जाता है। यदि आपने इस तकनीक का वास्तविक दुनिया में दुरुपयोग पाया है, तो इसे अपने संगठन की जिम्मेदार प्रकटीकरण प्रक्रिया और प्रासंगिक विक्रेता/प्राधिकरण चैनलों के माध्यम से रिपोर्ट करें।

अपने जोखिम पर उपयोग करें। इस तकनीक का अनधिकृत उपयोग लागू कानूनों का उल्लंघन कर सकता है।