Which of the main registry hives stores settings which are specific to the currently logged in user Windows Start menu Desktop etc )?

• The Registry

The Windows Registry is a hierarchical database that stores low-level settings for the Microsoft Windows operating system and for applications that opt to use the registry. The kernel, device drivers, services, Security Accounts Manager, and user interface can all use the registry. The registry also allows access to counters for profiling system performance.

In other words, the registry or Windows Registry contains information, settings, options, and other values for programs and hardware installed on all versions of Microsoft Windows operating systems. For example, when a program is installed, a new subkey containing settings such as a program’s location, its version, and how to start the program, are all added to the Windows Registry.

When introduced with Windows 3.1, the Windows Registry primarily stored configuration information for COM-based components. Windows 95 and Windows NT extended its use to rationalize and centralize the information in the profusion of INI files, which held the configurations for individual programs, and were stored at various locations. It is not a requirement for Windows applications to use the Windows Registry. For example, .NET Framework applications use XMLfiles for configuration, while portable applications usually keep their configuration files with their executables.

Prior to the Windows Registry, .INI files stored each program’s settings as a text file or binary file, often located in a shared location that did not provide user-specific settings in a multi-user scenario. By contrast, the Windows Registry stores all application settings in one logical repository (but a number of discrete files) and in a standardized form. According to Microsoft, this offers several advantages over

.INI files. Since file parsing is done much more efficiently with a binary format, it may be read from or written to more quickly than a text INI file. Furthermore, strongly typed data can be stored in the registry, as opposed to the text information stored in .INI files. This is a benefit when editing keys manually using regedit.exe, the built-in Windows Registry Editor. Because user-based registry settings are loaded from a user-specific path rather than from a read-only system location, the registry allows multiple users to share the same machine, and also allows programs to work for less privileged users. Backup and restoration is also simplified as the registry can be accessed over a network connection for remote management/support, including from scripts, using the standard set of APIs, as long as the Remote Registry service is running and firewall rules permit this.

Because the registry is a database, it offers improved system integrity with features such as atomic updates. If two processes attempt to update the same registry value at the same time, one process’s change will precede the other’s and the overall consistency of the data will be maintained. Where changes are made to .INI files, such race conditions can result in inconsistent data that does not match either attempted update. Windows Vista and later operating systems provide transactional updates to the registry by means of the Kernel Transaction Manager, extending the atomicity guarantees across multiple key and/or value changes, with traditional commit–abort semantics. (Note however that NTFS provides such support for the file system as well, so the same guarantees could, in theory, be obtained with traditional configuration files.)

Keys and values

The registry contains two basic elements: keys and values. Registry keys are container objects similar to folders. Registry values are non-container objects similar to files. Keys may contain values and subkeys. Keys are referenced with a syntax similar to Windows’ path names, using backslashes to indicate levels of hierarchy. Keys must have a case insensitive name without backslashes.

The hierarchy of registry keys can only be accessed from 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.

There are seven predefined root keys, traditionally named according to their constant handles defined in the Win32 API, or by synonymous abbreviations (depending on applications):

• 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 (only in Windows NT, but invisible in the Windows Registry Editor)
    • HKEY_DYN_DATA (only in Windows 9x, and visible in the Windows Registry Editor)

Like other files and services in Windows, all registry keys may be restricted by access control lists (ACLs), depending on user privileges, or on security tokens acquired by applications, or on system security policies enforced by the system (these restrictions may be predefined by the system itself, and configured by local system administrators or by domain administrators). Different users, programs, services or remote systems may only see some parts of the hierarchy or distinct hierarchies from the same root keys.

Registry values are name/data pairs stored within keys. Registry values are referenced separately from registry keys. Each registry value stored in a registry key has a unique name whose letter case is not significant. The Windows API functions that query and manipulate registry values take value names separately from the key path and/or handle that identifies the parent key. Registry values may contain

backslashes in their names, but doing so makes them difficult to distinguish from their key paths when using some legacy Windows Registry API functions (whose usage is deprecated in Win32).

The terminology is somewhat misleading, as each registry key is similar to an associative array, where standard terminology would refer to the name part of each registry value as a “key”. The terms are a holdout from the 16-bit registry in Windows 3, in which registry keys could not contain arbitrary name/data pairs, but rather contained only one unnamed value (which had to be a string). In this sense, the Windows 3 registry was like a single associative array, in which the keys (in the sense of both ‘registry key’ and ‘associative array key’) formed a hierarchy, and the registry values were all strings. When the 32-bit registry was created, so was the additional capability of creating multiple named values per key, and the meanings of the names were somewhat distorted. For compatibility with the previous behavior, each registry key may have a “default” value, whose name is the empty string.

Each value can store arbitrary data with variable length and encoding, but which is associated with a symbolic type (defined as a numeric constant) defining how to parse this data. The standard types are:

Table 3.1. List of Standard Registry value types

When an administrator runs the command regedit, pre-defined keys called root keys, high-level keys or HKEYS display in the left pane of the Registry Editor window. A pre-defined key and its nested subkeys are collectively called a hive.

An application must open a key before it can add data to the registry, so having pre-defined keys that are always open helps an application navigate the registry. Although pre-defined keys cannot be changed, subkeys can be modified or deleted as long as the user has permission to do so and the subkey is not located directly under a high-level key.

Before making any changes to registry keys, however, Microsoft strongly recommends the registry be backed up and that the end user only change values in the registry that they understand or have been told to change by a trusted advisor. Keys and subkeys are referred to with a syntax that’s similar to Windows’ path names, using backslashes to indicate levels in the hierarchy. Edits to the registry that cause syntax errors can make the computer inoperable.

Root keys

The keys at the root level of the hierarchical database are generally named by their Windows API definitions, which all begin “HKEY”. They are frequently abbreviated to a three- or four-letter short name starting with “HK” (e.g. HKCU and HKLM). Technically, they are predefined handles (with known constant values) to specific keys that are either maintained in memory, or stored in hive files stored in the local filesystem and loaded by the system kernel at boot time and then shared (with various access rights) between 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 registry is a hierarchical database where information is presented on a number of levels. Hive keys are on the first level. There are seven hive keys as we discussed previously. Registry keys are on the second level, subkeys are on the third and then come values. If we consider the registry in terms of a hierarchical file system.

The HKEY_LOCAL_MACHINE (local machine-specific configuration data) and HKEY_CURRENT_USER (user-specific configuration data) nodes have a similar structure to each other; user applications typically look up their settings by first checking for them in “HKEY_CURRENT_USER\Software\Vendor’s name\Application’s name\Version\Setting name”, and if the setting is not found, look instead in the same location under the HKEY_LOCAL_MACHINE key[citation needed]. However, the converse may apply for administrator-enforced policy settings where HKLM may take precedence over HKCU. The Windows Logo Program has specific requirements for where different types of user data may be stored, and that the concept of least privilege be followed so that administrator-level access is not required to use an application.

HKEY_CLASSES_ROOT (HKCR)

This key contains several subkeys with information about extensions of all registred file types and COM servers. This information is necessary for opening files with a double-click, or for drag-and-drop operations. Besides, the HKEY_CLASSES_ROOT key provides combined data to applications that were created for earlier versions of Windows.

HKEY_CURRENT_USER (HKCU)

This key store settings which are specific to the currently logged-in user (Windows Start menu, desktop, etc.). Its subkeys store information about environment variables, program groups, desktop settings, screen colors, network connections, printers and additional application settings. This information is gathered from the Security ID subkey (SID) of HKEY_USERS for the current user. In fact, this key stores all information related to the profile of the user who is currently working with Windows.

HKEY_LOCAL_MACHINE (HKLM)

Abbreviated HKLM, HKEY_LOCAL_MACHINE stores settings that are specific to the local computer.

The key located by HKLM is actually not stored on disk, but maintained in memory by the system kernel in order to map all the other subkeys. Applications cannot create any additional subkeys. On Windows NT, this key contains four subkeys, “SAM”, “SECURITY”, “SYSTEM”, and “SOFTWARE”, that  are  loaded  at  boot  time  within  their  respective  files  located  in  the  %SystemRoot

%\System32\config folder. A fifth subkey, “HARDWARE”, is volatile and is created dynamically, and as such is not stored in a file (it exposes a view of all the currently detected Plug-and-Play devices). On Windows Vista and above, a sixth and seventh subkey, “COMPONENTS” and “BCD”, are mapped in memory by the kernel on-demand and loaded from %SystemRoot%\system32\config\COMPONENTS or from boot configuration data, \boot\BCD on the system partition.

• The “HKLM\SAM” key usually appears as empty for most users (unless they are granted access by administrators of the local system or administrators of domains managing the local system). It is used to reference all “Security Accounts Manager” (SAM) databases for all domains into which the local system has been administratively authorized or configured (including the local domain of the running system, whose SAM database is stored in a subkey also named “SAM”: other subkeys will be created as needed, one for each supplementary domain). Each SAM database contains all builtin 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, a cryptographic hash of each user’s password for each enabled authentication protocol, 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.
• The “HKLM\SECURITY” key usually appears empty for most users (unless they are granted access by users with administrative privileges) and 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). The kernel will access it to read and enforce the security policy applicable to the current user and all applications or operations executed by this user. It also contains a “SAM” subkey which is dynamically linked to the SAM database of the domain onto which the current user logged on.

• The “HKLM\SYSTEM” key is normally only writable by users with administrative privileges on the local system. It contains information about the Windows system setup, data for the secure random number generator (RNG), the list of currently mounted devices containing a filesystem, several numbered “HKLM\SYSTEM\Control Sets” containing alternative configurations for system hardware drivers and services running on the local system (including the currently used one and a backup), a “HKLM\SYSTEM\Select” subkey containing the status of these Control Sets, and a “HKLM\SYSTEM\CurrentControlSet” which is dynamically linked at boot time to the Control Set which is currently used on the local system. Each configured Control Set contains:
  • an “Enum” subkey enumerating all known Plug-and-Play devices and associating them with installed system drivers (and storing the device-specific configurations of these drivers),
  • a “Services” subkey listing all installed system drivers (with non device-specific configuration, and the enumeration of devices for which they are instantiated) and all programs running as services (how and when they can be automatically started),
  • a “Control” subkey organizing the various hardware drivers and programs running as services and all other system-wide configuration,
  • a “Hardware Profiles” subkey enumerating the various profiles that have been tuned (each one with “System” or “Software” settings used to modify the default profile, either in system drivers and services or in the applications) as well as the “Hardware Profiles\Current” subkey which is dynamically linked to one of these profiles.

• The “HKLM\SOFTWARE” subkey contains software and Windows settings (in the default hardware profile). It is mostly modified by application and system installers. It is organized by software vendor (with a subkey for each), but also contains a “Windows” subkey for some settings of the Windows user interface, a “Classes” subkey containing 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), and a “Policies” subkey (also organized by vendor) for enforcing general usage policies on applications and system services (including the central certificates store used for authenticating, authorizing or disallowing remote systems or services running outside the local network domain).
• The “HKLM\SOFTWARE\Wow6432Node” key is used by 32-bit applications on a 64-bit Windows OS, and is equivalent to but separate from “HKLM\SOFTWARE”. The key path is transparently presented to 32-bit applications by WoW64 as HKLM\SOFTWARE (in a similar way that 32-bit applications see %SystemRoot%\Syswow64 as %SystemRoot%\System32)

HKEY_USERS (HKU)

While the HKEY_CURRENT_USER key stores the settings of the current user, this key stores Windows settings for all users. Its subkeys contain information about all user profiles, and one of the subkeys always corresponds to the HKEY_CURRENT_USER key (via the Security ID (SID) parameter of the user). Another subkey, HKEY_USERS\DEFAULT, stores information about system settings at the moment before the start of the current user session.

HKEY_CURRENT_CONFIG (HKCC)

This key store information about a hardware profile which is used by the local computer at system startup. Hardware profiles allow selecting drivers of supported devices for the specified session.

HKEY_PERFORMANCE_DATA

This key provides runtime information into performance data provided by either the NT kernel itself, or running system drivers, programs and services that provide performance data. This key is not stored in

any hive and not displayed in the Registry Editor, but it is visible through the registry functions in the Windows API, or in a simplified view via the Performance tab of the Task Manager (only for a few 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

This key is used only on Windows 95, Windows 98 and Windows ME. It contains information about hardware devices, including Plug and Play and network performance statistics. The information in this hive is also not stored on the hard drive. The Plug and Play information is gathered and configured at startup and is stored in memory.

• 3.1.2.   Automating Administrative Tasks – Windows Host Scripting

The Microsoft Windows Script Host (WSH) (formerly named Windows Scripting Host) is an automation technology for Microsoft Windows operating systems that provides scripting abilities comparable to batch files, but with a wider range of supported features. This tool was first provided on Windows 95 after Build 950a on the installation discs as an optional installation configurable and installable by means of the Control Panel. Windows Script Host is distributed and installed by default on Windows 98 and later versions of Windows. It is also installed if Internet Explorer 5 (or a later version) is installed. Beginning with Windows 2000, the Windows Script Host became available for use with user login scripts.

It is language-independent in that it can make use of different Active Scripting language engines. By default, it interprets and runs plain-text JScript (.JS & .JSE files) and VBScript (.VBS & .VBE files).

Users can install different scripting engines to enable them to script in other languages, for instance PerlScript. The language independent filename extension WSF can also be used. The advantage of the Windows Script File (.WSF) is that it allows multiple scripts (“jobs”) as well as a combination of scripting languages within a single file.

WSH engines include various implementations for the Rexx, BASIC, Perl, Ruby, Tcl, PHP, JavaScript, Delphi, Python, XSLT, and other languages.

Usage

Windows Script Host may be used for a variety of purposes, including logon scripts, administration and general automation. Microsoft describes it as an administration tool. WSH provides an environment for scripts to run – it invokes the appropriate script engine and provides a set of services and objects for the script to work with. These scripts may be run in GUI mode (WScript.exe) or command line mode (CScript.exe), or from a COM object (wshom.ocx), offering flexibility to the user for interactive or non-interactive scripts. Windows Management Instrumentation is also scriptable by this means.

The WSH, the engines, and related functionality are also listed as objects which can be accessed and scripted and queried by means of the VBA and Visual Studio object explorers and those for similar tools like the various script debuggers, e.g. Microsoft Script Debugger, and editors.

WSH implements an object model which exposes a set of Component Object Model (COM) interfaces. So in addition to ASP, IIS, Internet Explorer, CScript and WScript, the WSH can be used to automate and communicate with any Windows application with COM and other exposed objects, such as using PerlScript to query Microsoft Access by various means including various ODBC engines and SQL, ooRexxScript to create what are in effect Rexx macros in Microsoft Excel, Quattro Pro, Microsoft Word, Lotus Notes and any of the like, the XLNT script to get environment variables and print them in a new TextPad document, and so on.

The VBA functionality of Microsoft Office, Open Office (as well as Python and other installable macro languages) and Corel WordPerfect Office is separate from WSH engines although Outlook 97 uses VBScript rather than VBA as its macro language.

VBScript, JScript, and some third-party engines have the ability to create and execute scripts in an encoded format which prevents editing with a text editor; the file extensions for these encoded scripts is

.vbe and .jse and others of that type.

Unless otherwise specified, any WSH scripting engine can be used with the various Windows server software packages to provide CGI scripting. The current versions of the default WSH engines and all or most of the third party engines have socket abilities as well; as a CGI script or otherwise, PerlScript is the choice of many programmers for this purpose and the VBScript and various Rexx-based engines are also rated as sufficiently powerful in connectivity and text-processing abilities to also be useful. This

also goes for file access and processing—the earliest WSH engines for VBScript and JScript do not since the base language did not, whilst PerlScript, ooRexxScript, and the others have this from the beginning.

Any scripting language installed under Windows can be accessed by external means of PerlScript, PythonScript, VBScript and the other engines available can be used to access databases (Lotus Notes, Microsoft Access, Oracle Database, Paradox) and spreadsheets (Microsoft Excel, Lotus 1-2-3, Quattro Pro) and other tools like word processors, terminal emulators, command shells and so on. This can be accomplished by means of the WSH, so any language can be used if there is an installed engine.

Examples

The first example is very simple; it shows some VBScript which uses the root WSH COM object “WScript” to display a message with an ‘OK’ button. Upon launching this script the CScript or WScript engine would be called and the runtime environment provided. Content of a file hello0.vbs:

WSH programming can also use the JScript language. Content of a file hello1.js:

Or, code can be mixed in one WSF file, such as VBScript and JScript, or any other: Content of a file

hello2.wsf:

Security Concerns

Windows applications and processes may be automated using a script in Windows Script Host. Viruses and malware could be written to exploit this ability. Thus, some suggest disabling it for security reasons. Alternatively, antivirus programs may offer features to control .vbs and other scripts which run in the WSH environment.

Since version 5.6 of WSH, scripts can be digitally signed programmatically using the Scripting.Signer object in a script itself, provided a valid certificate is present on the system. Alternatively, the signcode tool from the Platform SDK, which has been extended to support WSH filetypes, may be used at the command line.

By using Software Restriction Policies introduced with Windows XP, a system may be configured to execute only those scripts which are stored in trusted locations, have a known MD5 hash, or have been digitally signed by a trusted publisher, thus preventing the execution of untrusted scripts.

Which Windows Registry hive stores information about the current hardware profile?

Which are the registry hives in Windows what do they contain?

Which registry hive stores security information for all local user accounts?

Which registry hive stores information about last user logon?