Windows Internals covering windows server 2008 and windows vista- P6

240 Although hotpatches utilize internal kernel mechanisms, their actual implementation is no different from coldpatches. The patch is delivered through Windows Update, typically as an executable file containing a program called Update.exe that will perform the extraction of the patch and the update process. For hotpatches, however, an additional hotpatch file, containing the .hp extension, will be present. This file contains a special PE header called .HOT1. This header will contain a data structure describing the various patch descriptors present inside the file. Each of these descriptors identifies the offset in the original file that needs to be patched, a validation mechanism (which can include a simple comparison of the old data, a checksum, or a hash), and the new data to be patched. The kernel will parse these descriptors and apply the appropriate modifications. In the case of a protected process (see Chapter 5 for more information on processes) and other digitally signed images, the hotpatch must also be digitally signed, in order to prevent “fake” patches from being performed to sensitive files or processes. Note Because the hotpatch file also includes the original data, the hotpatching mechanism can also be used to uninstall a patch at run time. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 241 Compile-time hotpatching support works by adding 7 dummy bytes to the beginning of each function—4 are considered part of the end of the previous function, and 2 are part of the function prolog; that is, the function’s beginning. Here’s an example of a function that was built with hotpatching information: 1. lkd> u NtCreateFile - 5 2. nt!FsRtlTeardownPerFileContexts+0x169: 3. 82227ea5 90 nop 4. 82227ea6 90 nop 5. 82227ea7 90 nop 6. 82227ea8 90 nop 7. 82227ea9 90 nop 8. nt!NtCreateFile: 9. 82227eaa 8bff mov edi,edi Notice that the five nop instructions don’t actually do anything, while the mov edi, edi at the beginning of the NtCreateFile function are also essentially meaningless—no actual statechanging operation takes place. Because 7 bytes are available, the NtCreateFile prologue can be transformed into a short jump to the buffer of five instructions available, which are then converted to a near jump instruction to the patched routine. Here’s NtCreateFile after having been hotpatched: 1. lkd> u NtCreateFile - 5 2. nt!FsRtlTeardownPerFileContexts+0x169: 3. 82227ea5 e93d020010 jmp nt_patch!NtCreateFile (922280e7) 4. nt!NtCreateFile: 5. 82227ea5 ebfc jmp nt!FsRtlTeardownPerFileContexts+0x169 (82227ea5) This method allows only the addition of 2 bytes to each function by jumping into the previous function’s alignment padding that it would most likely have at its end anyway. There are some limitations to the hotpatching functionality: ■ Patches that third-party applications such as security software might block or that might be incompatible with the operation of third-party applications ■ Patches that modify a file’s export table or import table ■ Patches that change data structures, fix infinite loops, or contain inline assembly code 3.14 Kernel Patch Protection Some 32-bit device drivers modify the behavior of Windows in unsupported ways. For example, they patch the system call table to intercept system calls or patch the kernel image in memory to add functionality to specific internal functions. To prevent these kinds of changes, Windows implements Kernel Patch Protection (KPP), also referred to as PatchGuard. KPP’s job on the system is similar to what its name implies—it Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 242 attempts to deter common techniques for patching the system, or hooking it. Table 3-25 lists which components or structures are protected and for what purpose. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 243 Note Because certain 64-bit Intel processors implement a slightly different feature set of the x64 architecture, the kernel needs to perform run-time code patching to work around the lack of a prefetch instruction. KPP can deter kernel patching even on these processors, by exempting those specific patches from detection. Additionally, because of hypervisor (Hyper-V) enlightenments (more information on the hypervisor is provided earlier in this chapter), certain functions in the kernel are patched at boot time, such as the swap context routine. These patches are also allowed by very explicit checks to make sure they are known patches to the hypervisorenlightened versions. When KPP detects a change in any of the structures mentioned (as well as some other internal consistency checks), it crashes the system with code 0x109—CRITICAL_STRUCTURE_CORRUPTION. For third-party developers who used techniques that KPP deters, the following supported techniques can be used: ■ File system minifilters (see Chapter 7 for more information on these) to hook all file operations, including loading image files and DLLs, that can be intercepted to purge malicious code on-the-fly or block reading of known bad executables. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 244 ■ Registry filter notifications (see Chapter 4 for more information on these notifications) to hook all registry operations. Security software can block modification of critical parts of the registry, as well as heuristically determine malicious software by registry access patterns or known bad registry keys. ■ Process notifications (see Chapter 5 for more information on these notifications). Security software can monitor the execution and termination of all processes and threads on the system, as well as DLLs being loaded or unloaded. With the enhanced notifications added in Windows Vista SP1 and Windows Server 2008, they also have the ability to block process launch. ■ Object manager filtering (explained in the object manager section earlier). Security software can remove certain access rights being granted to processes and/or threads to defend their own utilities against certain operations. 3.15 Code integrity Code integrity is a Windows mechanism that authenticates the integrity and source of executable images (such as applications, DLLs, or drivers) by validating a digital certificate contained within the image’s resources. This mechanism works in conjunction with system policies, defining how signing should be enforced. One of these policies is the Kernel Mode Code Signing (KMCS) policy, which requires that kernel-mode code be signed with a valid Authenticode certificate rooted by one of several recognized code signing authorities, such as Verisign or Thawte. To address backward compatibility concerns, the KMCS policy is only fully enforced on 64-bit machines, as those drivers have to be recompiled recently in order to run on that Windows architecture. This in turn implies that a company or individual is still responsible for maintaining the driver and is able to sign it. On 32-bit machines, however, many older devices ship with outdated drivers, possibly from out-of-business companies, so signing those drivers would sometimes be unfeasible. Figure 3-36 shows the warning displayed on 64-bit Windows machines that attempt to load an unsigned driver. Note Windows also has a second driver signing policy, part of the Plug and Play manager. This policy is applied solely to Plug and Play drivers, and unlike the kernel-mode code signing policy, it can be configured to allow unsigned Plug and Play drivers (but not on 64-bit systems, where the KMCS policy takes precedence). See Chapter 7 for more information on the Plug and Play manager. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 245 Note that even on 32-bit machines, code integrity will generate a warning when such a driver is loaded, which can be viewed in the Event Log. Note Protected Media Path applications can also query the kernel for its integrity state, which includes information on whether or not unsigned 32-bit drivers are loaded on the system. In such scenarios, they are allowed to disable protected, high-definition media playback as a method to ensure the security and reliability of the encrypted stream. The code integrity mechanism doesn’t stop at driver load time, however. Stronger measures also exist to authenticate per-page image contents for executable pages. This requires using a special flag while signing the driver binary and will generate a catalog with the cryptographic hash of every executable page on which the driver will reside. (Pages are a unit of protection on the CPU; for more information, see Chapter 9.) This method allows for detection of modification of an existing driver, which may either happen at run time by another driver or through a page file or hibernation file attack (in which the contents of memory are edited on the disk and then reloaded into memory). Generating such per-page hashes is also a requirement for the new filtering model, as well as Protected Media Path components. 3.16 Conclusion In this chapter, we’ve examined the key base system mechanisms on which the Windows executive is built. In the next chapter, we’ll look at three important mechanisms involved with the management infrastructure of Windows: the registry, services, and Windows Management Instrumentation (WMI). Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 246 4. Management Mechanisms This chapter describes four fundamental mechanisms in the Windows operating system that are critical to its management and configuration: ■ The registry ■ Services ■ Windows Management Instrumentation ■ Windows Diagnostics Infrastructure 4.1 The Registry The registry plays a key role in the configuration and control of Windows systems. It is the repository for both systemwide and per-user settings. Although most people think of the registry as static data stored on the hard disk, as you’ll see in this section, the registry is also a window into various in-memory structures maintained by the Windows executive and kernel. We’ll start by providing you with an overview of the registry structure, a discussion of the data types it supports, and a brief tour of the key information Windows maintains in the registry. Then we’ll look inside the internals of the configuration manager, the executive component responsible for implementing the registry database. Among the topics we’ll cover are the internal on-disk structure of the registry, how Windows retrieves configuration information when an application requests it, and what measures are employed to protect this critical system database. 4.1.1 Viewing and Changing the Registry In general, you should never have to edit the registry directly: application and system settings stored in the registry that might require manual changes should have a corresponding user interface to control their modification. However, as you’ve already seen a number of times in this book, some advanced and debug settings have no editing user interface. Therefore, both graphical user interface (GUI) and command-line tools are included with Windows to enable you to view and modify the registry. Windows comes with one main GUI tool for editing the registry—Regedit.exe—and a number of command-line registry tools. Reg.exe, for instance, has the ability to import, export, back up, and restore keys, as well as to compare, modify, and delete keys and values.Regini.exe, on the other hand, allows you to import registry data based on text files that contain ASCII or Unicode configuration data. 4.1.2 Registry Usage Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 247 There are four principal times that configuration data is read: ■ During the initial boot process, the boot loader reads the list of boot device drivers to load into memory before initializing the kernel. ■ During the kernel boot process, the kernel reads settings that specify which device drivers to load and how various subsystems—such as the memory manager and process manager—configure themselves and tune system behavior. ■ During logon, Explorer and other Windows components read per-user preferences from the registry, including network drive-letter mappings, desktop wallpaper, screen saver, menu behavior, and icon placement. ■ During their startup, applications read systemwide settings, such as a list of optionally installed components and licensing data, as well as per-user settings that might include menu and toolbar placement and a list of most-recently accessed documents. However, the registry can be read at other times as well, such as in response to a modification of a registry value or key. Some applications monitor their configuration settings in the registry and read updated settings when they see a change. In general, however, on an idle system there should be no registry activity. The registry is commonly modified in the following cases: ■ Although not a modification, the registry’s initial structure and many default settings are defined by a prototype version of the registry that ships on the Windows setup media that is copied onto a new installation. ■ Application setup utilities create default application settings and settings that reflect installation configuration choices. ■ During the installation of a device driver, the Plug and Play system creates settings in the registry that tell the I/O manager how to start the driver and creates other settings that configure the driver’s operation. (See Chapter 7 for more information on how device drivers are installed.) ■ When you change application or system settings through user interfaces, the changes are often stored in the registry. Note Sadly, some applications poll the registry looking for changes when they should be using the registry’s RegNotifyChangeKey function, which puts a thread to sleep until a change occurs to the area of the registry in which they’re interested. 4.1.3 Registry Data Types The registry is a database whose structure is similar to that of a disk volume. The registry contains keys, which are similar to a disk’s directories, and values, which are comparable to files on a disk. A key is a container that can consist of other keys (subkeys) or values. Values, on the other hand, store data. Top-level keys are root keys. Throughout this section, we’ll use the words subkey and key interchangeably. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 248 Both keys and values borrow their naming convention from the file system. Thus, you can uniquely identify a value with the name mark, which is stored in a key called trade, with the name trade\mark. One exception to this naming scheme is each key’s unnamed value. Regedit displays the unnamed value as (Default). Values store different kinds of data and can be one of the 14 types listed in Table 4-1. The majority of registry values are REG_DWORD, REG_BINARY, or REG_SZ. Values of type REG_ DWORD can store numbers or Booleans (on/off values); REG_BINARY values can store numbers larger than 32 bits or raw data such as encrypted passwords; REG_SZ values store strings (Unicode, of course) that can represent elements such as names, file names, paths, and types. The REG_LINK type is particularly interesting because it lets a key transparently point to another key or value. When you traverse the registry through a link, the path searching continues at the target of the link. For example, if \Root1\Link has a REG_LINK value of \Root2\RegKey, and RegKey contains the value RegValue, two paths identify RegValue: \Root1\Link\RegValue and \Root2\RegKey\RegValue. As explained in the next section, Windows prominently uses registry links: three of the six registry root keys are links to subkeys within the three nonlink root keys. 4.1.4 Registry Logical Structure Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 249 You can chart the organization of the registry via the data stored within it. There are six root keys (and you can’t add new root keys or delete existing ones) that store information, as shown in Table 4-2. Why do root-key names begin with an H? Because the root-key names represent Windows handles (H) to keys (KEY). As mentioned in Chapter 1, HKLM is an abbreviation used for HKEY_LOCAL_MACHINE. Table 4-3 lists all the root keys and their abbreviations. The following sections explain in detail the contents and purpose of each of these six root keys. HKEY_CURRENT_USER The HKCU root key contains data regarding the preferences and software configuration of the locally logged-on user. It points to the currently logged-on user’s user profile, located on the hard disk at \Users\< username>\Ntuser.dat. (See the section “Registry Internals” later in this chapter to find out how root keys are mapped to files on the hard disk.) Whenever a user profile is loaded (such as at logon time or when a service process runs under the context of a specific user Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... interactive user In Windows, such processes are called services or Windows services, because they rely on the Windows API to interact with the system Services are similar to UNIX daemon processes and often implement the server side of client /server applications An example of a Windows service might be a Web server, because it must be running regardless of whether anyone is logged on to the computer and it must... those subkeys, you should find one called Windows Vista or Windows Server 2008 If you have more than one Windows installation on your machine, you need to check the 0x22000002 subkey, which contains the path, such as \Windows 3 Now that you’ve found the correct GUID for your Windows installation, create a new subkey under the Elements subkey for that GUID and call it 0x260000a0 If this subkey already... capabilities HKLM\SAM holds local account and group information, such as user passwords, group definitions, and domain associations Windows Server systems that are operating as domain 254 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark controllers store domain accounts and groups in Active Directory, a database that stores domainwide settings and information (Active Directory isn’t... result of the access; and the stack of the thread at the moment of the access This information is useful for seeing how applications and the system rely on the registry, discovering where applications and the system store configuration settings, and troubleshooting problems related to applications having missing registry keys or values Process Monitor includes advanced filtering and highlighting so that... local system account are not terminated when a user logs off, and you can take advantage of that fact to have Process Monitor run through a logoff and subsequent logon You can launch Process Monitor in the local system account either by using the At command that’s built into Windows and specifying the /interactive flag, or by using the Sysinternals PsExec utility, like this: 1 psexec –i 0 –s –d c:\procmon.exe... logoff, and shutdown on a Windows system will typically be between 50 and 150 MB in size 4.1.7 Registry Internals In this section, you’ll find out how the configuration manager—the executive subsystem that implements the registry—organizes the registry’s on-disk files We’ll examine how the configuration manager manages the registry as applications and other operating system components read and change... SOFTWARE, and SYSTEM The HKLM\BCD subkey contains the Boot Configuration Database (BCD) information loaded as a registry hive This database replaces the Boot.ini file that was used before Windows Vista and adds greater flexibility and isolation of per-installation boot configuration data (For more information on the BCD, see Chapter 13.) Each entry in the BCD, such as a Windows installation or the command-line... understanding how the system or the application that’s failing is accessing the registry In such situations, the Process Monitor utility from Windows Sysinternals (www.microsoft.com /technet/sysinternals) might provide the answer Process Monitor lets you monitor registry activity as it occurs For each registry access, Process Monitor shows you the process that performed the access; the time, type, and. .. elements are documented in the BCD reference in the MSDN Library and define various command-line settings or boot parameters The value associated with each element subkey corresponds to the value for its respective command-line flag or boot parameter The BCDEdit command-line utility allows you to modify the BCD using symbolic names for the elements and objects It also provides extensive help for all the boot... working and failing systems, and save the output to a log file Then open the good and bad log files with Microsoft Excel (accepting the defaults in the Import wizard), and delete the first three columns (If you don’t delete the first three columns, the comparison will show every line as different because the first three columns contain information that is different from run to run, such as the time and . of those subkeys, you should find one called Windows Vista or Windows Server 2008. If you have more than one Windows installation on your machine, you need. the Windows operating system that are critical to its management and configuration: ■ The registry ■ Services ■ Windows Management Instrumentation ■ Windows