-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dangerously hijack file handles to close them #6
base: development
Are you sure you want to change the base?
Conversation
It's been a while since I've shown any significant changes. This is mainly because most of this time was spent brainstorming, prototyping, restarting, etc. I decided to commit my working tree to a temporary branch for your you to take a look at while I refactor the new methods, structs, enums, extern function, and classes to sub-classes for better organization and PR-friendly commits. |
NativeMethods backend is mostly done. Still need some xml documentation and thorough testing. |
Looking good so far @BinToss ! |
Jus tabout everything has been tentavtively implemented. I'm unsure if I should modify the existing methods–add an argument to switch to file handle logic–or implement separate methods for handles. |
@BinToss Separate methods would be the way to go. Since this is quite dangerous, it would be beneficial to add warnings for the developers as well as to use it only when absolutely necessary. |
Good point. Another potential problem to how to check if any of this actually works. I'd need to build a CLI project that can catch and print any and all exceptions. Luckily, I thought of exception reporting ahead of time—each SafeHandleEx object has a collection of exceptions. Thirdly, some data queries or functions may fail if the thread or process has unsufficient privileges. One such failure will result in a handle's object type remaining unidentified. As such, the method highest in the native methods call chain can allow optionally filters out non-file and unidentified handles. EDIT: I misremembered the Filter flag. The default filter for results is "only handles whose object are confirmed to be 'File'". The other flags enable including non-file handles and handles whose object type queries failed. |
@BinToss For the problem of requiring more privileges, that should be documented in the methods. If a developer still continues to use a function without the proper privileges, the consequences are theirs to carry. E.g. Throwing exceptions in such cases would probably be the safest option. |
Ready for testing. Need a CLI project at the very least.
Ready for a CLI project to test functionality and discover unhandled exceptions. |
Started the CLI project. Only had to spend two days troubleshooting a user error in VSCode. It's a start. Even though it's an exception, I'm still relieved to see it got that far. |
I'm having trouble deciding how to inform users about something. |
@BinToss I think if the DebugMode elevation is absolutely required in order for something to work, it should be an error. If it's not required for the functionality to work properly, you could add something to the method docs for the developers to be aware of instead, but I'll leave it up to you as to what you think is best. |
… double buffer length instead of assigning returnLength
style: remove unnecessary parentheses
refactor: remove unnecessary array buffer
Wrong buffer size. Wrong offsets. Redundant operations.
Update. Major performance issues aside, simply achieving a buggy, but working dry run is nigh impossible. |
Thanks for all the hard work @BinToss . I wish I could offer some more feedback but you're surfing in a lot of uncharted waters when it comes to those Windows API's. Either way, all I can say is that it is much appreciated. |
refactor: throw exception when OpenProcess_SafeHandle fails refactor: use global::PInvoke.Win32Exception instead of built-in type refactor: remove unnecessary usings I'm sorry I didn't commit every thing separately. TODO: Dup handles if not owned by current process
Still unused, but may be useful at a later date.
refactor: split IsClosed to BREAK: IsClosed is now a tuple This is the noun usage and pronunciation of "duplicate".
refactor: open one temporary process handle per requested access right to determine which ones can be acquired refactor: try opening process handle with PROCESS_DUP_HANDLE to duplicate other process's owned handles
…th Parallel.ForEach docs: document ProcessInfo.ProcessHandle summary, value
refactor: remove redundant 'duplicate handle' block refactor: finish refactoring IsClosed references When the handle is owned by the current process, DuplicateHandle is a duplicate the the kernel-provided handle-the same as when the handle is owned by a different process. DuplicateHandle will NEVER have DUPLICATE_SOURCE_CLOSE.
I keep running into issues that can't be solved without loading a kernel-mode driver (i.e. the code-signed KProcessHacker.sys from Process Hacker 2 would work). NtQueryObject, GetFileInformationByHandleEx, and a many other functions will hang indefinitely when certain handles or handles types are passed to them. Other functions return error codes with no documented explanation for the given parameters. Additionally, our elevated process is frequently denied permission to duplicate other process's handles. Any and all handle-based queries require a duplicated handle when operating on handles not owned by the current process. Loading a kernel-mode driver–even if it's signed–may be undesirable for API callers. But it's starting to seem like the only way to solve many of the issues I'm encountering. edit: GetFileInformationByHandleEx shouldn't hang because it communicates with drivers, but I've observed it hanging anyway. |
Status: Working in theory, but untested
Todo:
Mostly based on the following projects:
Documentation referenced:
https://www.geoffchappell.com/
https://docs.microsoft.com/en-us/windows/win32/
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/_kernel/
https://docs.rs/ntapi/latest/ntapi/
I may add Microsoft/CsWin32 and/or dotnet/PInvoke for interop assistance and fewer definitions.