Skip to content
KitploitKITPLOIT
उपकरणएक्सप्लॉइटब्लॉग
Log in
जमा करें
उपकरणएक्सप्लॉइटब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

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

फ़ीडसंपर्कगोपनीयता© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
CVE-2024-43630-POC — NtCopyFileChunk स्टैक बफर ओवरफ्लो POC | Kitploit
उपकरण/GitHubGitHub/quasarbinary/cve-2024-43630-poc
मेमोरी फोरेंसिकभेद्यता विश्लेषणशोषणरिवर्स इंजीनियरिंगबाइनरी शोषण
GitHubquasarbinary/cve-2024-43630-poc

CVE-2024-43630-POC

NtCopyFileChunk स्टैक बफर ओवरफ्लो POC

रिपॉजिटरी देखें
1191 साल पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

CVE-2024-43630-POC

इस रिपॉजिटरी में एक POC है जो निष्पादित होने पर स्टैक OOB राइट ट्रिगर करता है, जिससे सिस्टम क्रैश हो जाता है। यह भेद्यता एक अत्यंत दिलचस्प और दुर्लभ अवशेष है जो कर्नेल प्रोग्रामिंग की जटिलताओं और विशिष्टताओं को प्रदर्शित करती है, विशेष रूप से ऑब्जेक्ट प्रबंधन में। इसके अलावा, यह भेद्यता Windows 11 24h2, Windows 10 22h2/21h2 के कर्नेल को प्रभावित करती है, लेकिन Windows 11 22h2/23h2 को नहीं, जो रुचि को और बढ़ाता है।

12 नवंबर, 2024 को पैच किया गया

प्रभावित विंडोज़ संस्करण

  • Windows 11 Version 24H2
  • Windows 10 Version 22H2
  • Windows 10 Version 21H2
  • Windows Server 2025
  • Windows Server 2022, 23H2 Edition
  • Windows Server 2022
  • परीक्षण किया गया: Windows 11 24h2 (x64) ntoskrnl.exe version 10.0.26100.1742

भेद्यता अवलोकन

Windows कर्नेल सिस्कॉल फ़ंक्शन NtCopyFileChunk में एक स्टैक-आधारित बफर ओवरफ्लो भेद्यता (अधिक तकनीकी रूप से, OOB राइट) मौजूद है।

NtCopyFileChunk एक ही सिस्कॉल में दो ऑपरेशन करने की अनुमति देता है: स्रोत फ़ाइल को पढ़ना और गंतव्य फ़ाइल में लिखना।

NT_COPYFILE_DATA_BUFFER एक संरचना है जिसमें कॉपी करने के लिए आवश्यक सब कुछ शामिल होता है। कृपया ध्यान दें कि यह संरचना रिवर्स इंजीनियरिंग के माध्यम से प्राप्त की गई थी, और इसका नाम गढ़ा गया है। इसलिए, इसके बारे में सचेत रहें।

struct NT_COPYFILE_DATA_BUFFER // sizeof=0x48
{
    DWORD64 UnknownQword1;
    DWORD64 UnknownQword2;
    DWORD64 UnknownQword3;
    DWORD64 UnknownQword4;
    PIRP WriteIrp;
    PDEVICE_OBJECT HighestDeviceObject;
    PFILE_OBJECT DestFileObject;
    PFILE_OBJECT SourceFileObject;
    DWORD64 SourceOffsetQuadPart;
};

फ़ंक्शन स्यूडोकोड में कुछ इस तरह दिखता है:

// Pseudocode for the function nt!NtCopyFileChunk in win11 24h2
__int64 __fastcall NtCopyFileChunk(
	void* SourceHandle,
	void* DestHandle,
	void* UserInputHandleEvent,
	struct _IO_STATUS_BLOCK* IoStatusBlock,
	ULONG Length,
	__int64 SourceOffset,
	struct _KTHREAD** DestOffset,
	ULONG* SourceKey,
	_DWORD* DestKey,
	int Flags)
{
	[...]
	NTSTATUS Status;
	char is_alertable_io;
	DWORD64 SourceOffsetStack;
	struct _KTHREAD* DestOffsetValue;
	_OBJECT_HANDLE_INFORMATION* HandleInformation;
	NT_COPYFILE_DATA_BUFFER* DataBuffer_3;
	PVOID UserInputEventObject;
	_FILE_OBJECT* pSourceFileObject;
	PIRP WriteIrp;
	struct _KEVENT StackEvent; // [1]
	[...]

	memset(&StackEvent, 0, sizeof(StackEvent));
	DataBuffer = (NT_COPYFILE_DATA_BUFFER*)ExAllocatePool2(0x43u, Length + sizeof(NT_COPYFILE_DATA_BUFFER), 'pCoI');
	ArbDataBuffer = DataBuffer + sizeof(NT_COPYFILE_DATA_BUFFER); //point after NT_COPYFILE_DATA_BUFFER

	// Reference source file by handle
	ret = IopReferenceFileObject(SourceHandle, 1u, PreviousMode, (PVOID*)&DataBuffer_2->SourceFileObject, 0);
	if (ret < 0)
		goto RET;

	// Reference destination file by handle
	ret = ObReferenceFileObjectForWrite(
		(ULONG_PTR)DestHandle,
		PreviousMode,
		(_FILE_OBJECT*)&DataBuffer->DestFileObject,
		(_OBJECT_HANDLE_INFORMATION*)&HandleInformation);
	[...]

	//Fill ArbDataBuffer with data that we will write to the dest file
	ret = IopPopulateCopyWriteWorkerData(
		(__int64)DestFileObj,
		(__int64)IoStatusBlock,
		(__int64)ArbDataBuffer,
		Length,
		v28,
		(__int64)pSourceFileObject,
		UserInputHandleEvent_1,
		DestOffset,
		DestKey,
		SHIDWORD(HandleInformation),
		(__int64)&DataBuffer_2->WriteIrp);

	[...]


	if (DestFileObj->Flags & FO_SYNCHRONOUS_IO)
	{
    // [2]
		KeInitializeEvent(&StackEvent, SynchronizationEvent, 0);

    // [3]
		DataBuffer_3->WriteIrp->UserEvent = &StackEvent; //WriteIrp contains pointer to stack event!
		DataBuffer->WriteIrp->Flags |= IRP_MJ_WRITE;
	}
	else
	{
		//for asynchronous mode, we don't need that
		[...]
	}
	UserInputEventObject = 0;
  // [4]
	ret = ObReferenceObjectByHandle(
		UserInputHandleEvent,
		2u,
		(POBJECT_TYPE)ExEventObjectType,
		PreviousMode,
		&UserInputEventObject,
		0);
	if (ret >= 0)
	{
		//If the user has submitted the correct event, we proceed to the main logic for copying one file to another. 
		//I have omitted that section of code for simplicity.
		KeResetEvent((PRKEVENT)UserInputEventObject);
		goto NEXT_PATH_TO_READ_FILE_QUERY;
	}
RET:
	//Here it is! Free the DataBuffer structure (remember WriteIrp, which contains a pointer to the stack event).
  // [5]
	if (ArbDataBuffer)
		IopFreeCopyObjectsFromDataBuffer((__int64)ArbDataBuffer, 1);
	if (UserInputEventObject_1)
		ObfDereferenceObject(UserInputEventObject_1);
	return (unsigned int)ret;

}

[1] में, हम StackEvent देख सकते हैं, जो हमारा समस्या ऑब्जेक्ट है। [2] में, यदि गंतव्य फ़ाइल सिंक्रोनस मोड में खोली गई थी, तो कर्नेल गंतव्य फ़ाइल पर लिखने के ऑपरेशन के लिए सिंक्रोनस रूप से प्रतीक्षा करने हेतु स्टैक इवेंट का उपयोग करता है। ऐसा करने के लिए, यह उपयोगकर्ता द्वारा पारित इवेंट के बजाय स्टैक इवेंट पर IopWaitForSynchronousIoEvent (स्यूडोकोड में नहीं दिखाया गया) का उपयोग करता है। पहले, कर्नेल स्टैक इवेंट की प्रतीक्षा करता है, और उसके बाद ही उपयोगकर्ता द्वारा पारित इवेंट को अपडेट करता है। इसी प्रकार, [3] में, आप देख सकते हैं कि WriteIrp की UserEvent स्टैक इवेंट की ओर इशारा करती है। हालाँकि, क्या होगा यदि हम सही अनुरोध बनाते हैं लेकिन गलत इनपुट इवेंट पारित करते हैं? [4] में, हम देख सकते हैं कि यह इनपुट इवेंट को कैसे संदर्भित करता है, जहाँ हम एक अमान्य हैंडल (उदाहरण के लिए, मान 1) पारित कर सकते हैं। और फिर [5] में मेमोरी साफ़ की जाती है। यहीं पर सबसे दिलचस्प चीज़ घटित होती है।

आइए IopFreeCopyObjectsFromDataBuffer फ़ंक्शन का विश्लेषण करें और देखें कि irp साफ़ होने पर क्या होता है। आइए WriteIrp->UserEvent पर करीब से नज़र डालें।

void __fastcall IopFreeCopyObjectsFromDataBuffer(__int64 ArbDataBuffer, char to_clear_irp)
{
  NT_COPYFILE_DATA_BUFFER *DataBuffer;
  PFILE_OBJECT SourceFileObject;
  PIRP WriteIrp;
  PFILE_OBJECT DestFileObject;

  DataBuffer = (NT_COPYFILE_DATA_BUFFER *)(ArbDataBuffer - 0x48);
  if ( to_clear_irp )
  {
    WriteIrp = DataBuffer->WriteIrp;
    DestFileObject = DataBuffer->DestFileObject;
    if ( WriteIrp )
    {
      IopFreeIrpExtension((__int64)DataBuffer->WriteIrp, 9, 1);

      //We are moving deeper, closely monitoring UserEvent
      IopExceptionCleanupEx((ULONG_PTR)DestFileObject, WriteIrp, WriteIrp->UserEvent, 0, 0);
      return;
    }
    if ( DestFileObject )
      ObfDereferenceObjectWithTag(DataBuffer->DestFileObject, 0x746C6644u);
  }
  SourceFileObject = DataBuffer->SourceFileObject;
  if ( SourceFileObject )
    ObfDereferenceObjectWithTag(SourceFileObject, 0x746C6644u);
  ExFreePoolWithTag(DataBuffer, 0);
}
LONG_PTR __fastcall IopExceptionCleanupEx(ULONG_PTR DestFileObject, PIRP Irp, PVOID UserEvent, PVOID P, char a5)
{
  [...]
  if ( Irp )
  {
    MasterIrp = Irp->AssociatedIrp.MasterIrp;
    if ( MasterIrp )
      ExFreePoolWithTag(MasterIrp, 0);
    [...]
    IoFreeIrp(Irp);
  }
  //Oh, that's it! But how can you decrement the reference counter for a stack object that doesn't have an OBJECT_HEADER?
  //Vuln!
  if ( UserEvent )
    ObfDereferenceObject(UserEvent);
  if ( P )
    ExFreePoolWithTag(P, 0);
  [...]
}
टूल डाउनलोड करें