¿Qué, Por qué y Cómo?

A mi personalmente la idea me parece genial. Un dispositivo práctico, cómodo y desde luego parece bastante prometedor. Se puede acoplar fácilmente a tus propias gafas, lo cual, desde un punto de vista estético, también es importante. Quisiera tener el gusto de probarlas, pero de momento no han caido en mis manos. Para los que no lo conozcáis, Google Glass permite proyectar (gracias a un micro-proyector), imágenes sobre la escena real que visualizamos. Interesante para mostrar en tiempo real, información sobre el tiempo, noticias, correo, mensajes, GPS, incluso me atrevo a añadir las constantes vitales, con los sensores adicionales pertinentes (esto ya es apreciación mía) etc. Aquí tenéis la web de Google Glass donde podéis ver más imágenes y un video: http://www.google.com/glass/start/ Pero bueno, independientemente de todo esto, a mi personalmente la parte que más me interesa, como de costumbre es responder a la pregunta ¿Cómo?, puesto que el ¿Qué? y el ¿Por qué? so

Hay varias formas de localizar el punto de entrada (EP) de un programa, y aquí expongo un par de ellas. La primera es la más sencilla y rápida, la segunda un poco más compleja pero que abre el abanico de opciones. WinDbg como sabemos dispone de varios pseudo-registros predefinidos que nos facilitan bastante las sesiones de depuración. Uno de estos registros es $exentry. Para colocar un breakpoint en el punto de entrada del ejecutable basta con escribir este comando: 0:000> bu @$exentry El segundo método es un poco más enrevesado pero igualmente válido. Consiste en localizar manualmente el entrypoint mediante el uso de las cabeceras PE del módulo. Para ello, lo primero que hacemos es buscar la ImageBase del ejecutable. Esto lo podemos conseguir con el comando LM que nos dará el ImageBase y el ImageSize, pero también podemos localizarlo con el comando !PEB que nos muestra información sobre el proceso (PEB - Process Environment Block) Una vez tenemos la ImageBase tenemos que

Si ASLR (Address Space Layout Randomization) se introdujo como un nuevo sistema de mitigación de ataques al sistema operativo Windows Vista (sí también a Linux y otros), con la aparición de Windows 7 y Windows Server 2008 R2 Microsoft ha querido fortificar aún más esta técnica mediante una actualización que incorpora lo que han denominado como "Force ASLR" algo así como ASLR Forzoso u obligatorio. Con ASLR, el sistema operativo lo que persigue es aleatorizar o trasladar el espacio de direcciones de las librerías y aplicaciones con cada reinicio, de tal forma, que no sea predecible la ubicación de su dirección base. Como consecuencia, averiguar por ejemplo, la dirección de una determinada API del sistema o porción de código de una aplicación ya no es tan trivial (que no imposible). Esta característica está activada por defecto en la mayor parte de las librerías del sistema operativo y, en bastantes programas siempre y cuando el desarrollador active el flag /DYNAMICBASE en

Imaginad por un momento que os surge la necesidad de detener la ejecución de un programa cuando se pulsa una determinada tecla o combinación de estas, en fin, algo normal que a cualquier persona se le puede pasar por la imaginación, ¿o no?. Bromas aparte, para conseguirlo podemos utilizar infinidad de técnicas y en esta ocasión voy a comentaros la última que he empleado yo en uno de los trabajos que estoy realizando actualmente. Esta técnica consiste en colocar un punto de ruptura en la llamada a la API TranslateAccelerator. Ahora bien, debemos tener en cuenta que si colocamos un breakpoint de ejecución sin más, el debugger estará constantemente saltando y no podremos conseguir nuestro objetivo o, cuando menos, será muy desesperante. Para evitar tal situación, lo que tenemos que hacer es utilizar un breakpoint condicional para indicarle al debugger que se detenga solamente cuando se cumple una determinada condición o condiciones y por consiguiente que continúe con la ejecución nor

Si estás leyendo esta entrada del blog supongo que ya sabes perfectamente la importancia que tienen los símbolos (Públicos y Privados) a la hora de depurar software. En esta ocasión me voy a centrar en las formas que tenemos para indicarle al depurador de Microsoft donde se encuentran los símbolos. En el caso de WinDbg lo podemos especificar de diversas maneras: Desde línea de comandos con el comando -y Utilizando la variable de entorno _ NT_SYMBOL_PATH ó _NT_ALT_SYMBOL_PATH Desde el menú File\Symbol File Path Utilizando el comando .sympath Los símbolos pueden residir en una unidad de almacenamiento local (Ej. el disco duro) o bien proceder de una fuente o servidor remoto. En el la caso de una unidad local, indicaremos la ruta completa a los mismos, ej.; .sympath d:\desarrollo\windbg\symbols Cuando tengamos que cargar los símbolos desde un servidor remoto lo indicaremos así: .sympath srv*http://msdl.microsoft.com/download/symbols También podemos indicar ambos caso