डिबगर से एप्लिकेशन का मुख्य धागा डिस्कनेक्ट करना और CreateFile () पर कब्जा करने से बचना

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

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

कुख्यात मार्क रोसिनोविच और ब्रूस कॉगस्वेल के लेखकत्व के लिए, आप प्रक्रिया मॉनिटर उपयोगिता को ले कर और भी आसान कर सकते हैं।

यह उपयोगिता, पूरी तरह से शांति से पूर्ण कॉल स्टैक को दिखाती है, जिसमें हमारे लिए ब्याज के रिटर्न पते भी शामिल हैं।



हमारे लिए जो कुछ भी रहता है वह डीबगर शुरू करना है और बीपी को वांछित पते पर सेट करना है।



सच है, यह उपयोगिता पहले से ही वापसी पता दिखाती है, न कि सीधे फ़ंक्शन कॉल का पता। लेकिन उस पर और बाद में।

कल्पना करें कि हमारे आवेदन का शरीर पहले ही बदल दिया गया है। अनुप्रयोग चेकसम सत्यापन को दरकिनार करने का सबसे सरल समाधान है कि बिना बनाए गए एप्लिकेशन निकाय के पथ के साथ कैप्चर किए गए CreateFile () फ़ंक्शन में lpFileName पैरामीटर को प्रतिस्थापित किया जाए। इस ऑपरेशन के बाद, आपको चेकसम गणना तंत्र का अध्ययन करने की आवश्यकता नहीं है, यह मायने नहीं रखता कि वहां क्या लागू किया गया है, डिजिटल हस्ताक्षर सत्यापन, एमडी 5 हैश या तुच्छ CRC32। क्योंकि यह एल्गोरिथ्म मूल एप्लिकेशन के शरीर के साथ काम करेगा - सभी चेक सफलतापूर्वक पारित हो जाएंगे।

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

CreateFile () के लिए वर्कअराउंड में से एक कर्नेल32-> कर्नेलबेस-> ntdll को दरकिनार करके सीधे कर्नेल फ़ंक्शन को कॉल करना है। इस तरह के कॉल का परिणाम तस्वीर में देखा जा सकता है:



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

इस एल्गोरिथ्म को लागू करने के लिए, आइए जानें कि जब आप इस कोड को कहते हैं तो क्या होता है (delphi7 + Windows 7 32bit):

hFile := CreateFile(PChar(ParamStr(0)), GENERIC_READ, FILE_SHARE_READ or FILE_SHARE_WRITE, nil, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0); 

1. आयात तालिका पर जाएं
2. कर्नेल 32.dll लाइब्रेरी के CreateFileA () फ़ंक्शन पर नियंत्रण का स्थानांतरण
3. नियंत्रण का स्थानांतरण CreateFileW () फ़ंक्शन के लिए kernel32.dll लाइब्रेरी
4. नियंत्रण का स्थानांतरण CreateFileW () कर्नेलबेस लाइब्रेरी में करें
5. ntdll.dll लाइब्रेरी के ZwCreateFile () फ़ंक्शन पर नियंत्रण का स्थानांतरण
6. कर्नेल पर नियंत्रण का स्थानांतरण

हम पहले पांच बिंदुओं से दूर होना चाहते हैं और सीधे बिंदु संख्या 6 पर अमल करना चाहते हैं।
इसके लिए, ntdll.dll लाइब्रेरी में ZwCreateFile फ़ंक्शन का कार्यान्वयन, फ़ंक्शन के मापदंडों का विवरण और एक छोटा शैक्षिक कार्यक्रम हमें मदद करेगा :)

विभिन्न प्रणालियों के तहत तीसरी अंगूठी (यूजरमोड) के ZwCreateFile के कार्यान्वयन पर विचार करें।
MOV निर्देश के मशीन कोड पर ध्यान दें।

विंडोज विस्टा - 32 बिट्स (6.0.6002.18005)

 .text:77F343D4 public ZwCreateFile .text:77F343D4 ZwCreateFile proc near .text:77F343D4 B8 3C 00 00 00 mov eax, 3Ch .text:77F343D9 BA 00 03 FE 7F mov edx, 7FFE0300h .text:77F343DE FF 12 call dword ptr [edx] .text:77F343E0 C2 2C 00 retn 2Ch .text:77F343E0 ZwCreateFile endp 

विंडोज 7 - 32 बिट्स (6.1.7601.17725)

 .text:77F055C8 public ZwCreateFile .text:77F055C8 ZwCreateFile proc near .text:77F055C8 B8 42 00 00 00 mov eax, 42h .text:77F055CD BA 00 03 FE 7F mov edx, 7FFE0300h .text:77F055D2 FF 12 call dword ptr [edx] .text:77F055D4 C2 2C 00 retn 2Ch .text:77F055D4 ZwCreateFile endp 

विंडोज 8 - 32 बिट्स (6.2.8400.0)

 .text:6A21629C public ZwCreateFile .text:6A21629C ZwCreateFile proc near .text:6A21629C B8 64 01 00 00 mov eax, 164h .text:6A2162A1 E8 03 00 00 00 call sub_6A2162A9 .text:6A2162A6 C2 2C 00 retn 2Ch .text:6A2162A6 ZwCreateFile endp 

जैसा कि आप देख सकते हैं, अंतर काफी कम हैं। ध्यान देने योग्य बात यह है कि EAX रजिस्टर में एक निश्चित संख्या दर्ज की जाती है, और एक निश्चित फ़ंक्शन को कहा जाता है। इस फ़ंक्शन को KiFastSystemCall कहा जाता है और ऐसा कुछ दिखता है (OS पर निर्भर करता है):

 mov edx, esp sysenter ret 

SYSENTER के बजाय, INT 0x2E पर कॉल हो सकती है, लेकिन यह अब आवश्यक नहीं है।
64-बिट सिस्टम के तहत इस फ़ंक्शन का कार्यान्वयन थोड़ा अलग है:

विंडोज 8 - 64 बिट, 32-बिट एनडीटीएल (6.2.8400.0)

 .text:6B2BF470 public ZwCreateFile .text:6B2BF470 ZwCreateFile proc near .text:6B2BF470 B8 53 00 00 00 mov eax, 53h .text:6B2BF475 64 FF 15 C0 00 00 00 call large dword ptr fs:0C0h .text:6B2BF47C C2 2C 00 retn 2Ch .text:6B2BF47C ZwCreateFile endp 

क्योंकि हमारे पास 32-बिट कोड है, और सिस्टम 64-बिट है, एफएस गेटवे को पहले से ही यहां कहा जाता है: 0C0h, जो अंततः देशी 64-बिट फ़ंक्शन के निष्पादन के लिए गुजरता है, जो इस तरह दिखता है:

विंडोज 8 - 64 बिट, 64-बिट एनडीटीएल (6.2.8400.0)

 .text:0000000180003110 public NtOpenFile .text:0000000180003110 NtOpenFile proc near .text:0000000180003110 4C 8B D1 mov r10, rcx .text:0000000180003113 B8 31 00 00 00 mov eax, 31h .text:0000000180003118 0F 05 syscall .text:000000018000311A C3 retn .text:000000018000311A NtOpenFile endp 

लेकिन, इस बारीकियों के बावजूद, EAX रजिस्टर इस मामले में भी आरम्भिक है।

EAX में रखा गया नंबर KeServiceDescriptorTable टेबल से एक इंडेक्स है, जिसके माध्यम से कर्नेल निर्धारित करता है कि किस फ़ंक्शन को एक निश्चित समय पर कॉल करने की आवश्यकता है। ये इंडेक्स सीधे एनटीडीएलएल कोड में एम्बेडेड होते हैं, वे संस्करण से संस्करण में भिन्न होते हैं (तालिका परिवर्तन एक मामूली पैच के परिणामस्वरूप भी हो सकते हैं), इसलिए हमें यह सीखने की आवश्यकता है कि उन्हें गतिशील रूप से कैसे प्राप्त किया जाए।

निम्नलिखित समारोह हमें इसमें मदद करेंगे:

 type //  STD  TSDTIndex = ( sdtNtSetInformationThread, sdtZwOpenFile, sdtNtQueryObject, WOW64ReservedAddr); var FunctionSDTIndex: array [TSDTIndex] of DWORD = (0, 0, 0, 0); procedure InitSDTTable; const //  ,      ApiNames: array [TSDTIndex] of string = ( 'NtSetInformationThread', 'ZwOpenFile', 'NtQueryObject', '' ); const KSEG0_BASE = $80000000; MM_HIGHEST_USER_ADDRESS = $7FFEFFFF; MM_USER_PROBE_ADDRESS = $7FFF0000; MM_SYSTEM_RANGE_START = KSEG0_BASE; MustWrite = PAGE_READWRITE or PAGE_WRITECOPY or PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY; OBJ_CASE_INSENSITIVE = $00000040; FILE_SYNCHRONOUS_IO_NONALERT = $00000020; FILE_READ_DATA = 1; var pSectionAddr, dwLength: DWORD; lpBuffer: TMemoryBasicInformation; pNtHeaders: PImageNtHeaders; ExportAddr: TImageDataDirectory; ProcessExport: Boolean; ImageBase: DWORD; IED: PImageExportDirectory; I: Integer; FuntionAddr: Pointer; NamesCursor: PDWORD; OrdinalCursor: PWORD; Ordinal: DWORD; CurrentFuncName: string; SDT: TSDTIndex; begin //    ,    NTDLL pSectionAddr := GetModuleHandle('ntdll.dll'); ImageBase := 0; ExportAddr.VirtualAddress := 0; ExportAddr.Size := 0; dwLength := SizeOf(TMemoryBasicInformation); //  WOW ,     , //      sysenter //  32-     asm push eax mov eax, fs:[$c0] mov I, eax pop eax end; FunctionSDTIndex[WOW64ReservedAddr] := I; _Write(Format('WOW64Reserved: %d', [FunctionSDTIndex[WOW64ReservedAddr]])); //      while pSectionAddr < MM_USER_PROBE_ADDRESS do begin //     if VirtualQuery(Pointer(pSectionAddr), lpBuffer, dwLength) <> dwLength then RaiseLastOSError; try //     -   if (lpBuffer.State = MEM_FREE) or (lpBuffer.State = MEM_RESERVE) then Continue; //    -   if (lpBuffer.Protect and PAGE_GUARD) = PAGE_GUARD then Continue; if (lpBuffer.Protect and PAGE_NOACCESS) = PAGE_NOACCESS then Continue; _Write(Format(' : %x', [pSectionAddr])); //  -       ? if PWord(lpBuffer.BaseAddress)^ = IMAGE_DOS_SIGNATURE then begin //     pNtHeaders := Pointer(Integer(lpBuffer.BaseAddress) + PImageDosHeader(lpBuffer.BaseAddress)^._lfanew); ExportAddr.VirtualAddress := 0; ExportAddr.Size := 0; ImageBase := DWORD(lpBuffer.BaseAddress); if (pNtHeaders^.Signature = IMAGE_NT_SIGNATURE) and (pNtHeaders^.FileHeader.Machine = IMAGE_FILE_MACHINE_I386) then begin _Write(' PE .'); //   -      ExportAddr := pNtHeaders.OptionalHeader.DataDirectory[ IMAGE_DIRECTORY_ENTRY_EXPORT]; if ExportAddr.VirtualAddress <> 0 then Inc(ExportAddr.VirtualAddress, ImageBase) else ExportAddr.Size := 0; end; _Write(Format('  : %x', [ExportAddr.VirtualAddress])); _Write(Format('  : %x', [ExportAddr.Size])); end; // ,         ProcessExport := False; if ExportAddr.Size <> 0 then if ExportAddr.VirtualAddress >= DWORD(lpBuffer.BaseAddress) then ProcessExport := ExportAddr.VirtualAddress + ExportAddr.Size < DWORD(lpBuffer.BaseAddress) + lpBuffer.RegionSize; //    -   if ProcessExport then begin if (ImageBase = 0) or (ExportAddr.VirtualAddress = 0) then Exit; IED := PImageExportDirectory(ExportAddr.VirtualAddress); _Write(Format(' : %s', [string(PAnsiChar(ImageBase + IED^.Name))])); // ,     ? if LowerCase(string(PAnsiChar(ImageBase + IED^.Name))) = 'ntdll.dll' then begin _Write('  '); // ,   ,      I := 1; NamesCursor := Pointer(ImageBase + DWORD(IED^.AddressOfNames)); OrdinalCursor := Pointer(ImageBase + DWORD(IED^.AddressOfNameOrdinals)); while I < Integer(IED^.NumberOfNames) do begin //       CurrentFuncName := string(PAnsiChar(ImageBase + PDWORD(NamesCursor)^)); for SDT := sdtNtSetInformationThread to sdtNtQueryObject do if ApiNames[SDT] = CurrentFuncName then begin //       Ordinal := OrdinalCursor^ + IED^.Base; //       FuntionAddr := Pointer(ImageBase + DWORD(IED^.AddressOfFunctions)); FuntionAddr := Pointer(ImageBase + PDWORD(DWORD(FuntionAddr) + (Ordinal - 1) * 4)^); //      MOV FuntionAddr := Pointer(DWORD(FuntionAddr) + 1); //  SDT   FunctionSDTIndex[SDT] := PDWORD(FuntionAddr)^; _Write(Format('  %s - SDT  %d', [CurrentFuncName, FunctionSDTIndex[SDT]])); end; Inc(I); Inc(NamesCursor); Inc(OrdinalCursor); end; end; ImageBase := 0; end; // ,     ? if FunctionSDTIndex[sdtNtSetInformationThread] <> 0 then if FunctionSDTIndex[sdtZwOpenFile] <> 0 then if FunctionSDTIndex[sdtNtQueryObject] <> 0 then Exit; finally //    ,    . Inc(pSectionAddr, lpBuffer.RegionSize); end; end; end; 

यह फ़ंक्शन NTDLL.DLL लाइब्रेरी के लोड पते को निर्धारित करता है, इस लाइब्रेरी के एक्सपोर्ट टेबल में जाता है, हमारे द्वारा आवश्यक फ़ंक्शन के बारे में प्रविष्टियों की तलाश करता है (इस उदाहरण में, NtSetInformationThread, ZwOpenFile और NtQueryObject को माना जाता है), मेमोरी में उनके वास्तविक पते को निर्धारित करता है और आवश्यक फ़ंक्शन के एसडीटी इंडेक्स को पढ़ता है। मशीन फ़ंक्शन कोड ऊपर। परिणाम FunctionSDTIndex सरणी में रखे गए हैं।

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

 NTSTATUS ZwOpenFile( _Out_ PHANDLE FileHandle, _In_ ACCESS_MASK DesiredAccess, _In_ POBJECT_ATTRIBUTES ObjectAttributes, _Out_ PIO_STATUS_BLOCK IoStatusBlock, _In_ ULONG ShareAccess, _In_ ULONG OpenOptions ); 

स्टैक पर छह पैरामीटर रखे गए। पहले और चौथे लिंक का अनुसरण करते हैं, तीसरा सूचक। तो ठीक है, हम एक कॉल करते हैं:

  //      // ZwOpenFile // =========================================================================== _Write('  ZwOpenFile'); _Write('    '); SysCallArgument := FunctionSDTIndex[sdtZwOpenFile]; oa.Length := SizeOf(TObjectAttributes); oa.RootDirectory := 0; oa.ObjectName := @UnicodeStr; oa.Attributes := OBJ_CASE_INSENSITIVE; oa.SecurityDescriptor := nil; oa.SecurityQualityOfService := nil; UnicodeStr.Buffer := StringToOleStr('??' + ParamStr(0)); UnicodeStr.Length := Length(UnicodeStr.Buffer) * SizeOf(WideChar); UnicodeStr.MaximumLength := UnicodeStr.Length + SizeOf(WideChar); asm //    mov SAVED_EBP, ebp mov SAVED_ESP, esp //   //         push FILE_SYNCHRONOUS_IO_NONALERT // OpenOptions push FILE_SHARE_READ + FILE_SHARE_WRITE + FILE_SHARE_DELETE // ShareAccess lea eax, iosb //   OUT  IoStatusBlock push eax //    lea eax, oa // ObjectAttributes  ,   push eax //  -    push FILE_READ_DATA + SYNCHRONIZE // DesiredAccess lea eax, hFile //   OUT  FileHandle push eax //     //       , //     , //          movzx eax, IsWOW64 or eax, eax jz @32Bit //   64-  lea eax, @64bit push eax push eax mov eax, WOW64Addr push eax mov eax, SysCallArgument xor ecx, ecx lea edx, dword ptr ss:[esp+4*3] ret @64bit: add esp, 4 jmp @FINALIZE @32Bit: //   32-  (XP  ) lea eax, @FINALIZE push eax push eax movzx eax, NeedInt2E or eax, eax jnz @NT_CODE mov edx, esp mov eax, SysCallArgument sysenter @NT_CODE: //   W2K   pop eax lea edx, esp + 4 mov eax, SysCallArgument int $2E nop @FINALIZE: //   mov Status, eax //    mov ebp, SAVED_EBP mov esp, SAVED_ESP end; if Status <> 0 then hFile := 0; _Write(Format('  %x', [Status])); _Write(Format(' %d', [hFile])) 

;

दरअसल, टास्क पूरा हो चुका है।

अब बारीकियों: जैसा कि आप देख सकते हैं, कोड को तीन अलग-अलग तरीकों से बुलाया जा सकता है।

SYSENTER, INT2E और WOW64 रजिस्टर। यह विभिन्न ऑपरेटिंग सिस्टम के कार्यान्वयन की ख़ासियत और उनकी बिटनेस के कारण है। दूसरा बारीकियों EBP / ESP रजिस्टरों का संरक्षण है। कारण यह है कि 64-बिट सिस्टम के तहत फ़ंक्शन को कॉल करने के बाद, स्टैक पर संरेखण थोड़ा अलग है, इसलिए हम इसे जबरन बहाल करते हैं ताकि एप्लिकेशन को नष्ट न करें।

अन्य दो कार्यों के लिए कॉल को यहां नहीं माना जाएगा, लेकिन संक्षेप में - NtSetInformationThread डिबगर से एप्लिकेशन के मुख्य थ्रेड को डिस्कनेक्ट करता है। इसे कॉल करने के बाद, बीपी को स्थापित करने के प्रयास से त्रुटियों की एक अलग योजना बन जाएगी। उदाहरण के लिए, डेल्फी 7 इन त्रुटियों के साथ प्रतिक्रिया करता है:



उसके बाद, यह केवल प्रक्रिया को बाधित करने और पर्यावरण को पुनरारंभ करने के लिए बनी हुई है।

उदाहरण के स्रोत कोड में, यह कॉल DISABLE_HIDEFROMDEBUGGER द्वारा निष्क्रिय किया जाता है ताकि आप इसके संचालन की जाँच कर सकें, इस निर्देश की घोषणा पर टिप्पणी करें और उदाहरण का पुनर्निर्माण करें

दूसरा NtQueryObject फ़ंक्शन दिखाता है कि प्राप्त फ़ाइल हैंडल के साथ कैसे काम किया जाए (सिर्फ एक उदाहरण के रूप में)।

डेमो एप्लिकेशन का परिणाम कुछ इस तरह होगा:



यहाँ एक उदाहरण लीजिए।

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

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

लेकिन एक नवोदित सॉफ्टवेयर शोधकर्ता को डराने में मदद मिलेगी, शायद एक और अधिक उन्नत विशेषज्ञ की पहेली भी, और केवल स्रोत कोड के रूप में कार्यक्रम का वितरण पेशेवर को बचाएगा;)