Re: Object Manager Namespace Viewer

A few days ago I wrote about a ten year old Delphi project. It allows one to see the Object Manager namespace of an NT system.

Meanwhile I have started working on a WTL implementation of a similar tool. I want that tool – ntobjx – to become a replacement for WinObj from Microsoft and for it to eventually surpass the functionality of WinObj.

Because it is built as a Unicode-enabled program, it can handle characters and object names that WinObj can’t.

And since WTL is lighter than – I guess – MFC (?), it is a much smaller executable than WinObj although it already contains most of its functionality. And that is with two (SHA1 and SHA2 256-bit) signatures as opposed to a single one – weighing in at 10 KiB each.

Compare the sizes (unsigned) yourselves: approx. 240 KiB for ntobjx32.exe ¹ (32-bit version) versus approx. 700 KiB for winobj.exe.

I don’t know about WinObj, but my utility runs on Windows 2000 and later and I offer a native 64-bit (x64) build, should anyone prefer that. Code-signed binaries can be found on the download page of aforementioned project page.

Another advantage of my version is that it is open source, so people can contribute patches or fork the code and roll their own version. The license under which I am releasing the binary is the MS-PL, the same license the WTL is released under. However, I am dual-licensing the code under the permissive MIT license, such that it can be reused more easily. Now I realize that this won’t keep people from creating closed-source forks, but I want to encourage people to open up their forks or contribute back directly. Due credit will be given.

Other areas of interest in future:

• Parsing NTFS drives to show them in all detail
• Showing named pipes and mailslots just like the Delphi tool does (i.e. allow to drill down from the object manager namespace into device namespaces)
• Being able to parse symbolic link objects such as \SystemRoot in such a way that the target can be pointed out as device name and trailing path (inside that device’s namespace)
• Showing window stations along with desktops, possibly including their security settings
• Showing the registry the way it is seen without the Win32 subsystem (possibly including editing functionality), possibly including a way to enable users to see how the native registry maps to the Win32 registry
• Potentially a kernel mode driver that allows to inspect properties of objects that user mode won’t let us inspect (e.g. due to access denied)
• Possibly, but that is less likely, a way to view the shell namespace

// Oliver

1. If I link it such that it statically imports ntdll.dll and msvcrt.dll, using the Vista WDK, I can further decrease the size of the resulting binaries. [↩]