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