EnTeHandle

EnTeHandle is an enhanced version of the original NTHandleEx from www.sysinternals.com. 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.

My Enhancements

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 trick.

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 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.
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

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.

Resources

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

Internet

Software

  • PEDasm

  • This is a command line Dis-Assembler for Free!
  • WinDasm

  • My GUI version of PEDasm. This version is a little buggy. Will put up the new version when I get a chance.
  • PEViewer

  • Yes another one of mine. It allowed me to swipe the resources from NTHandleEx.
    Even the dialog template for the search dialog.
  • WinPE

  • And another one of mine. This lets you examine PE files in various ways.

Downloads

Download source - 77 Kb
Download ntexapi.h - 9 Kb


Comments

  • EnTeHandle crashes

    Posted by zijta on 07/08/2004 09:34am

    I downloaded the source code, compiled/linked it with MS/VS-6 C++. No problem so far. However EnTeHandle crashes immediately  in WINMAIN.CPP line 39. I am running XP-SP1
    Peter

    Reply
  • Error

    Posted by Legacy on 09/20/2003 12:00am

    Originally posted by: Do Xuan Huyen

    When I run one error occur how can I over come???. (Compile is ok)

    "Error in NtQuerySymbolicLinkObject = 0xC0000023"
    (A Messagebox, title: handle)
    "Driver not load"

    My computer Win2000 pro, sp 4, Vsc++6.0, the ddk 2k, sdk latest (new) version.

    Reply
  • WinDasm

    Posted by Legacy on 09/14/2003 12:00am

    Originally posted by: Robert Booth

    I was looking for your version of PEDasm with source code your link is broken could you please mail me a zip file containing your version WinDasm with source.

    Could you also tell me what version of a windows comiler you are usings?

    WinDasm
    My GUI version of PEDasm. This version is a little buggy. Will put up the new version when I get a chance.


    Thanks Robert

    Reply
  • Question

    Posted by Legacy on 06/17/2002 12:00am

    Originally posted by: Vitaly

    Hi, it's excellent article!
    I have following question: I need to enumerate file handles of one process only (my DLL resides inside it), but it should work for Win9x and WinNT. Any ideas how to do this with Win32 API (cause I'm using Delphi and don't like the idea porting DDK header files there)

    Thanks alot.

    Reply
  • Another 'How'd They Do That' project

    Posted by Legacy on 08/22/2000 12:00am

    Originally posted by: Jacques

    Have you considered extendi this program to show some info if the handle is a open network port? Something like the common stuff as origin addreess, destination address, origin port, destination port ?
    At sysinternals the equivalent program would be tcpviewpro (tcpview does not show which process owns the connection)

    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: August 14, 2014 @ 2:00 p.m. ET / 11:00 a.m. PT Data protection has long been considered "overhead" by many organizations in the past, many chalking it up to an insurance policy or an extended warranty you may never use. The realities of today make data protection a must-have, as we live in a data driven society. The digital assets we create, share, and collaborate with others on must be managed and protected for many purposes. Check out this upcoming eSeminar and join eVault Chief Technology …

  • Intelligent N+X Redundancy, Placement Affinities, & Future Proofing in the Virtualized Data Center Virtualization brought about the ability to simplify business continuity management in IT. Workload portability and data replication capabilities mean that physical infrastructure failures no longer need impact application services, and they can rapidly be recovered even in the event of complete site failure. However, Enterprises and Service Providers face new challenges ensuring they have enough compute …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds