👩🏻‍🔬 👩🏼‍🏭 ☑️ विंडो हुक पंजीकरण 🕠 🏀 🧗🏾

होम्स । लेकिन मुझे बताओ, मेरे दोस्त वॉटसन, क्या तुमने कभी एक खिड़की के हुक, विशेष रूप से एक वैश्विक एक को मिटा दिया है?

वाटसन । हम्म ... क्या आसान हो सकता है, प्रिय होम्स।

::UnhookWindowsHookEx( hhookMy);

एक्स मत बताओ, वॉटसन, मत बताओ। इस कॉल के बाद, हुक फ़ंक्शन वाले DLL मॉड्यूल को अभी भी उन सभी प्रक्रियाओं में लोड किया गया है जिसमें यह लोड किया गया था। सिस्टम केवल कुछ समय बाद इस DLL को लोड करता है। अर्थात्, उस क्षण जब कम से कम एक विंडो संदेश सभी थ्रेड्स (इस तरह की कतार वाले) की संदेश कतारों से होकर गुजरेगा। और इसलिए डेस्कटॉप पर हर प्रक्रिया के लिए।

में। यहाँ, वाह! क्या तुम मुझे, होम्स का मजाक उड़ाते हो? यह उपयोगकर्ता 32 है। Win32 में मुख्य भागों में से एक, जो बदले में विंडोज में अन्य सभी तकनीकों पर निर्भर करता है। उदाहरण के लिए वही .Net। और अचानक यह पूरी तरह से निर्धारक व्यवहार नहीं है।

और CreateFile , संयोग से, फ़ाइल को बहुत अधिक आस्थगित नहीं करता है - उदाहरण के लिए, जब तक कि फ़ाइल को पहले न लिखें? और CreateProcess , संयोग से, नहीं ...

एक्स नहीं, वॉटसन, इस बार मैं मजाक नहीं कर रहा हूं। CreateFile और CreateProcess हमारा कर्नेल 32 है - पूरी तरह से अलग मामला है।

मेरा विश्वास करो, दोस्त। अपनी जांच को आगे बढ़ाते हुए, मैंने उपयोगकर्ता32 मॉड्यूल की आंतरिक संरचना का अध्ययन करने में बहुत समय बिताया और मैं विश्वास के साथ कहता हूं: लेखकों ने इसे कर्नेल 32 की तुलना में पूरी तरह से अलग गुणवत्ता में लिखा (और समर्थन)।

में। क्या यह सिर्फ एक और विकास टीम है?

एक्स हाँ, जाहिर है।

में। शायद यह व्यवहार अभी भी उचित है। और क्या यह वास्तव में महत्वपूर्ण है जब हुक डीएलएल अनलोड किया जाता है?

एक्स कल्पना कीजिए कि हमारे एप्लिकेशन ने इंटरनेट और पुनरारंभ के माध्यम से खुद को अपडेट किया है। पुनः आरंभ करने के बाद, यह पता चलता है कि कुछ प्रक्रियाओं ने DLL के पुराने संस्करण को लोड कर दिया है, और कुछ नए। और इस मामले में, पुराने संस्करण भी अनलोड नहीं किए जाएंगे जब संदेश कतारों से गुजरते हैं।

में। क्या खौफ है!

लेकिन एक पल रुकिए। यदि एप्लिकेशन ने अपनी फ़ाइलों को अपडेट किया है, तो इसका मतलब है कि उसने हुक DLL के पुराने संस्करण का नाम बदल दिया या इसे अस्थायी निर्देशिका में कहीं स्थानांतरित कर दिया। फिर एक नया संस्करण शुरू होता है ... यह SetWindowsHookEx DLL पते पर SetWindowsHookEx , जिसकी फ़ाइल पथ अब DLL से भिन्न है, जैसा कि आप कहते हैं, लोड रहता है।

आप यह कहना चाहते हैं कि सिस्टम एक हुक बनाएगा जो गलत DLL को लक्षित करता है जिसे हम SetWindowsHookEx को पास करते हैं? यह नहीं हो सकता!

एक्स उन प्रक्रियाओं में जहां से DLL को उतारने का प्रबंधन नहीं किया गया था, यह वही है जो होगा, मैं अपने ट्यून्ड कीबोर्ड द्वारा कसम खाता हूं।

जाहिरा तौर पर, User32 आंतरिक रूप से उस पथ को बचाता है जो DLL के उस समय था जब हुक पहली बार बनाया गया था। दूसरी रचना में, उनका मानना है कि यह वही DLL है और इसे उतारने और पुनः लोड करने की आवश्यकता नहीं है।

में। हम्म ... और यह सब क्या है? क्या होगा अगर UnhookWindowsHookEx बाद आप बस एक सेकंड का इंतजार करें। विंडो मैसेज काफी बार आते हैं।

एक्स ऐसा तब होता है जब उपयोगकर्ता विंडो के साथ कुछ करता है। और, उदाहरण के लिए, कम से कम खिड़कियां शांत हैं। इसमें कोई गारंटी नहीं है कि एक संदेश प्रत्येक कतार में एक सेकंड के भीतर दिखाई देगा। या एक घंटे के लिए।

में। क्या करें? आप सभी प्रक्रियाओं से DLL को अनलोड करने की गारंटी कैसे देते हैं?

(होम्स चुप है और धूम्रपान करता है, वाटसन को देखता है।)

में। होम्स, आप हो जाएगा। मुझे यकीन है कि आप पहले से ही स्थिति से बाहर आने का सही रास्ता तय कर चुके हैं। कृपया साझा करें।

एक्स हमारे हुक फ़ंक्शन को यह पता लगाने पर कि यह एक निश्चित थ्रेड में पहली बार निष्पादित किया जा रहा है, एक विशेष अस्थायी फ़ाइल में एक फ़ाइल स्ट्रीम बनाएं। और इस धागे के नाम में दाईं ओर उस धागे की आईडी इंगित होगी जिसमें इसे निष्पादित किया गया है। कुछ इस तरह:

 using namespace std; namespace k = Kernel32; ... if( nullptr == tls_plistiterHookedThreadFileStreamHandle) //      . { _listHookedThreadFileStreamHandles.push_front( k::CreateFile( k::FormatMessage( L"%1:%2!4u! %3!4u!", sHookedThreadListFilePath, k::GetCurrentThreadId(), k::GetCurrentProcessId() ), GENERIC_WRITE, FILE_SHARE_READ, CREATE_ALWAYS, FILE_FLAG_DELETE_ON_CLOSE )); tls_plistiterHookedThreadFileStreamHandle = new list< HANDLE>::iterator( _listHookedThreadFileStreamHandles.begin()); }

तब मुख्य EXE इन थ्रेड्स ( FindNextStream ) पर FindNextStream करने में सक्षम होगा और प्रत्येक थ्रेड के लिए WM_NULL संदेश भेजेगा जिसे User32 ने हमारे हुक के साथ जोड़ा है। परिणामस्वरूप, User32 DLL को अनलोड करेगा।

DLL, अनलोडिंग, सूची के सभी _listHookedThreadFileStreamHandles से बंद करना चाहिए।

इस प्रकार, हमें यह भी एक अच्छा मानदंड है कि काम किया जाता है - हमारी अस्थायी फ़ाइल को हटाने की कोशिश करते समय सफलता।

में। होम्स, इतनी परेशानी क्यों? तर्क के साथ SendMessage है HWND_BROADCAST ।

एक्स SendMessage उन सभी थ्रेड्स को संदेश नहीं भेजता है जिनकी कतार है। हालाँकि, शायद यह भी काम करेगा। लगभग हमेशा।

(चिल्लाता है।) श्रीमती हडसन, चाय परोसें, कृपया!

अगले दिन

में। होम्स, एक सज्जन ने बताया कि SendMessage( HWND_BROADCAST) कम से कम उनके मामले में मदद नहीं करता है।

एक्स हम्म।

विंडो हुक पंजीकरण

अगले दिन

More articles: