2009-10-21 12 views
14

He estado utilizando Visual Studio 2005 en Windows XP Pro 64-bit para proyectos C y C++ por un tiempo. Uno de los trucos populares que he estado utilizando de vez en cuando en el depurador era recordar un valor de puntero numérico de la ejecución de depuración anterior del programa (digamos 0x00000000FFAB8938), agréguelo a la ventana de observación con una conversión tipo (por ejemplo, ((MyObject *) 0x00000000FFAB8938)->data_field) y luego observe la memoria ocupada por el objeto durante la siguiente ejecución de depuración. En muchos casos, esto es bastante conveniente y útil, ya que mientras el código permanezca inalterado, es razonable esperar que el diseño de memoria asignado también permanezca sin cambios. En resumen, funciona.Estabilidad del puntero en Windows Vista

Sin embargo, hace relativamente poco tiempo que comencé a usar la misma versión de Visual Studio en una computadora portátil con Windows Vista (Home Premium) de 64 bits. Por extraño que parezca, es mucho más difícil utilizar este truco en esa configuración. La dirección de memoria real parece cambiar muy a menudo de ejecución a ejecución sin motivo aparente, es decir, incluso cuando el código del programa no se modificó en absoluto. Parece que la dirección real no está cambiando completamente al azar, simplemente selecciona un valor de un conjunto fijo de valores más o menos estable, pero en cualquier caso hace que sea mucho más difícil hacer este tipo de observación de memoria.

¿Alguien conoce el motivo de este comportamiento en Windows Vista? ¿Qué está causando el cambio en el diseño de la memoria? ¿Es alguna intrusión externa en el espacio de direcciones de proceso de otros procesos del sistema? ¿O es alguna peculiaridad/característica de la implementación de la API de Heap en Vista? ¿Hay alguna manera de evitar que esto suceda?

+1

En Linux existe desde hace mucho tiempo un generador de espacio aleatorio que tiene como objetivo evitar los ataques de desbordamiento de búfer. Tal vez finalmente ha sido implementado también por MS? – jdehaan

+0

Bueno, sé de esto, pero AFAIK solo funciona cuando * reinicia * el copmputer. Más precisamente, escuché que MS implementó su versión para aleatorizar cosas en cada arranque (no sé cómo funciona en Linux). Entonces, el comportamiento que observo en Vista no parece estar relacionado. – AnT

+0

Aunque esto podría ser algo. Estoy ejecutando VS 2005, que es una aplicación de 32 bits que puede depurar aplicaciones de 64 bits. AFAIK, funciona a través del mecanismo de depuración remota de MS. ¿Podría ser que Vista básicamente "arranque" un nuevo entorno de 64 bits cada vez que inicie una aplicación de 64 bits de VS 2005 (haciendo que las cosas se aleatoricen)? – AnT

Respuesta

30

Windows Vista implementa address space layout randomization, heap randomization, and stack randomization. Este es un mecanismo de seguridad que trata de evitar ataques de desbordamiento de búfer que dependen del conocimiento de dónde está almacenada cada pieza de código y datos.

Es posible desactivar ASLR estableciendo el valor de registro MoveImages. No pude encontrar una forma de deshabilitar la asignación al azar de heap, pero algunos expertos de Microsoft recomiendan que las direcciones de computación se relacionen con _crtheap. Incluso si el montón se mueve, la dirección relativa puede permanecer estable.

+0

Gracias por la citación. :) Una cosa es especular pero es agradable ver la expulsión. – BobbyShaftoe

Cuestiones relacionadas