Windows Registry Structure: Understanding Keys, Values, and Hives in Windows Registry

On Microsoft Windows operating systems, the Windows Registry is a hierarchical database that holds configuration settings and options. It includes settings for both low-level operating system components and programmes running on the platform: the registry is used by the kernel, device drivers, services, SAM, user interface, and third-party applications. The registry also allows you to access counters for system performance profiling.

The registry contains two basic elements: Keys and Values. Then there is also the concept of Hives. We’ll be exploring these in this blog post.

Registry Keys

Each key can have subkeys, which can contain further subkeys, and so on. Registry keys are similar to folders in that they can contain values as well as subkeys. Keys are addressed using a syntax similar to that of Windows path names, with backslashes used to signify hierarchy levels. Each subkey must have a name, which must be a non-empty string that does not contain any backslashes or null characters and is case insensitive.

Only a known root key handle (which is anonymous but whose effective value is a constant numeric handle) that is mapped to the content of a registry key preloaded by the kernel from a stored “hive,” or to the content of a subkey within another root key, or mapped to a registered service or DLL that provides access to its contained subkeys and values can access the registry key hierarchy.

HKEY_LOCAL_MACHINE Software Microsoft Windows refers to the subkey “Windows” of the subkey “Microsoft” of the subkey “Software” of the HKEY_LOCAL_MACHINE root key.

There are seven predefined root keys:

All registry keys may be controlled by access control lists (ACLs) based on user privileges, security tokens acquired by apps, or system security policies imposed by the system, just like other files and services in Windows. (These limitations may be set by the system and configured by local system administrators or domain administrators.) Users, programmes, services, and remote systems may only see certain parts of the hierarchy or different hierarchies from the same root keys.

HKEY_LOCAL_MACHINE (HKLM)

The key indicated by HKLM is not saved on disc, but rather in memory by the system kernel, which uses it to map all other subkeys. Additional subkeys cannot be created by applications. This key has four subkeys, “SAM”, “SECURITY”, “SYSTEM”, and “SOFTWARE”, which are loaded at boot time within their respective files in the %SystemRoot%System32config folder on NT-based versions of Windows. The fifth subkey, “HARDWARE,” is volatile and dynamically formed, thus it is not saved in a file (it exposes a view of all the currently detected Plug-and-Play devices). The kernel maps the sixth subkey in memory and populates it with boot configuration data (BCD) for Windows Vista, Windows Server 2008, Windows Server 2008 R2, and Windows 7.

HKLMSAM Key

For most users, this key seems to be empty (unless they are granted access by administrators of the local system or administrators of domains man- aging the local system). It’s used to refer to all “Security and Accounts Management” (SAM) databases for all domains into which the local system has been administratively authorised or configured (including the running system’s local domain, which has a subkey named “SAM” in its SAM database; additional subkeys will be created as needed, one for each supplementary domain).

Each SAM database contains all built-in accounts (mostly group aliases) and configured accounts (users, groups and their aliases, including guest accounts and administrator accounts) created and configured on the respective domain, for each account in that domain, it notably contains the user name which can be used to log on that domain, the internal unique user identifier in the domain, their cryptographically hashed password on that domain, the location of storage of their user registry hive, various status flags (for example if the account can be enumerated and be visible in the logon prompt screen), and the list of domains (including the local domain) into which the account was configured.

HKLMSECURITY Key

This key is linked to the Security database of the domain into which the current user is logged on (if the user is logged on the local system domain, this key will be linked to the registry hive stored by the local machine and managed by local system administrators or by the builtin “System” account and Windows installers). It is usually empty for most users (unless they are granted access by users with administrative privileges). The kernel will utilise it to read and enforce the security policy that applies to the cur- rent user and all of their programmes and operations. It also has a “SAM” subkey that is dynamically linked to the domain’s SAM database, where the current user is logged on.

HKLMSYSTEM Key

Users with administrative access on the local system are usually the only ones who may write to this key. It contains data for the secure random number generator (RNG), a list of currently mounted devices with a file system, several numbered “HKLMSYSTEMControl Sets” containing alter- native configurations for system hardware drivers and services running on the local system (including the currently used one and a backup), a “HKLMSYSTEMSelect” subkey containing the status of these Control Sets, and a “HKLMSYSTEMCurrentControlSelect” subkey containing the status of these Control is dynamically linked at boot time to the Control Set which is currently used on the local system.

Each configured Control Set contains:

HKLMSOFTWARE Subkey

The software and Windows settings are stored on this key (in the default hardware profile). The majority of changes are made by application and system installers. It’s organised by the software vendor (with subkeys for each), but it also has a “Windows” subkey for some Windows user inter- face settings, a “Classes” subkey for all registered associations from file extensions, MIME types, Object Classes IDs, and interfaces IDs (for OLE, COM/DCOM, and ActiveX) to the installed applications or DLLs that may be handling these types on the local machine (however, these associations are configurable for each user, see below (including the central certificates store used for authenticating, authorising or disallowing remote systems or services running outside of the local network domain).

HKEY_CURRENT_CONFIG (HKCC)

This key stores information obtained during runtime; data in this key is not permanently kept on disc, but is regenerated at boot time. It’s a handle to the key “HKEY LOCAL MACHINESystemCurrentControlSetHardware ProfilesCurrent,” which is empty at first but is filled in at boot time by loading one of the other subkeys in “HKEY LOCAL MACHINESystemCur- rentControlSetHardware Profiles.”

HKEY_CLASSES_ROOT (HKCR)

This key stores information about registered programmes, including as file associations and OLE Object Class IDs, and links them to the applications that deal with them. HKCR is a collection of user-based HKCUSoftware- Classes and machine-based HKLMSoftwareClasses on Windows 2000 and later. If the same value appears in both subkeys, the one in HKCUSoftware- Classes takes precedence. The design allows COM objects to be registered by either the machine or the user. Unlike the HKCU hive, the user-specific classes hive is not part of a roaming user profile.

HKEY_USERS (HKU)

User hives are normally only loaded for presently logged-in users and contain subkeys matching to the HKEY CURRENT USER keys for each user profile actively loaded on the PC.

HKEY_CURRENT_USER (HKCU)

This key contains parameters specific to the user who is presently logged in. The HKCU key is a link to the HKEY USERS subkey that belongs to the user; both places have the identical information. Each user’s settings are stored in their own NTUSER.DAT and USRCLASS.DAT files under their own Documents and Settings subdirectory on Windows NT-based systems (or their own Users sub folder in Windows Vista and Windows 7). This hive’s settings are carried across from machine to machine by users with a roaming profile.

HKEY_PERFORMANCE_DATA

This key enables access to performance data provided by the NT kernel or by operating system drivers, programmes, and services that offer performance statistics. This key is not stored in any hive and is not visible in the Registry Editor, but it can be accessed via the Windows API registry functions, or in a simplified view via the Task Manager’s Performance tab (for a limited set of performance data on the local system), or via more advanced control panels (such as the Performances Monitor or the Performances Analyzer which allows collecting and logging these data, including from remote systems).

HKEY_DYN_DATA

Only Windows 95, Windows 98, and Windows Me supported this key. It includes Plug & Play and network performance statistics, as well as information about hardware devices. The data in this hive isn’t saved on the hard drive either. At launch, the Plug and Play information is gathered and configured, then saved in memory.

Values

Name/data pairs are kept as registry values in keys. The terms registry values and registry keys are not interchangeable. In a registry key, each registry value has its own name, regardless of letter case. The Windows API functions that query and update registry information isolate the value names from the key path and/or handle that identifies the parent key. Registry variables with backslashes in their names make it harder to distinguish them from their key paths when using numerous legacy Windows Registry API actions (whose usage is deprecated in Win32).

Although each registry key is similar to an associative array, the name portion of each registry value is referred to as a “key” in standard parlance. The phrases are a relic from the 16-bit registry of Windows 3, which per- mitted registry keys to have only one unnamed value rather than arbitrary name/data combinations (which had to be a string). The registry was treated as a single associative array, with a hierarchy of registry keys (in both the registry and dictionary senses) and all registry values being strings. When the 32-bit registry was introduced, it also contained the ability to create several named values per key, which changed the semantics of the names. To retain compatibility with earlier behaviour, each registry key may have a “default” value, which is the empty string.

Each value can have any sort of data, regardless of length or encoding, as well as a symbolic type (given as a numeric constant) that indicates how to read it.

The standard types are:

Hives

The Registry is divided into several logical divisions, or “hives” (the word hive constitutes an in-joke). Hives are named after their Windows API definitions, which all start with “HKEY.” They are usually abbreviated to a three- or four-letter abbreviation that begins with “HK” (e.g. HKCU and HKLM). They are predefined handles (with known constant values) to specific keys that are either maintained in memory, stored in hive files stored in the local file system and loaded by the system kernel at boot time and then shared (with various access rights) among all processes running on the local system, or loaded and mapped in all processes started in a user session when the user logs on the system.

The HKEY LOCAL MACHINE (local machine-specific configuration data) and HKEY CURRENT USER (user-specific configuration data) nodes are similar in structure; user applications typically look up their settings by first looking in “HKEY CURRENT USER Software Vendor’s name Application’s name VersionSetting name,” and if that doesn’t work, look in the same location under the HKEY LOCAL MACHINE key. The opposite may be true for administrator-enforced policy settings, where HKLM may take precedence over HKCU. The Windows Logo Program includes precise standards for where different sorts of user data can be stored, as well as following the principle of least privilege so that administrator-level access is not necessary to utilise an application.

We hope that this series takes away the fear that people generally have when they are dealing with the Windows Registry. If you figure out any interesting hacks, please feel free to let us know. We might add more more hacks. Thanks for reading this post. Please share this post and help secure the digital world. Visit our website, thesecmaster.com, and our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium, and Instagram and subscribe to receive updates like this.  

You may also like these articles: