FindZombieHandles cannot find any zombies when PIDs grow too large
Closed this issue · 7 comments
When PIDs grow over 2^16 - 1 (65535), zombies.Count
is almost always 0.
NtApiDotNet's SystemHandleTableInfoEntry
stores UniqueProcessId
as a ushort
. As a UInt16
, obviously it'll wrap on >= 2^16.
This is possibly more of a bug in NtApiDotNet, but I don't know the NT API well enough to be sure.
More specifically, it's on
blogstuff/FindZombieHandles/Program.cs
Line 51 in 0e55d94
NtSystemInfo.GetHandles
call filtering on NtProcess.Current.ProcessId
will never find any results if NtProcess.Current.ProcessId
is bigger than a UInt16
.
Funnily enough, this makes FindZombieHandles unusable on the worse leaks that force PIDs to grow very quickly.
Looks like NtApiDotNet should instead be using the extended struct that can return a larger PID: https://forum.sysinternals.com/discussion-howto-enumerate-handles_topic19403_page9.html
I'm now also wondering if the handle_info
buffer is large enough.
I'll see if I can find a bugtracker for NtApiDotNet...
I'll fix it in the next release.
So here's an odd problem. The process handle leak is fixed on my workstations which means that I can no longer easily generate PIDs above 65536. Can the creator of this issue test to see whether the new version fixes it? If so then I can check in a new binary.
Unfortunately, I won't be back at the machine with the original leak until next week. But I think I've recreated the leak here, and I've successfully tested the updated version past 100k zombies (PIDs through 700k). It seems to work.
Thanks!
P.S. if anyone feels the strange urge to resurrect the dead, source is here: https://gist.github.com/BobVul/15a12661630310bcd4b4d824ea0e4658
P.P.S. If anyone happens to see this and is using CreateProcess
, please remember to close your hThread and hProcess handles! *looks at a certain daemon*
Ok, confirmed working on the original machine with the original leaker.
Thanks for the bug report and the fix. I hadn't quite realized that this caused FindZombieHandles to completely fail when PIDs over 65535 were encountered, making this a particularly important fix. New binaries added.