![]()
Repasando unas anotaciones de finales del 96 para escribir la guía sobre POLEDIT me he encontrado con esto...
POLEDIT
"Desactivar herramientas de edición del Registro de configuraciones", se supone que desactiva la ejecución de REGEDIT.EXE, pero no es Windows el que lo impide, es el propio REGEDIT el que no se deja cargar.
En su momento, el tema de impedir la ejecución de un determinado programa me pareció interesante, y dedique un poco de tiempo a estudiar la forma en que Windows impedía la ejecución de REGEDIT. Me sorprendió ver que no es Windows el que impide esa ejecución, y jugando, jugando, encontré la forma de saltarme esa restricción.
Cuando se activa la restricción "Desactivar herramientas de edición del registro de configuraciones" con POLEDIT, lo que se está haciendo es impedir la ejecución de REGEDIT.EXE, y si se intenta iniciar, el sistema responderá con esta ventana...
Al no poder iniciar REGEDIT no podremos desactivar ninguna otra restricción aplicada al equipo, que se base en modificaciones del registro de Windows.
La activación de la restricción que impide ejecutar REGEDIT queda reflejada en el registro, en esta clave...
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System]
... con un valor de tipo DWORD de nombre "DisableRegistryTools" puesto a "1" cuando la restricción está activada.
Aquí está la gracia del asunto. A primera vista parece que si el valor "DisableRegistryTools" de esa clave del registro esta puesto a "1", lo que impide la ejecución de REGEDIT.EXE es el propio Windows.
Lo primero que se te puede pasar por la cabeza es renombrar el ejecutable para saltarse el seguimiento que pueda hacer Windows de ese nombre de archivo... no funciona. De alguna manera, Windows sabe que REGEDIT sigue siendo REGEDIT, a pesar de tener otro nombre de archivo.
Esto me llevó a pensar que REGEDIT informaba de alguna manera a Windows de quien era realmente. Con mi inseparable Norton para DOS comencé a mirar las tripas del archivo REGEDIT.EXE, y aproximadamente cuando llevaba un tercio apareció la clave del registro que genera POLEDIT para activar esta restricción.
![]()
Conclusión: REGEDIT mira esa clave del registro cada vez que se inicia para saber si tiene la ejecución permitida o prohibida. Así que no es Windows quien impide la ejecución del programa.
Windows está plagado de sorpresas como esta. Miles de claves del registro que conectan unas con otras y que hacen que Windows sea lo que es. Ya has visto que con una pequeña modificación (una simple "X") se desmota un sistema de seguridad... ¿cuantas cosas más se pueden hacer con la misma sencillez?.Visto que es el propio ejecutable REGEDIT.EXE el que no quiere arrancar cuando la restricción está activada, y que la forma normal de acceder al registro para desactivarla es usando REGEDIT, parece que la única vía posible es modificar el ejecutable para que no tenga en cuenta esa restricción... ¿simple verdad?.
Ya estará pensando alguno en desensambladores, instrucciones de código máquina y cosas por el estilo... nada de eso. Para modificar el archivo utilicé DISKEDIT de las Utilidades Norton para DOS, pero supongo que se puede hacer con cualquier otro editor hexadecimal de archivos.
Este es el aspecto de lo que se tiene que modificar...
![]()
Se puede ver claramente la cadena de texto "DisableRegistryTools" y a continuación unos ceros hasta que comienza la siguiente cadena de texto. Aprovechando que tenemos sitio metemos una "X" (por poner algo), justo pegado a la cadena que define la clave que pretendemos modificar. De esta forma el valor que REGEDIT buscará ahora en el registro será "DisableRegistryToolsX" en lugar del original. Como esa nueva clave del registro no existe, REGEDIT considera que no tiene la ejecución prohibida y se inicia como si tal cosa... pruébalo y verás.
¿Por que funciona este invento?
Para los curiosos. Este tipo de parches funciona por la forma en que el código ejecutable considera que ha terminado una cadena de texto de una longitud que puede ser variable. Se comienza a leer por el primer carácter, uno a uno, hasta que se encuentra un carácter de código ASCII igual a cero ("00" en hexadecimal). En este punto es dónde se considera que la cadena de texto ha terminado.
En el caso que nos ocupa, después de la cadena de texto que queríamos modificar teníamos varios códigos ASCII cero, así que se podía intentar lo de añadir una "X" al final de la cadena para modificarla, con la suerte de que después de esa "X" sigue habiendo un código ASCII cero que indica el final de la cadena.
Dedica un poco de tiempo al tema y te sorprenderás.
Elisoft © 04-11-2000
| ¿Has encontrado este documento interesante?... entonces tal vez quieras hacer una donación en agradecimiento. | |
| ¿Quieres tener una copia de este documento en los formatos MS-Word y PDF?... pues pasa por la página de descarga. |
La Web de ELISOFT
|