Windows Servicing Stack Exploration Notes

There is little documentation around since much of this topic is an internal working of the Windows operating system and not supposed to be publicly documented.

Naïve Approaches

The Windows operating system has a giant pile of program files. Upon naïve examination, one may find the following:

When searching for the name of a system file inside a Windows installation, there are at least two results. For example, if you target %SYSTEMROOT%\SystemApps\ShellExperienceHost_cw5n1h2txyewy\ClockFlyoutExperience.dll and search for ClockFlyoutExperience.dll, you will find at least one other file at %SYSTEMROOT%\WinSxS\amd64_microsoft-windows-s..ncehost.shellcommon_31bf3856ad364e35_<version>_none_<hash>\ClockFlyoutExperience.dll. They have the same content. These extra copies always appear inside the %SYSTEMROOT%\WinSxS directory.
- microsoft-windows-s..ncehost.shellcommon appears to be truncated from a longer name.
Surprisingly, system directory names, such as ShellExperienceHost_cw5n1h2txyewy, will not appear elsewhere in a search, although they will appear as part of the file name in %SYSTEMROOT%\WinSxS\FileMaps.
Most files in the Windows installation are owned and only writable by the user TrustedInstaller, not any administrator or SYSTEM. This makes it harder (but not impossible) to modify these files.
When different Windows editions are compared, certain relevant registry entries differ according to their files. For example, if you compare installation images of Windows 10 Home 1809 against Windows 10 Enterprise LTSC 2019, you will find the latter missing not only OneDriveSetup.exe but also a collection of relevant registry entries. This strongly hints at a mechanism for feature management that is not merely file management.

Servicing Stack

The Windows Servicing Stack is the infrastructure used to manage Windows installations. Servicing Stack Updates (SSU) cannot be uninstalled. A list of servicing stack versions is kept in HKLM\COMPONENTS\ServicingStackVersions, and Windows will use the latest version. The files for the servicing stack are located in %SYSTEMROOT%\WinSxS\<arch>_microsoft-windows-servicingstack_31bf3856ad364e35_<version>_none_<hash>.

Open the Properties :: Details panel to read a Microsoft-supplied description for each Servicing Stack executable.

Components

The subdirectories of %SYSTEMROOT%\WinSxS with extremely long names are part of Windows XP side-by-side assemblies, or also components after Vista. When a side-by-side assembly is a part of the Windows operating system, it is called a component. A component is completely defined by the following parts:

Manifest, located inside %SYSTEMROOT%\WinSxS\Manifests. Manifests located here are additionally encoded; see SXSEXP. The manifest specifies the component’s full name (not truncated), dependencies, the install location and security properties of its files, as well as its registry content.
Files, located inside subdirectories of %SYSTEMROOT%\WinSxS with extremely long names.
- A side-by-side assembly does not have to contain files. You will find certain manifests that do not have a corresponding file directory. These manifests may create folders or registry entries.
- The manifest specifies the actual install location of the files.
Security Catalog, located inside %SYSTEMROOT%\WinSxS\Catalogs. A side-by-side assembly must be signed via a catalog.

Component Store (`%SYSTEMROOT%\WinSxS`) and Component Servicing Infrastructure (CSI)

Component Based Servicing (CBS) was introduced in Windows Vista. Utilizing the side-by-side assembly specification from Windows XP, it was not completely built from the ground up.

The component store consists of %SYSTEMROOT%\WinSxS only. The registry hive %SYSTEMROOT%\System32\Config\COMPONENTS is completely derived from files within %SYSTEMROOT%\WinSxS to aid Component Based Servicing.

The whole Windows installation is made of hard link projections from %SYSTEMROOT%\WinSxS. The components and hard link projections are manipulated by the Component Servicing Infrastructure (CSI) when required.

There is no published documentation to work with CSI. However, the servicing stack files wcp.dll (“Windows Componentization Platform Servicing API”, a major CSI executable) and turbostack.dll expose potentially useful APIs.

Component Based Servicing (CBS)

Component Based Servicing runs as TrustedInstaller on the live system.

Packages

Packages ship components in a more manageable way. Packages refer to components. A package has a manifest that is similar to the component manifest, but in plain text XML with a MUM extension. They appear to use different parts of the same general schema. MUM files are signed via a catalog.

Package MUM files are stored in %SYSTEMROOT%\servicing\Packages. Derived data is stored in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing.

Unlike components, packages do not depend on one another but are owned (parented) by one another in a tree structure. Owned packages cannot be removed directly unless marked as standalone. However, ownership relations are not cryptographically signed in the registry once a package is installed. Therefore, with only administrator privilege, any subtree can be removed without breaking the ScanHealth integrity of the package tree (but potentially breaking the operating system.) This was implemented by install_wim_tweak.exe and CBSEnum, making arbitrary package removal possible. These tools simply delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\<package>\Owners\*, and then the package can be removed with DISM.

Windows Update

The built-in Windows Update can target any packages or introduce new packages. If a broken or missing package is targeted in the update, the update will fail and the whole update will be rolled back, without possibility to install a partial update or fixing the package.

Manual Package Update on Broken System

To update only applicable packages contained in an update, i.e. excluding broken or missing packages, all non-conflicting MUM files must be added with DISM /Add-Package. PSFExtractor may be used to extract those individual packages.

Other Observations

When DISM is used to service an offline image (i.e. not the current running system), it will execute the servicing stack inside the offline image. This can make debugging easier.
TrustedInstaller and TiWorker are children of svchost on the live system.
A breach was achieved in Windows 7, pending modern reproduction. It appears from this post that Windows did not verify the MUM signature to uninstall a package.