Que no panda el cúnico (nunca mejor dicho…)

Todo empezó una noche de primavera. Estaba yo solo en casa, con un portátil encima de la mesa con el Norton Antivirus caducado y por tanto en peligro que reclamaba mis cuidados. Me decidí a salir por un momento de mi universo Mac y ponerme a pensar cómo iba a manejar aquella situación: el ordenador necesitaba urgentemente un antivirus actualizado.

20040907panda.jpg

Tras buscar entre tarrinas, fundas y más fundas de cedeses, constaté lo inevitable: no tenía ni una sola copia actualizada de ningún antivirus. Vaya situación. En ese momento me acordé de un Panda Antivirus original que tenía guardado en algún lugar… para tranquilizarles, diré que me lo habían regalado en un curso sobre seguridad informática (gran paradoja…). Lo observé con desconfianza: había tenido problemas con el viejo Panda Platinum hacía unos años… Comencé a leer la información de la caja: «máxima protección», «impide el acceso de hackers», «lo instalas y te olvidas» (esto último resultó ser cierto, bellacos).

Con tanta frase, tanta característica interesante y tantos logotipos de «mejor producto del año», pensé que tal vez no sería tan malo como las anteriores versiones… vamos, que lo mismo se habían reformado. Los requisitos mínimos me animaron: Pentium 150 Mhz. Pensé que el Centrino podría de sobra con él, así que decidí instalarlo…

Que el autoarranque se bloqueara no fue un buen augurio, pero decidí continuar… finalmente, y tras una espera eterna, logré instalarlo, validando más tarde mi flamante licencia mediante un proceso bastante poco intuitivo… Pero ya tenía mi ordenador protegido. O eso pensaba.

El primer reinicio fue inusualmente lento. Pero era el primero, así que no le di importancia. Cinco minutos clavados tardó en iniciarse el Windows XP, cuando antes arrancaba en un par de minutos. No pasa nada. Cuando por fin pude abrir el panel de control del antivirus me encontré con una interfaz de las que odio: un montón de dibujos y de parafernalia tan bonita como lenta. Acceder a cada menú era una nueva aventura. Intenté tranquilizarme y tomar aire. Configuré las opciones como más me gustó, y empecé a descargar las actualizaciones.

En todo ese tiempo no logré utilizar el ordenador (256 de RAM, 1 GHz) para nada que no fuera el #@$ Panda. Al fin, la actualización terminó de bajarse. En ese momento, el antivirus me informa de que ha ocurrido un error y que debo reiniciar mi máquina. Ese detalle me indignó hasta los topes… ¿cómo puede un antivirus exigirme el reinicio del equipo por un error interno? ¿y si no puedo reiniciarlo? ¿así me protege el nuevo Panta Antivirus + Antispyware Titanium 2006?

Me resistí, pero al final tuve que claudicar. Reseteé el ordenador con cara de pocos amigos. Esta vez tardé 7 minutos en poder usar el ratón. Me estaba poniendo de color verde. La barra de tareas de Windows aparecía a la mitad, nunca había visto nada parecido. Sin duda el programa más lento y pesado que he visto en la vida. Un virus habría perjudicado menos el rendimiento de la máquina.

Así que, ciscándome en los muertos del tal panda, me dispuse a desinstalarlo. Error. Lo intenté de nuevo. Nada… En esa situación, la información del disco comenzaba a estar en cierto peligro… Por fortuna, pronto sería fulminado por las tropas imperiales :-P. Reinicié en modo «a prueba de fallos» como administrador. Tampoco podía. Borré los archivos por las bravas, limpié el registro. Reinicié el portátil, que tardo poco más de un minuto en arrancar, libre de sus cadenas de bambú.

Y así terminó mi breve e intenso coqueteo primaveral con Panda. Estoy pensando, según voy escribiendo esto, en instalarlo en mi Pentium I a ver si de verdad funciona, tal y como promete la publicidad… es intrigante… igual es tan lento que acaba tirando más rápido… creo que voy a probarlo :-P

He aprendido muchas cosas de esta aventura. La más importante es que Panda Software no ha sido todavía capaz de desarrollar algo decente, y posiblemente nunca lo hará. También me he planteado delicadas preguntas sobre los criterios que siguen las empresas para dar sus certificaciones. Por desgracia, todas mis conclusiones están llenas de palabras malsonantes e improperios diversos, así que me voy a morder la lengua antes de decir que me encantaría ver la cabeza de ese maldito panda separada del resto de su cuerpo.

Pero la publicidad no engañaba: «lo instalas y te olvidas». De volver a usar tu ordenador, se entiende.

El virus Chernobyl (CIH)

storycomputervirus.jpgHace unos días veíamos algunas cosas sobre los virus y cómo funcionan, y dejábamos pendiente una explicación detallada del virus CIH, popularmente conocido como Chernobyl. Pues bien, les presento un análisis pormenorizado de esta simpática criatura: cómo funciona, cómo infecta a otros programas y cómo logra dejarnos el ordenador como salido de un accidente nuclear.

Y aclarado esto, empecemos diciendo que una parte importante de los programas es el control de errores: cuando un programa “la pifia?, el sistema retoma el control e intenta salvar los muebles. En el caso de los virus, si hay un error durante la ejecución no nos interesa para nada que el sistema se entere, por lo que vamos a modificar el manejador de las excepciones para que el SO no se entere de nada. Para los amantes del rigor, el virus modifica el SEH (Structure Exception Handle). Así, si hay un error, en principio el virus retendrá el control de la situación.

Lo siguiente es ver cómo modificar los permisos con los que el programa se ejecuta. En Windows la seguridad está configurada en forma de anillos, que delimitan determinadas zonas. El primer anillo corresponde a los procesos del SO, y las aplicaciones que se ejecutan en este anillo tienen acceso a todo el sistema. El siguiente anillo tiene menos permisos, y así sucesivamente.

Las aplicaciones de usuario se ejecutan en principio en el tercer anillo, el llamado (seguro que no lo imaginan) “Ring 3?. La idea es que nuestro virus se convierta discretamente en una aplicación “Ring 0? para poder acceder a todo el sistema.

Para hacer esto es necesario vulnerar el mecanismo de protección, pero estos mecanismos en Windows 9x no estaban demasiado pulidos, de modo que el virus se servía de determinadas vulnerabilidades para hacer este cambio de anillo. Para quienes veneran el rigor técnico sobre el bien y el mal, habrá que decir que semejante cosa se consigue modificando la IDT (Interrupt Descriptor Table, Tabla de descriptores de interrupciones) y generando después una excepción, lo que le permitirá ejecutar su código con los permisos más elevados del sistema.

Una vez “trapicheado? el sistema, el virus se coloca en la memoria como un programa cualquiera y, como ya sugerimos en la entrega anterior, espera a que se ejecute alguna aplicación. Previamente habrá devuelto el control al programa “portador? para que haga lo que tenga que hacer.

Bien, ya tenemos nuestro virus en memoria esperando para atacar. Cuándo se cargue en memoria una posible víctima intentará la infección: Lo primero será comprobar si es un ejecutable de Windows y que no haya sido infectado anteriormente ¿cómo sabe esto último? Cuando infecta un fichero escribe un valor distinto del original (cero) en el primer byte antes de la cabecera del ejecutable.

Lo siguiente es “inyectar? el código maligno en el ejecutable, sin aumentar el tamaño del mismo. Pero esto no parece sencillo… ¿cómo lo logra? Digamos que en las cabeceras de los ejecutables de Windows se almacenan diversos datos relativos a las funciones que importan o exportan, información que el programa necesita y demás. Todos estos datos se organizan en “objetos?, que tienen que estar organizados de una forma muy concreta dentro del fichero del programa. A su vez, hay que guardar dónde se encuentran estos objetos, qué tamaño ocupan… todo esto se hace con tablas, por lo que el principio del ejecutable consiste en un montón de descriptores y tablas.

Entre todas estas secciones queda un espacio que no se usa, que es el que aprovecha el virus para escribir su código sin incrementar el tamaño del programa portador. Previamente habrá comprobado que tiene el espacio suficiente para infectar el fichero, y en caso contrario no lo hará. Por desgracia, CIH es una pequeña maravilla en cuando a tamaño, ya que sólo ocupa aproximadamente un 1KB, con lo cual casi siempre encontrará huecos en los que instalarse.

Una vez insertado su código, modifica la cabecera para que la dirección de entrada al ejecutable quede apuntando a su propio código.

El payload (carga dañina)

El payload varía entre versiones, pero generalmente lo que hace es obtener el mes y el día y comprobar si es el día 26 de abril. En caso afirmativo, comienza a sobreescribir el chip de la BIOS (si es de tipo flash).

Seguro que algún lector se pregunta algo así como “¿pero la BIOS no es una memoria de sólo lectura? ¿cómo consigue escribir entonces??. La respuesta es que la BIOS es de sólo lectura en principio, pero que generalmente se puede modificar aplicando cierto voltaje*. Normalmente las placas bases impiden que se suministre este voltaje al chip, pero cuando el virus CIH se extendió, tal protección solía venir inhabilitada para facilitar las actualizaciones de la BIOS, con lo que la información quedaba expuesta.

_327903_cih_300.jpg

Cuando termine con esto, localizará los discos duros del sistema y escribirá datos aleatorios sobre los primeros 2048 sectores, dejándolos inutilizables.

El CIH se encuentra prácticamente extinguido a fecha de hoy, gracias a que los sistemas Windows 9x van cayendo en desuso en favor de los basados en Windows NT (saber más). Se trata de un virus muy bien programado, toda una muestra de la belleza que puede encontrarse en la destrucción… Su creador, el taiwanés Chen Ing Hau, (nótese que sus iniciales son las letras C.I.H.) fue detenido en el año 2000.

* Si alguien tiene curiosidad sobre cómo puede ser esto, debe saber que amenazo con dedicarle una entrada al tema en breve.

Actualización: Menear el artículo (¡gracias, Taikochu!)

¿Qué es un virus?

virusinfluenza.jpgSeguro que se ha enfrentado ya a una de estas simpáticas y fascinantes criaturas que son los virus informáticos. O si no usted, probablemente algún conocido suyo los haya sufrido. O tal vez esté infectado y ni siquiera lo sospeche… (sienta cómo la paranoia se apodera de su mente)

El origen de los virus hay que buscarlo a mediados de los 80, cuando unos técnicos de los laboratorios Bell inventaron un juego denominado “Code Wars?, consistente en crear programas que combatían entre ellos por conseguir el control de la memoria del equipo. Hay mucho que decir sobre los virus, y mucho que discutir sobre el tema, pero de esta entrada me interesa que comprendan cómo funcionan y cómo son diseñados. Y es que conociendo bien a nuestro enemigo tendremos más probabilidades de saber defendernos.

Para empezar, hay que acotar un poco la terminología, ya que el término “virus? se utiliza a menudo para referir realidades muy diferentes. No todos los programas dañinos son virus estrictamente, y no todos los virus son dañinos directamente.

Hay que entender un par de ideas antes de entrar en consideraciones más complejas: la primera es que un virus no es más que un programa. Un tanto especial, sí, pero un programa a fin de cuentas. La segunda idea es que los virus informáticos no se parecen tanto a los biológicos: un virus biológico utiliza el material celular para autorreplicarse, mientras que un virus informático modifica los programas que “infecta? incluyendo una copia de sí mismo.

De modo que llegamos a algo que puede parecerse a una definición: un virus es un programa informático que es capaz de modificar a otros programas inyectándolos cierto código que altere su comportamiento.

¿Cómo nos infectan los virus?

Vamos a referirnos en este punto a los virus residentes tradicionales. Los últimos virus aprovechan generalmente fallos en el MS Outlook o en el MS Internet Explorer para infectar los computadores y extenderse por Internet, pero los más bonitos e interesantes son los antiguos.

En principio sólo hay un programa con el código puro del virus: este programa padre irá infectando a los demás, que actuarán a su vez como nuevos padres e irán propagando la infección. Lo que ocurre cuando se ejecuta un programa infectado en el ordenador es más o menos así:

  1. Al ejecutarse, el virus se carga en memoria y se empiezan a leer las instrucciones malignas.
  2. Estas instrucciones modifican ciertos parámetros del sistema operativo para poder hacerse con el control cuando se ejecuten otros programas.
  3. Espera a que otros programas se ejecuten. Cuando los programas se ejecutan, su contenido es transferido a la memoria principal, donde se encuentra el virus, momento que puede utilizar para infectarlos.
  4. Cuando se ejecute un programa, el virus obtendrá el control por un instante. Entonces copiará la parte de código infeccioso en el programa víctima, de manera que siempre se ejecute antes que el programa original. Una vez modificado el nuevo portador, dejará que se ejecute normalmente, y en principio el usuario no percibirá ningún cambio.

A partir de esta idea, podemos refinar el virus cuanto queramos: podemos hacer que compruebe si el programa que va a infectar es un antivirus y que intente cerrarlo en caso afirmativo, o que se envíe a si mismo por email para replicarse más rápido.

Algunos virus, los denominados polimórficos, “mutan?, modificando su código para evitar ser detectados, otros se instalan en el arranque del equipo… Unos buscan en el disco a otros programas y los modifican, aunque no se ejecuten, otros infectan directamente a quienes comparten la memoria con ellos… Hay tanta diversidad como informáticos retorcidos.

Básicamente un virus tiene que tratar de infectar cierta cantidad de programas: si infecta muchos el ordenador se volverá más pesado y el usuario podría darse cuenta. Si infecta pocos, apenas se extenderá. También tiene que intentar pasar desapercibido: utilizar polimorfismo, variar poco el tamaño del programa que infecte, vigilar la presencia de antivirus o de otros virus…

Algunos virus incluyen lo que se llama “payload?, que es como la carga dañina de los misiles: supone la temida manifestación del virus, y es cuando podemos agarrarnos a la silla y temblar de miedo. En algunos casos, la temida carga se reduce a un mensaje gracioso o político. En otros, puede dar lugar al borrado de ficheros o el colapso de la red.

Un ejemplo tristemente famoso

El virus CIH, también conocido como Chernobyl (ya que se se activa el día 26 de Abril) es un ejemplo del daño terrible que pueden causar estas pequeñas bestias. Este virus sólo es capaz de actuar bajo Windows 9x, infecta cualquier archivo .EXE al que tenga acceso y tiene uno de los “payload? más destructivos: sobreescribe las instrucciones del chip de las BIOS de tipo flash dejando el arranque inutilizado y borra el contenidos de los discos duros.

Más adelante hablaremos largo y tendido sobre esta criatura del señor.

El bug de los conguitos

El título ya es impactante… ¿Qué es un «bug»? Pues es un fallo más o menos importante que se cuela en un programa (ya ven, los informáticos somos así de inútiles…). Cuando una aplicación hace cosas raras (falla, termina repentinamente o se bloquea) suele ser debido a los bugs. Aunque la mayoría no supone un problema grave, otras veces son causa de vulnerabilidades que pueden ser explotadas para perjudicar a un usuario.

Por ejemplo, en los antiguos servidores de páginas web (por antiguos digo de hace unos cuatro o cinco años…) cuando se pasaban muchos datos a una web dinámica el ordenador en que estuviera alojada fallaba (los más expertos sabrán que estoy hablando del famoso atauque por desbordamiento de búfer, o buffer overflow). Ésta vulnerabilidad permitía, por ejemplo, ejecutar código remotamente en un servidor público, con los problemas de seguridad que produjo en su momento.

La palabra «bug» viene del inglés «insecto», y se usa en éste contexto porque en los primeros ordenadores, aquellos vetustos gigantes, los fallos eran causados no por mala programación sino por insectos que se introducían en las válvulas y en los componentes electromecánicos y provocaban que funcionaran mal… las cosas que aprende uno… Por cierto, que en la última entrega sobre Cracking usamos un debugger, ¿se acuerda? Éste tipo de programas nos ayuda a eliminar éstos incómodos bichitos de nuestras aplicaciones :-)

conguitos.jpgPero quiero presentarles un bug muy divertido e interesante, que puede utilizarse para colgar cualquier sistema Windows 9x (las versiones 95, 98 y Me) y que impide hacer ciertas cosas en los sistemas Windows NT (la gama 2000 y el XP). Supongo que apenas nadie usa Windows 98 ya, pero si algún día tienen la oportunidad, tecleen en el explorador de Windows la ruta «C:\con\con». El sistema mostrará una pantalla azul y morderá el polvo miserablemente. Si se pierde con tanta versión y tanto Windows, puede leer éste artículo publicado ayer.

Éste error podía ser explotado con un fichero html que intentara abrir esa carpeta. De hecho hubo quien lo creo, y lo puso como página de inicio en Internet Explorer, en dos o tres equipos de un ciber. Cada vez que alguien arrancaba el navegador, el equipo se colgaba. Fantástico, ¿eh?

Si usa Windows XP, en principio está a salvo… pero éste bug dejó sus secuelas, no crea… Vaya a cualquier carpeta de su disco. Ahora intente crear un archivo o una carpeta con el nombre «con». ¿Lo consigue? No sólo pasa con «con», también puede probar con «lpt1». No parece muy posible.

Éstos son problemas clásicos de Windows que han sido explotados amplia y vilmente. ¿A qué se debe? El antiguo MS-DOS, y por tanto los primeros Windows, usan nombres internamente para identificar los dispositivos, salvando las distancias, son como los «dev» de Linux. Por ejemplo el «con» denota la consola, el «lpt1» el puerto paralelo… Cuando se teclea c:\con\con, el sistema trata de buscar un archivo «con» utilizando la consola… simplificando una historia complicada (y además de verdad), se forma un enorme lío porque nada tiene sentido para Windows y entonces aparece la pantalla azul diciendo que nos va a poner dos velas negras…

Los Windows 9x estaban construidos sobre el MS-DOS, razón por la cual el fallo se hizo presente en éstas versiones. Hay un montón de nombres que, al igual que «con», provocan fallos en éstos sistemas, de modo que cuando se construyó Windows NT se corrigió. Los Windows de ésta familia (2000, XP…) no están diseñados sobre el DOS, pero sí que es necesario guardar la compatibilidad hacia atrás. Quien escribe ésto supone que para evitarse problemas decidieron «cortar por lo sano» y no permitir crear éstos ficheros con nombres especiales, ya que si ejecutáramos un programa en modo compatibilidad con Windows 95, podría fallar al confundir el teclado con una carpeta. También, podríamos crear un archivo con ese nombre reservado, que provocaría fallos al abrirlo con el MS-DOS o al portarlo a Windows anteriores… (Por cierto, ¿y si lo creamos con Linux y lo intentamos abrir?)

Lo más grave de éste fallo, conocido popularme como «el bug de los conguitos» es que cuando se descubrió, podría ejecutarse sobre algunos servidores basados en Windows y desactualizados (en realidad la mayoría de servidores usan Unix, así que eran muy pocos). Uno tecleaba por ejemplo «www.peich.com/con/con» ¡y el servidor caía! Imaginen los ratos de irrepetible diversión a los mandos del invento :-P

Hay infinidad de bugs: unos se conocen y se arreglan con facilidad. Otros, como éste problema con el «con» y los dispositivos perduran a través de los siglos como muestra de lo que sucede cuando se es medianamente chapucero o hay prisa por entregar el sistema… Otros no llegan a ésta categoría y son simples fallos de diseño, cosas que los programadores no pudieron prever y que se manifiestan en forma de problemas en ciertos contextos… Y ésto me recuerda un fallo muy antiguo sin solucionar de Internet Explorer que veremos más adelante, con el que van ustedes a hacerse algunas preguntas…

Cracking (y III): Cracker por un día

Ésta es la tercera y última parte de ésta serie sobre Cracking. En el primer artículo vimos una pequeña introdución y un poco de filosofía. En el segundo, aprendimos que los programas pueden modificarse con bastante poco esfuerzo mediante el editor adecuado. Nos queda entender cómo podemos utilizar éstos conocimientos para romper la protección de un programa. Al final del documento hay una advertencia sobre la legalidad de estos contenidos que debería leer.

Pues bien, en éste artículo vamos crackear un crackme, y así entenderemos cómo funcionan las protecciones de los programas y cómo se crean los cracks para evitar algunas. Es un tema muy muy técnico, pero voy a intentar que sea más o menos comprensible. Propongo a quienes tengan más interés por el sunto y más experiencia en la informática que sigan el ejemplo práctico. Quienes lo deseen, que salten directamente al final del documento, allí explico algunas conclusiones. Pero mi consejo es que me sigan, tal vez descubran su lado oscuro…

Bien, necesitamos una herramienta más compleja y potente que nuestro editor hexadecimal: un depurador. Los depuradores son programas que se utilizan en la informática para corregir los fallos de las aplicaciones. Podemos considerar un «fallo» de un programa el que pida una clave para usarlo (vaya cara)… de modo que un depurador nos servirá para llevar a cabo nuestras maldades. Lo que hacen fundamentalmente estos programas es «desarmar» los programas y dejarnos ver qué hacen.

El más interesante es el OllyDbg, que puede descargarse gratis y es uno de los más utilizados. Bien, ya tenemos el arma, ahora necesitamos la diana. Se trata del crackme que utilizamos en la sesión anterior. Como recordará, se llama abex’ 5th crackme, puede descargarse libremente y tiene esta carita de niño Jesús:

Como ven, es algo sencillo e imita conceptualmente a las ventanitas que nos exigen el número de serie para ejecutar un programa o renovar su licencia. Bueno, vamos a ver si cuela, ponemos un número al azar y…

No ha habido suerte y nos ha pillado… es lo más normal. Ahora es cuando empieza la guerra. Abrimos el OllyDbg, y cargamos el ejecutable del crackme, abexcm5.exe. Vemos una ventana con el código de la aplicación. Queda así de bonito y de ilegible:

Ahora pensemos un poco… si escribimos el número de serie correcto tendría que salir una ventana diciéndonos que lo hemos conseguido… vamos a intentar localizar la parte del código en que se toma la decisión de si la cadena es buena o mala (¡no se asuste, es muy sencillo!) Botón derecho sobre la ventana. Sale un menú y nos vamos a «Search for – All referenced text strings», que nos va a decir todos los textos interesantes a los que se hacen referencia en el código.

Ahora nos aparece una nueva ventana donde vemos muchas cosas interesantes… si nos fijamos, un texto del programa es «Yep, you entered a correct serial!». Seguro que es el texto que aparece en la ventana cuando escribimos el número correcto…

Con doble clic en la línea clave nos vamos a la línea del código que nos interesa. Como vemos pertenece a un bloque que, a todas luces, genera un cuadro de diálogo que nos informa del logro. La dirección 00401117 contiene la primera instrucción del bloque. Entonces, suponemos que si el usuario escribe el número «bueno», se salta a esa dirección. Bien, vamos a ver desde dónde se salta a esa dirección:

Y en la ventana que aparece, vemos que hay una instrucción que hace referencia a nuestro mensaje de enhorabuena: (004010FF) JE SHORT abexcm5.00401117 que no quiere decir sino: si la condición es cierta, salta a la dirección 00401117 que es, casualidades, la del mensaje que nos interesa. La instrucción JE significa «salto condicional» (compruébelo)

No nos interesa la condición que evalúa el JE, pero lo que nos interesa es que es un salto condicional: salta si el número es bueno. ¿Y si cambiamos ésta instrucción por: «salta siempre, aunque el número sea malo»? Se puede hacer y vamos a hacerlo.

Posicionados sobre la instrucción, hacemos doble clic y nos aparece una ventana que nos permite escribir una instrucción en lugar de la que tenemos. Vale. Pues el código para saltar siempre es JMP (de jump, saltar en inglés). Vamos a cambiar el JE por un JMP. Éste es el «antes»:

Y ahora el «después»:

Tenemos que hacer clic una vez en «Assemble» para seguir. Luego salimos con cancel. Ya hemos modificado el código, pero éste código reside en memoria y no es persistente: tenemos que guardarlo. Para ello, clic sobre el código, nos vamos a «Copy to executable – All modifications». Cerramos la ventana que aparece y contemos «Sí» a la pregunta de si queremos guardar los cambios. Ahora lo guardamos con otro nombre por si acaso.

Si lo hemos hecho bien, nuestro programa crackeado se tragará cualquier número de serie que le escribamos… compruébelo:

¡Nuestro primer crack ya está listo! Para los avanzados, un ejercicio: el número de serie «bueno» ha estado delante de nuestras narices un buen rato, ¿se atreven a adivinarlo? Si lo hubiéramos extraído sin más del código, no habríamos tenido que modificar el programa. Los crackers experimentados opinan (con razón) que es mucho más bonito encontrar el número sin tocar el programa, pero la idea es que veamos cómo se rompen las protecciones de los programas comerciales.

Es un ejemplo sencillo, pero da una buena idea de cómo funcionan las cosas. Si el crackme hubiera sido programa comercial, podríamos usarlo ahora sin restricciones, pues gracias a nuestras modificaciones, validaría como bueno cualquier número de serie. Sin embargo, estaríamos cometiendo un delito, y este blog no lo apoya ni lo fomenta en ningún modo.

Romper la protección de un juego no es ningún misterio de la metafísica: es informática pura y dura, abrir el programa, cambiar lo que no nos gusta y guardarlo. Ojo: las protecciones reales de los programas comerciales suelen ser muchísimo más complicadas que ésta. De hecho hay crackmes muy enrevesados, algunos los publican particulares aficionados al tema, otros grandes compañías que quieren poner a prueba un sistema de seguridad que están desarrollando.

Caminamos por el filo del cuchillo: aprenda, manipule y destruya si quiere, pero bajo su responsabilidad.

Atención

Éste es un artículo divulgativo, cuyo único objetivo es entender de forma práctica cómo se rompen las protecciones de los programas. En ningún modo se incita a la realización de actividades ilegales, y de acuerdo con éste principio, declinamos toda responsabilidad sobre las posibles aplicaciones de los conocimientos aquí expuestos.

Artículos anteriores:
Cracking (II): A golpes de martillo
Cracking (I): El poder del lado oscuro

Cracking (II): A golpes de martillo

Éste es el segundo artículo de nuestra serie de tres sobre el cracking. En el anterior vimos algunos conceptos básicos. En éste vamos a ver a través de un ejemplo cómo puede modificarse el código de un programa (por cierto, propondremos el II Reto SF), y en el siguiente aplicaremos ésto para romper la protección de un programa.

Los programas son conjuntos de instrucciones (creo que ya les habrá quedado suficientemente claro…) y como tales pueden ser alterados. Los archivos ejecutables (en Windows los .exe) pueden abrise, editarse y guardarse, como si te trataran de simples documentos de texto…

Hay una limitación: las instrucciones de un ejecutable están codificadas para que el ordenador las comprenda, así que si usted lo abre, lo más facil es que no se entere de nada. Los programas, al nivel más detallado, son conjuntos ordenados de unos y ceros, es decir, información binaria. Una forma abreviada y más cómoda de representar la información en binario es usar otro código, el hexadecimal (un día lo explicaré detenidamente). La instrucción de un programa codificada puede ser algo como 6A 00 E8 34, algo completamente incomprensible para nosotros los humanoides.

Para abrir un ejecutable, necesitamos un «editor hexadecimal», que no es más que un programa que sirve para representar de un modo más intuitivo (tampoco mucho…) los datos de un programa. Hay uno muy bueno llamado Hexplorer que puede descargarse gratuitamente de aquí. Y ésta es la única herramienta que necesitamos para modificar una aplicación. Como ésto está prohibido por la mayoría de las licencias, nos vamos a servir de un crackme, lo cual es perfectamente legítimo.

Crackmes los hay a patadas, pero he encontrado uno muy sencillo que nos va a servir muy bien. Se llama abex’ 5th crackme, puede descargarse libremente y tiene este aspecto:

Como ven, imita conceptualmente a las ventanitas que nos exigen el número de serie para ejecutar un programa o renovar su licencia. Nuestro objetivo de hoy es hacer ciertos cambios, de forma que al ejecutar el programa, en el cuadro de texto no se lea «Enter your serial» sino «Segmentation Fault» (hay que barrer para casa…). En realidad podemos poner lo que nos apetezca donde nos apetezca, hasta podríamos cambiar el texto de la barra de título.

Lo que tenemos que hacer es abrir el crackme con el Hexplorer. Para ello, ejecutamos el explorer, nos vamos a «File – Open», y allí seleccionamos el fichero del crackme que hemos descargado. Una vez abierto, lo que tenemos ante nosotros es el código ejecutable del Abex’ Crackme.

(Actualización) Es posible que vea el texto en un tamaño diminuto. Para corregirlo, acuda a «view – options» y en el apartado «font» elija por ejemplo «Fixed Roman Large» (también puede cambiar el esquema de colores). Gracias por informar del fallo, R. Mármol :-)

La columna de la izquierda representa los datos en hexadecimal, y la de la derecha, su traducción a caracteres más o menos comprensibles. Ahora tenemos que ir bajando, puede ver cómo algunas secuencias de texto son precisamente las que le presenta el crackme cuando lo ejecuta. Tenemos que llegar a un sitio donde veamos ésto:

Ahí está lo que nos interesa, ya podemos empezar: vamos a situarnos sobre la primera «E» de «Enter your serial». Ahora, puede sustituirla por la letra que desee… si pone una «S» en lugar de la «E», verá que el 45 de la columna izquierda (la de los numerajos) se cambia por un 53, que es código hexadecimal de la «S».

Ahora puede ir modificando el texto, con la precaución de dejar un 00 entre letra y letra (ojo: no es lo mismo un espacio (código 20) que «nada» (código 00), si se equivoca puede corregirlo directamente sobre la columna izquierda). Es necesario dejar ese 00 entre letra y letra para ser consecuentes con la memoria. Si lo ha hecho bien (tal vez le cueste un poco al principio, pero es muy muy facil) debería ver algo así:

¿Sí? ¿Seguro? Bien, si está todo bien, puede ir a «File – Save» y guardarlo (si no quiere arriesgarse, guárdelo con otro nombre, aunque siempre podrá volver a descargarlo si se le estropea). Si ahora lo ejecuta, debería ver:

¿Lo ha conseguido? ¡Apúntese un tanto! Si Windows le da problemas al ejecutar éste nuevo crackme, casi seguro que se ha equivocado: repáselo. Si lo ha logrado, y además es la primera vez que hace algo del estilo, acaba de conquistar un dominio desconocido a la mayoría de los usuarios: los programas no solo pueden ser ejecutados, sino que son archivos normales y corrientes, y como tales pueden ser abiertos, editados y guardados. Y si pueden ser editados, podemos hacerlos acordes a nuestros intereses.

Para los alumnos más aventajados, aquí dejo el…

II Reto SF

Que consiste simplemente en conseguir que el crackme presente éste aspecto… ¡envien las capturas de su pantalla a la dirección del blog! El primer lector en hacerlo pasará a formar parte de nuestro Salón de la Fama SF (SFSF :-P), que daremos a conocer próximamente.

Puede hacer más pruebas, pero hay que tener mucho cuidado cuando alteramos ciertas posiciones, ya que si manipulamos muy a lo loco, el programa dejará de funcionar correctamente. ¡Sean perversos!

Siguiente artículo:
Cracking (y III): Cracker por un día

Artículo anterior:
Cracking (I): El poder del lado oscuro

Cracking (I): El poder del lado oscuro

Le propongo que nos embarquemos en una interesante aventura durante el fin de semana. Hoy presento una serie de tres artículos sobre el apasionante mundo del cracking (si no sabe qué es, vamos a explicarlo inmediatamente). En esta primera entrega vamos a hacer una pequeña introducción y a aprender algún concepto básico. En la segunda, veremos a través de un ejemplo que los programas pueden modificarse con relativa facilidad. Para terminar, en la tercera estudiaremos un caso práctico de lo que puede hacerse con este «conocimiento prohibido»…

Quizás alguna vez haya tenido que utilizar un programa de los que «caducan» a los treinta días, o con ciertas funciones limitadas por ser una versión gratuita de una aplicación comercial. Y quizás alguna vez le hayan dejado un «parche» para burlar éstas restricciones… Si no sabe de qué estoy hablando, es que es usted una persona honrada y nunca ha «crackeado» un programa. En ese caso, sepa que muchos de los programas con uso restringido pueden modificarse para que puedan ser utilizados sin limitaciones… a este procedimiento se le suele llamar «crackear», y se trata normalmente de una actividad ilegal.

Éste es un mundo inmenso: Tal vez le hayan prestado una versión del juego de moda que, misteriosamente, no pide que inserte el CD cada vez que arranca. Otras veces, son los decodificadores de TV o las tarjetas de los mismos las que son crackeadas para poderlas utilizar sin restricciones. Hasta las play-station pueden ser modificadas para que admitan juegos grabados sobre discos no-originales… Todas son diversas caras de la misma moneda.

El término «cracker» se suele utilizar para referirse a alguien que viola la seguridad de un sistema para obtener beneficio o causar daños (en contraposición a la ética del hacker). Sin embargo, hay otra acepción que es la que nos interesa, que viene muy bien explicada en la Wikipedia:

También se denomina cracker a quien diseña o programa cracks informáticos, que sirven para modificar el comportamiento o ampliar la funcionalidad del software o hardware original al que se aplican, sin que en absoluto pretenda ser dañino para el usuario del mismo. Esta acepción está más cercana al concepto de hacker en cuanto al interés por entender el funcionamiento del programa o hardware, y la adecuación a sus necesidades particulares, generalmente desarrolladas mediante ingeniería inversa.

Creo que con ésto hemos aclarado casi todo, aunque quien tenga curiosidad por el tema puede visitar los artículos que he referido antes. Los términos son muy confusos y en algunos sitios se dan definiciones contradictorias, así que tal vez le resulte complicado (a mí me duele bastante la cabeza después de un buen rato buscando referencias fiables y objetivas…)

Efectivamente, la cosa va de «modificar el comportamiento de un programa». Siendo un poco cínicos, podemos pensar que eliminar una protección es, en efecto, una forma de modificar o ampliar la funcionalidad del software…

Ya dijimos que los programas no son más que conjuntos de instrucciones adecuadamente ordenadas. Existen técnicas, conocidas «ingeniería inversa» que sirven para ver el interior de los programas y modificar su comportamiento. Actualmente, la mayoría de las licencias de las aplicaciones comerciales prohíben realizar ingeniería inversa sobre el código, aunque en la práctica sea imposible de detectar. Utilizando ésta técnica puede aprenderse muchísimo sobre el funcionamiento real del software (y en consecuencia de sus protecciones)

Modificar el código de un programa comercial para evitar una protección o restricción impuesta por el fabricante se considera ilegal, y además, la mayoría de los crackers no están muy interesados en los programas que crackean, sino en las técnicas de protección y entre el «reto» que se establece entre ellos y el programador de la aplicación… Es por eso que, desde hace algunos años, existen programas llamados «crackmes», que viene de «crack me» (crackéame en inglés). Como éstas aplicaciones son creadas expresamente para ser crackeadas es perfectamente legal hacerlo, y no estamos perjudicando a nadie. En cierto modo, se puede decir que éstos programas sirven para canalizar la furia asesina de los crackers.

También se puede argumentar que pueden servir como campo de pruebas para cometer delitos, pero eso sería como prohibir la investigación sobre energía nuclear porque hay quien puede utilizarlo para hacer el mal.

En la siguiente entrega nos vamos a poner manos a la obra y vamos a ver cómo modifica un programa mediante técnicas de ingeniería inversa, y para ello vamos a servirnos de un crackme… ¡les espero!

Siguientes artículos:
Cracking (II): A golpes de martillo
Cracking (y III): Cracker por un día

¿Por qué se cuelgan los ordenadores? (y II)

Hace un par de días comentaba qué eso de que los ordenadores se bloqueen y cuáles son las principales causas de los cuelgues. En concreto, explicaba:

[…] los motivos tenemos que buscarlos en un montón de factores. Pero como todo en la informática, vamos a dividirlos en dos partes: hardware (el cuerpo del ordenador) y software (el alma del ordenador).

En la primera entrega nos referimos a las causas lógicas, esto es, al software, y como lo prometido es deuda, aquí va la segunda y última parte de ésta -por lo menos para mí- interesante entrada.

El hardware

Cuando falla un componente software, como el sistema operativo o un programa, el ordenador se ralentiza o nos presenta algún error, pero el equipo sigue activo y si tenemos un poco de pericia tal vez seamos capaces de salvar los muebles.

Aunque en ocasiones el ordenador se «bloquea» completamente: no responde el teclado, el ratón ni nada… y no muestra mensajes de error. Es como si se hubiera muerto súbitamente y no queda más remedio que apagarlo manualmente (seguro que ésto también le ha sucedido… :-P)

Las causas de este tipo de problemas solemos encontrarlas en el hardware: cuando el ordenador queda «muerto», suele deberse a que el microprocesador (el «cerebro» del ordenador) ha dejado de funcionar. ¿Por qué? Normalmente se debe a un problema de refrigeración: el ventilador se ha desconectado, está sucio, o no rinde lo suficiente. También puede ser que hemos forzado el micro más de lo normal (haciendo operaciones matemáticas o ejecutando muchos procesos) y se ha recalentado hasta dejar de funcionar…

Los procesadores trabajan a temperaturas altísimas. Si no se lo creen, pueden comprobarlo intentando freir un huevo sobre él en poco más de 10 minutos. En esta web explican cómo hacerlo paso a paso, aunque probablemente no se atreva… ¿Se imagina ir al servicio técnico con el ordenador manchado de huevo frito?

Cambiando de tercio, muchas veces el procesador deja de responder porque no le llega suficiente tensión. Los microprocesadores incorporan mecanismos que los deshabilitan si la corriente eléctrica no sobrepasa un determinado voltaje para que no provoquen un funcionamiento no deseado… ahora bien, ¿por qué podría suceder ésto? Tenga en cuenta que todo lo que conecte a su PC debe ser alimentado: no puede pretender conectar la cámara fotográfica, dos discos duros, tres lectores/grabadores de DVD, un montón de tarjetas (la inalámbrica, una de red convencional, la gráfica, la de sonido, las extensoras de puertos), el pen-drive, el MP3 del amigo… más el teclado, el ratón… sencillamente, ¡su ordenador no puede con todo! Si necesita conectar una legión de dispositivos, lo mejor será que piense en instalar una fuente de alimentación más potente que la que pueda tener…

Por último, los cuelgues pueden deberse a picos de tensión y otros fallos de alimentación. Éstos le serán muy difíciles de corregir, en la mayor parte de las ocasiones dependerán de la zona en la que viva… por ejemplo, en las proximidades de cables de alta tensión los dispositivos electrónicos se entienden francamente mal… también puede tener problemas si sufre frecuentes apagones o caidas de tensión. Como posible solución puede instalar un estabilizador o un SAI.

Los estabilizadores son aparatos compuestos de filtros y reguladores que consiguen mantener una alimentación estable (las subidas de tensión pueden dañar seriamente los equipos electrónicos). Yo tengo uno al que conecto el ordenador y me quedo muy tranquilo… Los SAI son más caros, pero ofrecen las ventajas de un estabilizador más una batería por si hay una bajada de tensión o un apagón… la mayoría de las empresas los utilizan.

Causas combinadas

Y para terminar, nos quedan por analizar las inestabilidades producidas por los controladores de los dispositivos. Los controladores o «drivers», son esos programas que tenemos que instalar para poder utilizar la impresora o el escáner: contienen instrucciones que permiten que el ordenador «sepa» como manejarlos. Son aplicaciones muy especiales, y como dependen mucho del hardware, no he querido englobarlos en ninguna de las secciones anteriores.

Éstos programas tienen prioridades muy altas (ver el post sobre el reparto de CPU) y por tanto, sus fallos suelen afectar mucho al ordenador: por ejemplo, un problema con su tarjeta gráfica puede provocar frecuentes pantallazos azules… y si no, que se lo pregunten a Dante ;-)

Hasta aquí este especial dedicado al apasionante mundo de los cuelgues… espero que les sirva para entender mejor a esa pobre e inocente máquina que llamamos ordenador.

¿Por qué se cuelgan los ordenadores? (I)

Si se ha preguntado alguna cuál es el origen del extraño nombre de este blog, Segmentation Fault, hoy está de enhorabuena (tal vez no…): lea este post entero y lo entenderá todo… Antes de nada quiero decir que no soy muy partidario de dividir las entradas, pero en esta ocasión no veo otra posibilidad… Sxim me dejó éste nuevo post en bandeja, cuando a raíz del post sobre el reparto de CPU, preguntaba:

¿Qué decimos técnicamente cuando decimos que «un programa / el ordenador se ha trabado»?

Seguro que al menos una vez se le ha colgado el ordenador. Y casi seguro que habrán sido más de una (y más de dos… :-P) Pero voy a empezar con una mala noticia… por desgracia, los cuelgues son algo propio e inseparable de la informática. Ayer existieron, existen hoy, y con toda probabilidad, seguirán existiendo mañana.

¿A qué nos referimos cuando decimos que el ordenador «se cuelga»? Hay muchas formas en que un equipo puede dejar de responder: puede ser que los programas fallen en cadena. También puede ser que el Sistema Operativo deje de funcionar por algún motivo. Puede ocurrir que sencillamente el equipo deje de responder y haya que reiniciarlo… cualquier cosa.

¿Y qué produce un cuelgue? Bien, no podemos señalar a nada ni nadie como causante de la catástrofe: los motivos tenemos que buscarlos en un montón de factores. Pero como todo en la informática, vamos a dividirlos en dos partes: hardware (el cuerpo del ordenador) y software (el alma del ordenador). Hoy vamos a empezar con éste último:

El software

Tenemos que ver al ordenador como una máquina muy compleja, con un montón de cables y circuitos complicadísimos. Para regir todo esto, necesitamos al Sistema Operativo (SO). Bien, los SO son programas gigantescos y muy enrevesados, así que podemos considerar normal que se equivoquen al gestionar esa enorme complejidad electrónica. Los SO tienen que tener lo que llamamos mecanismos de protección del sistema, que impiden que los programas se influyan unos sobre otros (de forma no deseada, se entiende).

Los programas guardan muchos datos que necesitan para funcionar, y mantienen éstos datos en memoria (podemos verlo como una consigna de un supermercado o de un aeropuerto), y para acordarse se quedan con la llave, en la que viene el número de taquilla en que dejaron una información. Por ejemplo: «el nombre del usuario está en el armarito número 9». Cuando el programa quiere recordar cómo se llamaba el usuario (para saludarle), toma la llave de la consigna 9 y la abre. A éstas llaves se les suele denominar punteros en informática.

Hemos dicho que debemos evitar que los programas se molesten unos a otros, y para ello, es necesario que mantengan separados sus armaritos y que no confundan sus llaves (a nadie le gustaría que le robaran la mochila en el híper, por ejemplo…). Bien, pues tenemos nuestro programita con sus datos identificados señalados en un enorme manojo de llaves. Ahora imagine que otro programa abre por error una taquilla y modifica el contenido, o que nuestra aplicación pierde una llave, o el número de la llave se altera… cualquier catásfrofe que se le ocurra. En la cruda realidad, éstos desarreglos significan generalmente errores críticos de ejecucion: el programa esperaba encontrarse otra cosa en su taquilla, y simplemente, falla.

¿Por qué se colgaban más los sistemas Windows? La explicación es que los Windows antiguos (95, 98…) no sabían hacer frente a un programa que trataba de abrir otra taquilla. Sencillamente se lo permitían, como si no fuera su problema… pero sí lo era. Los procesos empezaban entonces a fallar en cadena, por lo que tarde o temprano ocurrían dos cosas: o bien los armarios del SO eran alterados (pantalla azul), o bien el ordenador se quedaba sin recursos para atender las excepciones devueltas por los programas (bloqueo del sistema). Lo estoy contando a muy grandes rasgos, la realidad es generalmente mucho más complicada y menos novelesca…

Sin embargo, a partir de los Windows serios (NT, 2000, XP…) ésto se solucionó. De hecho, si usó W98 y ahora usa WXP, verá que el segundo es mucho más estable que el primero. En el caso de los Unix y los Linux, cuando un programa intenta acceder a una taquilla ajena, es fulminado inmediatamente y se produce un error. Unix tiene unas bases muy modulares, y por norma general, un fallo local no suele afectar al resto del sistema. Así, cuando un programa ejecuta una operación no válida, se produce un error denominado (agárrese) Segmentation Fault. En español, viene a ser «violación de segmento», que quiere decir que un proceso ha intentado acceder a memoria fuera de la que tiene reservada (fuera de su segmento, para entendernos…)

Sin embargo, es injusto decir que los errores o los cuelgues se produzcan exclusivamente a causa del software. Muchas veces, la culpa la tienen los dispositivos físicos: procesadores que no funcionan, fuentes de alimentación que no dan más de sí… todas estas cosas las vamos a analizar en la siguiente entrega. ¡Hasta entonces!

Actualización: Ya puedes leer la segunda parte del post.

El asunto Guillermito

¿Han oído hablar de un tal «Guillermito»? No me refiero a Bill Gates, quien recibe a menudo apelativos similares, sino a Guillaume T. ¿Que quién es y por qué hablo de él? Vamos a verlo… (Voy a resumir los hechos porque el dossier completo puede leerse, por ejemplo, vía Hispasec)

«Guillermito» es un investigador francés que usa ese apodo en homenaje a sus raíces españolas. Aunque no es su campo, Guillaume es un gran aficionado a la informática (no hay más que ver su web) y hace un tiempo publicó un análisis sobre la efectividad de Viguard, un antivirus de Tegam International que se anunciaba como 100% seguro. (La cronología de la jugada está aquí. Si no lo entienden porque está en francés, ahora sabrán cómo me siento yo cuando me encuentro una web en inglés :-P)

El caso es que la compañía lanzó una campaña muy dura contra Guillaume, seguida de acciones judiciales, que, incomprensiblemente, han conducido a este investigador a verse obligado a pagar nada menos que 14.000 €. Tegam exigía el pago del 10% del volumen de negocio que estimaban que había perdido por culpa de «Guillermito»: 9.000.000 € (curiosamente la empresa facturó menos de 1.500.000 € el año pasado, piensen sobre ello…), así que su victoria es básicamente simbólica.

No obstante, el precedente es nefasto… ¿ya no se puede investigar? ¿no se pueden publicar fallos de seguridad? El propio Guillaume lo resumía así, no sin cierta dosis de ironía:

No se tiene derecho en Francia a demostrar técnicamente que un programa informático presenta vulnerabilidades de seguridad o que su publicidad es falsa. Duerman tranquilos, ciudadanos, todos sus programas informáticos son perfectos.

A pesar de la condena, «Guillermito» puede dormir tranquilo: a través de su web lleva reacudados ya cerca de 10.000 €, con lo que suponemos que no le va a ser difícil hacer frente a la multa. Lo más curioso de ésto es que solicita ayuda «para comprar un antivirus nuevo», ya que la ley francesa no permite pedir dinero para pagar una sanción… ¡Bravo!

Muy brevemente, mi opinión al respecto es que de entrada, y ya que no existe software 100% seguro, la publicidad de la compañía es engañosa. Por otro lado, los análisis independientes permiten conocer la fiabilidad exacta de un software por encima de intereses comerciales, y de su existencia y su eficacia depende en buena parte nuestra seguridad… no perdamos el rumbo.