To most users the Windows registry is a tree of keys and values edited through regedit. To the kernel it is something more specific: a set of on-disk database files called hives, managed by an executive component known as the Configuration Manager (its routines are prefixed Cm). The Configuration Manager loads hives, maps them into memory, resolves key paths, enforces security, and keeps the files crash-consistent. Understanding that machinery explains a great deal — why the SAM database can be dumped offline, why certain keys are persistence goldmines, and why registry ACLs are a privilege-escalation surface. This article dissects the registry from the file format up.
Hives: The On-Disk Files
A hive is simply a file that contains a subtree of the registry. The machine-wide system hives live in C:\Windows\System32\config:
- SYSTEM — hardware, drivers, services, and control sets.
- SOFTWARE — installed software and machine-wide settings.
- SAM — the Security Account Manager database: local user accounts and their password hashes.
- SECURITY — the local security policy and LSA secrets.
- DEFAULT — the default user profile.
Each user also has per-profile hives: NTUSER.DAT (loaded as that user’s HKCU) and UsrClass.dat (per-user class registrations), stored in the user’s profile directory. The logical root keys map onto these files: HKLM and HKU are backed directly by hives, while HKCU, HKCC, and HKCR are links or derived views rather than standalone files.
The Registry Namespace vs Hives
The familiar HKEY_* roots are a user-mode convenience. HKLM\SYSTEM is the SYSTEM hive, HKLM\SAM is the SAM hive, HKLM\SECURITY is the SECURITY hive, and so on. HKCR is not a hive at all — it is a runtime merge of HKLM\Software\Classes (machine-wide) and HKCU\Software\Classes (per-user), with the per-user entries taking precedence. HKCU is a link to the current user’s subtree under HKU.
Inside the kernel object namespace, the entire registry is rooted at \REGISTRY, with \REGISTRY\MACHINE corresponding to HKLM and \REGISTRY\USER to HKU. This is why the registry is reachable through the same Object Manager machinery as files and devices: the Key object type has a parse method that the Configuration Manager supplies.
Hive Structure: Bins and Cells
A hive file begins with a base block (the header, signature regf) followed by the data, which is divided into hive bins (each with an hbin signature). Bins are aligned on 4KB boundaries and act as the allocation granularity from disk. Within a bin, storage is subdivided into cells, and each cell holds exactly one structure. The cell types are identified by a two-character signature:
nk— a key node (CM_KEY_NODE), representing one registry key.vk— a value (CM_KEY_VALUE), representing one named value.sk— a security cell (CM_KEY_SECURITY), holding a security descriptor shared by keys that have identical permissions.lf,lh,li,ri— subkey lists (variants optimized for different sizes and with name hashes).
Cells reference one another by cell index — an offset into the hive that the Configuration Manager treats like a pointer. Because everything is offset-based rather than using absolute memory addresses, a hive is fully relocatable: it can be written to disk, copied, and mapped anywhere in memory without fixing up internal references. This self-contained design is exactly what makes offline registry forensics possible.
Key Nodes and Values
The CM_KEY_NODE (nk cell) is the heart of the format. It stores the key’s name, its LastWriteTime timestamp, and cell indexes pointing to its subkey list, its value list, and its security (sk) cell. Walking from a key node to its subkey list, and from there to child nk cells, is how the tree is traversed; that LastWriteTime is a valuable forensic artifact because it records when a key was last modified.
A CM_KEY_VALUE (vk cell) describes a single value: its name, its data type, and either its data or a cell index to it. The common data types are REG_SZ (string), REG_EXPAND_SZ (string with environment variables), REG_DWORD (32-bit integer), REG_QWORD (64-bit), REG_BINARY (raw bytes), and REG_MULTI_SZ (a list of strings). As an optimization, small values (four bytes or fewer, such as a REG_DWORD) can be stored inline in the value cell itself rather than in a separate data cell.
The Configuration Manager, Key Objects, and Caching
When code opens a registry key, the Object Manager (using the Key type’s parse method) and the Configuration Manager cooperate to create a Key object. The body of that object references a Key Control Block (KCB) — an in-memory descriptor for the open key. Because programs open the same hot keys constantly, the Configuration Manager maintains a hash table of KCBs and reuses them, so repeatedly opening a popular key does not re-parse the hive each time.
Hives are not read one record at a time from disk; the Configuration Manager maps hive data into kernel memory (backed by paged pool and mapped views) so that key and value lookups are ordinary memory reads against the cell structures. This mapping is why a loaded hive consumes memory and why registry access is fast once a hive is loaded.
Transactions and Logs: Hive Recovery
Because a hive is a database that must survive a crash or power loss mid-write, the Configuration Manager does not modify the primary hive file directly and hope for the best. Modified (dirty) hive pages are first recorded in log files — you will see SYSTEM.LOG1 and SYSTEM.LOG2 alongside the hive — and flushed on a schedule. If the system crashes before a clean flush completes, on the next boot the Configuration Manager replays the log to bring the hive back to a consistent state. This write-ahead logging is invisible in normal operation but is the reason the registry rarely corrupts, and it is why forensic tools that parse hives must sometimes replay transaction logs to recover the most recent changes.
Inspecting the Registry
The registry can be examined both from the kernel debugger and from ordinary command-line tools:
# --- WinDbg (kernel mode) ---
# List every loaded hive and its base block address
!reg hivelist
# Show currently open keys (KCBs)
!reg openkeys
# Query a key by its \REGISTRY namespace path
!reg querykey \REGISTRY\MACHINE\SYSTEM\CurrentControlSet\Services
# --- User mode ---
# Read a value
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v ProductName
# Save a live hive to a file (needs the right privileges)
reg save HKLM\SAM C:\temp\sam.hive
reg save HKLM\SYSTEM C:\temp\system.hive!reg hivelist ties each logical hive to its in-memory structures; !reg querykey lets you walk the tree by its \REGISTRY path. On a live host, reg save writes a hive out in its native format — which, as the next section explains, is exactly what credential-dumping workflows rely on.
Security Relevance
The registry is one of the most security-relevant subsystems in Windows, for several reasons:
- Offline credential extraction. The
SAMhive holds local account password hashes and theSECURITYhive holds LSA secrets and cached domain credentials — but both are encrypted with a key (the “boot key” or SysKey) derived from theSYSTEMhive. An attacker who can copySAM+SYSTEM(orSECURITY+SYSTEM) can decrypt them offline with tools like secretsdump. This is why access to these hive files is equivalent to access to the credentials in them. - Persistence (ASEPs). Dozens of registry keys are Auto-Start Extensibility Points —
Run,RunOnce, services,Winlogonentries, image file execution options, and more. Attackers write here to survive reboots; defenders enumerate them with tools like Autoruns. - Weak key ACLs. Registry keys are securable objects with DACLs. A service configuration key or an ASEP key that is writable by an unprivileged user is a direct privilege-escalation path — modify what a SYSTEM service loads and you inherit its context.
- Privileged hive access. Even when the live SAM is locked, an attacker with
SeBackupPrivilegeor the ability to create a Volume Shadow Copy can read the hive files out from under the lock. Guarding these privileges matters as much as guarding the files.
Everything here is framed for defensive understanding and authorized testing: knowing how hives store credentials and how ACLs gate them is what lets defenders lock the surface down and spot abuse.
Conclusion
The registry is a memory-mapped, log-protected database of cells and hive bins that the Configuration Manager exposes as the familiar key/value tree. Its offset-based, self-contained format is what makes hives portable — and what makes offline credential extraction and forensic timelining possible. Its ACLs and autostart keys make it a front line for both persistence and privilege escalation. Having seen how configuration is stored, the next article turns to one of the registry’s biggest consumers and a security-critical subsystem in its own right: Windows services and the Service Control Manager.
You Might Also Like
This article is part of the Windows Internals series. These related deep-dives cover adjacent parts of the system:
Comments