Escuela Técnica de Ingeniería Informática de Gijón
3º Ingeniería Técnica en Informática de Sistemas

Conservar el registro de usuario tras reinstalar Windows

Autor: Ángel González Berdasco

Fecha: 12 de mayo de 2008

Objetivos

Este trabajo detalla cómo conservar el registro de un usuario limitado en un sistema Windows XP.

Disclaimer

Este trabajo tiene como finalidad la divulgación de mi investigación personal para que pueda servir a otros. No doy ninguna garantía de éxito. Todos los cambios que realice son bajo su responsabilidad. No se lo recomiendo a menos que sea un usuario experto.

El sistema utilizado es Windows XP. Aunque es probable que funcione en otras versiones de Windows, es terreno inexplorado.

Situación de partida

Suponemos un sistema Windows XP independiente (no conectado a ningún dominio) con un usuario de nombre PocaCosa que trabaja como usuario limitado (tal y como se debe hacer).

Debido a jugarretas del destino (o del SO), tiene que reinstalar el sistema operativo, perdiendo con ello la configuración personalizada del sistema, que busca mantener.

Nota: Nada impide efectuar las operaciones descritas en este documento en un sistema que hubiera sido reinstalado hace tiempo, o incluso incluyendo datos el registro de usuario desde otro ordenador, no obstante tomamos esta situación de partida debido a que:

• Es el caso más probable en que haga falta realizar estas operaciones.
• Cuanto más difiera el sistema original del final (programas instalados o desinstalados, archivos movidos de sitio, variaciones en las unidades de disco), mayor es la probabilidad de incompatibilidades al incluir datos provenientes de otra configuración.
• Si hay problemas al restaurar el registro, es probable que haga falta reinstalar Windows. Por lo tanto, si estamos con un sistema recién instalado, no tenemos nada que perder.

El registro

¿Qué es el registro y por qué querría conservarlo?

El registro es un lugar, cerca del caos, donde cientos de programas escriben y leen los datos que les parece.

En él hay almacenados datos que van desde la información del hardware o los programas instalados hasta la configuración de ventanas, el fondo de escritorio y los últimos documentos abiertos por el programa X. Nuestro objetivo es restaurar estos últimos datos, que son los relativos al usuario, de HKEY_CURRENT_USER. Cuando se reinstala Windows encima de otra versión, ya se conserva parte de los datos del sistema (HKEY_LOCAL_MACHINE) y sería imprudente cambiarlos por una versión potencialmente incorrecta (el motivo original para la reinstalación pueden haber sido perfectamente unos valores no válidos en el registro).

Entonces, ¿es peligroso?

En principio no. No son más que datos. Configuraciones como en qué posición dejaste abierta la ventana del programa para ponerla en el mismo sitio al volver a abrirlo, o el último programa abierto. Obviamente no hay ningún peligro si se pierden estos datos, y los daños que pueden causar no pasan de una inconveniencia. La posibilidad de problemas aumenta debido a que el registro también se usa para localizar programas a ejecutar (principalmente ActiveX y componentes críticos para el arranque de Windows).

¿Cómo puedo ver su contenido?

La forma más sencilla de explorar el contenido del registro es abriendo el programa C:\WINDOWS\regedit.exe1.

Pantalla del editor del registro de Windows

Estructura

Como se puede observar en la imagen anterior, el registro se divide en cinco ramas: HKEY_CLASSES_ROOT, HKEY_CURRENT_USER. HKEY_LOCAL_MACHINE, HKEY_USERS, HKEY_CURRENT_CONFIG, a menudo abreviadas HKCR, HCKCU, HKLM, HKU y HKCC respectivamente. Existen además las claves virtuales2 HKEY_PERFORMANCE_DATA, HKEY_PERFORMANCE_NLSTEXT y HKEY_PERFORMANCE_TEXT que sirven de interfaz para obtener información sobre rendimiento.

HKEY_CLASSES_ROOT

Contiene información que asocia las extensiones de los ficheros con su icono, los programas que los abren, etc. En su clave CLSID contiene los GUIDs del sistema asociándolos con la situación en disco y configuración del servicio que proveen. Forma parte del corazón de OLE y COM, de hecho la consulta de estas subclaves es automática por parte de CoCreateInstance 3.

Originalmente, era la única clave del registro y se almacenaba en REG.DAT4. En la actualidad, HKEY_CLASSES_ROOT monta la clave HKEY_LOCAL_MACHINE\SOFTWARE\Classes combinada -en las últimas versiones de Windows- con la de HKEY_CURRENT_USER\SOFTWARE\Classes5.

HKEY_CURRENT_USER

Contiene información relativa al usuario actual del programa. Es el sitio donde los programas deberían guardar las preferencias del usuario. Conviene tener en cuenta que no está disponible cuando aún no ha iniciado sesión el usuario, situación en la que están por ejemplo los programas que se ejecutan automáticamente al arrancar el sistema.

Si la información del perfil no está disponible (por ejemplo se trata de un perfil remoto y no tenemos conexión de red), se cargan los datos del usuario por defecto6.

HKEY_LOCAL_MACHINE

Contiene información general para la máquina. Desde datos de arranque del Sistema Operativo hasta los valores predeterminados de programas. En las nuevas versiones de Windows, sólo tienen permiso para modificarla usuarios del grupo Administradores.

HKEY_USERS

En este subárbol se montan los perfiels de cada usuario. Por cada usuario se montan dos claves. La primera con el SID del usuario y la segunda con el SID del usuario con el sufijo "_Classes". Esta última es en realidad un alias de \SOFTWARE\Classes dentro de la anterior.

HKEY_CURRENT_CONFIG

Contiene las diferencias entre el hardware actual y el predeterminado. Monta el contenido de HKEY_LOCAL_MACHINE\System\CurrentControlSet\Hardware Profiles\Current 7.

HKEY_PERFORMANCE

El subárbol HKEY_PERFORMANCE_DATA contiene información de rendimiento (contadores)8. Se trata únicamente de una interfaz, los datos se obtienen del origen en cada llamada, no son guardados en el registro. HKEY_PERFORMANCE_TEXT y HKEY_PERFORMANCE_NLSTEXT contienen la descripción de los contadores en inglés y el idioma local del usuario, respectivamente 7.

¿Dónde se guarda?

En las versiones de Win9x HKEY_LOCAL_MACHINE y HKEY_CURRENT_USER se amacenaban respectivamente en C:\WINDOWS\SYSTEM.DAT y C:\WINDOWS\USER.DAT. En Windows Millenium se añadió C:\WINDOWS\CLASS.DAT9.

En las versiones de Windows NT dentro de una serie de ficheros en C:\WINDOWS\system32\Config Los archivos SECURITY SAM software system contienen sus respectivas claves dentro de HKEY_LOCAL_MACHINE , mientras que el archivo default contiene HKEY_USERS\.DEFAULT. Por su parte, almacena HKEY_CURRENT_USER en el archivo NTUSER.DAT del directorio del usuario, normalmente C:\Documents and settings\NombreDeUsuario\NTUSER.DAT 10.

Recuperar el registro de usuario de una cuenta

Planteamiento

Tras reinstalar Windows, queremos restaurar una cuenta incluyendo sus datos almacenados en el registro. Esto es, restaurar HKEY_CURRENT_USER. No recomiendo intentar restaurar HKEY_LOCAL_MACHINE. Tras importar en una máquina dicha clave de otra, dejó de arrancar 11.

Creación de la cuenta de usuario

Proceso de creación de carpetas de perfil

El primer paso a la hora de reinstalar Windows para mantener la cuenta de usuario PocaCosa es que no vamos a crearla directamente o durante la instalación. Veamos un poco por qué.

Los programas y las rutas de configuración que queremos restaurar apuntarán a la carpeta del usuario (su HOMEPATH 12). Por lo tanto nos interesa que se mantenga el mismo. Puesto que estas rutas son del tipo C:\Documents and Settings\NombreDeUsuario, en principio al crear un usuario cuya carpeta de perfil ya exista podríamos esperar que lo aprovechase, incluso aunque sobreescribiese los datos del registro. Pero Windows XP toma un enfoque distinto: al crear una nueva cuenta, se asegura de que todo sea nuevo, estableciendo como carpeta de usuario una que no exista 13. Cuando se crea un usuario a la hora de asignarle una carpeta a su perfil se intenta con las siguientes rutas:

1. C:\Documents and Settings\NombreUsuario
2. C:\Documents and Settings\NombreUsuario.NombreMáquina
3. C:\Documents and Settings\NombreUsuario.NombreMáquina.000
4. C:\Documents and Settings\NombreUsuario.NombreMáquina.001
5. C:\Documents and Settings\NombreUsuario.NombreMáquina.002
6. ...y así sucesivamente.

Patrón de generado de las carpetas para los perfiles de usuario. Usuario Juan en la máquina XP

Cuando llega a C:\Documents and Settings\NombreUsuario.NombreMáquina.999 no puede crearlo y pasa a usar perfiles temporales, que utilizan el mismo patrón:

• C:\Documents and Settings\TEMP
• C:\Documents and Settings\TEMP.NombreMáquina
• C:\Documents and Settings\TEMP.NombreMáquina.000
• C:\Documents and Settings\TEMP.NombreMáquina.001

Llegados a 999, muestra un mensaje avisando que no puede crear un directorio de perfil temporal y no se puede entrar con la cuenta hasta que se borre alguna de las carpetas.

Engañando a Windows

Se hace preciso por tanto engañar a Windows para que use como carpeta de perfil la que ya existe. Una forma de hacerlo sería modificar el sitio donde Windows almacena la situación de la carpeta de perfil para que apunte a la carpeta inicial. O bien hacer que la carpeta inicial ya tenga el nombre apropiado.

Cambiar la posición de la carpeta de perfil

La situación de las carpetas de perfil de usuario se encuentra En HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\ hay una clave por cada usuario del sistema. Dentro de ella el valor ProfileImagePath indica la situación de la carpeta del perfil de usuario. Por lo tanto basta con cambiar en la clave en que se encuentre %SystemDrive%\Documents and Settings\NombreUsuario.NombreMáquina por %SystemDrive%\Documents and Settings\NombreUsuario.

Intercambiando las carpetas

También podemos renombrar las carpetas para que la cree con el nombre apropiado:

1. Renombrar la carpeta original a otro nombre
2. Crear la cuenta del usuario. Por el momento la crearemos de tipo administrador.
3. Entrar en sesión con dicha cuenta para que se cree la carpeta de perfil. Cerrar dicha sesión.
4. Borramos la carpeta recién creada y devolvemos el nombre a la carpeta original.

Con cualquiera de ambas alternativas, si a continuación iniciamos sesión deberíamos encontrarnos con la antigua configuración de la cuenta.

Limitando la cuenta

Desgraciadamente, si convertimos la cuenta en limitada, perdemos la configuración 14, aparece la configuración por defecto. De nuevo hay dos alternativas:

• Decidir que a fin de cuentas no se está tan mal trabajando siempre como administrador y olvidarse del tema.
• Seguir los pasos del resto del artículo para conservar la antigua configuración incluso como usuario limitado.

Permisos

¿Qué es lo que diferencia a un usuario limitado de uno administrador? Los permisos que tiene. Aunque no se nos muestre ningún error, al iniciar sesión como usuario limitado se está denegando el acceso a una serie de archivos a los que como administradores teníamos acceso.

¡Pero si antes accedía!

Bien, no exactamente. En la configuración original el usuario PocaCosa tenía acceso, pero el nuevo usuario PocaCosa no. Esto es así debido a que aunque tengan el mismo nombre, son usuarios diferentes. El sistema operativo no identifica a las cuentas por el nombre, sino usando un identificador. En los sistemas de tipo unix se trata de un entero, a veces de 16 bits, a veces de 32. Windows NT utiliza SIDs (Security IDs), de 96 bits.

Teoría de SIDs

Windows identifica los ordenadores y las cuentas de usuario mediante SIDs. Cada máquina tiene un identificador de 96 bits, al cual se le agrega un contador (que empieza en ) por cada cuenta que se crea en el sistema. Las cuentas de usuarios normales tienen el SID de la forma S-1-5-21-<SID máquina>-<contador usuarios>, por ejemplo S-1-5-21-1234567890-0987654321-0123456789-1002. El prefijo S-1-5-21 indica que se trata de una cuenta de usuario. Otros prefijos tienen diferente significado. Así, la cuenta del sistema tiene de SID S-1-5-18, la de servicios locales S-1-5-19 y los de red S-1-5-1915. Si en vez de identificar a un grupo, identifica a un grupo predeterminado, el identificador será de la forma S-1-5-32-<contador> Otros valores especiales son que el SID del usuario Administrador acaba en 500 (S-1-5-21-1234567890-0987654321-0123456789-500) y el del Invitado en 501. 16 17.

Podemos ver por tanto que el código de la máquina toma un importante valor en los SID. Que es precisamente el que ha sido sobreescrito al reinstalar windows. Si sigue habiendo acceso como administrador es simplemente porque el SID del grupo administradores, S-1-5-32-544, no contiene el id de la máquina sino que es fijo.

Nos encotnramos los SIDs en todos sitios, en los permisos, en las claves del registro... En HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\ hay una clave por cada usuario que tienen de nombre el número en hexadecimal del contador de la cuenta en el sistema, y en HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\Names tenemos los nombres, almacenando ese númeroi en el tipo del valor predeterminado.

Si miramos en el dato binario V de la carpeta con el código del usuario, por ejemplo HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\000001F4, tenemos al final —en Unicode— el nombre de la cuenta y su descripción, en este caso "Administrator - Built-in account for administering the computer/domain", y un poco más arriba (offset 158), el SID de la cuenta, pero en binario.

Para pasar a binario el SID18 basta con calcular el valor hexadecimal de cada segmento e invertir los bytes (esto es, almacenar el número en little endian). Así, el SID S-1-5-21-1234567890-0987654321-0123456789-500 correspondería a la cuenta de administrador de la máquina 1234567890-0987654321-0123456789.

1234567890 = 0x499602D2 -> D2029649
0987654321 = 0x3ADE68B1 -> B168DE3A
0123456789 = 0x075BCD15 -> 15CD5B07
Cuenta de usuario: 500 = 0x1F4

Por lo que en el offset 158 del valor binario HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\000001F4\V aparecerá D2029649B168DE3A15CD5B07F401.

Obtener el SID

No obstante, de poco sirve saber cómo trabajar con SIDs si no sabemos cómo obtrenerlos. Hay programas específicos para ello, como PsGetSid, pero no necesitamos tanto. La manera más sencilla de mirar el SID del usuario actual es mirar la clave de usuario (se distingue por su longitud) montada en HKEY_USERS cuando sólo ha iniciado sesión un usuario. Para averiguar el antiguo SID basta con mirar los permisos que tiene una carpeta en la que tuviera privilegios. Puesto que el SID ya no está a asociado a un nombre de usuario, se mostrara tal cual.

Cambiando SIDs

Al reinstalar Windows, cambia el SID de la máquina. Por lo tanto, también cambian los SIDs de las cuentas locales y los usuarios que antes tenían permisos para acceder ya no lo tienen. Tenemos dos opciones, adaptar el entorno existente a los nuevos SIDs o intentar recuperar los antiguos.

Recuperar los antiguos SIDs

Dado que los SIDs de los usuarios están basados en el SID de la máquina, cambiando el SID de la máquina por el anterior. Si a continuación creamos los usuarios en el mismo orden en que fueron creados en la máquina original, les serán asignados los mismos SIDs.

No hay demasiadas utilidades que permitan modificar el SID de una máquina, estando la mayoría de ellas dentro de paquetes de clonación. Una buena opción es NewSID19 de Mark Russinovich y Bryce Cogswell, que nos permite cambiar el SID por el que queramos (en este caso el SID anterior).

El mayor inconveniente es que se trata de un proceso crítico (no se debe interrumpir) y —cuando el disco duro es grande— muy largo (días). Por lo que si pensando que se ha colgado interrumpes el proceso, puedes encontrarte en una situación como esta:

Adaptarse a los nuevos SIDs

Esta opción resulta más segura al no tener que cambiar datos por toda la máquina.

Carpetas y archivos

Para empezar, hay que darle permisos al nuevo dueño a todas las carpetas que vaya a usar, como mínimo C:\Documents and Settings\PocaCosa. Preferiblemente, mediante la GUI de la pestaña seguridad de las propiedades de carpeta (sólo aparece si está desactivado el uso compartido simple de archivos20).

Desgraciadamente, esta opción sólo está disponible en las versión Profesional de Windows XP. Si podemos usarla tendremos que conformarnos con ejecutar en una ventana de comandos:

cacls "C:\Documents and Settings\PocaCosa" /T /E /C /G PocaCosa:F 

El resultado es igualmente satisfactorio, otorga permisos completos a PocaCosa dentro de su carpeta de perfil, pero es menos eficiente ya que en vez de aprovechar las normas de herencia efectuará una recursión, y puede tardar cierto tiempo 22.

Ventana de permisos. Puede observarse cómo tiene permisos sobre ella un SID del cual no conocemos su cuenta.

Registro

Una vez hayamos otorgado permisos al nuevo usuario en su carpeta, tendremos una experiencia mucho más satisfactoria, pero no obstante seguimos sin haber recuperado las preferencias del registro, pese a que ahora tenemos permisos sobre el archivo ntuser.dat que contiene el registro de usuario. ¿Por qué seguimos sin poder acceder a nuestro HKEY_CURRENT_USER? Sencillo. Tenemos permiso sobre el archivo del registro, pero no sobre el registro.

El registro tiene su propia serie de permisos:

Nos interesa cambiar tres cosas en el registro:

• Los permisos de las claves.
• Las referencias al SID en decimal.
• Las referencias al SID en binario.

Podemos hacerlo a mano, montando la antigua clave de usuario23 y modificándola24. Puesto que los permisos se obtienen en su mayoría por herencia, seguramente sería factible. La opción de Buscar en el registro resulta útil (no hay opción reemplazar), pero si en algún sitio hay referencias al SID por su código binario, o por nombre dentro de valores binarios, no las encontraremos.

Por lo tanto, yo me inclino por una opción más arriesgada, que es reemplazar con un editor hexadecimal todos los valores del SID, tanto en decimal como en binario↑, por el del nuevo. Este no es un procedimiento kosher, ya que al modificar a ciegas un archivo binario podemos estar dañando irrecuperablemente25 su estructura.

No obstante, jugamos con dos importantes factores a nuestro favor:

• Estamos sustituyendo valores por otros de la misma longitud, lo cual mantiene la alineación de los campos y la longitud de los valores26.
• Gracias a la longitud de los SIDs, resulta improbable que aparezca en otro contexto. Nos interesa reemplazar todas las apariciones del SID en decimal (las reemplazaríamos de todos modos si usaramos la GUI) y resulta poco probable que aparezcan los 12 bytes correspondientes al SID en binario sin referirse al SID que queremos reemplazar (a saber: en ACLs y valores binarios).

Por lo tanto, si queremos sustituir el SID antiguo S-1-5-21-1234567890-0987654321-0123456789-1002 por el nuevo S-1-5-21-5566778899-3344221100-3246897510-1002, reemplazaríamos las cadenas S-1-5-21-1234567890-0987654321-0123456789-1002 por S-1-5-21-5566778899-3344221100-3246897510-1002 y D2029649B168DE3A15CD5B07 por 53747486ACC354C766B987C1.

Mi experiencia es positiva al respecto, pero YMMV, los datos de cada registro son diferentes, incluso con los mismos contenidos, variarán timestamps, datos borrados...

Inconvenientes

Estoy escribiendo esto en una cuenta a la que se le ha aplicado el anterior procedimiento hace ya cerca de un año, sin que haya producido ningún problema. Únicamente hay un efecto colateral, probablemente debido a que quedaría algún paso por dar, y es que en la cuenta donde se realiza fallan las verificaciones de certificados de wintrust. La llamada WinVerifyTrust devuelve TRUST_E_SYSTEM_ERROR en cada archivo firmado. En la práctica, no limita el uso normal del ordenador, aparte de ejemplos27, sólo he visto que afecte a la pestaña Firmas digitales de los programas firmados digitalmente y a la versión Live de MSN Messenger28. Se recomienda utilizar una cuenta original para la realización de comprobaciones criptográficas con Wintrust.

Conclusiones

Hemos analizado con bastante profundidad el sistema de cuentas y permisos de Windows, junto detalles de bajo nivel de su implementación, lo cual da un mayor conocimiento de cómo se está comportando la máquina. Ello nos ha permitido, partiendo de una serie de conocimientos generales sobre el registro y los perfiles, recuperar unos datos que podían considerarse perdidos al haber sido almacenados en el registro de Windows en lugar de en ficheros independientes.

Como ampliación, podría considerarse mejorar el proceso mediante una aplicación que automatice la conversión de los SIDs, respetando las estructuras internas del registro29.

Notas

1. ↑ Las referencias a C:\WINDOWS a lo largo de todo el artículo se refieren a la carpeta donde se haya instalado Windows.
2. ↑ Esto es, más virtuales que las demás en el sentido que no se modifican y su información no siemrpe está guardada.
3. ↑ http://www.codeproject.com/KB/COM/Emul_CoCreateInstance.aspx.
4. ↑ How did registry keys work in 16-bit Windows?
5. ↑ HKEY_CLASSES_ROOT
6. ↑ HKEY_CURRENT_USER
7. ↑ ↑ Predefined Registry Keys
8. ↑ Performance Data Format
9. ↑ Separación en CLASS.DAT de componentes no esenciales. Confirmación del uso de class.dat en kb256986
10. ↑ En una configuración estática. Cuando se trabaja con perfiles móviles esto varía.
11. ↑ No, no fue problemático. Se trataba de una máquina virtual cuyo estado acababa de guardar :-)
12. ↑ La carpeta del usuario contiene a su vez carpetas como Escritorio, Mis Documentos o Datos de programa. Puede obtenerse de las variables del entorno con %HOMEDRIVE%%HOMEPATH%.
13. ↑ Lo cual, por otra parte elimina problemas de permisos y confidencialidad de los archivos que hubiera.
14. ↑ En caso de que se convierta la cuenta en limitada desde la propia cuenta, conviene recordar que el cambio de permisos no es efectivo hasta el próximo inicio de sesión.
15. ↑ De este modo, un programa que se ejecute como LocalSystem tendrá el mismo SID en todos los ordenadores, mientras que el SID de los usuarios cambiará dependiendo del ordenador en el que se le haya creado la cuenta. En el caso de las cuentas de dominio, el SID no depende de la máquina sino del dominio.
16. ↑ KB243330: Identificadores de seguridad bien conocidos en los sistemas operativos Windows.
17. ↑ KB163846: SID Values For Default Windows NT Installations.
18. ↑ Debo agradecer toda esa información a efsrecovery .
19. ↑ NewSID. Incluye bastante información técnica sobre el proceso de cambiar los SIDs.
20. ↑ Herramientas, Opciones de carpeta, Ver, Utilizar uso compartido simple de archivos. Ver ventana
21. ↑ Cambia las acls de "C:\Documents and Settings\PocaCosa" de forma recursiva (/T) manteniendo los valores ya existentes (/E), omitiendo errores (/C) y dando (/G) al usuario PocaCosa permisos totales (Full).
22. ↑ http://articles.techrepublic.com.com/5100-10878_11-1050976.html
23. ↑ Seleccionamos HKEY_USERS y escogemos la opción Cargar subárbol del menú Archivo.
24. ↑ Recomiendo encarecidamente mantener en todo momento una copia intacta por si hubiera algún problema en el proceso.
25. ↑ Es decir, si no se hizo la copia de seguridad que menciono en el punto anterior.
26. ↑ El registro almacena todos los valores junto con su longitud, de modo que es robusto para almacenar datos binarios (lo cual puede ser inconveniente en ocasiones).
27. ↑ Ejemplo de cómo verificar la firma digital de un archivo ejecutable.
28. ↑ Cada vez que intenta iniciar sesión, se descarga http://clientconfig.passport.net/ppcrlconfig.bin, una librería que contiene en un recurso los datos de a dónde conectarse. Debido a la forma en que se cargan si fuera sustituido maliciosamente, se podría ejecutar código, por lo que realiza antes una comprobación de firma digital mediante Wintrust. Ante un TRUST_E_SYSTEM_ERROR fallará con el críptico error 8004888d.
29. ↑ Hay programas de código abierto capaz de trabajar con las hives de Windows, como ReactOS, que es compatible binariamente con ellas, por lo que no sería necesario partir de cero para descubrir el formato (pese a la poca documentación).

Licencia

Este trabajo está disponible bajo una licencia dual Creative Commons Reconocimiento-CompartirIgual 3.0 y GNU Free Documentation License 1.2 o posterior.