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

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

यदि आप डिबगर के काम से पहले से परिचित हैं - यह ठीक है, तो संभावना है कि लेख में उल्लिखित इसके काम के कुछ पहलू आपके लिए रूचि के होंगे।

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

मैं इसका केवल एक सरल भाषा में वर्णन करने की कोशिश करूंगा, ताकि आपके पास एक ऐसा बिंदु हो जिससे आप अचानक से दिलचस्पी लेने पर धक्का दे सकें, और निश्चित रूप से, यदि आप आवेदन संरक्षण को लागू कर रहे हैं, तो आपको कम से कम डिबगर की पेचीदगियों को समझने की आवश्यकता है (अन्यथा कैसे?)।

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

आप से, कोडांतरक का कम से कम न्यूनतम ज्ञान होना वांछनीय है, क्योंकि अफसोस, यह लेख इसके बिना नहीं कर सकता।

चलिए डिबगर को प्रक्रिया से जोड़कर शुरू करते हैं:

एक प्रक्रिया से जुड़ने से पहले, डिबगिंग विशेषाधिकार प्राप्त करने के लिए पहला कदम है। यह इस तरह के सरल कोड के साथ किया जाता है:

function SetDebugPriv: Boolean; var Token: THandle; tkp: TTokenPrivileges; begin Result := false; if OpenProcessToken(GetCurrentProcess, TOKEN_ADJUST_PRIVILEGES or TOKEN_QUERY, Token) then begin if LookupPrivilegeValue(nil, PChar('SeDebugPrivilege'), tkp.Privileges[0].Luid) then begin tkp.PrivilegeCount := 1; tkp.Privileges[0].Attributes := SE_PRIVILEGE_ENABLED; Result := AdjustTokenPrivileges(Token, False, tkp, 0, PTokenPrivileges(nil)^, PDWord(nil)^); end; end; end; 

अगला चरण निर्धारित किया गया है: क्या हम पहले से चल रही प्रक्रिया में शामिल हो जाएंगे, या हम खरोंच से एक नई प्रक्रिया शुरू करेंगे।

यदि प्रक्रिया पहले से चल रही है और हम इसमें शामिल होना चाहते हैं, तो हमें केवल प्रक्रिया के पीआईडी ​​का पता लगाना होगा और निम्नलिखित कोड को निष्पादित करना होगा:

 function TFWDebugerCore.AttachToProcess(ProcessID: DWORD; SentEntryPointBreakPoint: Boolean): Boolean; begin Result := False; if FProcessInfo.ProcessID <> 0 then Exit; FSetEntryPointBreakPoint := SentEntryPointBreakPoint; FProcessInfo.ProcessID := ProcessID; Result := DebugActiveProcess(ProcessID); end; 

सच है, यह कोड हमेशा कम से कम दो कारणों से सफलतापूर्वक निष्पादित नहीं होता है।

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

दूसरा कारण यह हो सकता है कि हमें जिस प्रक्रिया की आवश्यकता है वह डिबगर की तुलना में उच्च विशेषाधिकार के साथ शुरू हो। इस स्थिति में, DebugActiveProcess फ़ंक्शन का कॉल भी विफल हो जाएगा, और GetLastError एक त्रुटि कोड लौटाएगा: ERROR_ACCESS_DENIED।

दूसरे मामले में, आप आवश्यक विशेषाधिकारों के साथ डिबगर चलाकर इस त्रुटि के आसपास काम कर सकते हैं।

दूसरा विकल्प इस कोड के साथ प्रक्रिया शुरू करके डिबगर को प्रक्रिया में संलग्न करना है:

 function TFWDebugerCore.DebugNewProcess(const FilePath: string; SentEntryPointBreakPoint: Boolean): Boolean; var PI: TProcessInformation; SI: TStartupInfo; begin Result := False; if FProcessInfo.ProcessID <> 0 then Exit; FSetEntryPointBreakPoint := SentEntryPointBreakPoint; ZeroMemory(@SI, SizeOf(TStartupInfo)); SI.cb := SizeOf(TStartupInfo); Result := CreateProcess(PChar(FilePath), nil, nil, nil, False, DEBUG_PROCESS or DEBUG_ONLY_THIS_PROCESS, nil, nil, SI, PI); if Result then begin FProcessInfo.ProcessID := PI.dwProcessId; FProcessInfo.CreatedProcessHandle := PI.hProcess; FProcessInfo.CreatedThreadHandle := PI.hThread; end; end; 

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

जैसे ही हम एक डिबगर के रूप में इस प्रक्रिया में शामिल हुए, यह प्रक्रिया अपने आप ही काम करना बंद कर देती है और अपनी प्रत्येक गतिविधि के लिए हमारी टीम की प्रतीक्षा करेगी - इसे आगे क्या करना चाहिए। ऐसा करने के लिए, वह डिबगिंग घटनाओं को उत्पन्न करेगा और तब तक प्रतीक्षा करेगा जब तक हम उन पर प्रतिक्रिया नहीं करते।

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

एमएसएनडी डिबग इवेंट लूप के निम्नलिखित कार्यान्वयन की सिफारिश करता है।

डिबगर का मुख्य लूप लिखना

हम अपने डिबगर में लगभग समान लागू करते हैं।

 procedure TFWDebugerCore.RunMainLoop; var DebugEvent: TDebugEvent; CallNextLoopIteration: Boolean; ThreadIndex: Integer; begin CallNextLoopIteration := False; repeat ContinueStatus := DBG_CONTINUE; if not WaitForDebugEvent(DebugEvent, MainLoopWaitPeriod) then begin if GetLastError = ERROR_SEM_TIMEOUT then begin DoIdle; if FProcessInfo.ProcessID = 0 then Exit; CallNextLoopIteration := True; Continue; end else begin DoMainLoopFailed; Break; end; end; case DebugEvent.dwDebugEventCode of CREATE_THREAD_DEBUG_EVENT: DoCreateThread(DebugEvent); CREATE_PROCESS_DEBUG_EVENT: DoCreateProcess(DebugEvent); EXIT_THREAD_DEBUG_EVENT: DoExitThread(DebugEvent); EXIT_PROCESS_DEBUG_EVENT: begin DoExitProcess(DebugEvent); Break; end; LOAD_DLL_DEBUG_EVENT: DoLoadDll(DebugEvent); UNLOAD_DLL_DEBUG_EVENT: DoUnLoadDll(DebugEvent); OUTPUT_DEBUG_STRING_EVENT: DoDebugString(DebugEvent); RIP_EVENT: DoRip(DebugEvent); EXCEPTION_DEBUG_EVENT: begin ThreadIndex := GetThreadIndex(DebugEvent.dwThreadId); case DebugEvent.Exception.ExceptionRecord.ExceptionCode of EXCEPTION_BREAKPOINT: ProcessExceptionBreakPoint(ThreadIndex, DebugEvent); EXCEPTION_SINGLE_STEP: ProcessExceptionSingleStep(ThreadIndex, DebugEvent); EXCEPTION_GUARD_PAGE: ProcessExceptionGuardPage(ThreadIndex, DebugEvent); else CallUnhandledExceptionEvents(ThreadIndex, CodeDataToExceptionCode( DebugEvent.Exception.ExceptionRecord.ExceptionCode), DebugEvent); end; end; end; CallNextLoopIteration := ContinueDebugEvent(DebugEvent.dwProcessId, DebugEvent.dwThreadId, ContinueStatus); until not CallNextLoopIteration; end; 

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

 PDebugEvent = ^TDebugEvent; _DEBUG_EVENT = record dwDebugEventCode: DWORD; dwProcessId: DWORD; dwThreadId: DWORD; case Integer of 0: (Exception: TExceptionDebugInfo); 1: (CreateThread: TCreateThreadDebugInfo); 2: (CreateProcessInfo: TCreateProcessDebugInfo); 3: (ExitThread: TExitThreadDebugInfo); 4: (ExitProcess: TExitProcessDebugInfo); 5: (LoadDll: TLoadDLLDebugInfo); 6: (UnloadDll: TUnloadDLLDebugInfo); 7: (DebugString: TOutputDebugStringInfo); 8: (RipInfo: TRIPInfo); end; {$EXTERNALSYM _DEBUG_EVENT} TDebugEvent = _DEBUG_EVENT; DEBUG_EVENT = _DEBUG_EVENT; {$EXTERNALSYM DEBUG_EVENT} 

प्रत्येक घटना के मापदंडों का अपना सेट होता है, लेकिन हम थोड़ी देर बाद उन पर ध्यान केंद्रित करेंगे।

यदि किसी भी घटना को हमारे कोड द्वारा संसाधित नहीं किया जाता है, तो हम बस जारी रखने की प्रक्रिया को डिबगड्यूवेंट फ़ंक्शन को कॉल करके DBG_CONTINUE को ContinueStatus पैरामीटर सेट करके निष्पादित करना जारी रखते हैं।

Nuance: अगर WaitForDebugEvent ने एक त्रुटि लौटा दी (उदाहरण के लिए, टाइमआउट द्वारा), आपको ContinueDebugEvent को कॉल नहीं करना चाहिए, यह एक त्रुटि भी लौटाएगा। इस बिंदु पर, वे अक्सर ठोकर खाते हैं, डिबगर के अपने स्वयं के कार्यान्वयन में इसे ध्यान में रखना न भूलें।

अब तक, सब कुछ काफी सरल है, अब देखते हैं कि कौन सी घटनाएं हमें देती हैं।

CREATE_PROCESS_DEBUG_EVENT:

डीबगिंग प्रारंभ होने पर डीबगर को प्राप्त होने वाली पहली पहली घटना होगी। इससे कोई फर्क नहीं पड़ता कि हमने स्वयं प्रक्रिया शुरू की है, या डीबगएक्टिवप्रोसेस को कॉल करके इसमें शामिल हो गए हैं, हम इसके साथ काम करना शुरू कर देंगे। इस ईवेंट के लिए पैरामीटर DebugEvent.CreateProcessInfo संरचना (CREATE_PROCESS_DEBUG_INFO संरचना) में संग्रहीत हैं ।

सामान्य तौर पर, इस ईवेंट के लिए हैंडलर इस तरह दिखता है:

 procedure TFWDebugerCore.DoCreateProcess(DebugEvent: TDebugEvent); begin //     FProcessInfo.AttachedFileHandle := DebugEvent.CreateProcessInfo.hFile; FProcessInfo.AttachedProcessHandle := DebugEvent.CreateProcessInfo.hProcess; FProcessInfo.AttachedThreadHandle := DebugEvent.CreateProcessInfo.hThread; FProcessInfo.EntryPoint := DWORD(DebugEvent.CreateProcessInfo.lpStartAddress); AddThread(DebugEvent.dwThreadId, FProcessInfo.AttachedThreadHandle); //  BreakPoint     if FSetEntryPointBreakPoint then SetBreakpoint(FProcessInfo.EntryPoint, 'Process Entry Point Breakpoint'); if Assigned(FCreateProcess) then begin FCreateProcess(Self, GetThreadIndex(DebugEvent.dwThreadId), DebugEvent.CreateProcessInfo); DoResumeAction(GetThreadIndex(DebugEvent.dwThreadId)); end; end; 

इसमें, हम बस प्रक्रिया के मापदंडों को याद करते हैं, और आंतरिक सूची में प्रक्रिया के मुख्य धागे की आईडी और हैंडल भी जोड़ते हैं। ये डेटा हमारे लिए बाद में उपयोगी होंगे।

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

प्रवेश बिंदु क्या है: जब लोडर प्रक्रिया बनाता है, जब तक कि जब यह शुरू नहीं होता है, तब तक कई प्रारंभिक क्रियाएं की जाती हैं। आवेदन का मुख्य धागा बनाना, स्टैक स्थापित करना, प्रक्रिया पर्यावरण / थ्रेड ब्लॉक, पुस्तकालयों को लोड करना, उनके टीएलएस कॉलगर्ल्स को निष्पादित करना, आदि। यह सब पूरा होने के बाद ही, लोडर हस्तांतरण सीधे प्रवेश बिंदु पर नियंत्रण करता है, जहां से प्रोग्रामर द्वारा लागू कोड पहले से ही शुरू हो रहा है। इस बिंदु का पता पीई फ़ाइल के हेडर में सीधे संग्रहीत किया जाता है, जहां से इसे पीई फ़ाइल की संरचना को प्रदर्शित करने वाले किसी भी एप्लिकेशन द्वारा प्राप्त किया जा सकता है, उदाहरण के लिए PEiD या PeExplorer, या आप इस मान को स्वयं पढ़ सकते हैं, जो फ़ाइल के बहुत शुरुआत में स्थित TIIAGEDosHeader संरचना को पढ़कर, इसके _lfanew फ़ील्ड को ऑफसेट करेगा। TImageNtHeaders शुरू करें, जिसके बाद TImageNtHeaders संरचना को स्वयं पढ़ें और इसके TImageNtHeaders.OptionalHeader.AddressOfEntryPoint फ़ील्ड का मान देखें।

एक खाली परियोजना को संकलित करने की कोशिश करें, और इसमें F7 दबाएं, और फिर सीपीयू-व्यू टैब पर जाएं, यह कुछ इस तरह दिखना चाहिए:



प्रवेश बिंदु पता निकला: 0x0043E2D4। अब देखते हैं कि PEiD हमें परिणामी एप्लिकेशन के बारे में क्या बताता है:



वह कहते हैं कि प्रवेश बिंदु मान 0x0003E2D4 है।

हालाँकि यह उस संख्या के साथ मेल नहीं खाता, जिसे हमने डिबगर में देखा था, फिर भी, सब कुछ यहाँ ठीक है, क्योंकि AddressOfEntryPoint पैरामीटर में संग्रहीत मान RVA (सापेक्ष वर्चुअल पता) के रूप में दर्शाया गया है। इस पते की ख़ासियत यह है कि यह हमारे मॉड्यूल (hInstance) के लोड पते को ध्यान में नहीं रखता है। RVA पते से VA (वर्चुअल एड्रेस) प्राप्त करने के लिए, आपको इसमें hInstance मॉड्यूल को जोड़ना होगा।

एक अति सूक्ष्म अंतर है: यह केवल अनुप्रयोगों के लिए सच है, पुस्तकालयों के लिए यह थोड़ा अलग तरीके से काम करता है। उनके लिए, आपको अनुभागों के पते पर ध्यान केंद्रित करना होगा। इस डेमो में अधिक विवरण पाया जा सकता है: "फ़ाइल गुणों को लागू करना बुकमार्क" ।
इसमें, DebugHlp.pas मॉड्यूल में, ImageRvaToVa () फ़ंक्शन का एक कार्यान्वयन दिया गया है, जिसके द्वारा आप कास्टिंग पते के नियमों का स्पष्ट रूप से अध्ययन कर सकते हैं।

खैर, आवेदन के लिए, आधार डाउनलोड पता हमेशा इमेज बेस पैरामीटर में लिंकर सेटिंग्स में हमारे द्वारा निर्दिष्ट मूल्य के बराबर होता है, जो कि डिफ़ॉल्ट रूप से 0x00400000 है। इन दो नंबरों को जोड़ने पर, हमें केवल आवश्यक 0x0043E2D4 मिलता है।

LOAD_DLL_DEBUG_EVENT:

CREATE_PROCESS_DEBUG_EVENT के तुरंत बाद, हम DebugEvent.LoadDll संरचना (LOAD_DLL_DEBUG_INFIN संरचना) में मापदंडों के साथ, पुस्तकालय लोडिंग घटनाओं को प्राप्त करना शुरू कर देंगे ।

सामान्य स्थिति में, हम डेल्फी डिबगर में पुस्तकालयों को लोड करने का निरीक्षण कर सकते हैं, जो इवेंट में लोड होने की सूचना प्रदर्शित करता है:



इस घटना के प्राप्त होने पर, डेल्फी डीबगर, यदि बीपी मॉड्यूल को लोड करने के लिए स्थापित किया गया है, तो इसे लोड होने के तुरंत बाद बाधित किया जाता है।



हम इस कोड के साथ एक मॉड्यूल लोड करने के बारे में भी उपयोगकर्ता को सूचित कर सकते हैं:

 procedure TFWDebugerCore.DoLoadDll(DebugEvent: TDebugEvent); begin if Assigned(FLoadDll) then begin FLoadDll(Self, GetThreadIndex(DebugEvent.dwThreadId), DebugEvent.LoadDll); DoResumeAction; end; CloseHandle(DebugEvent.LoadDll.hFile); end; 

जिसमें, घटना को बढ़ाने के अलावा, हम तुरंत लोड किए गए पुस्तकालय के हैंडल को बंद कर देते हैं, हमें अब इसकी आवश्यकता नहीं होगी (डिबगर कार्यान्वयन के इस संस्करण में)।

बारीकियों यह है: डिबगEvent.LoadDll.lpImageName पैरामीटर में संग्रहीत लोड किए गए लाइब्रेरी के लिए पथ के साथ पता, हमारे पता स्थान में स्थित नहीं है, इसलिए हमें इसे ReadcesscessMemory के माध्यम से पढ़ना होगा।
दूसरी बारीकियों: यह मान एक बफर के लिए एक संकेतक भी है जिसके साथ पथ के बारे में डेटा स्थित हैं, अर्थात। कम से कम दो बार पढ़ना है।
तीसरा कैविएट: पथ दोनों Ansii और यूनिकोड एन्कोडिंग में हो सकता है।
ठीक है, एक नाश्ते के लिए, चौथा कैवेट: हम डेटा नहीं पढ़ सकते हैं :)

लोड करने योग्य पुस्तकालय के लिए एक वैध मार्ग प्राप्त करने के लिए, TFWDebugerCore वर्ग GetDllName विधि प्रदान करता है जो इन सभी बिंदुओं को ध्यान में रखता है।

कार्यान्वयन पर विचार करें।
TFWDebugerCore वर्ग बाहरी OnLoadDll घटना को कॉल करके हमें पुस्तकालय लोड करने की सूचना देगा, जहां हम निम्नलिखित कोड लिखेंगे:

 procedure TdlgDebuger.OnLoadDll(Sender: TObject; ThreadIndex: Integer; Data: TLoadDLLDebugInfo); const FormatStrKnownDLL = 'Load Dll at instance %p handle %d "%s"'; FormatStrUnknownDLL = 'Load unknown Dll at instance %p handle %d'; var DllName: AnsiString; IsUnicodeData: Boolean; begin FCore.ContinueStatus := DBG_EXCEPTION_NOT_HANDLED; IsUnicodeData := Data.fUnicode = 1; DllName := FCore.GetDllName(Data.lpImageName, Data.lpBaseOfDll, IsUnicodeData); if DllName <> '' then begin if IsUnicodeData then Writeln(Format(FormatStrKnownDLL, [Data.lpBaseOfDll, Data.hFile, PWideChar(@DllName[1])])) else Writeln(Format(FormatStrKnownDLL, [Data.lpBaseOfDll, Data.hFile, PAnsiChar(@DllName[1])])); end else Writeln(Format(FormatStrUnknownDLL, [Data.lpBaseOfDll, Data.hFile])); end; 

यहां, हम TFWDebugerCore.GetDllName () विधि को कहते हैं और (फ़्यूनिकोड पैरामीटर पर ध्यान केंद्रित करते हुए) डेटा को कंसोल पर प्रिंट करते हैं।

GetDllName विधि का कार्यान्वयन इस प्रकार है:

 function TFWDebugerCore.ReadData(AddrPrt, ResultPtr: Pointer; DataSize: Integer): Boolean; var Dummy: DWORD; begin Result := ReadProcessMemory(FProcessInfo.AttachedProcessHandle, AddrPrt, ResultPtr, DataSize, Dummy) and (Integer(Dummy) = DataSize); end; function TFWDebugerCore.ReadStringA(AddrPrt: Pointer; DataSize: Integer): AnsiString; begin SetLength(Result, DataSize); if not ReadData(AddrPrt, @Result[1], DataSize) then Result := ''; end; function GetMappedFileNameA(hProcess: THandle; lpv: Pointer; lpFilename: LPSTR; nSize: DWORD): DWORD; stdcall; external 'psapi.dll'; function TFWDebugerCore.GetDllName(lpImageName, lpBaseOfDll: Pointer; var Unicode: Boolean): AnsiString; var DllNameAddr: Pointer; MappedName: array [0..MAX_PATH - 1] of AnsiChar; begin if ReadData(lpImageName, @DllNameAddr, 4) then Result := ReadStringA(DllNameAddr, MAX_PATH); if Result = '' then begin if GetMappedFileNameA(FProcessInfo.AttachedProcessHandle, lpBaseOfDll, @MappedName[0], MAX_PATH) > 0 then begin Result := PAnsiChar(@MappedName[0]); Unicode := False; end; end; end; 

यही है, पहले हम डिबग की गई प्रक्रिया के पता स्थान (ReadData + ReadStringA) से डेटा पढ़कर लाइब्रेरी का रास्ता प्राप्त करने का प्रयास करते हैं, और यदि यह काम नहीं करता है, तो हम GetMappedFameNameA फ़ंक्शन को कॉल करके इस डेटा को लेते हैं। यह प्रतीकात्मक लिंक का उपयोग करके डेटा देता है, इसलिए अच्छे परिणाम को अभी भी सामान्य पथ पर लाने की आवश्यकता है, लेकिन इस मामले में मैंने ऐसा नहीं किया, ताकि कोड को जटिल न करें।

CREATE_THREAD_DEBUG_EVENT

हम इस घटना को उस समय प्राप्त करेंगे जब डिबग किए गए एप्लिकेशन में एक नया धागा बनाया जाता है। इस ईवेंट के लिए पैरामीटर DebugEvent.CreateThread संरचना (CREATE_THREAD_DEBUG_INFO संरचना) में संग्रहीत हैं ।

सभी मापदंडों में से, हम DebugEvent.CreateThread.hThread में सबसे अधिक रुचि रखते हैं, जिसे आंतरिक सूची में सहेजना वांछनीय है।

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

इस घटना के लिए हैंडलर कोड इस प्रकार है:

 procedure TFWDebugerCore.DoCreateThread(DebugEvent: TDebugEvent); begin AddThread(DebugEvent.dwThreadId, DebugEvent.CreateThread.hThread); if Assigned(FCreateThread) then begin FCreateThread(Self, GetThreadIndex(DebugEvent.dwThreadId), DebugEvent.CreateThread); DoResumeAction; end; end; 

धागे के मापदंडों को बचाने और बाहरी हैंडलर को कॉल करने के अलावा, इसमें कुछ भी नहीं है।

OUTPUT_DEBUG_STRING_EVENT:

यह घटना उस समय उत्पन्न होती है जब डीबग किए गए एप्लिकेशन आउटपुटडबगस्ट्रिंग फ़ंक्शन को कॉल के लिए कुछ संवाद करने की कोशिश कर रहा है। इस ईवेंट के लिए पैरामीटर DebugEvent.DebugString संरचना (OUTPUT_DEBUG_STRING_INFO संरचना) में संग्रहीत हैं ।

ईवेंट हैंडलर सरल है:

 procedure TFWDebugerCore.DoDebugString(DebugEvent: TDebugEvent); begin if Assigned(FDebugString) then begin FDebugString(Self, GetThreadIndex(DebugEvent.dwThreadId), DebugEvent.DebugString); DoResumeAction; end; end; 

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

उदाहरण के लिए, इस तरह:

 procedure TdlgDebuger.OnDebugString(Sender: TObject; ThreadIndex: Integer; Data: TOutputDebugStringInfo); begin if Data.fUnicode = 1 then Writeln('DebugString: ' + PWideChar(FCore.ReadStringW(Data.lpDebugStringData, Data.nDebugStringLength))) else Writeln('DebugString: ' + PAnsiChar(FCore.ReadStringA(Data.lpDebugStringData, Data.nDebugStringLength))); end; 

हैंडलर में, हम देखते हैं कि डेटा को फ़ोकस करने के लिए बफ़र को क्या रखा गया है। Data.fUnicode पैरामीटर पर ध्यान केंद्रित करते हुए और डीबगर कोर ReadStringX () के संगत फ़ंक्शन को कॉल करें।

UNLOAD_DLL_DEBUG_EVENT, EXIT_THREAD_DEBUG_EVENT, EXIT_PROCESS_DEBUG_EVENT, RIP_EVENT:

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

EXCEPTION_DEBUG_EVENT:

उपरोक्त सभी आठ घटनाएँ, सिद्धांत रूप में, द्वितीयक हैं। EXCEPTION_DEBUG_EVENT ईवेंट के आने के बाद ही मुख्य कार्य शुरू होता है।
इसके पैरामीटर DebugEvent.Exception संरचना (EXCEPTION_DEBUG_INFO संरचना) पर जाते हैं ।

इस घटना की पीढ़ी का अर्थ है कि डिबग किए गए एप्लिकेशन में एक निश्चित अपवाद उत्पन्न हुआ, जिसके प्रकार को DebugEvent.Exception.ExceptionRecord.ExceptionCode पैरामीटर में पाया जा सकता है। याद रखें, लेख के पहले भाग में मैंने उल्लेख किया है कि संरचित त्रुटि हैंडलिंग (एसईएच) तंत्र के माध्यम से डिबगिंग किया जाता है? अब हम इस पर और विस्तार से विचार करेंगे।

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

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

आमतौर पर, डीबगर बीपी के साथ काम करने के लिए तीन तंत्र प्रदान करता है (ठीक है, यदि आप मॉड्यूल को लोड करने के लिए बीपी को ध्यान में नहीं रखते हैं, क्योंकि वास्तव में यह सुविधा क्लासिक बीपी नहीं है)।

1. कोड की प्रति लाइन मानक बी.पी.
2. बीपी को मेमोरी एड्रेस (मेमोरी ब्रेकपॉइंट या डेल्फी में डेटा क्रिप्टपॉइंट काट दिया गया)।
3. हार्डवेयर बीपी (डेल्फी में उपलब्ध नहीं)।

उनके साथ काम करने के लिए, तीन प्रकार के अपवादों को संसाधित करना पर्याप्त है:

 EXCEPTION_DEBUG_EVENT: begin ThreadIndex := GetThreadIndex(DebugEvent.dwThreadId); case DebugEvent.Exception.ExceptionRecord.ExceptionCode of EXCEPTION_BREAKPOINT: ProcessExceptionBreakPoint(ThreadIndex, DebugEvent); EXCEPTION_SINGLE_STEP: ProcessExceptionSingleStep(ThreadIndex, DebugEvent); EXCEPTION_GUARD_PAGE: ProcessExceptionGuardPage(ThreadIndex, DebugEvent); else CallUnhandledExceptionEvents(ThreadIndex, CodeDataToExceptionCode( DebugEvent.Exception.ExceptionRecord.ExceptionCode), DebugEvent); end; end; 

यह स्पष्ट करने के लिए कि केवल ये तीन अपवाद पर्याप्त क्यों हैं, आपको EXCEPTION_DEBUG_EVENT घटना को संसाधित करने के लिए तर्क के विश्लेषण के साथ आगे बढ़ने से पहले प्रत्येक प्रकार के बीपी को सेट करने के लिए तंत्र पर विचार करना होगा।

कोड की एक पंक्ति पर एक ब्रेकपॉइंट लागू करना:

कोड की एक पंक्ति पर बीपी स्थापित करना डिबग किए गए एप्लिकेशन के कोड को संशोधित करके किया जाता है। शास्त्रीय रूप से, यह बीपी द्वारा निर्धारित पते पर 0xCC ओपकोड लिखकर किया जाता है, जिसका अर्थ है निर्देश "INT3"।

अन्य विकल्प हैं, उदाहरण के लिए, 0xCD03 ओपकोड, जो एक "INT3" निर्देश भी है। दूसरा विकल्प एंटी-डिबगिंग में अधिक उपयोग किया जाता है और अधिकांश मामलों में एप्लिकेशन द्वारा ही स्थापित किया जाता है, इस तथ्य पर डिबगर की उपस्थिति को पकड़ने की कोशिश कर रहा है कि परमाणु _KiTrap03 () केवल एकल-बाइट कोड के साथ काम कर सकता है और थोड़ा गलत तरीके से डबल-बाइट की प्रक्रिया करता है।

लेकिन, यह सब गीत है, हम पहले opcode में रुचि रखते हैं।

स्थापित BPs की सूची को संग्रहीत करने के लिए, TFWDebugerCore वर्ग निम्नलिखित संरचनाओं का उपयोग करता है:

 //      ( ) TBreakpointType = ( btBreakpoint, // WriteProcessMemoryEx + 0xCC btMemoryBreakpoint // VirtualProtectEx + PAGE_GUARD ); //         TInt3Breakpoint = record Address: Pointer; ByteCode: Byte; end; TMemotyBreakPoint = record Address: Pointer; Size: DWORD; BreakOnWrite: Boolean; RegionStart: Pointer; RegionSize: DWORD; PreviosRegionProtect: DWORD; end; TBreakpoint = packed record bpType: TBreakpointType; Description: ShortString; Active: Boolean; case Integer of 0: (Int3: TInt3Breakpoint;); 1: (Memory: TMemotyBreakPoint); end; TBreakpointList = array of TBreakpoint; 

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

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

डीबग अनुप्रयोग में BP स्थापित करना कुछ इस तरह दिखता है:

 function TFWDebugerCore.SetBreakpoint(Address: DWORD; const Description: string): Boolean; var Breakpoint: TBreakpoint; OldProtect: DWORD; Dummy: DWORD; begin ZeroMemory(@Breakpoint, SizeOf(TBreakpoint)); Breakpoint.bpType := btBreakpoint; Breakpoint.Int3.Address := Pointer(Address); Breakpoint.Description := Description; Check(VirtualProtectEx(FProcessInfo.AttachedProcessHandle, Pointer(Address), 1, PAGE_READWRITE, OldProtect)); try Check(ReadProcessMemory(FProcessInfo.AttachedProcessHandle, Pointer(Address), @Breakpoint.Int3.ByteCode, 1, Dummy)); Check(WriteProcessMemory(FProcessInfo.AttachedProcessHandle, Pointer(Address), @BPOpcode, 1, Dummy)); finally Check(VirtualProtectEx(FProcessInfo.AttachedProcessHandle, Pointer(Address), 1, OldProtect, OldProtect)); end; Result := AddNewBreakPoint(Breakpoint); end; 

प्रारंभ में, संरचना को प्रारंभ किया जाता है, बीपी का प्रकार स्थापित किया जाता है, इसका विवरण और पैरामीटर। कोड क्षेत्र में लिखने के बाद, जिसमें आमतौर पर लिखने की अनुमति नहीं होती है, संबंधित अधिकार सेट होते हैं, पता BP पर स्थित मूल मान पढ़ा जाता है, BPOpcode निरंतर द्वारा प्रस्तुत 0xCC निर्देश लिखा जाता है, और मूल पृष्ठ विशेषताएँ VirtualProtectEx () को बार-बार कॉल करके वापस आ जाती हैं। सब कुछ के अंत में, यदि कोई त्रुटि नहीं हुई है, तो स्थापित बीपी का रिकॉर्ड कक्षा की सामान्य सूची में रखा गया है।

खैर, अब मज़ा शुरू होता है:

बीपी स्थापित करने के बाद, डिबग किए गए एप्लिकेशन अपने सामान्य ऑपरेशन को जारी रखेंगे, जब तक कि हमारे द्वारा दर्ज किए गए INT3 निर्देश में संक्रमण न हो जाए। इस बिंदु पर, EXCEPTION_DEBUG_EVENT ईवेंट अपवाद कोड EXCEPTION_BREAKPOINT के साथ उठाया जाएगा।

अपवाद पैरामीटर हमें डिबग-ईवेंट के रूप में पास किया जाएगा। अपवाद.ExceptionRecord (EXCEPTION_DEBUG_INFO संरचना)।

जैसा कि मैंने पहले बताया, बीपी को डीबग किए गए एप्लिकेशन द्वारा ही स्थापित किया जा सकता है, इसलिए, इन मापदंडों पर ध्यान केंद्रित करते हुए, आपको यह पता लगाने की आवश्यकता है कि बीपी किस तरह का काम करता है?

ऐसा करने के लिए, हमें पहले से सहेजे गए ब्रेकपॉइंट्स की एक सूची की आवश्यकता होगी। इसके माध्यम से चलने और DebugEvent.Exception.Exception.ecception.ExceptionRecord.ExceptionAddress में संग्रहीत पते की तुलना प्रकार btBreakpoint के प्रत्येक रिकॉर्ड के पता फ़ील्ड के साथ, हम निर्धारित कर सकते हैं कि क्या हम इस पते पर बीपी स्थापित करते हैं या यह कुछ हमारा नहीं है।

यदि हमने यह निर्धारित किया है कि बीपी वास्तव में हमारा है, तो हम एक बाहरी घटना को बढ़ाते हैं (उपयोगकर्ता को दिखाने के लिए कि हम सिर्फ यहां नहीं हैं, बल्कि काम भी कर रहे हैं) और इसे संसाधित करने के बाद, हम डिबग किए गए एप्लिकेशन को पुनर्स्थापित करने के लिए आगे बढ़ते हैं।

बीपी स्थापित करने का परिणाम: बीपी स्थापित

करके, हमने कुछ निष्पादन योग्य कोड खो दिए हैं।

उदाहरण के लिए, प्रारंभिक कोड इस प्रकार था:



हमारे जोड़तोड़ के बाद, यह निम्नलिखित में बदल गया:



पहला कदम मूल निर्देश के अर्थ को पुनर्स्थापित करना है।

इसे और अधिक सुविधाजनक बनाने के लिए, TBreakpoint संरचना में एक सक्रिय पैरामीटर है जो ब्रेकपॉइंट की स्थिति को इंगित करता है। इस पैरामीटर पर ध्यान केंद्रित करते हुए, TFWDebugerCore वर्ग उनकी गतिविधि के बारे में जानता है, और राज्य को स्विच करने के लिए, यह ToggleInt3Breakpoint विधि को कार्यान्वित करता है, जिसमें ध्वज के आधार पर, बीपी को चालू और बंद कर देता है, मिटाए गए बाइट को अपनी जगह पर लौटाता है।

 procedure TFWDebugerCore.ToggleInt3Breakpoint(Index: Integer; Active: Boolean); var OldProtect: DWORD; Dummy: DWORD; begin CheckBreakpointIndex(Index); if FBreakpointList[Index].bpType <> btBreakpoint then Exit; if FBreakpointList[Index].Active = Active then Exit; Check(VirtualProtectEx(FProcessInfo.AttachedProcessHandle, FBreakpointList[Index].Int3.Address, 1, PAGE_READWRITE, OldProtect)); try if Active then Check(WriteProcessMemory(FProcessInfo.AttachedProcessHandle, FBreakpointList[Index].Int3.Address, @BPOpcode, 1, Dummy)) else Check(WriteProcessMemory(FProcessInfo.AttachedProcessHandle, FBreakpointList[Index].Int3.Address, @FBreakpointList[Index].Int3.ByteCode, 1, Dummy)); finally Check(VirtualProtectEx(FProcessInfo.AttachedProcessHandle, FBreakpointList[Index].Int3.Address, 1, OldProtect, OldProtect)); end; FBreakpointList[Index].Active := Active; end; 

कार्यान्वयन लगभग बीपी सेट करने वाले कोड के समान है, इस तथ्य को छोड़कर कि जब आप बीपी को फिर से स्थापित करते हैं, तो आपको बाइट मान को फिर से पढ़ने की आवश्यकता नहीं है (क्योंकि हम पहले से ही जानते हैं)।

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

दूसरी बारीकियों: आप निश्चित रूप से इस दिशा में सपना देख सकते हैं: "ठीक है, इसके बारे में सोचो -" पुश एबप "विफल रहा, ठीक है, ढेर दूर चला गया, लेकिन हम एक डिबगर हैं और अगर कुछ आ सकता है और सब कुछ ठीक कर सकता है ..."। तो यह मूल रूप से सही है, एक बिंदु को छोड़कर।

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

यह क्या है:

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

एक उदाहरण के रूप में, काफी कम संख्या में डेवलपर्स ऐसी अवधारणा को "लंबे एनओपी" के रूप में जानते हैं। इसके अलावा, एक या डेढ़ या दो साल पहले यह इंटेल के मैनुअल में नहीं था, जहां यह कहा गया था कि एनओपी (कोड को संरेखित करने के लिए उपयोग किया जाने वाला एक खाली निर्देश) केवल 0x90 ओपकोड के रूप में दिखता है। तदनुसार, अधिकांश असंतुष्ट केवल इस ओपकोड के साथ काम कर सकते हैं। हां, हालांकि, बहुमत क्यों - मैं अभी तक एक डिस्सेम्बलर से नहीं मिला हूं जो लंबे पैरों को सही ढंग से पहचानता है।

चूंकि डिस्सेम्बलर इसे सामान्य रूप से नहीं पहचान सकता है, हम निम्न चाल कर सकते हैं:

उदाहरण के लिए, एक तीन-बाइट एनओपी (ओपकोड $ 0F, $ 1F, $ 00) लें और इस कोड को लिखें:

 asm db $0F, $1F, $00 xor eax, eax inc eax neg eax end; 

और यहां वह है जो



डिस्सेम्बलर हमें दिखाएगा: सभी निर्देशों के ऑप्सोड सही हैं और उन्हें सही तरीके से निष्पादित किया जाएगा, लेकिन डिस्सेम्बलर हमें वह दिखाता है जो हमने शुरू में नहीं लिखा था।

खैर, या दूसरा उदाहरण, पहले से ही सीधे कूद का उपयोग कर रहा है। यहां यह विचार इस तथ्य में निहित है कि अगले निर्देश की शुरुआत से पहले, बिल्कुल बाएं बाइट लिखा गया है, जिसके पहले निर्देश कोड "jmp +1" लिखा गया है, जिससे प्रोग्राम को इस कचरा बाइट को छोड़ कर सीधे वांछित कोड पर जाने के लिए मजबूर किया गया है। यह एक भयावह बात प्रतीत होती है - लेकिन असंतुष्ट काफी भ्रामक है।

एक उदाहरण के रूप में, हम निम्नलिखित कोड लिखेंगे:

 asm db $EB, $01 // jmp +1 (  xor  " ") db $B8 //   ""  xor eax, eax //   inc eax neg eax not eax sub edx, eax imul eax, edx nop nop end; 

अब देखते हैं कि disassembler हमें क्या दिखाता है:



पूर्ण कचरा, जैसा कि अपेक्षित था।

तो, मैंने यह सब क्या बताया: आइए अपने बीपी पर वापस जाएं और कल्पना करें कि इसे 0x452220 पर नहीं बल्कि नौ बाइट्स में आगे स्थापित किया गया था, बस पुश $ 00452245 निर्देश की शुरुआत में।

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



यानीमूल "पुश $ 00452245" के बजाय, निर्देश "inc epb" और "और al, [ebp + $ 00]" को निष्पादित किया जाएगा, जो यहां नहीं थे। और कुछ निर्देशों के बाद, हमें वह मिलता है जो अपेक्षित था - एक त्रुटि।

इसलिए, मिटाए गए बाइट को उसके स्थान पर वापस करना पर्याप्त नहीं है, आपको डिबग किए गए एप्लिकेशन को सही पते से प्रोग्राम जारी रखने की आवश्यकता है। अगले पुनरावृत्ति में निष्पादित होने वाले अनुदेश का पता ईआईपी (विस्तारित निर्देश सूचक) रजिस्टर को संग्रहीत करता है। इस रजिस्टर तक पहुंच डीबग की गई प्रक्रिया के थ्रेड संदर्भ के माध्यम से किया जाता है जिसमें व्यवधान उत्पन्न हुआ। EIP रजिस्टर के मूल्य को बदलने के लिए, आपको GetThreadContext फ़ंक्शन को कॉल करके संदर्भ प्राप्त करने की आवश्यकता है, Context.Eip पैरामीटर के वर्तमान मूल्य को कम करें, और फिर SetThreadContext फ़ंक्शन को कॉल करके नया मान लिखें।

एक बारीकियों है: जब EXCEPTION_DEBUG_EVENT घटना होती है, तो हमें केवल डिबगEvent.dwTreadId पैरामीटर में थ्रेड आईडी, और GetThreadContext () और SetThreadContext () फ़ंक्शन उनके काम के लिए एक थ्रेड हैंडल की आवश्यकता होती है, आईडी उनके लिए दिलचस्प नहीं है। बेशक, आप OpenThread फ़ंक्शन को कॉल करके आवश्यक मान प्राप्त कर सकते हैं, लेकिन इस मामले में हमें ऐसा नहीं करना है, क्योंकि हमारे पास थ्रेडआईडी = थ्रेडहैंडल के रूप में संग्रहीत थ्रेड हैंडल की एक सहेजी गई सूची है।

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

इसलिए यह कार्य दिखाई दिया, हमें किसी तरह निर्देश के निष्पादन के तुरंत बाद डिबगर को एप्लिकेशन ट्रांसफर कंट्रोल करना होगा, जिसके साथ हमने बीपी को हटा दिया था। यदि हम सफल होते हैं, तो हम बीपी को उसके सही स्थान पर लौटा सकते हैं।

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

और इस मामले में सही समाधान प्रोसेसर को ट्रेस मोड में रखना है।
प्रोसेसर ध्वज इस मोड को सक्षम करने के लिए जिम्मेदार है। यदि यह ध्वज सक्षम है, तो प्रत्येक निर्देश एक "INT1" व्यवधान को ट्रिगर करेगा, जो डीबग की गई प्रक्रिया में अपवाद को फेंक देगा और डिबगर को अपवाद कोड EXTEPTION_SINGLE_STEP के साथ EXCEPTION_DEBUG_EVENT इवेंट पर नियंत्रण मिल जाएगा।

आप इस ध्वज को थ्रेड संदर्भ के माध्यम से सक्षम कर सकते हैं, जिसके माध्यम से हमने ईआईपी रजिस्टर के मूल्य को बदल दिया है। झंडे की स्थिति को Context.EFlags पैरामीटर द्वारा नियंत्रित किया जाता है। TF ध्वज इस पैरामीटर के आठवें बिट में संग्रहीत किया जाता है। यानी इसे सक्षम करना आसान बनाने के लिए हमें कुछ इस तरह करना चाहिए:

 const EFLAGS_TF = $100; // 8-  ... Context.EFlags := Context.EFlags or EFLAGS_TF; 

ट्रेसिंग Nuance: "INT1" रुकावट की ख़ासियत यह है कि यह TF ध्वज को रीसेट करता है। यानीअगर हमें बीपी को बहाल करने के लिए केवल एक निर्देश पर अमल करने की आवश्यकता है, तो यह व्यवहार हमें पूरी तरह से सूट करता है, क्योंकि हमें टीएफ ध्वज को उसके मूल राज्य में बहाल करने के बारे में चिंता करने की आवश्यकता नहीं है। लेकिन यदि हम प्रत्येक निर्देश के अनुक्रमिक अनुरेखण में रुचि रखते हैं, तो हमें प्रत्येक EXCEPTION_SINGLE_STEP हैंडलर में TF ध्वज को स्वतंत्र रूप से फिर से उठाना होगा। हम इस मोड पर बाद में विचार करेंगे।

सारांश में, कोड पते पर बीपी को स्थापित करने और संसाधित करने के लिए एल्गोरिथ्म निम्नानुसार है:

• बीपी का वर्णन करने वाली संरचना को आरम्भ करें, इसमें इस पते पर पते और बाइट मान को सहेजें।
• बीपी पते पर 0xCC ओपकोड लिखें और निष्पादन के लिए कार्यक्रम चलाएं।
• EXTEPTION_BREAKPOINT अपवाद की प्रतीक्षा करें, जिसकी प्राप्ति पर मूल बाइट को पुनर्स्थापित करना है
• ईआईपी रजिस्टर के मूल्य को बदलें और टीएफ ध्वज को सक्षम करके प्रोसेसर को ट्रेस मोड में डालें
• EXCEPTION_SINGLE_STEP अपवाद की प्रतीक्षा करें
• 0xCC opcode को पुनर्स्थापित करें।

अब आपको इस बात का कम से कम अंदाजा है कि डेल्फी डीबगर में F7 बटन दबाने पर वास्तव में कितने कार्य होते हैं :)

खैर, यह कैसे TFWDebugerCore वर्ग में लागू किया गया है।

EXCEPTION_BREAKPOINT हैंडलर अपवाद:

 procedure TFWDebugerCore.ProcessExceptionBreakPoint(ThreadIndex: Integer; DebugEvent: TDebugEvent); var ReleaseBP: Boolean; BreakPointIndex: Integer; begin ReleaseBP := False; BreakPointIndex := GetBPIndex( DWORD(DebugEvent.Exception.ExceptionRecord.ExceptionAddress)); if BreakPointIndex >= 0 then begin if Assigned(FBreakPoint) then FBreakPoint(Self, ThreadIndex, DebugEvent.Exception.ExceptionRecord, BreakPointIndex, ReleaseBP) else CallUnhandledExceptionEvents(ThreadIndex, ecBreakpoint, DebugEvent); ToggleInt3Breakpoint(BreakPointIndex, False); SetSingleStepMode(ThreadIndex, True); if ReleaseBP then RemoveBreakpoint(BreakPointIndex) else FRestoreBPIndex := BreakPointIndex; end else CallUnhandledExceptionEvents(ThreadIndex, ecBreakpoint, DebugEvent); end; 

इसमें, हम पहली बार ExceptionAddress पैरामीटर द्वारा आंतरिक सूची में BP इंडेक्स की तलाश करते हैं।
बाहरी घटना को उठाएं।
ToggleInt3Breakpoint विधि को कॉल करके BP बंद करें।
EIP संपादित करें और SetSingleStepMode विधि को कॉल करके ट्रेसिंग सक्षम करें।
यदि बाहरी ईवेंट हैंडलर में मौजूद उपयोगकर्ता ने कहा कि वह इस बीपी को हटाना चाहता है, तो हम इसे रिमूव प्वाइंट रिमूव करके कॉल करते हैं।
ठीक है, अगर आपको बस निष्पादन जारी रखने की आवश्यकता है, तो हमें EXCEPTION_SINGLE_STEP हैंडलर के लिए वर्तमान बीपी के सूचकांक को याद रखना चाहिए, जहां, इस चर पर ध्यान केंद्रित करते हुए, यह डीबग की गई प्रक्रिया में बीपी को पुनर्स्थापित करेगा।

SetSingleStepMode विधि के लिए कोड निम्नानुसार है:

 procedure TFWDebugerCore.SetSingleStepMode(ThreadIndex: Integer; RestoreEIPAfterBP: Boolean); var Context: TContext; begin ZeroMemory(@Context, SizeOf(TContext)); Context.ContextFlags := CONTEXT_FULL; Check(GetThreadContext(FThreadList[ThreadIndex].ThreadHandle, Context)); if RestoreEIPAfterBP then Dec(Context.Eip); Context.EFlags := Context.EFlags or EFLAGS_TF; Check(SetThreadContext(FThreadList[ThreadIndex].ThreadHandle, Context)); end; 

यहां सब कुछ बहुत सरल है, हमें CONTEXT_FULL ध्वज सेट करके पूर्ण थ्रेड संदर्भ मिलता है।
यदि आवश्यक हो, तो ईआईपी रजिस्टर को संपादित करें।
टीएफ ध्वज को चालू करें।
और हम एक नया संदर्भ प्रदान करते हैं।

RemoveBreakpoint विधि और भी सरल है:

 procedure TFWDebugerCore.RemoveBreakpoint(Index: Integer); var Len: Integer; begin ToggleBreakpoint(Index, False); Len := BreakpointCount; if Len = 1 then SetLength(FBreakpointList, 0) else begin FBreakpointList[Index] := FBreakpointList[Len - 1]; SetLength(FBreakpointList, Len - 1); end; end; 

यहां, बीपी बंद हो जाता है और फिर डीबगर सूची से बीपी डेटा हटा दिया जाता है।

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

स्मृति पते पर बीपी लागू करना:

डीबग किए गए एप्लिकेशन की मेमोरी में डेटा परिवर्तनों को नियंत्रित करने के लिए अगले प्रकार के बीपी का उपयोग किया जाता है। मेमोरी ब्रेकप्वाइंट (इसके बाद एमबीपी) के रूप में बेहतर जाना जाता है।

इसे निम्नानुसार लागू किया जाता है: संपूर्ण एप्लिकेशन मेमोरी को उन पृष्ठों के एक सेट के रूप में प्रस्तुत किया जाता है जिन्हें सूचीबद्ध किया जा सकता है और उनकी विशेषताएं प्राप्त कर सकते हैं। (डेमो एप्लिकेशन देखें: मेमोरी कार्ड प्रोसेस करें )। जब हम MBP को किसी पते पर रखना चाहते हैं, तो हमें उस पृष्ठ की सीमाओं की गणना करने की आवश्यकता है, जिसके लिए यह पता है और VirtualProtectEx फ़ंक्शन को कॉल करके PAGE_GUARD ध्वज को इसके लिए सेट करें।

Nuance: आप निश्चित रूप से, पृष्ठ के पते की गणना नहीं कर सकते हैं, लेकिन आवश्यक पते पर बस VirtualProtectEx को कॉल करें, लेकिन पेज एड्रेसिंग की ख़ासियत यह है कि आप पेज के एक छोटे से हिस्से की सुरक्षा को बदल नहीं सकते हैं, जिससे सभी पते अपरिवर्तित रहते हैं। सुरक्षा विशेषताओं को हमेशा एक पृष्ठ पर पूरी तरह से सौंपा जाता है। इसलिए, यदि हम केवल एक बाइट में परिवर्तन को ट्रैक करने के लिए जाते हैं, तो इसके बगल में बाइट्स तक पहुंचने पर, डिबगर को भी सूचनाएं प्राप्त होंगी।

दूसरा चेतावनी: अधिकांश डिबगर आपको एक ही समय में एक ही पृष्ठ पर स्थित दो या अधिक एमबीपी स्थापित करने की अनुमति नहीं देते हैं। यह व्यवहार निम्नलिखित बिंदु के कारण सबसे अधिक संभावना है: एमबीपी स्थापित करते समय, आपको एमबीपी को हटाने का समय आने पर इसे वापस करने के लिए पृष्ठ के सुरक्षा क्षेत्र की वर्तमान स्थिति को याद रखना होगा। इस घटना में कि एमबीपी पहले से ही पृष्ठ पर सेट है, इसकी सुरक्षा विशेषताओं को बदल दिया जाता है। इस बिंदु को प्राप्त करने के लिए, निम्न दृष्टिकोण का उपयोग TFWDebugerCore वर्ग में किया जाता है। एक नया MBP स्थापित करते समय, यह पहले जांचा जाता है कि क्या इस पृष्ठ को नियंत्रित करने वाला कोई अन्य MBP है। यदि कोई पाया जाता है, तो यह PreviosRegionProtect पैरामीटर का मान लेता है, यदि कोई MDR नहीं है, तो VirtualProtectEx को कॉल करके यह मान प्राप्त किया जाता है।

MVR स्थापना कोड इस तरह दिखता है:

 function TFWDebugerCore.SetMemoryBreakpoint(Address: Pointer; Size: DWORD; BreakOnWrite: Boolean; const Description: string): Boolean; var Breakpoint: TBreakpoint; MBI: TMemoryBasicInformation; Index: Integer; begin Index := GetMBPIndex(DWORD(Address)); if (Index >= 0) and (FBreakpointList[Index].bpType = btMemoryBreakpoint) then begin MBI.BaseAddress := FBreakpointList[Index].Memory.RegionStart; MBI.RegionSize := FBreakpointList[Index].Memory.RegionSize; MBI.Protect := FBreakpointList[Index].Memory.PreviosRegionProtect; end else Check(VirtualQueryEx(DebugProcessData.AttachedProcessHandle, Address, MBI, SizeOf(TMemoryBasicInformation)) > 0); ZeroMemory(@Breakpoint, SizeOf(TBreakpoint)); Breakpoint.bpType := btMemoryBreakpoint; Breakpoint.Description := ShortString(Description); Breakpoint.Memory.Address := Address; Breakpoint.Memory.Size := Size; Breakpoint.Memory.BreakOnWrite := BreakOnWrite; Breakpoint.Memory.RegionStart := MBI.BaseAddress; Breakpoint.Memory.RegionSize := MBI.RegionSize; Check(VirtualProtectEx(FProcessInfo.AttachedProcessHandle, Address, Size, MBI.Protect or PAGE_GUARD, Breakpoint.Memory.PreviosRegionProtect)); if Index >= 0 then Breakpoint.Memory.PreviosRegionProtect := MBI.Protect; Result := AddNewBreakPoint(Breakpoint); end; 

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

एमवीआर स्थापित करने के बाद, आप निष्पादन के लिए कार्यक्रम चला सकते हैं। जैसे ही मॉनिटर किए गए पृष्ठ तक पहुंच होती है, EXCEPTION_DEBUG_EVENT घटना EXCEPTION_GUARD_PAGE अपवाद कोड के साथ उत्पन्न होगी।

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

हैंडलर कोड इस तरह दिखता है:

 procedure TFWDebugerCore.ProcessExceptionGuardPage(ThreadIndex: Integer; DebugEvent: TDebugEvent); var CurrentMBPIndex: Integer; function CheckWriteMode: Boolean; begin Result := not FBreakpointList[CurrentMBPIndex].Memory.BreakOnWrite; if not Result then Result := DebugEvent.Exception.ExceptionRecord.ExceptionInformation[0] = 1; end; var MBPIndex: Integer; ReleaseMBP: Boolean; dwGuardedAddr: DWORD; begin ReleaseMBP := False; dwGuardedAddr := DebugEvent.Exception.ExceptionRecord.ExceptionInformation[1]; MBPIndex := GetMBPIndex(dwGuardedAddr); if MBPIndex >= 0 then begin CurrentMBPIndex := MBPIndex; while not CheckIsAddrInRealMemoryBPRegion(CurrentMBPIndex, dwGuardedAddr) do begin CurrentMBPIndex := GetMBPIndex(dwGuardedAddr, CurrentMBPIndex + 1); if CurrentMBPIndex < 0 then Break; end; if CurrentMBPIndex >= 0 then begin MBPIndex := CurrentMBPIndex; if Assigned(FBreakPoint) and CheckWriteMode then FBreakPoint(Self, ThreadIndex, DebugEvent.Exception.ExceptionRecord, MBPIndex, ReleaseMBP) else CallUnhandledExceptionEvents(ThreadIndex, ecGuard, DebugEvent); end else CallUnhandledExceptionEvents(ThreadIndex, ecGuard, DebugEvent); FBreakpointList[MBPIndex].Active := False; SetSingleStepMode(ThreadIndex, False); if ReleaseMBP then RemoveBreakpoint(MBPIndex) else FRestoreMBPIndex := MBPIndex; end else CallUnhandledExceptionEvents(ThreadIndex, ecGuard, DebugEvent); end; 

प्रारंभ में, डिबगर को वह पता प्राप्त होता है जिसके लिए कॉल हुआ था जिसके कारण अपवाद हुआ। यह पता ExceptionRecord.ExceptionInformation सरणी में दूसरे पैरामीटर के रूप में संग्रहीत है, ऑपरेशन ध्वज इस सरणी में पहला पैरामीटर है। शून्य का मतलब एक पते पर पढ़ने का प्रयास है, एक का मतलब एक पते पर पढ़ने का प्रयास है।
अगला, हम CheckIsAddrInRealMemoryBPRegion को कॉल करके एक उपयुक्त एमडीआर की खोज करते हैं जो यह जांचता है कि पता एमडीआर द्वारा नियंत्रित क्षेत्र में है या नहीं।

यदि एक उपयुक्त पाया जाता है, तो ब्रेकऑनराइट पैरामीटर की जाँच की जाती है।
इस पैरामीटर के मूल्य की तुलना पहले पैरामीटर ExceptionInformation के मान से की जाती है। यदि ब्रेकऑनराइट को सक्षम किया जाता है, तो एक बाहरी घटना को केवल तभी कहा जाता है जब इकाई एक्ससेप्शन इंफॉर्मेशन में होती है; अन्यथा, यदि ब्रेकऑनराइट को अक्षम किया जाता है, तो ईवेंट को हमेशा कहा जाता है।

सभी जांचों के बाद, कोड को बीपी प्रसंस्करण के साथ सादृश्य द्वारा लागू किया जाता है, बीपी प्रसंस्करण से एकमात्र अंतर यह है कि इस मामले में हमें ईआईपी रजिस्टर के मूल्य को संपादित करने की आवश्यकता नहीं है। ऐसा करने के लिए, गलत दूसरे पैरामीटर के रूप में SetSingleStepMode विधि में पारित किया जाता है।

सादृश्य से, कैप्चर किए गए MVP की वसूली FRCEoreMBPIndex इंडेक्स पर आधारित EXCEPTION_SINGLE_STEP हैंडलर में होती है।

MBP की गतिविधि को बदलने के लिए निम्न कोड जिम्मेदार है:

 procedure TFWDebugerCore.ToggleMemoryBreakpoint(Index: Integer; Active: Boolean); var Dummy: DWORD; begin CheckBreakpointIndex(Index); if FBreakpointList[Index].bpType <> btMemoryBreakpoint then Exit; if FBreakpointList[Index].Active = Active then Exit; if Active then Check(VirtualProtectEx(FProcessInfo.AttachedProcessHandle, FBreakpointList[Index].Memory.Address, FBreakpointList[Index].Memory.Size, FBreakpointList[Index].Memory.PreviosRegionProtect or PAGE_GUARD, Dummy)) else Check(VirtualProtectEx(FProcessInfo.AttachedProcessHandle, FBreakpointList[Index].Memory.Address, FBreakpointList[Index].Memory.Size, FBreakpointList[Index].Memory.PreviosRegionProtect, Dummy)); FBreakpointList[Index].Active := Active; end; 

MVR को निकालना बीपी के समान विधि द्वारा किया जाता है।

सिद्धांत रूप में, बीपी और एमवीआर में कुछ बारीकियों के अपवाद के साथ कोई प्रमुख कार्डिनल अंतर नहीं हैं। वे सिर्फ अपने कार्यों के लिए प्रत्येक को लागू करते हैं।

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

मैं लेख के अंत में इस तरह के उपयोग का एक उदाहरण दिखाऊंगा। अब चलो तीसरे और अंतिम प्रकार के ब्रेकपॉइंट पर चलते हैं।

हार्डवेयर ब्रेकप्वाइंट का कार्यान्वयन:

तथाकथित हार्डवेयर ब्रेकप्वाइंट (इसके बाद HBP)। एक शक्तिशाली पर्याप्त डिबगिंग उपकरण। बीपी और एमवीआर के विपरीत, ये ब्रेकप्वाइंट डिबग किए गए एप्लिकेशन की मेमोरी में संशोधन नहीं करते हैं। केवल बुरी बात यह है कि उनमें से बहुत कम हैं, प्रत्येक धागे के लिए केवल चार टुकड़े हैं।

लेकिन अन्य HBPs के विपरीत, यह डीबग किए गए एप्लिकेशन को नियंत्रित करने के लिए काफी लचीली स्थिति प्रदान करता है।

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

यानीHBP BP (निष्पादन मोड में) और MBP (रिकॉर्ड में - पढ़ें / लिखें मोड) दोनों के संचालन का अनुकरण कर सकता है। सच है, एमवीआर के विपरीत, यह मेमोरी क्षेत्र की एक बड़ी श्रृंखला को नियंत्रित नहीं कर सकता है, क्योंकि केवल निश्चित आकार 1, 2 या 4 बाइट के ब्लॉक के साथ काम कर सकते हैं।

HBP सेटिंग्स को प्रत्येक थ्रेड के संदर्भ में संग्रहीत किया जाता है, इसके लिए DR रजिस्टरों का उपयोग किया जाता है, जो तब एक्सेस किए जाते हैं जब CONTEXT_DEBUG_REGISTERS ध्वज निर्दिष्ट किया जाता है।
उनमें से छह हैं। Dr0..Dr3, Dr6, Dr7। (Dr4 और Dr5 आरक्षित हैं)।
पहले 4 रजिस्टर HBP में से प्रत्येक के पते को संग्रहीत करते हैं। रजिस्टर ड्रब का उपयोग एचबीपी के प्रत्येक पैरामीटर को ठीक करने के लिए किया जाता है। रजिस्टर Dr6 चार HBP में से किसी के संचालन के बाद परिणाम पढ़ने के लिए कार्य करता है।

TFWDebugerCore वर्ग निम्न संरचना के रूप में HBP के बारे में जानकारी संग्रहीत करता है:

 THWBPIndex = 0..3; THWBPSize = (hsByte, hdWord, hsDWord); THWBPMode = (hmExecute, hmWrite, hmIO, hmReadWrite); THardwareBreakpoint = packed record Address: array [THWBPIndex] of Pointer; Size: array [THWBPIndex] of THWBPSize; Mode: array [THWBPIndex] of THWBPMode; Description: array [THWBPIndex] of ShortString; Active: array [THWBPIndex] of Boolean; end; 

चूंकि प्रत्येक विशेष धागे के लिए सभी 4 एचबीपी का अपना है, वे बीपी कक्षाओं की सामान्य सूची में संग्रहीत नहीं हैं।
याद रखें कि शुरुआत में मैंने कहा था कि हम थ्रेड्स के बारे में डेटा को एक जोड़ी ID = hThreadHolle के रूप में एक अलग सूची में संग्रहीत करेंगे। वास्तव में, यह सूची इस प्रकार है:

 TThreadData = record ThreadID: DWORD; ThreadHandle: THandle; Breakpoint: THardwareBreakpoint; end; TThreadList = array of TThreadData; 

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

एचबीपी की स्थापना, राज्य के परिवर्तन और हटाने के साथ काम बेहद सरल है।

स्थापना इस तरह दिखती है:

 procedure TFWDebugerCore.SetHardwareBreakpoint(ThreadIndex: Integer; Address: Pointer; Size: THWBPSize; Mode: THWBPMode; HWIndex: THWBPIndex; const Description: string); begin if ThreadIndex < 0 then Exit; FThreadList[ThreadIndex].Breakpoint.Address[HWIndex] := Address; FThreadList[ThreadIndex].Breakpoint.Size[HWIndex] := Size; FThreadList[ThreadIndex].Breakpoint.Mode[HWIndex] := Mode; FThreadList[ThreadIndex].Breakpoint.Description[HWIndex] := ShortString(Description); FThreadList[ThreadIndex].Breakpoint.Active[HWIndex] := True; UpdateHardwareBreakpoints(ThreadIndex); end; 

हम केवल संरचना को इनिशियलाइज़ करते हैं और UpdateHardwareBreakpoint विधि को कॉल करते हैं।

राज्य संशोधन निम्नलिखित कोड द्वारा कार्यान्वित किया जाता है:

 procedure TFWDebugerCore.ToggleHardwareBreakpoint(ThreadIndex: Integer; Index: THWBPIndex; Active: Boolean); begin if ThreadIndex < 0 then Exit; if FThreadList[ThreadIndex].Breakpoint.Active[Index] = Active then Exit; FThreadList[ThreadIndex].Breakpoint.Active[Index] := Active; UpdateHardwareBreakpoints(ThreadIndex); end; 

बस सक्रिय ध्वज को बदलें और फिर से अपडेटहार्डवेयर क्रिप्टपॉइंट्स को कॉल करें।

खैर, हटाने:

 procedure TFWDebugerCore.DropHardwareBreakpoint(ThreadIndex: Integer; Index: THWBPIndex); begin if ThreadIndex < 0 then Exit; if FThreadList[ThreadIndex].Breakpoint.Address[Index] = nil then Exit; FThreadList[ThreadIndex].Breakpoint.Address[Index] := nil; UpdateHardwareBreakpoints(ThreadIndex); end; 

हम एचबीपी पते को रीसेट करते हैं और फिर से अपडेटहार्डवेयर क्रिप्टपॉइंट्स को कॉल करते हैं।

पूरी बारीकियाँ UpdateHardwareBreakpoint विधि में सटीक रूप से निहित है।
इसका मुख्य कार्य सक्रिय एचबीपी के पते के साथ Dr0-Dr3 रजिस्टरों को भरना है और Dr7 रजिस्टर का सही इनिशियलाइजेशन करना है।

यहां इसके साथ छेड़छाड़ करना आवश्यक है।

यह रजिस्टर बिट फ़्लैग का एक सेट

है जो एचबीपी में से प्रत्येक के लिए सेटिंग्स को परिभाषित करता है और औपचारिक रूप से सब कुछ इस प्रकार दिखता है: सबसे पुराने 4 बिट्स (31-28) Dr3 रजिस्टर की सेटिंग्स को संग्रहीत करते हैं।
यह इस तरह दिखता है:

मॉनिटर किए गए HBP मेमोरी के आकार के लिए चार के ऊपरी 2 बिट्स (LENi) जिम्मेदार हैं।
00 - 1 बाइट
01 - 2 बाइट्स
10 - बिट्स के इस संयोजन का उपयोग नहीं किया जाता है।
11 - 4 बाइट्स 4 के

निचले 2 बिट्स (आरडब्ल्यूआई) एचबीपी
00 के ऑपरेटिंग मोड को सेट करने के लिए जिम्मेदार हैं - निष्पादित
01 -
10 लिखें - आईओ पढ़ें / लिखें
11 - पढ़ें / लिखें

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

की तरह दिखना चाहिए । अगले 4 बिट्स (27-24) Dr2
बिट्स के HBP रजिस्टर को कॉन्फ़िगर करने के लिए उपयोग किए जाते हैं 23-20 Dr1 और अंत में, बिट्स 19- को देखें। 16 से रजिस्टर Dr0।

Dr7 रजिस्टर के बिट 13 (जीडी - ग्लोबल डिबग रजिस्टर एक्सेस डिटेक्ट) - डिबग रजिस्टरों में डेटा की अखंडता के लिए जिम्मेदार है। उदाहरण के लिए, यदि डिबग किए जा रहे कार्यक्रम ने अचानक इन रजिस्टरों में अपने मूल्यों को संग्रहीत करने का निर्णय लिया, तो डिबगर को इस बारे में सूचित किया जाएगा।

Dr7 रजिस्टर के बिट 9 (GE - ग्लोबल सटीक डेटा ब्रेकपॉइंट मैच) - इसमें वैश्विक HBP के साथ काम शामिल है।
Dr7 रजिस्टर (LE - स्थानीय सटीक डेटा ब्रेकपॉइंट मैच) के बिट 8 - स्थानीय HBP के साथ काम करने में सक्षम बनाता है।

कार्यों को स्विच करते समय LE बिट को रीसेट किया जाता है, और अधिक विवरण इंटेल मैनुअल में पाए जा सकते हैं।

वैश्विक या स्थानीय मोड में HBP सहित रजिस्टरों में से प्रत्येक के लिए 8 बिट्स (7-0) बचे हैं जो Gi और Li झंडे की एक जोड़ी के रूप में दर्शाए गए हैं।

बिट 7 (Gi - वैश्विक ब्रेकप्वाइंट सक्षम) - Dr3 रजिस्टर के लिए वैश्विक मोड को सक्षम करता है
बिट 6 (ली - स्थानीय ब्रेकप्वाइंट सक्षम) - Dr3 5-4 रजिस्टर के लिए स्थानीय मोड को चालू करता है
, वही Dr1 के लिए Dr2
3-2 और Dr0

कन्फ्यूज के लिए 1-0 से ?

ठीक है, फिर यहां चित्र है:



स्रोत कोड के रूप में, सब कुछ काफी सरल दिखता है।

 procedure TFWDebugerCore.UpdateHardwareBreakpoints(ThreadIndex: Integer); const DR7_SET_LOC_DR0 = $01; DR7_SET_GLB_DR0 = $02; DR7_SET_LOC_DR1 = $04; DR7_SET_GLB_DR1 = $08; DR7_SET_LOC_DR2 = $10; DR7_SET_GLB_DR2 = $20; DR7_SET_LOC_DR3 = $40; DR7_SET_GLB_DR3 = $80; DR7_SET_LOC_ON = $100; DR7_SET_GLB_ON = $200; DR7_PROTECT = $2000; DR_SIZE_BYTE = 0; DR_SIZE_WORD = 1; DR_SIZE_DWORD = 3; DR_MODE_E = 0; DR_MODE_W = 1; DR_MODE_I = 2; DR_MODE_R = 3; DR7_MODE_DR0_E = DR_MODE_E shl 16; DR7_MODE_DR0_W = DR_MODE_W shl 16; DR7_MODE_DR0_I = DR_MODE_I shl 16; DR7_MODE_DR0_R = DR_MODE_R shl 16; DR7_SIZE_DR0_B = DR_SIZE_BYTE shl 18; DR7_SIZE_DR0_W = DR_SIZE_WORD shl 18; DR7_SIZE_DR0_D = DR_SIZE_DWORD shl 18; DR7_MODE_DR1_E = DR_MODE_E shl 20; DR7_MODE_DR1_W = DR_MODE_W shl 20; DR7_MODE_DR1_I = DR_MODE_I shl 20; DR7_MODE_DR1_R = DR_MODE_R shl 20; DR7_SIZE_DR1_B = DR_SIZE_BYTE shl 22; DR7_SIZE_DR1_W = DR_SIZE_WORD shl 22; DR7_SIZE_DR1_D = DR_SIZE_DWORD shl 22; DR7_MODE_DR2_E = DR_MODE_E shl 24; DR7_MODE_DR2_W = DR_MODE_W shl 24; DR7_MODE_DR2_I = DR_MODE_I shl 24; DR7_MODE_DR2_R = DR_MODE_R shl 24; DR7_SIZE_DR2_B = DR_SIZE_BYTE shl 26; DR7_SIZE_DR2_W = DR_SIZE_WORD shl 26; DR7_SIZE_DR2_D = DR_SIZE_DWORD shl 26; DR7_MODE_DR3_E = DR_MODE_E shl 28; DR7_MODE_DR3_W = DR_MODE_W shl 28; DR7_MODE_DR3_I = DR_MODE_I shl 28; DR7_MODE_DR3_R = DR_MODE_R shl 28; DR7_SIZE_DR3_B = DR_SIZE_BYTE shl 30; DR7_SIZE_DR3_W = DR_SIZE_WORD shl 30; DR7_SIZE_DR3_D = $C0000000; //DR_SIZE_DWORD shl 30; DR_On: array [THWBPIndex] of DWORD = ( DR7_SET_LOC_DR0, DR7_SET_LOC_DR1, DR7_SET_LOC_DR2, DR7_SET_LOC_DR3 ); DR_Mode: array [THWBPIndex] of array [THWBPMode] of DWORD = ( (DR7_MODE_DR0_E, DR7_MODE_DR0_W, DR7_MODE_DR0_I, DR7_MODE_DR0_R), (DR7_MODE_DR1_E, DR7_MODE_DR1_W, DR7_MODE_DR1_I, DR7_MODE_DR1_R), (DR7_MODE_DR2_E, DR7_MODE_DR2_W, DR7_MODE_DR2_I, DR7_MODE_DR2_R), (DR7_MODE_DR3_E, DR7_MODE_DR3_W, DR7_MODE_DR3_I, DR7_MODE_DR3_R) ); DR_Size: array [THWBPIndex] of array [THWBPSize] of DWORD = ( (DR7_SIZE_DR0_B, DR7_SIZE_DR0_W, DR7_SIZE_DR0_D), (DR7_SIZE_DR1_B, DR7_SIZE_DR1_W, DR7_SIZE_DR1_D), (DR7_SIZE_DR2_B, DR7_SIZE_DR2_W, DR7_SIZE_DR2_D), (DR7_SIZE_DR3_B, DR7_SIZE_DR3_W, DR7_SIZE_DR3_D) ); var Context: TContext; I: THWBPIndex; begin if ThreadIndex < 0 then Exit; ZeroMemory(@Context, SizeOf(TContext)); Context.ContextFlags := CONTEXT_DEBUG_REGISTERS; for I := 0 to 3 do begin if not FThreadList[ThreadIndex].Breakpoint.Active[I] then Continue; if FThreadList[ThreadIndex].Breakpoint.Address[I] <> nil then begin Context.Dr7 := Context.Dr7 or DR7_SET_LOC_ON; case I of 0: Context.Dr0 := DWORD(FThreadList[ThreadIndex].Breakpoint.Address[I]); 1: Context.Dr1 := DWORD(FThreadList[ThreadIndex].Breakpoint.Address[I]); 2: Context.Dr2 := DWORD(FThreadList[ThreadIndex].Breakpoint.Address[I]); 3: Context.Dr3 := DWORD(FThreadList[ThreadIndex].Breakpoint.Address[I]); end; Context.Dr7 := Context.Dr7 or DR_On[I]; Context.Dr7 := Context.Dr7 or DR_Mode[I, FThreadList[ThreadIndex].Breakpoint.Mode[I]]; Context.Dr7 := Context.Dr7 or DR_Size[I, FThreadList[ThreadIndex].Breakpoint.Size[I]]; end; end; Check(SetThreadContext(FThreadList[ThreadIndex].ThreadHandle, Context)); end; 

यदि आप कोड से पहले स्थिरांक के ब्लॉक पर ध्यान नहीं देते हैं, तो Dr7 रजिस्टर के आरंभ को तीन लाइनों के साथ लागू किया जाता है।

 Context.Dr7 := Context.Dr7 or DR_On[I]; Context.Dr7 := Context.Dr7 or DR_Mode[I, FThreadList[ThreadIndex].Breakpoint.Mode[I]]; Context.Dr7 := Context.Dr7 or DR_Size[I, FThreadList[ThreadIndex].Breakpoint.Size[I]]; 

खैर, DR7_SET_LOC_ON द्वारा निरूपित LE बिट के समावेश के अलावा।

अब हम HBP के प्रसंस्करण की ओर मुड़ते हैं।

जब BP ट्रिगर हुआ, तो हमें EXCEPTION_BREAKPOINT कोड प्राप्त हुआ।
जब MVR ट्रिगर किया गया था, तो कोड EXCEPTION_GUARD_PAGE था।
और HBP पर रुकावट होने पर, हम EXCEPTION_SBLE_STEP कोड के साथ एक EXCEPTION_DEBUG_EVENT घटना उत्पन्न करेंगे, जो अन्य बातों के अलावा, बीपी और एमबीपी की स्थिति को बहाल करने के लिए उपयोग किया जाता है (इसलिए, मैंने लेख की शुरुआत में इसके कार्यान्वयन का हवाला नहीं दिया)।

जब EXCEPTION_SINGLE_STEP प्राप्त होता है, तो HBP हैंडलर को पहले वाले के रूप में लागू किया जाता है:

 function TFWDebugerCore.ProcessHardwareBreakpoint(ThreadIndex: Integer; DebugEvent: TDebugEvent): Boolean; var Index: Integer; Context: TContext; ReleaseBP: Boolean; begin ZeroMemory(@Context, SizeOf(TContext)); Context.ContextFlags := CONTEXT_DEBUG_REGISTERS; Check(GetThreadContext(FThreadList[ThreadIndex].ThreadHandle, Context)); Result := Context.Dr6 and $F <> 0; if not Result then Exit; Index := -1; if Context.Dr6 and 1 <> 0 then Index := 0; if Context.Dr6 and 2 <> 0 then Index := 1; if Context.Dr6 and 4 <> 0 then Index := 2; if Context.Dr6 and 8 <> 0 then Index := 3; if Index < 0 then begin Result := False; Exit; end; ReleaseBP := False; if Assigned(FHardwareBreakpoint) then FHardwareBreakpoint(Self, ThreadIndex, DebugEvent.Exception.ExceptionRecord, Index, ReleaseBP); ToggleHardwareBreakpoint(ThreadIndex, Index, False); SetSingleStepMode(ThreadIndex, False); if ReleaseBP then DropHardwareBreakpoint(ThreadIndex, Index) else begin //   HWBP    , //  ..     //  ProcessExceptionSingleStep,   HWBP   //        HWBP if (FRestoredThread >= 0) and (FRestoredHWBPIndex >= 0) then ToggleHardwareBreakpoint(FRestoredThread, FRestoredHWBPIndex, True); FRestoredHWBPIndex := Index; FRestoredThread := ThreadIndex; end; end; 

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

HBP संख्या निर्धारित करने के लिए, थ्रेड संदर्भ से Dr6 रजिस्टर का मूल्य पढ़ना आवश्यक है।
इस रजिस्टर के निचले 4 बिट्स झंडे हैं जो मान 1 लेते हैं यदि संबंधित DrX रजिस्टर ने काम किया है।

सब कुछ काफी सरल है, आवश्यक एनवीआर निर्धारित करने के बाद, हम एक बाहरी घटना कहते हैं, एनवीआर को बंद कर देते हैं, प्रोसेसर को ट्रेस मोड में डालते हैं (ईआईपी को संपादित किए बिना), फिर या तो एनवीआर को हटा दें या दो चर में अपने इंडेक्स को स्टोर करें, जिस पर ध्यान केंद्रित करते हुए EXCEPTION_SINGLE_STEP हैंडलर NVR की स्थिति को पुनर्स्थापित करेगा।

खैर, ऐसा लगता है कि हम एक तार्किक निष्कर्ष पर आए हैं।
यह केवल EXCEPTION_SINGLE_STEP हैंडलर के कार्यान्वयन को दिखाने के लिए बना हुआ है।

यह इस तरह दिखता है:

 procedure TFWDebugerCore.ProcessExceptionSingleStep(ThreadIndex: Integer; DebugEvent: TDebugEvent); var Handled: Boolean; begin //  HWBP Handled := ProcessHardwareBreakpoint(ThreadIndex, DebugEvent); //    - HWPB   HWBP if not Handled and (FRestoredThread >= 0) and (FRestoredHWBPIndex >= 0) then begin ToggleHardwareBreakpoint(FRestoredThread, FRestoredHWBPIndex, True); FRestoredThread := -1; FRestoredHWBPIndex := -1; end; //   if FRestoreBPIndex >= 0 then begin CheckBreakpointIndex(FRestoreBPIndex); if FBreakpointList[FRestoreBPIndex].bpType = btBreakpoint then ToggleInt3Breakpoint(FRestoreBPIndex, True); FRestoreBPIndex := -1; end; //  M if FRestoreMBPIndex >= 0 then begin CheckBreakpointIndex(FRestoreMBPIndex); if FBreakpointList[FRestoreMBPIndex].bpType = btMemoryBreakpoint then ToggleMemoryBreakpoint(FRestoreMBPIndex, True); FRestoreMBPIndex := -1; end; //         //     if ResumeAction <> raRun then begin CallUnhandledExceptionEvents(ThreadIndex, ecSingleStep, DebugEvent); //          DoResumeAction(ThreadIndex); end; end; 

उनका कार्य शुरू में यह निर्धारित करना है कि HBP पर रोक के कारण कोई अपवाद उत्पन्न हुआ है या नहीं। यदि यह सच है, तो ToggleHardwareBreakpoint पर कॉल करके HBP अपनी जगह पर लौट आता है।
यदि अपवाद को उठाया गया था क्योंकि बीपी या एमवीपी प्रसंस्करण के बाद ट्रेस ध्वज को चालू किया गया था, तो वैरिएबल FRestoreBPIndex और FRestoreMBPIndex उस ब्रेकपॉइंट के सूचकांक को इंगित करेगा, जिसे अपनी जगह पर लौटने की आवश्यकता है।
इसके प्रकार के आधार पर, कॉल ToggleInt3Breakpoint या ToggleMemoryBreakpoint तरीकों से किए जाते हैं।

अभ्यास:

मैं डिबगर कार्यान्वयन के वर्णन के साथ इसे समाप्त करूंगा, लेकिन अपना समय ले लो - कुछ और बिंदु हैं जो मैं व्यवहार में दिखाना चाहूंगा।
खैर, जैसा कि उस विमान के बारे में मज़ाक है: "अब हम इस पूरे डोंगी को हवा में उठाने की कोशिश करेंगे" :)

इसके लिए, हमें दो अनुप्रयोगों को लागू करने की आवश्यकता है।

सबसे पहले, हम इसे डीबग करने का प्रयास करेंगे। एक नया VCL प्रोजेक्ट बनाएं, इसे "test_app" नाम से सहेजें और फिर प्रोजेक्ट संकलित करें।

अब हम डिबगर एप्लिकेशन लिखेंगे। इसके लिए हमारे पास पर्याप्त फॉर्म, दो बटन (डिबगिंग प्रक्रिया को शुरू करने और रोकने के लिए) और TMemo या TRichEdit होगा, जहां सभी जानकारी प्रदर्शित की जाएगी।

हम लिखते हैं:

 type TdlgDebuger = class(TForm) Panel1: TPanel; btnStart: TButton; btnStop: TButton; edLog: TRichEdit; procedure btnStartClick(Sender: TObject); procedure btnStopClick(Sender: TObject); private FCore: TFWDebugerCore; FNeedStop: Boolean; procedure Writeln(const Value: string = ''); end; ... procedure TdlgDebuger.btnStartClick(Sender: TObject); var Path: string; begin FNeedStop := False; //        Path := ExtractFilePath(ParamStr(0)) + '..\test_app\test_app.exe'; FCore := TFWDebugerCore.Create(50); try btnStart.Enabled := False; btnStop.Enabled := True; if not FCore.DebugNewProcess(Path, True) then RaiseLastOSError; FCore.RunMainLoop; finally FCore.Free; btnStart.Enabled := True; btnStop.Enabled := False; end; Writeln; Writeln('Debug stop'); end; procedure TdlgDebuger.Writeln(const Value: string); begin edLog.Lines.Add(Value); end; procedure TdlgDebuger.btnStopClick(Sender: TObject); begin FNeedStop := True; end; 

आपको कुछ इस तरह मिलना चाहिए:



"प्रारंभ" बटन पर क्लिक करें, अगर सब कुछ सही ढंग से किया जाता है, तो परीक्षण आवेदन शुरू हो जाएगा।

इस मामले में, मुख्य अनुप्रयोग माउस और कीबोर्ड कमांड का व्यावहारिक रूप से जवाब देना बंद कर देगा।

तथ्य यह है कि शुरू करने के बाद यह TFWDebugerCore.RunMainLoop डिबगिंग चक्र के अंदर स्थित है, जो संदेश कतार भ्रूण चक्र को क्रियान्वित करने से रोकता है।

परीक्षण एप्लिकेशन को बंद करें, यह डिबगर को डिबगिंग चक्र से बाहर निकलने की अनुमति देगा और खिड़की के साथ काम करने का अवसर देगा।

अच्छे तरीके से, डिबगर को एक अलग थ्रेड में चलाने की आवश्यकता होती है (या बल्कि, एक अच्छे तरीके से नहीं, बल्कि यह सही तरीका है), लेकिन इसे लॉन्च किए बिना भी, हम TFWDebugerCore क्लास के ऑनइयर इवेंट को बंद करके सामान्य तरीके से काम कर सकते हैं, जिसमें हम निम्नलिखित कोड लिखते हैं:

 procedure TdlgDebuger.OnIdle(Sender: TObject); begin if FNeedStop then FCore.StopDebug else Application.ProcessMessages; end; 

Application.ProcessMessages को कॉल करना हमारे आवेदन को प्रक्रिया में धीमा नहीं होने देगा।

अब डेल्फी डिबगर प्रदर्शित करता है कि प्रक्रिया के बारे में डिबगिंग जानकारी प्राप्त करने की कोशिश करते हैं। ऐसा करने के लिए, OnCreateProcess और OnLoadDll संचालकों को कनेक्ट करें।

पहले में हम निम्नलिखित लिखते हैं:

 procedure TdlgDebuger.OnCreateProcess(Sender: TObject; ThreadIndex: Integer; Data: TCreateProcessDebugInfo); var T: TThreadData; begin T := FCore.GetThreadData(ThreadIndex); Writeln(Format('CreateThread ID: %d', [T.ThreadID])); Writeln(Format('ProcessStart ID: %d', [FCore.DebugProcessData.ProcessID])); end; 

दूसरे में, यह कोड:

 procedure TdlgDebuger.OnLoadDll(Sender: TObject; ThreadIndex: Integer; Data: TLoadDLLDebugInfo); const FormatStrKnownDLL = 'Load Dll at instance %p handle %d "%s"'; FormatStrUnknownDLL = 'Load unknown Dll at instance %p handle %d'; var DllName: AnsiString; IsUnicodeData: Boolean; begin FCore.ContinueStatus := DBG_EXCEPTION_NOT_HANDLED; IsUnicodeData := Data.fUnicode = 1; DllName := FCore.GetDllName(Data.lpImageName, Data.lpBaseOfDll, IsUnicodeData); if DllName <> '' then begin if IsUnicodeData then Writeln(Format(FormatStrKnownDLL, [Data.lpBaseOfDll, Data.hFile, PWideChar(@DllName[1])])) else Writeln(Format(FormatStrKnownDLL, [Data.lpBaseOfDll, Data.hFile, PAnsiChar(@DllName[1])])); end else Writeln(Format(FormatStrUnknownDLL, [Data.lpBaseOfDll, Data.hFile])); end; 

उसके बाद, हम डिबगिंग एप्लिकेशन को फिर से शुरू करेंगे और "स्टार्ट" बटन दबाएंगे।

निम्नलिखित होना चाहिए:



ठीक है, ऐसा लगता है - ऐसा लगता है।

ट्रेस कार्यान्वयन:

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



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

 procedure TdlgDebuger.OnBreakPoint(Sender: TObject; ThreadIndex: Integer; ExceptionRecord: Windows.TExceptionRecord; BreakPointIndex: Integer; var ReleaseBreakpoint: Boolean); begin //      Writeln(Format('!!! --> Breakpoint "%s"', [FCore.BreakpointItem(BreakPointIndex).Description])); //   (    ) ReleaseBreakpoint := True; //    FCore.ResumeAction := raTraceInto; //     FStepCount := 0; end; 

चूंकि अनुरेखण OnSingleStep ईवेंट की पीढ़ी के माध्यम से होता है, इसलिए हम इसे लागू भी करते हैं:

 procedure TdlgDebuger.OnSingleStep(Sender: TObject; ThreadIndex: Integer; ExceptionRecord: Windows.TExceptionRecord); begin //      Inc(FStepCount); Writeln(Format('!!! --> trace step №%d at addr 0x%p', [FStepCount, ExceptionRecord.ExceptionAddress])); //        if FStepCount > 10 then FCore.ResumeAction := raRun else FCore.ResumeAction := raTraceInto; end; 

परिणाम निम्नलिखित निष्कर्ष होगा:



हमने StepIn ट्रेस किया, ट्रेस का पांचवां चरण जो 0x00409FF4 पर हुआ था, यह स्पष्ट रूप से हमें दिखाता है, यह _InitExe () फ़ंक्शन की शुरुआत है, जिसे 0x00409C53 कहा जाता है। अनुरेखण एक धीमी प्रक्रिया है और मैंने _InitExe () फ़ंक्शन से वापस लौटने के लिए नियंत्रण की प्रतीक्षा करना शुरू नहीं किया, प्रदर्शन के लिए मैंने खुद को एक दर्जन चरणों तक सीमित कर लिया।

दूसरा ट्रेस मोड MVR की स्थापना है।
इसे प्रदर्शित करने के लिए, OnPageGuard इवेंट को ब्लॉक करना और प्रवेश बिंदु पर पहुंचने के लिए, शून्य की एक नियंत्रित मेमोरी रेंज के साथ SetMemoryBreakpoint विधि को कॉल करना आवश्यक है। इस स्थिति में, डिबगर को MBP द्वारा मॉनिटर किए जा रहे पृष्ठ के बारे में पता चल जाएगा, लेकिन इस MBP के लिए ऑनब्रेक हैंडलर को नहीं बुलाया जाएगा। इस अनुरेखण विकल्प के कार्यान्वयन को आपके विवेक पर छोड़ दिया गया है, मैं आपको केवल एक संकेत देता हूं, यह अत्यधिक अनुशंसा की जाती है कि डीबग इवेंट संचालकों (इंडेक्स गायब हो जाए) से RemoveBreakpoint विधि को कॉल न करें, बीपी / एमबीपी / एचबीपी को हटाने के लिए दो तरीके हैं, जब बीपी हैंडलर कहा जाता है। , या किसी भी हैंडलर में उपलब्ध RemoveCurrentBreakpoint प्रक्रिया। संभवतः TFWDebugerCore वर्ग के निम्नलिखित कार्यान्वयन में इस व्यवहार को संशोधित किया जाएगा,लेकिन कुछ समय के लिए, ऐसा विकल्प जाएगा।

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

डिबग स्ट्रिंग प्राप्त करना:

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

 // //    // ============================================================================= procedure TForm1.btnDebugStringClick(Sender: TObject); begin OutputDebugString('Test debug string'); end; 

फिर, डिबगर में, निम्न कोड को लागू करके OnDebugString ईवेंट को बंद करें:

 procedure TdlgDebuger.OnDebugString(Sender: TObject; ThreadIndex: Integer; Data: TOutputDebugStringInfo); begin if Data.fUnicode = 1 then Writeln('DebugString: ' + PWideChar(FCore.ReadStringW(Data.lpDebugStringData, Data.nDebugStringLength))) else Writeln('DebugString: ' + PAnsiChar(FCore.ReadStringA(Data.lpDebugStringData, Data.nDebugStringLength))); end; 

डीबगर चलाएँ, इसमें डीबग किए गए अनुप्रयोग और बटन पर क्लिक करें। संदेश "टेस्ट डिबग स्ट्रिंग" लॉग में प्रदर्शित किया जाता है? यदि हाँ, तो सब कुछ सही ढंग से किया गया था :)

अपवाद हैंडलिंग:

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

 // //       // ============================================================================= procedure TForm1.btnExceptClick(Sender: TObject); begin try asm int 3 end; ShowMessage('Debugger detected.'); except ShowMessage('Debugger not found.'); end; end; 

यह, सिद्धांत रूप में, विरोधी डिबगिंग भी नहीं है, लेकिन अजीब तरह से कभी-कभी कुछ उलटफेर ऐसी प्राइमरी स्कीम पर भी झुलस रहे हैं।

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

खैर, अब उपरोक्त कोड के उदाहरण के साथ इसका क्या मतलब है: "INT3" निर्देश को लागू करके, हम एक अपवाद बढ़ाते हैं। आवेदन के सामान्य संचालन के दौरान, इस अपवाद को संभालने के लिए कोई नहीं है, इसलिए जब ऐसा होता है, तो अपवाद के लिए एक संक्रमण..हैंडलर होता है, जिसमें हम कहते हैं कि सब कुछ ठीक है। यदि हम डिबगर के अधीन हैं, तो वह इस अपवाद को पकड़ लेगा और एप्लिकेशन हैंडलर को नहीं बुलाया जाएगा।

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

यह इस कोड को पार करने के लिए बस के रूप में सरल है, यह OnUnognBreakPoint ईवेंट को ब्लॉक करने के लिए पर्याप्त है (int3 एक ब्रेकपॉइंट है, और यह हमारे द्वारा सेट नहीं किया गया था, इसलिए, यह इस ईवेंट में पकड़ा जाएगा)। ईवेंट हैंडलर में, निम्न कोड लिखें:

 procedure TdlgDebuger.OnUnknownBreakPoint(Sender: TObject; ThreadIndex: Integer; ExceptionRecord: Windows.TExceptionRecord); var ApplicationBP: Boolean; begin ApplicationBP := (DWORD(ExceptionRecord.ExceptionAddress) > FCore.DebugProcessData.EntryPoint) and (DWORD(ExceptionRecord.ExceptionAddress) < $500000); Writeln; if ApplicationBP then begin Writeln(Format('!!! --> Unknown application breakpoint at addr 0X%p', [ExceptionRecord.ExceptionAddress])); Writeln('!!! --> Exception not handled.'); FCore.ContinueStatus := DBG_EXCEPTION_NOT_HANDLED; end else begin Writeln(Format('!!! --> Unknown breakpoint at addr 0X%p', [ExceptionRecord.ExceptionAddress])); Writeln('!!! --> Exception handled.'); FCore.ContinueStatus := DBG_CONTINUE; end; Writeln; end; 

इसमें सब कुछ सरल है, जिस पते पर बीपी स्थापित है, उसके आधार पर हम एप्लिकेशन बॉडी में उसका स्थान निर्धारित करते हैं या नहीं (मोटे तौर पर एप्लिकेशन के डाउनलोड पते से $ 500,000 तक की सीमा लेते हैं)। यदि आवेदन के शरीर में बीपी स्थापित होता है, तो यह कुछ प्रकार का एंटी-डिबगिंग है। हम डिबगर से कहते हैं कि हमें पता नहीं है कि DBG_EXCEPTION_NOT_HANDLED ध्वज सेट करके इसके साथ क्या करना है, अन्यथा हम बस उस जानकारी को लॉग इन करते हैं जो कोई और व्यक्ति ब्रेकप्वाइंट के साथ खेल रहा है।

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

स्टैक ओवरफ्लो होने पर क्या होता है:

खैर, आखिरी बात मैं आपको दिखाना चाहता था कि डिबगर के किनारे से स्टैक ओवरफ्लो कैसे दिखता है। मैं पिछले लेखों में से एक से अतिप्रवाह का उदाहरण लूंगा, उदाहरण के लिए, इस तरह:

 // //      // ============================================================================= procedure TForm1.btnKillStackClick(Sender: TObject); procedure T; var HugeBuff: array [0..10000] of DWORD; begin if HugeBuff[0] <> HugeBuff[10000] then Inc(HugeBuff[0]); T; end; begin try T; except T; end; end; 

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

हम OnUnognException इवेंट में ओवरफ़्लो हैंडलर लागू करते हैं, क्योंकि TFWDebugerCore इन दो अपवादों को अलग-अलग घटनाओं के रूप में नहीं फेंकता है। हम इसमें निम्नलिखित लिखेंगे:

 procedure TdlgDebuger.OnUnknownException(Sender: TObject; ThreadIndex: Integer; ExceptionRecord: Windows.TExceptionRecord); var Cause: string; begin Writeln; case ExceptionRecord.ExceptionCode of EXCEPTION_STACK_OVERFLOW: begin Writeln('!!! --> Stack overflow detected. Probe to continue.'); FCore.ContinueStatus := DBG_CONTINUE; end; EXCEPTION_ACCESS_VIOLATION: begin { The first element of the array contains a read-write flag that indicates the type of operation that caused the access violation. If this value is zero, the thread attempted to read the inaccessible data. If this value is 1, the thread attempted to write to an inaccessible address. If this value is 8, the thread causes a user-mode data execution prevention (DEP) violation. The second array element specifies the virtual address of the inaccessible data. } case ExceptionRecord.ExceptionInformation[0] of 0: Cause := 'read'; 1: Cause := 'write'; 8: Cause := 'DEP violation'; else Cause := 'unknown cause'; end; Writeln(Format('!!! --> Access violation at addr 0x%p %s of address 0x%p', [ ExceptionRecord.ExceptionAddress, Cause, Pointer(PDWORD(@ExceptionRecord.ExceptionInformation[1])^) ])); Writeln('!!! --> Process Stopped.'); FCore.ContinueStatus := DBG_CONTROL_C; end; else Writeln(Format('!!! --> Unknown exception code %p at addr 0x%p', [ Pointer(ExceptionRecord.ExceptionCode), ExceptionRecord.ExceptionAddress ])); end; Writeln; end; 

इसे इस तरह से बदलना चाहिए:

संक्षेप में:

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

लेख के लिए स्रोत कोड इस लिंक पर डाउनलोड किया जा सकता है: http://rouse.drkb.ru/blog/dbg_part2.zip

खैर, लेख के तीसरे भाग में हम डिबगर के आवेदन पर विरोध को देखेंगे, जो वास्तव में यह डिबग नहीं होना चाहता है :)

और इस पर मेरे पास वास्तव में सब कुछ है।

© अलेक्जेंडर (Rouse_) Bagel
मॉस्को, नवंबर 2012