Windows nt object manager

From Wikipedia, the free encyclopedia

This article is about the Windows Executive subsystem. For the general concept, see Object manager.

Object Manager (internally called Ob) is a subsystem implemented as part of the Windows Executive which manages Windows resources. Resources, which are surfaced as logical objects, each reside in a namespace for categorization. Resources can be physical devices, files or folders on volumes, Registry entries or even running processes. All objects representing resources have an Object Type property and other metadata about the resource. Object Manager is a shared resource, and all subsystems that deal with the resources have to pass through the Object Manager.

Object Manager is the centralized resource broker in the Windows NT line of operating systems, which keeps track of the resources allocated to processes. It is resource-agnostic and can manage any type of resource, including device and file handles. All resources are represented as objects, each belonging to a logical namespace for categorization and having a type that represents the type of the resource, which exposes the capabilities and functionalities via properties. An object is kept available until all processes are done with it; Object Manager maintains the record of which objects are currently in use via reference counting, as well as the ownership information. Any system call that changes the state of resource allocation to processes goes via the Object Manager.

Objects can either be Kernel objects or Executive objects. Kernel objects represent primitive resources such as physical devices, or services such as synchronization, which are required to implement any other type of OS service. Kernel objects are not exposed to user mode code, but are restricted to kernel code. Applications and services running outside the kernel use Executive objects, which are exposed by the Windows Executive, along with its components such as the memory manager, scheduler and I/O subsystem. Executive objects encapsulate one or more kernel objects and expose not only the kernel and kernel-mediated resources, but also an expanded set of services that the kernel does.^{[clarification needed]} Applications themselves can wrap one or more Executive objects and surface objects^{[definition needed]} that offer certain services. Executive objects are also used by the environment subsystems (such as the Win32 subsystem, the OS/2 subsystem, the POSIX subsystem, etc.) to implement the functionality of the respective environments.

Whenever an object is created or opened, a reference to the instance, known as a handle, is created. The Object Manager indexes objects by both their names and handles. Referencing objects by handles is faster since it bypasses name translation. Handles are associated with processes by making an entry in the process’s Handle table, which lists the handles it owns, and can be transferred between processes. A process must own a handle to an object to use it, and can own up to 16,000,000 handles at one time. During creation, a process gains handles to a default set of objects. There are different types of handles, such as file handles, event handles, and process handles, which identify the type of target objects but do not distinguish the operations that can be performed through them. This consistency ensures uniform handling of various object types programmatically. Handle creation and resolution of objects from handles are exclusively managed by the Object Manager, ensuring that no resource usage goes unnoticed.

The types of Executive objects exposed by Windows NT are:

Each object managed by the Object Manager has a header and a body; the header contains state information used by Object Manager, whereas the body contains the object-specific data and the services it exposes. An object header contains certain data, exposed as Properties, such as Object Name (which identifies the object), Object Directory (the category the object belongs to), Security Descriptors (the access rights for an object), Quota Charges (the resource usage information for the object), Open handle count (the number of times a handle, an identifier to the object, has been opened), Open handle list (the list of processes which has a live reference to the object), its Reference count (the number of live references to the object), and the Type (an object that identifies the structure of the object body) of the object.

A Type object contains properties unique to the type of the object as well as static methods that implement the services offered by the object. Objects managed by Object Manager must at least provide a predefined set of services: Close (which closes a handle to an object), Duplicate (create another handle to the object with which another process can gain shared access to the object), Query object (gather information about its attributes and properties), Query security (get the security descriptor of the object), Set security (change the security access), and Wait (to synchronize with one or more objects via certain events). Type objects also have some common attributes, including the type name, whether they are to be allocated in non-paged memory, access rights, and synchronization information. All instances of the same type share the same type object, and the type object is instantiated only once. A new object type can be created by endowing an object with Properties to expose its state and methods to expose the services it offers.

Object name is used to give a descriptive identity to an object, to aid in object lookup. Object Manager maintains the list of names already assigned to objects being managed, and maps the names to the instances. Since most object accesses occur via handles, it is not always necessary to look up the name to resolve into the object reference. Lookup is only performed when an object is created (to make sure the new object has a unique name), or a process accesses an object by its name explicitly. Object directories are used to categorize them according to the types. Predefined directories include \?? alias \DosDevices (device names), \BaseNamedObjects (Mutexes, events, semaphores, waitable timers, and section objects), \Callback (callback functions), \Device, \Driver, \FileSystem, \KnownDlls, \Nls (language tables), \ObjectTypes (type objects), \RPC Control (RPC ports), \Security (security subsystem objects), and \Windows (windowing subsystem objects). Objects also belong to a Namespace. Each user session is assigned a different namespace. Objects shared between all sessions are in the GLOBAL namespace, and session-specific objects are in the specific session namespaces

OBJECT_ATTRIBUTES structure:

typedef struct _OBJECT_ATTRIBUTES {
  ULONG Length;
  HANDLE RootDirectory;
  PUNICODE_STRING ObjectName;
  ULONG Attributes;
  PSECURITY_DESCRIPTOR SecurityDescriptor;
  PSECURITY_QUALITY_OF_SERVICE SecurityQualityOfService;
} OBJECT_ATTRIBUTES *POBJECT_ATTRIBUTES;

The Attributes member can be zero, or a combination of the following flags:

OBJ_INHERIT
OBJ_PERMANENT
OBJ_EXCLUSIVE
OBJ_CASE_INSENSITIVE
OBJ_OPENIF
OBJ_OPENLINK
OBJ_KERNEL_HANDLE

Object Manager paths are available to many Windows API file functions, although Win32 names like \\?\ and \\.\ for the local namespaces suffice for most uses.^[1] Using the former in Win32 user-mode functions translates directly to \??, but using \?? is still different as this NT form does not turn off pathname expansion.^[2]

Tools that serve as explorers in the Object Manager namespaces are available. These include the 32-bit WinObj from Sysinternals^[3] and the 64-bit WinObjEx64.^[4]

• Architecture of Windows NT
• Process groups and cgroups – the equivalent POSIX and Linux concepts to the ‘Job’ object type discussed above

• Object Manager Routines (Windows Drivers)
• Channel9 Interview

Uncovering this important but little-known
Executive subsystem

The Object Manager is the Windows NT Executive subsystem that
receives the least amount of attention or recognition. Ironically, the Object
Manager provides a resource management support infrastructure that all other NT
Executive subsystems (including the Memory Manager, I/O Manager, and Process
Manager) rely on. The Object Manager is a support subsystem that performs its
work behind the scenes. As an NT systems administrator or a Win32 programmer,
you probably will never interact directly with the Object Manager; however,
almost everything you do, from opening files to starting a program to viewing
the Registry, requires its assistance.

In this tour of the Object Manager, I’ll first describe where the Object
Manager fits into NT’s architecture, the role it plays in common operations, and
the services it provides. Next, I’ll explain how NT’s subsystems define object
types and what kind of information the Object Manager tracks. Finally, I’ll look
at the Object Manager namespace, which is the doorway to file system namespaces
and the Registry namespace.

Resource Management
A major part of NT’s role is managing a computer’s physical and logical
resources, such as physical and virtual memory, disks, files, processes,
threads, synchronization primitives (semaphores, events, etc.), printers, and
video displays. NT must provide a mechanism whereby programs can look up
resources, share them, protect them, read and modify their attributes, and
interact with them. Thus, resource management encompasses tracking the state of
resources, allowing only actions consistent with their state, and an API so that
programs can manipulate them.

Files are a visible example of a common resource. NT provides an API for
creating and opening files; modifying their attributes (hidden, read-only,
etc.); and on NTFS, ensuring that programs honor file security settings.
Programs expect these capabilities, and NT implements its resource management
(i.e., the way NT efficiently keeps track of a file’s state) hidden from
applications. The operating system does the work of tracking the state and
protecting resources.

In NT, the typical way a program accesses a resource such as a file is to
open or create the resource and then manipulate it. Usually, a resource is
assigned a name when it’s created so that programs can share it. To look up or
open an existing shared resource or a global resource (e.g., a file system,
disk, or other physical device attached to the system), a program specifies the
resource’s name. However, programs often create unnamed resources, which
typically are logical resources (e.g., synchronization primitives), that an
application will privately use.

Regardless of whether resources are physical resources (such as disk drives
and keyboards) or logical resources (such as files and shared virtual memory),
NT represents them as object data structures, which the Object Manager
defines. Objects are shells that other NT Executive subsystems can fill in so
that they can build custom object types to represent the resources they manage.
The Object Manager tracks information that is independent of the type of
resource an object represents; the subsystem-specific core of an object contains
data relevant to a particular resource.

The reason NT builds objects using the Object Manager’s infrastructure is
simple: Each subsystem does not need to reinvent the wheel to track the
system-related state of an object, look up its resources, charge applications
for the memory required to allocate an object, and protect resources with
security. By concentrating these functions in the Object Manager, Microsoft can
share code across subsystems, write and validate NT’s security code once, and
apply the same naming conventions to all resources.

Object Types
The Object Manager’s duties involve creating object types, creating and
deleting objects, querying and setting an object’s attributes, and locating
objects. As I mentioned previously, Executive subsystems (including the Object
Manager) create objects that represent the resources they manage. Before a
subsystem (e.g., the I/O Manager) can tell the Object Manager to make an object
(e.g., a file), the Object Manager must define the underlying object type
that the subsystem will instantiate the object from. Object types, like classes
in C++ parlance, store information common to all objects representing the same
type of resource. This information includes statistical information and pointers
to the method procedures that the subsystems will invoke when they perform
actions on an object of the corresponding type. Thus, when the Executive
subsystems initialize, they call a function in the Object Manager to define
their object types.

For example, open files require resource management, and the I/O Manager
subsystem builds file objects (with help from the Object Manager) to track open
files. Inside the file object’s body, the I/O Manager keeps track of the file’s
name, its logical volume, and whether the file is marked for deletion; the file
object also provides storage for private data associated with the file system
driver that the file belongs to.

Other examples of subsystem object types include process objects, which
represent active processes; section objects, which represent memory-mapped files
or shared memory; and device objects, which represent physical or logical
devices. Table 1 summarizes the 23 object types NT 4.0 defines.

As with objects, NT implements object types as data structures. Figure 1
shows typical information an object type data structure stores. The object
type’s statistical data is useful for system monitoring. This data includes
information such as the name of the object type, how many objects of that type
currently exist, the maximum number of objects that have existed at any time,
and the default amount of memory that NT charges a process each time the
subsystem creates an object of that type.

Object type procedures or methods are what really differentiate object
types. When a subsystem creates an object type, the subsystem passes to the
Object Manager a data structure that contains pointers to all the object type
procedures. The Object Manager calls these procedures when the subsystem
requires actions performed on an object. For example, if a subsystem wants to
close an object, the Object Manager first calls the Okay-To-Close Procedure (if
the subsystem has specified one). If that procedure returns a FALSE value, an
error returns to the closer to signal that the object cannot be closed. If the
procedure returns a TRUE value, the Object Manager then calls the Close
Procedure so that the subsystem responsible for the object can clean up the
object’s state. Each object type procedure receives a predefined list of
parameters that includes information pertinent to the requested operation. The
call-out mechanism the Object Manager uses for object types lets subsystems see
and control the actions taken on the objects (and therefore, the resources) that
they manage.

I’ll describe the purpose of most of the object type procedures throughout
the rest of the article, but I’ll comment on two unrelated procedures that
appear in Figure 1 now. The Dump Procedure is not defined for any object type,
nor does NT ever reference it. Microsoft developers probably relied on dump
procedures in the early days of NT, but they removed the code after they had the
basic object building blocks in place and working. The Security Procedure lets
subsystems implement object security schemes that differ from NT’s default
security policies. NT falls back on its default security policies if a subsystem
does not define a Security Procedure.

WinInfo Short Takes

An often irreverent look at some of the week’s other news …

The Memory-Optimization Hoax

Don’t believe the hype. At best, RAM optimizers have no effect. At worst, they seriously degrade performance. …

Common .pst File Questions

Sue Mosher addresses some of the inevitable questions that Outlook users eventually ask about Personal Folders (.pst) files. …

sandbox-attacksurface-analysis-tools

(c) Google LLC. 2015 - 2021
Developed by James Forshaw

This is a small suite of PowerShell tools to test various properties of sandboxes on Windows. Many of the
tools take a -ProcessId flag which is used to specify the PID of a sandboxed process. The tool will impersonate
the token of that process and determine what access is allowed from that location. Also it's recommended
to run these tools as an administrator or local system to ensure the system can be appropriately enumerated.

EditSection: View and manipulate memory sections.
TokenView: View and manipulate various process token values.
NtApiDotNet: A basic managed library to access NT system calls and objects.
NtObjectManager: A powershell module which uses NtApiDotNet to expose the NT object manager.
ViewSecurityDescriptor: View the security descriptor from an SDDL string or an inherited object.

You can load the using the Import-Module Cmdlet. You'll need to disable signing requirements however.

For example copy the module to %USERPROFILE%\Documents\WindowsPowerShell\Modules then load the module with:

Import-Module NtObjectManager

You can now do things like listing the NT object manager namespace using:

Get-ChildItem NtObject:\

Also see help for various commons such as Get-NtProcess, Get-NtType or New-File.

The tools can be built with Visual Studio 2019. It's possible to also build NtApiDotNet and NtObjectManager
with .NET 5.0 building the specific project files.

Thanks to the people who were willing to test it and give feedback:
* Matt Graeber
* Lee Holmes
* Casey Smith
* Jared Atkinson

Release Notes:

1.1.33
--------
* Various bug fixes.
* Added RPC pipe support.

1.1.32
--------
* Too many changes to mention.

1.1.31
--------
* Added signing and encryption to SSPI.
* Added Get-LsaContextSignature and Test-LsaContextSignature.
* Added Protect-LsaContextMessage and Unprotect-LsaContextMessage
* Named auth commands to Lsa.
* Added TCP/IP RPC transport and add signing/encryption.
* Added Disconnect-RpcClient.
* Added server information for local RPC connection.
* Added Enable-NtTokenPrivilege and Disable-NtTokenPrivilege.
* Added native ARM/ARM64 support.
* Added Get-Win32ServiceConfig and Set-Win32ServiceConfig.
* Fixed bug in ACL canonicalization.
* Added support for SDK names of enumerations/structures. 
* Added Get-NtSDKName.
* Added support for Win32 WriteProcessMemory.
* Added Get-Win32ServiceTrigger and support for triggers in Start-Win32Service.
* Added Set-Win32ServiceSecurityDescriptor.
* Fixed INdrStructure unmarshaling #35

1.1.30
--------
* Fixed issue when displaying only a SACL with Format-NtSecurityDescriptor.
* Added basic named pipe support for RPC clients.
* Fixed issue enumerating per-user audit rules.
* Added view accessor for safe buffers.
* Improved debug tracing for RPC clients.
* Improved handling of paths with local files commands.
* Fixed path issue with Set-Win32SecurityDescriptor.
* Added querying trace providers from the WMI security key.

1.1.29
--------
* Added Get-NtProcessUser.
* Added Get-NtProcessEnvironment.
* Added global option for New-NtSymbolicLink.
* Added Split-Win32CommandLine.
* Added send and post methods to NtMessage.
* Added AsObject parameter for Get-NtObjectInformation.
* Added NtMailslotFile and fixed mailslot creation.
* Added Get-NtKeySymbolicLinkTarget.
* Added support for a FollowLink switch which will allow accessible cmdlets to follow symbolic links. Feature request #29.
* Separated forms code from the main assembly.
* Added setting service security and Get/Set-Win32ServiceSecurityDescriptor.
* Added Win32 debug console class and Start/New/Read-Win32DebugConsole.
* Added Test-NtTokenCapability.
* Added New-Win32Service and Remove-Win32Service.
* Reimplemented SidName to allow access to the Domain component.
* Added section characteristics check when parsing RPC servers. Fix for issue #27.
* Added an SDKName attribute to access rights.
* Added Add-NtAccountRight and Remove-NtAccountRight.
* Added basic VBS enclave support.
* Added support to parse ELAM information from a binary.
* Added Get-NtSigningLevel and Get-X509Certificate.
* Added Compare-NtSigningLevel.
* Added silo impersonation commands.
* Added option to impersonation System when creating a token or with Invoke-NtToken.
* Added proper enumeration of AppContainer profiles and support creating with capabilities.
* Added Get-AppModelApplicationPolicy.
* Added Get-NtThreadContext and Set-NtThreadContext.
* Added support for calling CreateProcessWithLogon via Win32Process.
* Added Start-AppModelApplication.
* Added Add-NtThreadApc.
* Fixed path handling in Get-Win32SecurityDescriptor.
* Added Get-NtFileFinalPath command.
* Reworked handling of lease oplocks.
* Added basic USN journal support.
* Added Get-NtFileStream.
* Added Get-NtMountPoint command.
* Added basic async support and the Wait-AsyncTaskResult command.
* Added Send-NtFileControl command.
* Added Get-NtFileVolumeInformation and Set-NtFileVolumeInformation.
* Added Get-NtFileItem command.
* Added support for querying device nodes, setup class and interface classes.
* Added Get-NtFileSharingProcess.
* IPeb: Added GetBeingDebugged() (#26)
* Added support for enumerating filter drivers and connecting to ports.
* Added New-NtKeySymbolicLink and Set-NtKeySymbolicLinkTarget.
* Added a Get-NtKeyHive command.

1.1.28
--------
* Added Import-Win32Module and Get-Win32Module.
* Added support for Registry Keys in the NtObjectManager provider.
* Added Get-NtDirectoryEntry.
* Added Win32 CreateRemoteThread.
* Added addition Registry Key functions.
* Added Network Authentication commands.
* Added Authentication Token formatting commands.
* Added new filtering features to TokenViewer.
* Improved cmdlets for getting and setting object information classes.
* Added Add-NtSection and Remove-NtSection.
* Added Compare-NtObject.
* Added Test-NtTokenPrivilege.
* Added type parsing from PDBs via SymbolResolver.
* Added a summary format to Format-NtSecurityDescriptor.
* Added Out-HexDump.
* Added C# compiler support for .NET Core Support of Get-RpcClient.
* Updated New-NtSecurityDescriptor and Edit-NtSecurityDescriptor.
* Basic C++ NDR formatting from irsl@.
* Added Format-NtJob.
* Added New-NtSecurityAttribute and Get-NtAceConditionData.
* Added Device/User Claims to Token Viewer and Format-NtToken.
* Added many different commands to manipulate Security Descriptors.
* Added Win32 Security Descriptor commands.
* Added filtering for accessible path commands.
* Added Audit support.
* Added basic AuthZ API support.
* Added basic ASN.1 DER parsing and Format-ASN1DER command.
* Added Kerberos Keytab file reading and writing.

1.1.27
--------
* Added support for directory change notifications.
* Added New-NtDesktop, Get-NtDesktop and Get-NtDesktopName.
* Added New-NtWindowStation, Get-NtWindowStation and Get-NtWindowStationName.
* Changed Win32 error codes to an enumeration.
* Added Load/Unload driver.
* Added properties to NtType to show access masks.
* Added basic SendInput method.
* Added token source tab to Token Viewer.
* Updated for the Job object and New-NtJob.
* Added NtWindow class a HWND enumeration.
* Added Get-AccessibleWindowStation command.
* Added some well known WNF names.
* Added option to Get-AccessibleService to check file permissions.
* Added Set-NtProcessJob command.
* Added Get-AccessibleToken command.
* Added support for compound ACEs.
* Added Get/Sid-NtTokenSid and Get/Set-NtTokenGroup.
* Added Get-AccessibleEventTrace command.
* Added Get-AccessibleWnf command.

1.1.26
--------
* Add DeviceGuid to Get/New-NtFile
* Fixed bug in ETA registrations and added GUID enumeration.
* Added SetExceptionPort to NtProcess.
* Added child process mitigation improvements.
* Added extended Fork.
* Updated native process creation support.
* Various new non-throwing methods.
* Updated to C# 7.3.
* Added list of access rights to NtType.
* Added default mandatory policy to NtType.
* Added SetDisposition methods to NtFile.
* Added console and GUI support for Object ACEs.
* Updated access checking to support Object Types.
* Access check returns a structure rather than just an access mask.
* CPP style NDR formatting (#21)
* Added Get-NtTokenPrivilege command.
* Added Get-NtLocallyUniqueId command.

1.1.25
--------
* Added new options to Get-NtSecurityDescriptor.
* Updated accessible resource checking.
* Added Remove-NtTokenPrivilege.
* Added Session option to Get-NtToken.
* Added command line option to Show-NtToken.
* Added information classes for symbolic links.

1.1.24
--------
* Added Add-NtTokenSecurityAttribute and Remove-NtTokenSecurityAttribute cmdlets.
* Added additional properties for running servies.
* Added support for drivers to Get-RunningService and Get-AccesibleService.
* Added fake service NtType objects for services and SCM to allow formatting and the UI.
* Added NtType property to security descriptors.
* Added option to Show-NtToken to elevate to admin.
* Added Suspend, Resume and Stop process commands.
* Added Get-NtEaBuffer and Set-NtEaBuffer commands.
* Added open to Get-NtDebug to get from a process.

1.1.23
--------
* Added basic ETW APIs.
* Added new thread properties.
* Added Close-NtObject function.
* Added Get-AccessibleScheduledTask cmdlet.
* Added typing for New-ExecutionAlias and renamed to Set-ExecutionAlias.
* Added Compare-RpcServer.
* Fixed handling of FQBN token security attributes.
* Added option to Format-RpcClient to output to a directory.
* Added Select-RpcServer cmdlet.
* Added RPC ALPC port brute force.

1.1.22
--------
* Removed old standalone utilities, everything should be accessible from PowerShell.
* Added Test-NetworkAccess cmdlet to replace CheckNetworkAccess utility.
* Added Set-NtFileHardlink cmdlet.
* Various fixes for RPC client code.

1.1.21
--------
* Various updates to the NDR parser, including new types and support for correlation expressions.
* Added complete transaction cmdlets.
* Added extended process creation flags for Win32Process.
* Added Format-NtSecurityDescriptor to display on the console
* Added Copy-NtObject cmdlet.
* Added basic RPC ALPC client support.
* Added option to specify a debug object for a Win32 process.
* Added processor system information.

1.1.20
--------
* Added basic ALPC support including cmdlets.
* Added better debug support including cmdlets.
* Display container access rights in SD GUI and also extract SACL if available.
* Added Set/Get-NtProcessMitigation policy to get specific policies.
* Exposed process mitigation policies using flag enums.
* Added Win32.AppContainerProfile to create and delete AC profiles.
* Many new non-throwing methods added to objects.
* Added ReadScatter and WriteGather methods to NtFile.
* Improved formatting of IO Control Codes.
* Added ability to acknowledge oplock breaks.
* Added Wow64 FS redirection support.
* Use proper WIN32 NT status facility for Win32 errors as status codes.
* Added read/write to file from safe buffers.
* Added methods to zero or fill safe buffers using native methods.
* Fix bug with querying BnoIsolationPrefix which next took into account the enable flag correctly.
* Fix from diversenok "Improve detection of restricted tokens (#20)"
* Code cleanups and source code separation.

1.1.19
--------
* Fix for bug in NtWaitTimeout not creating infinite waits.
* Added some new NTSTATUS codes and break apart the status.
* Added some new FSCTL codes.

1.1.18.1
--------
* Added missing release notes.

1.1.18
------
* Added better support for transaction objects including some cmdlets.
* Added general QueryInformation and SetInformation methods to a number of objects.
* Added side channel isolation mitigation policy.
* Added more FS volume information classes.
* Added extended section/memory functions.
* Added a few missing NDR type formats.
* Added BNO isolation process attribute.
* Added new types to separate out named pipes from normal files.
* Added Start-NtFileOplock.
* Added support for absolute security descriptors.

1.1.17
------
* Added methods to get AppModel policy from a token.
* Added Start-Win32ChildProcess
* Default to a version of DbgHelp if installed to the NtObjectManager directory under x86 or x64.
* Added some setters to token properties.
* Added a fix for a memory corruption issue in getting NT type information on 32 bit platforms (from 1orenz0).
* Added option to parse out RPC clients in Get-RpcServer.
* Fixed performance issue with section viewer and the corrupter.
* Added a valid length property to NtMappedSection.
* Added Get-NtObjectFromHandle cmdlet.
* Added Copy-NtToken function.
* Added enumeration for device characteristics.
* Fixed path resolving for file paths.
* Added Get-RpcAlpcServer cmdlet.

1.1.16
------
* Added Get-NtFilePathType function.
* Added Add-NtSecurityDescriptorDaclAce function.
* Added Path support to Get-NtSecurityDescriptor and Set-NtSecurityDescriptor.
* Added parameter to only return a specific set of IIDs from a COM proxy definition.
* Added support for extracting RPC servers from a DLL.
* Added support for enumerating registered RPC endpoints with Get-RpcEndpoint.
* Added support for enumerating running service information with Get-RunningService.
* Added Get-NtAlpcServer function.
* Reworked OpenWithType to support bruteforce of the object type.
* Added Win32Utils method to parse command line and extract image path.
* Fix DepStatus On Windows Server 2K12 / 2K16 from Rosalie.
* Added option to Get-NtProcess and Get-NtThread to only return system information.
* Added basic transaction support to registry keys.

1.1.15
------
* Convert access exceptions during NDR parsing into an NdrParser exception rather than crashing the process.
* Added function to enumerate running services with PIDs.
* Added methods to load module into a symbol resolver after creation.
* Added basic support for WNF registrations including a Get-NtWnf cmdlet.
* Expose all parameters for section mapping.
* Added a Get-NtMappedSection cmdlet.
* Various fixes to NDR decoding.
* Added method to create an anonymous named pipe pair.
* Rework of cached signing level, including unpacked EA data based on information provided by Alex Ionescu.
* Added protection level to the base New-Win32Process function.
* Added access rights for process creation.

1.1.14
------
* Added basic support for transaction objects.
* Minor fixes for ALPC support.
* Implemented OOP NDR parsing.
* Added NDR parsing and formatting powershell functions such as New-NdrParser and Format-NdrComProxy
* Fix for display of NDR arrays from 1orenz0.
* Print NDR correlation descriptors during formatting.
* Added support to read out COM proxies.

1.1.13
------
* Fixed bug in Get-NtToken for sandboxed tokens.
* Extended support for Job objects.
* Added Set-NtFileReparsePoint cmdlet.
* Added support for viewing a file with Show-NtSection
* Added support for DuplicateTo methods from rosalie.lecart.
* Improved support for Win32 Desktop and WindowStation objects.
* ScriptBlock support for the $_ argument.
* Added SID -> Name cache to improve performance.
* Fixed user marshallers in NDR for Windows 7.
* Added internal security descriptor viewer control.

1.1.12
------
* Added basic NDR parser.
* Added basic symbol resolver.
* Added method to read a security descriptor from another process.
* Improved process memory read and writing methods.
* Added virtual memory cmdlets to allocate, release and modify memory.
* Added Get-EmbeddedAuthenticodeSignature function.
* Added Get and Set NtSecurityDescriptor functions.
* Added ProcessTrustLabel to basic security information set.
* Added Get-NtFileChild cmdlet.
* Added Get-NtKeyChild cmdlet.
* Added Get-NtDirectoryChild cmdlet.
* Added name lookup to NtIoControlCode.
* Added NtNamedPipeFile type with implementations of basic pipe functions.
* Added ADd-DosDevice and Remove-DosDevice cmdlets.
* Added file directory and stream visitors.
* Merged Get-NtLowBoxToken and Get-NtFilteredToken into Get-NtToken.
* Modified Show-NtSection to also display an arbitrary byte array.
* Added an Invoke-NtToken cmdlet to run a script block under impersonation.
* Added Remove-NtFile cmdlet.
* Added case sensitive property for RS4.
* Added flags for NtCreateDirectoryObjectEx.
* Added pseudo option to Get-NtToken.
* Improved conditional ACE support.

1.1.11
------
* Improved New-NtToken including adding missing IL
* Added new NTSTATUS codes from 1709
* Changes to native process creation
* Added OverrideChildProcessCreation for Win32 process
* Added display of process trust labels from tokens.
* Fixed IsChildProcessRestricted on 1709 and above (changed structure)
* Fixed named pipe server in TokenViewer
* Added -All parameter to Show-NtToken to display list of tokens.

1.1.10
------
* Added support for extended handle information to allow for PIDs > 64k.
* Added basic New-NtToken cmdlet and system call.
* Added Resolve-NtObjectAdddress cmdlet to resolve the addresses of a list of objects.
* Added generic object ReOpen method.
* Added vistor method to object directories to enumerate recursively with a callback.
* Added display of process trust labels.

1.1.9
-----
* Fix for bug when querying extended process information on Windows 7/8.
* Add OneDrive file attributes from thierry.franzetti.
* Added support for displaying child AppContainer names.
* Various improvements to section editor including integer data inspectors.

1.1.8
-----
* Better support for relative paths in the cmdlets including supporting ones based on the current directory.
* RenameEx and DispositionEx support from fllombard.
* Added Key value deletion and fixes from rsiestrunck.
* Fixed bug in NtOpenSession prototype.
* Added support for adding additional groups to a token in Get-NtToken if user has SeTcbPrivilege.
* Added Show-NtToken to display a token in the GUI, renamed old whois style token viewer to Show-NtTokenEffective.
* Added PowerShell functions to get and create execution alias reparse points.
* Added section viewer and editor with Show-NtSection function.

1.1.7
-----
* Added projects to build NtObjectManager for PowerShell Core 6.0
* Added additional techniques to open process tokens in access checking cmdlets.
* Fixed issues with Add-NtKey and added Remove-NtKey cmdlets.
* Minor fixes from fllombard
* Added change notify key with asynchronous support
* Added kernel LUID allocation

1.1.6
-----
* Added support for child process policy and desktop app policy to Win32ProcessConfig.
* Added new mitigation options from Win10 1709.
* Fix a couple of crashes.

1.1.5
-----
* Fixed crash on 32 bit Windows when enumerating NT types.
* Merged ManagedHandleUtils assembly into main NtApiDotNet under the Win32 namespace.

1.1.4
-----
* Added Show-NtSecurityDescriptor function.
* Added support for modifying security descriptors in the UI.
* Cleanup of access mask when being displayed in the UI.
* Added opaque reparse buffer.

1.1.3
-----
* Added Show-NtToken function.
* Added basic version checking for certain functions which can't be accessed on Windows 7.
* Fixed referenced System.Management.Automation assembly version to run properly with no PS2.
* Fixed some bugs in token structures which preventing being used with multiple values.
* Added support to Win32Process for LPAC.

1.1.2
-----
* Added Get-AccessibleHandle cmdlet.
* Support for oplock levels.
* Added support to set inherit and protect on close flags to objects.
* Added Get-NtFilePath function.

1.1.1
-----
* Fix to native protected process creation.
* Added functions to create native NT processes.

1.1.0
-----
* Removed check tools, excluding CheckNetworkAccess.
* Added basic Job object cmdlets.
* Added creation of protected processes in Win32Process.
* Added service access checking cmdlet.
* Added get executable manifest cmdlet.

1.0.9
-----
* Made New-Win32Process more generic and added support for Win32k filter enable.
* Added function to capture token from a process using impersonation.
* Added basic support for Desktop and WindowStation objects using Win32u.dll exports.
* Added file locking implementation including async.
* Added hardlink enumeration.
* Added NTFS stream enumeration.
* Deprecated most of the old standalone utilities in favour of PS cmdlets.

1.0.8
-----
* Added cmdlets to create a kernel memory dump, system environment and licensing.
* Additional system calls implemented.
* Added access to secure boot policies and code integrity policies.
* Made Win32 Process creation more generic and added cmdlet.
* Added access check by type including SELF SID.

1.0.7
-----
* Added new cmdlets to do access checking. Many of the old standalone utilities are now deprecated.
* Added cmdlets to create lowbox tokens
* Added list of known capability SIDs and resolve them during name lookup
* Added cmdlet to get a SID
* Added cmdlet to do a standalone access checking
* Reworked the APIs to include non-throwing versions of many of the core Open/Create methods.
* Made NtType more inspectable, includes access enumeration and rationalizes the opening methods.
* Various additional properties such as extended process flags, checking for LPAC
* Rework of access mask handling. Now all low-level APIs use an AccessMask structure which has
  conversion operators to and from other enumerations.
* Various other bug fixes.

1.0.6
-----
* Added cmdlet to filter a Token object.
* Cleanups to various components to make them easier to use from PS

1.0.5
-----
* Added additional Known SIDs
* Unified the variant Get-NtToken* cmdlets into one.
* Added additional token cmdlets such as Logon and Clipboard.
* Added initial support for IO Completion Ports
* Added object creation time property
* Added support to set a process device map
* Added top level CanSynchronize property to NtObject
* Bugs fixes from Rustam Agametov
* Made process list in token viewer a list rather than a tree and made a separate handle tab.

1.0.4
-----
* Support getting and setting file EA buffer
* Added cmdlet to get NTSTATUS code information
* Support to toggle UIAccess and Virtualization flags on tokens
* Added asynchronous support for file operations using Task APIs
* Added support for virtual memory functions
* Added cmdlet to create named pipes and mailslots.
* Added support for specifying SD as SDDL directly to cmdlets.
* Added thread descriptions for Anniversary edition and above.

1.0.3
-----
* Fixed small bug in handling of IO_STATUS_BLOCK which could result in memory corruption.
* Added support to list directory entries for a file directory.
* Added support to do basic read and writes to a file.

1.0.2
-----
* Added support to disable dynamic code policy on a process.
* Added cmdlets for reparse points.
* Fixes for EA buffer.
* Added service SIDs.
* Added support for removing token privileges.
* Fixed token security attribute parsing.

v1.0.1
------
* Replaced all unmanaged code with a managed library.
* Added NtObjectManager Powershell Module

v1.0.0
------
* Initial Release

Диспетчер объектов в Windows с иерархической категорией с использованием пространств имен

Диспетчер объектов (внутреннее название Ob ) — это подсистема, реализованная как часть Windows Executive, которая управляет ресурсами Windows. Ресурсы, которые отображаются как логические объекты, каждый находится в пространстве имен для категоризации. Ресурсы могут быть физическими устройствами, файлами или папками на томах, записями реестра или даже запущенными процессами. Все объекты, представляющие ресурсы, имеют свойство Тип объектаи другие метаданные о ресурсе. Диспетчер объектов — это общий ресурс, и все подсистемы, которые имеют дело с ресурсами, должны проходить через диспетчер объектов.

Содержание

• 1 Архитектура
  • 1.1 Структура объекта
• 2 Использование
• 3 См. Также
• 4 Ссылки
• 5 Внешние ссылки

Архитектура

Диспетчер объектов централизованный брокер ресурсов в линейке операционных систем Windows NT, который отслеживает ресурсы, выделенные процессам. Он не зависит от ресурсов и может управлять любым типом ресурсов, включая дескрипторы устройств и файлов. Все ресурсы представлены как объекты, каждый из которых принадлежит к логическому пространству имен для категоризации и имеет тип, который представляет тип ресурса, который раскрывает возможности и функциональные возможности через свойства. Объект остается доступным до тех пор, пока с ним не будут выполнены все процессы; Диспетчер объектов поддерживает запись о том, какие объекты в настоящее время используются, с помощью подсчета ссылок, а также информацию о владельце. Любой системный вызов , который изменяет состояние выделения ресурсов процессам, выполняется через диспетчер объектов.

Объекты могут быть объектами ядра или исполнительными объектами. Объекты ядра представляют собой примитивные ресурсы, такие как физические устройства, или службы, такие как синхронизация, которые требуются для реализации любого другого типа службы ОС. Объекты ядра не доступны коду пользовательского режима, но ограничены кодом ядра. Приложения и службы, работающие вне ядра, используют объекты Executive, которые предоставляются Windows Executive вместе с его компонентами, такими как диспетчер памяти, планировщик и подсистема ввода-вывода. Исполнительные объекты инкапсулируют один или несколько объектов ядра и предоставляют не только ядро ​​и ресурсы, опосредованные ядром, но также расширенный набор служб, которые выполняет ядро. Сами приложения могут заключать в оболочку один или несколько объектов Executive и поверхностных объектов, которые предлагают определенные услуги. Исполнительные объекты также используются подсистемами среды (такими как подсистема Win32, подсистема OS / 2, подсистема POSIX и т. Д.) Для реализации функциональности соответствующих сред.

Каждый раз, когда объект создается или открывается, создается ссылка на экземпляр, называемая дескриптором. Диспетчер объектов индексирует объекты как по именам, так и по ручкам. Но обращение к объектам по ручкам происходит быстрее, потому что перевод имени можно пропустить. Дескрипторы связаны с процессами (путем внесения записи в таблицу дескрипторов процесса, в которой перечислены принадлежащие им дескрипторы) и также могут передаваться между процессами. Процесс должен владеть дескриптором объекта перед его использованием. Одновременно процессу может принадлежать не более 16 000 000 дескрипторов. Во время создания процесс получает дескрипторы набора объектов по умолчанию. Хотя существуют различные типы дескрипторов — дескрипторы файлов, дескрипторы событий и дескрипторы процессов — они помогают только в определении типа целевых объектов; не в различении операций, которые могут быть выполнены с их помощью, тем самым обеспечивая единообразие программной обработки различных типов объектов. Создание дескрипторов и разрешение объектов из дескрипторов осуществляется исключительно через диспетчер объектов, поэтому никакое использование ресурсов не остается незамеченным им.

Типы исполнительных объектов, предоставляемые Windows NT:

Структура объекта

Каждый объект, управляемый диспетчером объектов, имеет заголовок и тело; заголовок содержит информацию о состоянии, используемую диспетчером объектов, тогда как тело содержит данные об объекте и предоставляемые им службы. Заголовок объекта содержит определенные данные, представленные как Свойства, такие как Имя объекта(которое идентифицирует объект), Каталог объектов(категория, к которой принадлежит объект), Дескрипторы безопасности (права доступа для объекта), Quota Charges(информация об использовании ресурсов для объекта), Счетчик открытых дескрипторов(количество раз, когда дескриптор, идентификатор объекта, был открыт), Открыть список дескрипторов(список процессов, которые имеют живую ссылку на объект), его Счетчик ссылок(количество активных ссылок на объект) и Тип(объект, который идентифицирует структуру тела объекта) объекта.

A Типобъект содержит свойства, уникальные для данного типа объекта, а также статические методы, реализующие услуги, предлагаемые объектом. Объекты, управляемые диспетчером объектов, должны как минимум предоставлять предопределенный набор служб: Close(закрывает дескриптор объекта), Дублировать(создает другой дескриптор объекта, с которым другой процесс может получить общий доступ к объекту), объект запроса(собрать информацию о его атрибутах и ​​свойствах), безопасность запроса(получить дескриптор безопасности объекта), Установить безопасность(изменить безопасность доступа) и Ждать(для синхронизации с одним или несколькими объектами через определенные события). Объекты типа также имеют некоторые общие атрибуты, включая имя типа, то, должны ли они быть выделены в невыгружаемой памяти, права доступа и информацию о синхронизации. Все экземпляры одного и того же типа совместно используют один и тот же объект типа, и объект типа создается только один раз. Новый тип объекта может быть создан путем наделения объекта свойствами, чтобы раскрыть его состояние и методы для предоставления услуг, которые он предлагает.

Имя объектаиспользуется для придания объекту описательной идентичности, чтобы помочь в поиске объекта. Диспетчер объектов поддерживает список имен, уже назначенных управляемым объектам, и сопоставляет имена экземплярам. Поскольку большинство обращений к объектам происходит через дескрипторы, не всегда необходимо искать имя для разрешения в ссылку на объект. Поиск выполняется только тогда, когда объект создан (чтобы убедиться, что новый объект имеет уникальное имя), или когда процесс обращается к объекту по его имени явно. Каталоги объектовиспользуются для их категоризации по типам. Предопределенные каталоги включают \ ??(имена устройств), \ BaseNamedObjects(мьютексы, события, семафоры, ожидаемые таймеры и объекты разделов), \ Callback(обратный вызов functions), \ Device, \ Drivers, \ FileSystem, \ KnownDlls, \ Nls(языковые таблицы), \ ObjectTypes(типы объектов), \ RPC Controls(RPC порты), \ Security(объекты подсистемы безопасности) и \ Window(объекты оконной подсистемы). Объекты также принадлежат пространству имен. Каждому пользовательскому сеансу назначается другое пространство имен. Объекты, совместно используемые всеми сеансами, находятся в пространстве имен GLOBAL, а объекты, относящиеся к сеансу, находятся в определенных пространствах имен сеанса

Структура OBJECT_ATTRIBUTES:

typedef struct _OBJECT_ATTRIBUTES {ULONG Length; HANDLE RootDirectory; PUNICODE_STRING ObjectName; ULONG атрибуты; PSECURITY_DESCRIPTOR SecurityDescriptor; PSECURITY_QUALITY_OF_SERVICE SecurityQualityOfService; } OBJECT_ATTRIBUTES * POBJECT_ATTRIBUTES;

Элемент Attributes может быть нулем или комбинацией следующих флагов:

OBJ_INHERIT OBJ_PERMANENT OBJ_EXCLUSIVE OBJ_CASE_INSENSITIVE OBJ_OPENIF OBJ_OPENLINK OBJ_KERNEL_HANDLE

Путь к диспетчеру использования

доступен для объекта многие файловые функции Windows API, хотя имена Win32, такие как \\? \ и \\. \ для локальных пространств имен, достаточны для большинства применений. Использование первого в функциях пользовательского режима Win32 преобразуется непосредственно в \ ??, но с использованием \ ?? по-прежнему отличается, поскольку эта форма NT не отключает расширение имени пути.

Доступны инструменты, которые служат в качестве исследователей в пространствах имен диспетчера объектов. К ним относятся 32-разрядный WinObj из Sysinternals и 64-разрядный WinObjEx64.

См. Также

• Архитектура Windows NT

Ссылки

Внешние ссылки

• Процедуры диспетчера объектов (драйверы Windows)
• Интервью на Channel9

1. ^«Именование файлов, путей и пространств имен — приложения Win32». docs.microsoft.com.
2. ^»winapi — Есть ли разница между \ ?? \ и \\? \ путями?». Переполнение стека.
3. ^«WinObj — Windows Sysinternals». docs.microsoft.com.
4. ^»hfiref0x / WinObjEx64: 64-разрядный обозреватель объектов Windows». GitHub. 20 февраля 2020 г.

The architecture of Windows NT, a line of operating systems produced and sold by Microsoft, is a layered design that consists of two main components, user mode and kernel mode. It is a preemptive, reentrant operating system, which has been designed to work with uniprocessor and symmetrical multi processor (SMP)-based computers. To process input/output (I/O) requests, they use packet-driven I/O, which utilizes I/O request packets (IRPs) and asynchronous I/O. Starting with Windows 2000, Microsoft began making 64-bit versions of Windows available—before this, these operating systems only existed in 32-bit versions.

Programs and subsystems in user mode are limited in terms of what system resources they have access to, while the kernel mode has unrestricted access to the system memory and external devices. The Windows NT kernel is known as a hybrid kernel. The architecture comprises a simple kernel, hardware abstraction layer (HAL), drivers, and a range of services (collectively named Executive), which all exist in kernel mode.Template:Sfn

User mode in Windows NT is made of subsystems capable of passing I/O requests to the appropriate kernel mode software drivers by using the I/O manager. Two subsystems make up the user mode layer of Windows NT: the Environment subsystem (which runs applications written for many different types of operating systems), and the Integral subsystem (operates system specific functions on behalf of the environment subsystem). Kernel mode in Windows NT has full access to the hardware and system resources of the computer. The kernel mode stops user mode services and applications from accessing critical areas of the operating system that they should not have access to what to nothing

The Executive interfaces, with all the user mode subsystems, deals with I/O, object management, security and process management. The kernel sits between the Hardware Abstraction Layer and the Executive to provide multiprocessor synchronization, thread and interrupt scheduling and dispatching, and trap handling and exception dispatching. The kernel is also responsible for initializing device drivers at bootup. Kernel mode drivers exist in three levels: highest level drivers, intermediate drivers and low level drivers. Windows Driver Model (WDM) exists in the intermediate layer and was mainly designed to be binary and source compatible between Windows 98 and Windows 2000. The lowest level drivers are either legacy Windows NT device drivers that control a device directly or can be a PnP hardware bus.

User mode[]

The user mode is made up of subsystems which can pass I/O requests to the appropriate kernel mode drivers via the I/O manager (which exists in kernel mode). ^{[citation needed]} Two subsystems make up the user mode layer of Windows NT: the Environment subsystem and the Integral subsystem.

The environment subsystem was designed to run applications written for many different types of operating systems. None of the environment subsystems can directly access hardware, and must request access to memory resources through the Virtual Memory Manager that runs in kernel mode. ^{[citation needed]} Also, applications run at a lower priority than kernel mode processes. ^{[citation needed]}

There are three main environment subsystems: the Win32 subsystem, an OS/2 subsystem and a POSIX subsystem.^[1]

• The Win32 environment subsystem can run 32-bit Windows applications. It contains the console as well as text window support, shutdown and hard-error handling for all other environment subsystems. It also supports Virtual DOS Machines (VDMs), which allow MS-DOS and 16-bit Windows (Win16) applications to run on Windows NT. There is a specific MS-DOS VDM which runs in its own address space and which emulates an Intel 80486 running MS-DOS 5.0. Win16 programs, however, run in a Win16 VDM. Each program, by default, runs in the same process, thus using the same address space, and the Win16 VDM gives each program its own thread to run on. However, Windows NT does allow users to run a Win16 program in a separate Win16 VDM, which allows the program to be preemptively multitasked as Windows NT will pre-empt the whole VDM process, which only contains one running application. The Win32 environment subsystem process (csrss.exe) also includes the window management functionality, sometimes referred to as a «window manager». It handles input events (such as from the keyboard and mouse), then passes messages to the applications that need to receive this input. Each application is responsible for drawing or refreshing its own windows and menus, in response to these messages.
• The OS/2 environment subsystem supports 16-bit character-based OS/2 applications and emulates OS/2 1.x, but not 32-bit or graphical OS/2 applications as used with OS/2 2.x or later.
• The POSIX environment subsystem supports applications that are strictly written to either the POSIX.1 standard or the related ISO/IEC standards. The POSIX subsystem has been an area of recent active development and is a major feature of Windows Compute Cluster Server 2003.

The integral subsystem looks after operating system specific functions on behalf of the environment subsystem. ^{[citation needed]} It consists of a security subsystem, a workstation service and a server service. The security subsystem deals with security tokens, grants or denies access to user accounts based on resource permissions, handles login requests and initiates login authentication, and determines which system resources need to be audited by Windows NT. ^{[citation needed]} It also looks after Active Directory. ^{[citation needed]} The workstation service is an API to the network redirector, which provides the computer access to the network. ^{[citation needed]} The server service is an API that allows the computer to provide network services.^{[citation needed]}

Kernel mode[]

Windows NT kernel mode has full access to the hardware and system resources of the computer and runs code in a protected memory area.^[2] It controls access to scheduling, thread prioritization, memory management and the interaction with hardware. The kernel mode stops user mode services and applications from accessing critical areas of the operating system that they should not have access to; user mode processes must ask the kernel mode to perform such operations on their behalf.

While the x86 architecture supports four different privilege levels (numbered 0 to 3), only the two extreme privilege levels are used. Usermode programs are run with CPL 3, and the kernel runs with CPL 0. These two levels are often referred to as «ring 3» and «ring 0», respectively. Such a design decision had been done to achieve code portability to RISC platforms that only support two privilege levels,^[3] though this breaks compatibility with OS/2 applications that contain I/O privilege segments that attempt to directly access hardware.^[4]

Kernel mode consists of executive services, which is itself made up of many modules that do specific tasks, kernel drivers, a kernel and a Hardware Abstraction Layer, or HAL.^[2]

Executive[]

The Windows Executive services make up the low-level kernel-mode portion, and are contained in the file NTOSKRNL.EXE.^[2] It deals with I/O, object management, security and process management. These are divided into several subsystems, among which are Cache Manager, Configuration Manager, I/O Manager, Local Procedure Call (LPC), Memory Manager, Object Manager, Process Structure and Security Reference Monitor (SRM). Grouped together, the components can be called Executive services (internal name Ex). System Services (internal name Nt), i.e., system calls, are implemented at this level, too, except very few that call directly into the kernel layer for better performance. ^{[citation needed]}

The term «service» in this context generally refers to a callable routine, or set of callable routines. This is distinct from the concept of a «service process,» which is a user mode component somewhat analogous to a daemon in Unix-like operating systems.

File:Object Manager (Windows) screenshot.png

Object Manager

The Object Manager (internal name Ob) is an executive subsystem that all other executive subsystems, especially system calls, must pass through to gain access to Windows NT resources—essentially making it a resource management infrastructure service.Template:Sfn The object manager is used to reduce the duplication of object resource management functionality in other executive subsystems, which could potentially lead to bugs and make development of Windows NT harder.Template:Sfn To the object manager, each resource is an object, whether that resource is a physical resource (such as a file system or peripheral) or a logical resource (such as a file). Each object has a structure or object type that the object manager must know about.

Object creation is a process in two phases, creation and insertion. Creation causes the allocation of an empty object and the reservation of any resources required by the object manager, such as an (optional) name in the namespace. If creation was successful, the subsystem responsible for the creation fills in the empty object.Template:Sfn Finally, if the subsystem deems the initialization successful, it instructs the object manager to insert the object, which makes it accessible through its (optional) name or a cookie called a handle.Template:Sfn From then on, the lifetime of the object is handled by the object manager, and it’s up to the subsystem to keep the object in a working condition until being signaled by the object manager to dispose of it.Template:Sfn

Handles are identifiers that represent a reference to a kernel resource through an opaque value.^[5] Similarly, opening an object through its name is subject to security checks, but acting through an existing, open handle is only limited to the level of access requested when the object was opened or created. ^{[citation needed]}

Object types define the object procedures and any data specific to the object. In this way, the object manager allows Windows NT to be an object oriented operating system, as object types can be thought of as polymorphic classes that define objects. Most subsystems, though, with a notable exception in the I/O Manager, rely on the default implementation for all object type procedures. ^{[citation needed]}

Each instance of an object that is created stores its name, parameters that are passed to the object creation function, security attributes and a pointer to its object type. The object also contains an object close procedure and a reference count to tell the object manager how many other objects in the system reference that object and thereby determines whether the object can be destroyed when a close request is sent to it.Template:Sfn Every named object exists in a hierarchical object namespace.

Cache Controller

Closely coordinates with the Memory Manager, I/O Manager and I/O drivers to provide a common cache for regular file I/O. Uniquely, the Windows Cache Manager operates on file blocks (rather than device blocks), for consistent operation between local and remote files, and ensures a certain degree of coherency with memory-mapped views of files, since cache blocks are a special case of memory-mapped views and cache misses a special case of page faults.

Configuration Manager

Implements the Windows registry.

I/O Manager

Allows devices to communicate with user-mode subsystems. It translates user-mode read and write commands into read or write IRPs which it passes to device drivers. It accepts file system I/O requests and translates them into device specific calls, and can incorporate low-level device drivers that directly manipulate hardware to either read input or write output. It also includes a cache manager to improve disk performance by caching read requests and write to the disk in the background.

Local Procedure Call (LPC)

Provides inter-process communication ports with connection semantics. LPC ports are used by user-mode subsystems to communicate with their clients, by Executive subsystems to communicate with user-mode subsystems, and as the basis for the local transport for MSRPC.

Memory Manager

Manages virtual memory, controlling memory protection and the paging of memory in and out of physical memory to secondary storage, and implements a general-purpose allocator of physical memory. It also implements a parser of PE executables that lets an executable be mapped or unmapped in a single, atomic step.

Starting from Windows NT Server 4.0, Terminal Server Edition, the memory manager implements a so-called session space, a range of kernel-mode memory that is subject to context switching just like user-mode memory. This lets multiple instances of the kernel-mode Win32 subsystem and GDI drivers run side-by-side, despite shortcomings in their initial design. Each session space is shared by several processes, collectively referred to as a «session».

To ensure a degree of isolation between sessions without introducing a new object type, the association between processes and sessions is handled by the Security Reference Monitor, as an attribute of a security subject (token), and it can only be changed while holding special privileges.

The relatively unsophisticated and ad-hoc nature of sessions is due to the fact they weren’t part of the initial design, and had to be developed, with minimal disruption to the main line, by a third party (Citrix) as a prerequisite for their terminal server product for Windows NT, called WinFrame. Starting with Windows Vista, though, sessions finally became a proper aspect of the Windows architecture. No longer a memory manager construct that creeps into user mode indirectly through Win32, they were expanded into a pervasive abstraction affecting most Executive subsystems. As a matter of fact, regular use of Windows Vista always results in a multi-session environment.^[6]

Process Structure

Handles process and thread creation and termination, and it implements the concept of Job, a group of processes that can be terminated as a whole, or be placed under shared restrictions (such a total maximum of allocated memory, or CPU time). Job objects were introduced in Windows 2000.

PnP Manager

Handles Plug and Play and supports device detection and installation at boot time. It also has the responsibility to stop and start devices on demand—this can happen when a bus (such as USB or FireWire) gains a new device and needs to have a device driver loaded to support it. Its bulk is actually implemented in user mode, in the Plug and Play Service, which handles the often complex tasks of installing the appropriate drivers, notifying services and applications of the arrival of new devices, and displaying GUI to the user.

SAVE

Power Manager

Deals with power events (power-off, stand-by, hibernate, etc.) and notifies affected drivers with special IRPs (Power IRPs).

Security Reference Monitor (SRM)

The primary authority for enforcing the security rules of the security integral subsystem.^[7] It determines whether an object or resource can be accessed, via the use of access control lists (ACLs), which are themselves made up of access control entries (ACEs). ACEs contain a security identifier (SID) and a list of operations that the ACE gives a select group of trustees—a user account, group account, or login session^[8]—permission (allow, deny, or audit) to that resource.Template:Sfn^[9]

GDI

The Graphics Device Interface is responsible for tasks such as drawing lines and curves, rendering fonts and handling palettes. The Windows NT 3.x series of releases had placed the GDI component in the user-mode Client/Server Runtime Subsystem, but this was moved into kernel mode with Windows NT 4.0 to improve graphics performance.^[10]

Kernel[]

The kernel sits between the HAL and the Executive and provides multiprocessor synchronization, thread and interrupt scheduling and dispatching, and trap handling and exception dispatching; it is also responsible for initializing device drivers at bootup that are necessary to get the operating system up and running. That is, the kernel performs almost all the tasks of a traditional microkernel; the strict distinction between Executive and Kernel is the most prominent remnant of the original microkernel design, and historical design documentation consistently refers to the kernel component as «the microkernel».

The kernel often interfaces with the process manager.Template:Sfn The level of abstraction is such that the kernel never calls into the process manager, only the other way around (save for a handful of corner cases, still never to the point of a functional dependence).

Kernel-mode drivers[]

Windows NT uses kernel-mode device drivers to enable it to interact with hardware devices. Each of the drivers has well defined system routines and internal routines that it exports to the rest of the operating system. All devices are seen by user mode code as a file object in the I/O manager, though to the I/O manager itself the devices are seen as device objects, which it defines as either file, device or driver objects. Kernel mode drivers exist in three levels: highest level drivers, intermediate drivers and low level drivers. The highest level drivers, such as file system drivers for FAT and NTFS, rely on intermediate drivers. Intermediate drivers consist of function drivers—or main driver for a device—that are optionally sandwiched between lower and higher level filter drivers. The function driver then relies on a bus driver—or a driver that services a bus controller, adapter, or bridge—which can have an optional bus filter driver that sits between itself and the function driver. Intermediate drivers rely on the lowest level drivers to function. The Windows Driver Model (WDM) exists in the intermediate layer. The lowest level drivers are either legacy Windows NT device drivers that control a device directly or can be a PnP hardware bus. These lower level drivers directly control hardware and do not rely on any other drivers.

Hardware abstraction layer[]

The Windows NT hardware abstraction layer, or HAL, is a layer between the physical hardware of the computer and the rest of the operating system. It was designed to hide differences in hardware and therefore provide a consistent platform on which the kernel is run. The HAL includes hardware-specific code that controls I/O interfaces, interrupt controllers and multiple processors.

However, despite its purpose and designated place within the architecture, the HAL isn’t a layer that sits entirely below the kernel, the way the kernel sits below the Executive: all known HAL implementations depend in some measure on the kernel, or even the Executive. In practice, this means that kernel and HAL variants come in matching sets that are specifically engineered to work together.

In particular hardware abstraction does not involve abstracting the instruction set, which generally falls under the wider concept of portability. Abstracting the instruction set, when necessary (such as for handling the several revisions to the x86 instruction set, or emulating a missing math coprocessor), is performed by the kernel, or via platform virtualization.

See also[]

• Windows NT
• Windows library files
• MinWin
• Linux architecture
• Unix architecture
• Comparison of operating system kernels
• User-Mode Driver Framework
• Kernel-Mode Driver Framework
• ReactOS

Notes and references[]

Notes

References

External links[]

• Microsoft’s official Windows 2000 site
• Windows 2000 Plug and Play architecture
• Memory management in the Windows XP kernel

hr:Arhitektura Windowsa NT
ja:Windows NT系
tl:Kernel