What is Windows Registry?
Windows registry is nothing but a system-defined, hierarchical database (data organized in a tree-like structure). It contains all the information, low-level settings, options, and other necessary values for software and hardware installed on the Windows Operating system. The Operating System (kernel) core, device drivers, windows services, SAM or security accounts manager, and user interfaces use the Registry. In addition, it allows access to the counter for profiling the computer performance. When an application or a program is installed, a new subkey containing setting such as program location, its current version, how to start that program, details about its execution, user preference, configuration, and all are added to the Windows Registry.
In other words, when a new program is installed, a new set of instructions, file references, and preferences are added to the Registry in a particular location for the programs for future interactions. It also refers to the file location, options to use the program, and more.
In the early days of Windows, the Windows Registry stored configuration information for Component Object Model(binary interface) based components. It was introduced with Windows 3.1, and its use extended to Windows 95 and NT. Windows 3.1 entirely relied on .ini files to store the windows programs and configurations settings. The .ini files take care of the configuration for various programs and are stored at multiple locations. Such as:
- .Net Framework applications use XML files for configurations.
- Standalone programs kept their configuration files with executable files.
The Windows registry, which is widely recognized today, was first employed in Windows 95. It simplified the storage initialization information and made the data more secure. The purpose of the Registry is to handle a system-wide data repository to replace the INI files.
Why Are INI Files Replaced With Registry?
The initialization (INI) files are text-based files. They are easy easily edited and modified with a text editor. Therefore they can be accessed easily and unauthorized. The INI files compel a decentralization of data. It does not have clear-cut rules for organizing the files and folders; therefore, there is a risk of data loss, duplication, and data corruption.
Hence it is more difficult to retrieve. Therefore it is easily tampering. Besides, the information is stored in a structured hierarchical way as a flat text. Therefore, the XML can easily handle and store complex data descriptions and the usability of INI files. Moreover, it cannot store more than 64 KB of data in a single entry. The restriction is due to the API function that reads and n returns the values from the file.
In the case of Registry, it is only subject to security policies; therefore, it can only be edited or manipulated through special registry editor tools and API functions. The size restrictions are not an issue in the Windows Registry. Recognizing the inherent problems with initialization (INI) files, Microsoft has developed the Windows 95 Registry.
.INI Files Vs. Windows Registry:
It is a unified database for storing the System and applications configuration data in a hierarchical format. Though the bracketed sections in INI files are similar to registry keys and the keyword information s, the Registry can have the name of the last user to the Active X components of the System. The Registry plays a vital role in automation and software components, active x controls, and servers, which have entries to describe them each. The class ID is a sequence of characters that are used in the Operating System to identify the components. Initialization (INI) files could not provide user-specific settings for individual users. But the Registry can store all application settings in multiple discrete files in a single logical repository in a homogeneous form.
- The file parsing can be done more quickly than the INI files.
- The strongly typed (stricter typing rules at compile time) data can be stored in the Registry than the text data stored in INI files.
- Windows registry allows multiple users to share the machine
- Allows less privileged users to work on the programs
- Backup and restoration simplified
- The Registry can be accessed over remote network connections
- You can edit the Registry with the application programming interface as a Remote Registry Service
- The firewall rules permit running the Remote Registry Service
- It is a database that allows the atomic transaction, which is an indivisible and irreducible series of database operations.
- If two processes attempt to write or update the same registry value simultaneously, one process setting will precede the other to maintain overall consistency.
- In INI files, the race condition or race hazard bug can result in inconsistent data. Still, the Windows Operating system does transactional updates to the Registry with the help of Kernel Transaction Manager.
Structure of Windows Registry:
We already know the Registry is a system-defined database that contains the critical data for the smooth running of Windows and the application and services of the operating System.
It contains two essential elements, namely keys and values. The registry keys are nothing but container objects similar to folders, and the values are non-container objects similar to files. It is structured in a tree format. Each node of the tree is termed as a key. Each key contains some values and or subkeys. Key referred with syntax similar to windows path names. It uses backslashes to indicate the levels of hierarchy. Keys have a case-insensitive name without backslashes.
Every now and then, the presence of a key is all the data that an application requires; at other times, an application opens a key and uses the values associated with the key.
The hierarchy of registry keys can be accessed from the known root key handle. The Root key is mapped to the content of a registry key preloaded by the kernel form the stored hive or the content of a subkey within another root key or mapped to register service or DLL, which provides access to its subkeys and values.
For Example:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
Here Windows is the subkey of Microsoft and Microsoft is the subkey of Software of the HKEY_LOCAL_MACHINE, which is the root key.
Generally, there are seven predefined root keys according to their constant handles, and they are in the Win32 API.
They are here as follows:
- HKEY_LOCAL_MACHINE or HKLM
- HKEY_CURRENT_CONFIG or HKCC
- HKEY_CLASSES_ROOT or HKCR
- HKEY_CURRENT_USER or HKCU
- HKEY_USERS or HKU
- HKEY_PERFORMANCE_DATA (in Windows NT, but not viewable in the Windows Registry Editor)
- HKEY_DYN_DATA (only in Windows 9x, can be visible in the Windows Registry Editor)
Like any other services and files in Windows, the registry keys also be restricted by ACLs of system resources. That depends on the user privileges, the security tokens acquired by the applications, or the system security policies enforced by the system administrators.
What are Windows Registry Values?
The key can have any number of values, and the values can be in any form. Each key has a specific name consisting of one or more printable characters. For example, a key can not include the backslash \. But value names and data can include the backslash character. In addition, it can use any other printable character. The Registry values are names or data pairs stored within the keys.
The registry values are referenced separately from the registry keys. Therefore, the windows API functions that query and manipulate the registry values and take value names separately from the key path that identifies the parent key.
A registry value can store data in different formats. When storing the data under registry value, namely the RegSetValueEx function, you need to specify one of the values to indicate the type of the data being stored. While retrieving the function RegQueryValueEx, use these values to indicate the type of data retrieved.
The key is similar to the associative array with 16-bit registry data in Windows 3. It contains one unnamed value or string. In a 32-bit registry, it is capable of creating multiple named values per key. Each registry key has a default value, whose name is the empty string. Each value can store arbitrary data with variable length and encoding associated with the symbolic type (numeric value) that defines how to parse the data.
Table:
| Registry Value | Type of Data |
| REG_BINARY | Any Arbitrary Data in Binary |
| REG_DWORD | Dword value – 32-bit number ( a number – between 0 and 4,294,967,295) |
| REG_DWORD_LITTLE_ENDIAN | Any 32-bit number in LE (little-endian format). |
| REG_DWORD_BIG_ENDIAN | Any 32-bit number in BE (big-endian format). |
| REG_EXPAND_SZ | It is a null-terminated string that contains unexpanded references to environment variables—usually stored and exposed in UTF-16LE. |
| REG_LINK | Null-terminated Unicode string. It contains the target path of a symbolic link that was created by calling the RegCreateKeyEx function with REG_OPTION_CREATE_LINK |
| REG_MULTI_SZ | It is a multi-string value, which is an ordered list of non-empty strings in Unicode. Each one is terminated by a null character, the list being customarily terminated by a second null character. |
| REG_NONE | None defined value type |
| REG_QWORD | Any 64-bit number (either big- or little-endian, or unspecified) |
| REG_QWORD_LITTLE_ENDIAN | It is a 64-bit number in little-endian format. This value is defined in the Windows header files. |
| REG_SZ | It is a null-terminated string in either a Unicode or an ANSI string. |
The above registry value types are defined in Winnt.h.
String Character:
The string may not have been stored with proper terminating null characters in the case of REG_SZ, REG_MULTI_SZ, or REG_EXPAND_SZ types. Therefore the string should have properly terminated to use it; if not, it may overwrite the buffer.
When we write a string to the Registry, we need to specify the length of the string, including the \0. The strlen function should not be used since it will not include the terminating null. For example, if you are using a stern, then the length of the string could be strlen( string ) + 1.
REG_MULTI_SZ string ends with a string of length 0. Hence we could not include a zero-length string in the sequence.
In a little-endian format, multi-byte value is stored in memory from the lowest byte to the highest value byte. The string 0x12345678 is stored as (0x78 0x56 0x34 0x12) in little-endian format.
In big-endian format, multi-byte value is stored in memory from the highest byte to the lowest value byte. The string 0x12345678 is stored as (0x12 0x34 0x56 0x78) in big-endian format.
Registry Element and Size Limit:
Each of the trees under My Computer is a key. For example, the HKEY_LOCAL_MACHINE key has the following subkeys: HARDWARE, SAM, SECURITY, SOFTWARE, and SYSTEM. And these keys, in turn, have many subkeys. Besides, each value consists of a value name and its associated data, if any. A registry tree can be 512 levels deep. You can create up to 32 levels simultaneously through a single registry API call.
Key Name: It can have a maximum of 255 characters. The key name includes the absolute path of the key in the Registry, starting from the bask key.
Example: HKEY_LOCAL_MACHINE.
Value Name: It can have 16,383 characters or ANSI characters or 16,383 Unicode characters.
Value: In standard format, 1MB, and in the latest systems, it can use the available memory
Registry Tree: A registry tree can have 512 levels deep. We can simultaneously create up to 32 levels through a single registry API call.
Long values more than 2048 bytes should be stored in a file, and the location of the long value file should be stored in the Registry. The file location can be the name of the value of the data of the value. Each \ character in the location string must be preceded by another \ as an escape character. The file location also can be the name of the key within the 255 character limit for key names, and it should not contain any of the not allowed characters such as \ in the key names.
Windows Registry Storage Space:
Some technical and practical guidelines are set for the System’s efficiency. Application programs can store configuration and initialization data in the Registry and store the other kind of data elsewhere. The data of more than one or two kilobytes should be stored as a file. It should be referred to by a key in the Registry instead of stored as a value. The executable binary codes should not be stored in the Registry. The value entered uses much lesser space than the key. Therefore to save space, the application should combine similar data together as a structure and store the structure as a value.
Predefined Keys or Root Keys:
An application should open a key before inputting data into the Registry. To open a key, it should supply a handle to another key in the Registry which is already open. The predefined keys of the System are always open. The predefined keys guide the application to navigate in the Registry and allow the Administrator to manipulate the data. All the applications that added data to the Registry should work within the framework of predefined keys.
Every application uses the handles to these keys as entry points to the Registry. And they are valid for all implementations to the Registry.
The following are handles to the predefined keys:
Handles and their Descriptions:
HKEY_CLASSES_ROOT: The HKCR key contains file name extensions association and COM class registration information such as programmatic identifiers, CLSIDs, and interface IDs. Generally, the class registration and file name extension data is stored under both HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER keys.
The HKEY_LOCAL_MACHINE\Software\Classes key has the default settings of all users on the local computer. The HKEY_CURRENT_USER\Software\Classes key contains the settings of the current interactive user.
HKCR is a compilation of user-oriented HKCU\Software\Classes and machine-based HKLM\Software\Classes. It allows either machine or user-specific registration of COM objects.
The HKEY_CLASSES_ROOT key gives a merged view of the Registry that merges the information from these two sources. The HKEY_CLASSES_ROOT also provides this merged view for all applications designed for previous Windows operating system versions. In addition, the RegOpenkeyEx and RegQueryValueEx allow us to specify the HKEY_CLASSES_ROOT key.
Note: The user-specific setting has much privilege and priority over the default setting.
The COM runtime ignores or overrides per user COM configuration and accesses only per machine COM configuration if the application is with the administrator rights and the user account is disabled. Therefore, the application that requires administrator rights should register dependent COM objects.
The Advantages of Per-user Class Registration:
The advantages of Per-user Class Registration are the following:
- First, multiple users can customize a single computer. For example, one user can install an application that uses a particular file type, and another user can install a different application that uses the same file type without affecting the first user.
- Roaming class registration is possible. Since the class registration is stored in the user profile, it can be loaded on each computer on which the profile is loaded. Therefore when the user logs on to a different computer system, the registration travels with the user profile through the directory and is written to the local portion of the System.
- It provided much more registry security. Now the class information is written to the user profile; the system administrator can limit the access to HKLM\SOFTWARE\Classes. Previously any user could manipulate the registry keys in HKLM\SOFTWARE\Classes, which could break the application or change its behavior.
Registry Hives:
A Registry hive is a logical group of keys, subkeys, and valves that have the supporting files loaded in the memory when the windows operating system is started or the user logs in. In other words, the branches of the Registry, which are actually stored in the memory disk as files, are termed hives. Few hives are volatile and are not stored on the disk at all. The hive records of HKLM\HARDWARE are created each time the system boots and detects the computer’s hardware. Individual user settings on a system are stored in files of a hive per user. Not all hives are loaded at any point of time. On booting, a minimal set of required hives are loaded. Once the System initializes, the user can log in and load the required application.
Whenever a new user logs on to the System, a new hive is created for that particular user with a separate file for that individual user profile. It is termed a user profile hive. The user profile hive has the specific registry information and his preference for the application settings, desktop environment, network connection, and other computer peripherals. User profile hives can be found under the HKEY_USERS key.
All the supporting files for the hives are in the %SystemRoot%\System32\Config directory. They are updated each and every time the user logs in. the file name extensions can indicate the type of data stored in the files.
Supporting files and Registry Hives:
- The File system such as System, System.alt, System.log, and System.sav are stored under the hive
- Default user files such as Default, Default.log, and Default.sav is stored under the registry hive HKEY_USERS\.DEFAULT.
- The SAM files such as Sam, Sam.log, and Sam.sav files are stored under the registry hive HKEY_LOCAL_MACHINE\SAM.
- Security files such as Security, Security.log, and Security.sav files are stored under the registry hive HKEY_LOCAL_MACHINE\Security.
- Software-related files, Software, Software.log, and Software.sav, are stored under the hive HKEY_LOCAL_MACHINE\Software.
- System files such as System, System.alt, System.log, and System.sav are under the hive HKEY_LOCAL_MACHINE\System.
- The current user files such as dat, Ntuser.dat, and .log are stored under the registry hive HKEY_CURRENT_USER.
Note: Before adding the data into the Registry, the application needs to divide the data into computer-specific data and user-specific data. By the distinctions of the data, the application can support more users. For example, the user-specific data can be over a network, or it may be in a different location, allowing independent user profile data.
Opening, Creating, and Closing Key:
An application must create or open a key to add data to the Registry. To do that, the application always refers to the key as a subkey of the currently open key. The following predefined keys are always open in the Registry:
- HKEY_LOCAL_MACHINE
- HKEY_CLASSES_ROOT
- HKEY_USERS
- HKEY_CURRENT_USER
The application opens the RegOpenKeyEx function to open a key and the RegCreateKeyEx function to create a key. Further, the RegCloseKey function to close the key. And it writes the data it contains into the Registry. The RegCloseKey need not necessarily write the data to the Registry before returning. It takes a few seconds for the cache to flush the hard disk. If an application needs to write the registry data to the hard disk, it can use the RegFlushKey function. Since RegFlushKey uses so many system resources, therefore it should be called only when it is absolutely necessary.
Writing and Deleting Registry Data:
Applications use the RegSetValueEx function to associate a value and its data with the key. To delete a registry value from a key, the application needs to use the RegDeleteValue function. The Subkeys and values cannot be created under a deleted key. To delete a key itself, it needs to use the RegDeleteKey function.
A deleted key is not removed until its last handle to it has been closed. You cannot lock a registry key during the write operation. However, you can use security attributes and control the access to the registry key. More than one registry operation can be performed with a single transaction. The application can use the RegCretedKeyTransacted or RegOpenKeyTransacted function with a transaction to associate a registry key.
Retrieving Data from the Registry:
- An application enumerates the subkeys to find a particular one and retrieves the data from values associated with it to retrieve the data.
- To do this, an application can call the RegEnumKeyEx function to enumerate the subkeys of a given key.
- RegQueryInfoKey function retrieves detailed data from a particular key.
- RegGetKeySecurity function retrieves a copy of the security descriptor protecting the key.
- RegEnumValue function enumerates the values of the given key.
- RegQueryValueEx function to retrieve the value for the key.
- The RegQueryMultipleValue function retrieves the data type for a list of value names related with an open registry key.
- The RegNotifyChangeKeyValue function is to notify the calling when there are changes to the attributes or contents of a registry key.
Registry Files:
Generally, applications can save part of the Registry in a file and then load the file’s content back into the Registry. When manipulating a large amount of data, the registry file is useful. The registry files have two formats, namely standard and latest. The Registry file is created in the process’s current directory for a local key and in the %systemroot%\system32 directory for a remote key.
Application Data in Registry:
On a 64-bit Windows Operating System, a part of registry entries are separately stored for 32-bit applications. They are mapped into separate logical registry views using the registry redirector and the registry reflection since both 64-bits and 32-bits use different registry keys and values.
They may also have shared registry keys that are not redirected or reflected. The parent of each registry node is the image-specific Node or ISN in 64- bits.
The registry redirector guides an application to access the appropriate ISN subnode. The WOW64 component automatically creates the Redirection subnodes in the registry tree. Therefore you need not name the registry key you created in WOW6432Node.
Registry Redirector:
The Registry Redirector isolates 64-bit and 32-bit applications. In addition, it provides separate logical views of certain portions of the Registry on WOW64.
It intercepts 64bits and 32-bit registry calls to their respective logical registry views and then maps them to the corresponding physical registry location. Hence the 32-bit application can access registry data as if it were running on 32-bit Windows even if the data is stored in different locations on a 64-bit System. The Registry Reflector is no longer in use.
User control Group Policies:
10 Group Policy settings can configure for User Account Control (UAC). The table lists the default for each of the policy settings. For example, the admin approval mode for the built-in administrator account can be controlled by the Admin Approval Mode of the built-in Administrator account policy setting by enabling or disabling it.
The user account control policy allows UIAccess applications prompt for the elevation without using the secure desktop policy setting control. It is because UIA programs are designed to interact with Windows and application programs on behalf of the Windows user. Generally, the policy setting allows the UIA programs to bypass the secure desktop to increase usability in some instances. However, allowing an interactive desktop instead a secure desktop can raise your security risk.
