मेमोरी कार्ड प्रोसेस करें

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

पूछो क्यों?
खैर, 32-बिट एप्लिकेशन के लिए, 2-3 गीगाबाइट आपकी सीमा है जिसके बाहर आप AWE का उपयोग किए बिना बाहर निकल सकते हैं, लेकिन यह अभी भी अपने स्वयं के संसाधनों को नियंत्रित करने के लिए वांछनीय है। लेकिन इसके बिना भी, बस यह पता लगाने के लिए ...

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

आइए देखें कि डिबगिंग के दौरान प्रोग्रामर मेमोरी के साथ कैसे काम करता है (विशेषकर जब किसी थर्ड-पार्टी एप्लिकेशन को डीबग करते हुए, दूसरे शब्दों में, रिवीजन करते समय):

1. एक नियम के रूप में, सबसे अधिक लगातार संचालन एप्लिकेशन मेमोरी में मूल्यों की खोज करना है और, दुर्भाग्य से, यह कार्यक्षमता किसी कारण से डेल्फी डिबगर में उपलब्ध नहीं है (वास्तव में, एमएस वीसी ++ में)।
2. सिस्टम संरचनाओं का संशोधन (PEB / TEB / SEHChain / Unwind / PE फ़ाइलों की निर्देशिका आदि ...) बहुत आसान हो जाएगा जब संरचनाओं के क्षेत्र उन पतों पर अनमैप हो जाते हैं जो वे पढ़ते हैं और एक पठनीय रूप में प्रस्तुत किए जाते हैं।
3. प्रक्रिया मेमोरी में ट्रैकिंग परिवर्तन (लगभग कोई कार्यक्षमता प्रदान नहीं की गई, लोकप्रिय डीबगर्स के लिए प्लग इन के रूप में कार्यान्वित)। वास्तव में, क्यों एक नीले रंग का पता लगाने के लिए जब मेमोरी कार्ड की दो तस्वीरों की तुलना करने के लिए पर्याप्त है यह समझने के लिए कि हमें जो डेटा संशोधन की आवश्यकता है वह यहां हो रही है या नहीं?

हां, वास्तव में, कई उपयोग के मामले हैं।

हालांकि, अगर गीत के बिना, बहुत कम उपयोगिताओं हैं जो डिबगिंग के लिए उपयोग की जाने वाली प्रक्रिया मेमोरी कार्ड के बारे में अधिक या कम जानकारी प्रदर्शित करते हैं।

सबसे सुविधाजनक कार्यान्वयन ओलीडबग 2 से है, लेकिन, दुर्भाग्य से, यह 64 बिट्स पर डेटा प्रदर्शित नहीं करता है (हम अभी भी इंतजार कर रहे हैं)।


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


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


खैर, मुझे इसके साथ काम करने के इतने सालों के लिए आईडीए प्रो मेमोरी कार्ड की आदत नहीं है (मैं सहज नहीं हूं :)

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

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

1. उपलब्ध क्षेत्रों की एक सूची प्राप्त करें

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

एक क्षेत्र क्या है?
मोटे तौर पर ( MSDN पर आधारित ) सभी पृष्ठों का एक सेट होता है, जिसमें समान विशेषताएँ होती हैं, जो VirtualQuery फ़ंक्शन को दिए गए पते से शुरू होती हैं।

सबसे सरल रूप में, आप इस कोड के साथ हमारी प्रक्रिया के क्षेत्रों की एक सूची प्राप्त कर सकते हैं:

program Project1; {$APPTYPE CONSOLE} {$R *.res} uses Windows, SysUtils; var MBI: TMemoryBasicInformation; dwLength: NativeUInt; Address: PByte; begin Address := nil; dwLength := SizeOf(TMemoryBasicInformation); while VirtualQuery(Address, MBI, dwLength) <> 0 do begin Writeln( 'AllocationBase: ', IntToHex(NativeUInt(MBI.AllocationBase), 8), ', BaseAddress: ', IntToHex(NativeUInt(MBI.BaseAddress), 8), ', RegionSize: ', MBI.RegionSize); Inc(Address, MBI.RegionSize); end; Readln; end. 

उदाहरण के लिए, हमने शुरुआत में पता पैरामीटर को पहले पैरामीटर के रूप में पारित किया है। फ़ंक्शन को कॉल करने के बाद, MBI वैरिएबल निम्नलिखित मान लेगा:

• बेसअड्रेस = नील
• अलोकेशनबेस = नील
• आबंटनप्रक्रिया = ०
• क्षेत्रसाइज = $ 10000
• राज्य = $ 10,000
• रक्षा करना = १
• टाइप_9 = 0

क्षेत्र का आकार $ 10,000 (64 kb) है, यह एक पंक्ति में 16 पृष्ठों से मेल खाता है, पता शून्य से शुरू होता है, जिसका राज्य (राज्य) MEM_FREE ($ 10,000) है और सुरक्षा विशेषता PAGE_NO_ACCESS (1) सुरक्षा पैरामीटर में सेट है।

यदि आप इस तरह कोड को फिर से लिखते हैं:

 function ExtractAccessString(const Value: DWORD): string; const PAGE_WRITECOMBINE = $400; begin Result := 'Unknown access'; if (Value and PAGE_EXECUTE) = PAGE_EXECUTE then Result := 'E'; if (Value and PAGE_EXECUTE_READ) = PAGE_EXECUTE_READ then Result := 'RE'; if (Value and PAGE_EXECUTE_READWRITE) = PAGE_EXECUTE_READWRITE then Result := 'RWE'; if (Value and PAGE_EXECUTE_WRITECOPY) = PAGE_EXECUTE_WRITECOPY then Result := 'RE, Write copy'; if (Value and PAGE_NOACCESS) = PAGE_NOACCESS then Result := 'No access'; if (Value and PAGE_READONLY) = PAGE_READONLY then Result := 'R'; if (Value and PAGE_READWRITE) = PAGE_READWRITE then Result := 'RW'; if (Value and PAGE_WRITECOPY) = PAGE_WRITECOPY then Result := 'Write copy'; if (Value and PAGE_GUARD) = PAGE_GUARD then Result := Result + ', Guarded'; if (Value and PAGE_NOCACHE) = PAGE_NOCACHE then Result := Result + ', No cache'; if (Value and PAGE_WRITECOMBINE) = PAGE_WRITECOMBINE then Result := Result + ', Write Combine'; end; function ExtractRegionTypeString(Value: TMemoryBasicInformation): string; begin Result := ''; case Value.State of MEM_FREE: Result := 'Free'; MEM_RESERVE: Result := 'Reserved'; MEM_COMMIT: case Value.Type_9 of MEM_IMAGE: Result := 'Image'; MEM_MAPPED: Result := 'Mapped'; MEM_PRIVATE: Result := 'Private'; end; end; Result := Result + ', ' + ExtractAccessString(Value.Protect); end; var MBI: TMemoryBasicInformation; dwLength: NativeUInt; Address: PByte; begin Address := nil; dwLength := SizeOf(TMemoryBasicInformation); while VirtualQuery(Address, MBI, dwLength) <> 0 do begin Writeln( 'AllocationBase: ', IntToHex(NativeUInt(MBI.AllocationBase), 8), ', BaseAddress: ', IntToHex(NativeUInt(MBI.BaseAddress), 8), ' - ', ExtractRegionTypeString(MBI)); Inc(Address, MBI.RegionSize); end; 

... तो आप VirtualAlloc फ़ंक्शन के साथ क्षेत्रीयकरण के सिद्धांत को स्पष्ट रूप से देख सकते हैं:


उदाहरण के लिए, दूसरे और तीसरे क्षेत्रों में एक ही पहुंच विशेषता (रिकॉर्ड पढ़ें) है, लेकिन अलग-अलग आवंटन। VirtualAlloc के माध्यम से मेमोरी आवंटित करते समय AllocationBase पृष्ठों को सौंपा जाता है, इस प्रकार उन्हें एक अलग क्षेत्र में संयोजित किया जाता है।

2. हम प्रवाह पर डेटा एकत्र करते हैं

समय आ गया है कि हम उन क्षेत्रों के बारे में जानकारी प्राप्त करें जिन्हें वे संग्रहीत करते हैं, और हम प्रवाह (धागे - जो भी आपको पसंद हैं) के साथ शुरू करेंगे।

थ्रेड की सूची प्राप्त करने के लिए कोड सरल है - CreateToolhelp32Snapshot के माध्यम से।

 const THREAD_GET_CONTEXT = 8; THREAD_SUSPEND_RESUME = 2; THREAD_QUERY_INFORMATION = $40; ThreadBasicInformation = 0; ThreadQuerySetWin32StartAddress = 9; STATUS_SUCCESS = 0; var hSnap, hThread: THandle; ThreadEntry: TThreadEntry32; TBI: TThreadBasicInformation; TIB: NT_TIB; lpNumberOfBytesRead: NativeUInt; ThreadStartAddress: Pointer; begin //      hSnap := CreateToolhelp32Snapshot(TH32CS_SNAPTHREAD, GetCurrentProcessId); if hSnap <> INVALID_HANDLE_VALUE then try ThreadEntry.dwSize := SizeOf(TThreadEntry32); if Thread32First(hSnap, ThreadEntry) then repeat if ThreadEntry.th32OwnerProcessID <> GetCurrentProcessId then Continue; Writeln('ThreadID: ', ThreadEntry.th32ThreadID); //   hThread := OpenThread(THREAD_GET_CONTEXT or THREAD_SUSPEND_RESUME or THREAD_QUERY_INFORMATION, False, ThreadEntry.th32ThreadID); if hThread <> 0 then try //   ThreadProc() if NtQueryInformationThread(hThread, ThreadQuerySetWin32StartAddress, @ThreadStartAddress, SizeOf(ThreadStartAddress), nil) = STATUS_SUCCESS then Writeln('ThreadProcAddr: ', IntToHex(NativeUInt(ThreadStartAddress), 1)); //     if NtQueryInformationThread(hThread, ThreadBasicInformation, @TBI, SizeOf(TThreadBasicInformation), nil) = STATUS_SUCCESS then begin Writeln('Thread Environment Block (TEB) Addr: ', IntToHex(NativeUInt(TBI.TebBaseAddress), 1)); //      // TIB (Thread Information Block)   if ReadProcessMemory(GetCurrentProcess, TBI.TebBaseAddress, @TIB, SizeOf(NT_TIB), lpNumberOfBytesRead) then begin Writeln('Thread StackBase Addr: ', IntToHex(NativeUInt(TIB.StackBase), 1)); Writeln('Thread StackLimit Addr: ', IntToHex(NativeUInt(TIB.StackLimit), 1)); end; end; finally CloseHandle(hThread); end; until not Thread32Next(hSnap, ThreadEntry); finally CloseHandle(hSnap); end; Readln; end. 

कदम:

1. CreateToolhelp32Snapshot / Thread32First / Thread32Next का उपयोग करके हमें अपने एप्लिकेशन से सक्रिय थ्रेड की एक सूची मिलती है।
2. अधिक विस्तृत जानकारी के लिए, आपको थ्रेड को हैंडल की आवश्यकता होती है, जिसे ओपनथ्रेड कहकर प्राप्त किया जाता है।
3. NtQueryInformationTread के उपयोग से हमें थ्रेड प्रक्रिया का पता मिलता है जिसके साथ उसने काम करना शुरू किया, और TThreadBasicInformation संरचना के रूप में थ्रेड के बारे में बुनियादी जानकारी।
4. इस संरचना में से, हम केवल एक क्षेत्र में रुचि रखते हैं - TebBaseAddress, जिसमें स्ट्रीम पर्यावरण ब्लॉक का पता शामिल है, तथाकथित TEB (थ्रेड एनवायरनमेंट ब्लॉक)।
5. ReadProcessMemory (हालांकि यह आपके आवेदन के लिए बेमानी है) को कॉल करके, हम TEB पते पर डेटा पढ़ते हैं, अर्थात् इसका पहला पैरामीटर, जो एक NT_TIB संरचना है।

NT_TIB घोषणा कुछ इस तरह दिखती है:

  PNT_TIB = ^_NT_TIB; _NT_TIB = record ExceptionList: Pointer; StackBase, StackLimit, SubSystemTib: Pointer; case Integer of 0: ( FiberData: Pointer ); 1: ( Version: ULONG; ArbitraryUserPointer: Pointer; Self: PNT_TIB; ) end; NT_TIB = _NT_TIB; PPNT_TIB = ^PNT_TIB; 

ठीक है, या इस तरह, यदि आप थोड़ा और वर्णन करते हैं:

• ExceptionList - एक 32-बिट प्रक्रिया में, वर्तमान SEH फ्रेम के पते के लिए एक संकेतक (EXCEPTION_REGISTRATION संरचना)। इस जानकारी के आधार पर, हम SEH फ्रेम की पूरी श्रृंखला को खोल देंगे।
• यदि TEB 32-बिट एप्लिकेशन में चलने वाली 64-बिट स्ट्रीम से संबंधित है, तो यह फ़ील्ड उसके 32-बिट एनालॉग के ExceptionList फ़ील्ड को इंगित करेगा।
• 64-बिट प्रक्रिया में, यह क्षेत्र हमेशा अशक्त होता है, क्योंकि 64 बिट्स के लिए, एसईएच तंत्र के बजाय थोड़ा अलग तंत्र काम करता है।
• स्टैकबेस - स्टैक का आधार। जिस पते से स्टैकलिमिट की दिशा में स्टैक बढ़ना शुरू होता है।
• StackLimit स्टैक का वर्तमान शीर्ष है।
• आर्बिट्वेलरपॉइंटर एक मुफ्त टीएलएस स्लॉट की तरह है। मोटे तौर पर, एक धारा से संबंधित एक चर जिसका मूल्य प्रोग्रामर द्वारा अपनी जरूरतों के लिए मनमाने ढंग से बदला जा सकता है।
• स्वयं - TEB पते वाला पैरामीटर (अर्थात स्वयं)

शेष खेतों की जरूरत नहीं है।

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

यह कोड हमें निम्नलिखित चित्र प्रदर्शित करेगा:


और इसलिए यह VMMap में देखा जाएगा।


चित्र से पता चलता है कि VMMap TEB के बारे में जानकारी प्रदर्शित नहीं करता था।

वैसे, ऊपर दिए गए कोड से कुछ फ़ंक्शन और संरचनाएं मानक डेल्फी स्रोतों में घोषित नहीं की जाती हैं, आप उनकी घोषणा को डेमो उदाहरणों में देख सकते हैं जो इस लेख का हिस्सा हैं। लेकिन इसका मतलब यह नहीं है कि वे MSDN में प्रलेखित नहीं हैं :)

यदि हम अपनी स्ट्रीम के TEB के साथ काम करना चाहते हैं, तो कोड को इस तथ्य के कारण बहुत सरल किया जाएगा कि आपको ToolHelp32.dll फ़ंक्शन का उपयोग करने की आवश्यकता नहीं है, बल्कि FS खंड रजिस्टर (x64 के लिए GS) का उपयोग करें।
उदाहरण के लिए, इस तरह के एक समारोह अक्सर TEB पता प्राप्त करने के लिए पाया जाता है:

 function GetCurrentTEB: NativeUInt; asm {$IFDEF WIN64} // mov RAX, qword ptr GS:[30h] //   ,      64-  DB $65, $48, $8B, $04, $25, $30, 0, 0, 0 //    ,    mov RAX, qword ptr GS:[abs $30] {$ELSE} mov EAX, FS:[18h] {$ENDIF} end; 

इस मामले में, TEB संरचना के पैरामीटर NtTIB.Self को एक्सेस किया जाता है, जो इसकी शुरुआत से ऑफसेट 0x18 (या 64-बिट TEB के मामले में 0x30) पर स्थित है।

हालाँकि, हम जारी रखते हैं ...
प्राप्त आंकड़ों का हिस्सा है, लेकिन यह हमारे लिए उपलब्ध सभी जानकारी नहीं है।

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

यहां हम ऐसी सरल प्रक्रिया के साथ SEH फ्रेम के प्रचार से निपटेंगे:

 procedure GetThreadSEHFrames(InitialAddr: Pointer); type EXCEPTION_REGISTRATION = record prev, handler: Pointer; end; var ER: EXCEPTION_REGISTRATION; lpNumberOfBytesRead: NativeUInt; begin while ReadProcessMemory(GetCurrentProcess, InitialAddr, @ER, SizeOf(EXCEPTION_REGISTRATION), lpNumberOfBytesRead) do begin Writeln('SEH Frame at Addr: ', IntToHex(NativeUInt(InitialAddr), 1), ', handler at addr: ', IntToHex(NativeUInt(ER.handler), 1)); InitialAddr := ER.prev; if DWORD(InitialAddr) <= 0 then Break; end; end; 

TEB.TIB.ExceptionList मान प्राप्त करने के बाद, जो एक पैरामीटर के रूप में पहली EXCEPTION_REGISTRATION संरचना को इंगित करता है, यह इन संरचनाओं की श्रृंखला के साथ चलता है, इस संरचना के मौजूदा मूल्य पर ध्यान केंद्रित करता है, जिसमें पिछले EXCEPTION_REGISTRATION संरचना का पता होता है। और हैंडलर पैरामीटर में अपवाद हैंडलर का पता होता है यदि यह अचानक होता है।

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


खैर, कॉलस्टैक को निम्नलिखित प्रक्रिया प्राप्त होगी:

 procedure GetThreadCallStack(hThread: THandle); var StackFrame: TStackFrame; ThreadContext: PContext; MachineType: DWORD; begin // ThreadContext   ,   VirtualAlloc //         //     ERROR_NOACCESS (998) ThreadContext := VirtualAlloc(nil, SizeOf(TContext), MEM_COMMIT, PAGE_READWRITE); try ThreadContext^.ContextFlags := CONTEXT_FULL; if not GetThreadContext(hThread, ThreadContext^) then Exit; ZeroMemory(@StackFrame, SizeOf(TStackFrame)); StackFrame.AddrPC.Mode := AddrModeFlat; StackFrame.AddrStack.Mode := AddrModeFlat; StackFrame.AddrFrame.Mode := AddrModeFlat; StackFrame.AddrPC.Offset := ThreadContext.Eip; StackFrame.AddrStack.Offset := ThreadContext.Esp; StackFrame.AddrFrame.Offset := ThreadContext.Ebp; MachineType := IMAGE_FILE_MACHINE_I386; while True do begin if not StackWalk(MachineType, GetCurrentProcess, hThread, @StackFrame, ThreadContext, nil, nil, nil, nil) then Break; if StackFrame.AddrPC.Offset <= 0 then Break; Writeln('CallStack Frame Addr: ', IntToHex(NativeUInt(StackFrame.AddrFrame.Offset), 1)); Writeln('CallStack Handler: ', IntToHex(NativeUInt(StackFrame.AddrPC.Offset), 1)); Writeln('CallStack Stack: ', IntToHex(NativeUInt(StackFrame.AddrStack.Offset), 1)); Writeln('CallStack Return: ', IntToHex(NativeUInt(StackFrame.AddrReturn.Offset), 1)); end; finally VirtualFree(ThreadContext, SizeOf(TContext), MEM_FREE); end; end; 

सच है, डेल्फी डिबगर के विपरीत, यह उन प्रक्रियाओं के बारे में डेटा आउटपुट करेगा जिनके लिए स्टैक फ्रेम उत्पन्न होता है, यह बाकी को छोड़ देगा।
StackWalk (या StackWalk64) फ़ंक्शन स्टैक फ़्रेम के बारे में जानकारी सूचीबद्ध करने के लिए ज़िम्मेदार है।

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

यह निम्न कारण से होगा: StackWalk फ़ंक्शन को ठीक से पता लगाने के लिए, वर्तमान स्टैक फ्रेम (EB64 और ESP / RBP और RS64 के लिए RSP) के मापदंडों को निर्दिष्ट करना आवश्यक है) और, वास्तव में, वर्तमान कोड पता (X64 के लिए EIP या RIP रजिस्टर)। यदि हम इस डेटा को स्वयं से लेते हैं, तो यह उस समय होगा जब हम GetThreadContext फ़ंक्शन को कॉल करते हैं, और हम इस फ़ंक्शन से बाहर निकलने के बाद स्टैक को स्पिन करना शुरू कर देंगे, जहां सभी तीन पैरामीटर बन जाते हैं, इसे हल्के ढंग से डालने के लिए, मान्य नहीं। इस कारण से, यह फ़ंक्शन को कॉल करके खुद को ट्रेस करने के लिए काम नहीं करेगा।
इस बिंदु पर विचार करने के लिए वांछनीय है ...

मैं 64-बिट OS के तहत 32-बिट प्रक्रिया के थ्रेड्स के बारे में जानकारी प्राप्त करने पर ध्यान केंद्रित करूंगा, जिसमें 32 और 64-बिट वेरिएंट थोड़ी देर बाद शामिल होंगे, लेकिन अब ...

3. हम ढेर के बारे में डेटा एकत्र करते हैं

डेल्फी आवेदन ही, एक नियम के रूप में, हीप्स का उपयोग नहीं करता है, यह सी ++ अनुप्रयोगों की अधिकता है, लेकिन अभी भी हीप्स यहां मौजूद हैं। आमतौर पर वे अपनी आवश्यकताओं के लिए विभिन्न तृतीय-पक्ष पुस्तकालयों द्वारा बनाए और उपयोग किए जाते हैं।

हीप डेटा प्राप्त करने में अति सूक्ष्म अंतर यह है कि प्रत्येक ढेर को बनाने वाले हीपेंट्री तत्व कई हजार हो सकते हैं, और दूसरी बारीकियों यह है कि हीवेट 2 नेक्स्ट फ़ंक्शन प्रत्येक कॉल के साथ पूरी सूची को फिर से बनाता है, एक काफी संवेदनशील देरी (अप करने के लिए) दसियों सेकंड)।

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

 const RTL_HEAP_BUSY = 1; RTL_HEAP_SEGMENT = 2; RTL_HEAP_SETTABLE_VALUE = $10; RTL_HEAP_SETTABLE_FLAG1 = $20; RTL_HEAP_SETTABLE_FLAG2 = $40; RTL_HEAP_SETTABLE_FLAG3 = $80; RTL_HEAP_SETTABLE_FLAGS = $E0; RTL_HEAP_UNCOMMITTED_RANGE = $100; RTL_HEAP_PROTECTED_ENTRY = $200; RTL_HEAP_FIXED = (RTL_HEAP_BUSY or RTL_HEAP_SETTABLE_VALUE or RTL_HEAP_SETTABLE_FLAG2 or RTL_HEAP_SETTABLE_FLAG3 or RTL_HEAP_SETTABLE_FLAGS or RTL_HEAP_PROTECTED_ENTRY); STATUS_SUCCESS = 0; function CheckSmallBuff(Value: DWORD): Boolean; const STATUS_NO_MEMORY = $C0000017; STATUS_BUFFER_TOO_SMALL = $C0000023; begin Result := (Value = STATUS_NO_MEMORY) or (Value = STATUS_BUFFER_TOO_SMALL); end; function FlagToStr(Value: DWORD): string; begin case Value of LF32_FIXED: Result := 'LF32_FIXED'; LF32_FREE: Result := 'LF32_FREE'; LF32_MOVEABLE: Result := 'LF32_MOVEABLE'; else Result := ''; end; end; var I, A: Integer; pDbgBuffer: PRtlDebugInformation; pHeapInformation: PRtlHeapInformation; pHeapEntry: PRtrHeapEntry; dwAddr, dwLastSize: ULONG_PTR; hit_seg_count: Integer; BuffSize: NativeUInt; begin // ..  Heap32ListFirst, Heap32ListNext, Heap32First, Heap32Next //   , -   // RtlQueryProcessDebugInformation   ,     //      //    BuffSize := $400000; pDbgBuffer := RtlCreateQueryDebugBuffer(BuffSize, False); //       while CheckSmallBuff(RtlQueryProcessDebugInformation(GetCurrentProcessId, RTL_QUERY_PROCESS_HEAP_SUMMARY or RTL_QUERY_PROCESS_HEAP_ENTRIES, pDbgBuffer)) do begin //     , ... RtlDestroyQueryDebugBuffer(pDbgBuffer); BuffSize := BuffSize shl 1; pDbgBuffer := RtlCreateQueryDebugBuffer(BuffSize, False); end; if pDbgBuffer <> nil then try //       if RtlQueryProcessDebugInformation(GetCurrentProcessId, RTL_QUERY_PROCESS_HEAP_SUMMARY or RTL_QUERY_PROCESS_HEAP_ENTRIES, pDbgBuffer) = STATUS_SUCCESS then begin //       pHeapInformation := @pDbgBuffer^.Heaps^.Heaps[0]; //    ... for I := 0 to pDbgBuffer^.Heaps^.NumberOfHeaps - 1 do begin //     pHeapEntry := pHeapInformation^.Entries; dwAddr := DWORD(pHeapEntry^.u.s2.FirstBlock) + pHeapInformation^.EntryOverhead; dwLastSize := 0; A := 0; while A < Integer(pHeapInformation^.NumberOfEntries) do try hit_seg_count := 0; while (pHeapEntry^.Flags and RTL_HEAP_SEGMENT) = RTL_HEAP_SEGMENT do begin //     RTL_HEAP_SEGMENT, //       EntryOverhead dwAddr := DWORD(pHeapEntry^.u.s2.FirstBlock) + pHeapInformation^.EntryOverhead; Inc(pHeapEntry); Inc(A); Inc(hit_seg_count); //      if A + hit_seg_count >= Integer(pHeapInformation^.NumberOfEntries - 1) then Continue; end; //       ,     , //    +    if hit_seg_count = 0 then Inc(dwAddr, dwLastSize); //   if pHeapEntry^.Flags and RTL_HEAP_FIXED <> 0 then pHeapEntry^.Flags := LF32_FIXED else if pHeapEntry^.Flags and RTL_HEAP_SETTABLE_FLAG1 <> 0 then pHeapEntry^.Flags := LF32_MOVEABLE else if pHeapEntry^.Flags and RTL_HEAP_UNCOMMITTED_RANGE <> 0 then pHeapEntry^.Flags := LF32_FREE; if pHeapEntry^.Flags = 0 then pHeapEntry^.Flags := LF32_FIXED; //   Writeln('HeapID: ', I, ', entry addr: ', IntToHex(dwAddr, 8), ', size: ', IntToHex(pHeapEntry^.Size, 8), ' ', FlagToStr(pHeapEntry^.Flags)); //     dwLastSize := pHeapEntry^.Size; //     Inc(pHeapEntry); finally Inc(A); end; //     Inc(pHeapInformation); end; end; finally RtlDestroyQueryDebugBuffer(pDbgBuffer); end; Readln; end. 

संक्षेप में, RtlQueryProcessDebugInformation, RtlCreateQueryDebugBuffer, और RtlQueryProcessDebugInformation फ़ंक्शंस को कॉल करके, एक बफर बनाया जाता है जिसमें वर्तमान डेटा ढेर के बारे में जानकारी होती है। फिर, इसमें संग्रहीत डेटा की संरचना को जानने के बाद, हम इस डेटा को लूप में प्राप्त करते हैं।
pDbgBuffer ^ .Heaps - हीप सूचियों (THeapList32 का एनालॉग) को संग्रहीत करता है, और रिकॉर्ड खुद pDbgBuffer ^ .Heaps ^ .Heaps [N] .Entries (THeapEntry32 का एनालॉग) में संग्रहीत किए जाते हैं।

यह कोड निम्नलिखित जानकारी को आउटपुट करेगा:


सिद्धांत रूप में, मैं डिबगिंग का उपयोग तब करता हूं जब बहुत कम डिबगिंग होता है, लेकिन कभी-कभी यह जानकारी काम में आ सकती है।

4. हम डाउनलोड की गई पीई फ़ाइलों पर डेटा एकत्र करते हैं

अब यह निष्पादन योग्य फ़ाइलों और पुस्तकालयों के बारे में जानकारी प्राप्त करने का समय है, जो प्रक्रिया के पता स्थान में लोड किए गए हैं। ऐसा करने के कई तरीके हैं (उदाहरण के लिए, PEB.LoaderData का विश्लेषण करके), लेकिन चलो इसे आसान करते हैं।

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

निम्न कोड निर्दिष्ट पते पर एक मान्य पीई फ़ाइल की उपस्थिति का पता लगाता है:

 function CheckPEImage(hProcess: THandle; ImageBase: Pointer; var IsPEImage64: Boolean): Boolean; var ReturnLength: NativeUInt; IDH: TImageDosHeader; NT: TImageNtHeaders; begin Result := False; IsPEImage64 := False; if not ReadProcessMemory(hProcess, ImageBase, @IDH, SizeOf(TImageDosHeader), ReturnLength) then Exit; if IDH.e_magic <> IMAGE_DOS_SIGNATURE then Exit; ImageBase := Pointer(NativeInt(ImageBase) + IDH._lfanew); if not ReadProcessMemory(hProcess, ImageBase, @NT, SizeOf(TImageNtHeaders), ReturnLength) then Exit; Result := NT.Signature = IMAGE_NT_SIGNATURE; IsPEImage64 := (NT.FileHeader.Machine = IMAGE_FILE_MACHINE_IA64) or (NT.FileHeader.Machine = IMAGE_FILE_MACHINE_ALPHA64) or (NT.FileHeader.Machine = IMAGE_FILE_MACHINE_AMD64); end; 

ठीक है, अधिक सटीक रूप से, वह बस अपने हस्ताक्षर पर ध्यान केंद्रित करते हुए ImageDosHeader और ImageNTHeader की उपस्थिति की जांच करता है। सिद्धांत रूप में, 99% मामलों के लिए यह पर्याप्त है।

तीसरा पैरामीटर सिर्फ जानकारीपूर्ण है, यह दर्शाता है कि पीई फ़ाइल 64-बिट है या नहीं।

आप GetMappedFileName फ़ंक्शन को कॉल करके डाउनलोड की गई फ़ाइल के लिए पथ प्राप्त कर सकते हैं:

 function GetFileAtAddr(hProcess: THandle; ImageBase: Pointer): string; begin SetLength(Result, MAX_PATH); SetLength(Result, GetMappedFileName(hProcess, ImageBase, @Result[1], MAX_PATH)); end; 

और अब देखते हैं कि हम एक नियमित कंसोल एप्लीकेशन में क्या लोड कर रहे हैं:

 var MBI: TMemoryBasicInformation; dwLength: NativeUInt; Address: PByte; IsPEImage64: Boolean; begin Address := nil; dwLength := SizeOf(TMemoryBasicInformation); while VirtualQuery(Address, MBI, dwLength) <> 0 do begin if CheckPEImage(GetCurrentProcess, MBI.BaseAddress, IsPEImage64) then begin Write(IntToHex(NativeUInt(MBI.BaseAddress), 8), ': ', GetFileAtAddr(GetCurrentProcess, MBI.BaseAddress)); if IsPEImage64 then Writeln(' (x64)') else Writeln(' (x32)'); end; Inc(Address, MBI.RegionSize); end; Readln; end. 

आपको निम्न चित्र मिलता है:


32-बिट एप्लिकेशन में 64-बिट लाइब्रेरी? हाँ, यह आसान है :)

मेरे पास एक 32-बिट एप्लिकेशन, ऑपरेटिंग सिस्टम विंडोज 7 x64 है। चित्र में जो दिखाया गया है, उसे देखते हुए, चार 64-बिट लाइब्रेरी हमारी 32-बिट प्रक्रिया में चुपचाप रहते हैं और काम करते हैं, हालांकि, यहां कुछ भी असामान्य नहीं है - यह तथाकथित Wow64 ( 64-बिट विंडोज में Win32 अनुकरण ) है।

लेकिन यह तुरंत स्पष्ट हो जाता है कि 32-बिट धाराओं और ढेर के 64-बिट एनालॉग कहां से आते हैं।

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

आइए इसे ऐसे करें:

 procedure GetInfoFromImage(const FileName: string; ImageBase: Pointer); var ImageInfo: TLoadedImage; ImageSectionHeader: PImageSectionHeader; I: Integer; begin if MapAndLoad(PAnsiChar(AnsiString(FileName)), nil, @ImageInfo, True, True) then try ImageSectionHeader := ImageInfo.Sections; for I := 0 to Integer(ImageInfo.NumberOfSections) - 1 do begin Write( IntToHex((NativeUInt(ImageBase) + ImageSectionHeader^.VirtualAddress), 8), ': ', string(PAnsiChar(@ImageSectionHeader^.Name[0]))); if IsExecute(ImageSectionHeader^.Characteristics) then Write(' Execute'); if IsWrite(ImageSectionHeader^.Characteristics) then Write(' Writable'); Writeln; Inc(ImageSectionHeader); end; finally UnMapAndLoad(@ImageInfo); end; Writeln; end; 

यहां हम MapAndLoad फ़ंक्शन के लिए एक कॉल का उपयोग करते हैं, जो फ़ाइल को लोड करने और उसके हेडर की जांच करने के अलावा, NtMapViewOfSection को कॉल करके अनुभाग संरेखण भी करता है।

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

MapAndLoad भी अच्छा है क्योंकि यह 64-बिट प्रक्रियाओं को 32-बिट PE फ़ाइलों को लोड करने की अनुमति देता है (हालांकि यह 32-बिट प्रक्रियाओं के लिए काम नहीं करता है), और यह सुविधा बाद में काम आएगी।

कोड का सार यह है: MapAndLoad निष्पादित करने के बाद, हमारे पास हाथ पर एक TLoadedImage संरचना होगी, जिसमें सेक्शन पैरामीटर TImageSectionHeader संरचनाओं की एक सरणी को इंगित करता है। इनमें से प्रत्येक संरचना में एक VirtualAddress फ़ील्ड है, जो लाइब्रेरी लोड पते से ऑफसेट है। इस क्षेत्र के मूल्य को hInstance लाइब्रेरी के साथ जोड़कर, हमें अनुभाग का पता मिलता है।

IsExecute और IsWrite फ़ंक्शंस अनुभाग की विशेषताओं की जाँच करते हैं और यदि अनुभाग में निष्पादन योग्य कोड (IsExecute) या संशोधन (IsWrite) के लिए उपलब्ध डेटा शामिल है, तो वापस लौटें। वे इस प्रकार दिखते हैं:

 function IsExecute(const Value: DWORD): Boolean; begin Result := False; if (Value and IMAGE_SCN_CNT_CODE) = IMAGE_SCN_CNT_CODE then Result := True; if (Value and IMAGE_SCN_MEM_EXECUTE) = IMAGE_SCN_MEM_EXECUTE then Result := True; end; function IsWrite(const Value: DWORD): Boolean; begin Result := False; if (Value and IMAGE_SCN_CNT_UNINITIALIZED_DATA) = IMAGE_SCN_CNT_UNINITIALIZED_DATA then Result := True; if (Value and IMAGE_SCN_MEM_WRITE) = IMAGE_SCN_MEM_WRITE then Result := True; end; 

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


सच है, इस कोड के साथ एक और छोटी अति सूक्ष्म अंतर है।
जैसा कि पिछली तस्वीर में देखा गया है, GetMappedFileName फ़ंक्शन निम्न फ़ाइल में डाउनलोड किए गए फ़ाइल का पथ देता है: "\ Device \ HarddiskVolume2 \ Windows \ System32 \ wow64cpu.dll", और MapAndLoad फ़ंक्शन को "C: \ Windows \ System32 \ wow64cpu के लिए सामान्यीकृत पथ की आवश्यकता होती है। डीएल। "

निम्न कोड परिचित रूप में रास्ता लाने के लिए जिम्मेदार है:

 function NormalizePath(const Value: string): string; const OBJ_CASE_INSENSITIVE = $00000040; STATUS_SUCCESS = 0; FILE_SYNCHRONOUS_IO_NONALERT = $00000020; FILE_READ_DATA = 1; ObjectNameInformation = 1; DriveNameSize = 4; VolumeCount = 26; DriveTotalSize = DriveNameSize * VolumeCount; var US: UNICODE_STRING; OA: OBJECT_ATTRIBUTES; IO: IO_STATUS_BLOCK; hFile: THandle; NTSTAT, dwReturn: DWORD; ObjectNameInfo: TOBJECT_NAME_INFORMATION; Buff, Volume: string; I, Count, dwQueryLength: Integer; lpQuery: array [0..MAX_PATH - 1] of Char; AnsiResult: AnsiString; begin Result := Value; //     ZwOpenFile RtlInitUnicodeString(@US, StringToOleStr(Value)); //   InitializeObjectAttributes FillChar(OA, SizeOf(OBJECT_ATTRIBUTES), #0); OA.Length := SizeOf(OBJECT_ATTRIBUTES); OA.ObjectName := @US; OA.Attributes := OBJ_CASE_INSENSITIVE; //  ZwOpenFile   ,     //    , : // \SystemRoot\System32\ntdll.dll // \??\C:\Windows\System32\ntdll.dll // \Device\HarddiskVolume1\WINDOWS\system32\ntdll.dll //        NTSTAT := ZwOpenFile(@hFile, FILE_READ_DATA or SYNCHRONIZE, @OA, @IO, FILE_SHARE_READ or FILE_SHARE_WRITE or FILE_SHARE_DELETE, FILE_SYNCHRONOUS_IO_NONALERT); if NTSTAT = STATUS_SUCCESS then try //  ,      NTSTAT := NtQueryObject(hFile, ObjectNameInformation, @ObjectNameInfo, MAX_PATH * 2, @dwReturn); if NTSTAT = STATUS_SUCCESS then begin SetLength(AnsiResult, MAX_PATH); WideCharToMultiByte(CP_ACP, 0, @ObjectNameInfo.Name.Buffer[ObjectNameInfo.Name.MaximumLength - ObjectNameInfo.Name.Length {$IFDEF WIN64} + 4{$ENDIF}], ObjectNameInfo.Name.Length, @AnsiResult[1], MAX_PATH, nil, nil); Result := string(PAnsiChar(AnsiResult)); //     ZwOpenFile  //    \Device\HarddiskVolume\- //        SetLength(Buff, DriveTotalSize); Count := GetLogicalDriveStrings(DriveTotalSize, @Buff[1]) div DriveNameSize; for I := 0 to Count - 1 do begin Volume := PChar(@Buff[(I * DriveNameSize) + 1]); Volume[3] := #0; //         //     QueryDosDevice(PChar(Volume), @lpQuery[0], MAX_PATH); dwQueryLength := Length(string(lpQuery)); if Copy(Result, 1, dwQueryLength) = string(lpQuery) then begin Volume[3] := '\'; if lpQuery[dwQueryLength - 1] <> '\' then Inc(dwQueryLength); Delete(Result, 1, dwQueryLength); Result := Volume + Result; Break; end; end; end; finally ZwClose(hFile); end; end; 

यह पहले से ही काफी पुराना कोड है, जिसे मैं सामान्य पथ पर लाने के लिए लगातार उपयोग करता हूं। इसका सार निम्न प्रकार के रास्तों से है:

• \ SystemRoot \ System32 \ ntdll.dll
• \ ?? \ C: \ Windows \ System32 \ ntdll.dll
• \ Device \ HarddiskVolume1 \ WINDOWS \ system32 \ ntdll.dll

… "\Device\HarddiskVolume1\WINDOWS\system32\ntdll.dll".
ZwOpenFile + NtQueryObject, QueryDosDevice, . ( ) .

.
, PE , , , , , UNWIND ..

:

 procedure EnumDirectoryes(ImageBase: Pointer; ImageInfo: TLoadedImage; AddrStart, AddrEnd: NativeUInt); const DirectoryStr: array [0..14] of string = ('export', 'import', 'resource', 'exception', 'security', 'basereloc', 'debug', 'copyright', 'globalptr', 'tls', 'load_config', 'bound_import', 'iat', 'delay_import', 'com'); var I: Integer; dwDirSize: DWORD; DirAddr: Pointer; ReadlDirAddr: NativeUInt; begin for I := 0 to 14 do begin DirAddr := ImageDirectoryEntryToData(ImageInfo.MappedAddress, True, I, dwDirSize); if DirAddr = nil then Continue; ReadlDirAddr := NativeUint(ImageBase) + NativeUint(DirAddr) - NativeUint(ImageInfo.MappedAddress); if (ReadlDirAddr >= AddrStart) and (ReadlDirAddr < AddrEnd) then Writeln( IntToHex(ReadlDirAddr, 8), ': directory "', DirectoryStr[I], '"'); end; end; 

TLoadedImage, ImageDirectoryEntryToData , , , PE . , , , , ImageBase .

:


यह तुरंत स्पष्ट है कि, उदाहरण के लिए, msctf.dll पुस्तकालय के ".text" अनुभाग में आयात / निर्यात / लंबित आयात निर्देशिकाएं आदि हैं।
संसाधन निर्देशिका ".rsrc" अनुभाग में बैठती है, और रिलेक्स भी हैं जहां उन्हें होना चाहिए, हालांकि, "बाउंड_मपोर्ट" निर्देशिका योजना से बाहर हो जाती है।

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

, , , .
, , , .

5. (PEB) + KUSER_SHARED_DATA

, , , , ?

, .

NtQueryInformationProcess ProcessBasicInformation ( ). PROCESS_BASIC_INFORMATION, PebBaseAddress PEB.

, ( ) . 64- 32-, 64- PEB, 32-.

Wow64PEB को 64-बिट एप्लिकेशन (इसे कॉल करें) से एक्सेस करने के लिए, आपको NtWInformationProcess फ़ंक्शन को ProcessWow64Information पैरामीटर (26 के बराबर निरंतर) और Sizeff (ULONG_PTR) के बराबर बफर आकार के साथ कॉल करने की आवश्यकता है। इस स्थिति में, PROCESS_BASIC_INFORMATION संरचना के बजाय, फ़ंक्शन एक पॉइंटर को 32-बिट PEB में लौटाएगा, जिसमें से हम ReadProcessMemory का उपयोग करके आवश्यक जानकारी पढ़ेंगे।

PEB क्या है?
, , , . , . , : BeingDebugged, ; PEB_LDR_DATA, ; , , :)

( Windows7 x86/64):

  PPEB = ^TPEB; TPEB = record InheritedAddressSpace: BOOLEAN; ReadImageFileExecOptions: BOOLEAN; BeingDebugged: BOOLEAN; BitField: BOOLEAN; { BOOLEAN ImageUsesLargePages : 1; BOOLEAN IsProtectedProcess : 1; BOOLEAN IsLegacyProcess : 1; BOOLEAN IsImageDynamicallyRelocated : 1; BOOLEAN SkipPatchingUser32Forwarders : 1; BOOLEAN IsPackagedProcess : 1; BOOLEAN IsAppContainer : 1; BOOLEAN SpareBits : 1; } Mutant: HANDLE; ImageBaseAddress: PVOID; LoaderData: PVOID; ProcessParameters: PRTL_USER_PROCESS_PARAMETERS; SubSystemData: PVOID; ProcessHeap: PVOID; FastPebLock: PRTLCriticalSection; AtlThunkSListPtr: PVOID; IFEOKey: PVOID; EnvironmentUpdateCount: ULONG; UserSharedInfoPtr: PVOID; SystemReserved: ULONG; AtlThunkSListPtr32: ULONG; ApiSetMap: PVOID; TlsExpansionCounter: ULONG; TlsBitmap: PVOID; TlsBitmapBits: array[0..1] of ULONG; ReadOnlySharedMemoryBase: PVOID; HotpatchInformation: PVOID; ReadOnlyStaticServerData: PPVOID; AnsiCodePageData: PVOID; OemCodePageData: PVOID; UnicodeCaseTableData: PVOID; KeNumberOfProcessors: ULONG; NtGlobalFlag: ULONG; CriticalSectionTimeout: LARGE_INTEGER; HeapSegmentReserve: SIZE_T; HeapSegmentCommit: SIZE_T; HeapDeCommitTotalFreeThreshold: SIZE_T; HeapDeCommitFreeBlockThreshold: SIZE_T; NumberOfHeaps: ULONG; MaximumNumberOfHeaps: ULONG; ProcessHeaps: PPVOID; GdiSharedHandleTable: PVOID; ProcessStarterHelper: PVOID; GdiDCAttributeList: ULONG; LoaderLock: PRTLCriticalSection; NtMajorVersion: ULONG; NtMinorVersion: ULONG; NtBuildNumber: USHORT; NtCSDVersion: USHORT; PlatformId: ULONG; Subsystem: ULONG; MajorSubsystemVersion: ULONG; MinorSubsystemVersion: ULONG; AffinityMask: ULONG_PTR; {$IFDEF WIN32} GdiHandleBuffer: array [0..33] of ULONG; {$ELSE} GdiHandleBuffer: array [0..59] of ULONG; {$ENDIF} PostProcessInitRoutine: PVOID; TlsExpansionBitmap: PVOID; TlsExpansionBitmapBits: array [0..31] of ULONG; SessionId: ULONG; AppCompatFlags: ULARGE_INTEGER; AppCompatFlagsUser: ULARGE_INTEGER; pShimData: PVOID; AppCompatInfo: PVOID; CSDVersion: UNICODE_STRING; ActivationContextData: PVOID; ProcessAssemblyStorageMap: PVOID; SystemDefaultActivationContextData: PVOID; SystemAssemblyStorageMap: PVOID; MinimumStackCommit: SIZE_T; FlsCallback: PPVOID; FlsListHead: LIST_ENTRY; FlsBitmap: PVOID; FlsBitmapBits: array [1..FLS_MAXIMUM_AVAILABLE div SizeOf(ULONG) * 8] of ULONG; FlsHighIndex: ULONG; WerRegistrationData: PVOID; WerShipAssertPtr: PVOID; pContextData: PVOID; pImageHeaderHash: PVOID; TracingFlags: ULONG; { ULONG HeapTracingEnabled : 1; ULONG CritSecTracingEnabled : 1; ULONG LibLoaderTracingEnabled : 1; ULONG SpareTracingBits : 29; } CsrServerReadOnlySharedMemoryBase: ULONGLONG; end; 

, , MSDN .

Window 2000/XP/2003 , .
, PEB ? , .

तो:

• BeingDebugged — . PEB BeingDebugged , IsDebuggerPresent, , False, ? .
• ImageBaseAddress — hInstance ( ImageBase PE ).
• LoaderData — , , , , , . , :)
• ProcessParameters — ParamStr/GetCurrentDir .. ? . .
• , , CSDVersion. , , NtMajorVersion/NtMinorVersion/NtBuildNumber .

अच्छी तरह से और इतने पर - आप लंबे समय तक जारी रख सकते हैं।

इन क्षेत्रों में से अधिकांश प्रक्रिया पता स्थान में अपने पृष्ठों पर कब्जा कर लेते हैं। उदाहरण के लिए, ProcessParameters आमतौर पर लोडर द्वारा बनाए गए ढेर में से एक में बैठता है, पर्यावरण चर भी उस क्षेत्र में कहीं स्थित हैं।

यदि हम यह सब कल्पना करना चाहते हैं (और मैं इसके लिए अग्रणी हूं), हमारे पास यह डेटा हाथ में होना चाहिए ताकि अंतिम एप्लिकेशन में कुछ प्रदर्शित हो सके।

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


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

• यदि आप जानना चाहते हैं कि GetForegroundWindow को कॉल किए बिना कौन सी प्रक्रिया सक्रिय है, तो ConsoleSessionForegroundProcessId पढ़ें।
• क्या आप विन के बाएं संस्करण को खिसकाने का प्रयास कर रहे हैं ताकि पिछले ओएस के लिए डिज़ाइन नहीं किए गए सुरक्षा प्रणाली का हिस्सा काट दिया जाए? वर्तमान मानों को पढ़ें NtMajorVersion / NtMinorVersion फ़ील्ड्स से ...

हालाँकि, शायद, हम यहाँ अभी के लिए बंद हो जाएगा ...

6. ट्रेजियनडॉटा

इस पर सैद्धांतिक भाग समाप्त हो गया और इसे सभी को अभ्यास में लाने का समय आ गया।

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

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

प्रत्येक क्षेत्र के लिए जानकारी TRegionData वर्ग द्वारा संग्रहीत की जाएगी, जिसे "MemoryMap.RegionData.pas" मॉड्यूल में लागू किया गया है।

यह लगभग इस प्रकार दिखता है (एक परियोजना के विकास की प्रक्रिया में, कक्षा की घोषणा बदल सकती है)।

  TRegionData = class private FParent: TRegionData; FRegionType: TRegionType; FMBI: TMemoryBasicInformation; FDetails: string; FRegionVisible: Boolean; FHiddenRegionCount: Integer; FTotalRegionSize: NativeUInt; FHeap: THeapData; FThread: TThreadData; FPEBData: TSystemData; FSection: TSection; FContains: TList; FDirectories: TList; FShared: Boolean; FSharedCount: Integer; FFiltered: Boolean; protected ... public constructor Create; destructor Destroy; override; property RegionType: TRegionType read FRegionType; property MBI: TMemoryBasicInformation read FMBI; property Details: string read FDetails; property RegionVisible: Boolean read FRegionVisible; property HiddenRegionCount: Integer read FHiddenRegionCount; property Parent: TRegionData read FParent; property TotalRegionSize: NativeUInt read FTotalRegionSize; property Heap: THeapData read FHeap; property Thread: TThreadData read FThread; property SystemData: TSystemData read FPEBData; property Section: TSection read FSection; property Directory: TList read FDirectories; property Contains: TList read FContains; end; 

क्रम में:

प्रत्येक क्षेत्र, एक नियम के रूप में, अपने आप में एक प्रकार का डेटा संग्रहीत करता है।
यानीढेर के लिए, धाराओं के ढेर, पीई फाइलें, पृष्ठों का अपना क्षेत्र आवंटित किया जाता है।
क्षेत्र प्रकार संग्रहीत करने के लिए रीजनल टाइप प्रॉपर्टी जिम्मेदार है। यह एक एनुमरेटेड प्रकार है जो निम्नानुसार घोषित किया गया है:

  //   TRegionType = ( rtDefault, rtHeap, //     rtThread, //      TEB rtSystem, //     (PEB/KUSER_SHARED_DATA  ..) rtExecutableImage //     PE  ); 

, VirtualQueryEx MBI.

Details. , PE , , ID .…

.
(), .
RegionVisible , .
HiddenRegionCount (AllocationBase BaseAddress ).
Parent .
, , , , - :)

TotalRegionSize , .

, , Heap, :

  THeapEntry = record Address: ULONG_PTR; Size: SIZE_T; Flags: ULONG; end; THeapData = record ID: DWORD; Wow64: Boolean; Entry: THeapEntry; end; 

, , Contains.

Contains .

  TContainItemType = (itHeapBlock, itThreadData, itStackFrame, itSEHFrame, itSystem); TContainItem = record ItemType: TContainItemType; function Hash: string; case Integer of 0: (Heap: THeapData); 1: (ThreadData: TThreadData); 2: (StackFrame: TThreadStackEntry); 3: (SEH: TSEHEntry); 4: (System: TSystemData); end; 

Thread, , .

 type TThreadInfo = (tiNoData, tiExceptionList, tiStackBase, tiStackLimit, tiTEB, tiThreadProc); type TThreadData = record Flag: TThreadInfo; ThreadID: Integer; Address: Pointer; Wow64: Boolean; end; 

यदि क्षेत्र के भीतर बहुत सारे प्रवाह डेटा हैं (उदाहरण के लिए, SEH फ़्रेम या कॉलस्टैक प्रवाह की एक सूची), तो उन्हें भी Contains फ़ील्ड में रखा गया है।

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

यदि क्षेत्र PE फ़ाइल के किसी एक अनुभाग से संबंधित है, तो अनुभाग डेटा को अनुभाग पैरामीटर में रखा गया है। खैर, फ़ाइल निर्देशिकाओं की सूची निर्देशिका क्षेत्र में रखी गई है।

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

TMemoryMap वर्ग इसके लिए जिम्मेदार है ...

7. TMemoryMap

इस वर्ग को "MemoryMap.Core.pas" मॉड्यूल में लागू किया गया है।
इसका कार्य वस्तुतः तीन मुख्य चरणों में घटा है:

1. निर्दिष्ट आवेदन की स्मृति में सभी चयनित क्षेत्रों की एक सूची प्राप्त करें, थ्रेड्स / हीप्स / लोड की गई छवियों, आदि पर डेटा।
2. TRegionData सूची बनाना और प्राप्त जानकारी के साथ अपने क्षेत्रों में भरना।
3. डेटा को सहेजना / लोड करना, डेटा को फ़िल्टर करना।

व्यवहार में, सब कुछ थोड़ा अधिक जटिल दिखता है।
जानकारी एकत्र करने की मूल प्रक्रिया इस प्रकार है:

 function TMemoryMap.InitFromProcess(PID: Cardinal; const ProcessName: string): Boolean; var ProcessLock: TProcessLockHandleList; begin Result := False; FRegions.Clear; FModules.Clear; FFilter := fiNone; ProcessLock := nil; //     FProcess := OpenProcess( PROCESS_QUERY_INFORMATION or PROCESS_VM_READ, False, PID); if FProcess = 0 then RaiseLastOSError; try FPID := PID; FProcessName := ProcessName; //    FProcess64 := False; {$IFDEF WIN64} if not IsWow64(FProcess) then FProcess64 := True; {$ELSE} //    32 ,    64- //   if Is64OS and not IsWow64(FProcess) then raise Exception.Create('Can''t scan process.'); {$ENDIF} //     if SuspendProcessBeforeScan then ProcessLock := SuspendProcess(PID); try FSymbols := TSymbols.Create(FProcess); try FPEImage := TPEImage.Create; try FWorkset := TWorkset.Create(FProcess);; try //        GetAllRegions; finally FWorkset.Free; end; {$IFDEF WIN64} //       32   AddWow64HeapsData; {$ENDIF} //     AddThreadsData; //     AddHeapsData; //    Process Environment Block AddPEBData; //     PE  AddImagesData; finally FPEImage.Free; end; finally FSymbols.Free; end; finally if SuspendProcessBeforeScan then ResumeProcess(ProcessLock); end; //  SortAllContainsBlocks; //      CalcTotal; //    UpdateRegionFilters; finally CloseHandle(FProcess); end; end; 

GetAllRegions/AddThreadsData/AddHeapsData AddImagesData , .

.
, , ( ), , .

:

1. 32- 32- 32- .
2. 64- 64- .
3. 32- 64-.
4. 32- 32- 64- , .
5. 64- 32-, .

, .

32- 64- : , ReadProcessMemory ERROR_PARTIAL_COPY.

32- 64- .
, 32- 64- , /.

32- , 32 , 64- .

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

 const ProcessWow64Information = 26; ... NtQueryInformationProcess(FProcess, ProcessWow64Information, @FPebWow64BaseAddress, SizeOf(ULONG_PTR), @ReturnLength) 

32-बिट टीईबी तक पहुंच 64-बिट टीईबी से पते को पढ़कर प्राप्त की जा सकती है, जो NtTIB.ExceptionList पैरामीटर में संग्रहीत है।

  //  64  TEB  TIB.ExceptionList    Wow64TEB if not ReadProcessMemory(hProcess, TIB.ExceptionList, @WOW64_NT_TIB, SizeOf(TWOW64_NT_TIB), lpNumberOfBytesRead) then Exit; 

आप इस कोड के साथ कॉलस्टैक प्रचार के लिए 32-बिट स्ट्रीम का संदर्भ प्राप्त कर सकते हैं:

 const ThreadWow64Context = 29; ... ThreadContext^.ContextFlags := CONTEXT_FULL; if NtQueryInformationThread(hThread, ThreadWow64Context, ThreadContext, SizeOf(TWow64Context), nil) <> STATUS_SUCCESS then Exit; 

या Wow64GetThreadContext फ़ंक्शन को कॉल करके।

लेकिन मैं नहीं जानता कि कानूनी तरीके से 64-बिट प्रक्रिया से 32-बिट हीप के बारे में डेटा कैसे प्राप्त किया जाए। एकमात्र विकल्प जो अब मैं लागू कर रहा हूं वह 32-बिट प्रक्रिया के लिए एक कमांड भेज रहा है, जो 32-बिट हीप के बारे में डेटा एकत्र करता है और इसे 64-बिट पर वापस भेजता है (यह AddWow64HeapsData फ़ंक्शन में हैंडलर करता है)।

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

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

एक दूरस्थ प्रक्रिया को ठंड करने के बाद, तीन सहायक कक्षाएं बनाई जाती हैं।

1. TSymbols - मैं उसके बारे में अगले अध्याय में बात करूँगा।
2. TPEImage - इस वर्ग में ऐसे तरीके हैं जो आपको चौथे अध्याय में वर्णित पीई फ़ाइल के बारे में जानकारी प्राप्त करने की अनुमति देते हैं। केवल सुविधा के लिए बनाया गया।
3. TWorkset एक अन्य सहायक वर्ग है जिसका कार्य साझा मेमोरी के बारे में जानकारी प्राप्त करना है।

संक्षेप में, TWorkset फॉर्म की संरचनाओं की एक सूची संग्रहीत करता है:

  TShareInfo = record Shared: Boolean; SharedCount: Byte; end; 

इन संरचनाओं को एक शब्दकोश में संग्रहीत किया जाता है और प्रत्येक एक विशिष्ट पृष्ठ पते से जुड़ा होता है।
पैरामीटर सरल हैं:

• साझा - क्या पृष्ठ सार्वजनिक है
• SharedCount - पेज पर कितने लिंक हैं

यह डेटा निम्न तरीके से प्राप्त किया जाता है, जिसमें सब कुछ QueryWorkingSet फ़ंक्शन को कॉल करने के लिए नीचे आता है:

 procedure TWorkset.InitWorksetData(hProcess: THandle); const {$IFDEF WIN64} AddrMask = $FFFFFFFFFFFFF000; {$ELSE} AddrMask = $FFFFF000; {$ENDIF} SharedBitMask = $100; SharedCountMask = $E0; function GetSharedCount(Value: ULONG_PTR): Byte; inline; begin Result := (Value and SharedCountMask) shr 5; end; var WorksetBuff: array of ULONG_PTR; I: Integer; ShareInfo: TShareInfo; begin SetLength(WorksetBuff, $400000); while not QueryWorkingSet(hProcess, @WorksetBuff[0], Length(WorksetBuff) * SizeOf(ULONG_PTR)) do SetLength(WorksetBuff, WorksetBuff[0] * 2); for I := 0 to WorksetBuff[0] - 1 do begin ShareInfo.Shared := WorksetBuff[I] and SharedBitMask <> 0; ShareInfo.SharedCount := GetSharedCount(WorksetBuff[I]); try FData.Add(Pointer(WorksetBuff[I] and AddrMask), ShareInfo); except on E: EListError do ; else raise; end; end; end; 

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

वास्तव में, यह सिर्फ एक सूचना वर्ग है, अधिक नहीं, कम नहीं।

हालांकि, हमारे कोड पर वापस जाएं।
अगले चरण हैं:

1. GetAllRegions पहले अध्याय से कोड का एक एनालॉग है।
2. AddThreadsData दूसरे अध्याय के कोड का एक एनालॉग है।
3. AddHeapsData तीसरे अध्याय से कोड का एक एनालॉग है।
4. AddPEBData - पांचवें अध्याय से संरचना डेटा का उत्पादन।
5. AddImagesData चौथे अध्याय से कोड का एक एनालॉग है।

जैसा कि आप देख सकते हैं, मैंने आपको पहले से ही सब कुछ दिलचस्प (लगभग) बताया था :)

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

हालाँकि, यदि आप चाहें तो आप इसे कक्षा के कोड से ही देख सकते हैं।
इसके साथ काम करना काफी सरल है:

 var AMemoryMap: TMemoryMap; M: TMemoryStream; I: Integer; begin try M := TMemoryStream.Create; try //   AMemoryMap := TMemoryMap.Create; try //     AMemoryMap.InitFromProcess(GetCurrentProcessId, ''); //  , AMemoryMap.SaveToStream(M); //           finally AMemoryMap.Free; end; //     -,      M.Position := 0; //   AMemoryMap := TMemoryMap.Create; try //   AMemoryMap.LoadFromStream(M); //     AMemoryMap.Filter := fiNone; //   //       AMemoryMap.ShowEmpty := True; //    for I := 0 to AMemoryMap.Count - 1 do Writeln(NativeUInt(AMemoryMap[I].MBI.BaseAddress)); finally AMemoryMap.Free; end; finally M.Free; end; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; Readln; end. 

जैसा कि वे कहते हैं, मैंने खुद के लिए लिखा है, इसलिए, इस वर्ग के साथ काम करना नाशपाती की तरह आसान है :)

8. TSymbols - प्रतीकों के साथ काम करते हैं

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


यह बहुत सरलता से किया जाता है - सिर्फ SymGetSymFromAddr फ़ंक्शन को कॉल करना पर्याप्त है, लेकिन कई बारीकियां हैं।

आइए पहले कोड को देखें:

 function TSymbols.GetDescriptionAtAddr(Address, BaseAddress: ULONG_PTR; const ModuleName: string): string; const BuffSize = $7FF; {$IFDEF WIN64} SizeOfStruct = SizeOf(TImagehlpSymbol64); MaxNameLength = BuffSize - SizeOfStruct; var Symbol: PImagehlpSymbol64; Displacement: DWORD64; {$ELSE} SizeOfStruct = SizeOf(TImagehlpSymbol); MaxNameLength = BuffSize - SizeOfStruct; var Symbol: PImagehlpSymbol; Displacement: DWORD; {$ENDIF} begin Result := ''; if not FInited then Exit; GetMem(Symbol, BuffSize); try Symbol^.SizeOfStruct := SizeOfStruct; Symbol^.MaxNameLength := MaxNameLength; Symbol^.Size := 0; SymLoadModule(FProcess, 0, PAnsiChar(AnsiString(ModuleName)), nil, BaseAddress, 0); try if SymGetSymFromAddr(FProcess, Address, @Displacement, Symbol) then Result := string(PAnsiChar(@(Symbol^).Name[0])) + ' + 0x' + IntToHex(Displacement, 4) else begin //        SymLoadModule(FProcess, 0, PAnsiChar(AnsiString(ModuleName)), nil, BaseAddress, 0); if SymGetSymFromAddr(FProcess, Address, @Displacement, Symbol) then Result := string(PAnsiChar(@(Symbol^).Name[0])) + ' + 0x' + IntToHex(Displacement, 4); end; finally SymUnloadModule(FProcess, BaseAddress); end; finally FreeMem(Symbol); end; if Result = '' then Result := ExtractFileName(ModuleName) + ' + 0x' + IntToHex(Address - BaseAddress, 1); end; 

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

दूसरा चेतावनी यह है कि SymGetSymFromAddr फ़ंक्शन की कॉल कभी-कभी विफल हो सकती है। कारण मेरे लिए स्पष्ट नहीं है, लेकिन इंटरनेट समय-समय पर इस स्थिति का वर्णन करता है और इसे कैसे हल किया जाता है इसे SymLoadModule फ़ंक्शन को SymUnloadModule कहे बिना फिर से कॉल करना है। मुझे इस तरह के अजीब व्यवहार की समझ नहीं थी - लेकिन यह वास्तव में मदद करता है।

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

डिबगिंग के लिए यह जानकारी बहुत महत्वपूर्ण नहीं है, लेकिन यह इसे थोड़ा सरल करता है।
यहाँ, उदाहरण के लिए, एक मानक क्रोम ब्राउज़र स्ट्रीम स्टैक की तरह दिखता है (CallStack + SEH फ्रेम):


अधिक उपयोगी जानकारी जो प्रतीक प्रदान कर सकते हैं, निर्यात की गई लाइब्रेरी फ़ंक्शंस और उनके वर्तमान पतों की एक सूची है।
TSymbols वर्ग में, यह जानकारी GetExportFuncList प्रक्रिया को कॉल करके प्राप्त की जाती है और इस तरह दिखाई देती है:

 function SymEnumsymbolsCallback(SymbolName: LPSTR; SymbolAddress: ULONG_PTR; SymbolSize: ULONG; UserContext: Pointer): Bool; stdcall; var List: TStringList; begin List := UserContext; List.AddObject(string(SymbolName), Pointer(SymbolAddress)); Result := True; end; procedure TSymbols.GetExportFuncList(const ModuleName: string; BaseAddress: ULONG_PTR; Value: TStringList); begin SymLoadModule(FProcess, 0, PAnsiChar(AnsiString(ModuleName)), nil, BaseAddress, 0); try if not SymEnumerateSymbols(FProcess, BaseAddress, @SymEnumsymbolsCallback, Value) then begin SymLoadModule(FProcess, 0, PAnsiChar(AnsiString(ModuleName)), nil, BaseAddress, 0); SymEnumerateSymbols(FProcess, BaseAddress, @SymEnumsymbolsCallback, Value) end; finally SymUnloadModule(FProcess, BaseAddress); end; end; 

यह सभी SymEnumerateSymbols को कॉल करने के लिए नीचे आता है, जो कॉलबैक फ़ंक्शन के पते को पास करता है।
जब इसे कहा जाता है, तो SymbolName पैरामीटर में निर्यातित फ़ंक्शन का नाम होगा, और SymbolAddress इसका पता।

यह उपयोगकर्ता को निम्नलिखित संकेत प्रदर्शित करने के लिए पर्याप्त है:


आप इस वर्ग के कार्यान्वयन को और अधिक विस्तार से देख सकते हैं, जिसमें "मेमोरियल.सिमबोलसपास" मॉड्यूल में SymSetOptions और SymInitialize के लिए छोड़ी गई कॉल भी शामिल है।

9. ProcessMemoryMap

.
, MemoryMap :

1. EurekaLog OnAttachedFilesRequest, , Private (, , MEM_PRIVATE) , PEB. .
2. .

, MemoryMap, .


मैं इसके स्रोत कोड का वर्णन नहीं करूंगा, मैं केवल कार्यक्षमता पर थोड़ा चलूंगा।

सामने के छोर से, यह VMMap की याद दिलाता है। हालांकि, यह मूल रूप से योजनाबद्ध था, क्योंकि इस तरह के एक इंटरफ़ेस विश्लेषण के लिए सबसे सुविधाजनक है।

ऊपरी हिस्से में उनके प्रकारों के आधार पर क्षेत्रों की सामान्य जानकारी के साथ एक सूची है, यह एक फिल्टर भी है।

फिलहाल, यह निम्नलिखित कार्यक्षमता का प्रतिनिधित्व करता है:

1. निर्दिष्ट पते पर स्मृति की सामग्री देखें (Ctrl + Q)।


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


यह प्रक्रिया पैरामीटर ब्लॉक जैसा दिखेगा:


अच्छी तरह से और इतने पर। :

• PEB — Process Environment Block (32/64)
• TEB — Thread Environment Block (32/64)
• KUSER_SHARED_DATA
• PE Header (IMAGE_DOS_HEADER / IMAGE_NT_HEADER / IMAGE_FILE_HEADER / IMAGE_OPTIONAL_HEADER(32/64) / IMAGE_DATA_DIRECTORY / IMAGE_SECTION_HEADERS)
• Process Parameters (32/64)

, .

2. (Ctrl+F):


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

3. दो मेमोरी कार्ड का तुलनित्र। यह सेटिंग्स में शामिल है।

आपको दो मेमोरी कार्ड के बीच अंतर खोजने की अनुमति देता है और उन्हें पाठ के रूप में प्रदर्शित करता है।


केवल कार्डों की ही तुलना की जाती है, आंकड़ों की नहीं। यानीयदि किसी पते पर 4 बाइट्स बदल गए हैं, तो यह परिवर्तन प्रदर्शित नहीं किया जाएगा। लेकिन इस घटना में कि क्षेत्र का आकार बदल गया है, एक गुच्छा चला गया है, फ़ाइल अपलोड / डाउनलोड हो गई है, आदि। - यह सब तुलनात्मक परिणामों में प्रदर्शित होगा।
आप पहले से सहेजे गए कार्ड की वर्तमान तस्वीर और F5 हॉटकी का उपयोग करके तस्वीर को अपडेट करते समय दोनों की तुलना कर सकते हैं।

4. एक मेमोरी डंप।

डेल्फी डिबगर में भी लापता कार्यक्षमता। आपको निर्दिष्ट क्षेत्र की मेमोरी की सामग्री या निर्दिष्ट पते से डिस्क को सहेजने की अनुमति देता है।

5. विश्लेषण प्रक्रिया (लोड + ई) में भरी हुई सभी पुस्तकालयों से सभी उपलब्ध निर्यात कार्यों का आउटपुट।


साथ ही अपने नाम या पते के आधार पर किसी फ़ंक्शन की त्वरित खोज करता है।

अब तक, मेरे पास व्यक्तिगत रूप से पर्याप्त वर्तमान कार्यक्षमता है, और मैंने नया नहीं जोड़ा है, लेकिन भविष्य में यह उपयोगिता विकसित होगी।

ProcessMemoryMap एक OpenSource प्रोजेक्ट है।
इसकी नवीनतम स्थिर रिलीज हमेशा लिंक पर उपलब्ध होती है: http://rouse.drkb.ru/winapi.php#pmm2
GitHub नवीनतम कोड परिवर्तनों के साथ भंडार यहां पाया जा सकता है: https://github.com/AlexanderBagelel-ProcessMemoryMap

स्रोत कोड से सीधा लिंक : https://github.com/AlexanderBagel/ProcessMemoryMap/archive/master.zip
नवीनतम बिल्ड का सीधा लिंक: http://rouse.drkb.ru/files/processmm_bin.zip

स्व-असेंबली को वर्चुअल ट्रीव्यू संस्करण 5 और उससे अधिक के घटकों के स्थापित पैकेज की आवश्यकता होती है: http://www.soft-gems.net/ ।

असेंबली डेल्फी XE4 और "Win32 / रिलीज़" मोड में उच्चतर का उपयोग करके किया जाता है, और इस उपयोगिता का 64-बिट संस्करण स्वचालित रूप से इकट्ठा और जुड़ा होगा (एक संसाधन के रूप में)।
डेल्फी के पुराने संस्करणों के तहत, ProcessMemoryMap का परीक्षण नहीं किया गया था।

10. निष्कर्ष में

, . , , , , .

, .

TEB/PEB .. :
http://processhacker.sourceforge.net/
http://redplait.blogspot.ru/
http://www.reactos.org/ru

PE :
http://msdn.microsoft.com/en-us/magazine/ms809762.aspx

SEH:
http://msdn.microsoft.com/en-us/library/ms680657(v=VS.85).aspx
http://www.microsoft.com/msj/0197/exception/exception.aspx
http://qxov.narod.ru/articles/seh/seh.html

- .

« » .

aka « », aka «Inovet», aka «».

सौभाग्य है।