Por qué el Registro de Windows es técnicamente tonto (2010)

Es bastante común denigrar el registro de Windows en términos no técnicos o ligeramente técnicos. Acabo de pasar unas semanas realizando ingeniería inversa completa del formato binario para nuestra biblioteca hivex y nuestro shell, que ahora admite lectura y escritura en el registro. Así que ahora puedo decirles por qué el registro también apesta técnicamente.

1. Es una implementación medio vacía de un sistema de archivos

A menudo se dice que el registro es un "archivo monolítico", en comparación con el almacenamiento de la configuración en muchos archivos discretos como, por ejemplo, Unix lo hace en /etc. Esto no entiende el punto: el registro es un sistema de archivos. Por supuesto, se almacena en un archivo, pero también lo es ext3 si elige almacenarlo en un montaje de bucle. El formato binario del registro tiene todos los aspectos de un sistema de archivos: elementos correspondientes a directorios, inodos, atributos extendidos, etc.

La principal diferencia es que este formato de sistema de archivos de registro es medio tonto. El formato está mal construido, es frágil, es específico de Endian, está subespecificado y es lento. El formato cambia de una versión a otra de Windows. Algunas partes no están documentadas, aparentemente para los propios desarrolladores de Windows (a juzgar por los símbolos de depuración de NT reproducidos en un artículo). Algunas partes del formato desperdician espacio, mientras que otras estúpidas "optimizaciones" se realizan para ahorrar un puñado de bytes (a costa de hacer que el acceso sea mucho más complejo).

2. Hola, programadores de Microsoft, un volcado del núcleo no es un formato de archivo

El formato es básicamente un volcado de estructuras C de 32 bits en una pila de memoria C. Esto probablemente se hizo originalmente por velocidad, pero abre el formato a todo tipo de problemas:

Puede ocultar elementos en bloques no utilizados. Puede crear registros que contengan bloques, bucles o punteros que sean inaccesibles fuera del montón y que provoquen que Windows se bloquee o se cuelgue (consulte el punto 3). Es endian y específico del tamaño de palabra. Depende del empaque de la estructura del compilador original alrededor de 1992.

3. La implementación de lectura/escritura del registro en Windows NT es deficiente

Se podría esperar, dada la importancia del registro para la integridad de Windows, que las personas que escribieron el código que lo carga habrían pasado algún tiempo pensando en comprobar la coherencia del archivo, pero aparentemente esto no se hace.< /p> Todas las versiones de Windows probadas simplemente ignorarán los bloques que no estén alineados correctamente. Igual, ignorará las entradas del directorio que no estén en orden alfabético (simplemente deja de reproducirse en el primer lugar en que encuentra un subdirectorio llamado B > siguiente entrada A). Igual, ignorará las entradas de archivos que contengan varios tipos de campos no válidos.

El resultado de esto es que puede ocultar fácilmente elementos en el registro binario que son completamente invisibles para Windows, pero que serán evidentes en otras herramientas. Desde la perspectiva de otras herramientas (como nuestra herramienta hivex), debemos escribir exactamente los mismos bits que escribiría Windows, para asegurarnos de que Windows podrá leer el . Todos los errores que cometemos, incluso los aparentemente insignificantes, son castigados en silencio.

Compare esto con el uso de un formato de sistema de archivos establecido, donde todos conocen las reglas y la coherencia (p. ej., fsck/chkdsk) es importante.

La escritura también apesta, porque los programadores no ponen correctamente a cero los campos, por lo que encontrará partes (especialmente el encabezado de registro) que contienen bits aleatorios de memoria, presumiblemente memoria del kernel, volcados en el archivo. Todavía no he encontrado nada interesante...

También encontré registros que contenían bloques inaccesibles (no, debo agregar, los que había tratado de modificar). Me resulta muy extraño que las máquinas virtuales Windows 7 creadas relativamente recientemente, que no tienen ningún tipo de infección de virus, tengan daños visibles en el registro.

4. Los tipos no están bien especificados

Cada campo de registro se escribe superficialmente, por lo que REG_SZ es una cadena y REG_EXPAND_SZ también es una cadena. ¿Buen derecho? No, porque lo que cuenta como una "cadena" no está bien definido. Una cadena se puede codificar en ASCII de 7 bits o UTF-16-LE. La única forma de saberlo es saber qué versiones de Windows usarán el registro.

Las cadenas también se almacenan en campos REG_BINARY (en varias codificaciones), pero los datos binarios sin procesar también se almacenan en estos campos.

Considérese afortunado si solo accede a los campos oficiales de Microsoft, ya que algunas aplicaciones no se limitan a los tipos publicados y solo usan el campo de tipo para lo que quieran.

¿Y tú qué eres...