What it doesEnTeHandle allows you to see all the open handles a process currently has open. Handles being, files, events, mutexes etc. In addition, you can also view the dlls currently used by the process, thread information, process memory and even a dynamic update.There is also a dll and handle search. The search allows you to see for example all the processes that have a perticular file handle open.
How it works!It took about a month of reading the dis-assemblies of both the original GUI and the associated driver handle.sys. At first I thought the driver was the major component but as it turned out the GUI was more interesting.
The driver takes a parameter of the handle address in memory of the object and returns the name associated with the handle. Since this information is stored in kernel space it is only available to a kernel mode driver.
The GUI interface to the driver uses a few undocumented calls into NTDLL.DLL to obtain most of the information it displays. The NtQuerySystemInformation call is used to obtain a list of all the open handles and a list of all the processes currently running on the system. Each entry in the handle list contains the PID associated with that handle. The process list is first displayed in the top listview. When a process is clicked the PID is used to search the handle table for all entries that have a matching PID. The Handle address for that handle is then passed to the driver. If a name exists for the handle it is returned to the GUI which displays it in the bottom listview.
The DLL's associated with each process are obtained via the RtlQueryDebugInformation call in NTDLL.DLL. This function returns a list of modules loaded by the process in question. The gotcha here is that the CALLING process must have the SeDebug privelege set before the call will work.
My EnhancementsOnce I figured out how all this worked writing a new GUI interface to the driver was easy. OK, somewhat easy. I started out by providing the same functionality as the real NtHandleEx. The hardest part about this was since the calls to NTDLL.DLL are undocumented so is the data returned. So... I posted a few questions on the NTKernel usenet group and some very kind person sent me an old MS internal header file called NTEXAPI.H. This header contained the function prototypes and structure typdefs to most of what I needed. The rest was figured out by using some of the other tools supplied with NT. i.e. PVIEW, PSTAT, and TASKMAN. Using this data and a little test program under the debugger did the trick.
Basic GUI EnhancementsThe user can now double click on a handle name OR a dll name and have the search run without having to key in anything.
The thread display was created when I figured out that each process entry in the pidlist contained an array of all the threads in that process. The data displayed is contained in each thread record.
The process detail display and the process list are fields contained in the each process entry. The hardest part about the thread and process info was converting the time stamps.
Added a refresh button on the tool bar along with a dynamic update of 5 seconds.
A context menu was added to the process list. It provides all the same options available from the View menu along with a process terminate option. I know it works since while testing I accidently canceled the Win32 subsystem and crashed my machine. I then added an "Are you sure Y/N" box then backed up all my code to CDROM. Driver Interface. This took a little digging in the sense that when NtHandleEx fires up it registers the driver in the registry as a service but doesn't clean up the entry when its finished. The GUI had to be able to handle 2 different situations when starting up.
- 1) Is the original driver already registered if so then use it.
- 2) if the driver is not registered then dynamically load the copy contained in the same directory as the GUI. This was needed so that my version of the GUI could coexist when NtHandle was on the system but in another directory.
The AppThe app was written in MFC using MS/VC++ 5.0. It's a SDI app with static splitter windows that are dynamically switched depending on the requested view.
A DeviceDriver class was written to handle the loading and unloading of the driver. This is done in the CWinapp.
The CDocument class handles the loading and refreshloading of the tables returned from the NT calls. It also handles dynamically loading the functions from NTDLL. I did it this way so that the DDK would not be required to build the app. The document is smart enough to load the functions only once even if we do a refresh.
Each View is a CListView control using the LVS_REPORT and LVS_SHOWSELALWAYS style. a static CSplitterWnd is used for an upper and lower view. The Lower view is changed dynamically depending on the view option selected.
ResourcesWriting this kind of stuff requires a lot of resources!
Books & Periodicals
- Inside Windows NT second edition
- Microsoft Systems Journal. the March 1998 issue
- Windows NT magazine. 'Inside NT's Object Manager'
- Windows Developer Journal. 'Using NT's Undocumented Object Manager Interface'
- Programming Windows 95 w/ MFC
- Windows NT Device Driver Developement
- The Windows NT Device Driver Book
- NT System Software Resources
Home of the original NtHandle and many other cool things
The absolute best place for MFC tips and tricks
Give unto Ceasar....
The Debug Monitor was a big help in hacking.
This is a command line Dis-Assembler for Free!
My GUI version of PEDasm. This version is a little buggy. Will put up the new version when I get a chance.
Yes another one of mine. It allowed me to swipe the resources from NTHandleEx.
Even the dialog template for the search dialog.
And another one of mine. This lets you examine PE files in various ways.
DownloadsDownload source - 77 Kb
Download ntexapi.h - 9 Kb