home contact portfolio music video history Rss feed bird

ETHICAL HACKING

Ethical Hacking

An ethical hacker is a computer and network expert who attacks a security system on behalf of its owners, seeking vulnerabilities that a malicious hacker could exploit. To test a security system, ethical hackers use the same methods as their less principled counterparts, but report problems instead of taking advantage of them. Ethical hacking is also known as penetration testing, intrusion testing and red teaming. An ethical hacker is sometimes called a white hat, a term that comes from old Western movies, where the "good guy" wore a white hat and the "bad guy" wore a black hat.
One of the first examples of ethical hackers at work was in the 1970s, when the United States government used groups of experts called red teams to hack its own computer systems. According to Ed Skoudis, Vice President of Security Strategy for Predictive Systems' Global Integrity consulting practice, ethical hacking has continued to grow in an otherwise lackluster IT industry, and is becoming increasingly common outside the government and technology sectors where it began. Many large companies, such as IBM, maintain employee teams of ethical hackers.
In a similar but distinct category, a hacktivist is more of a vigilante: detecting, sometimes reporting (and sometimes exploiting) security vulnerabilities as a form of social activism.

Understanding Basics:

Registry:
The registry is a system-defined database in which applications and system components store and retrieve configuration data. The data stored in the registry varies according to the version of Microsoft Windows. Applications use the registry API to retrieve, modify, or delete registry data.
You should not edit registry data that does not belong to your application unless it is absolutely necessary. If there is an error in the registry, your system may not function properly. If this happens, you can restore the registry to the state it was in when you last started the computer successfully. For more information, see the help for your operating system.

Structure of Registry:
The registry is a hierarchical database that contains data that is critical for the operation of Windows and the applications and services that run on Windows. The data is structured in a tree format. Each node in the tree is called a key. Each key can contain both subkeys and data entries called values. Sometimes, the presence of a key is all the data that an application requires; other times, an application opens a key and uses the values associated with the key. A key can have any number of values, and the values can be in any form.

Each key has a name consisting of one or more printable characters. Key names are not case sensitive. Key names cannot include the backslash character (\), but any other printable character can be used. Value names and data can include the backslash character.

The name of each subkey is unique with respect to the key that is immediately above it in the hierarchy. Key names are not localized into other languages, although values may be.
The following illustration is an example registry key structure as displayed by the Registry Editor.




Registry Editor window
Each of the trees under My Computer is a key. The HKEY_LOCAL_MACHINE key has the following subkeys: HARDWARE, SAM, SECURITY, SOFTWARE, and SYSTEM. Each of these keys in turn has subkeys. For example, the HARDWARE key has the subkeys DESCRIPTION, DEVICEMAP, and RESOURCEMAP; the DEVICEMAP key has several subkeys including VIDEO.
Each value consists of a value name and its associated data, if any. MaxObjectNumber and VgaCompatible are values that contain data under the VIDEO subkey.
A registry tree can be 512 levels deep. You can create up to 32 levels at a time through a single registry API call.
Registry Storage Space:
Although there are few technical limits to the type and size of data an application can store in the registry, certain practical guidelines exist to promote system efficiency. An application should store configuration and initialization data in the registry, and store other kinds of data elsewhere.
Generally, data consisting of more than one or two kilobytes (K) should be stored as a file and referred to by using a key in the registry rather than being stored as a value. Instead of duplicating large pieces of data in the registry, an application should save the data as a file and refer to the file. Executable binary code should never be stored in the registry.
A value entry uses much less registry space than a key. To save space, an application should group similar data together as a structure and store the structure as a value rather than storing each of the structure members as a separate key. (Storing the data in binary form allows an application to store data in one value that would otherwise be made up of several incompatible types.)
Views of the registry files are mapped in paged pool memory.
Windows Server 2008 for 32-bit, Windows Vista with SP1 for 32-bit, Windows Vista, Windows Server 2003, Windows XP:  Views of the registry files are mapped in the computer cache address space. Therefore, regardless of the size of the registry data, it is not charged more than 4 megabytes (MB).
The maximum size of a registry hive is 2 GB, except for the system hive.
Windows Server 2003 with SP1, Windows Server 2003, and Windows XP:  There are no explicit limits on the total amount of space that may be consumed by hives in paged pool memory and in disk space, although system quotas may affect the actual maximum size. The maximum size of a registry hive was limited to 2 GB starting with Windows Server 2003 with Service Pack 2 (SP2).
The maximum size of the system hive is limited by physical memory as shown in the following table.
SystemMaximum size of the system hive
x86-based systems50 percent of physical memory, up to 400 MB.
Windows Server 2003 with SP2, Windows Server 2003 with SP1, Windows Server 2003, and Windows XP:  25 percent of physical memory, up to 200 MB.
x64-based systems50 percent of physical memory, up to 1.5 GB.
Windows Server 2003 with SP2:  25 percent of system memory, up to 200 MB.
Windows Server 2003 with SP1, Windows Server 2003, and Windows XP 64-Bit Edition:  32 MB.
Intel Itanium-based systems50 percent of physical memory, up to 1 GB.
Windows Server 2008, Windows Vista, Windows Server 2003 with SP2, Windows Server 2003 with SP1, Windows Server 2003, and Windows XP 64-Bit Edition:  32 MB.

Windows 2000

Registry data is stored in the paged pool, an area of physical memory used for system data that can be written to disk when not in use. The RegistrySizeLimit value establishes the maximum amount of paged pool that can be consumed by registry data from all applications. This value is located in the following registry key:

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
By default, the registry size limit is 25 percent of the paged pool. (The default size of the paged pool is 32 MB, so this is 8 MB.) The system ensures that the minimum value of RegistrySizeLimit is 4 MB and the maximum is approximately 80 percent of the PagedPoolSize value. If the value of this entry is greater than 80 percent of the size of the paged pool, the system sets the maximum size of the registry to 80 percent of the size of the paged pool. This prevents the registry from consuming space needed by processes. Note that setting this value does not allocate space in the paged pool, nor does it assure that the space will be available if needed.
The paged pool size is determined by the PagedPoolSize value in the following registry key:

HKEY_LOCAL_MACHINE
   System
      CurrentControlSet
         Control
            SessionManager
               MemoryManagement
For an example of how to determine the current and maximum sizes of the registry, see Determining the Registry Size.
The maximum paged pool is approximately 300,470 MB so the registry size limit is 240-376 MB. However, if the /3GB switch is used, the maximum paged pool size is 192 MB, so the registry can be a maximum of 153.6 MB.

 Predefined Keys:
An application must open a key before it can add data to the registry. To open a key, an application must supply a handle to another key in the registry that is already open. The system defines predefined keys that are always open. Predefined keys help an application navigate in the registry and make it possible to develop tools that allow a system administrator to manipulate categories of data. Applications that add data to the registry should always work within the framework of predefined keys, so administrative tools can find and use the new data.
An application can use handles to these keys as entry points to the registry. These handles are valid for all implementations of the registry, although the use of the handles may vary from platform to platform. In addition, other predefined handles have been defined for specific platforms. The following are handles to the predefined keys.
HandleDescription
HKEY_CLASSES_ROOT
Registry entries subordinate to this key define types (or classes) of documents and the properties associated with those types. Shell and COM applications use the information stored under this key.
This key also provides backward compatibility with the Windows 3.1 registration database by storing information for DDE and OLE support. File viewers and user interface extensions store their OLE class identifiers in HKEY_CLASSES_ROOT, and in-process servers are registered in this key.
This handle should not be used in a service or an application that impersonates different users.
For more information, see HKEY_CLASSES_ROOT.
HKEY_CURRENT_CONFIG
Contains information about the current hardware profile of the local computer system. The information under HKEY_CURRENT_CONFIG describes only the differences between the current hardware configuration and the standard configuration. Information about the standard hardware configuration is stored under the Software and System keys of HKEY_LOCAL_MACHINE.
HKEY_CURRENT_CONFIG is an alias for HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles\Current.
For more information, see HKEY_CURRENT_CONFIG.
HKEY_CURRENT_USER
Registry entries subordinate to this key define the preferences of the current user. These preferences include the settings of environment variables, data about program groups, colors, printers, network connections, and application preferences. This key makes it easier to establish the current user's settings; the key maps to the current user's branch in HKEY_USERS. In HKEY_CURRENT_USER, software vendors store the current user-specific preferences to be used within their applications. Microsoft, for example, creates the HKEY_CURRENT_USER\Software\Microsoft key for its applications to use, with each application creating its own subkey under the Microsoft key.
The mapping between HKEY_CURRENT_USER and HKEY_USERS is per process and is established the first time the process references HKEY_CURRENT_USER. The mapping is based on the security context of the first thread to reference HKEY_CURRENT_USER. If this security context does not have a registry hive loaded in HKEY_USERS, the mapping is established with HKEY_USERS\.Default. After this mapping is established it persists, even if the security context of the thread changes.
All registry entries in HKEY_CURRENT_USER except those under HKEY_CURRENT_USER\Software\Classes are included in the per-user registry portion of a roaming user profile. To exclude other entries from a roaming user profile, store them in HKEY_CURRENT_USER_LOCAL_SETTINGS.
This handle should not be used in a service or an application that impersonates different users. Instead, call the RegOpenCurrentUser function.
For more information, see HKEY_CURRENT_USER.
HKEY_CURRENT_USER_LOCAL_SETTINGS
Registry entries subordinate to this key define preferences of the current user that are local to the machine. These entries are not included in the per-user registry portion of a roaming user profile.
Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP/2000:  This key is supported starting with Windows 7 and Windows Server 2008 R2.
HKEY_LOCAL_MACHINE
Registry entries subordinate to this key define the physical state of the computer, including data about the bus type, system memory, and installed hardware and software. It contains subkeys that hold current configuration data, including Plug and Play information (the Enum branch, which includes a complete list of all hardware that has ever been on the system), network logon preferences, network security information, software-related information (such as server names and the location of the server), and other system information.
For more information, see HKEY_LOCAL_MACHINE.
HKEY_PERFORMANCE_DATA
Registry entries subordinate to this key allow you to access performance data. The data is not actually stored in the registry; the registry functions cause the system to collect the data from its source.
HKEY_PERFORMANCE_NLSTEXT
Registry entries subordinate to this key reference the text strings that describe counters in the local language of the area in which the computer system is running. These entries are not available to Regedit.exe and Regedt32.exe.
Windows 2000:  This key is not supported.
HKEY_PERFORMANCE_TEXT
Registry entries subordinate to this key reference the text strings that describe counters in US English. These entries are not available to Regedit.exe and Regedt32.exe.
Windows 2000:  This key is not supported.
HKEY_USERS
Registry entries subordinate to this key define the default user configuration for new users on the local computer and the user configuration for the current user.
Registry Hive:
The RegOverridePredefKey function enables you to map a predefined registry key to a specified key in the registry. For instance, a software installation program could remap a predefined key before installing a DLL component. This enables the installation program to easily examine the information that the DLL's installation procedure writes to the predefined key.
The RegDisablePredefinedCache and RegDisablePredefinedCacheEx functions disable handle caching for predefined registry handles. Services that use impersonation should call RegDisablePredefinedCacheEx before using predefined registry handles.
The predefined handles are not thread safe. Closing a predefined handle in one thread affects any other threads that are using the handle.
A hive is a logical group of keys, subkeys, and values in the registry that has a set of supporting files containing backups of its data.
Each time a new user logs on to a computer, a new hive is created for that user with a separate file for the user profile. This is called the user profile hive. A user's hive contains specific registry information pertaining to the user's application settings, desktop, environment, network connections, and printers. User profile hives are located under the HKEY_USERS key.
Registry files have the following two formats: standard and latest. The standard format is the only format supported by Windows 2000. It is also supported by later versions of Windows for backward compatibility. The latest format is supported starting with Windows XP. On versions of Windows that support the latest format, the following hives still use the standard format: HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE\SAM, HKEY_LOCAL_MACHINE\Security, and HKEY_USERS\.DEFAULT; all other hives use the latest format.
Most of the supporting files for the hives are in the %SystemRoot%\System32\Config directory. These files are updated each time a user logs on. The file name extensions of the files in these directories, or in some cases a lack of an extension, indicate the type of data they contain. The following table lists these extensions along with a description of the data in the file.
ExtensionDescription
none
A complete copy of the hive data.
.alt
A backup copy of the critical HKEY_LOCAL_MACHINE\System hive. Only the System key has an .alt file.
.log
A transaction log of changes to the keys and value entries in the hive.
.sav
A backup copy of a hive.
Windows Server 2003 and Windows XP/2000:  Copies of the hive files as they looked at the end of the text-mode stage in Setup. Setup has two stages: text mode and graphics mode. The hive is copied to a .sav file after the text-mode stage of setup to protect it from errors that might occur if the graphics-mode stage of setup fails. If setup fails during the graphics-mode stage, only the graphics-mode stage is repeated when the computer is restarted; the .sav file is used to restore the hive data.

The following table lists the standard hives and their supporting files.
Registry hiveSupporting files
HKEY_CURRENT_CONFIGSystem, System.alt, System.log, System.sav
HKEY_CURRENT_USERNtuser.dat, Ntuser.dat.log
HKEY_LOCAL_MACHINE\SAMSam, Sam.log, Sam.sav
HKEY_LOCAL_MACHINE\SecuritySecurity, Security.log, Security.sav
HKEY_LOCAL_MACHINE\SoftwareSoftware, Software.log, Software.sav
HKEY_LOCAL_MACHINE\SystemSystem, System.alt, System.log, System.sav
HKEY_USERS\.DEFAULTDefault, Default.log, Default.sav
 Categories Of Data:
Before putting data into the registry, an application should divide the data into two categories: computer-specific data and user-specific data. By making this distinction, an application can support multiple users, and yet locate user-specific data over a network and use that data in different locations, allowing location-independent user profile data. (A user profile is a set of configuration data saved for every user.)
When the application is installed, it should record the computer-specific data under the HKEY_LOCAL_MACHINE key. In particular, it should create keys for the company name, product name, and version number, as shown in the following example:
HKEY_LOCAL_MACHINE\Software\MyCompany\MyProduct\1.0
If the application supports COM, it should record that data under HKEY_LOCAL_MACHINE\Software\Classes.
An application should record user-specific data under the HKEY_CURRENT_USER key, as shown in the following example:
HKEY_CURRENT_USER\Software\MyCompany\MyProduct\1.0

OPEN,CREATING,CLOSING:
Before an application can add data to the registry, it must create or open a key. To create or open a key, an application always refers to the key as a subkey of a currently open key. The following predefined keys are always open: HKEY_LOCAL_MACHINE, HKEY_CLASSES_ROOT, HKEY_USERS, and HKEY_CURRENT_USER. An application uses the RegOpenKeyEx function to open a key and the RegCreateKeyEx function to create a key. A registry tree can be 512 levels deep. You can create up to 32 levels at a time through a single registry API call.
An application can use the RegCloseKey function to close a key and write the data it contains into the registry. RegCloseKey does not necessarily write the data to the registry before returning; it can take as much as several seconds for the cache to be flushed to the hard disk. If an application must explicitly write registry data to the hard disk, it can use the RegFlushKey function. RegFlushKey, however, uses many system resources and should be called only when absolutely necessary.

WRITING AND DELETING REG DATA:
An application can use the RegSetValueEx function to associate a value and its data with a key. For a list of the value types supported by RegSetValueEx, see Registry Value Types.
To delete a value from a key, an application can use the RegDeleteValue function. To delete a key, it can use the RegDeleteKey function. A deleted key is not removed until the last handle to it has been closed. Subkeys and values cannot be created under a deleted key.
It is not possible to lock a registry key during a write operation to synchronize access to the data. However, you can control access to a registry key using security attributes. For more information, see Registry Key Security and Access Rights.
More than one registry operation can be performed within a single transaction. To associate a registry key with a transaction, an application can use the RegCreateKeyTransacted or RegOpenKeyTransacted function. For more information about transactions, see Kernel Transaction Manager.
Retreving Data From Registry:
To retrieve data from the registry, an application typically enumerates the subkeys of a key until it finds a particular one and then retrieves data from the value or values associated with it. An application can call the RegEnumKeyEx function to enumerate the subkeys of a given key.
To retrieve detailed data about a particular subkey, an application can call the RegQueryInfoKey function. The RegGetKeySecurity function retrieves a copy of the security descriptor protecting a key.
An application can use the RegEnumValue function to enumerate the values for a given key, and RegQueryValueEx function to retrieve a particular value for a key. An application typically calls RegEnumValue to determine the value names and then RegQueryValueEx to retrieve the data for the names.
The RegQueryMultipleValues function retrieves the type and data for a list of value names associated with an open registry key. This function is useful for dynamic key providers because it assures consistency of data by retrieving multiple values in an atomic operation.
Because other applications can change the data in a registry value between the time your application can read a value and use it, you may need to ensure your application has the latest data. You can use the RegNotifyChangeKeyValue function to notify the calling thread when there are changes to the attributes or contents of a registry key, or if the key is deleted. The function signals an event object to notify the caller. If the thread that calls RegNotifyChangeKeyValue exits, the event is signaled and the monitoring of the registry key is stopped.
You can control or specify what changes should be reported through the use of a notify filter or flag. Usually, changes are reported by signaling an event that you specify to the function. Note that the RegNotifyChangeKeyValue function does not work with remote handles.
To monitor registry operations in more detail, see Registry.

 Registry Files:
Applications can save part of the registry in a file and then load the contents of the file back into the registry. A registry file is useful when a large amount of data is being manipulated, when many entries are being made in the registry, or when the data is transitory and must be loaded and then unloaded again. Applications that back up and restore parts of the registry are likely to use registry files.
To save a key and its subkeys and values to a registry file, an application can call the RegSaveKey or RegSaveKeyEx function.
RegSaveKey and RegSaveKeyEx create the file with the archive attribute. The file is created in the current directory of the process for a local key, and in the %systemroot%\system32 directory for a remote key.
Registry files have the following two formats: standard and latest. The standard format is the only format supported by Windows 2000. It is also supported by later versions of Windows for backward compatibility. RegSaveKey creates files in the standard format.
The latest format is supported starting with Windows XP. Registry files that are created in this format cannot be loaded on Windows 2000. RegSaveKeyEx can save registry files in either format by specifying either REG_STANDARD_FORMAT or REG_LATEST_FORMAT. Therefore, it can be used to convert registry files that use the standard format to the latest format.
To write the registry file back to the registry, an application can use the RegLoadKey, RegReplaceKey, or RegRestoreKey functions as follows.
  • RegLoadKey loads registry data from a specified file into a specified subkey under HKEY_USERS or HKEY_LOCAL_MACHINE on the calling application's computer or on a remote computer. The function creates the specified subkey if it does not already exist. After calling this function, an application can use the RegUnLoadKey function to restore the registry to its previous state.
  • RegReplaceKey replaces a key and all its subkeys and values in the registry with the data contained in a specified file. The new data takes effect the next time the system is started.
  • RegRestoreKey loads registry data from a specified file into a specified key on the calling application's computer or on a remote computer. This function replaces the subkeys and values below the specified key with the subkeys and values that follow the top-level key in the file.
The RegConnectRegistry function establishes a connection to a predefined registry handle on another computer. An application uses this function primarily to access information from a remote registry on other machines in a network environment, which you can also do by using the Registry Editor. You might want to access a remote registry to back up a registry or regulate network access to it. Note that you must have appropriate permissions to access a remote registry using this function.

Permissions:
The Windows security model enables you to control access to registry keys. For more information about security, see Access-Control Model.
You can specify a security descriptor for a registry key when you call the RegCreateKeyEx or RegSetKeySecurity function. If you specify NULL, the key gets a default security descriptor. The ACLs in a default security descriptor for a key are inherited from its direct parent key.
To get the security descriptor of a registry key, call the RegGetKeySecurity, GetNamedSecurityInfo, or GetSecurityInfo function.
The valid access rights for registry keys include the DELETE, READ_CONTROL, WRITE_DAC, and WRITE_OWNER standard access rights. Registry keys do not support the SYNCHRONIZE standard access right.
The following table lists the specific access rights for registry key objects.
ValueMeaning
KEY_ALL_ACCESS (0xF003F)
Combines the STANDARD_RIGHTS_REQUIRED, KEY_QUERY_VALUE, KEY_SET_VALUE, KEY_CREATE_SUB_KEY, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY, and KEY_CREATE_LINK access rights.
KEY_CREATE_LINK (0x0020)
Reserved for system use.
KEY_CREATE_SUB_KEY (0x0004)
Required to create a subkey of a registry key.
KEY_ENUMERATE_SUB_KEYS (0x0008)
Required to enumerate the subkeys of a registry key.
KEY_EXECUTE (0x20019)
Equivalent to KEY_READ.
KEY_NOTIFY (0x0010)
Required to request change notifications for a registry key or for subkeys of a registry key.
KEY_QUERY_VALUE (0x0001)
Required to query the values of a registry key.
KEY_READ (0x20019)
Combines the STANDARD_RIGHTS_READ, KEY_QUERY_VALUE, KEY_ENUMERATE_SUB_KEYS, and KEY_NOTIFY values.
KEY_SET_VALUE (0x0002)
Required to create, delete, or set a registry value.
KEY_WOW64_32KEY (0x0200)
Indicates that an application on 64-bit Windows should operate on the 32-bit registry view. This flag is ignored by 32-bit Windows. For more information, see Accessing an Alternate Registry View.
This flag must be combined using the OR operator with the other flags in this table that either query or access registry values.
Windows 2000:  This flag is not supported.
KEY_WOW64_64KEY (0x0100)
Indicates that an application on 64-bit Windows should operate on the 64-bit registry view. This flag is ignored by 32-bit Windows. For more information, see Accessing an Alternate Registry View.
This flag must be combined using the OR operator with the other flags in this table that either query or access registry values.
Windows 2000:  This flag is not supported.
KEY_WRITE (0x20006)
Combines the STANDARD_RIGHTS_WRITE, KEY_SET_VALUE, and KEY_CREATE_SUB_KEY access rights.

When you call the RegOpenKeyEx function, the system checks the requested access rights against the key's security descriptor. If the user does not have the correct access to the registry key, the open operation fails. If an administrator needs access to the key, the solution is to enable the SE_TAKE_OWNERSHIP_NAME privilege and open the registry key with WRITE_OWNER access. For more information, see Enabling and Disabling Privileges.
You can request the ACCESS_SYSTEM_SECURITY access right to a registry key if you want to read or write the key's system access control list (SACL). For more information, see Access-Control Lists (ACLs) and SACL Access Right.
To view the current access rights for a key, including the predefined keys, use the Registry Editor (Regedt32.exe). After navigating to the desired key, go to the Edit menu and select Permissions.

32,64 bit
On 64-bit Windows, portions of the registry entries are stored separately for 32-bit application and 64-bit applications and mapped into separate logical registry views using the registry redirector and registry reflection, because the 64-bit version of an application may use different registry keys and values than the 32-bit version. There are also shared registry keys that are not redirected or reflected.
The parent of each 64-bit registry node is the Image-Specific Node or ISN. The registry redirector transparently directs an application's registry access to the appropriate ISN subnode. Redirection subnodes in the registry tree are created automatically by the WOW64 component using the name Wow6432Node. As a result, it is essential not to name any registry key you create Wow6432Node.
The KEY_WOW64_64KEY and KEY_WOW64_32KEY flags enable explicit access to the 64-bit registry view and the 32-bit view, respectively. For more information, see Accessing an Alternate Registry View.
To disable and enable registry reflection for a particular key, use the RegDisableReflectionKey and RegEnableReflectionKey functions. Applications should disable reflection only for the registry keys that they create and not attempt to disable reflection for the predefined keys such as HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER. To determine which keys are on the reflection list, use the RegQueryReflectionKey function.

Registry virtualization is an application compatibility technology that enables registry write operations that have global impact to be redirected to per-user locations. This redirection is transparent to applications reading from or writing to the registry. It is supported starting with Windows Vista.
This form of virtualization is an interim application compatibility technology; Microsoft intends to remove it from future versions of the Windows operating system as more applications are made compatible with Windows Vista and later versions of Windows. Therefore, it is important that your application does not become dependent on the behavior of registry virtualization in the system.
Virtualization is intended only to provide compatibility for existing applications. Applications designed for Windows Vista and later versions of Windows should not write to sensitive system areas, nor should they rely on virtualization to remedy any problems. When updating existing code to run on Windows Vista and later versions of Windows, developers should ensure that applications only store data in per-user locations or in computer locations within %alluserprofile% that properly use an access control list (ACL).
For more information about building UAC-compliant applications, see the UAC Developer Guide.

Virtualization Overview

Prior to Windows Vista, applications were typically run by administrators. As a result, applications could freely access system files and registry keys. If these applications were run by a standard user, they would fail due to insufficient access rights. Windows Vista and later versions of Windows improve application compatibility for these applications by automatically redirecting these operations. For example, registry operations to the global store (HKEY_LOCAL_MACHINE\Software) are redirected to a per-user location within the user's profile known as the virtual store (HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software).

Registry virtualization can be broadly classified into the following types:
Open Registry Virtualization
If the caller does not have write access to a key and attempts to open the key, the key is opened with the maximum allowed access for that caller.
If the REG_KEY_DONT_SILENT_FAIL flag is set for the key, the operation fails and the key is not opened. For more information, see "Controlling Registry Virtualization" later in this topic.
Write Registry Virtualization
If the caller does not have write access to a key and attempts to write a value to it or create a subkey, the value is written to the virtual store.
For example, if a limited user attempts to write a value to the following key: HKEY_LOCAL_MACHINE\Software\AppKey1, virtualization redirects the write operation to HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\AppKey1.
Read Registry Virtualization
If the caller reads from a key that is virtualized, the registry presents a merged view of both the virtualized values (from the virtual store) and the non-virtual values (from the global store) to the caller.
For example, suppose HKEY_LOCAL_MACHINE\Software\AppKey1 contains two values V1 and V2 and that a limited user writes a value V3 to the key. When the user attempts to read values from this key, the merged view includes values V1 and V2 from the global store and value V3 from the virtual store.
Note that virtual values take precedence over global values when present. In the example above, even if the global store had value V3 under this key, the value V3 would still be returned to the caller from the virtual store. If V3 were to be deleted from the virtual store, then V3 would be returned from the global store. In other words, if V3 were to be deleted from HKEY_USERS\<User SID>_Classes\VirtualStore\Machine\Software\AppKey1 but HKEY_LOCAL_MACHINE\Software\AppKey1 had a value V3, then that value would be returned from the global store.

Registry Virtualization Scope

Registry virtualization is enabled only for the following:
  • 32-bit interactive processes.
  • Keys in HKEY_LOCAL_MACHINE\Software.
  • Keys that an administrator can write to. (If an administrator cannot write to a key, then the application would have failed on previous versions of Windows even if it was run by an administrator.)
Registry virtualization is disabled for the following:
  • 64-bit processes.
  • Processes that are not interactive, such as services.Note that using the registry as an inter-process communication (IPC) mechanism between a service (or any other process that does not have virtualization enabled) and an application will not work correctly if the key is virtualized. For instance, if an antivirus service updates its signature files based on a value set by an application, the service will never update its signature files because the service reads from the global store but the application writes to the virtual store.
  • Processes that impersonate a user. If a process attempts an operation while impersonating a user, that operation will not be virtualized.
  • Kernel-mode processes such as drivers.
  • Processes that have requestedExecutionLevel specified in their manifests.
  • Keys and subkeys of HKEY_LOCAL_MACHINE\Software\Classes, HKEY_LOCAL_MACHINE\Software\Microsoft\Windows, and HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT.

Controlling Registry Virtualization

In addition to controlling virtualization at an application level by using requestedExecutionLevel in the manifest, an administrator can enable or disable virtualization on a per-key basis for keys in HKEY_LOCAL_MACHINE\Software. To do this, use the Reg.exe command-line utility FLAGS option with the flags listed in the following table.
FlagMeaning
REG_KEY_DONT_SILENT_FAILThis flag disables open registry virtualization. If this flag is set and an open operation fails on a key that has virtualization enabled, the registry does not attempt to reopen the key. If this flag is clear, the registry attempts to reopen the key with MAXIMUM_ALLOWED access instead of the requested access.
REG_KEY_DONT_VIRTUALIZEThis flag disables write registry virtualization. If this flag is set and a create key or set value operation fails because the caller does not have sufficient access right to the parent key, the registry fails the operation. If this flag is clear, the registry attempts to write the key or value in the virtual store. The caller must have the KEY_READ right on the parent key.
REG_KEY_RECURSE_FLAGIf this flag is set, registry virtualization flags are propagated from the parent key. If this flag is clear, registry virtualization flags are not propagated. Changing this flag affects only new descendent keys created after the flag is changed. It does not set or clear these flags for existing descendent keys.

The following example shows the use of the Reg.exe command-line utility with the FLAGS option to query the state of the virtualization flags for a key.
C:\>reg flags HKLM\Software\AppKey1 QUERY

HKEY_LOCAL_MACHINE\Software\AppKey1

        REG_KEY_DONT_VIRTUALIZE: CLEAR
        REG_KEY_DONT_SILENT_FAIL: CLEAR
        REG_KEY_RECURSE_FLAG: CLEAR

The operation completed successfully.

Whenever auditing is enabled on a key that is being virtualized, a new virtualization audit event is generated to indicate that the key is being virtualized (addition to the usual audit events). Administrators can use this information to monitor the status of virtualization on their systems.

1 comment:

  1. Keep the links for learning Hacking also raa.

    ReplyDelete