domingo, 28 de abril de 2013

Google Glass - Unas "gafas" futuristas que ya están aquí.

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:


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é? son más que evidentes.

Y con respecto al ¿Cómo?, nada mejor que tener acceso al código fuente del KERNEL que forma tan futurista artefacto.

Pues sí, Google a liberado bajo licencia GPL el código fuente del kernel de "Google Glass" y para los interesados lo podéis descargar desde la página web del proyecto:


Eso sí, os adelanto de antemano, que se trata de un archivito comprimido de unos 65 MBytes, que una vez descomprimido se quedará en unos 500 MBytes y que arroja la friolera de más de 37700 archivos repartidos en unos 2300 directorios (carpetas de las de ahora :) Para los que hayan "metido mano" al kernel de Linux, esto no les sorprenderá, es más, el kernel de Google Glass existe gracias al kernel de Linux, al igual que Android -no se trata de kernels creados desde cero-

La inmensa mayoría de estos archivos son código fuente en lenguaje "C" y "Ensamblador". Así que ya sabéis, si estáis aburridos y no sabéis que hacer, pues a jugar un rato con esas miles y miles de líneas de código.

Con respecto a la parte hardware, todavía no he podido comprobar nada, esencialmente se basa en un micro-proyector y una especie de prisma sobre el cual se proyecta la imagen superpuesta. Según tengo entendido contará con una resolución de 640x360 pixels, una cámara de 5MP capaz de capturar imagen o video en HD 720p,  conectividad WiFi 802.11 b/g y Bluetooth, unos 16 GB  de unidad de almacenamiento, supongo que "ampliables", micrófono, altavoces, etc.

 
En esta imagen si os fijáis bien, se puede apreciar "el prisma" o la "pantalla en ángulo" que hace posible que podamos ver la imagen proyectada. NOTA AL MARGEN: A modo de experimento, tomad una lupa, una hoja de papel vegetal o papel cebolla y "proyectar" la imagen de la televisión sobre el papel, variad el ángulo del papel con respecto a la lupa y veréis lo que sucede. Tendréis que variar la distancia desde la lupa al papel para lograr una imagen nítida, lo cual va en función de la "Longitud focal" de la lupa. Una vez encontrado el punto de foco, ¡voilá!


Aquí podéis ver una infografía sobre su funcionamiento:


Habrá que esperar a que caiga una en nuestras manos para poder hacer una análisis real, pero mientras tanto, ya tenemos información suficiente para entretenernos un largo rato.

Por cierto, antes de "meterle mano" al kernel de Google Glass, os recomiendo que bajéis a la farmacia a por un par de cajas de "aspirina plus extra forte a tuti pleni" ;)

Saludos!

viernes, 26 de abril de 2013

WinDbg - Setting breakpoint on Entry Point

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 buscar la dirección del entry point en las cabeceras del módulo. Existe una cabecera opcional de valores en el formato PE que nos muestra este dato. Para ello ejecutamos el comando:

0:000>  !dh ImageBase.

De toda la información que nos muestra este comando, nos quedamos con "Adress of Entry Point". Se trata de una dirección relativa a la ImageBase, por lo tanto el EntryPoint real lo calculamos sencillamente sumando ambos valores.

Para colocar el breakpoint con este método utilizamos el siguiente comando:

0:000> bp ImageBase + EntryPoint

Por supuesto, hay herramientas externas a WinDbg que nos proporcionan estos datos, pero para ejecutables que no están comprimidos y/u ofuscados, estos métodos van perfecto!

sábado, 20 de abril de 2013

Force ASLR - Trasladando forzosamente la ImageBase

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 el momento del "linkado".

Aquí aparece el primer "punto débil" de ASLR, ya que, debe ser el desarrollador el que decida si activarlo o no. Ahora bien, esto dependerá del entorno de desarrollo utilizado, ya que por ejemplo con Visual Studio 2008 en adelante, estará activado por defecto, no así con otros compiladores.

Bien, dicho esto sobre ASLR, aparece en acción "Force ASLR" con el fin de proteger aquellas librerías o programas cuya característica o flag /DINAMICBASE no está activado.

Con esta actualización, tenemos a nuestra disposición una nueva clave en el registro de windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\

En esa sub-clave podemos crear una nueva entrada por cada programa o módulo que queramos proteger. Para ello, tan solo hay que añadir una nueva clave con el nombre de imagen exacto del programa (Botón derecho/Nueva clave). A continuación deberemos añadirle a esa clave un nuevo valor de tipo QWORD (Botón derecho/Nuevo/Valor QWORD) y lo renombramos como: MitigationOptions.

A esta nueva entrada la podemos asignar uno de los valores siguientes:
  •  0x000 : No asignado
  •  0x100 : Aleatorización activada
  •  0x200 : Aleatorización explícitamente desactivada
  •  0x300 : Aleatorización activada con fallo de carga del módulo
En el primer caso (0x000), se indica de manera explícita que "Force ASLR" no ha sido asignado.

En el segundo caso, el valor 0x100, indica que se active ASLR para el módulo indicado, pero debemos tener en cuenta que solamente se aplicará la aleatorización del espacio de direcciones, en el caso de que el módulo disponga de la "Relocation Table", en caso contrario, el módulo será cargado, si procede, en la dirección indicada en su campo "ImageBase"

En el tercer caso (0x200) se indica de manera explícita que "Force ASLR" ha sido desactivado para ese módulo concreto.

Y finalmente, el último valor (0x300) activa ASLR al igual que el valor 0x100), pero en esta ocasión si el módulo no dispone de la tabla de reubicaciones (Relocation Table), en lugar de cargarlo en su "ImageBase", se producirá un error de carga.

En cualquier caso indicaros que hay herramientas (EMET) que permiten utilizar todo esto sin necesidad de manipular de forma manual el registro de windows, lo cual, como sabéis puede tener consecuencias catastróficas para el sistema operativo y/o el resto del software.

ADVERTENCIA: Modificar estos valores puede hacer que ciertos programas funcionen de manera anómala, tened en cuenta que si en algún programa hacen "uso directo" de las direcciones de memoria "pre-supuestas" y activamos "Force ASLR" estas obviamente cambiaran.

jueves, 11 de abril de 2013

WinDbg Breakpoint on key pressed

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 normal del programa en el resto de los casos.

A modo de ejemplo y haciendo uso de uno de los depuradores que más me gusta (sí el depurador de Microsoft), vamos a detener la ejecución del programa cuando se pulse la tecla INTRO. Para esto, es preciso conocer tanto el prototipo de la API TranslateAccelerator que podéis ver a continuación:

int WINAPI TranslateAccelerator(
  _In_  HWND hWnd,
  _In_  HACCEL hAccTable,
  _In_  LPMSG lpMsg
);


como las estructuras de datos involucradas, ya que, si os fijáis el tercer parámetro de la API es un puntero a la estructura MSG. En este caso la principal estructura que debemos conocer es MSG, ya que necesitaremos hacer buen uso de algunos de sus miembros:

typedef struct tagMSG {
  HWND   hwnd;
  UINT   message;
  WPARAM wParam;
  LPARAM lParam;
  DWORD  time;
  POINT  pt;
} MSG, *PMSG, *LPMSG;


Llegados a este punto, ya conocemos bien a nuestro objetivo y cómo podemos "jugar" con él. Ahora tan solo falta saber cómo le decimos al depurador que utilice toda esta información. Aunque puede hacerse de varias formas, la técnica que expongo aquí es mediante el uso del evaluador de expresiones al estilo C++ que incorpora el debugger.

Si observamos la estructura MSG, enseguida nos damos cuenta de que hay varias cosas muy útiles para conseguir nuestro objetivo. Dado que queremos detener la ejecución del programa al pulsar una tecla, será preciso acceder al miembro 'message' de MSG.

En concreto el mensaje que vamos a capturar será WM_KEYDOWN cuyo valor constante equivalente en hexadecimal es el 0x0100. Además, como no queremos que se detenga la ejecución al pulsar cualquier tecla, sino solamente la tecla ENTER, también tendremos que utilizar el miembro 'wParam' que nos indicará cual es la tecla (VK_KEY) que se ha pulsado. En este caso para la tecla ENTER el valor que deberá contener 'wParam' será 0x0D (ya sabéis el número de la suerte).

Bueno, pues ahora sí que tenemos a nuestro alcance todo lo que necesitamos, así que, manos a la obra. Vamos a indicarle al debugger cual será nuestro maravilloso breakpoint:

bp 003814ac "j @@c++((((ole32!MSG *)@eax)->message == 0x0100) && (((ole32!MSG *)@eax)->wParam == 0x0D)) ''; 'gc'"

Como digo, hay muchas maneras de conseguir esto mismo, pero para mi caso concreto, esta era la más efectiva. La expresión habla más o menos por si sola, no obstante si tenéis alguna duda, sentiros libres de comentarlo.

¡Suerte y feliz debugging!

viernes, 5 de abril de 2013

WinDbg Symbols Path

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 casos en una sola instrucción:

.sympath d:\desarrollo\windbg\symbols;srv*http://msdl.microsoft.com/download/symbols

Es recomendable "cachear" los símbolos de forma local para evitar conectar con el servidor remoto cada vez que los necesitemos. Esto lo podemos conseguir utilizando el parámetro "cache":

.sympath cache*d:\desarrollo\windbg\symbols;srv*http://msdl.microsoft.com/download/symbols

Por último, aclarar que si queremos configurar el "path" desde el menú File/Symbol File Path, no es preciso incluir el comando .sympath