OWN-Defender — Windows Security Center COM अनुसंधान

OWN-Defender एक Windows सुरक्षा अनुसंधान परियोजना है जो यह समझने पर केंद्रित है कि Windows Security Center (WSC) अपने COM इंटरफेस के माध्यम से एंटीवायरस सुरक्षा उत्पादों का प्रतिनिधित्व और प्रबंधन कैसे करता है।

यह परियोजना DefendNot द्वारा प्रदर्शित व्यवहार की जांच के रूप में शुरू हुई, लेकिन मौजूदा कार्यान्वयन को एक ब्लैक बॉक्स के रूप में मानने के बजाय, मैंने इसे स्वतंत्र रिवर्स इंजीनियरिंग और सत्यापन के लिए एक प्रारंभिक बिंदु के रूप में उपयोग किया।

इस परियोजना का लक्ष्य पूर्ण निष्पादन पथ को समझना है:

COM
 ↓
CLSID / IID
 ↓
CoCreateInstance
 ↓
QueryInterface
 ↓
ATL Interface Map
 ↓
vtable
 ↓
IWscAVStatus4
 ↓
CWscIsv
 ↓
WSCAPI.dll
 ↓
RPC
 ↓
Windows Security Center

यह परियोजना एक नियंत्रित Windows अनुसंधान वातावरण में विकसित और परीक्षण की गई थी।

केवल अनुसंधान / शैक्षिक उपयोग

यह परियोजना Windows आंतरिक अनुसंधान, रिवर्स इंजीनियरिंग, सुरक्षा शिक्षा और अधिकृत सुरक्षा परीक्षण के लिए है। इसका उपयोग उन प्रणालियों पर सुरक्षा सॉफ़्टवेयर में हस्तक्षेप करने के लिए न करें जिनके आप स्वामी नहीं हैं या जिनके परीक्षण की स्पष्ट अनुमति आपके पास नहीं है।

---

अनुसंधान प्रेरणा

प्रारंभिक प्रश्न सरल था:

Windows Security Center को कैसे पता चलता है कि एक एंटीवायरस उत्पाद मौजूद है?

सार्वजनिक API दस्तावेज़ीकरण पर रुकने के बजाय, मैं समझना चाहता था कि API के नीचे क्या होता है।

इससे कई प्रश्न उत्पन्न हुए:

• कौन सी COM क्लास WSC कार्यक्षमता को लागू करती है?
• कौन सा IID एंटीवायरस इंटरफेस से मेल खाता है?
• QueryInterface() इंटरफेस को कैसे हल करता है?
• इंटरफेस ATL इंटरफेस मैप में कहाँ संग्रहीत है?
• IDA कभी-कभी किसी विधि के लिए केवल __int64 a1 क्यों दिखाता है?
• पुनर्निर्मित C++ इंटरफेस में अतिरिक्त पैरामीटर क्यों होते हैं?
• कौन सा Register() फ़ंक्शन वास्तव में AV पंजीकरण फ़ंक्शन है?
• पंजीकरण अंततः Windows Security Center तक कैसे पहुँचता है?
• RPC सीमा कहाँ दिखाई देती है?
• परिणाम को स्वतंत्र रूप से कैसे सत्यापित किया जा सकता है?

---

रिवर्स इंजीनियरिंग यात्रा

1. COM क्लास की पहचान

पहला कदम Windows Security Center COM क्लास की पहचान करना था।

यह परियोजना WSC COM क्लास का उपयोग करती है:

CLSID_WscIsv
F2102C37-90C3-450C-B3F6-92BE1693BDF2

कार्यान्वयन में केवल हार्डकोडेड मान पर निर्भर रहने के बजाय Windows रजिस्ट्री से CLSID को गतिशील रूप से खोजने का तर्क भी शामिल है।

अवधारणात्मक रूप से:

HKLM
 └── SOFTWARE
     └── Classes
         └── CLSID
             └── {CLSID}
                 └── Windows Security Center ISV API

इसने पहला महत्वपूर्ण संबंध प्रदान किया:

Registry
   ↓
CLSID
   ↓
Windows Security Center ISV API

---

2. सही इंटरफेस की पहचान

अगली चुनौती यह निर्धारित करना था कि कौन सा COM इंटरफेस अनुरोध किया जाना चाहिए।

यह परियोजना उपयोग करती है:

IWscAVStatus4

साथ में:

4DCBAFAC-29BA-46B1-80FC-B8BDE3C0AE4D

अनुसंधान से महत्वपूर्ण सबकों में से एक था:

अकेले GUID नाम पर्याप्त साक्ष्य नहीं है।

मैंने यह मानने के बजाय कि इंटरफेस नाम और GUID सही हैं, रिवर्स इंजीनियरिंग के माध्यम से संबंध को सत्यापित किया।

जांच में शामिल थे:

• GUID संदर्भ
• QueryInterface
• ATL इंटरफेस मैप
• _ATL_INTMAP_ENTRY
• vtable स्थान
• क्रॉस-रेफरेंस
• फ़ंक्शन कार्यान्वयन
• रनटाइम व्यवहार

---

3. QueryInterface को समझना

सबसे उपयोगी रिवर्सिंग चरणों में से एक इसके कार्यान्वयन का अनुसरण करना था:

CComAggObject<CWscIsv>::QueryInterface()

जो अंततः यहाँ पहुँचता है:

ATL::CComObjectRootBase::InternalQueryInterface()

ATL इंटरफेस मैप का उपयोग अनुरोधित IID की तुलना पंजीकृत इंटरफेस प्रविष्टियों से करने के लिए किया जाता है।

अवधारणात्मक रूप से:

Requested IID
     ↓
QueryInterface()
     ↓
InternalQueryInterface()
     ↓
ATL Interface Map
     ↓
GUID comparison
     ↓
Matching interface
     ↓
Interface pointer

इसने स्वतंत्र साक्ष्य प्रदान किया कि जांचा जा रहा GUID वास्तव में अपेक्षित COM इंटरफेस से मेल खाता है।

---

4. Register() भ्रम

सबसे बड़ी रिवर्सिंग चुनौतियों में से एक यह समझना था कि IDA/Ghidra हमेशा वह विधि हस्ताक्षर क्यों नहीं दिखाता जिसकी मैंने अपेक्षा की थी।

पुनर्निर्मित इंटरफेस में शामिल है:

virtual HRESULT __stdcall Register(
    BSTR path,
    BSTR name,
    unsigned int,
    unsigned int
) = 0;

हालाँकि, डीकंपाइलर ऐसा कार्यान्वयन दिखा सकता है:

_IWscAVStatus4<CWscIsv>::Register(__int64 a1)

पहली नज़र में यह असंगत लग रहा था।

आगे की जांच से पता चला कि डीकंपाइलर प्रतिनिधित्व एक रैपर/थंक और अंतर्निहित अप्रत्यक्ष vtable कॉल का वर्णन कर रहा था, न कि पूर्ण तार्किक इंटरफेस हस्ताक्षर प्रस्तुत कर रहा था।

यह एक महत्वपूर्ण सबक बन गया:

डीकंपाइलर आउटपुट मशीन कोड की एक व्याख्या है, मूल स्रोत-स्तर की सच्चाई नहीं।

इन विसंगतियों को हल करने के लिए, मैंने तुलना की:

COM interface definition
        ↓
vtable layout
        ↓
assembly
        ↓
wrapper/thunk
        ↓
calling convention
        ↓
actual target function

---

5. एकाधिक Register() फ़ंक्शन

भ्रम का एक और स्रोत ऐसे नामों वाले कई फ़ंक्शनों की उपस्थिति थी:

IWscAVStatus2::Register
IWscAVStatus4::Register
IWscFWStatus2::Register
RegisterAV

महत्वपूर्ण अहसास यह था कि समान नामों का मतलब समान इंटरफेस नहीं है।

उदाहरण के लिए:

AV
 ↓
IWscAVStatus4
 ↓
AV registration

जबकि:

Firewall
 ↓
IWscFWStatus2
 ↓
Firewall registration

किसी फ़ंक्शन को केवल इसलिए चुनने के बजाय कि उसके नाम में Register शामिल है, इंटरफेस संख्या और आसपास के कार्यान्वयन को सत्यापित करना पड़ा।

यह अनुसंधान के सबसे उपयोगी हिस्सों में से एक था क्योंकि इसने मुझे सहसंबंधित करने के लिए मजबूर किया:

Interface
+
IID
+
vtable
+
implementation
+
parameter layout
+
call target

---

6. पंजीकरण पथ का पता लगाना

सही इंटरफेस की पहचान करने के बाद, मैंने पंजीकरण ऑपरेशन को बाइनरी में गहराई से ट्रेस किया।

देखा गया पथ लगभग था:

IWscAVStatus4::Register()
        ↓
CWscIsv
        ↓
RegisterSecurityProductFunction
        ↓
wscRegisterSecurityProduct()
        ↓
WSCAPI.dll
        ↓
s_wscRegisterSecurityProduct()
        ↓
NdrClientCall3()
        ↓
RPC
        ↓
Windows Security Center

यह विशेष रूप से महत्वपूर्ण था क्योंकि COM विधि स्वयं अंतिम ऑपरेशन नहीं थी।

कॉल अंततः एक RPC सीमा को पार कर गई।

इसने वास्तुकला को देखने के मेरे तरीके को बदल दिया:

COM
  ≠
final implementation

इसके बजाय:

COM
 ↓
local implementation
 ↓
WSC API
 ↓
RPC client
 ↓
Windows component

---

7. WSCAPI.dll को समझना

अगली परत WSCAPI.dll थी।

रिवर्स-इंजीनियर्ड पथ यहाँ पहुँचा:

wscRegisterSecurityProduct()

जिसने अंततः यह आह्वान किया:

s_wscRegisterSecurityProduct()

और फिर:

NdrClientCall3()

यह वह बिंदु था जहाँ जांच एक सामान्य COM कॉल से Windows RPC इंफ्रास्ट्रक्चर में स्थानांतरित हो गई।

इस परत को समझने से यह समझाने में मदद मिली कि केवल मूल COM DLL को देखकर व्यवहार को पूरी तरह से क्यों नहीं समझा जा सकता था।

---

8. रनटाइम सत्यापन

स्थैतिक विश्लेषण अनुसंधान का केवल एक हिस्सा था।

प्रासंगिक इंटरफेस और कॉल पथ का पुनर्निर्माण करने के बाद, मैंने अपना स्वयं का नियंत्रित कार्यान्वयन बनाया और परिणामी व्यवहार की तुलना Windows Security Center से की।

मैंने Windows Security Center / WMI जानकारी का उपयोग किया जैसे:

ROOT\SecurityCenter2
    AntiVirusProduct

पंजीकृत उत्पाद जानकारी को स्वतंत्र रूप से देखने के लिए।

सत्यापन प्रक्रिया थी:

Reverse engineering
       ↓
Interface reconstruction
       ↓
Own implementation
       ↓
Runtime execution
       ↓
Windows Security Center
       ↓
WMI observation
       ↓
Compare results

इसने मुझे यह सत्यापित करने की अनुमति दी कि स्थैतिक विश्लेषण से निष्कर्ष देखने योग्य Windows व्यवहार के अनुरूप थे।

---

9. मैंने क्या सीखा

इस परियोजना ने मुझे एक COM इंटरफेस के साथ बातचीत करने के तरीके से कहीं अधिक सिखाया।

COM