मिश्रित एप्लिकेशन में बफर ओवरफ़्लो अपवाद पर जानकारी कैसे प्राप्त करें?

Question

मेरे द्वारा विकसित किए गए सभी WPF एप्लिकेशन में AppDomain.CurrentDomain.UnhandledException पर सदस्यता लेने वाला एक वैश्विक अपवाद हैंडलर है जो इसे ढूंढने वाली सभी चीज़ों को लॉग करता है और फिर एक संवाद बॉक्स दिखाता है जो उपयोगकर्ता को लेखक से संपर्क करने के लिए कहता है, जहां लॉग फ़ाइल आदि है। यह बहुत अच्छी तरह से काम करता है और दोनों ग्राहक और मैं इसके साथ बहुत खुश हैं क्योंकि यह तेजी से समस्याओं को ठीक करने की अनुमति देता है।

हालांकि मिश्रित WPF/C#/CLI/C++ अनुप्रयोग के विकास के दौरान कभी-कभी एप्लिकेशन क्रैश होते हैं जो इसे उपरोक्त अपवाद हैंडलर तक नहीं बनाते हैं। इसके बजाए, एक मानक विंडोज़ संवाद बॉक्स कहता है कि "XXX ने काम करना बंद कर दिया है" पॉप अप करता है। विवरण में यह जैसे

Problem Event Name: BEX 
Application Name: XXX.exe 
Fault Module Name: clr.dll 
... 

यह ज्यादातर होता है जब वापस umanaged कोड के भीतर से एक प्रबंधित फ़ंक्शन को कॉल से पता चलता है, और उस समारोह स्क्रीन अद्यतन करता है जब। मुझे समस्या के मूल कारण को समझने में मुझे लंबा समय नहीं लगा, लेकिन केवल इसलिए कि मैं अपनी मशीन पर दुर्घटना को पुन: पेश कर सकता हूं और डीबगर को हुक कर सकता हूं: सभी अवसरों में देशी धागा अभी भी फ़ंक्शन पॉइंटर को कॉल करने के बिंदु पर था प्रबंधित प्रतिनिधि जो सीधे सी #/डब्ल्यूपीएफ कोड में कॉल करता है।

वास्तविक समस्या तब होगी जब यह क्लाइंट मशीन पर होता है: यह देखते हुए कि आमतौर पर क्लाइंट सबसे अच्छा त्रुटि संवाददाता नहीं होते हैं, यह पता लगाने में बहुत लंबा लगता है कि क्या गलत है, जब वे मुझे प्रदान कर सकते हैं उपरोक्त विवरण।

प्रश्न: मैं इस तरह के दुर्घटनाओं के लिए अधिक जानकारी प्राप्त करने के लिए क्या कर सकता हूं? क्या इस तरह एक अपवाद प्राप्त करने का कोई तरीका है एक कस्टम त्रुटि हैंडलर वैसे भी? या एक प्रक्रिया डंप प्राप्त करें? जब msvcr100_clr0004.dll और clr.dll (धागा जहां तोड़ने occurrs पर लोड) के लिए प्रतीकों लोड हो रहा है, कॉल स्टैक इस तरह है:

msvcr100_clr0400.dll!__crt_debugger_hook() 
clr.dll!___report_gsfailure() + 0xeb bytes 
clr.dll!_DoJITFailFast@0() + 0x8 bytes 
clr.dll!CrawlFrame::CheckGSCookies() + 0x2c3b72 bytes 

मैं किसी भी तरह __crt_debugger_hook में कुछ देशी सी ++ कोड हुक कर सकते हैं() (उदाहरण के लिए एक मिनीडम्प लिखने के लिए)? जो मुझे एक अतिरिक्त प्रश्न की ओर ले जाता है: CheckGSCookies किसी मशीन पर कोई डीबगर स्थापित नहीं होता है, क्या यह अभी भी वही कोड कॉल करेगा?

अद्यतन कोड पर कुछ स्पष्टीकरण:। देशी सी ++ एक CLI प्रतिनिधि (जो करने के लिए एक देशी समारोह सूचक GetFunctionPointerForDelegate जो बारी में एक सी # System.Action कॉल का उपयोग कर प्राप्त किया जाता है कहता है यह कार्रवाई एक स्ट्रिंग (एक WPF करने के लिए बाध्य अद्यतन करता है लेबल) और एक PropertyChanged घटना उठाती है। यह किसी भी तरह जब एक अनाम धागा है कि मेरे कोड में सीधे नहीं बनाया गया था में बहुत तेजी से अद्यतन करना) एक बफर अतिप्रवाह का आह्वान (।

अद्यतनSetUnhandledExceptionFilter है, जो कुछ भी नहीं किया में देख सबसे पहले, मुझे this nifty article मिला कि यह कोई अपवाद कैसे पकड़ सकता है। यह काम करता है, और मैं अपवाद में एक मिनीडम्प लिखने में सक्षम था। उस प्रक्रिया का उपयोग करके स्थापित इल्टर। डंप मूल रूप से एक ही जानकारी देता है जो डीबगर को हुकिंग करता है: वास्तविक समस्या यह प्रतीत होती है कि स्थिति स्ट्रिंग को ओवरराइट किया जा रहा है (मूल धागे से बुलाया जा रहा है) जबकि एक ही समय में ui धागे से पढ़ा जा रहा है। सभी अच्छे उत्तर जैसे, लेकिन इसे डेल हुकिंग की आवश्यकता होती है जो चीजों को हल करने के लिए मेरी पसंदीदा विधि नहीं है। एक और तरीका अभी भी अच्छा होगा।

Answer 1

सीएलआर के .NET 4 संस्करण में बफर ओवरफ़्लो हमलों के खिलाफ सुरक्षा है। मूल योजना यह है कि कोड किसी सरणी या स्टैक फ्रेम के अंत में "कुकी" लिखता है, फिर बाद में जांच करता है कि उस कुकी के पास अभी भी मूल मान है। यदि यह बदल गया है, तो रनटाइम मानता है कि मैलवेयर ने प्रोग्राम राज्य से समझौता किया है और तुरंत प्रोग्राम को रोक दिया है। इस तरह की गर्भपात सामान्य अनचाहे अपवाद तंत्र से गुजरती नहीं है, जो बहुत शोषक होगी।

आपके प्रोग्राम वास्तव में पर हमला होने वाली बाधाएं बहुत कम हैं। अधिक संभावना है कि आपके मूल कोड में एक सीएलआर संरचना या ढेर फ्रेम में पॉइंटर बग और स्क्रिबल्स जंक है। डीबगिंग करना आसान नहीं है, दुर्घटना से पहले नुकसान आमतौर पर किया जाता है। एक दृष्टिकोण तब तक कोड को टिप्पणी करना है जब तक कि दुर्घटना गायब न हो जाए।