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

• CLSID बनाम IID
• COM सक्रियण
• CoCreateInstance
• QueryInterface
• संदर्भ गणना
• इंटरफेस पॉइंटर्स
• vtables
• ATL इंटरफेस मैप

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

• IDA/Ghidra डीकंपाइलर सीमाएँ
• क्रॉस-रेफरेंस का अनुसरण
• GUID की पहचान
• इंटरफेस का पुनर्निर्माण
• कंपाइलर-जनित रैपर/थंक का विश्लेषण
• अप्रत्यक्ष vtable कॉल को समझना
• कॉलिंग कन्वेंशन को मान्य करना

Windows आंतरिक

• Windows Security Center
• WSC प्रदाता इंटरफेस
• WSCAPI.dll
• Windows RPC
• MIDL-जनित RPC स्टब्स
• NdrClientCall3
• Security Center उत्पाद स्थिति

अनुसंधान पद्धति

सबसे महत्वपूर्ण बात, मैंने साक्ष्य के एक ही टुकड़े पर भरोसा करने से बचना सीखा।

इसके बजाय:

Symbol
   ↓
Decompiler
   ↓
Assembly
   ↓
GUID
   ↓
Interface Map
   ↓
vtable
   ↓
Call Graph
   ↓
RPC
   ↓
Runtime Verification

प्रत्येक परत निष्कर्ष में विश्वास बढ़ाती है।

परियोजना वास्तुकला

अनुसंधान कार्यान्वयन में दो मुख्य घटक शामिल हैं।

OWN-Defender
│
├── OWN-Defender.cpp
│   ├── WSC COM interaction
│   ├── CLSID discovery
│   ├── COM initialization
│   ├── IWscAVStatus4 interaction
│   ├── registration
│   ├── status update
│   └── cleanup
│
└── dllmain.cpp
    ├── DLL entry point
    ├── research loader
    ├── controlled execution
    └── cleanup/stop handling

रिपॉजिटरी जानबूझकर छोटी है ताकि रिवर्स-इंजीनियर्ड व्यवहार और कार्यान्वयन के बीच संबंध का अनुसरण करना आसान बना रहे।

प्रमुख अनुसंधान प्रश्न

यह परियोजना केवल कार्यक्षमता को पुन: प्रस्तुत करने के बजाय प्रश्नों के आसपास बनाई गई थी:

How does WSC identify the COM class?

How is the IID mapped to the interface?

How does QueryInterface locate the interface?

Why does IDA show different function signatures?

Where is the actual vtable?

Which Register() is the AV implementation?

What happens after the COM method?

Where does WSCAPI.dll enter the call chain?

Where does RPC begin?

How can the result be independently verified?

ये प्रश्न अंततः अंतिम कार्यान्वयन से अधिक मूल्यवान थे।

सुरक्षा अनुसंधान परिप्रेक्ष्य

यह परियोजना निम्नलिखित के बीच सुरक्षा सीमा का अध्ययन करने के लिए एक उपयोगी प्रारंभिक बिंदु भी प्रदान करती है:

Application
     ↓
COM
     ↓
Windows Security Center
     ↓
Security Provider Information

एक महत्वपूर्ण अंतर यह है कि सुरक्षा-उत्पाद जानकारी का पंजीकरण स्वचालित रूप से Defender इंजन को अक्षम करने या उसके सुरक्षा तंत्र को बायपास करने के बराबर नहीं है।

इसलिए, इस परियोजना को मुख्य रूप से इस रूप में देखा जाना चाहिए:

Windows Security Center / COM रिवर्स-इंजीनियरिंग अनुसंधान

न कि इस दावे के रूप में कि अकेले WSC पंजीकरण एक Defender भेद्यता का गठन करता है।

किसी भी सुरक्षा प्रभाव के लिए अलग जांच और सत्यापन की आवश्यकता होती है।

श्रेय

यह अनुसंधान आंशिक रूप से es3n1n द्वारा DefendNot में प्रदर्शित कार्य से प्रेरित था।

WSC तंत्र को समझने के लिए एक उपयोगी प्रारंभिक बिंदु प्रदान करने के लिए लेखक को विशेष धन्यवाद।

मूल परियोजना: https://github.com/es3n1n/defendnot

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

अस्वीकरण

यह रिपॉजिटरी निम्नलिखित के लिए प्रदान की गई है:

• Windows आंतरिक अनुसंधान
• रिवर्स इंजीनियरिंग शिक्षा
• सुरक्षा अनुसंधान
• डिटेक्शन इंजीनियरिंग
• अधिकृत प्रयोगशाला परीक्षण

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

लेखक दुरुपयोग, क्षति, डेटा हानि, सुरक्षा-नियंत्रण हस्तक्षेप या अनधिकृत तैनाती के लिए जिम्मेदार नहीं है।

लाइसेंस

यह परियोजना GNU General Public License v3.0 के तहत लाइसेंस प्राप्त है।

विवरण के लिए LICENSE देखें।

अंतिम निष्कर्ष

OWN-Defender का मुख्य लक्ष्य केवल एक AV पंजीकरण तकनीक को पुन: प्रस्तुत करना नहीं है।

यह एक दोहराने योग्य रिवर्स-इंजीनियरिंग पद्धति का प्रदर्शन करना है:

Find
 ↓
Map
 ↓
Reverse
 ↓
Reconstruct
 ↓
Trace
 ↓
Implement
 ↓
Verify

जो Windows Security Center के बारे में एक प्रश्न से शुरू हुआ, वह COM, ATL, GUID/IID मैपिंग, vtables, कंपाइलर-जनित कोड, WSCAPI, RPC और Windows सुरक्षा वास्तुकला की गहरी खोज बन गया।

कार्यान्वयन परिणाम है। रिवर्स-इंजीनियरिंग प्रक्रिया वास्तविक परियोजना है।