Exploring the Windows Registry Part 1,2,3

[Aerosol]

Exploring the Windows Registry Part 1

The Registry is a key component of the Windows operating system, and it's always been recommended that you should never careless run Registry Cleaners or start to change keys or delete keys which do not fully understand the purpose of. You never to seem to find much information about the Registry in general, unless it's in Specialist blogs or computer science papers. In this blog post I hope to show how to explore the Registry using WinDbg and look at some of the internal workings.

The Registry tends to be referred less commonly as the Configuration Manager, and the Configuration Manager is the technical name for it. As the name suggests, the Configuration Manager mainly maintains the state of the configuration data for the operating system and any programs which may have been installed. The Registry is divided into several sections called Rootkeys. The Rootkeys are defined as follows:

HKEY_LOCAL_MACHINE

HKEY_CURRENT_CONFIG

HKEY_CLASSES_ROOT

HKEY_CURRENT_USER

HKEY_PERFORMANCE_DATA

HKEY_USERS

Each Rootkey has a number of Hives which are subdivided into Keys and Values. This can be seen when viewing the Registry with the Registry Editor.

Configuration Data), COMPONENTS, HARDWARE, SAM, SECURITY, SOFTWARE and SYSTEM. Any changes here will apply to the entire system.

The HKEY_CURRENT_CONFIG contains information relating to Hardware Profiles, which enables configuration driver settings. A Hardware Profile may change from boot to boot, and will be used by any programs which require it.

The HKEY_CLASSES_ROOT contains information for file extension associations, COM Class reregistration and UAC (User Account Control).

The HKEY_CURRENT_USER contains the configuration data regarding the locally logged on user. The Root Key is mapped to the Ntuser.dat file which is present on the hard drive. Some of the local configuration data examples include: Environment Variables, Network Settings, Software Settings and Session Information.

The HKEY_USERS contains data required each loaded user profile, and will be used by Winlogin to implement any specific user changes. This section will also contain keys relating to user security identifiers for that profile.

The HKEY_PERFORMANCE_DATA contains operating system and server performance counters, and will not be visible through the Registry Editor. These performance counters are only available through the Windows Registry API.

The HKEY is used to represent a handle to the rootkey. Now we have looked at the general logical structure of the Windows Registry, will need to examine it's actual implementation onto the hard disk. This is achieved through the concept of Hives, Cells and Bins. It is possible to be examine to parts of the Registry in Physical Memory.

The structure of a Configuration Manager Hive can be seen with WinDbg using the _CMHIVE data structure. It's a large data structure, and therefore I have omitted some of the fields.

The above data structure contains a larger sub structure called _HHIVE, which contains some very useful information. The _CMHIVE structure is allocated from paged pool, and has the pool tag of CM10. You can view this pool allocation information with !pooltag and !poolfin

Using the !poolfind extension with the pooltag and specifying the pool type as paged pool with the 1 switch, we can see all the pool allocations for that specific pool tag

A Hive is simply the on disk representation of the Registry, each one of these has it's own registry tree which serves as a root. The hives are then loads the Hives which can be found HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\hivelist. These Hives are stored on the hard disk, and are then linked to the Registry file paths as seen below. Most of the hives reside in the System32 folder, whereas, the others will reside in the UserProfiles and Users folder.

Alternatively, we can view the Hivelist within WinDbg using the !reg hivelist extension. You may have noticed that the HARDWARE hive not does have a folder path, this is because it is updated every time the computer is booted, and therefore is only present within memory.

We can even view the current paged pool consumption of the Registry Hives using the !reg dumppool extension. Again I've had to omit some information due to the size limitations.

Using Process Explorer, and then selecting the System process, we can view the Hive Handles which are currently opened by the System Process.

Going back to the general structure of how Hives are organized, Hives are linked together within a doubly linked list, the Head of this linked list can be found with WinDbg, the address is 8336e44c on x86, I'm sure if there is any difference on x64.

We can also see this with the _CMHIVE structure and the HiveList field. The addresses within the linked list are all virtual addresses

In the second part I have be taking a closer look at the structure of Hives and some more forensic analysis techniques.

Source : BSODTutorials: Exploring the Windows Registry Part 1

Exploring the Windows Registry Part 2

Each Hive is divided into a number of allocation units called Blocks, the first block of a Hive is called the Base Block. The information which is stored within a Hive is then organized into Cells which contain active registry data such as keys, values, security descriptors and subkeys.

The Hive Blocks are allocated in 4096 byte allocation sizes, and are called Hive Bins. The Base Block may also be referred to as the Registry Header, with the other blocks being called Hive Bins. Each Hive Bin is then divided further into Cells as explained above.

A Hive Bin will have the hbin signature which can be found with WinDbg. Firstly, use the !reg hivelist extension, and then use the !reg viewlist extension with a desired Hive Address.

The !reg viewlist extension will list the Mapped Views for the selected Hive. I wasn't able to find a dump file which had any mapped views, therefore I won't be able to show you the steps completely. Once you have used the !reg viewlist extension, then use the db command with a desired view to view the contents of a bin.

The _HHIVE data structure seems to contain a Signature field and BaseBlock field as described earlier. Each Hive Bin contains a pointer to the next Hive Bin and the first Hive Bin. We can find free Hive Bins with the !reg freebins extension and the Hive address.

These Hive Bins are only really containers for Cells which hold registry information such as keys, security descriptors, subkey lists and key values. There a few different types of Cells:

Key Cell

Value Cell

Subkey-list Cell

Value-list Cell

Security-Descriptor Cell

The Key Cell contains the registry key and may be called the Key Node. A Key Cell will contain the kn signature for Keys and kl for Link Nodes. Furthermore, the Key Cell will maintain timestamp information about the latest update to that key, and various Cell Indexes which will describe additional information.

The Value Cell contains information about the key's value, and will have a Cell Index into what the cell which contains such data about the key. The signature will be kv.

The Subkey-List Cell contains a list of Cell Indexes for Key Cells in which all share a common Parent Key.

The Value-List Cell is the same as above, but applies to Value Cells rather than Key Cells.

The Security Descriptor Cell will contain the ks signature and a reference count which maintains a count of the number of Key Nodes or Key Cells which share the Security Descriptor. This cell will contain a Security Descriptor.

We can view Cell data structures with the _CM_CELL_DATA and then using the -r switch to dump all the hidden sub data structures. The -r switch is really useful for data structures in general, especially since Microsoft won't document some sub fields fully.

Since we are the topic of keys, I thought it would be appropriate to look at the concept of Keys and how we can investigate into Keys further with WinDbg. We can firstly use the !reg openkeys extension, and then view any open keys. Please note that I've omitted the output of the extension to one Hive.

However, we can gather more interesting information by looking into a few data structures. Each key will have a Key Control Block (KCB), we can use the _CM_KEY_CONTROL_BLOCK data structure to view the information about the open key.

This is similar information to which can be found with the !reg kcb extension, you will need to use the !reg findkcb extension with the full registry path, in order to find the kcb address. However, with the open keys case, you can simply use the !reg kcb extension since the KCB address is already given.

The Configuration Manager maintains open keys within a table for fast name lookups, the table can be found with two global variables called CmpCacheTable and CmpHashTableSize. The CmpCacheTable is a pointer to a hash table which explains the _CM_KEY_HASH data structure within the KCB.

Each entry within the table is a pointer to the _CM_KEY_HASH data structure.

The NextHash field points to the next structure within the table.

Source: link

Exploring the Windows Registery Part 3

Cells are containers for information, such as keys, thus the reason for the different type of cells explained in the last post. In order to make the logical structure of the registry clearer, it's important for me to state how all the different parts I've been discussing fit together to form one complete picture of the Windows Registry.

Hives are split into Bins, and the Bins are then split into Cells. A Empty Bin will not contain any cells, whereas, a Bin with Cells will obviously contains Cells which will contain registry data. This brings around the point about Cell Indexes and Cell Mappings, and some of the data structures will can explore with WinDbg.

Cell Indexes are essentially pointers which link cells from different hives together, to make easier and more efficient for the Configuration Manager to load information which it is searching for. More specifically, the Cell Index is a offset into the cell with the subtraction of the size of the base block for the selected hive.

The tables which the Cell Indexes are used to index into, can be found within the Storage.Map member of the _DUAL data structure of the appropriate _HHIVE data structure. We can expand the _DUAL data structure and examine this member.

The _HMAP_DIRECTORY is a array of pointers to table entries, which then contain the information for a specific Block and Bin. The FreeDisplay field is used to for free cells within memory.

Since Hives are allocated from Paged Pool, they will need to be mapped since paged pool isn't guaranteed to be contiguous. This leads to the concept of Cell Index Mapping, which is very much the same as Virtual Address Translation on x86 systems; remember that x64 had a additional table of directory pointers.

Using the diagram above, it may become more apparent what the pointers within the mentioned data structures are being used to index into. As we can see, the Directory Index pointer is being used to point to the Hive Cell Map Directory, which is then used to point to the Cell Map Table with a Table Index pointer, and then the Byte Offset is used to point to the specific Cell within the Hive Block.

There is a additional bit which is either 0 or 1, and is used to determine if the Hive is Volatile or Stable, and which table type to begin searching with. This translation is used for Hives in memory. 1 is Volatile and 0 is Stable.

Directory Index = 10 bits

Table Index = 9 bits

Byte Offset = 12 bits

Since Hives usually reside on the hard disk, and are then mapped into memory, in order to avoid excessive consumption of the Cache Manager's address space. The number of mapped views for a hive is limited to 256 views. The LRU (Least Recently Used) views list is consulted when this has been reached, and when a new mapping is required because the Configuration Manager requires a hive to be mapped into memory. The LRU mapping will be removed from the list. This data structure is allocated with Paged Pool.

There is some interesting WinDbg extensions we can use to find additional information related to Cell Indexes such as the !reg cellindex extension.

The extension shows the virtual address associated with the Cell Index. The first address is the Hive Address and the 40 is the offset which we are looking for. I've used the SYSTEM hive in this example.

Source: link