hfiref0x / winobjex64

Windows Object Explorer 64-bit

WinObjEx64

Windows Object Explorer 64-bit

WinObjEx64 is an advanced utility that lets you explore the Windows Object Manager namespace. For certain object types, you can double-click on it or use the "Properties..." toolbar button to get more information, such as description, attributes, resource usage etc. WinObjEx64 let you view and edit object-related security information if you have required access rights.

System Requirements

WinObjEx64 does not require administrative privileges. However administrative privilege is required to view much of the namespace and to edit object-related security information.

WinObjEx64 works only on the following x64 Windows: Windows 7, Windows 8, Windows 8.1 and Windows 10/11, including Server variants.

Features

View list

• Explore all of Windows Object Manager namespace

  • Hierarchical objects tree

  • Symbolic links resolving

  • Version information for Section type objects that are backed by an image file

  • Additional information for WindowStation type objects

  • View objects details

    • Descriptions
    • Flags
    • Invalid attributes
    • Memory pool type
    • Object type specific information
    • Object-related structure memory dumps¹
      • ALPC_PORT
      • CALLBACK_OBJECT
      • DEVICE_OBJECT
      • DRIVER_OBJECT
      • DIRECTORY_OBJECT
      • FLT_SERVER_PORT_OBJECT
      • KEVENT
      • KMUTANT
      • KSEMAPHORE
      • KTIMER
      • KQUEUE (IoCompletion)
      • OBJECT_SYMBOLIC_LINK
      • OBJECT_TYPE
    • Opened handles
    • Statistics
    • Supported access rights
    • Process Trust label
    • And more...

  • Display in dump sub-structures such as¹:

    • ALPC_PORT_ATTRIBUTES
    • DEVICE_MAP
    • LDR_DATA_TABLE_ENTRY
    • OBJECT_TYPE_INITIALIZER
    • UNICODE_STRING
    • and many others

  • Edit object-related security information²

  • Detect driver object IRP modifications (as part of structure dump)¹

  • Detect kernel object hooking (as part of structure dump)¹

  • Search for objects by name and/or type

• System information viewer

  • Boot state and type
  • Code Integrity options
  • Mitigation flags
  • Windows version and build

• Loaded drivers list viewer

  • Ability to dump selected driver¹
  • Export driver list to file in CSV format
  • Jump to driver file location
  • Recognize Kernel Shim Engine "shimmed" drivers¹
  • View driver file properties

• Mailslots/Named pipes viewer

  • Display list of all registered mailslots/named pipes
  • Named pipes security information editor⁴
  • Object statistics

• Hierarchical process tree viewer²

  • Show process id, user name, EPROCESS addresses
  • Highlight processes by type similar to default Process Explorer highlighting
  • Show thread list for selected process
  • Show ETHREAD addresses
  • Show common properties for Process/Thread objects
    • Basic properties as for any other object type
    • Start time
    • Process type
    • Image file name
    • Command line
    • Current directory
    • Applied mitigation's
    • Protection
    • State of "Critical Process" flag
    • Security edit
  • Jump to process file location
  • Process/Thread token information
    • User name
    • User SID
    • AppContainer SID
    • Session
    • UIAccess
    • Elevation state
    • Integrity level
    • Privileges and groups
  • Show additional token properties for Process/Thread
    • Basic properties as for any other object type
    • List of security attributes
    • Security edit

• Software Licensing Cache viewer

  • Display list of registered licenses
  • Display license data
  • Dump license data of type SL_DATA_BINARY to file

• User Shared Data viewer

  • Display structured dump of most important parts of KUSER_SHARED_DATA

• System callbacks viewer¹

  • Display address, module and callback specific information for callbacks registered with:
    • PsSetCreateProcessNotifyRoutine
    • PsSetCreateProcessNotifyRoutineEx
    • PsSetCreateProcessNotifyRoutineEx2
    • PsSetCreateThreadNotifyRoutine
    • PsSetCreateThreadNotifyRoutineEx
    • PsSetLoadImageNotifyRoutine
    • PsSetLoadImageNotifyRoutineEx
    • KeRegisterBugCheckCallback
    • KeRegisterBugCheckReasonCallback
    • CmRegisterCallback
    • CmRegisterCallbackEx
    • IoRegisterShutdownNotification
    • IoRegisterLastChanceShutdownNotification
    • PoRegisterPowerSettingCallback
    • SeRegisterLogonSessionTerminatedRoutine
    • SeRegisterLogonSessionTerminatedRoutineEx
    • IoRegisterFsRegistrationChange
    • IopFsListsCallbacks
    • ObRegisterCallbacks
    • DbgSetDebugPrintCallback
    • DbgkLkmdRegisterCallback
    • PsRegisterAltSystemCallHandler
    • CodeIntegrity SeCiCallbacks
    • ExRegisterExtension
    • PoRegisterCoalescingCallback
    • PsRegisterPicoProvider
    • KeRegisterNmiCallback
    • PsRegisterSiloMonitor
    • EmProviderRegister

• Windows Object Manager private namespace viewer¹

  • View basic namespace entry information
  • View boundary descriptor information
  • Show common properties for objects

• KiServiceTable viewer¹

  • Show dump of Ntoskrnl-managed KiServiceTable (sometimes referenced as SSDT)
  • Jump to service entry module
  • Export list to file in CSV format

• W32pServiceTable viewer¹

  • Show dump of Win32k-managed W32pServiceTable (sometimes referenced as Shadow SSDT)
  • Support Win32k import forwarding
  • Support Win32k ApiSets resolving
  • Jump to service entry module
  • Export list to file in CSV format

• CmControlVector viewer

  • Show dump of Ntoskrnl CmControlVector array
  • Dump value data from kernel memory to file¹
  • Export list to file in CSV format

• Most of list/trees allows to copy object address and/or name to the clipboard

• Running on Wine/Wine-Staging is supported³

• Plugins subsystem for extending basic features

  • Available plugins that shipped with WinObjEx64 release:
    • ApiSetView - viewer for Windows ApiSetSchema internals, support loading ApiSet schema from file
    • Example plugin - example plugin for developers
    • Sonar - NDIS protocols viewer, display registered NDIS protocols and dumps some information about them
    • ImageScope - context plugin allowing to view more details in WinObjEx64 for Section type objects that are backed by image file (available through popup menu on object of Section type in WinObjEx64 main list)

• Documentation

  • Windows Callbacks
  • Plugins subsystem

1. This feature require driver support enabled, see "Driver support" part below.
2. This may require administrator privileges.
3. Most of additional Windows internals-specific features however will be unavailable due to obvious reasons.
4. Some named pipes may require administrator privileges to access.

Driver support

WinObjEx64 supports two types of driver helpers:

1. Helper for read-only access to the kernel memory. Default version uses Kernel Local Debugging Driver (KLDBGDRV) from WinDbg. In order to use it (and thus enable all the above features) Windows must be booted in the debug mode (bcdedit -debug on) and WinObjEx64 must be run with administrator privileges. If you are using WinObjEx64 version with custom helper driver - Windows debug mode is not required. There are exist several drivers that can be used as helpers for WinObjEx64, by default it has only WinDbg type built-in.
2. Helper to access object handles. WinObjEx64 (any variant) support Process Explorer driver of version 1.5.2 to open process/threads. To enable this just load Process Explorer with administrator privileges simultaneously with WinObjEx64.

All driver helpers require WinObjEx64 to be run with administrative privileges.

Build

WinObjEx64 comes with full source code. In order to build from source you need Microsoft Visual Studio 2015 and later versions.

Instructions

• Select Platform ToolSet first for project in solution you want to build (Project->Properties->General):
  • v140 for Visual Studio 2015;
  • v141 for Visual Studio 2017;
  • v142 for Visual Studio 2019;
  • v143 for Visual Studio 2022.
• For v140 and above set Target Platform Version (Project->Properties->General):
  • If v140 then select 8.1;
  • If v141 and above then select 10.
• Minimum required Windows SDK version 8.1
• Recommended Windows SDK version 10.0.19041 and above

What is new

Whats New in 2.0.0

Complete changelog

Authors

(c) 2015 - 2024 WinObjEx64 Project, hfiref0x

Original WinObjEx (c) 2003 - 2005 Four-F

winobjex64's Issues

Windows 11 enhanced support tickets

20210601 Fixed in 1.9.1
MmUnloadedDrivers cannot be found using existing pattern because it is no longer unique.

21996 MiRememberUnloadedDriver

PAGE:00000001407FA273 BA D0 07 00 00                                                  mov     edx, 7D0h
PAGE:00000001407FA278 B9 40 00 00 00                                                  mov     ecx, 40h
PAGE:00000001407FA27D 41 B8 4D 6D 44 54                                               mov     r8d, 54446D4Dh
PAGE:00000001407FA283 E8 68 A0 AF FF                                                  call    MiAllocatePool
PAGE:00000001407FA288 48 89 05 09 F9 42 00                                            mov     cs:MmUnloadedDrivers, rax

Prior duplicate code MiCreatePebOrTeb

PAGE:00000001406B15A0 BA D0 07 00 00                                                  mov     edx, 7D0h
PAGE:00000001406B15A5 EB DF                                                           jmp     short loc_1406B1586

How is this related to Sysinternals WinObj?

It looks like the same app to me. Did Sysinternals copy this app originally? Or is this a copy of the Sysinternals app?

[1.9.0] Feature requests

This is combined list of feature requests, to remember.

These are requested by AIonescu. Both require kernel memory read.

1. windbg !alpc /lpc analogue for ALPC ports properties. Show list of connections to the port. Depends on ALPC_PORT (private), ALPC_COMMUNICATION_INFO (private). (ID 20210401)
2. windbg !ca analogue for section objects properties. Show list of mappings including their VA per processes. Depends on CONTROL_AREA (private). (ID 20210402)

Private requests made by URs (ID 20210405, ID 20210406, 20210509)
Private requests made by H.E. (ID 20210501, 20210502, 20210503, 20210504, 20210506, 20210507)
Private request made by RL (ID 20210505)

Cannot list IRPs for drivers

For some reason I cannot see the object tab in the driver properties for displaying the IRPs for drivers.

I already have set testsigning and local debugging enabled:

I rebooted the machine for the effects to take place, but I'm still not able to see any IRPs. What gives?

Use CMake for building

Describe the feature
Currently in order to build this one needs Visual Studio. Visual Studio is a non-free toolchain with telemetry. It'd be preferred to build it using Clang + MinGW-w64 stdlib.

In ordert o have cross-toolchain building it is preferred to set building with CMake. I have a set of toolchain files that can be helpful for cross-building from Debian machines.

Please add the possibility to change object permissions from the command line

Compile Error for x86

The code can't be compiled for x86.

in propObjectDump.c I had to add #if defined(_AMD64_)around the hint call because according to the WDM.h for Build 14939 this field is only avaiable for x64.

typedef struct _KDEVICE_QUEUE {
    CSHORT Type;
    CSHORT Size;
    LIST_ENTRY DeviceListHead;
    KSPIN_LOCK Lock;

#if defined(_AMD64_)

    union {
        BOOLEAN Busy;
        struct {
            LONG64 Reserved : 8;
            LONG64 Hint : 56;
        };
    };

#else

    BOOLEAN Busy;

#endif

} KDEVICE_QUEUE, *PKDEVICE_QUEUE, *PRKDEVICE_QUEUE;

Now I still get this error:

propSecurity.c(471): error C2440: '=': cannot convert from 'void (__cdecl *)(IObjectSecurity *,HANDLE)' to 'PCLOSEOBJECTMETHOD'

Windows Defender identifies binary as trojan

Identified as: Win32/Spallowz.A!cl

Category: Trojan

Description: This program is dangerous and executes commands from an attacker.

Recommended action: Remove this software immediately.

Items:
file:C:\ProgramData\Microsoft\Windows Defender\Scans\FilesStash\260A5552-CCD4-7324-ECB2-4F4BC7C2A253_1d1ce1b1363ccb0
file:C:\Users\Alex\Desktop\WinObjEx64.exe
webfile:C:\ProgramData\Microsoft\Windows Defender\LocalCopy{9D978906-6B4F-4B93-8A83-89B5389F0367}-260A5552-CCD4-7324-ECB2-4F4BC7C2A253_1d1ce1b1363ccb0|chrome.exe
webfile:C:\ProgramData\Microsoft\Windows Defender\Scans\FilesStash\260A5552-CCD4-7324-ECB2-4F4BC7C2A253_1d1ce1b1363ccb0|https://raw.githubusercontent.com/hfiref0x/WinObjEx64/master/Compiled/WinObjEx64.exe|chrome.exe
webfile:C:\Users\Alex\Desktop\WinObjEx64.exe|https://raw.githubusercontent.com/hfiref0x/WinObjEx64/master/Compiled/WinObjEx64.exe|chrome.exe

Get more information about this item online.

[Bug] Under certain conditions SHOpenFolderAndSelectItems fails with result CONNECT_E_CANNOTCONNECT

If WinObjEx64 is run as admin from the user account without administrative privileges and "Jump To File" function is used for the files and directories which are "protected" (e.g. windows or system32) the SHOpenFolderAndSelectItems API will fail and return CONNECT_E_CANNOTCONNECT (0x80040202) thus resulting in supJumpToFile routine do nothing. Internally SHOpenFolderAndSelectItems calls SHGetIDispatchForFolder undocumented routine from shdocvw.dll which fails with above mentioned error code and causes calling function to return that error code as well. Windows Error Log does corresponding entry for this case with source "DistributedCOM".

This behavior is not seen to be Microsoft documented. In WinObjEx64 this will be fixed with workaround in next v1.8.8 release.

ID 20201101

Add SeCiCallbacks to the callbacks viewer

See for reference
https://github.com/swwwolf/wdbgark/blob/master/src/secicallbacks.cpp.

Assume support from 7 up to 10 19H1.

Callbacks array structure:

• Windows 7 (7600, 7601)
  • fixed size pointer array with 3 elements
• Windows 8, Windows 8.1 (9200, 9600)
  • first element (QWORD) is the size in bytes of pointers array following next
• Windows 10 (10240, 10586, 14393, 15063, 16299, 17134, 17763, 18317)
  • first element (QWORD) is the size in bytes of pointers array following next, starting from RS1 (14393) contain revision marker (QWORD) at the end of this array which looks like 0xX00000Y where X is A (10) and Y is changing between Windows 10 version, for example in RS1(14393) this value is two in 19H1(18317) this value is six.

Callbacks names can be recovered from symbols. Since size of this array depends on Windows version as well as position of elements in this array it is better to hardcode these names.

[Bug] SCM processes improperly identified in the process list

Due to incorrect SCM API result parsing SCM processes are not correctly identified and thus not (all) appropriately marked in the Extras->Process list dialog. This will be fixed in next v1.8.8 release.

ID 20201001

Access Denied error for pipes created with open mode PIPE_ACCESS_INBOUND

To open handle for pipe created with open mode PIPE_ACCESS_INBOUND we need specify GENERIC_WRITE | FILE_READ_ATTRIBUTES access right https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea

PR - #17

WinGet install fails without elevation

Describe the bug
WinGet install fails with error 0x80070005 : Access is denied if run from a non-elevated prompt.

To Reproduce

winget install -i WinObjEx64

Expected behavior

Screenshots

Environment
Windows 11 23H2, build 22631.3235

Run as LocalSystem is not reliable

Describe the bug
Sometimes the "Run as LocalSystem" feature fails. It occurs because supxGetSystemToken returns the first system token it finds, which might happen to be a token of a restricted service.

To Reproduce
Most frequently it happens when WinObjEx64 runs under an administrative account that does not have SeDebugPrivilege.

Screenshots
On the screenshot you can see that after supxGetSystemToken returns a restricted token and supRunAsLocalSystem impersonates it, the function silently fails because it is unable to change token's session ID without SeTcbPrivilege,

Environment
Tested it on Windows 7.

Additional context
In fact, the reason why without SeDebugPrivilege supxGetSystemToken returns a restricted token (or even no token in some cases) is that you use PROCESS_QUERY_INFORMATION instead of PROCESS_QUERY_LIMITED_INFORMATION.

WinObjEx64/Source/WinObjEx64/sup.c

Lines 3697 to 3700 in 84a75c4

	if (NT_SUCCESS(supOpenProcess(
	List.Processes->UniqueProcessId,
	PROCESS_QUERY_INFORMATION,
	&hObject)))

While administrators have high integrity, Mandatory Integrity Control prevents them from opening system processes for read and write access. This happens because PROCESS_QUERY_INFORMATION is considered as a denied read access while PROCESS_QUERY_LIMITED_INFORMATION is an allowed execute access. So, changing PROCESS_QUERY_INFORMATION to PROCESS_QUERY_LIMITED_INFORMATION might solve most of the problems and make this feature work even without SeDebugPrivilege.

Preferably, supxGetSystemToken should not rely on any particular process order. You might just want to use winlogon's token, or, perhaps, add some checks to make sure you are using the right security context.

And showing an error message in case something went wrong would be useful.

FLT_SERVER_PORT_OBJECT

Consider adding this to next version to the object properties.
http://redplait.blogspot.ru/2016/07/filterconnectionports.html

9600, 10586 structure seems the same
fltmgr!_FLT_SERVER_PORT_OBJECT
+0x000 FilterLink : _LIST_ENTRY
+0x010 ConnectNotify : Ptr64 long
+0x018 DisconnectNotify : Ptr64 void
+0x020 MessageNotify : Ptr64 long
+0x028 Filter : Ptr64 _FLT_FILTER
+0x030 Cookie : Ptr64 Void
+0x038 Flags : Uint4B
+0x03c NumberOfConnections : Int4B
+0x040 MaxConnections : Int4B

Build Error: StripDebug.exe

]

Hellou

Hey bro! Your software is too complicated for me and I only used RKU, but thank you for your code! respectfully: TrashGen

Where to find this own driver thats referenced in the sources?

Where to find this own driver that is referenced in the sources?
Would be nice to not have to boot the system in debug mode.

Different window stations assumed as aliases

OS: Windows 7 x64
WinObjEx64: 1.5.2

There are two window stations that are named WinSta0 that are situated in different locations:

The one, in which the interactive user works:
\Sessions\1\Windows\WindowStations\WinSta0

And the other, for services:
\Windows\WindowStations\WinSta0

These are two different window stations but WinObjEx64 shows them as if they are represented by the same object. As a result, it is not possible to view information and change security for the second window station and its desktops.

[Feature] IoRegisterPlugPlayNotification callbacks

For reference,
https://github.com/0mWindyBug/PnpNotifyResearch/tree/main

ImageScope limitations

This plugin is currently in a beta stage. It may crash WinObjEx64 while running. This will be fixed in the next 1.8.7 patch.

Show "??" entry in the list

Object Explorer shows the content of "\" by calling NtQueryDirectoryObject recursively.
This approach overlooks one particular directory - ?? (a.k.a. "local \DosDevices"), which is not returned when querying the root directory, unlike the global version of \DosDevices (GLOBAL??).
This directory typically contains a symbolic link to Global, network drives, subst drives and whatever else the user defined with DefineDosDevice.

This information is also available under \Sessions\<SESSION_ID>\DosDevices\<LOGON_SESSION_ID>, but getting there is more cumbersome and requires Administrator rights.

It can be added manually (I'm not familiar with the code, so apologies if something is horribly wrong):

diff --git a/Source/WinObjEx64/kldbg.c b/Source/WinObjEx64/kldbg.c
index 0d5b62e..1477191 100644
--- a/Source/WinObjEx64/kldbg.c
+++ b/Source/WinObjEx64/kldbg.c
@@ -70,6 +70,12 @@ static UNICODE_STRING g_usGlobalNamespace = {
     OB_GLOBALNAMESPACE
 };
 
+static UNICODE_STRING g_usLocalDevices = {
+    sizeof(OB_LOCALDEVICES) - sizeof(WCHAR),
+    sizeof(OB_LOCALDEVICES),
+    OB_LOCALDEVICES
+};
+
 /*
 * ObGetPredefinedUnicodeString
 *
@@ -94,6 +100,8 @@ PUNICODE_STRING ObGetPredefinedUnicodeString(
     case OBP_ROOT:
     default:
         return &g_usObjectsRootDirectory;
+    case OBP_LOCALDEVICES:
+        return &g_usLocalDevices;
     }
 }
 
diff --git a/Source/WinObjEx64/kldbg.h b/Source/WinObjEx64/kldbg.h
index 7cf596d..422ef1a 100644
--- a/Source/WinObjEx64/kldbg.h
+++ b/Source/WinObjEx64/kldbg.h
@@ -100,6 +100,7 @@
 #define OBTYPES_DIRECTORY       L"\\ObjectTypes"
 #define OB_GLOBALROOT           L"\\GLOBAL??\\GLOBALROOT"
 #define OB_GLOBALNAMESPACE      L"\\??"
+#define OB_LOCALDEVICES         L"??"
 
 #define OBJECT_SHIFT 8
 
@@ -135,6 +136,7 @@ typedef ULONG_PTR *PUTable;
 #define OBP_OBTYPES         2 
 #define OBP_GLOBAL          3
 #define OBP_GLOBALNAMESPACE 4  
+#define OBP_LOCALDEVICES    5
 
 //enum with information flags used by ObGetObjectHeaderOffset
 typedef enum _OBJ_HEADER_INFO_FLAG {
diff --git a/Source/WinObjEx64/list.c b/Source/WinObjEx64/list.c
index aa83f34..d9d2c4e 100644
--- a/Source/WinObjEx64/list.c
+++ b/Source/WinObjEx64/list.c
@@ -346,6 +346,12 @@ VOID xxxListObjectDirectoryTree(
 
     } while (TRUE);
 
+    xxxListObjectDirectoryTree(HeapHandle,
+        ObGetPredefinedUnicodeString(OBP_LOCALDEVICES),
+        directoryHandle,
+        ViewRootHandle,
+        prevItem);
+
     NtClose(directoryHandle);
 }
 

The result:

Links:
https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/local-and-global-ms-dos-device-names
https://www.osronline.com/article.cfm%5Earticle=381.htm
https://superuser.com/questions/884347/win32-and-the-global-namespace
https://stackoverflow.com/questions/4686897/sessions-window-stations-and-desktops