análisis técnico de un sistema de protección basado en keyfile

Análisis Técnico de un Sistema de Protección basado en KEYFILE1001 Ways to Crack Software 2011

29/11/2011Centro de Investigaciones en Alta TecnologíaRodolfo Hernández Baz

Seguridad en Software 2

Coatepec, Ver. – México – [email protected] – www.ccat.edu.mx – www.x25.org.mx



Definición de la Ingeniería Reversa (Cracking)

Aún hoy el término “Cracking” tiene una amplia gama de significados. Para algunos el “Cracking” consiste en forzar bruscamente a un programa, generalmente de manera poco elegante, para que trabaje. Para otros el “Cracking” es hacer un programa inteligente (generalmente pequeño) o la modificación de un programa, y una persona que despliega una inusual perspicacia en un lenguaje de programación o en un sistema operativo. Por otra parte, cualquier manipulación diestra sería también considerada como un acto de “Cracking”. Algunos Psicólogos, Sociólogos, y otros profesionales que se relacionan con los aspectos del comportamiento, consideran el “Cracking” no más que como una afición a la computadora. A los que padecen la enfermedad se les considera como a seres socialmente ineptos e incapaces de formar parte de un grupo por otro medio, que el que proporciona la lejanía y la abstracción de la computación.

En el libro llamado El Diccionario del Hacker, los autores Guy Steele y otros, han perfilado por lo menos siete definiciones diferentes de un pirata o Cracker:

1. Una persona que disfruta aprendiendo sobre los detalles de los sistemas de la computadora y sobre cómo aumentar sus capacidades; como opuesto a la mayoría de los usuarios de computadoras, quienes prefieren aprender sólo lo mínimamente necesario.

2. Uno que programa con entusiasmo, o que disfruta programando, más que teorizando solamente acerca de la programación.

3. Una persona capaz de apreciar el valor pirata.

4. Una persona que es buena programando rápidamente.

5. Un experto en un programa particular o uno que frecuentemente trabaja usándolo o en él.

6. Un experto de cualquier género.

7. Un malévolo e inquisitivo entrometido que trata de descubrir información hurgando a su alrededor. Por ejemplo un pirata de la contraseña es uno que trata, posiblemente por medios engañosos o ilegales, de descubrir las contraseñas de las computadoras de otra gente. Un pirata de la red es uno que trata de aprender acerca de la red de computadoras (posiblemente para mejorarla o posiblemente para interferirla).

Por lo tanto, para nuestros propósitos, la piratería también llamada Hacking, es cualquier actividad relacionada con la computadora que no ha sido sancionada o aceptada por el patrón o dueño de un sistema de red o software. Debemos distinguirlo, de cualquier modo, de la piratería de Software (Cracking) y del crimen computacional, donde el tópico principal es el derecho de propiedad de la información y el uso de sistemas de computación para perpetrar lo que, en cualquier otra situación, se miraría simplemente como un robo monetario fraude. Hasta cierto punto esta definición es bastante amplia. No obstante, tal definición nos provee con una rica carga de casos y sucesos que están en el corazón mismo de los tópicos éticos en computación.



Definición de un KEYFILE:Siempre eh dicho que todo sistema de protección tiene su forma de

desprotegerlo y precisamente de eso se encarga la ingeniería reversa o también llamada CRACKING, de analizar y encontrar en el código desensamblado de un software la protección con la cual este verifica que no está registrado, existen cientos de tipos de protecciones algunas básicas, otras no tanto pero al fin y al cabo todas son factibles de vulnerar, como en el siguiente ejemplo que analizaremos dos tipos de protección basado en KEYFILE.

Diferencias a tomar en cuenta:

Existen dos tipos de archivos en general con los cuales los programadores protegen el software, estos son los siguientes:

RegFile: archivo .reg que contiene las entradas del Registro en lugar de efectuar directamente los cambios en el Registro.

KeyFile: archivo que especifica el nombre de archivo que contiene la clave o registro para que el software quede registrado.

Comenzando con el análisis:

Existen muchos variantes de protecciones basadas en KEYFILE, la que veremos en este articulo está basada en “KEYFILE con verificación Hexadecimal de Contenido Variable”que desde este momento llamaremos “KVHCV”. Esta verifica como su nombre lo dice que exista un archivo en algún lugar del disco duro, lógicamente especificado por el programa el cual debe de tener y contener una extensión predeterminada y un valor dentro del mismo, en algunos casos los programadores encriptan el contenido del KEYFILE pero aun así es reversible.

Utilerias a usar:1. W32dasm

2. OllyDbG v 1.10

3. Editor de Texto

4. Editor Hexadecimal

5. Calculadora Científica



Análisis del Comportamiento de la Protección

Lo primero que todo reverser hace es analizar el programa que trata de vulnerar, con diferentes utilerías y además lo ejecuta para ver el comportamiento de la protección y el software en sí mismo, cabe mencionar que para este artículo usaremos un CRackME para prueba de concepto llamado:

El cual nos ayudara a entender como los reverses hacen su trabajo.

Al ejecutar el crackme lo primero que aparece es una NAg screen donde nos dice el nombre del creador y un string reference “CLick OK to check for the Keyfie” y un botón “Aceptar” ahora le damos click en “Aceptar y vemos la siguiente pantalla:

Otro String Reference “ Hmmmmm, I can’t find the file! “ como podemos ver cuando le damos click en el botón de Aceptar en la primera NAgScreen nos ejecuta otra NAgScreen en la cual nso dice que no encuentra el archivo, esto me hace pensar y preguntarme varias cosas, primeramente me doy cuenta que el Crackme verifica si existe un archivo, pero ¿ qué archivo es, con que extensión, en que formato y en donde lo busca? Esas preguntas las iremos resolviendo en el transcurso de este texto.



Análisis interno del Ejecutable

Una vez hecho el análisis del comportamiento de la protección pasamos a hacer un reconocimiento interno del PE (Portable Ejecutable) a más detalle donde veremos y encontraremos en que lenguaje fue programado, si esta empacado o encriptado, para eso usaremos el RDG Packer Detector v 0.6.7 el cual nos dirá muchas cosas.

Le damos click en abrir y seleccionamos el Crackme en cuestión:

Y como podemos ver nos dice en que lenguaje de programación fue hecho y lo más importante no está empacado ni protegido, cabe mencionar que esto es un error ya que facilitan el trabajo para los piratas informáticos que quieren tener el software totalmente libre de uso sin pagar las regalías pertinentes.

El siguiente paso es analizar el ejecutable en lo que yo llamo código muerto que consiste simplemente desensamblar el (PE) con el W32Dasm una utilería realmente viejita pero sigue siendo de gran utilidad y valía para los reversers, una vez dicho estoy pasamos a desensamblar el (PE) y en el W32Dasm podremos ver lo siguiente:



En esta ventana podemos ver las partes que conforman el (PE) ahora viene lo máscomplicado analizaremos cada parte que conforma al (PE)

En la imagen siguiente podemos ver la cabecera del ejecutable que en este caso contiene 5 secciones las cuales contienen toda la información que el ejecutable necesita para poder ser inicializado

Pero antes de explicarles en qué consisten las cabeceras, les explicare a grandes rasgos que es un Portable ejecutable.



Análisis de Archivos Portables Ejecutables PE Files

Que es el Formato Portable Ejecutable?

Desde la versión 3.1 de Windows introdujeron un nuevo tipo de formato para los archivos ejecutables el cual llamaron PE (Portable Executable). El cual tuvo su inicio en el formato COOF (Common Object File Format) que usa Unix para que se pudiera mantener su compatibilidad con MS-DOS y los sistemas operativos Windows, este nuevo tipo de archivo ejecutable continuo con la cabecera MZ del MS-DOS.

Pero por que le pusieron el nombre de Portable Executable? Eso simple y sencillamente porque es portable y totalmente compatible con cualquier versión del sistema operativo windows. Así como también es usado en procesadores diferentes a Intel X86, MIPS Alpha entre muchos otros, cabe mencionar también que los DLL y Drivers de dispositivos también se manejan en el formato PE.

Pero como nos podemos dar cuenta de esa cabecera? Pues simplemente abrimos con un editor Hexadecimal un PE y podremos ver la cabecera:

Esto nos dice mucho acerca del ejecutable para conocer y comprender los conceptos básicos de cómo se ejecutan y el por qué se ejecutan las aplicaciones hechas para el Sistema Operativo WINDOWS 32 Bits, como se cargan las librerías de funciones dinámicas llamados también DLL, y sus funciones importadas y exportadas del mismo.



En la siguiente imagen tomada de internet, podemos ver don la estructura lógica de un PE

Archivos en General y el Formato PE

Como hemos visto existen gran variedad de archivos donde los datos en un archivo común y corriente no es más que un conjunto de datos organizados de tal forma en registros donde cada registro podríamos llamarlo como en la programación estructurada, con esto decimos que es un espacio que ocupa en memoria para guardar datos de forma organizada.

Entonces, en los archivos con formato PE, tenemos un encabezado y un cuerpo.



El encabezado de los archivos PE lo podemos dividir en 4 sub encabezados que son los siguientes:

El encabezado DOS MZ

El encabezado PE

El encabezado NT opcional

El conjunto de tablas de secciones

Veamos la organización en la siguiente tabla:

PE EXE (Windows 32Bit EXE, DLL, OCX, etc)

Encabezado MZ EXE Contiene información necesaria para ejecutar el DOS STUB. Conservado por compatibilidad Encabezado

DOSEncabezado MZ extendido

El desplazamiento (OFFSET) 3Ch apunta al encabezado PE

DOS STUBUsualmente despliega 'Requires windows to run' o un mensaje similar

Agregado para avisar que el programa rueda en Windows

Encabezado PEContiene info necesaria para correr el programa en Win32

Encabezados agregados por W32

Encabezado opcional NTContiene info adicional necesaria para correr el programa en Win32

Tabla de Objetos o Secciones

Información sobre objetos o secciones en el archivo

Objetos o secciones Datos de las seccionesCuerpo del archivo



A este antiguo encabezado EXE MZ se le han agregado algunos campos que informan al cargador del Sistema Operativo (SO) dónde está el encabezado PE con información relevante para W32.

Encabezado MZ Extendido

001C DwordTabla de relocalización con un número variable de reubicación de elementos.

0020 Dword Identifuicador OEM

0024 Dword Información OEM.

0028 26Bytes Reservado.

003C DwordDesplazamiento del nuevo encabezado EXE desde el inicio del archivo o 0 si es un archivo MZ EXE

El último campo de esta extensión, 'e_lfanew', indica la dirección donde está la signatura que identifica el formato del archivo. Si se trata de un archivo con un programa W32, este campo apunta a dos caracteres: "PE" (Portable Executable), el formato elegido por M$ para los archivos con programas W32.

Si abrimos NOTEPAD.EXE con con HEX WORKSHOP y revisamos el campo e_lfanew en el desplazamiento 003Ch, veremos el número 8000h, que al revés es 0080h, el desplazamiento donde veremos los caracteres 'PE', que identifican el formato del archivo (Si trabajas con HEX WORKSHOP, no cierres todavía este archivo). Si ahora abrimos con HEX WORKSHOP el archivo WINFILE.EXE, generalmente ubicado en el directorio C:\WINDOWS, veremos que el desplazamiento 003Ch apunta al desplazamiento 0400h, donde encontramos los caracteres 'NE', que es el formato de los archivos W16.

Inmediatamente después de la signatura hay dos bytes o una palabra (WORD) con ceros, después de los cuales inicia el encabezado PE. En la actualidad, el formato NE está prácticamente extinguido. Lo pasaré por alto y me concentraré en el formato PE.

Entre el encabezado MZ DOS y la signatura PE, está la sección "STUB" del archivo, la cual se incluye para el despliegue de un mensaje que indica que el programa sólo puede correr en Windows.



También existen muchas secciones importantes que deberíamos de conocer a cerca de los Portables Ejecutables como lo son:

El tamaño de la secciones Punto de Entrada (RVA Entry Point) Base de las secciones Base de la Imagen (ImageBase) Alineamientos Tamaño de la imagen Directorio de datos SizeOfRawData PointerToRawData

Y muchas y muchas más cosas que debemos de conocer a cerca de los PE, que en este texto no se trataran ya que el objetivo principal es el de mostrar la protección de KEYFILES.

Regresando a la imagen previa, tomada del desensamblado del crackme:

Ahora explicaremos algunas de las secciones PE del crackme en cuestión:

.data y .text : permiten especificar las secciones de memoria donde se ubicaran los códigos de maquina correspondientes a las líneas de texto que siguen a la directiva.

.reloc : En pocas palabras, los traslados de base son simplemente una lista de ubicaciones en un archivo ejecutable en un valor delta se necesita ser añadido a los contenidos actuales de la memoria. Las páginas de un archivo ejecutable se ponen enla memoria sólo cuando son necesarios, y el formato de los Movimientos de base así lo refleja. Las reubicaciones de base residen en una sección llamada. Reloc, pero la forma correcta de encontrarlos es a partir de la DataDirectory con la entradaIMAGE_DIRECTORY_ENTRY_BASERELOC.



.rsrc : esta sección contiene la información sobre los recursos compartidos que son las funciones importadas y exportadas que usa el ejecutable.

Con esta explicación creo que es suficiente, ahora si continuemos con la protección de KEYFILES.

Una vez desensamblado el ejecutable vamos y damos click en el botón: para que nos muestre los String references que contiene y vemos la siguiente ventana:

Donde podemos ver los textos que muestra al llevar a cabo una acción y si ustedes son muy avivados podemos darnos cuenta de algo súper importante, recuerdan que habíamos dicho en líneas anteriores que el crackme buscaba un archivo? Y no lo encontraba? Bueno pues ahí nos podemos dar cuenta que archivo busca:

Abex.l2c

Ya vieron que fácil fue encontrar el nombre del archivo que busca para saber si esta registrado? Ok ahora creemos un archivo con ese nombre en el folder donde tenemos el crackme:

Lógicamente este lo creamos en primera instancia con el Block de notas, una vez hecho esto, ejecutamos el crackme y vemos que mensajes nos manda ahora:



Ok perfecto como vemos ya no dice que no encuentra ninguna keyfile, ahora dice que el archivo encontrado cumple con el nombre mas no con el contenido, ya dimos el primer paso, lo siguiente es ahora abrirlo el ejecutable con el debugger llamado OllyDBG el cual nos mostrara en código desensamblado la información:



Ya lo tenemos abierto en el debugger, el siguiente paso es dar clic con botón derecho y seleccionar la opción Serarch for All reference strings y aparece esto:

Donde sin más palabras podemos ver lo mismo que en el W32dasm los strings references que contiene el ejecutable, ahora demos doble click sobre abex.l2c y veamos a donde nos lleva:

Aquí claramente podemos ver todo el código que se encarga de decidir si es válido o no el KEYFILE en la dirección de memoria: veamos el código desensamblado para entenderle mejor 2 cabe señalar que resaltare las líneas más importantes en color rojo con mis comentarios:

00401025 |. 68 B9204000 PUSH PoC-21.004020B ; |FileName = "abex.l2c" \\ aquí pone en memoria el nombre del archivo\

0040102A |. E8 5E000000 CALL <JMP.&KERNEL32.CreateFileA> ; \CreateFileA \\ en este apartado usa una api de Windows específicamente la de la librearía KERNEL32 llamada CreateFIleA \\

0040102F |. A3 CA204000 MOV DWORD PTR DS:[4020CA],EAX

00401034 |. 83F8 FF CMP EAX,-1 \\ compara el registro EXA con -1 \\

00401037 |. 74 3C JE SHORT PoC-21.00401075 \\ si es igual salta a la dirección de memoria 401075 \\

00401039 |. 6A 00 PUSH 0 ; /pFileSizeHigh = NULL

0040103B |. FF35 CA204000 PUSH DWORD PTR DS:[4020CA] ; |hFile = NULL

00401041 |. E8 4D000000 CALL <JMP.&KERNEL32.GetFileSize> ; \GetFileSize \\ toma el tamaño del archivo\\



00401046 |. 83F8 12 CMP EAX,12 \\ compara el registro EAX con 12 \\

00401049 |. 75 15 JNZ SHORT PoC-21.00401060 \\ hace un salto condicional JNZ (salta si no es cero) a la dirección de memoria 401060 \\

0040104B |. 6A 00 PUSH 0 ; /Style = MB_OK|MB_APPLMODAL

0040104D |. 68 35204000 PUSH PoC-21.00402035 ; |Title = "Well done!" \\ empuja el string a memoria \\

00401052 |. 68 40204000 PUSH PoC-21.00402040 ; |Text = "Yep, keyfile found!" \\ empuja el string a memoria \\

00401057 |. 6A 00 PUSH 0 ; |hOwner = NULL

00401059 |. E8 41000000 CALL <JMP.&USER32.MessageBoxA> ; \MessageBoxA \\ aquí hace uso de la librería USER32.DLL para mostrar pun mensaje por medio de la API MessageBoxA \\

0040105E |. EB 28 JMP SHORT PoC-21.00401088 \\ y termina la ejecución \\

00401060 |> 6A 00 PUSH 0 ; /Style = MB_OK|MB_APPLMODAL

00401062 |. 68 79204000 PUSH PoC-21.00402079 ; |Title = "Error" \\ empuja el string a memoria \\

00401067 |. 68 7F204000 PUSH PoC-21.0040207F ; |Text = "The found file is not a valid keyfile!" \\ empuja el string a memoria \\

0040106C |. 6A 00 PUSH 0 ; |hOwner = NULL

0040106E |. E8 2C000000 CALL <JMP.&USER32.MessageBoxA> ; \MessageBoxA \\ aquí hace uso de la librería USER32.DLL para mostrar pun mensaje por medio de la API MessageBoxA \\

00401073 |. EB 13 JMP SHORT PoC-21.00401088 \\ y termina la ejecución \\

00401075 |> 6A 00 PUSH 0 ; |/Style = MB_OK|MB_APPLMODAL

00401077 |. 68 54204000 PUSH PoC-21.00402054 ; ||Title = "Error" \\ empuja el string a memoria que será el titulo de la ventana que contendrá la siguiente línea de string\\

0040107C |. 68 5A204000 PUSH PoC-21.0040205ª ; ||Text = "Hmmmmm, I can't find the file!" \\ empuja el string a memoria \\

00401081 |. 6A 00 PUSH 0 ; ||hOwner = NULL

00401083 |. E8 17000000 CALL <JMP.&USER32.MessageBoxA> ; |\MessageBoxA \\ aquí hace uso de la librería USER32.DLL para mostrar un mensaje por medio de la API MessageBoxA \\

00401088 \> E8 0C000000 CALL <JMP.&KERNEL32.ExitProcess> ; \ExitProcess \\ termina la ejecución \\

0040108D $- FF25 54304000 JMP DWORD PTR DS:[<&KERNEL32.CreateFileA>] ; kernel32.CreateFileA

00401093 $- FF25 58304000 JMP DWORD PTR DS:[<&KERNEL32.GetFileSize>] ; kernel32.GetFileSize

00401099 .- FF25 5C304000 JMP DWORD PTR DS:[<&KERNEL32.ExitProcess>] ; kernel32.ExitProcess

0040109F $- FF25 64304000 JMP DWORD PTR DS:[<&USER32.MessageBoxA>] ; USER32.MessageBoxA

**********************************************************



Ok con esto creo que tenemos todo claro para finalizar este análisis hagamos una unión de lo que hace el CRackme:

1. busca si existe el archivo: abex.l2c2. si lo encuentra verifica el contenido.3. Compara el contenido del KEYFILE con 12h de error usand4. Si el contenido no es lo que necesita manda un mensaje o las Apis del sistema

operativo.5. si es lo que necesita te registra y te manda el mensaje de chico bueno.

Ese es el proceso que necesita para validarlo, pero nos encontramos con un problema cuando lo compara con 12h que canijos es esto? Bueno pues muy fácil lo resolveremos con la calculadora de WINDOWS, si están leyendo bien amigos, CON LA CALCULADORA DE WINDOWS resolveremos este dilema del contenido que necesita el KEYFILE Para ser válido.

Vamos y abrimos la calculadora, la pasamos a formato científico y seleccionamos el formato Hexadecimal de la misma y ponemos lo siguiente:



Una vez hecho esto simplemente seleccionamos el formato DEC para pasar ese mismo valor hexadecimal a valores decimales y veamos que nos dice:

NoS podemos dar cuenta que el valor 12h tiene un valor 18 en decimal, mmmm entonces lo que tenemos que hacer según el código que vemos del crackme es crear un archivo con el nombre de abex.l2c e incluirle dieciocho valores entonces se me ocurre poner:

Chilitom3x ccat201

Guardamos el archivo y …..

Ahora si objetivo cumplido, ya vieron que fácil.

Saludos: Rodolfo h-Baz aka Pr@fEsOr X2011 –Diciembre-

análisis técnico de un sistema de protección basado en keyfile

Documents