Winreg

[Eryk Sun]

On 7/30/20, R Pasco <pascor22234 at gmail.com> wrote:

>   access rights must be set to [winreg.KEY_ALL_ACCESS | winreg.KEY_WOW64_64KEY

It's a bad practice to request more access than you require, at the
very least because the request may fail with access denied for no good
reason.

KEY_ALL_ACCESS includes all applicable standard rights (WRITE_OWNER,
WRITE_DAC, READ_CONTROL, DELETE) and all key rights (KEY_QUERY_VALUE,
KEY_SET_VALUE, KEY_CREATE_SUB_KEY, KEY_ENUMERATE_SUB_KEYS, KEY_NOTIFY,
KEY_CREATE_LINK). For an existing key, do you need to change the
owner, read and modify the security, delete the key, set a symlink,
etc? It looks like you just need to set a value, i.e. KEY_SET_VALUE.

>   winreg.KEY_WOW64_32KEY] (??? Why does this also work ?)

By default a 64-bit process doesn't see redirected keys, but if you
need to access them, use KEY_WOW64_32KEY in the desired access.
Normally a 32-bit process under WOW64 sees redirected keys, and if you
need to access the non-redirected keys, use KEY_WOW64_64KEY.

Note that KEY_WOW64_64KEY and KEY_WOW64_32KEY access modes only affect
runtime redirection. As with the standard MAXIMUM_ALLOWED access mode,
they're not assignable rights that can be granted or denied in a key
object's access control list.

>  with winreg.ConnectRegistry( None, hive ) as hivehndl

There is no need to call ConnectRegistry here. By default, predefined
handles are resolved to local key handles. Also, if you actually need
to access a remote machine, note that it's nonsensical to try to
connect to HKEY_CURRENT_USER. The API allows it, but why would one
assume that the remote machine will have a profile for the current
user's SID? The remote system will most likely just connect to a
handle for the default user profile.

> The key HKEY_LOCAL_MACHINE:SOFTWARE requires KEY_WOW64_64KEY
> to be 'OR'ed. Winreg gives no indication of this requirement, but the
> Windows doc "Redirected, Shared, and Reflected Keys Under WOW64" does
> specifically mention  HKEY_CURRENT_USER :SOFTWARE as needing this added
> access.

At the machine level, the software hive is stored on disk at
"%SystemRoot%\System32\config\SOFTWARE" and mounted at
"\REGISTRY\MACHINE\SOFTWARE". For a WOW64 process, by default there is
extensive runtime redirection of keys in this hive to the subkeys
"WOW6432Node" and "Classes\WOW6432Node".

At the user level, there are two hives mounted. The user profile is
stored on disk at "%USERPROFILE%\NTUSER.DAT" and mounted at
"\REGISTRY\USER\<SID>", where "<SID>" is the string form of the user's
security identifier (e.g. "S-1-5-21-<RID1>-<RID2>-<RID3>-<RID4>"). For
a WOW64 process, there is no redirection of subkeys that are
physically stored in this hive.

The user's software classes hive is stored on disk at
"%LOCALAPPDATA%\Microsoft\Windows\UsrClass.dat" and mounted at
"\REGISTRY\USER\<SID>_Classes". In the user profile, the
"Software\Classes" key is a symbolic link to the latter. For a WOW64
process, some subkeys in the classes hive are redirected to subkeys in
"WOW6432Node" (i.e. "Software\Classes\WOW6432Node"). It's just a
limited subset, including "CLSID", "DirectShow", "Interface", "Media
Type", and "MediaFoundation".

---

One never sees "\REGISTRY\MACHINE" and "\REGISTRY\USER" in the
registry API because it's designed to always use the "RootDirectory"
handle in the native NT object attributes [1]. For local access, the
API maps real handles for "\REGISTRY\MACHINE" and "\REGISTRY\USER" to
the predefined pseudo-handles HKEY_LOCAL_MACHINE and HKEY_USERS.
Similarly, HKEY_CURRENT_USER is mapped to a handle for
"\REGISTRY\USER\<SID>", where "<SID>" is the string form of the user's
security identifier. For remote access via RegConnectRegistryW (i.e.
winreg.ConnectRegistry), the predefined handles are mapped to
remote-procedure-call (RPC) handles that proxy real key handles on the
remote system.

[1] https://docs.microsoft.com/en-us/windows/win32/api/ntdef/ns-ntdef-_object_attributes