Exploring the Windows Executive - Part 1 - Object Manager
16 Oct 2016
The Windows object manager is responsible for creating, protecting and managing objects. Internally – it has 3 types:
kernel objects : primitive set of objects implemented in the kernel.
executive objects : implemented in components of the kernel.
GDI/User objects : belong within Windows subsystem and are not used by kernel.
Other than this, there is something called “Type Objects”. To save memory, object manager saves static content for objects of the same type under a Typeobject. Any object created of a specific type will inherit the type object’s properties from the TypeObject.
Whenever user mode code wants to access an object, it open a handle to the object. Whenever kernel mode code opens the object, it gains a reference to the object. Thus the object manager also keeps track of the handle and reference counts of the object. Every time a process opens a handle to the object, the handle count in the object’s header is incremented by 1.There is also a reference count that gets incremented when handle count gets incremented, and whenever the kernel assigns a pointer to the object.
The object handle is an index into the process specific Handle Table. The index starts at 0, and increments in multiples of 4. Handle table has 3 levels -> Lowest level is created when process gets created. Other levels as needed. Lowest level -> 4k Page – with 511 handle entries and a pointer to mid-level table. Mid level has 4096 pointers to sub handle tables – each of which is can have 512 entries.
You can get to the kernel handle table by looking at the address pointed to by ObpKernelHandleTable. Addresses have the MSB bit as 1 – that is how OM knows this is a kernel handle.
The !object extension displays information about a system object.
Syntax:
!object Address
!object 0 Name
!object Path
Where:
Address - Specifies the hexadecimal address of the system object for which to display information.
Name - If the first argument is zero, the second argument is interpreted as the name of a class of system objects for which to display all instances.
Path - If the first argument begins with a backslash (), !object interprets it as an object path name. When this option is used, the display will be arranged according to the directory structure used by the Object Manager.
The \Driver directory contains all driver objects
The \Device directory contains all the device objects
The \ObjectTypes directory contains Type objects for the various object types available.
The \BaseNamedObjects is the global namespace (as opposed to session namespace)
The \Sessions directory contains per session namespaces. When an application creates an object, it typically goes into it respective session unless the application has specifically asked OS to place objects in the Global namespace. Separate session namespaces allow multiple clients to run the same application without interfering with each other. By Default – for a process that’s created in a session, the system uses the session’s namespace unless the process wants to use the global namespace and prepends Global\ prefix to the object name.
The \Global?? – is the namespace where named symbolic links are created for use by all applications. The C: can be found here.
The C: is a symbolic link for target ‘\Device\hardDiskVolume2’. Lets explore this device object
Now that we know the object type details, lets dump the object’s header(objectheader) and body(deviceobject)