"किसी भी सीपीयू"

Question

के खिलाफ निर्मित अनुप्रयोगों में Win32 हुक डीएलएल इंजेक्शन मैं एक परियोजना पर काम कर रहा हूं जो सभी उपयोगकर्ता इंटरैक्शन को कैप्चर करता है। एमएसडीएन बताता है (this)

सेटविंडोशूकएक्स का उपयोग किसी अन्य प्रक्रिया में डीएलएल इंजेक्ट करने के लिए किया जा सकता है। एक 32-बिट डीएलएल को 64-बिट प्रक्रिया में इंजेक्शन नहीं दिया जा सकता है, और 64-बिट DLL को 32-बिट प्रक्रिया में इंजेक्शन नहीं दिया जा सकता है। यदि किसी एप्लिकेशन को अन्य प्रक्रियाओं में हुक के उपयोग की आवश्यकता है, तो यह आवश्यक है कि 32-बिट एप्लिकेशन कॉल SetWindowsHookEx 32-बिट प्रक्रियाओं में 32-बिट DLL इंजेक्ट करने के लिए, और 64-बिट एप्लिकेशन कॉल SetWindowsHookEx को इंजेक्ट करने के लिए 64-बिट डीएलएल 64-बिट प्रक्रियाओं में।

मेरा प्रश्न यह है कि यदि Any CPU के खिलाफ कोई एप्लिकेशन बनाया गया तो क्या होता है। क्या मुझे Any CPU के विरुद्ध बनाए गए डीएलएल से SetWindowsHookEx पर कॉल करने की आवश्यकता है।

मैं HookFunctions_64.dll (दोनों 64) लोड हो रहा है WH_CBT और WH_MOUSE विश्व स्तर पर (नहीं एक विशिष्ट थ्रेड) की स्थापना HookFunctions_32.dll (दोनों 86) और HookLogger_64.exe लोड हो रहा है HookLogger_32.exe लिखा है।

HookLogger_32.exe, HookLogger_64.exe, HookFunctions_32.dll और HookFunctions_64.dll C++ में लिखे गए हैं।

जब मैं Any CPU के विरुद्ध बनाए गए .NET अनुप्रयोग पर क्लिक करता हूं, तो इन डीएलएल इंजेक्शन (SetWindowHookEx के माध्यम से) प्राप्त होते हैं। विंडोज ओएस & लटकता है मुझे अपनी मशीन को मजबूती से पुनरारंभ करना होगा।

जब एक ही .NET अनुप्रयोग x86 या x64 के खिलाफ बनाया गया है, और जब मैं हुकलॉगर्स (32 & 64 बिट दोनों) के बाद एप्लिकेशन पर क्लिक करता हूं, तो सब कुछ ठीक काम कर रहा है।

इस अपरिभाषित व्यवहार के लिए कोई कारण नहीं है।

जिस प्लेटफॉर्म पर मैं काम कर रहा हूं वह 64-बिट मशीन है।

Answer 1

आपको एक संबंधित बिटसे के साथ एक डीएलएल से इंजेक्ट करने की आवश्यकता है - यानी "कोई भी CPU" रनटाइम पर 32 या 64 बिट हो जाता है ... और आपके डीएलएल को रनटाइम बैटन से मेल खाना चाहिए!

:

कुछ अपनी स्थिति में उपयोगी के रूप में "पक्ष-साथ विधानसभा" (एक ही विधानसभा के दो संस्करणों, एक 32 और अन्य 64 बिट) ... मुझे लगता है कि आप इन उपयोगी मिलेगा में जाना जाता है

• Using Side-by-Side assemblies to load the x64 or x32 version of a DLL
• http://blogs.msdn.com/b/gauravseth/archive/2006/03/07/545104.aspx
• http://www.thescarms.com/dotnet/Assembly.aspx

यहाँ आप एक अच्छा पूर्वाभ्यास जो उपयोगी जानकारी टुकड़े में बहुत-सा मिल सकता है - यह वर्णन .NET DLL wrapping C++/CLI DLL referencing a native DLL

अद्यतन:

hooking वास्तव में आसान बनाने के लिए और मजबूत this well-tested and free library देखते हैं - अन्य बातों के यह AnyCPU साथ काम करता है, के बीच!

Answer 2

मुझे लगता है कि आपकी मुख्य समस्या यह है कि आप देशी प्रक्रिया में .NET असेंबली इंजेक्ट करने की कोशिश कर रहे हैं और यह निश्चित रूप से काम नहीं करेगा। मुझे यह भी यकीन नहीं है कि SetWindowsHookEx सीएलआर प्रक्रिया में .NET असेंबली इंजेक्शन का समर्थन करता है। आपकी समस्या का हल है:

1. पुनर्लेखन/देशी संकलक का उपयोग कर अपने dll पुन: संयोजित इस तरह के सी ++/डेल्फी/वीबी आदि के रूप में, x86 और x64 मंच के लिए।
2. सुनिश्चित करें कि आपका डीएल केवल सिस्टम पुस्तकालयों पर निर्भर करता है। उदाहरण के लिए, यह किसी भी डीएल पर निर्भर नहीं होना चाहिए जो विंडोज़ के साथ नहीं भेजता है, क्योंकि आप लक्ष्य प्रक्रिया को क्रैश कर सकते हैं। आप निर्भरताओं की पहचान के लिए "निर्भरता वाकर" उपकरण का उपयोग कर सकते हैं।
3. जैसा कि एमएसडीएन में उल्लिखित है, आपके पास प्रत्येक सीपीयू के लिए एक निष्पादन योग्य इंजेक्टर होना चाहिए जिसे आप समर्थन देना चाहते हैं। इस मामले में x86 और x64।

या आप एक बेहतर इंजेक्शन/हुकिंग लाइब्रेरी जैसे मैडकोडहुक या डेटोर का उपयोग कर सकते हैं। इस तरह आप समस्या # 3 से उबरेंगे, न कि उनके द्वारा प्रदान किए जाने वाले दर्जनों पेशेवरों का उल्लेख किया जाए।

Answer 3

बस समस्या मेरा अनुमान है की अपने विवरण से ... आपका कोई सीपीयू संकलित कार्यक्रम एक x86 ठूंठ जो अपने 32 बिट हुक फायरिंग है, तो 86 ठूंठ चेकों लोड हो रहा है और देखता है पर्यावरण 64 बिट समर्थन और शुरूआत भी काम करती है 64 बिट सीएलआर संस्करण।

इस परिदृश्य में आपका 32 बिट हुक डीएलएल WH_SHELL संदेश प्राप्त कर रहा है और एक प्रक्रिया (x86 स्टब) में इंजेक्ट करने की कोशिश कर रहा है जो पहले ही समाप्त हो चुका है या 64 बिट सीएलआर प्रक्रिया में 32 बिट हुक इंजेक्शन कर रहा है। इस प्रकार आपके "बहुत संदिग्ध और सिस्टम क्रैश पर विस्तारित करने की जरूरत है।

यदि आप वास्तव में अपना कोड क्या कर रहे हैं, इसके बारे में विस्तार से देखभाल करना चाहते हैं, तो अधिक सहायता (और कम सामान्यीकरण और 'केवल प्रोग्राम ए' का उपयोग करें) दिया जाएगा। क्या आप वास्तव में प्रक्रिया में कोड इंजेक्ट कर रहे हैं या आप प्रक्रिया के dwThreadId के साथ SetWindowsHookEx को कॉल कर रहे हैं।

Answer 4

32-बिट कंप्यूटर पर, यह स्पष्ट होना चाहिए कि किसी भी CPU अनुप्रयोग पर ध्यान दिया जाता है।

एक 64-बिट कंप्यूटर .NET Framework के दो अलग-अलग इंस्टॉलेशन प्राप्त करता है: प्रत्येक प्रत्येक के लिए एक। लक्ष्य के रूप में किसी भी CPU के साथ संकलित एक .NET अनुप्रयोग सामान्य रूप से 64-बिट स्थापना पर चलता है, लेकिन यह 32-बिट स्थापना पर भी चला सकता है यदि किसी अन्य एप्लिकेशन द्वारा संदर्भित किया गया है जो सीधे x86 को लक्षित करता है। इस प्रकार, आप केवल यह सुनिश्चित कर सकते हैं कि आप क्या प्राप्त कर रहे हैं यदि आप जानते हैं कि एप्लिकेशन कैसे चल रहा है: एक स्वतंत्र प्रक्रिया के रूप में, या संदर्भ के माध्यम से।

मैं कोई धारणा नहीं करता। मान लें कि 64-बिट कंप्यूटर पर प्रक्रिया 64-बिट है: यह संभावित रूप से 32-बिट हो सकती है। इसे ठीक से जांचें कि यह किस मोड में चल रहा है। फिर, 32-बिट या 64-बिट के अनुसार इंजेक्ट करें।

कारण यह है कि आपको लक्ष्य प्रक्रिया के रूप में एक ही गठबंधन का उपयोग करना चाहिए, तकनीकी कारणों के लिए जिसमें मुझे नहीं मिलेगा, ऐसे हुक सिस्वा बाधा कहलाते हैं। SysWOW 32-बिट अनुप्रयोगों को 32-बिट कंप्यूटर पर चलाने के लिए 32-बिट अनुप्रयोगों को चलाने की अनुमति देता है, 32-बिट कंप्यूटर पर चलाने के लिए 16-बिट अनुप्रयोग इत्यादि। जब आप SysWOW के विभिन्न पक्षों पर चल रहे अनुप्रयोगों के बीच संवाद करते हैं तो आप "बाधा पार करते हैं" - यह है, कोई SysWOW (32-बिट) के भीतर चल रहा है, और दूसरा (64-बिट) नहीं है। सीधे शब्दों में कहें, एक प्रक्रिया पूरी तरह से SysWOW में या बाहर होना चाहिए। इस प्रकार, आप 64-बिट प्रक्रिया में 32-बिट कोड नहीं जोड़ सकते हैं, और इसके विपरीत।