👈🏽 🚢 ✊ गार्जेंट कुंजी एमुलेटर का पता लगाने का एक आसान तरीका 🕺🏾 👔 ☔️

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

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

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

प्रक्रिया कुछ इस तरह होगी:

Via SetupDiGetClassDevsA () में हमें उपस्थित सभी उपकरणों की एक सूची मिलती है।
डिवाइस के GUID की जाँच करके डिवाइस गार्डेंट कुंजी से संबंधित है या नहीं इसकी जाँच करें। (संरक्षक के लिए, यह पैरामीटर {C29CC2E3-BC48-4B74-9043-2C6413FFA848484) है
हम पैरामीटर SPDRP_PHYSICAL_DEVICE_OBJECT_NAME के साथ SetupDiGetDeviceRegistryPropertyA () कॉल करके प्रत्येक डिवाइस का एक प्रतीकात्मक लिंक प्राप्त करते हैं।
आइए डिवाइस को खोलें ZwOpenFile () (CreateFile () दुर्भाग्य से यहां काम नहीं करेगा, क्योंकि प्रतीकात्मक लिंक के साथ काम करते समय कठिनाइयां आएंगी)।

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

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

शुरुआत के लिए, IOCTL स्थिरांक इस तरह दिखते हैं:

GetDongleQueryRecordIOCTL = $E1B20008; GetDongleQueryRecordExIOCTL = $E1B20018;

गार्जेंट चुपके I / II से कुंजियों के लिए पहला
संरक्षक चुपके III और उच्चतर के लिए दूसरा (साइन / टाइम / फ्लैश / कोड)

डिवाइस के लिए पहला अनुरोध भेजते समय, हम ड्राइवर से निम्नलिखित बफर को हमें वापस करने की उम्मीद करेंगे:

  TDongleQueryRecord = packed record dwPublicCode: DWord; // Public code byHrwVersion: Byte; //    byMaxNetRes: Byte; //    wType: WORD; //    dwID: DWord; // ID  byNProg: Byte; //   byVer: Byte; //  wSN: WORD; //   wMask: WORD; //   wGP: WORD; //   GP/  wRealNetRes: WORD; //   , .. <= byMaxNetRes dwIndex: DWord; //     end;

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

  TDongleQueryRecordEx = packed record Unknown0: array [0..341] of Byte; wMask: WORD; //   wSN: WORD; //   byVer: Byte; //  byNProg: Byte; //   dwID: DWORD; // ID  wType: WORD; //    Unknown1: array [354..355] of Byte; dwPublicCode: DWORD; Unknown2: array [360..375] of Byte; dwHrwVersion: DWORD; //   dwProgNumber: DWORD; //   Unknown3: array [384..511] of Byte; end;

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

स्थापित कुंजी के बारे में डेटा प्राप्त करने के लिए सामान्य कोड इस तरह दिखता है:

 procedure TEnumDonglesEx.Update; var dwRequired: DWord; hAllDevices: H_DEV; dwInfo: DWORD; Data: SP_DEVINFO_DATA; Buff: array [0 .. 99] of AnsiChar; hDeviceHandle: THandle; US: UNICODE_STRING; OA: OBJECT_ATTRIBUTES; IO: IO_STATUS_BLOCK; NTSTAT, dwReturn: DWORD; DongleQueryRecord: TDongleQueryRecord; DongleQueryRecordEx: TDongleQueryRecordEx; begin SetLength(FDongles, 0); DWord(hAllDevices) := INVALID_HANDLE_VALUE; try if not InitSetupAPI then Exit; UpdateUSBDevices; hAllDevices := SetupDiGetClassDevsA(nil, nil, 0, DIGCF_PRESENT or DIGCF_ALLCLASSES); if DWord(hAllDevices) <> INVALID_HANDLE_VALUE then begin FillChar(Data, Sizeof(SP_DEVINFO_DATA), 0); Data.cbSize := Sizeof(SP_DEVINFO_DATA); dwInfo := 0; while SetupDiEnumDeviceInfo(hAllDevices, dwInfo, Data) do begin dwRequired := 0; FillChar(Buff[0], 100, #0); if SetupDiGetDeviceRegistryPropertyA(hAllDevices, @Data, SPDRP_PHYSICAL_DEVICE_OBJECT_NAME, nil, @Buff[0], 100, @dwRequired) then if CompareGuid(Data.ClassGuid, GrdGUID) then begin RtlInitUnicodeString(@US, StringToOleStr(string(Buff))); FillChar(OA, Sizeof(OBJECT_ATTRIBUTES), #0); OA.Length := Sizeof(OBJECT_ATTRIBUTES); OA.ObjectName := @US; OA.Attributes := OBJ_CASE_INSENSITIVE; NTSTAT := ZwOpenFile(@hDeviceHandle, 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 if DeviceIoControl(hDeviceHandle, GetDongleQueryRecordIOCTL, nil, 0, @DongleQueryRecord, SizeOf(TDongleQueryRecord), dwReturn, nil) and (DongleQueryRecord.dwID <> 0) then begin SetLength(FDongles, Count + 1); FDongles[Count - 1].Data := DongleQueryRecord; FDongles[Count - 1].PnPParentPath := GetPnP_ParentPath(Data.DevInst); Inc(dwInfo); Continue; end; Move(FlashBuffer[0], DongleQueryRecordEx.Unknown0[0], 512); if DeviceIoControl(hDeviceHandle, GetDongleQueryRecordExIOCTL, @DongleQueryRecordEx.Unknown0[0], SizeOf(TDongleQueryRecordEx), @DongleQueryRecordEx.Unknown0[0], SizeOf(TDongleQueryRecordEx), dwReturn, nil) then begin DongleQueryRecordEx.wMask := htons(DongleQueryRecordEx.wMask); DongleQueryRecordEx.wSN := htons(DongleQueryRecordEx.wSN); DongleQueryRecordEx.dwID := htonl(DongleQueryRecordEx.dwID); DongleQueryRecordEx.dwPublicCode := htonl(DongleQueryRecordEx.dwPublicCode); DongleQueryRecordEx.wType := htons(DongleQueryRecordEx.wType); SetLength(FDongles, Count + 1); ZeroMemory(@DongleQueryRecord, SizeOf(DongleQueryRecord)); DongleQueryRecord.dwPublicCode := DongleQueryRecordEx.dwPublicCode; DongleQueryRecord.dwID := DongleQueryRecordEx.dwID; DongleQueryRecord.byNProg := DongleQueryRecordEx.byNProg; DongleQueryRecord.byVer := DongleQueryRecordEx.byVer; DongleQueryRecord.wSN := DongleQueryRecordEx.wSN; DongleQueryRecord.wMask := DongleQueryRecordEx.wMask; DongleQueryRecord.wType := DongleQueryRecordEx.wType; FDongles[Count - 1].Data := DongleQueryRecord; FDongles[Count - 1].PnPParentPath := GetPnP_ParentPath(Data.DevInst); end; finally ZwClose(hDeviceHandle); end; end; Inc(dwInfo); end; end; finally if DWord(hAllDevices) <> INVALID_HANDLE_VALUE then SetupDiDestroyDeviceInfoList(hAllDevices); end; end;

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

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

लेकिन चलो विचलित न हों, आपने संभवतः उपरोक्त प्रक्रिया में GetPnP_ParentPath () फ़ंक्शन को कॉल किया। यह फ़ंक्शन डिवाइस को रूट से पूर्ण पथ देता है। इसका कार्यान्वयन निम्नानुसार है:

  function GetPnP_ParentPath(Value: DWORD): string; var hParent: DWORD; Buffer: array [0..1023] of AnsiChar; Len: ULONG; S: string; begin Result := ''; if CM_Get_Parent(hParent, Value, 0) = 0 then begin Len := Length(Buffer); CM_Get_DevNode_Registry_PropertyA(hParent, 15, nil, @Buffer[0], @Len, 0); S := string(PAnsiChar(@Buffer[0])); while CM_Get_Parent(hParent, hParent, 0) = 0 do begin Len := Length(Buffer); CM_Get_DevNode_Registry_PropertyA(hParent, 15, nil, @Buffer[0], @Len, 0); S := string(PAnsiChar(@Buffer[0])); Result := S + '#' + Result; end; end; if Result = '' then Result := ' '; end;

वास्तव में (आप हँसेंगे) इस रेखा के आधार पर एमुलेटर का पता लगाया जाएगा।
आमतौर पर, डिवाइस पथ निम्नानुसार है:

\ डिवाइस \ 00000004 # \ डिवाइस \ 00000004 # \ डिवाइस \ 00000044 # \ डिवाइस \ 00000049 # \ डिवाइस \ NTPNP_PCI0005 # \ डिवाइस \ USBPDO-3 #

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

\ डिवाइस \ 00000040 # \ डिवाइस \ 00000040

तदनुसार, इस जानकारी के आधार पर, आप एक साधारण फ़ंक्शन लागू कर सकते हैं:

  function IsDonglePresent(const Value: string): Boolean; begin Result := Pos('NTPNP_PCI', Value) > 0; if not Result then Result := Pos('USBPDO', Value) > 0; end;

खैर, निष्कर्ष में, मैं कुछ और बारीकियों का वर्णन करूंगा जो कि आलेख से जुड़े डेमो उदाहरण में देखे जा सकते हैं:

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

एक छोटी सी बारीकियों:
लेख में वर्णित विधि झूठी / सकारात्मक प्रतिक्रिया देगी जब उपयोगकर्ता आपके एनीवेयर प्लेटफ़ॉर्म उत्पाद का उपयोग करता है: http://www.digi.com/products/usb/anywhereusb#overview

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

गार्जेंट कुंजी एमुलेटर का पता लगाने का एक आसान तरीका

More articles: