मैं अपने प्रॉक्सी डीएलएल में ole32.dll पर कॉल कैसे रीडायरेक्ट करूं?

Question

मैं कुछ प्रक्रियाओं में CoCreateInstance पर सभी कॉलों का पता लगाने की कोशिश कर रहा हूं (आदर्श रूप में, मैं बाल प्रक्रियाओं में भी कॉल का पता लगाने में सक्षम हूं)।

इसे प्राप्त करने के लिए, विंडोज 7 पर माइक्रोसॉफ्ट विजुअल स्टूडियो 2008 का उपयोग करके, मैं एक प्रॉक्सी डीएलएल बनाता हूं जो विभिन्न लेखों में वर्णित मानक ole32.dll लाइब्रेरी में एक कॉल के अलावा सभी को आगे बढ़ाता है, उदा। Intercepted: Windows Hacking via DLL Redirection। परिणामस्वरूप डीएलएल ठीक दिखता है, लेकिन मैं सिर्फ मौजूदा प्रोग्राम नहीं कर सकता (मैं मानक ActiveX Control Test Container (tstcon32.exe) परीक्षण अनुप्रयोग के रूप में उपयोग कर रहा हूं) मेरे प्रॉक्सी डीएलएल उठाओ। कोई फर्क नहीं पड़ता कि मैं क्या करता हूं, Process Explorer के अनुसार प्रोग्राम हमेशा C:\Windows\SysWow64\ole32.dll चुनते हैं। मैंने अब तक कुछ चीजों की कोशिश की:

1. निर्देशिका को तैयार करें जिसमें मेरी प्रॉक्सी डीएलएल PATH पर है और फिर प्रोग्राम को आमंत्रित करें; ऐसा कोई प्रतीत नहीं होता है।
2. मेरे प्रॉक्सी डीएलएल को उसी प्रोग्राम में कॉपी प्रोग्राम के रूप में कॉपी करें; कोई भाग्य नहीं।
3. फ़ाइल को उसी निर्देशिका में उसी निर्देशिका में बनाएं जैसा कि Dynamic-Link Library Redirection आलेख में वर्णित है और मेरे प्रॉक्सी DLL को उसी निर्देशिका में डालें - या तो काम नहीं किया। लेकिन फिर, मैंने पढ़ा कि यह हाल ही के विंडोज संस्करणों पर काम करना बंद कर दिया है। इसके अतिरिक्त, ole32.dllHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs रजिस्ट्री सेटिंग के अनुसार "ज्ञात DLL" है, इसलिए .local-आधारित रीडायरेक्शन शायद वैसे भी काम नहीं करेगा।
4. वर्णित अनुसार संशोधित-आधारित पुनर्निर्देशन का उपयोग करें उदा। DLL redirection using manifests प्रश्न में, लेकिन ऐसा कोई प्रभाव नहीं प्रतीत होता। हालांकि, यह दृष्टिकोण गैर-तुच्छ लगता है, इसलिए संभावना है कि मैंने कुछ गलत किया है।

क्या किसी को मानक डीएलएल जैसे कॉल को रीडायरेक्ट करने का अनुभव है जैसे ole32.dll स्टब डीएलएल का उपयोग कर? आपने अपने स्टब डीएलएल को लेने के लिए एप्लिकेशन को कैसे मजबूर किया?

Answer 1

शायद winapioverride आपकी मदद कर सकता है। यह प्रोग्रामिंग के बिना सभी जीत एपीआई कॉल लॉग कर सकते हैं। इसलिए यह लॉगिंग करने वाली प्रक्रिया में डीएलएस इंजेक्ट करता है। अगर मैं इसे सही ढंग से याद करता हूं तो अपने कस्टम डीएलएस को इंजेक्ट करना भी संभव है - प्रक्रिया वास्तव में किसी भी कोड को निष्पादित करने से पहले भी। प्रलेखन में कॉम ऑब्जेक्ट्स जासूसी करने के बारे में कुछ जानकारी है।

Answer 2

मुझे पता है यह एक छोटे से देर से लगभग 6 महीने से है, लेकिन मैं एक ही बात कोशिश कर रहा था और कुछ अतिरिक्त नोट:

1. आप का स्वामित्व लेने और HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs से ole32.dll निकाल सकते हैं। यह आपको इस तथ्य को पाने की इजाजत देता है कि विंडोज ने इन चाबियों को बंद कर दिया है।
2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Managersupposed to alter the search path में SafeDllSearch के साथ एक कुंजी SafeDllSearch बनाना।

इन तकनीकों और रीबूटिंग दोनों को लागू करने के बाद, हुकिंग अभी भी काम नहीं कर रही है। मैं एक और चला गया, हमारी बचाव सीडी (एक विंडोज पीई आधारित पर्यावरण) में से एक के साथ एक वीएम बूट किया और system32 में से एक को ओवरराइट किया। परिणामस्वरूप बूट नहीं होता है - कोई प्रतीक त्रुटियां नहीं, लेकिन मुझे LogonUI.exe तक कभी नहीं मिलता है। यह संभव है कि मेरे झुका हुआ कार्य टूट गए हैं, इसलिए यह कारण हो सकता है।

वैसे भी, जिसने एक वास्तविक, मूर्त हुक प्रभाव उत्पन्न किया - यद्यपि जो "टूटा" चिल्लाता है!दुर्भाग्य से यह डीबग करना बेहद मुश्किल प्रतीत होता है, और मैं हुकिंग की अन्य विधि का सहारा ले सकता हूं - अर्थात् IAT patching।

संपादित करें एक और प्रयोग मैंने डीएल को स्पष्ट रूप से लक्ष्य प्रक्रिया 'पता स्थान में लोड करना था। कोड का स्निपेट ऐसा करता है:

wchar_t* TargetPath = argv[1]; 
wchar_t DllPath[] = L"N:\\experiments\\ole32.dll"; 
STARTUPINFOW si; 
PROCESS_INFORMATION pi; 
memset(&si, 0, sizeof(STARTUPINFOW)); 
memset(&pi, 0, sizeof(PROCESS_INFORMATION)); 

// create process suspended 
BOOL bResult = CreateProcess(NULL, TargetPath, NULL, NULL, FALSE, 
    CREATE_SUSPENDED, NULL, NULL, &si, &pi); 

// write DLL name to remote process 
void* RemoteAddr = VirtualAllocEx(pi.hProcess, NULL, sizeof(DllPath)+1, 
    MEM_RESERVE | MEM_COMMIT, PAGE_READONLY); 
WriteProcessMemory(pi.hProcess, RemoteAddr, DllPath, sizeof(DllPath), &BytesWritten); 

// get handle to LoadLibraryW 
PTHREAD_START_ROUTINE pfLoadLibrary = (PTHREAD_START_ROUTINE) 
    GetProcAddress(GetModuleHandle(L"kernel32.dll"), "LoadLibraryW"); 

// create remote thread calling LoadLibraryW 
HANDLE hThread = CreateRemoteThread(pi.hProcess, NULL, 
    0, pfLoadLibrary, RemoteAddr, 0, NULL); 

// start remote process 
ResumeThread(pi.hThread); 

ब्रेवटी के लिए हटाए गए त्रुटि को संभालने में त्रुटि।

असल में, उद्देश्य ole32.dll को लक्ष्य के पता स्थान में लोड करने के लिए मजबूर करना था इससे पहले कि उसे system32 से ole32.dll लोड करने का मौका मिले। मेरे मामले में, ole32.dll को बाद में एप्लिकेशन के भार दिनचर्या में लोड किया जा रहा था, इसलिए सिद्धांत में यह काम करना चाहिए था। अभ्यास में, यह नहीं था। मुझे यकीन नहीं है क्यों।

अद्यतन मेरा मूल कोड विफल हुआ क्योंकि डीएलएल के पास रनटाइम पर अनसुलझे प्रतीक चेतावनियां थीं। यह तकनीक काम करती है तो जाहिर है, यह मेरे ole32.dll और सिस्टम 32 से एक को लोड करता है। यह सुनिश्चित करने के लिए कि पुस्तकालय सफलतापूर्वक लोड हो रहा था, मैंने ऊपर दिए गए कोड पर LoadLibrary(DllPath) कॉल किया।