How to implement CompareObjectHandles function?

[YuZhouRen86]

I am one of the VxKex NEXT developers, and we need this function to allow some Win 10 programs to work normally on Win 7.

[idontyboi]

You are better off implementing CompareObjectHandles as a kernel mode driver. I am one of the One-Core-API testers.

CompareObjectHandles calls out to kernelmode and the implementation is just getting the kernel addresses of object handles, comparing if the addresses match and then returning either STATUS_NOT_SAME_OBJECT or STATUS_SUCCESS.

// ntoskrnl.exe
NTSTATUS NtCompareObjects(HANDLE FirstObjectHandle, HANDLE SecondObjectHandle)
{
    NTSTATUS Status;
    KPROCESSOR_MODE PreviousMode = KeGetCurrentThread()->PreviousMode;
    PVOID Object1;
    PVOID Object2;

    Status = ObReferenceObjectByHandle(FirstObjectHandle, 0, NULL, PreviousMode, &Object1, 0);
    if (NT_SUCCESS(Status)) {
        Status = ObReferenceObjectByHandle(SecondObjectHandle, 0, NULL, PreviousMode, &Object2, 0);
        if (NT_SUCCESS(Status)) {
            Status = Object1 != Object2 ? STATUS_NOT_SAME_OBJECT : STATUS_SUCCESS;
            ObDereferenceObject(Object2);
        }
        ObDereferenceObject(Object1);
    }
    return Status;
}

// kernelex.dll
BOOL WINAPI CompareObjectHandles(HANDLE hFirstObjectHandle, HANDLE hSecondObjectHandle) {
    // This will fail without a custom kernel or a custom kernel driver.
    NTSTATUS Result = NtCompareObjects(hFirstObjectHandle, hSecondObjectHandle);
    if (NT_SUCCESS(Result)) {
        return TRUE;
    }
    SetLastError(RtlNtStatusToDosError(Result));
    return FALSE;
}

An existing kernelmode driver is being developed for OCA to add support for APIs that can't be done without going into the kernel. What you would need to do in this kernelmode driver is to register a device that processes IOCTL requests sent by the application using NtDeviceIoControlFile, using the IRP_MJ_DEVICE_CONTROL function to process it in kernelmode.

If you don't want to go kernelmode, unfortunately the only option is to detect every object primitive type one by one and do comparison checks. You would need to do it like this:

    if (IsThread(hFirstObjectHandle))
        return IsThread(hSecondObjectHandle) && AreThreadsEqual(hFirstObjectHandle, hSecondObjectHandle);
    if (IsFile(hFirstObjectHandle))
        return IsFile(hSecondObjectHandle) && AreFilesEqual(hFirstObjectHandle, hSecondObjectHandle);
    ... <continue for every object type you want to handle.>

Not only does this require a lot of code, but it would require specific handling for every kernel handle type in existence from files to events to even DX11 device objects. So we haven't tried this method at all. On top of that, it won't support custom kernel objects registered ahead of time.

For the implementation you are seeing right now, this function is implemented solely for newer Chromium versions to work on Windows XP. The only usages of CompareObjectHandles are in GPU acceleration routines, which are usually blocklisted on almost all XP systems. The return value of TRUE was chosen because we read the chromium source code (in DXGISharedHandleManager::GetOrCreateSharedHandleState) and found out that returning TRUE results in less errors than FALSE.

[YuZhouRen86]

Thank you for the information. Vxiiduu (the author of original VxKex) partially implemented it CLICK HERE, in KexDll, which is a custom kernel mode DLL. Can we fully implement it without a driver?

[idontyboi]

There is only a single way to mostly implement NtCompareObjects, and it is not only very slow, but would get VxKex-NEXT flagged by every antivirus in the world, because it involves doing what actual malware does to achieve kernel exploits by getting kernel addresses from userspace using NtQuerySystemInformation's SystemHandleInformation class, so only use it as a last resort implementation.

This implementation works for the simple test of event handles. Not tested for anything more complex. It's pretty slow, as it involves allocating multiple megabytes of memory per call.

	ULONG returnLenght = 0;
        // TODO: do a smarter way than this
	PSYSTEM_HANDLE_INFORMATION handleTableInformation = (PSYSTEM_HANDLE_INFORMATION)HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, 2097152);
	NtQuerySystemInformation(SystemHandleInformation, handleTableInformation, 2097152, &returnLenght);
	PSYSTEM_HANDLE_TABLE_ENTRY_INFO firstHandleInfo;
	PSYSTEM_HANDLE_TABLE_ENTRY_INFO secondHandleInfo;
	
	for (int i = 0; i < handleTableInformation->NumberOfHandles; i++)
    {
        PSYSTEM_HANDLE_TABLE_ENTRY_INFO handleInfo = &handleTableInformation->Handles[i];
		if (handleInfo->UniqueProcessId == GetCurrentProcessId()) {
			if (handleInfo->HandleValue == FirstObjectHandle) {
				firstHandleInfo = handleInfo;
				if (secondHandleInfo && firstHandleInfo->Object == secondHandleInfo->Object) {
					HeapFree(GetProcessHeap(), 0, handleTableInformation);
					return 0;
				}
			}
			if (handleInfo->HandleValue == SecondObjectHandle) {
				secondHandleInfo = handleInfo;
				if (firstHandleInfo && firstHandleInfo->Object == secondHandleInfo->Object) {
					HeapFree(GetProcessHeap(), 0, handleTableInformation);
					return 0;
				}
			}
		}
    }
	
	HeapFree(GetProcessHeap(), 0, handleTableInformation);
	
    return STATUS_NOT_SAME_OBJECT;

However, One-Core-API will not use this implementation and will go through the route of a kernel driver. I know dotexe's VxKex fork plans to use a kernel driver eventually, so you should consider having an optional kernel mode component.

[Neustradamus]

Attention: dotexe1337 has stopped all.

[yatham1557]

Attention: dotexe1337 has stopped all.

he didn't, he just distribute it on his own website here
http://thrashnet.org/projects/vxkex/