Let me explain why.
For last 2 weeks, I have been working on a Get-Handles code which spits out the handles, base address, handle type. I even wrote a blog post and didn’t publish it , something like Mitt Romney’s transition website :). (I am usually too excited to blog after finishing the code and usually skip going into details.)
But for some reason, I was missing a parameters, or a particular flag or something in my P/Invoke calls. The last iteration from today spit out a Process Access Violation error. It’s frustrating to say the least.
Matt’s code is a big deal.
Right now we have a way to access Windows native functions from Powershell and do stuff. It’s a nice little wrapper code probably a first-step in replacing Sysinternals set of tools.
Every Admin/Dev/DevOps guy in Windows world uses SysInternals tools. They are small, and they expose the inner-workings of your application.
– There is no source code. There used to be at one point in time. (Fortunately there is an open source project by WJ32 with source code – ProcessHacker)
– You cannot package any of SysInternal tools with your code. That’s a license violation.
– Sysinternal tools works great on the console but they suck if you are trying to get these values remotely. The amount of plumbing required to do this remotely is just not worth it.
There are lots of handles.C code floating around in the intertubes. There is a bunch of C# code also. But, this is probably the first time someone did this in Powershell.
Now that you can call NTSTATUS and NTQSI from Powershell, I am hoping someone can write a Powershell wrapper and produce these:
– PsMutex, PsSemaphores – to list out Mutant’s and Semaphores.
– List all processes which are not closing their handles ()
– List out contents of TEB, EPRCB.
– Maybe someday someone will write code to extract DPC/ISR’s
I call these class of problems as “Alerting Code“, meaning, by executing GetHandles remotely you are setting up an alert for your monitors to investigate further. This goes deeper than just investigating the PerfMon spikes and checking eventlogs, and gives a view of things at OS Level – not your fluffy managed code level accessible via Powershell using [System.Whatever..]
Alerting Code doesnt necessitate starting a Windbg session.
Typically, you would want to setup alerts form your alerting code, and depending on the results, you may initiate a remote WinDBG / OllyDBG session to the target machine. You can automate this and intercept viruses, badly coded runaway programs, and hopefully someday solve the classic Windows problem of “My Computer is So Slowwwww”.
In case you cannot initiate a WinDbg session, then these tiny little Powershell wrapper code comes in handy.
I can do all of that now without Powershell, but I am resorted to using SysInternals tools and I have to physically on the console of the target machine to do this.
If I have a bunch of Powershell modules which sets-up alerts that’s the first-loop in Systems Automation right there.
I understand that most of the values returned may not have the ntdll!Ke – functions. You would need the Symbol table for that.
Nicholas Dorier did a Symbol table lookup in nHook.
WJ32 did something smarter in his famed ProcessHacker; he wrote a lookup table for Symbols:)
So, there is a scope for improvement and I hope others join-in
Overall I am really happy that Matt wrote this and that it works flawlessly.
PS: If you think this post makes sense, please join us for Windows Internals Study Group and code with us :). We do a Google Hangout every Wednesday 8:30pm – 11:30pm (EST). All artifacts open sourced.