डिबगर सीखना, भाग तीन

डिबगर क्या है, इसका उपयोग कैसे करें और इसे कैसे लागू किया जाता है, लेख के पहले और दूसरे भाग को पढ़ने के बाद, आप जानते हैं। लेख के अंतिम भाग में, हम इसके संचालन के सिद्धांतों के ज्ञान के आधार पर डीबगर से निपटने के कुछ तरीकों पर विचार करने का प्रयास करेंगे। मैंने विरोधी डिबगिंग ट्रिक्स का एक टेम्प्लेट सेट नहीं दिया है, यदि आप चाहें, तो आप इंटरनेट पर यह सब पा सकते हैं, मैं इसे कुछ अलग तरीके से करने की कोशिश करूंगा, कुछ सार एप्लिकेशन के आधार पर, जहां से मैं सबसे सरल योजना से सुरक्षा कोड का विस्तार करूंगा ... जब तक मैं थक न जाऊं :)

तुरंत, मैं एक आरक्षण कर दूंगा, आवेदन / डिबगर के विरोध में, बाद वाला हमेशा जीत जाएगा :)
लेकिन, केवल अगर एक सक्षम विशेषज्ञ इसका उपयोग करेगा, और ऐसे विशेषज्ञों से निपटने के लिए व्यावहारिक रूप से बेकार है (ठीक है, जब तक कि आपके पास कम से कम समान योग्यता नहीं है)।

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

यहां कुछ ऐसा है जिस पर हम विचार करेंगे, केवल बहुत ही सरल रूप में।

सबसे सरल शेयरवेयर:

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

सबसे स्पष्ट समाधान कुंजी है। परीक्षण उपयोगकर्ता उसे नहीं जानता है, और कानूनी व्यक्ति, जिसने इसके लिए वास्तविक पैसे का भुगतान किया है, आवेदन की एक कानूनी प्रति को सक्रिय कर सकता है और तस्वीर का आनंद ले सकता है।

कुंजी तो कुंजी है।

हम एक नया वीसीएल एप्लिकेशन बनाते हैं, एक तस्वीर के साथ TImage फॉर्म पर फेंकते हैं, दृश्यमान को गलत पर सेट करते हैं। फिर हम फॉर्म पर दो टीईडिट डालते हैं, पहला यूजरनेम के लिए और दूसरा एक्टिवेशन कोड के लिए। खैर, दो बटन - एप्लिकेशन को बंद करें और सक्रिय करें।

खैर, कुछ इस तरह से:



जिसके बाद हम "शीर्ष गुप्त" सक्रियण कोड लिखते हैं:

function TForm1.GenerateSerial(const AppUserName: string): string; const MagicSerialMask: int64 = $C5315E6121543992; var I: Integer; SN: int64; RawSN: string; begin SN := 0; Result := ''; for I := 1 to Length(AppUserName) do begin Inc(SN, Word(AppUserName[I])); SN := SN * 123456; end; Sn := SN xor MagicSerialMask; RawSN := IntToHex(SN, 16); for I := 1 to 16 do if ((I - 1) mod 4 = 0) and (I > 1) then Result := Result + '-' + RawSN[I] else Result := Result + RawSN[I]; end; procedure TForm1.btnCheckSerialClick(Sender: TObject); begin if edSerial.Text <> GenerateSerial(edAppUserName.Text) then Application.MessageBox('  ', PChar(Application.Title), MB_OK or MB_ICONERROR) else begin Image1.Visible := True; Label1.Visible := False; Label2.Visible := False; Label3.Visible := False; edAppUserName.Visible := False; edSerial.Visible := False; btnCancel.Visible := False; btnCheckSerial.Visible := False; end; end; 

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

आइए इसे कहते हैं:



(ठीक है ... पहली बात मुझे मिली :)

जोड़तोड़ के बाद, "यह" विभिन्न शेयरवेयर साइटों पर प्रकाशित किया जाता है और यहां तक ​​कि कभी-कभी प्रोग्रामर मंचों के लिंक फॉर्म के विषयों में दिए जाते हैं: "टेस्ट प्लाज़ संरक्षण"।

और पटाखा कैसा दिखता है?

वह एक डिबगर लेता है (सादगी के लिए, वही ऑली डेबग लेते हैं) और इस तस्वीर को देखता है:



उसके पास एक आवेदन कोड नहीं है, लेकिन शुरुआत में सॉफ्टवेयर "डिफेंडर्स" की एक विशिष्ट गलती है - गलत कुंजी के बारे में एक संवाद प्रदर्शित करना।

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



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

किसी तरह यह स्पष्ट नहीं है, है ना?

ठीक है, यहाँ डेल्फी डीबगर से एक तस्वीर है:



यहां, डिबगिंग के लिए कोड अधिक समझ में आता है, और पतों की व्याख्या करने और उन्हें पढ़ने योग्य रूप में लाने के कारण इसका पढ़ना अधिक सुविधाजनक है। उदाहरण के लिए, अब यह स्पष्ट रूप से दिखाई दे रहा है कि पते पर पहुंचने से पहले 0x475729, जिस पर निर्णय किया जाता है, टेक्स्ट को टीईडिट्स से प्राप्त किया जाता है और जेनरेटसेरियल प्रक्रिया कहा जाता है।

पटाखा के पास ऐसी कोई जानकारी नहीं है, और जैसा कि पिछली छवि में देखा जा सकता है, विश्लेषण के लिए चित्र को अधिक या कम समझने के लिए उसे सभी कॉल का विश्लेषण करना होगा। खैर, सच्चाई यह है कि यहाँ मैं थोड़ा अतिरंजित करता हूं, वास्तव में एप्लिकेशन मैप काफी सरलता से बनाया गया है, उपकरण की उपलब्धता के साथ, लेकिन ... लेकिन कुछ लोग कभी-कभी डॉल्फिन के सिस्टम मॉड्यूल को डीबग करने के लिए कड़ी मेहनत करते हैं, उनकी दृढ़ता के लिए सम्मान और प्रशंसा :)

खैर, बारीकियों पर 0x475729 पर स्क्रीनशॉट दो अलग-अलग निर्देश हैं - जेडजेड और जेई, ये डिस्क्लेमर की व्याख्या करने की बारीकियां हैं, वे समान हैं।

एक दिलचस्प दृष्टिकोण है जिसे कई बार मुझे आवाज दी गई है।
यहाँ थोड़ा अधिक है, मैंने घोषणा की कि मैं मैसेजबॉक्सए पर बीपी डालूंगा, और उन्होंने मुझे बताया कि वे मैसेजबॉक्स को कॉल करेंगे और कॉल को पकड़ा नहीं जा सकता। यह कथन एक ठोस चार के लिए एक प्लस के साथ है, हां, वास्तव में, यदि एप्लिकेशन यूनिकोड एपीआई को कॉल करता है, तो ब्रेकडाउन के साथ एक छोटी सी चूक होगी, लेकिन एक अति सूक्ष्म अंतर है। आइए पूरे मैसेजबॉक्स कॉल स्टैक का विस्तार करें।

देखें कि यह क्या दिलचस्प योजना है:
MessageBoxA -> MessageBoxExA -> MessageBoxTimeOutA -> MessageBoxTimeOutW-> SoftModalMessageBox ()

तो हाँ, हम किसी भी सूचीबद्ध फ़ंक्शन (आमतौर पर MessageBoxTimeOutW पर्याप्त है) के कॉल पर बीपी डाल सकते हैं, जिस कॉल को हमें ज़रूरत है उसे पकड़ने के लिए, जिस तरह से मैसेजबॉक्स डब्ल्यू फ़ंक्शन भी कॉल करेगा।

वहाँ वास्तव में एक छोटी सी अति सूक्ष्म अंतर है, डेल्फी में एक खिड़की प्रदर्शित करने के अन्य तरीके हैं।

खैर, उदाहरण के लिए ShowMessage ()। यह विधि MessageBox API को कॉल नहीं करती है।
यह तर्क को सुनने के लिए पर्याप्त है कि इस पद्धति को पूरी तरह से एक अलग रूप बनाने के लिए लागू किया जाता है जिसमें बटन आवश्यक रूप से लगाए जाते हैं और सामान्य तौर पर ये वीसीएल के आंतरिक होते हैं, जिनमें से डीबगर में कुछ भी स्पष्ट नहीं होता है।
यह कैसे होता है, अगर यह कॉल ShowWindow API पर आराम नहीं करता है, जिससे हम कोड की आवश्यकता पर भी निकल जाएंगे।

अभी भी बातचीत की चुनौतियां हैं, लेकिन उनके पास बिल्कुल वही व्यंजन होंगे। यह सब बहुत समय के बिना पता चला है।

इसलिए, अपनी नोटबुक में पहला निष्कर्ष निकालें:
इस चेक के तुरंत बाद एक असफल कोड जांच के बारे में एक संदेश कॉल करना खराब स्वाद का संकेत है।

परिचय आवेदन अखंडता नियंत्रण:

तब ठीक है - उन्होंने हमें हैक कर लिया, और आवेदन के एक ही बाइट में केवल एक बदलाव किया। अब हमारी मजेदार तस्वीर हर किसी के लिए बिल्कुल मुफ्त में उपलब्ध है।

दुख की बात है, लेकिन महत्वपूर्ण नहीं - हम लड़ेंगे ...

हैकिंग एप्लिकेशन बॉडी के सीधे संपादन के माध्यम से हुई।
इसलिए कार्य बड़ा हो गया है: स्रोत कोड की अखंडता का सत्यापन प्रदान करने के लिए।

यह menacing लगता है, लेकिन वास्तव में यह व्यावहारिक रूप से असंभव है :)

हम इस परीक्षा के लिए क्या आवेदन कर सकते हैं?
बहुत सारे buzzwords हैं: डिजिटल रूप से साइन, डिस्क पर फ़ाइल की छवि को सत्यापित करें, कोड अनुभाग को चेकसम के साथ जांचें। सब कुछ खाली है - अंत में, वैसे भी, हमें किसी तरह मेमोरी में एप्लिकेशन कोड का वर्तमान मूल्य प्राप्त करने की आवश्यकता है ...

खैर, हम एक डिजिटल हस्ताक्षर देख रहे हैं। उसने, सबसे पहले, भुगतान किया। दूसरे, यह WinVerifyTrust फ़ंक्शन के एपीआई को कॉल करके जांचा जाता है, जो अवरोधन के लिए असुरक्षित है। तीसरा, यह ImageRemoveCertificate के माध्यम से नियमित रूप से आसानी से हटा दिया जाता है।

तो यह एक विकल्प नहीं है, हमें डिस्क पर फ़ाइल की छवि की जांच करने के लिए क्या करना है?
यहाँ भी, सब कुछ दुखी है। देखो, हमारी निष्पादन योग्य फ़ाइल को पैच किया गया था, हम इसे डिस्क पर छवि के साथ तुलना करके यह निर्धारित करना चाहते हैं कि हम क्या करते हैं उसी ParamStr (0) के माध्यम से वर्तमान फ़ाइल को पथ मिलता है (उदाहरण के लिए), फिर इस पथ पर फ़ाइल खोलें और जाँच शुरू करें, लेकिन ...
लेकिन OpenFile / CreateFile को कॉल करने के चरण में, पटाखा मूल पैरामीटर, अनमॉडिफाइड छवि के पथ के साथ संगत पैरामीटर में पथ को बदल देता है, और हमारे सभी चेक जंगल से गुजरते हैं।

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

उदाहरण के लिए, हमारे डिबगर को पिछले लेख से लें और इसका उपयोग जादू की तस्वीर के साथ हमारे एप्लिकेशन को लॉन्च करने के लिए करें, और प्रवेश बिंदु पर पहुंचने पर हम निम्नलिखित कोड निष्पादित करेंगे:

 procedure TTestDebugger.OnBreakPoint(Sender: TObject; ThreadIndex: Integer; ExceptionRecord: Windows.TExceptionRecord; BreakPointIndex: Integer; var ReleaseBreakpoint: Boolean); var JmpOpcode: Byte; begin if ExceptionRecord.ExceptionAddress = Pointer(FCore.DebugProcessData.EntryPoint) then begin JmpOpcode := $EB; FCore.WriteData(Pointer($475729), @JmpOpcode, 1); 

डिस्क पर एप्लिकेशन अपरिवर्तित रहेगा, लेकिन जेई निर्देश के बजाय, रिकॉर्ड किए गए जेएमपी अनुदेश के कारण एक सीधा कूद किया जाएगा। जो पहले से ही बहुत दुखी है, क्योंकि इस मामले में, अखंडता की जाँच करने के लिए पहले दो विकल्प काम नहीं करने की गारंटी देते हैं।

तीसरा विकल्प रहता है, एप्लिकेशन बॉडी में सीधे कोड सेक्शन की जाँच करना।
यह कार्यान्वयन के लिए एक बजाय संसाधन-गहन विकल्प है और निम्नलिखित कारणों से हमेशा सफलता की ओर अग्रसर नहीं होता है।

सबसे पहले, चेकसम कॉन्स्टेंट। यदि वे आवेदन के शरीर में संग्रहीत होते हैं, तो पटाखा उन्हें सही वाले में बदल देगा। (आपकी नोटबुक के लिए दूसरा निष्कर्ष आवेदन में कोड ब्लॉक के सीआरसी स्थिरांक हैं, एक बुरा स्वर है)।
दूसरे, लेख के दूसरे भाग में मैंने MIA के बारे में बात की - मेमोरी ब्रेकप्वाइंट। कोड अखंडता जांच का पता लगाने के लिए यह एक आदर्श तंत्र है (यदि आप अधिक सक्षम HBP - हार्डवेयर ब्रेकप्वाइंट को ध्यान में नहीं रखते हैं)।

यह बस काम करता है - यदि संदेह है कि कोड का वर्तमान खंड सुरक्षा तंत्र द्वारा नियंत्रित किया जाता है, तो एमवीआर या एचबीपी को यह निर्धारित करने के लिए उस पर लटका दिया जाता है जहां कोड अखंडता की जांच स्वयं स्थित है।
यदि इस तरह की जांच का पता चला है, तो यह पैच द्वारा भी अक्षम है।

खैर, हम वास्तव में गतिरोध के लिए रवाना हुए: ग्राहक ग्राहक नहीं है :)

हालांकि ...



यह संभव है, निश्चित रूप से, लेकिन ...
लेकिन पहले, आइए देखें कि सामान्य रूप से एप्लिकेशन कोड अखंडता जांच को कैसे लागू किया जाए।

विशेष रूप से, हम उस कोड की सुरक्षा करना चाहते हैं जो परिवर्तनों से बहुत शुरुआत में था। ऐसा करने के लिए, हमें किसी तरह एप्लिकेशन को चलाने के दौरान मेमोरी में उसकी लोकेशन का पता लगाना होगा।

लेबल हमारे "सब कुछ" हैं।
अधिकांश टिका हुआ रक्षक लेबल के आधार पर काम करते हैं, इसलिए हमें दूसरी बाइक के साथ क्यों आना चाहिए। एक लेबल क्या है - सिद्धांत रूप में, यह एक ऐसा लेबल है जो हर किसी के द्वारा अप्रकाशित है, गोटो () के साथ उपयोग किया जाता है, जिसके बारे में केवल सबसे आलसी ने अपने उच्च योग्य "एफआई" को व्यक्त नहीं किया है।
हालाँकि ... हम उनके बारे में क्या सोचते हैं? जैसा कि मैंने कहा - हमारे टैग सभी हैं :)

सच है, एक बारीकियों है, प्रक्रिया के अंदर कोड के एक छोटे हिस्से को नियंत्रित करने के लिए लेबल का उपयोग करना सुविधाजनक है (क्रॉस-चेकिंग के लिए - इसके बारे में बाद में), अब हम कुल कई प्रक्रियाओं में रुचि रखते हैं।

इसके लिए, लेबल काम नहीं करेगा, लेकिन लेबल के रूप में रिक्त प्रक्रियाएं, जिनमें से पता हम अखंडता चेक कोड से प्राप्त कर सकते हैं, करेंगे।

खैर, अखंडता की गणना करने के लिए पूरी प्रक्रिया को ढेर करने की आवश्यकता है, और यह भी (जो वास्तव में ऊपर की गई बारीकियों में से एक था) एक निश्चित निरंतर जिसके साथ हम डेटा ब्लॉक के सीआरसी की तुलना करेंगे।

ठीक है, पर्याप्त बंद करो, हम लिखते हैं:

 const CheckedCodeValidCheckSum: DWORD = 248268; // <<       procedure CheckedCodeBegin; begin end; function TForm1.CalcCheckSum(Addr: Pointer; Size: Integer): DWORD; var pCursor: PByte; I: Integer; Dumee: DWORD; begin Result := 0; pCursor := Addr; for I := 0 to Size - 1 do begin if pCursor^ <> 0 then Inc(Result, pCursor^) else Dec(Result); Inc(pCursor); end; end; procedure TForm1.CheckCodeProtect; var CheckedCodeBeginAddr, CheckedCodeEndAddr: Pointer; CurrentCheckSum: DWORD; begin //      CheckedCodeBeginAddr := @CheckedCodeBegin; //      CheckedCodeEndAddr := @CheckedCodeEnd; //        CurrentCheckSum := CalcCheckSum(CheckedCodeBeginAddr, Integer(CheckedCodeEndAddr) - Integer(CheckedCodeBeginAddr)); if CurrentCheckSum <> CheckedCodeValidCheckSum then begin MessageBox(Handle, '   .', PChar(Application.Title), MB_ICONERROR); TerminateProcess(GetCurrentProcess, 0); end; end; function TForm1.GenerateSerial(const AppUserName: string): string; const MagicSerialMask: int64 = $C5315E6121543992; var I: Integer; SN: int64; RawSN: string; begin SN := 0; Result := ''; for I := 1 to Length(AppUserName) do begin Inc(SN, Word(AppUserName[I])); SN := SN * 123456; end; Sn := SN xor MagicSerialMask; RawSN := IntToHex(SN, 16); for I := 1 to 16 do if ((I - 1) mod 4 = 0) and (I > 1) then Result := Result + '-' + RawSN[I] else Result := Result + RawSN[I]; end; procedure TForm1.btnCheckSerialClick(Sender: TObject); begin //    CheckCodeProtect; if edSerial.Text <> GenerateSerial(edAppUserName.Text) then ShowMessage('  ') else begin Image1.Visible := True; Label1.Visible := False; Label2.Visible := False; Label3.Visible := False; edAppUserName.Visible := False; edSerial.Visible := False; btnCancel.Visible := False; btnCheckSerial.Visible := False; end; end; procedure CheckedCodeEnd; begin end; 

हमारे यहाँ क्या है:
दो प्रक्रियाओं के रूप में खाली प्रक्रियाओं CheckedCodeBegin और CheckedCodeEnd, इन दो लेबल के बीच डेटा के "चेकसम" की गणना, CheckCodeProtect प्रक्रिया द्वारा किया जाता है, अच्छी तरह से, चेकसम खुद, चेक किए जा रहे कोड के क्षेत्र से बाहर ले जाया गया और CheckedCodeValidCheckSum निरंतर (ध्यान नहीं देते) के क्षेत्र से बाहर ले जाता है।

सिद्धांत रूप में, कुछ भी जटिल नहीं है, लेकिन चलो इसका विश्लेषण करते हैं, लेकिन यह हमें क्या देता है?

वास्तव में बहुत कुछ, क्योंकि:

1. यह कोड डिस्क पर एप्लिकेशन बॉडी के एक पैच का पता लगाता है (क्योंकि जब यह शुरू होता है, तो यह पहले से ही बाइट्स बदल चुका होता है)।
2. यह कोड लोडर द्वारा आवेदन निकाय के एक पैच का पता लगाता है (जैसा कि ऊपर वर्णित है)।
3. और यह कोड पता लगाता है ... पिछले लेख से चित्र याद है?

हां, हां, यह डीबगर द्वारा स्थापित ब्रेकपॉइंट है। और उसका दिया गया कोड भी पूरी तरह से पता लगाता है, क्योंकि यदि आपको याद है, तो बीपी इंस्टॉलेशन तंत्र में एप्लिकेशन बॉडी को संशोधित करना शामिल है।

यहां आपकी नोटबुक में तीसरा नोट है - बीपी का पता लगाने के लिए कोड की बॉडी की जाँच की जाती है।

सच है, दुर्भाग्य से, यहां सब कुछ इतना सरल नहीं है, कुछ मामलों में यह कोड काम नहीं करेगा, लेकिन हम जल्दी नहीं करेंगे, हम इसे प्राप्त करेंगे।

अब, दुख की बात है, जैसा कि मैंने कहा, यह जाँच आसानी से पता चल जाती है। उदाहरण के लिए, यहां डिबगर के नीचे एक स्क्रीनशॉट है, जहां स्कैन की शुरुआत में इसे तुरंत बाधित किया जाता है:



चेकसम गणना प्रक्रिया के लिए कोड को नीले रंग में हाइलाइट किया गया है, डिबगर को 0x467069 पते पर बाधित किया गया था, बस संरक्षित क्षेत्र को पढ़ने के पहले ही प्रयास में।
ठीक है, अधिक सटीक रूप से, यहां मैंने थोड़ा धोखा दिया, अगर सत्यापन कोड की जाँच की जा रही क्षेत्र के दायरे से बाहर थी, तो स्टॉप बस इस निर्देश पर हुआ होगा, और इसलिए, निश्चित रूप से, मैं पहले "PUSH EBX" पर रुक गया।

लेकिन यह गीत है, सवाल अलग है, और अब क्या करना है?

खैर, सबसे पहले, सब कुछ इतना डरावना नहीं है। यहां, एप्लिकेशन कोड की अखंडता का केवल एक ही चेक लागू किया गया है। हां, यह आसानी से पता चल जाता है। हां, इसे आसानी से एक पैच के साथ हटा दिया जाता है, लेकिन हमें उनमें से कई को एक-दूसरे को क्रॉस-कंट्रोल करने से क्या रोकता है? क्या उन्हें भी हटाया जाएगा? ठीक है, एक सवाल नहीं है, और अधिक जोड़ें, लेकिन यह हमारे लिए क्या खर्च करता है?

एक बार जब मैं सीधे सुरक्षा के डेवलपर्स द्वारा सीधे आवेदन सुरक्षा के विश्लेषण के लिए एक उत्पाद भेजा गया था (क्षमा करें - कोई नाम नहीं)। वीएम आरंभीकरण कोड को देखते हुए, मैंने तुरंत इसके विश्लेषण के लिए पथ को रेखांकित किया, मुझे केवल एक विशिष्ट एपीआई फ़ंक्शन को कॉल करते समय छोटे डेटा ब्लॉकों के क्रिप्ट एल्गोरिथ्म को बाहर निकालना था। समस्या यह थी कि जैसे ही मैंने आवेदन का एक बाइट पैच किया, चेकसम सत्यापन तंत्र ने काम किया। स्वाभाविक रूप से, मैंने जल्दी से इसे बाढ़ दिया, लेकिन जैसा कि यह निकला, बाढ़ कोड को चार अलग-अलग एल्गोरिदम द्वारा नियंत्रित किया गया था। मैंने उन्हें पटकना शुरू कर दिया और आपको क्या लगता है? प्रत्येक पैच के लिए, हमने कोड के अधिक से अधिक टुकड़ों को समझा जो एक हिमस्खलन की तरह कोड की अखंडता को नियंत्रित करते हैं। नतीजतन, मैं सिर्फ मैनुअल पैच की मात्रा में डूब गया और मुझे एक स्वचालित उपयोगिता / डिबगर लिखना पड़ा, जिसमें लगभग सभी बारीकियों को ध्यान में रखते हुए, लगभग एक सप्ताह का काम किया गया। और अंत में, मैं संरक्षण कोर के अगले स्तर में भाग गया।
हालांकि, यह अब महत्वपूर्ण नहीं है, अर्थ महत्वपूर्ण है - यदि आप चाहें, तो पटाखे के लिए एक अच्छा सिरदर्द लागू करना संभव है, यहां तक ​​कि चेकसम के एक तुच्छ सत्यापन पर भी।

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

सच्चाई यह है कि, हम डेमो एप्लिकेशन में PAGE_GUARD को हटाने के विकल्प पर विचार नहीं करेंगे। लेकिन चिंता न करें, मैं आपको एक और दिलचस्प तरीका दिखाऊंगा, केवल इसके लिए आपको कुछ और बारीकियों पर विचार करने की आवश्यकता है, इसलिए थोड़ी देर बाद।

ठीक है, अब से, हम मानते हैं कि एप्लिकेशन अखंडता नियंत्रण कोड लिखा गया है ताकि इसे हैक नहीं किया जा सके (सरल बनाने के लिए) ...

डिबगर का पता लगाना

खैर, अब हम इस निष्कर्ष पर पहुंचे हैं कि हम एक तस्वीर के साथ, और एक डिबगर की मदद से अपना रूप चाहते हैं। बेशक आपको यह जानने की जरूरत है कि इसका पता कैसे लगाया जाए। अभी के लिए, आइस्डबगरपर्सेंट फंक्शन पर चलें, यह एक शुरुआत के लिए पर्याप्त है।

हम कोड लिखते हैं:

 function IsDebuggerPresent: BOOL; stdcall; external kernel32; procedure TForm1.FormCreate(Sender: TObject); begin if IsDebuggerPresent then begin MessageBox(Handle, '    .', PChar(Application.Title), MB_ICONERROR); TerminateProcess(GetCurrentProcess, 0); end; end; 

सब कुछ बहुत सरल है, अगर हम डिबगर के अधीन हैं, तो यह फ़ंक्शन ट्रू वापस आ जाएगा।
हम मानते हैं कि एप्लिकेशन की अखंडता की जांच करने के लिए कोड इतना जटिल है कि इसे पैच करना असंभव है और इस फ़ंक्शन को कॉल एक संरक्षित क्षेत्र में रखा गया है।
इस मामले में पटाखा क्या लागू होगा?

वास्तव में केवल तीन विकल्प हैं, इस तथ्य को देखते हुए कि आप अनुप्रयोग निकाय को पैच नहीं कर सकते हैं:

1. बीपी को इस फ़ंक्शन के कॉल पर रखें, जहां इसके कॉल के परिणाम को बदलना है।
2. इस फंक्शन के कोड को पैच करें ताकि यह हमेशा फाल्स लौटे
3. डीबग की गई प्रक्रिया के पता स्थान में Peb.BeingDebugged चर में परिवर्तन करें।

तीसरे विकल्प से निपटना मुश्किल है (यह संभव है, लेकिन आवश्यक नहीं), लेकिन हम पहले दो पर और अधिक विस्तार से विचार करेंगे, अधिक सटीक रूप से हम दूसरे विकल्प पर विचार करेंगे, क्योंकि पहली में, 0xCC ओपकोड के साथ BP स्थापित करते समय एप्लिकेशन कोड पैच भी उत्पन्न होता है।

सबसे पहले, डिबग किए गए एप्लिकेशन में इस कोड को फॉर्मक्रिएट प्रक्रिया में जोड़ें:

 procedure TForm1.FormCreate(Sender: TObject); var P: PCardinal; begin P := GetProcAddress(GetModuleHandle(kernel32), 'IsDebuggerPresent'); ShowMessage(IntToHex(P^, 8)); 

यह IsDebuggerPresent फ़ंक्शन के पहले 4 बाइट्स दिखाएगा।

आप ऐसा कोड नहीं लिख सकते:

 function IsDebuggerPresent: BOOL; stdcall; external kernel32; procedure TForm1.FormCreate(Sender: TObject); var P: PCardinal; begin P := @IsDebuggerPresent; ShowMessage(IntToHex(P^, 8)); 

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

आइए कोड को निष्पादित करें और मूल्य याद रखें।

प्रत्येक प्रणाली के तहत, यह अलग होगा, उदाहरण के लिए, एक्सपी में यह मूल फ़ंक्शन का शरीर होगा, सात में कर्नेलबेस से एनालॉग के लिए एक एडेप्टर होगा। मुझे मूल्य 9090F3EB मिला, जो निम्नलिखित चित्र से मेल खाता है:



अब, हमारे डिबगर को लेख के दूसरे भाग से लेते हैं, और ऑनब्रेक्राफ्ट विधि में हम इस कोड के साथ इस फ़ंक्शन के शरीर को पैच करेंगे:

 procedure TTestDebugger.HideDebugger; const PachBuff: array [0..2] of Byte = ( $31, $C0, // xor eax, eax $C3 // ret ); var Addr: Pointer; begin Addr := GetProcAddress(GetModuleHandle(kernel32), 'IsDebuggerPresent'); FCore.WriteData(Addr, @PachBuff[0], 3); end; procedure TTestDebugger.OnBreakPoint(Sender: TObject; ThreadIndex: Integer; ExceptionRecord: Windows.TExceptionRecord; BreakPointIndex: Integer; var ReleaseBreakpoint: Boolean); var JmpOpcode: Byte; begin if ExceptionRecord.ExceptionAddress = Pointer(FCore.DebugProcessData.EntryPoint) then begin HideDebugger; 

यहाँ एक बारीकियों है, kern32.dll लाइब्रेरी का पता सभी अनुप्रयोगों के लिए समान है, इसलिए डीबगररपर्सेंट फ़ंक्शन का पता डीबगर और डीबग किए गए एप्लिकेशन में समान होगा।

पैच का अर्थ EAX रजिस्टर को शून्य करना है, जिसके माध्यम से फ़ंक्शन का परिणाम वापस आ जाता है और उस कोड पर लौटता है जो इस फ़ंक्शन को कॉल करता है।

हम डिबगर शुरू करते हैं, यह हमारे एप्लिकेशन को लॉन्च करेगा और प्रक्रिया मेमोरी में हस्तक्षेप करने के परिणामस्वरूप, डिबगर के फॉर्मक्रिएट फ़ंक्शन में कोड का पता नहीं लगाया जाएगा। सच है, अब इस फ़ंक्शन के पहले 4 बाइट्स को पढ़ने वाला कोड 9090F3EB नहीं, बल्कि 90C3C031 नंबर को लौटाएगा, जो पैच के ऑपकोड से मेल खाता है।

हम यह कैसे निर्धारित कर सकते हैं कि किसी दिए गए फ़ंक्शन का शरीर पैच है? सिद्धांत रूप में, हम डिस्क पर स्थित कर्नेल 32.dll फ़ाइल से इस फ़ंक्शन के पहले 4 बाइट्स पढ़ सकते हैं, लेकिन इस मामले में, जब आप लाइब्रेरी बॉडी खोलते हैं, तो हमें उसी पैच फ़ाइल में पथ के साथ प्रतिस्थापित किया जा सकता है और चेक यह कहेगा कि सब कुछ ठीक है।

लेकिन एक और तरीका है जो शायद ही कभी अभ्यास में उपयोग किया जाता है (मुझे मिला है, अगर मैं गलत नहीं हूं, केवल 1 बार) और यह निम्नलिखित में शामिल है।

चूँकि हम डिस्क से सही मान नहीं पढ़ सकते हैं, हम इसे किसी अन्य प्रक्रिया की स्मृति से प्राप्त 4 बाइट्स को पढ़कर प्राप्त कर सकते हैं। , - - , .

:

 function IsDebuggerPresent: BOOL; stdcall; external kernel32; procedure TForm1.CheckIsDebugerPresent; var Snapshot: THandle; ProcessEntry: TProcessEntry32; ProcessHandle: THandle; pIsDebuggerPresent: PDWORD; OriginalBytes: DWORD; lpNumberOfBytesRead: DWORD; begin pIsDebuggerPresent := GetProcAddress(GetModuleHandle(kernel32), 'IsDebuggerPresent'); Snapshot := CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if Snapshot <> INVALID_HANDLE_VALUE then try ProcessEntry.dwSize := SizeOf(TProcessEntry32); if Process32First(Snapshot, ProcessEntry) then begin repeat if ProcessEntry.th32ProcessID = GetCurrentProcessId then Continue; ProcessHandle := OpenProcess(PROCESS_ALL_ACCESS, False, ProcessEntry.th32ProcessID); if ProcessHandle <> 0 then try if ReadProcessMemory(ProcessHandle, pIsDebuggerPresent, @OriginalBytes, 4, lpNumberOfBytesRead) then begin if OriginalBytes <> pIsDebuggerPresent^ then begin MessageBox(Handle, ' IsDebuggerPresent .', PChar(Application.Title), MB_ICONERROR); TerminateProcess(GetCurrentProcess, 0); end; if IsDebuggerPresent then begin MessageBox(Handle, '    .', PChar(Application.Title), MB_ICONERROR); TerminateProcess(GetCurrentProcess, 0); end; end; finally CloseHandle(ProcessHandle); end; until not Process32Next(Snapshot, ProcessEntry) end; finally CloseHandle(Snapshot); end; end; procedure TForm1.FormCreate(Sender: TObject); begin CheckIsDebugerPresent; CheckCodeProtect; end; 

TlHelp32 , .

— API , , , .

, , IsDebuggerPresent kernel32.dll kernelbase.dll, , .

. , , .

.

, , , ?

, , , .

, , CheckIsDebugerPresent, -, . DebugActiveProcess, DbgUiRemoteBreakin. .

, DbgUiRemoteBreakin, TerminateProcess, , , .

:

 type TDbgUiRemoteBreakinPath = packed record push0: Word; push: Byte; CurrProc: DWORD; moveax: byte; TerminateProcAddr: DWORD; calleax: Word; end; procedure TForm1.BlockDebugActiveProcess; var pDbgUiRemoteBreakin: Pointer; Path: TDbgUiRemoteBreakinPath; OldProtect: DWORD; begin pDbgUiRemoteBreakin := GetProcAddress(GetModuleHandle('ntdll.dll'), 'DbgUiRemoteBreakin'); if pDbgUiRemoteBreakin = nil then Exit; Path.push0 := $006A; Path.push := $68; Path.CurrProc := $FFFFFFFF; Path.moveax := $B8; Path.TerminateProcAddr := DWORD(GetProcAddress(GetModuleHandle(kernel32), 'TerminateProcess')); Path.calleax := $D0FF; if VirtualProtect(pDbgUiRemoteBreakin, SizeOf(TDbgUiRemoteBreakinPath), PAGE_READWRITE, OldProtect) then try Move(Path, pDbgUiRemoteBreakin^, SizeOf(TDbgUiRemoteBreakinPath)); finally VirtualProtect(pDbgUiRemoteBreakin, SizeOf(TDbgUiRemoteBreakinPath), OldProtect, OldProtect); end; end; procedure TForm1.FormCreate(Sender: TObject); begin BlockDebugActiveProcess; CheckIsDebugerPresent; CheckCodeProtect; end; 

DbgUiRemoteBreakin :



TerminateProcess ( ), uExitCode hProcess, DWORD(-1) . EAX TerminateProcess .

, — CREATE_PROCESS_DEBUG_EVENT, , , ..

.
, , , , DebugActiveProcess. ( , ...)

Memory Breakpoint

, PAGE_GUARD. VirtualQuery, VirtualProtect.

ReadProcessMemory. , . , PAGE_GUARD , , EXCEPTION_GUARD_PAGE . « ». , . , , Hardware Breakpoint , / .

CalcCheckSum :

 function TForm1.CalcCheckSum(Addr: Pointer; Size: Integer): DWORD; var pRealData, pCursor: PByte; I: Integer; Dumee: DWORD; begin pRealData := GetMemory(Size); try ReadProcessMemory(GetCurrentProcess, Addr, pRealData, Size, Dumee); Result := 0; pCursor := pRealData; for I := 0 to Size - 1 do begin if pCursor^ <> 0 then Inc(Result, pCursor^) else Dec(Result); Inc(pCursor); end; finally FreeMemory(pRealData); end; end; 

, , .

?

, , .

, , , .

. :

 constructor TTestDebugger.Create(const Path: string); begin FCore := TFWDebugerCore.Create; if not FCore.DebugNewProcess(Path, True) then RaiseLastOSError; FCore.OnCreateProcess := OnCreateProcess; FCore.OnLoadDll := OnLoadDll; FCore.OnDebugString := OnDebugString; FCore.OnBreakPoint := OnBreakPoint; FCore.OnHardwareBreakpoint := OnHardwareBreakpoint; FCore.OnUnknownBreakPoint := OnUnknownBreakPoint; FCore.OnUnknownException := OnUnknownException; end; destructor TTestDebugger.Destroy; begin FCore.Free; inherited; end; 

, , , .

. IsDebuggerPresent, ( ) — Peb.BeingDebugged.

:

 procedure TTestDebugger.HideDebugger(hProcess: THandle); var pProcBasicInfo: PROCESS_BASIC_INFORMATION; pPeb: PEB; ReturnLength: DWORD; begin if NtQueryInformationProcess(hProcess, 0, @pProcBasicInfo, SizeOf(PROCESS_BASIC_INFORMATION), @ReturnLength) <> STATUS_SUCCESS then RaiseLastOSError; if not ReadProcessMemory(hProcess, pProcBasicInfo.PebBaseAddress, @pPeb, SizeOf(PEB), ReturnLength) then RaiseLastOSError; pPeb.BeingDebugged := False; if not WriteProcessMemory(hProcess, pProcBasicInfo.PebBaseAddress, @pPeb, SizeOf(PEB), ReturnLength) then RaiseLastOSError; end; 

, , BeingDebugged . IsDebuggerPresent . .

, — - .

:

( ). - . JE, if value then..else, , .. value : then else.

JE , ZF. . JE .

JE, .. , . . crackme.exe, - , , . 0467840.

:

 procedure TTestDebugger.OnBreakPoint(Sender: TObject; ThreadIndex: Integer; ExceptionRecord: Windows.TExceptionRecord; BreakPointIndex: Integer; var ReleaseBreakpoint: Boolean); begin if ExceptionRecord.ExceptionAddress = Pointer(FCore.DebugProcessData.EntryPoint) then begin Writeln; Writeln(Format('!!! --> Process Entry Point found. Address: %p', [Pointer(FCore.DebugProcessData.EntryPoint)])); Writeln; HideDebugger(FCore.DebugProcessData.AttachedProcessHandle); FCore.SetHardwareBreakpoint(ThreadIndex, Pointer($467840), hsByte, hmExecute, 0, 'wait JE'); end else begin Writeln; Writeln(Format('!!! --> BreakPoint at addr 0X%p - "%s"', [ExceptionRecord.ExceptionAddress, FCore.BreakpointItem(BreakPointIndex).Description])); Writeln; end; end; 

:

 procedure TTestDebugger.OnHardwareBreakPoint(Sender: TObject; ThreadIndex: Integer; ExceptionRecord: Windows.TExceptionRecord; BreakPointIndex: THWBPIndex; var ReleaseBreakpoint: Boolean); var ThreadData: TThreadData; begin Writeln; ThreadData := FCore.GetThreadData(ThreadIndex); Writeln(Format('!!! --> Hardware BreakPoint at addr 0X%p - "%s"', [ExceptionRecord.ExceptionAddress, ThreadData.Breakpoint.Description[BreakPointIndex]])); FCore.SetFlag(ThreadIndex, EFLAGS_ZF, True); Writeln; end; 

, , .

परिणाम कुछ इस तरह होगा:



, , , , :)

Hardware BreakPoint:

, , , . , .

, GetThreadContext DR7 ( — ), , API , .

 procedure TForm1.CheckHardwareBreakPoint; var Context: TContext; begin Context.ContextFlags := CONTEXT_DEBUG_REGISTERS; GetThreadContext(GetCurrentThread, Context); if Context.Dr7 <> 0 then begin MessageBox(Handle, ' HardwareBreaakPoint.', PChar(Application.Title), MB_ICONERROR); TerminateProcess(GetCurrentProcess, 0); end; end; 

, _except_handler.

 type //    TSeh = packed record Esp, Ebp, SafeEip: DWORD; end; var seh: TSeh; function _except_handler(ExceptionRecord: PExceptionRecord; EstablisherFrame: Pointer; Context: PContext; DispatcherContext: Pointer): DWORD; cdecl; const ExceptionContinueExecution = 0; begin if Context^.Dr7 <> 0 then begin MessageBox(0, ' HardwareBreaakPoint.', PChar(Application.Title), MB_ICONERROR); TerminateProcess(GetCurrentProcess, 0); end; //     Context^.Eip := seh.SafeEip; Context^.Esp := seh.Esp; Context^.Ebp := seh.Ebp; //     Result := ExceptionContinueExecution; end; procedure TForm1.CheckHardwareBreakPoint2; asm //  SEH  push offset _except_handler xor eax, eax push fs:[eax] mov fs:[eax], esp //     lea eax, seh mov [eax], esp add eax, 4 mov [eax], ebp add eax, 4 lea ecx, @done mov [eax], ecx //   mov eax, [0] @done: //  SEH  xor eax, eax pop fs:[eax] add esp, 4 end; 

. , . except, try..finally..except SEH :)

सारांश

, , , .

: http://rouse.drkb.ru/blog/dbg_part3.zip

.
, . , :)

, .

© (Rouse_)
, 2012