SetWall: cambia el fondo de pantalla aplicado por directivas de grupo

El mes pasado escribí un artículo sobre cómo cambiar el fondo de pantalla establecido a través de directivas de grupo, además de mostrar algunos detalles técnicos sobre las operaciones en registro que se llevan a cabo en el proceso. Como mencioné en ese momento, realizo este cambio manualmente cada que mi equipo actualiza las directivas de grupo, así que decidí construir una pequeña aplicación que realizará este procedimiento cada que lo necesitara y la compartiré por aquí.

SetWall

SetWall es una aplicación de consola que utiliza varias funciones de la API de Windows para modificar el fondo de pantalla y notificarle al sistema operativo para que lo pueda visualizar. No hice modificaciones de seguridad, así que el cambio de fondo durará lo que demoren las directivas de grupo para volverse a forzar en el equipo, pero igual siempre puede volverse a ejecutar la aplicación.

¿Cómo funciona?

Para ejecutar SetWall, basta con abrir un símbolo del sistema con privilegios elevados y lanzar como parámetro la ruta del JPG o PNG:

SetWall.exe [RutaImagen]

Donde [RutaImage] debe contener la extensión del archivo, por ejemplo:

SetWall.exe C:\Imagen.jpg

La aplicación verificará que el archivo exista en la ruta utilizando la función GetFileAttributes y si no hay problemas, procederá a aplicar el fondo de forma local para luego abrir la subclave en donde se almacena la directiva y escribir el nuevo contenido con la ruta de la imagen. Finalmente, llama a la función SystemParametersInfo para notificarle al sistema operativo del cambio y que se pueda ver inmediatamente.

Así es como se ve mi equipo con el fondo corporativo:

image

Para cambiar el fondo por una imagen ubicada en D:\WALL, basta con ejecutar SetWall con el nombre de archivo completo:

SetWall.exe “D:\WALL\img10.jpg”

La aplicación debe notificar el cambio en local y dominio:

SNAGHTML6087a79

En caso de intentar establecer algún TXT u otro tipo de archivo diferente a JPG y PNG, la aplicación nos dará un error:

SNAGHTML6099afc

El resultado final será el fondo de pantalla que queríamos, en vez del corporativo:

image

Descarga

Para los que estén interesados, la aplicación se puede descargar desde aquí:

https://1fichier.com/?mvw7d6fqgp

Si en algún momento logro que el cambio sea permanente, actualizaré la aplicación en el mismo servidor.

Saludos,

—Checho

Explorando el «Registry Redirector» en Windows

Antes de empezar

Si no estoy mal, este es el primer artículo en el que escribiré sobre una característica interna del sistema operativo; así que pido disculpas de antemano por cualquier equivocación que tenga y por si el código que aquí expondré no es el más profesional. Dicho esto, ¡empecemos!

Windows de 32 bit en Windows de 64 bit (WOW64)

Debido a que el trabajo de «Registry Redirector» hace parte de WOW64 , es necesario dar una introducción, mas no voy a profundizar porque de esto no se trata el artículo y, a decir verdad, no tengo aún el conocimiento para exponerlo.

«Windows 32 –bit On Windows 64-bit (WOW64)» es una capa de emulación que permite ejecutar aplicaciones basadas en 32 bits en un sistema operativo de 64 bits sin que la aplicación lo llegue a percibir. WOW64 tiene una colección de DLLs en modo usuario (existe modo usuario y modo kernel) que interceptan llamadas desde y hacia un proceso de 32 bits y hace la respectiva traducción para que todo funcione en el ambiente de 64 bits.

Registry Redirector

Lo primero que hay que decir es que este es que el mecanismo que voy a pasar a describir no es nuevo, pues existe desde Windows Vista, pero aún tiene influencia en problemas relacionados a la compatibilidad de aplicaciones.

El trabajo del «Registry Redirector» es aislar las aplicaciones de 32 y de 64 bits de ciertas partes del registro con diferentes nodos  para almacenar la información. Básicamente, intercepta la llamada que hace la aplicación, sea de 32 o de 64 bits, a su respectiva ubicación lógica y la dirige a una ubicación física. Este proceso es completamente transparente para la aplicación (y para nosotros), así que las aplicaciones de 32 bits, por ejemplo, pueden seguir accediendo a sus datos como si estuvieran en un sistema base de 32 bits. Esto es para que puedan correr y convivir sin problemas.

Las subclaves que son dirigidas se guardan en la subclave de Wow6432Node; por ejemplo, todo lo que una aplicación de 32 bits intente escribir en HKEY_LOCAL_MACHINE\Software es dirigido a la subclave HKEY_LOCAL_MACHINE\Wow6432Node.

Nota: de aquí en adelante utilizaré las siglas de HKLM y HKCU para poder referirme a las claves de HKEY_LOCAL_MACHINE y HKEY_CURRENT_USER, respectivamente.

¿Cómo lo vemos en acción?

Para poder ver y entender este mecanismo, decidí escribir, con mi pobre conocimiento en C, una aplicación propuesta por la documentación oficial de Microsoft y mostrarla en este artículo, con la ayuda adicional de Process Monitor.

La aplicación

La aplicación que escribí se llama DemoApp.exe y lo que hace es tratar de abrir la subclave WinSide, ubicada en la subclave HKEY_LOCAL_MACHINE\Software. Si la subclave existe, consulta el contenido del valor predeterminado, Default, y lo muestra en consola; si no, la aplicación crea la subclave de WinSide , escribe el contenido del valor predeterminado y procede a mostrarlo en consola. 

Nota: en cada subclave que se crea siempre existe el valor de Default, que puede o no tener un contenido.

A continuación, muestro una imagen en donde trato de ilustrar las operaciones que hace la aplicación.

SNAGHTML1cd7165

La imagen anterior, aunque resume el comportamiento general de la aplicación, es fiel a la gráfica cuando el ejectuable es de la misma arquitectura que el sistema operativo instalado; sin embargo, cuando la aplicación es de 32 bit y se ejecuta en un sistema de 64, el Registry Redirector actuará sobre la subclave de HKLM\WinSide y la ubicación física cambiará, así:

SNAGHTML36a031

Esta dirección al nodo físico, como ya lo dije, es completamente transparente para la aplicación, así que el desarrollador no tiene que preocuparse realmente por este mecanismo.

El código (para los interesados)

Importante: insisto en que soy un programador novato de C, así que seguramente encontrarán errores o mejoras prácticas en mi código. ¡Cualquier aporte es bienvenido!

Lo primero que hice fue crear una serie de macros para remplazar el mensaje según esté compilada la aplicación; es decir, si ejecuto la versión compilada a 64 bits, el mensaje será «64-bit app on WINx64», de lo contrario, «32-bit app on WINx64».

#ifdef _M_AMD64

#define MSG L”64-bit app on WINx64.\n”

#else

#define MSG L”32-bit app on WINx64.\n”

#endif

Luego creé una función llamada showValue que utiliza la función RegGetValue de la API de Windows para consultar el contenido del valor Default y luego mostrarlo. La función personalizada quedó así:

/*This function receives some variables to show a registry value’s –
content, but only REG_SZ is working by now.*/
void showValue(HKEY openKeyResult, LPCWSTR regValueName, DWORD flags)
{
    //Buffer that receives the value’s data.
    WCHAR valuesData[255];
    PVOID pValuesData = valuesData; //A.K.A. pvData
    DWORD sizeOfBuffer = sizeof(valuesData); //A.K.A. pcbData
    DWORD typeOfData;

    LONG getValue = RegGetValue(openKeyResult, NULL, regValueName,
                                flags, &typeOfData, pValuesData,  &sizeOfBuffer);

    if (getValue != ERROR_SUCCESS)
    {
        wprintf(L”Error getting the value. Code: %li\n”, getValue);
    }
    else
    {
        switch (typeOfData)
        {
        case REG_SZ:
            wprintf(L”Value’s data: %s\n”, (PWCHAR)pValuesData);
            break;

        default:
            wprintf(L”No other types are allowed.\n”);
            break;
        }
    }

}

Nota: RegGetValue está documentada en la página oficial de MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms724868(v=vs.85).aspx

La función recibe una variable openKeyResult, que es el handle a la subclave abiera previamente con RegOpenkeyEx (en wmain la utilizo); regValueName, que es el nombre del valor a consultar y flags, que me indica el tipo de datos que voy a utilizar.

Finalmente está el código de la función principal wmain. Aquí lo que hice fue declarar las variables necesarias para usar la función RegCreateKeyEx que abre o crea la subclave, luego las que requiere RegSetValueEx para escribir el contenido del valor Default y las de RegGetValue para consultar e imprimir el contenido del valor Default.

La siguiente porción de código se puede resumir así en esta secuencia:

¿Existe la subclave HKEY_LOCAL_MACHINE\Software\WinSide?

  • : consultar e imprimir el contenido del valor Default.
  • No: crear la subclave WinSide, escribir el contenido del valor Default e imprimirlo.

Así se ve todo esto usando C y la API de Windows:

int wmain()
{

    void showValue(HKEY openKeyResult, LPCWSTR regValueName, DWORD flags);
   

    //RegCreateKeyEx
    HKEY hKey = HKEY_LOCAL_MACHINE;
    LPCWSTR subKey = L”Software\\WinSide”;
    DWORD reserved = 0;
    LPWSTR classTypeOfKey = NULL;
    DWORD options = REG_OPTION_NON_VOLATILE;
    REGSAM samDesired = KEY_READ | KEY_WRITE;
    LPSECURITY_ATTRIBUTES securityAttributes = NULL;
    //Handle to the opened or created key.
    HKEY openKeyResult;
    DWORD disposition;

    //RegSetValueEx
    LPCWSTR valueName = NULL; //To set the default value’s content.
    DWORD typeOfData = REG_SZ;
    const BYTE *pData = (const BYTE*)MSG;
    DWORD size = sizeof(MSG);

    //RegGetValue
    LPCWSTR valueNameDefault = NULL; //To get the default value’s data.

    //Restrict the data type of value queried.
    DWORD flags = RRF_RT_ANY;
       

    LONG createKey = RegCreateKeyEx(hKey, subKey, reserved, classTypeOfKey,
                                    options, samDesired, securityAttributes,
                                    &openKeyResult, &disposition);

    if (createKey != ERROR_SUCCESS)
    {
        wprintf(L”Error opening or creating the key. Code: %li\n”, createKey);

    }
    else
    {
        LONG setValue;
       
        switch (disposition)
        {
        case REG_CREATED_NEW_KEY:

            //Let’s create the value!
            setValue = RegSetValueEx(openKeyResult, valueName, reserved,
                typeOfData, pData, size);

            if (setValue != ERROR_SUCCESS)
            {
                wprintf(L”Registry value could not be set.\n”);
            }
            else
            {
                wprintf(L”Registry value set.\n”);
            }

            //Let’s query it!
            showValue(openKeyResult, valueNameDefault, flags);
            break;

        case REG_OPENED_EXISTING_KEY:

            //Let’s query the value!
            showValue(openKeyResult, valueNameDefault, flags);
            break;

        }

        //Closing the key.
        RegCloseKey(openKeyResult);

       
    }

    return 0;

}

Lo más interesante de todo esto es que en las variables hKey y subKey estoy apuntando HKLM como clave y Software\WinSide como subclave, así que en teoría siempre debería escribir ahí; sin embargo, el Registry Redirector se encargará de dirigir la escritura a la ubicación física de acuerdo a la arquitectura del proceso, es decir, HKLM\Software\WinSide para x64 y WKLM\Software\Wow6432Node\WinSide para x86.

El resultado

Afortunadamente, Visual Studio me permite cambiar la arquitectura en la que la aplicación compila sin mucho esfuerzo, así que puedo mostrar el resultado fácilmente.

image

Ejecución de la aplicación a 32 bits en Windows de 64 bits

Cuando lanzo DemoApp.exe compilada a 32 bits, recibo este mensaje:

image

Como lo mencioné en la gráfica de la aplicación y en el código, estoy consultando el contenido del valor Default y mostrándolo. Si analizamos la traza con Process Monitor, veremos lo que ocurrió:

SNAGHTMLb91b44

Primero se muestra la operación de RegCreateKey, la cual intenta abrir la clave y si no existe, la crea; luego RegSetValue para crear el contenido del valor Default y finalmente RegQueryValue, operación que remplaza al RegGetValue en el código que expuse anteriormente para obtener el contenido del valor Default y poder imprimirlo después. Noten que todas las operaciones se hacen sobre la ruta HKLM\Software\WOW6432Node\WinSide, puesto que el proceso es de 32 bits.

Al ingresar a las propiedades de la entrada RegCreateKey, pestaña de Stack, puedo ver todas las ocurrencias de las DLLs, encargadas de interceptar las llamadas y realizar la traducción:

image

La aplicación cree que escribe en la ubicación física nativa, pero en cada operación que haga siempre será dirigida a WOW6432Node\WinSide.

Nota: existe una excepción en donde una aplicación puede leer y escribir en la subclave nativa, así el mecanismo del Registry Redirector esté funcionando; solo es necesario ingresar en la máscara de acceso, samDesired, el derecho de acceso KEY_WOW64_64KEY para usarla luego con RegCreateKeyEx, así:

REGSAM samDesired = KEY_READ | KEY_WRITE | KEY_WOW64_64KEY;

Si al ejecutar la aplicación los descriptores de seguridad (los que me dicen si puedo) no me lo deniega, la aplicación escribirá en HKLM\Software, sin hacer dirección a Wow6432Node.

Nota: no tengo idea de cómo se puede establecer esto en desarrollos con .Net, pero me imagino que existe la forma.

Ejecución de la aplicación a 64 bits en Windows de 64 bits

Esto es lo que pasa cuando lanzo la aplicación, compilada a 64 bits, en Windows de la misma arquitectura:

image

Observen que el mensaje ahora es «64-bit app on WINx64», pero es la misma aplicación.

Así se ve en Process Monitor:

image

Al estar la aplicación a 64 bits, no es necesario que actúe la capa de emulación de WOW64, por ende, el mecanismo del Registry Redirector tampoco se activa y la aplicación escribe en la ubicación nativa: HKLM\Software\WinSide.

Lo mismo a nivel de Stack, la comunicación es directa:

image

Eso es todo lo que tengo para escribir sobre el Registry Redirector. Agradezco mucho cualquier corrección, pues me ayudarán a aprender.

Espero escribir próximamente sobre Registry Reflection para ampliar un poco más WOW64.

Saludos,

—Checho

Interpretar las principales operaciones de registro con Process Monitor: RegOpenKey y RegCloseKey

Si alguna vez llegan a utilizan Process Monitor mientras diagnostican un problema o siguen algún comportamiento de Windows, se darán cuenta de que, sin duda alguna, es una herramienta indispensable  para trabajar. Aunque la herramienta no se ve tan compleja después de ejecutarla, el reto más grande pasa por saber interpretar correctamente los resultados de cada traza y resolver el problema. De la necesidad propia de comprenderla nació esta entrada de blog.

Unas de las operaciones más útiles en Process Monitor son las de registro de Windows, puesto que nos permite saber, a ciencia cierta, qué pasó exactamente mientras alguna operación se estaba ejecutando. Sin embargo, no es tan intuitivo ver nombres como RegOpenKey, RegCreateKey o RegSetValue, así que hoy quiero desglosar un poco estas tres operaciones comunes y mostrar cómo se pueden interpretar desde la consola de Process Monitor.

A continuación, describiré un poco qué hace cada operación y luego mostraré cómo se puede leer desde Process Monitor cuando hagamos algún diagnóstico.

Nota: no entraré en detalles demasiado técnicos, no por falta de interés, sino porque me falta el conocimiento para poder hacerlo.

RegOpenKey

La forma más sencilla que encontré para entender esta operación fue trabajar con la función de la API de Windows, RegOpenKeyEx, ya que los resultados que suministra Process Monitor están basados en ella.

La función de RegOpenKeyEx se utiliza, básicamente, para abrir una clave de registro, con el fin de realizar alguna operación adicional con las subclaves, valores de registro o bien crear alguna subclave nueva.

Consideremos la siguiente subclave: HKEY_CURRENT_USER\WinSide.

HKEY_CURRENT_USER o su abreviación, HKCU, es una de las 6 claves raíces que tiene el Registro de Windows, así que siempre va a estar presente y no se puede eliminar. WinSide, por el contrario, es una subclave que puede o no existir dentro de HKCU y se puede modificar.

Para poder comprobar con una aplicación creada en C o C++ que la subclave de WinSide existe, podemos declarar las siguientes variables:

LONG openKey;
HKEY key = HKEY_CURRENT_USER;
LPCWSTR subKey = L”WinSide”;
DWORD options = 0;
REGSAM samDesired = KEY_READ | KEY_WRITE;
HKEY handleKeyResult;
PHKEY phKey = &handleKeyResult;

openKey es la variable necesaria para recibir el tipo de valor retornado por RegOpenKeyEx; en la variable key tenemos el handle a una clave raíz abierta, HKCU; en subKey indicamos la subclave que deseamos abrir; options contiene la opción que aplica al abrir la clave, pero no es relevante con esta función; samDesired especifica los derechos de acceso deseados sobre la subclave que vamos a abrir, en este caso de lectura (KEY_READ) y escritura (KEY_WRITE); y phKey es un apuntador a un tipo de valor HKEY que recibirá otro handle, en caso de que la subclave abra correctamente.

La llamada a la función quedaría así:

openKey = RegOpenKeyEx(key, subKey, options, samDesired, phKey);

La línea anterior intentará abrir la subclave de HKCU\WinSide y asignará el código de error a la variable openKey declarada ateriormente.

Ahora supongamos que haremos una operación desde la aplicación para intentar abrir la subclave de WinSide, pero la validación sobre error será básica, por ejemplo:

if (openKey != ERROR_SUCCESS)//Si no abre la clave

wprintf(L”No pude abrir la subclave %s. Código: %li\n”, subKey, openKey);

else //Si la clave abre.
{
wprintf(L”La clave %s fue abierta.\n”, subKey);

//Cerrar handle para la clave
 RegCloseKey(*phKey);
}

En la validación anterior estoy validando si (if) openKey es diferente a ERROR_SUCCESS, es decir, cualquier otro mensaje inválido. En caso de que esto pase, mostraré un mensaje que me indica el código de error retornado por el manejador de errores de Windows. Si el valor retornado por la función es ERROR_SUCCESS, el programa se va para el else, así que muestro el mensaje satisfactorio y luego proceso a cerrar el handle de la clave con la función RegCloseKey.

Si yo ejecuto el programa sin crear la subclave de WinSide, el resultado se vería así:

image

Hasta aquí he mostrado la cara desde el desarrollo, así que sería relativamente fácil identificar qué está sucediendo y a qué hace referencia el número dos en el código. Sin embargo, la idea de esta entrada es aprender a interpretar lo que está sucediendo desde Process Monitor, pues casi siempre no tendremos acceso al código. Veamos cómo podríamos utilizar Process Monitor para deducir casi todo lo que he mostrado en código.

Primero, es necesario establecer algunos filtros en Process Monitor para que solo muestre los resultados de la aplicación RegApp.exe cuando está haciendo operaciones de registro, incluir lo que contenga WinSide y excluir todo lo demás. Después de configurar los filtros, basta con reproducir el resultado en consola que mostré antes mientras monitoreo con Process Monitor y empezar a analizar el resultado:

image

Interpretemos cada columna:

Process Name: RegApp.exe es el nombre de proceso que se está ejecutando y que está realizando la operación descrita en la tercera columna. Esto siempre es importante, puesto que sabemos de primera mano quién está tratando de realizar manipulaciones en el registro.

PID: cada que sea crea un proceso en Windows se le asigna un identificador de proceso con el que el sistema operativo sigue trabajando hasta que se termina el proceso. En cada nueva ejecución se crea un nuevo Identificador de proceso (PID).

Operation: como vemos en la captura de pantalla, la operación que está realizando la aplicación es la de RegOpenKey, es decir, tal cual lo vimos con la función de la API, está tratando de abrir una subclave de registro. Cada que veamos esta operación podemos tener la certeza de que la aplicación solo está tratando de abrir la subclave de registro y no creándola; opción que sí tiene la operación de RegCreateKeyEx, que veremos después. La subclave sobre la que está trabajando se muestra en la siguiente columna.

Path: esta es una de las columnas más importantes, puesto que me indica en qué ruta exacta, en este caso de registro, se está desarrollando la operación descrita anteriormente. En el caso de la captura anterior y de la aplicación que mostré, la ruta es HKCU\WinSide; como pueden recordar, HKCU es la abreviatura de HKEY_CURRENT_USER, así mismo lo hace con las demás claves raíces.

Result: de esta columna depende, la mayoría de las veces, seguir analizando la entrada o pasar a una próxima. Lo que vemos aquí es el resultado de la operación que la aplicación intentó hacer. El texto que muestra es el código de error devuelto por Windows, pero un poco más abreviado, y será de gran importancia de acuerdo al código que se reciba. Algunos de los más comunes son: SUCCESS, ACCESS DENIED, PATH NOT FOUND, NAME NOT FOUND, etc.

Para el caso de la captura anterior, el resultado arrojado es NAME NOT FOUND, el cual indica que la subclave de registro no existe en la ruta que está buscando.

Detail: aquí podemos ver información adicional de la operación específica que está realizando la aplicación; en el caso de las operaciones de registro, podemos ver la máscara de acceso que solicitó la aplicación. Si nos devolvemos un poco a la primera porción de código, yo declaré una variable llamada samDesired en la que pedí los derechos de acceso KEY_READ y KEY_WRITE, es decir, de escritura. En Process Monitor se ve como Desired Access: Read/Write.

Con la máscara de acceso podemos saber qué quiere hacer la aplicación con la subclave, por ejemplo, poder leer y escribir nuevo contenido, pero es el descriptor de seguridad el que tiene la última palabra sobre lo que en verdad puede hacer en la subclave. Es un tema complejo de seguridad en el que no entraré por falta de conocimiento.

La idea es ir leyendo los resultados de izquierda a derecha para poder entenderlos correctamente. Si resumimos todo, podemos decir que el proceso RegApp.exe, que tiene un identificador de proceso 3956, está intentando abrir la subclave de registro de HKCU\WinSide, pero no la encontró, lo cual indica que no está creada. Los derechos de acceso que había solicitado la aplicación era de escritura y de lectura.

Si queremos ver todo estos detalles un poco más agrupados, podemos hacer doble clic sobre la entrada o clic derecho y seleccionar Properties. Incluso podemos comparar con las declaraciones que hice en el código para que veamos qué tanto detalle puedo extraer con Process Monitor.

image

¿Qué pasa si la subclave de WinSide existe? Ejecutando la aplicación, el resultado sería este:

SNAGHTML20c388f

Del lado de Process Monitor, podremos ver un poco más de detalles:

SNAGHTML20f8e90

No tiene caso volver a describir cada columna, así que me concentraré en la lectura. La primera operación dentro de las tres que están resaltadas en la captura es la de RegOpenKey, que intenta abrir la subclave HKCU\WinSide y esta vez, a diferencia de lo que mostré, el resultado es SUCCESS, quiere decir que la subclave estaba creada en el registro de Windows. La máscara de acceso sigue conteniendo escritura y lectura (Read/Write), por ende, podrá crear otras subclaves o valores, a menos que el descriptor de seguridad de la subclave no lo permita.

El resultado de SUCCESS es equivalente a cero y en el código entraría en el else:

else //Si la clave abre.
    {
        wprintf(L”La clave %s fue abierta.\n”, subKey);

        //Cerrar la clave.
        RegCloseKey(*phKey);

    }

Después de esto hay una operación llamada RegSetInfoKey que ignoraremos por ahora; luego aparece la operación de RegCloseKey, la cual está encargada de cerrar el handle abierto cuando el trabajo con la subclave está terminado. La operación de RegCloseKey no tiene mayor ciencia, mas voy a tocar unos detalles que encontré interesantes cuando escribía esto.

RegCloseKey

El trabajo de la función RegCloseKey, como ya lo mencioné, es el de cerrar el handle abierto que obtuvimos con RegOpenKeyEx. El código para cerrarlo en la aplicación Si en el código no cerramos manualmente el handle, Windows lo hará eventualmente, pues va cerrando todo lo que esté abierto antes de hacerlo con la clave raíz de HKEY_CURRENT_USER.

Lo anterior se puede comprobar quitando del código la llamada a RegCloseKey; después de ejecutado y analizado con Process Monitor, se puede ver que el handle se cierra más adelante:

SNAGHTML221c921

Lo ideal es que esto esté gestionado desde el código de la aplicación y no dejarle la tarea a Windows. Desde Process Monitor sería muy complicado saber si desde el código el handle se cerró después de la operación en registro, pero si es así, generalmente estará la operación de RegCloseKey justo después de terminadas las otras tareas con la subclave de registro.

En la próxima entrada referente a esto, me enfocaré en interpretar la operación de RegCreateKey y luego en RegSetValue. La función de RegCloseKey la seguiré mostrando, pero no con detalles.

Traté de acertar lo más que pude, pero igual podría haberme equivocado en algunos aspectos, puesto que es un tema muy ligado a Windows Internals. ¡Comentarios bienvenidos!

Saludos,

—Checho