Introducción a la ingeniería inversa PhD Roberto Gómez Cárdenas

1. Introducción De acuerdo a la BSA (Bussiness Software Alliance) el 36% del software que se utiliza en el mundo es ilegal. Las tasas de piratería disminuyeron en 37 países pero aumentaron en 34 países. Las perdidas por esta causa se incrementaron de 29 billones de dólares a 33 billones de dólares. La principal técnica utilizada para romper la seguridad del material pirateado es la ingeniería inversa. La ingeniería inversa es una metodología para analizar el diseño de un dispositivo o sistema. El objetivo del estudio varia ya que como toda metodología o herramienta en el área de seguridad es un arma de dos filos. Por un lado se puede utilizar para conocer como funciona un sistema y darle la vuelta a los sistemas de protección contra copias no autorizadas. Por otro lado es una buena herramienta para entender el funcionamiento de los nuevos virus y poder erradicarlos y/o diseñar una vacuna. Desde un punto de vista de sistemas computacionales la ingeniería inversa puede ser vista como el proceso de extraer el código fuente de una aplicación a partir del código objeto. Hay que tomar en cuenta que el término cracking también se utiliza también cuando se burla al sistema de protección de algún software en específico para obtener una copia funcional de un software supuestamente protegido. En las dos siguientes secciones se dan a conocer las principales herramientas utilizadas dentro del área de ingeniería inversa. En la sección 4 se dan a conocer algunas técnicas de defensa. Al final se presentan nuestras conclusiones. 2. Las herramientas Para poder realizar un análisis de ingeniería inversa es necesario contar con las herramientas adecuadas. Dependiendo del objetivo del análisis será la, o las, herramientas utilizadas. Entre las herramientas más comunes podemos mencionar a los editores hexadecimales, los des-ensambladores, los descompresores, los depuradores, los analizadores de archivos, los dumpeadores de memoria y monitores de registro.

Un editor hexadecimal, permite editar un archivo en su forma bruta, es decir permite editar los bits de un archivo. Para que el usuario no tenga que lidiar con unos y ceros en la aplicación, el editor los agrupa en conjuntos de 4 bits y los convierte a hexadecimal. De esta forma el usuario solo ve números hexadecimales en el editor. A través de este tipo de herramientas es posible conocer el contenido de cualquier tipo de archivo, imágenes, ejecutables, office etc. También es posible conocer el contenido de un disco. Las personas que se dedican a hacer forencia usan este tipo de editores para buscar información oculta. Es importante hacer notar que no solo es posible conocer el contenido de un archivo sino que es posible modificar esté con los datos que se consideran relevantes. Usando esta herramienta es posible cambiar una instrucción por otra si conocemos el código hexadecimal de la instrucción y donde se encuentra ubicada. Entre los editores hexadecimales más conocidos podemos mencionar a Winhex, Hex, Ultraedit y Hacker's View. Como su nombre lo dice, los des-ensambladores permiten des-ensamblar un programa. Dado un archivo ejecutable con esta herramienta podemos conocer las instrucciones en ensamblando que lo componen y poder entender su funcionamiento. Su función es toda la contraria a la de un compilador. Como ejemplos de des-ensambladores podemos mencionar IDA, Sourcery, DeCadePro, W32Dasm, VBDE, LDasm. Una técnica utilizada para proteger aplicaciones de ser copiadas, es comprimir/cifrar el código de la aplicación y descomprimir/descifrar el código en el momento que se necesite ejecutar. Los descompresores son aplicaciones que permiten obtener el ejecutable original antes de que fuera procesado por el compresor/cifrador. O polo menos contar con una imagen descomprimida que pueda ser ejecutada o funcional. Ejemplo de este de aplicaciones son Armadillo Kille, CUP, EXELOCK, PeUNLOCK, Deshrink. Un depurador permite dar seguimiento a la ejecución de una aplicación y poder conocer que es lo que hace cada una de las instrucciones de la aplicación. También permite conocer los valores de las diferentes variables que la componen en todo momento. Con este tipo de herramientas es posible localizar instrucciones que lleven

a cabo ciertas acciones, por ejemplo solicitar un número de licencia (en el caso de un atacante) o conocer donde lleva a cabo ciertas acciones dañinas un virus. Este tipo de herramientas también son utilizadas por desarrolladores de código para encontrar errores de codificación, Podemos mencionar a Debug, Soft-Ice, TR, dbg, como ejemplos de estas herramientas. Los analizadores de archivos proporcionan información sobre un archivo, como el tipo de este. En el caso de ejecutables pueden dar a conocer el tipo de plataforma para la cual fue compilada la aplicación. Si se conoce el tipo de plataforma se podrá elegir el des-ensamblador y depurador adecuado. El comando file de Linux es un ejemplo de este tipo de utilerías, así como File Inspector XL, EXEScan, GETTyp. FILE Info, Multi Ripper y Language 2000. Los dumpeadores de memoria permiten vaciar el contenido de una región de la memoria RAM. Lo cual puede ser interesante ya que muchas aplicaciones almacenan información al arranque de la aplicación para consultarla periódicamente. Al conocer el contenido de la memoria es posible que se conozcan contraseñas utilizadas por la aplicación. Como ejemplos podemos mencionar a AMDUump, LordPE DEeluex, ProcDump, Pupe Los monitores de registro son utilizados en aplicaciones que corren sobre Windows. Varias aplicaciones almacenan información en los registros de Windows y este tipo de herramienta permite conocer el contenido de los registros. 3. Técnicas de ingeniería inversa. Lo primero que uno tiene que hacer para poder llevar a cabo un análisis de ingeniería inversa es conocer las protecciones que la aplicación presenta, para poder darles la vuelta. Existen varias técnicas para hacer esto. La primera técnica, a la retro, consiste en depurar el programa hacia atrás. Se lanza la aplicación y en cuanto sistema de protección se active se detiene la ejecución. A partir de este momento se examina al código hacia atrás, buscando las instrucciones relacionadas con el mensaje de protección. Una vez localizado el mensaje, se procede a investigar las condiciones e instrucciones que lo generaron, para poder cambiarlas o darles la vuelta. Todas estas acciones se harán con la ayuda de las herramientas descritas en la sección anterior. Otra opción consiste en poner un punto de ruptura (breakpoint) en una función, o funciones, que se crea que son usadas dentro del sistema de protección. Una vez que

la ejecución llega a este punto, se continúa depurando hasta llegar al punto buscado. Esto es muy utilizado cuando se busca la función que despliega un banner, o una pantalla nag, o cuando se conoce el sistema de protección que esta usando el sistema analizado. Si el procedimiento de protección muestra un mensaje de error, esté se copia. La aplicación se des-ensambla y se busca la cadena de caracteres en la lista de instrucciones que hace referencias a cadenas. Una vez localizadas las direcciones de las instrucciones, se examina el código que hay alrededor y se busca por un salto que aleje al flujo de información de una referencia a dicha cadena. En muchas ocasiones es necesario examinar las llamadas previas al salto, ya que estas pueden contener las instrucciones de verificación. Si se conoce la cadena de caracteres, y esta no se puede localizar por la técnica anterior, se puede utilizar un editor hexadecimal o un dumpeador de memoria. Se busca la cadena y si se encuentra en memoria se introduce una instrucción para interrumpir al programa antes de realizar cualquier acción sobre esta. Por último, si se sospecha que una determinada secuencia de instrucciones en ensamblador está siendo usada por el sistema de protección, se puede utilizar un editor hexadecimal para buscar la secuencia de códigos-bytes y actuar en consecuencia. Por ejemplo si la operación en cuestión es una comparación de fechas, esta instrucción se puede cambiar por una comparación entre dos números iguales, lo cual siempre dará verdad y evitará que el sistema de alerta se active. 4. Posibles defensas. Existen diferentes tipos de mecanismos de defensa para dificultar el trabajo de las personas que llevan a cabo un análisis de ingeniería inversa. Entre las más comunes podemos mencionar a los sistemas de protección por tiempo, sistemas de protección mediante hardware externo (mochilas o dongles), sistemas de defensa basado en empaquetadores y en la comprobación de la integridad de los datos (CRC). Existen dos formas de implementar un sistema de protección por límite de tiempo. En el primero el software comprueba si han transcurrido n días desde la instalación del mismo. En caso positivo procede a la salida inmediata o a su des-instalación o puede mostrar mensaje informando al usuario. En el segundo de los casos se comprueba si se ha llegado a una fecha límite. En ambos casos el software no funcionará si se vuelve a instalar. Sin embargo un atacante tiene analizará la aplicación

para comprobar donde se almacena la fecha de instalación o donde se encuentra el contador de los días que han pasado y modificar estos valores. Otra opción de protección es utiliza un dispositivo hardware externo, que se conecta a la computadora cada vez que se utiliza la aplicación a protegida. Este dispositivo se conoce como dongle o mochila. Una mochila no es más que una caja que contiene un circuito que puede variar en complejidad según el tipo de mochila. Algunas mochilas cuentan con memoria donde se almacenan datos usados por la propia mochila. El software a proteger se comunica con la mochila a través de rutinas que proporciona el fabricante. La protección depende de la habilidad del programador de implementar la protección. Es importante cifrar la llamada a la mochila, mandar llamar a la mochila en varios lugares del programa y en diferentes intervalos de tiempo durante la ejecución de la aplicación. Con el objetivo de ocultar el funcionamiento del sistema de protección del software, algunos autores software empaquetan sus programas para reducir el tamaño de los archivos del programa y complicar el trabajo de ingeniería inversa, ya que no se puede obtener un desensamblado exacto del archivo El programa original esta envuelto dentro del código del empaquetador, el cual esconde el código original Cuando se lanza el programa, se esta ejecutando en primer lugar el código empaquetador., el cual desempaqueta aplicación original en memoria y después se ejecuta. Es posible usar un cifrador en lugar de un empaquetador. También es posible utilizas CRCs (Código Redundancia Cíclica) para la protección de software. Los CRCs son usados para la detección de errores en la transmisión de datos en comunicaciones. El dispositivo calcula el CRC en base a un polinomio y envía información junto con su CRC. En el otro extremo de la recepción se usa el mismo polinomio para calcular el CRC de lo recibido y compara resultado. Si son iguales se ha transmitido con éxito, en caso contrario algún dato fue cambiado. Es posible usar huellas digitales en lugar de CRCs.

Conclusiones Se han presentado las diferentes herramientas y técnicas utilizadas para llevar a cabo un análisis de ingeniería inversa. Las opciones son variadas y no existe un método único para llevar a cabo este tipo de análisis. Existen varios tutoriales para ahondar en esta área y también se cuenta con los famosos crackmes. Estos son programas o aplicaciones diseñadas especialmente para practicar eludir diferentes tipos de protección. Cada crackme contiene un tipo de protección y el reto es romperlo. Es importante conocer las técnicas usadas por los especialistas en crackeo de aplicaciones para poder tomar las medidas adecuadas y proteger nuestro software. Referencias [1] Cracking sin secretos, Ataque y defensa de software, J. Zemánek, Ed. Alfaomega, 2005 [2] Hacker Disassembling Uncovered, K. Kaspersky, Ed. Alist, 2003 [3] Reversing, Secrets of Reverse Engineering, Eldad Eilam, Ed. Wiley Publishing, 2005 [4] Seguridad en software, Profesor X, Revista Conthackto, No 2, noviembre/diciembre 2005 [5] Digital Rigthts Management, Spyware and Security, E.W. Felten and J. A. Halderman, IEEE Security & Privacy, Vol.4 No. 1, January/February 2006 [6] Electronic Frontier Foundation’s Sony BMG Settlement FAQ http://www.ef.org/IP/DRM/Sony-BMG/settlement_faq.php [7] Armouring the ELF: Binary encryption on the UNIX platform, grugp, scut, Phrack Magazine http://www.phrack.org