15 abril 2014

Dragonjar Security Conference - 2014





Parece que fue ayer cuando Jaime Andrés Restrepo de La Comunidad Dragonjar junto con Jhon César Arango, me invitaron a la colombiana ciudad de Manizales para asistir como ponente al ACK Security Conference. Esto sucedió en 2012, cuando Jaime me contaba que recuperó un evento que hacían tiempo atrás, el EISI.

Como la cosa va de años pares, y coincidiendo con el despegue de Dragonjar Soluciones y Seguridad Informática SAS, a primeros de Mayo de 2014, habrá un evento internacional de Seguridad Informática en Manizales, que tiene todas las papeletas para ser le-gen-da-rio: El Dragonjar Security Conference

Con ponentes de 6 países diferentes, habrá una completa oferta con tres días de talleres (del 5 al 7 de Mayo) y de conferencias de seguridad (del 8 al 10 de Mayo) relacionadas con las siguientes temáticas:

  • Vulnerabilidades 0-Day
  • Pentesting
  • Seguridad en Redes
  • Ingeniería Social
  • Criptografía
  • Seguridad Física
  • Sistemas de gestión de seguridad de información (ISO 27000)
  • Seguridad Móviles
  • Informática Forense
  • Seguridad en Entornos Industriales
  • Seguridad en La Nube
  • Seguridad en Tecnologías Emergentes
  • Desarrollo Seguro
Como representación española, va nuestro amigo y "antiguo" colaborador Marc Rivero, que dará dos charlas, relacionadas con Reporting de Vulnerabilidades y otra sobre ECrime.   

Entre los ponentes tengo el placer de conocer a Camilo Galdós, joven hacker peruano al que tuve el gran placer de conocer cuando estuve en Lima en el evento PeruHack, y que junto a Jhon Vargas y, por supuesto, "el tío" Walter Cuestas, me trataron de forma inmejorable! Camilo es un crack y le auguro mucho éxito en Colombia en sus charlas. 

Desde tierras pamperas, irán Óscar Banchiero, autor de Pengowin, el repositorio de herramientas de hacking del que ya hablamos en Security By Default y Cristian Amicelli, compañero de mi amigo Matías Katz en MKIT Argentina

Como referentes nacionales estarán el propio Jaime Andrés Restrepo, Jhon César Arango y uno de los mayores expertos en reversing que hay en Colombia: Carlos Mario Penagos.

Si estáis en Colombia, es el evento que NO te puedes perder... 

Estamos totalmente seguros que será un rotundo éxito, y desde España, os deseamos muchísima suerte! 
Leer más...

14 abril 2014

Curso Attack & Hardening de GNU Linux

Es indudable que Linux se ha impuesto en el mercado de los servidores y que a día de hoy es la plataforma más ampliamente utilizada para implementar servicios en Internet.

El problema de la masificación de Linux es que, cuando alguien descubre una vulnerabilidad que afecta a la plataforma, automáticamente son comprometidos miles de servidores 'de golpe' ya que, si bien el despliegue se soluciones Linux se ha simplificado mucho, nadie repara en que aparte de desplegar, hay que securizar

Con esa idea en mente, Securízame, ha diseñado un novedoso curso online que aúna las dos disciplinas más demandadas en materia de seguridad: ataque y defensa.

Al ser online, el curso se puede realizar desde cualquier ciudad o país sin necesidad de acudir a un sitio determinado

Con una fase 1 en la que se hablará de hacking y auditorías, el alumno aprenderá a manejar diversas herramientas de ataque, así como técnicas y metodologías que le permitan ser capaz de auditar y valorar una plataforma basada en GNU Linux.

En la parte 2, y tomando como referencia lo aprendido en en anterior módulo, el alumno aprenderá a defenderse, a implementar estrategias de seguridad que mitiguen y dificulten la labor de 'explotar' un sistema Linux.

El contenido de los dos módulos es el siguiente:

MÓDULO I – Ataque a una infraestructura GNU Linux

  • Escaneo de puertos
  • Fingerprinting
  • Ataques a servicios: Identificación a través de banners, fuerza bruta, exploting de vulnerabilidades en servicios
  • Ataques web: XSS, SQLi, Log Injection,…
  • Ataques internos (con shell): aplicaciones desactualizadas, permisos inadecuados, acceso a credenciales por ficheros de log, uso de vulnerabilidades….
  • Exploiting de binarios vulnerables a buffer overflows, race conditions, etc,…
MÓDULO II – Hardening de una infraestructura GNU Linux

  • Seguridad desde la instalación
  • Aplicaciones y servicios necesarios
  • Hardening de pila TCP/IP
  • Securización de BASH y SSHD
  • Políticas de actualización
  • Políticas de filtrado, TCPWrappers y firewalling
  • Herramientas anti-fuerza bruta
  • Detección y monitorización de ataques
  • Herramientas de control de integridad de ficheros
  • Introducción a SELinux
  • Herramientas de auditoría interna de sistema
  • Securización de Apache, PHP y MySQL
  • Protección de ataques DoS y fuerza bruta en Apache
  • Mod_security, instalación y configuración
El curso será impartido por Lorenzo Martínez (co-editor de este blog) y por quien escribe estas líneas.

El calendario previsto es el siguiente:
  • Fechas de registro: 14 de Abril al 18 de Mayo de 2.014
  • Fechas de confirmación de pago: 19 al 30 de Mayo de 2.014
  • Inicio de curso: 2 al 12 de Junio de 2.014
La información más detallada, así como la forma de apuntarse la podéis encontrar en la web del curso: "Attack & Hardening de GNU Linux"
Leer más...

13 abril 2014

Enlaces de la SECmana - 222


Leer más...

12 abril 2014

"Intrusion Prevention Systems" y "Modern Malware" for Dummies




Seguramente todos conocemos la serie de libros “For Dummies”, que podemos encontrar en cualquier librería y con temáticas muy variadas.

El año pasado, Alex nos hablaba y enlazaba un montón de ejemplares de Libros for Dummies específicos sobre Seguridad  

Curiosamente, en las dos últimas ediciones del Congreso de Seguridad español RootedCon, dos patrocinadores del evento regalaban dos de estos libros en papel: “Intrusion Prevention Systems” for Dummies y “Modern Malware” for Dummies, respectivamente en las ediciones de 2013 y 2014. 

Pasamos mucho tiempo devorando PDFs, y de vez en cuando, me gusta recordar cómo se siente  eso de usar libros en papel. 

Aunque ambos libros no pasan de las 70 hojas, os hago un resumen rápido de cada uno:

“Intrusion Prevention Systems” for Dummies, en su momento estaba patrocinado por Sourcefire, un fabricante de IPS basado en Snort.

En los primeros capítulos habla de topología de red, y nos ayuda a entender las diferencias entre IDS e IPS, así como dónde debe colocarse cada tipo de dispositivo, y las capacidades de cada uno, así como las diferencias teóricas entre NIDS/HIDS o NIPS/HIPS. Igualmente, indican las posibilidades de análisis de tráfico en entornos virtualizados, cloud, así como las diversas normativas internacionales (SOX, PCI-DSS, HIPAA, SAS70, etc,…) que requieren que haya un despliegue de IPS que analicen el tráfico. 

También habla de los diferentes motores existentes para detectar/prevenir ataques utilizados por los principales fabricantes, y lo bien que se adaptan a todos los tipos de malware, APT y detección de Zero-Days. No puedo evitar sonreir y leer con un cierto escepticismo estas cosas cuando ves la cantidad de organizaciones afectadas por vulnerabilidades de tipo Zero-Day que han tenido, más que seguro, despliegues de IPS. 

Que no se me malinterprete por lo que he dicho anteriormente. Por supuesto, no puedo dejar de recomendar que haya configuraciones mixtas de IDS e IPS en las organizaciones, puesto que ayudarán a detectar anomalías, bloquear de forma efectiva muchos ataques, y servir como muy buenas fuentes de información por los logs generados, al hacer un análisis forense, si hay un incidente, pero hay que tener claro que no son efectivos al 100%.

Quiero destacar algo que se menciona en esta obra, con lo que, en mi opinión, estoy de acuerdo pero parcialmente. Típicamente, y por la localización donde va cada dispositivo de seguridad, está claro que un IDS analiza una copia del tráfico y un IPS sobre el tráfico original, pudiendo bloquear lo que considere un ataque. Sin embargo, se dice en este libro, que un IDS sólo permite detectar un ataque y no tomar decisiones de bloqueo de dicho tráfico. Originalmente, esto se pensó así, pero el autor no ha tenido en cuenta la posibilidad que tienen (o tenían algunos IDS como ISS, en su día) de enviar un TCP RST al origen y al destino del ataque detectado. Recuerdo que hace años, en un ISP en el que trabajamos Yago y yo, protegimos del malware MyDoom, los servidores de correo a través de los que se transmitía esta joya. Importamos las reglas SNORT en ISS mediante lo que se conocía como reglas TRONS (SNORT al revés) y disponíamos de una interfaz de red con pila TCP/IP que construía y enviaba paquetes con el flag RST activo, de forma cruzada, spoofeando el origen. Otra opción es que aquellos firewalls que permitan interacción desde otros dispositivos, ya sea por API o por un protocolo bastante antiguo llamado OPSEC, se puede indicar como reacción al IDS que así lo haga.

De complementar funcionalidades de los IPS con WAF (Web Application Firewall) no se habla en este libro.

En mi opinión, por el tiempo que se invierte en leer menos de 70 hojas, merece la pena. Si más o menos el lector se abstrae de cosas enfocadas al fabricante que lo patrocina, para personas que se estén iniciando en el mundo de la seguridad, o reciclando de otros sectores, y que nos soléis preguntar por dónde empezar, es un buen complemento a la formación sobre seguridad perimetral  


 “Modern Malware” for Dummies, patrocinado por Palo Alto, fabricante de UTMs

Este libro, que también recomendó hace una semana nuestro amigo 1gbdeinfo en su blog, sí que lo veo de muchísimo más valor que el anterior. Se habla de diferentes maneras por las que se puede introducir el malware en las redes, que ya no está escrito generalmente por gente ávida de fama, sino por gobiernos, agencias de inteligencia, mafias y grupos organizados de individuos que con motivación, financiación y recursos son capaces de saltarse muchos de los mecanismos de protección actuales. Igualmente se explica diferentes técnicas típicamente utilizadas en malware y botnets, como cifrado y ofuscación, así como el uso de “covert channels” para comunicarse al exterior con su creador, de forma “invisible” o al menos muy complicada de detectar. 
Obviamente, hay un capítulo destinado a explicar cómo un Next Generation Firewall es capaz de ayudar a controlar este tipo de amenazas. 


Sin darle el mismo sesgo que al anterior, lo he visto bastante interesante y muy recomendable para tener cierta cultura sobre esta temática. En menos de 70 páginas no se puede terminar con unos enormes conocimientos, pero se hace bastante agradable de leer.   
Leer más...

11 abril 2014

Ola k ase? ejecutas código o k ase?

Llegados a este punto lo di por solucionado y me olvidé del reto hasta que hace menos de un mes me encontré en una de esas situaciones que aterrorizan a cualquier informático del siglo XXI: ¡estar de viaje hospedado en un hotel sin WIFI y con un ordenador delante! Ya había visto todas las series y papers que tenía en el ordenador. En ese momento vi solitaria una carpeta con el binario y me dio por volver a cargarlo en IDA a ver que se me ocurría. ¿Ejecución de código…?

Cuando estuve haciendo el reto ya se me ocurrió esa idea pero la descarté ya que el binario solo leía 20 bytes (14h) de todo el fichero y eso no es suficiente como para cargar una shellcode (por muy pequeña que sea) y saltar a ella. Sin embargo ese día sin internet tenía tiempo para darle a la pelota a ver que salía, y algo salió.

Se me ocurrió que podía escribir yo mismo el código ASM necesario para releer el fichero  “key.txt” entero y por tanto ya tener la shellcode en memoria a la que más tarde saltaría. Sin embargo solo tenía 16 bytes (20 menos los 4 necesarios para indicar a donde queremos hacer el salto) y era imposible en tan poco espacio. Incluso intentando rescatar valores de la pila o de los registros para hacer que ocupase lo menos posible (evitando un MOV EAX, 11223344 que ocupa 5 bytes y usar instrucciones que solo sean un opcode como PUSH EAX).  Imposible…

Finalmente, tras estar cerca de rendirme, le volví a echar un ojo al código y… se me ocurrió una forma de conseguirlo. Podría hacer una ROP chain que se encargase de modificar en memoria y en tiempo de ejecución la zona donde se encuentra ese 14h por otro valor más grande, es decir utilizar el propio código de ReadFile que tiene el programa pero habiendo modificado el número de valores que la función va a leer. Al fin y al cabo, ¡para qué escribir mi código y gastar valiosos bytes si el propio código tiene lo que necesito!



A la izquierda tenemos el código ensamblado generado por el compilador mientras que a la derecha tenemos el principio de la ROP chain a la que se accede tras hacer el CALL EAX. Podemos ver que he usado EDI como referencia tanto para saber a qué dirección saltar después de parchear el número de bytes a leer como para saber qué dirección exacta saltar. No voy a entrar en detalles con los datos ya que son puras matemáticas en función del tamaño en opcodes de cada instrucción. Al utilizar EDI (que es el valor del RET) como referencia, he conseguido ahorrar mucho tamaño a la ROP chain e incluso me han sobrado algunos bytes.

Tras ejecutar ese cacho de código podemos ver que en efecto el flujo vuelve al primer PUSH de la función ReadFile y que el tamaño a leer ha cambiado:



Después del CALL a la función ReadFile ya tenemos toda la shellcode en memoria. Solo falta saltar a ella. Si echamos un ojo a la memoria podremos ver que solo se carga el contenido del fichero “key.txt” que no se había cargado anteriormente. Esto nos viene perfecto ya que simplemente debemos volver a hacer matemáticas con el valor “7A40B660” harcodeado para saltar de nuevo a nuestro propio código del fichero “key.txt” (esta vez 529 bytes (211h)).

Como vimos anteriormente, nuestro fichero se carga en la dirección de memoria 4040E4. Si le sumamos los 4 bytes que se usan para hacer  las “mates” con el valor harcodeado nos queda 4040E8 y por tanto como vimos antes:
7A40B660 + X = 4040E8 => X = 85FF8A88  (888AFF85 en Little Endian).

Lo añadimos a nuestro ROP chain y ¡listo! Ya tenemos lo necesario para saltar a nuestra shellcode. Yo he creado un “key.txt” con una shellcode que ejecuta una calculadora. Corremos el programa y:




Aquí os dejo el código en python que usé para generar el archivo “key.txt” malicioso que ejecutará la shellcode que le indiquemos:


exploit=open("key.txt","w+")
shellcode=("\xdb\xc2\xb8\x68\x84\x96\x3c\xd9\x74\x24\xf4\x5b\x33\xc9\xb1"
"\x33\x31\x43\x17\x83\xeb\xfc\x03\x2b\x97\x74\xc9\x57\x7f\xf1"
"\x32\xa7\x80\x62\xba\x42\xb1\xb0\xd8\x07\xe0\x04\xaa\x45\x09"
"\xee\xfe\x7d\x9a\x82\xd6\x72\x2b\x28\x01\xbd\xac\x9c\x8d\x11"
"\x6e\xbe\x71\x6b\xa3\x60\x4b\xa4\xb6\x61\x8c\xd8\x39\x33\x45"
"\x97\xe8\xa4\xe2\xe5\x30\xc4\x24\x62\x08\xbe\x41\xb4\xfd\x74"
"\x4b\xe4\xae\x03\x03\x1c\xc4\x4c\xb4\x1d\x09\x8f\x88\x54\x26"
"\x64\x7a\x67\xee\xb4\x83\x56\xce\x1b\xba\x57\xc3\x62\xfa\x5f"
"\x3c\x11\xf0\x9c\xc1\x22\xc3\xdf\x1d\xa6\xd6\x47\xd5\x10\x33"
"\x76\x3a\xc6\xb0\x74\xf7\x8c\x9f\x98\x06\x40\x94\xa4\x83\x67"
"\x7b\x2d\xd7\x43\x5f\x76\x83\xea\xc6\xd2\x62\x12\x18\xba\xdb"
"\xb6\x52\x28\x0f\xc0\x38\x26\xce\x40\x47\x0f\xd0\x5a\x48\x3f"
"\xb9\x6b\xc3\xd0\xbe\x73\x06\x95\x31\x3e\x0b\xbf\xd9\xe7\xd9"
"\x82\x87\x17\x34\xc0\xb1\x9b\xbd\xb8\x45\x83\xb7\xbd\x02\x03"
"\x2b\xcf\x1b\xe6\x4b\x7c\x1b\x23\x28\xe3\x8f\xaf\x81\x86\x37"
"\x55\xde")

ROP="\x88"+"\x8a"+"\xff"+"\x85"#address to Jump
ROP+="\x5f"#POP EDI
ROP+="\x83"+"\xef"+"\x22"#SUB EDI,22h
ROP+="\x66"+"\xc7"+"\x47"+"\x0b"+"\x11"+"\x02"#MOV word ptr [EDI+0Bh], 211h =529bytes for the shellcode
ROP+="\xff"+"\xe7"#JMP EDI
ROP+="\x90"*4
ROP+="\x9c"+"\x8a"+"\xff"+"\x85"#address to Jump to the shellcode

ROP+="\x90"*50 # NOP junk. Happy Hour!

exploit.write(ROP+shellcode)
print "[+] Evil Key File generated"
exploit.close()

En el siguiente enlace podéis acceder al writeup completo en formato PDF: http://goo.gl/YQ0ts9

Agradecimientos

Quiero dar las gracias a los "juankers y en especial a Francisco Oca (@francisco_oca). Sus consejos y  tips sobre reversing son siempre muy apreciados. 




Artículo cortesía de: Alberto García Illera
Leer más...

08 abril 2014

Desangrando el corazón de OpenSSL (CVE-2014-0160)

Estamos ante una de las vulnerabilidades más graves (opinión personal) de los últimos años. Y no sólo vulnerabilidad, la explotación tiene efectos que sinceramente, tras verlos, asustan.

Ayer 7 de Abril se publicó una vulnerabilidad en OpenSSL 1.0.1 que permitiría a un atacante obtener 64Kb de memoria. Pueden parecer pocos, pero os aseguro que en dicha sección de memoria se pueden encontrar credenciales, cookies de sesión, claves privadas, etc, de los clientes y servidores conectados al servidor vulnerable. El aluvión de tweets referentes a este tema fue masivo, han sido unas navidades anticipadas con un regalo en forma de vulnerabilidad que permite ser explotada en cualquier servicio vulnerable expuesto sin apenas ser detectado.

Esta vulnerabilidad ha sido descubierta por Neel Mehta del equipo de Google Security, y el CVE reservado (CVE-2014-0160) fue creado el 3 de Diciembre de 2013:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160

Impacto tras explotación

La información que se podría obtener sería la siguiente:

  1. Claves privadas
  2. Usuarios y contraseñas utilizadas en servicios vulnerables
  3. Información sensible utilizada por servicios vulnerables
  4. Direcciones de memoria y su contenido que podría permitir evadir mecanismos de mitigación ante exploits.

¿Mi servidor es vulnerable?

Rápidamente, comenzaron a publicarse herramientas que permitían tanto comprobar si un servidor es vulnerable como obtener la información tras su explotación.

Servicio online en http://filippo.io/Heartbleed para comprobar si un servicio web es vulnerable
El caso más sonado fue el de Yahoo.com, cuya página de autenticación de usuarios login.yahoo.com ha sido vulnerable durante un día entero, corriendo imágenes de su explotación como la pólvora en redes sociales, mostrándose usuarios y contraseñas (en caso de encontrarse conectados en el momento del análisis).


Cómo corregir esta vulnerabilidad

Lo primero y más importante, actualizar la librería OpenSSL a una versión no vulnerable, a partir de la 1.0.1g. También se recomienda encarecidamente regenerar toda aquella información afectada, claves de usuarios, claves privadas... Esta tarea puede ser ardua y suponer un esfuerzo considerable, pero nadie nos asegura si, durante el período hasta la actualización de nuestros servicios vulnerables, pudiera haberse explotado este fallo para obtener de manera masiva información sensible.

Otro método para su corrección consiste en deshabilitar el soporte de Heartbeat en OpenSSL, recompilándolo con la opción -DOPENSSL_NO_HEARTBEATS

En este enlace del GIT de openssl se pueden ver las modificaciones realizadas sobre los ficheros d1_both.c y t1_lib.c que solventarían esta grave vulnerabilidad.

¿Qué páginas se encuentran afectadas?

Unas cuantas...

Se ha puesto a disposición de todos un listado del TOP 1000 portales web según el ranking de ALEXA, mostrando si son vulnerables o no. El listado corresponde con el estado de dichas webs durante el 8 de abril siendo confeccionada tras la ejecución de la herramienta de comprobación de manera masiva.


Muchas páginas de proyectos importantes, como Cloudflare que lo indica en un post dentro de su blog, tuvieron constancia de la vulnerabilidad una semana antes de su publicación, teniendo tiempo para corregir la vulnerabilidad en sus servidores. Otros muchos, parece que han hecho caso omiso aún habiendo tenido el privilegio de haber sido informados (ya que todo ha seguido las normas del responsible disclosure).

Existe una página considerada "oficial" de Heartbleed dedicada a intentar responder todas las preguntas referentes a esta vulnerabilidad: http://heartbleed.com

En el siguiente listado disponible dentro del advisory en kb.cert.org se encuentran todos los fabricantes afectados hasta el momento.

Leer más...

3.5  Parchear el binario en tiempo de ejecución

Una vez que sabemos a dónde debemos saltar para pintar el cuadrado, modifiquemos la zona a la que salta el JMP que hemos comentado anteriormente y deberíamos finalizar el reto.



La zona de memoria donde está el salto es “4010BD” y debemos saltar a “4022E0”. Los saltos en x86 son relativos a la zona desde la que se llama. Para saber exactamente quée opcodes necesitamos podemos usar “rasm2” de radare2:



Con el parámetro  “-o” indicamos que el salto se debe hacer teniendo en cuenta que el JMP está en la dirección “4010BD”.
¡Ya tenemos todo! Veamos cómo queda el fichero “key.txt”:

  • Los primeros cuatro bytes deciden a donde se hace el primer salto CALL EAX (el encargado de crear la ventana).
  • Los siguientes cuatro bytes deciden dónde vamos a escribir (0D1BE014C + X = 4110BD => X = 2E830F71 (710F831E en Little Endian)).
  • Los últimos cuatro bytes deciden qué vamos a escribir (lo obtenido con rasm2).

Veamos que todo funciona correctamente:



De momento EDI apunta a la dirección del JMP que queremos modificar sin embargo  el JMP no apunta a la parte de código que pinta el cuadrado y que, por tanto, nos interesa (4022E0).
A pesar de ello  MOV [edi+1], eax:



El JMP ya está apuntando a donde nosotros queremos y si pulsamos F9 para dejar que el programa prosiga con su ejecución obtenemos:



¡Reto solucionado!



Resolviendo el reto “por las ramas”

Muchos pueden pensar que eesto ya es suficiente, sin embargo seguí dándole un par de vueltas y conseguí solucionar el reto de otra forma distinta la cual el programador del código no había considerado a la hora de codear el reto. En este momento tenemos dos cosas a favor:
  • Sabemos cuáles son las dos zonas a las que debemos saltar (la que crea la ventana y la que pinta el cuadrado dentro de ella).
  • En el primer CALL EAX podemos saltar a la dirección que queramos.

Por tanto… ¿Por qué no saltar a la zona donde se carga nuestro “key.txt” y hacer que dicho archivo contenga dos saltos: uno a la zona donde se crea la ventana y otro a donde se pinta el cuadrado?
Tras esto me planteé dos elementos en contra que debemos controlar para que funcione la idea:
  • ¿Se cargan suficientes bytes en memoria  del archivo “key.txt” para poder hacer esos dos saltos?
  • ¿La zona donde se mapea el contenido de “key.txt” es siempre la misma o varía?

Recordemos la primera parte del código donde se carga el contenido del fichero a memoria:



Como vemos el número de bytes que se leerán del archivo “key.txt”  será de 14h que equivale a 20 bytes. Por tanto tenemos 20 bytes para hacer los dos saltos a las zonas de crear ventana y pintar cuadrado (realmente solo tenemos 16, ya que los cuatro primeros son los que usarán para calcular a dónde se hará el salto del CALL EAX). Aunque no es mucho es suficiente para hacer dos saltos. Primero contra bypassed.
También podemos ver que la zona de memoria donde se guarda el contenido del fichero es siempre la misma ya que está hardcodeada (lpBuffer=4040E4). Por tanto, el contenido del fichero se va a cargar siempre en la misma zona de memoria. Segundo contra bypassed.

Debemos hacer que el “CALL EAX” sea a 4040E4+4=4040E8 (la zona donde se carga nuestro “key.txt” sin contar los 4 primeros bytes que son los que decidirán a donde saltamos sumándose al valor 7A40B660).

Tenemos: 7A40B660 + X = 4040E8 => X = 85FF8A88  (888AFF85 en Little Endian).

Con esto ya solo nos falta generar los opcodes para saltar a las dos zonas que crean la ventana y pintan el cuadrado respectivamente.  Para hacer esto yo he optado por usar esta fórmula:

MOV EAX, 402000 ; zona donde se crea la ventana
CALL EAX
MOV  EAX, 4022E0 ; zona donde se pinta el cuadrado
CALL EAX
Para saber cuáles son los opcodes yo he usado rasm2 de radare2:



Añadimos esos opcodes a los 4 que ya teníamos y todo debería de funcionar. Comprobémoslo:



¡Genial! Todo está como debería. Si pulsamos F9 para seguir a la ejecución del programa:


¡Reto conseguido!  Esta vez de otra forma distinta y, a mi gusto, más interesante ya que somos nosotros mismos los encargados de guiar de la mano por donde debe continuar el flujo de instrucciones sin depender de parte del código del programador.


Artículo cortesía de: Alberto García Illera

Leer más...