EnTeHandle is an enhanced version of the original NTHandleEx from
It started out as a ‘How’d They Do That’ kinda project and exploded, as
most projects do, into what it is now.
What it does
EnTeHandle 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.
Once 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
Basic GUI Enhancements
The 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
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.
Note:handle.sys should live in the same directory as
the GUI interface just to avoid any problems. If NtHandle is installed
on the system you can just copy my version of the GUI to the same directory
The 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.
Writing 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.