[Feature] Unlock files by closing their handles with P/Invoke

[BinToss]

This option can be more dangerous compared to telling a process to end and then waiting for it to end.

Personally, I prefer not closing processes that are locking a file, especially if one of them is the File Explorer desktop shell.
Instead, I typically use ProcessHacker to close the file handle.
Closing a handle held by another process is useful when that process is not responding to attempts to terminate it.

I'll be porting portions of ProcessHacker to .NET with the intention of using some of its features for other C#/.NET projects including its ability to close handles held by other processes.

I'll submit a pull request with this feature when I have a working example.

[CodeDead]

Hi @BinToss ,

Closing a handle is indeed dangerous and can cause undefined behaviour in exterior processes. The reason why this was never implemented in DeadLock is because of how dangerous this can be.

If you do decide to close a handle, you can do so using the CloseHandle API provided by Microsoft:
https://docs.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-closehandle

However, do note that this can cause serious problems and in case of elevated processes such as drivers, it can cause blue screens of death.

Killing a process is safer because you need elevated rights to kill certain processes that are essential to your system.

Closing the handle could be used as a final resort, of sorts, if killing a process was unsuccessful, but only if the holder of the handle is not absolutely required by the system.

This feature being added to the deadlock SDK is still a good idea, but if you can, it's best to separate the methods that kill the processes versus the methods that will close the handle in addition to the methods that kill handles having a code doc warning slapped on them so that the users are aware of the dangers.

Thanks for your continued contributions and innovations!

[BinToss]

Small update: I've spent nearly every day peeling apart ProcessHacker to learn how it retrieves a list of handles from every process. I've either not found all the code necessary for this functionality or I've overlooked it.

After a few days, I'd begun to search for it from ./ProcessHacker/findobj.c.

A cursory glance tells me that a kernel-level driver (e.g. KProcessHacker) would greatly assist in handle collection.

[CodeDead]

@BinToss NtQuerySystemInformation should be able to list ALL handles.

typedef struct _SYSTEM_HANDLE
{
    DWORD    dwProcessId;
    BYTE     bObjectType;
    BYTE     bFlags;
    WORD     wValue;
    PVOID    pAddress;
    DWORD    GrantedAccess;
}
SYSTEM_HANDLE;

ProcessHacker has its own implementation:
https://github.com/processhacker/processhacker/blob/master/ProcessHacker/hndlprv.c

[CodeDead]

@BinToss It's an undocumented feature of NtQuerySystemInformation. I forgot to mention that, apologies. You can find the information about it here:
https://blog.katastros.com/a?ID=01600-1528e951-c96a-492d-8269-54c6a4a5646a

typedef struct _SYSTEM_HANDLE_INFORMATION_EX
{
    ULONG NumberOfHandles;
    SYSTEM_HANDLE_INFORMATION Information[655360];//Note that the value of 655360 is defined by myself, you can define other constant values ​​yourself
}SYSTEM_HANDLE_INFORMATION_EX, *PSYSTEM_HANDLE_INFORMATION_EX;

typedef struct _SYSTEM_HANDLE_INFORMATION
{
    ULONG ProcessId;//Process identifier 
    UCHAR ObjectTypeNumber;//The type of object opened
    UCHAR Flags;//Handle attribute flags
    USHORT Handle;//Handle value, which uniquely identifies a handle among the handles opened by the process
    PVOID Object;//This is the address of the EPROCESS corresponding to the handle
    ACCESS_MASK GrantedAccess;//Access permissions of the handle object
}SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION;

Hope this helps, it should be possible to get the handles with this function and close them with the CloseHandle function:
https://docs.microsoft.com/en-us/windows/win32/api/handleapi/nf-handleapi-closehandle

[BinToss]

Ah, I figured that out eventually. I found some unofficial documentation of that and similar kernel symbols that Microsoft had accidentally exposed.
https://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/ex/sysinfo/handle_ex.htm
https://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/ex/sysinfo/handle_table_entry_ex.htm
https://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/ex/sysinfo/class.htm
https://www.geoffchappell.com/studies/windows/km/ntoskrnl/api/ex/sysinfo/query.htm
I'm working on structs to wrap their primitive parameters.

[BinToss]

My current issue is filtering handles by their object type.
ProcessHacker wraps handle objects and passes the wrappers' pointers around which has been a major impedance.

[BinToss]

Found a way to identify the Type of a Handle's object.
scroll down to the table
https://docs.microsoft.com/en-us/windows/win32/sysinfo/kernel-objects

This is the function I'm using to check a handle's object's type
https://docs.microsoft.com/en-us/windows/win32/api/winternl/nf-winternl-ntqueryobject

Now, I'm finalizing details for two wrapper classes. The File-specific of the two will be what's returned in a List.
Getting a process's command line from its mutable PEB is tedious and unreliable, but it's better than nothing.

I'd also like to make service and task host processes supply the names of their respective services and tasks, but that might be even more complicated, so I'll leave that to whoever really wants that feature.

[BinToss]

It's been mostly done since Spring. I needed a long break after discovering the limitations of what this can do without requiring all users to install a kernel-mode driver.
There's very little it can't do without the driver, but knowing that I couldn't reach my original goal was a blow to my motivation to finish it.
When complete, API users will be given warnings (and/or have access to a list of exceptions) when collected handle information is limited by a lack of token elevation (didn't run as admin) or due to a handle being owned by a protected process e.g.

Name (Service Name(s))	Protection Level (Type)
System	Full (WinSystem)
Secure System	Full (WinSystem)
Registry	Full (WinSystem)
smss.exe	Light (WinTcb)
Memory Compression	Full (WinSystem)
csrss.exe	Light (WinTcb)
wininit.exe	Light (WinTcb)
services.exe	Light (WinTcb)
svchost.exe (WaaSMedicSvc)	Light (Windows)
MsMpEng.exe (WinDefend)	Light (Antimalware)
NisSrv.exe (WdNisSrv)	Light (Antimalware)
SecurityHealthService.exe (SecurityHealthService)	Light (Windows)
svchost.exe (wscsvc)	Light (Windows)
svchost.exe (DoSvc)	Light (Windows)
svchost.exe (AppXSvc)	Light (Windows)
lsass.exe (EFS, KeyIso, SamSs, VaultSvc)	Light (Lsa)
csrss.exe	Light (WinTcb)