Aviso: Este crackme forma parte de una serie de pruebas de Yoire.com que todavía está en activo. Lo ético si continuas leyendo este manual es que no utilices la respuesta para completar la prueba sin esfuerzo. 😉
Analizando…
Cargamos el crackme en Ollydbg y vamos a las «Referenced Strings«. Vemos una referencia muy interesante que se llama «checkkey«.
Pinchamos sobre ella y aparecemos aquí:
Vemos una referencia a «GetDlgItemTextA» y depués un Call también interesante, vamos a explorarlo.
Entendiendo la rutina de comprobación del serial
Dentro del Call hay dos bucles, uno realiza una operación con nuestro serial (bucle nombre) y el otro comprueba nuestro serial con «3d34273130276a» dígito a dígito (bucle comprobación).
MOV EDX,10006000 --> EDX = "3d34273130276a"
...
MOV AL,BYTE PTR DS:[ECX] --> AL = 1ºdígito serial xoreado
CMP AL,BYTE PTR DS:[ECX+EDX] --> AL = 1ºdígito de EDX?
JNZ SHORT 1000105A --> Si no son iguales bad boy
INC ECX
TEST AL,AL
JNZ SHORT 1000104A --> bucle
Ejemplo para «deurus».
Nombre: d e u r u s Ascii hex: 64 65 75 72 75 73 XOR 55: 31 30 20 27 20 26
Serial XOReado para deurus sería = 313020272026 que obviamente se aleja bastante de 3d34273130276a.
Por suerte XOR es una función reversible por lo que si revertimos 3d34273130276a nos dará el serial correcto.
Serial correcto XOReado: 3d 34 27 31 30 27 6a
XOR 55: 68 61 72 64 65 72 3F Valor ascii: h a r d e r ?
Se suele decir que para cada problema hay una solución. Si esto lo llevamos al terreno stego podemos decir que para cada reto hay una herramienta que nos da la solución. En la entrada anterior os comenté que mi fondo de armario son steganabara y stegsolve aunque cuando la imagen es PNG, una herramienta de uso obligatorio es TweakPNG.
La víctima
imagen original del reto
Nos enfrentamos a una imagen PNG de 112KB (115477 bytes) con una resolución de 300×225 píxeles. A priori llama la atención el elevado tamaño VS la baja resolución, lo que aviva nuestras sospechas de que esos KB extras se deban a que haya insertado otro archivo en su interior.
Chunk
Los archivos PNG tienen la peculiaridad de que están divididos en secciones (chunks) en la que algunas son críticas como IHDR (cabecera), IDAT (la imagen) e IEND (final)y otras muchas secundarias como por ejemplo tEXt (para insertar texto). Al explorar el archivo con TweakPNG vemos la cabecera, varios chunks de texto, muchos IDAT que he combinado en uno para mejorar el análisis y la sección final. Si os fijáis, al combinar los IDAT ha cambiado el tamaño del PNG de 115447 a 110893 bytes aunque en este caso sigue siendo un tamaño elevado.
aspecto original de los chunks
aspecto de los chunks tras combinar todos los IDAT en uno
Llama la atención el chunk cHRm de 12595 bytes del que TweakPNG ya nos avisa que no reconoce su contenido. Cargamos la imagen en un editor hexadecimal y buscamos la palabra «Great» que es el texto que hay justo antes del chunk cHRm que nos interesa.
detalle del chunk cHRm en editor hexadecimal
La búsqueda da sus frutos ya que el chunk parece que está formado por un archivo mp4. A partir de aquí tenemos varias opciones, para mí la más limpia es con un editor hexadecimal apuntar los offsets de inicio y fin del chunk y crear un archivo nuevo con el contenido. Otra opción es exportar el chunk desde TweakPNG con extensión mp4 y borrar los bytes del nombre del chunk con un editor hexadecimal, de lo contrario no podréis reproducir el mp4.
nombre del chunk a borrar para que funcione el mp4
Hecho esto, al escuchar el mp4 obtenemos la solución del reto.
Esta es la tercera y última entrega de los crackmes de Cruehead. En esta ocasión nos enfrentamos a un «keyfile«, un archivo llave para que nos entendamos. Tiene un poco más de dificultad que los anteriores pero es ideal para los que empiezan.
El algoritmo
Si iniciamos el crackme no pasa nada, lo único que vemos es la palabra «UNCRACKED» en el título. Abrimos el crackme con Olly y empezamos. En las «string references» vemos el nombre del archivo llave «crackme3.key«. Lo creamos y escribimos el serial 12345678 y empezamos a tracear.
El CMP EAX,-1 significa que está comprobando que el archivo no esté vacio, como no es nuestro caso continuamos.
A continuación vemos que compara nuestra longitud de serial con 0x12 (18 en decimal). Nuestro serial tiene 8 dígitos así que nos tira fuera.
Escribimos en el archivo llave el serial «deurus123456789012» y volvemos a tracear. Vemos que ahora si pasa los filtros iniciales y llegamos a la primera zona interesante. En la imágen está explicado pero os hago un resumen. En el bucle lo que hace es un XOR a los primeros 14 dígitos de nuestro serial con los valores del 41 al 4E (4F finaliza). El bucle solo se rompe si llegamos a 4F o si el resultado del XOR da 0. Además en EAX acumula la suma del resultado del XOR.
Ejemplo:
d e u r u s 1 2 3 4 5 6 7 8 9 0 1 2
64 65 75 72 75 73 31 32 33 34 35 36 37 38
XOR
41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E
-----------------------------------------
25 27 36 36 30 35 76 7A 7A 7E 7E 7A 7A 76 = 4ED (Suma)
A continuación hace XOR entre 12345678 y 4ED, coge los 4 últimos dígitos de nuestro serial y los compara.
Ejemplo:
12345678 XOR 4ED = 12345295
Compara 12345295 con 32313039
32313039 = 2109, nuestros 4 últimos dígitos al revés. Recordemos que nuestro serial era "deurus123456789012"
El serial bueno para el nombre deurus12345678 serían los bytes correspondientes de «12345295», es decir, nuestro serial bueno sería:
Ejemplo:
Necesitamos 12345295 para la comparación.
12 34 52 95 hexadecimal
18 52 82 149 decimal
Tenemos que escribirlo al revés. Con Alt-Izq + 149 escribimos el primer caracter, el resto igual.
Nuestro serial quedaría: deurus12345678òR4↕
Metemos el serial y vemos que lo acepta pero que nos muestra un nombre extraño. Esto es por que nos está mostrando los bytes del nombre xoreados, tendremos que hacer un XOR antes al nombre que queramos para que lo muestre correctamente.
Recapitulando
Con lo que sabemos ahora hay que empezar a coger el toro por los cuernos. Lo primero que queremos que muestre el nombre deurus y no deurus12345678. Para ello debemos cortar el bucle y eso solo lo podemos hacer forzando que el resultado del XOR sea 0. Ok pues para deurus el siguiente valor de BL, es decir el séptimo, en el bucle sería 47 lo que corresponde a la letra G. Pues si ponemos de serial deurusGxxxxxxxxxxx ya tendríamos la primera parte solucionada.
Pero recordemos que necesitamos XORear el nombre inicialmente, luego debemos escribir el resultado del XOR.
Ejemplo:
d e u r u s
64 65 75 72 75 73
XOR
41 42 43 44 45 46
-----------------
25 27 36 36 30 35
25 27 36 36 30 35 ----- debemos meter esto en el archivo llave.
XOR
41 42 43 44 45 46
-----------------
64 65 75 72 75 73 ----- Al desencriptarlo el bucle se verá nuestro nombre correctamente.
En el archivo llave escribiriamos: %'6605
Ahora nos faltaría calcular el nuevo SUM. Como el resultado del XOR ahora es nuestro nombre, basta con sumar sus valores ascii (64+65+75+72+75+73 == 0x298)
0x12345678 XOR 0x298 == 0x123454E0
Luego nuestros 4 últimos dígitos deben ser lo correspondiente a los bytes E0, 54, 34, 12. Los pasamos a decimal y los escribimos en el archivo llave con el truco del ALT-Izq que hemos comentado antes.
El contenido final del archivo llave para el nombre deurus sería:
%’6605GxxxxxxxÓT4↕
Aquí vemos el archivo llave normal.
Y aquí lo vemos con un editor hexadecimal. Como veis se ven claramente los bytes E0, 54, 34, 12.
Os dejo un keygen hecho en .Net para que probéis. Os genera el contenido del archivo y el archivo «crackme3.key».
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.
El otro día navegando por la red fuí a dar a un mirror de la gran web «Karpoff Spanish Tutor«. Para los que no la conozcais, debeis saber que fué una referencia para el Cracking en la escena nacional. Contenía manuales, cursos, utilidades y todo lo que te pudieras imaginar y/o necesitar para iniciarte en el mundillo del Cracking. Por aquel entonces yo era un cigoto en esto de la Ingeniería Inversa pero la web de Karpoff sentó mis bases y contribuyó a mi afán por saber y compartir. El lector debería saber que estamos hablando de finales de los 90, por lo que este crackme y sucesivos de la web de Karpoff ahora pueden parecer más fáciles pero hay que tener en cuenta que ahora tenemos mejores herramientas.
El objetivo es sacar un serial valido o hacer un generador de llaves, esta hecho para newbies y no tiene ninguna otra proteccion.
El crackme está hecho en Delphi y no tiene ningún tipo de protección antidebug ni nada por el estilo.
El algoritmo
Abrimos Delphi Decompiler y buscamos en los eventos el botón de registro, en este caso se llama «focusClick» y vemos que su RVA apunta a la dirección «442AEC«, lo apuntamos y abrimos el crackme con Ollydbg.
En Olly pulsamos Ctrl+G e introducimos el offset anterior. Un poco más abajo vemos un Call interesante, entramos en el.
Dentro del Call vemos a simple vista dos funciones muy interesantes como son «GetVolumeInformationA» y «GetUserNameA«.
Traceamos el código y vemos que obtiene el número de serie del disco C y el usuario de windows y finalmente los concatena. Se puede ver a simple vista en el Stack o Pila.
No necesitamos saber nada más, probamos el número de serie cazado y funciona. Os adjunto el keygen hecho en C++.
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:
Este episodio fue uno de los primeros en abordar el tema de la inteligencia artificial en la televisión.
El nombre «COS» es una referencia al sistema operativo OS/2 de IBM, que estaba en uso en la época.
Tomas falsas:
Durante una de las escenas de acción, el actor encargado de operar el COS tuvo dificultades para mantener la seriedad debido a los efectos especiales rudimentarios, resultando en varias tomas falsas.
«Kill Switch» (Temporada 5, Episodio 11)
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:
William Gibson es considerado el padre del ciberpunk, y su influencia se nota en la atmósfera y el estilo del episodio.
La tecnología y los conceptos presentados en «Kill Switch» fueron increíblemente visionarios para su tiempo, anticipando el desarrollo de IA avanzada y redes cibernéticas.
Tomas falsas:
Las escenas de acción en el episodio, especialmente las que involucran a Mulder y Scully en entornos virtuales, resultaron en varios momentos divertidos detrás de cámaras, con los actores luchando por coordinar sus movimientos con los efectos especiales.
«First Person Shooter» (Temporada 7, Episodio 13)
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:
Este episodio fue dirigido por Chris Carter, el creador de la serie, y escrito por William Gibson y Tom Maddox, quienes también escribieron «Kill Switch».
«First Person Shooter» fue criticado y elogiado a partes iguales por su tratamiento de la cultura de los videojuegos y la tecnología de realidad virtual.
Tomas falsas:
Las escenas dentro del videojuego requirieron el uso de efectos especiales avanzados para la época, lo que resultó en numerosos errores técnicos y momentos de risas entre el elenco.
«Rm9sbG93ZXJz» (Temporada 11, Episodio 7)
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:
El título del episodio, «Rm9sbG93ZXJz», es «Followers» en base64, una referencia a la temática del episodio sobre las redes sociales y la vigilancia tecnológica.
Este episodio es casi completamente sin diálogos, lo que crea una atmósfera única y tensa que subraya la dependencia moderna de la tecnología.
Tomas falsas:
La falta de diálogos resultó en situaciones cómicas durante el rodaje, ya que los actores tenían que comunicar mucho con expresiones faciales y movimientos, lo que llevó a varios malentendidos y momentos divertidos.
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.
Con The Ring inauguro una nueva sección llamada Blooper Tech Movie (BTM), algo así como pifias o tomas falsas tecnológicas en películas. Aunque no os lo creáis, los creadores del séptimo arte y sus asesores son humanos, y como tal se rigen por la ley del mínimo esfuerzo. En este BTM vamos a ver como una simple escena nos puede arruinar la excelente atmósfera de intriga que hasta ese momento se respiraba.
BTM
Transcurridos 70 minutos de película vemos que la protagonista está en una redacción buscando información sobre la maldita cinta de vídeo en un PC.
Hasta aquí todo correcto, pero instantes después vemos que realiza una búsqueda sobre «Moesko Islands» y cuando se abre el plano y podemos ver la barra de direcciones, en realidad vemos un archivo local situado en «C:\WIN98\Desktop\search.com\2_moesko_island_pt2.html«. A continuación la secuencia, se pueden ver los enlaces «locales» en el segundo 13 y 17.
Teniendo en cuenta que la película data del año 2002, me parece increíble que los productores no se lo curraran un poco más y registraran un dominio como «jdoesearch.com» y simularan que se realizan las búsquedas ONline y no OFFline como se están haciendo en realidad.
Quizá no tenían pensado mostrar la parte superior del navegador o simplemente pensaron que nadie se fijaría pero el caso es que para cualquiera que haya navegado por Internet más de 2 veces, si se fija en la barra de direcciones su expresión facial cambia a WTF!.
La primera entrega de Misión Imposible es ya un clásico y poco o nada tiene que envidiar a sus secuelas. Es ágil, entretenida y como toda peli de espías que se precie, los protagonistas tienen gadgets por un tubo.
El argumento gira sobre la lista NOC. Dicha lista relaciona nombres en clave de agentes repartidos por el mundo con sus nombres reales y al parecer la quiere todo el mundo.
Lista NOC
¿Donde está la lista aquí o aquí?
Al inicio nos hacen creer que la lista NOC está en un sótano de una embajada (No jodas), sin seguridad y accesible por todo el mundo que sepa llegar allí. En esta ocasión no se puede ni llamar hackeo, ya que, el tipo en cuestión simplemente copia la lista (bueno la mitad 😉 en un disco de 3,5″
Tipo robando la lista NOC
¿Eso son Emails o Newsgroups?
Aquí empieza la locura. ¿Os acordáis del BTM de Dexter donde empieza a escribir en foros aleatorios con la esperanza de contactar con el carnicero de la bahía?, pues aquí lo mismo pero con grupos de noticias o newsgroups.
La cosa es que a Ethan Hank no se le ocurre mejor idea para encontrar a Max que buscar en todo tipo de grupos de noticias relacionados con temas bíblicos y en concreto con el libro de Job. Vamos a ver Ethan, hijo del metal, eso es una puta locura, ya de paso anúnciate en el periódico y ponte una diana en el pecho. Pero como es una película resulta que funciona. El caso es que parece que existen la ostia de grupos de discusión donde incluso se puede hablar sobre un capítulo y versículo en particular.
Newsgroup sobre el Libro de Job
El error
El problema es que en cada grupo que encuentra escribe un mensaje muy parecido a como se escribe un email y claro, queda un poco mal. Tanto si quieren hacer creer que escriben un email como si no, el caso es que la escena pierde credibilidad. Ni podría ser un email ni parece factible que alguien se ponga ese nombre de usuario, en definitiva, una chapuza.
¿Parece un email no?
Os dejo una serie de imágenes para que os deleitéis.
File carving is the process of reassembling computer files from fragments in the absence of filesystem metadata. Wikipedia.
«File carving», literalmente tallado de archivos aunque lo traduciremos como extracción, es el proceso de re-ensamblado de archivos extraídos de un conjunto de mayor tamaño.
List of headers and tails / Lista de cabeceras y pies
Header = Cabecera
Footer or tail = Pie
Image files / Archivos de imagen
JPEG
Header: FFD8
Footer: FFD9
GIF87a
Header: 47 49 46 38 37 61
Footer: 00 3B
GIF89a
Header: 47 49 46 38 39 61
Footer: 00 3B
BMP
Header: 42 4D
Footer: Don’t have footer, but size is in bytes 2,3,4,5 in little-endian order (low byte first).
Example: 00 00 C0 38 == 49208 bytes
PNG
Header: 89 50 4E 47 0D 0A 1A 0A
Footer: 49 45 4E 44 AE 42 60 82
Microsoft Office >2007
All this documents have the same header and footer, because of this, we need search the middle bytes. This type uses a ZIP file package.
Los documentos de Microsoft Office >2007 tienen la misma cabecera y pie, por lo que necesitamos bytes intermedios para distinguirlos. Usan encapsulado ZIP.
DOCX
Header: 50 4B 03 04 14 00 06 00
Middle: 77 6F 72 64 (word)
Footer: 50 4B 05 06 (PK..) followed by 18 additional bytes at the end of the file.
All this documents have the same header and footer, because of this, we need some bytes to differentiate them. In this case we can do this jumping 73 bytes from header. This type uses a ZIP file package.
Los documentos de OpenOffice tienen la misma cabecera y pie, por lo que necesitamos bytes intermedios para distinguirlos. Usan encapsulado ZIP.
Footer: 6D 61 6E 69 66 65 73 74 2E 78 6D 6C 50 4B 05 06 (manifest.xmlPK) followed by 18 additional bytes.
Autocad
DWG (R11/R12 versions)
Header: 41 43 31 30 30 39
Footer: CD 06 B2 F5 1F E6
DWG (R14 version)
Header: 41 43 31 30 31 34
Footer: 62 A8 35 C0 62 BB EF D4
DWG (2000 version)
Header: 41 43 31 30 31 34
Footer: DB BF F6 ED C3 55 FE
DWG (>2007 versions)
Header: 41 43 31 30 XX XX
Footer: Don’t have
Note: >2007 versions have two patterns and the key is the position 0x80. If in this position we get the bytes «68 40 F8 F7 92», we need to search again for this bytes and displace 107 bytes to find the end of the file. If in the position 0x80 we get another different bytes, we need to search again this bytes and displace 1024 bytes to find the end of the file.
Nota: Las versiones >2007 siguen dos patrones y la clave está en la posición 0x80. Si en la posicion 0x80 obtenemos los bytes «68 40 F8 F7 92», los buscamos una segunda vez y ha 107 bytes encontramos el final del archivo. Si en la posición 0x80 obtenemos otros bytes diferentes a los del primer caso, los volvemos a buscar y a 1024 bytes hallaremos el final del archivo.
Others / Otros
PDF
Header: 25 50 44 46 (%PDF)
Footers:
0A 25 25 45 4F 46 (.%%EOF) or
0A 25 25 45 4F 46 0A (.%%EOF.) or
0D 0A 25 25 45 4F 46 0D 0A (..%%EOF..) or
0D 25 25 45 4F 46 0D (.%%EOF.)
ZIP
Header: 50 4B 03 04
Footer: 50 4B 05 06 (PK..) followed by 18 additional bytes at the end of the file.
RAR (< 4.x version)
Header: 52 61 72 21 1A 07 00
Tail: C4 3D 7B 00 40 07 00
7ZIP
Header: 37 7A BC AF 27 1C 00 03 (7z¼¯’…)
Footer: 01 15 06 01 00 20 followed by 5 additional bytes at the end of the file.
Se nos proporciona la imagen anterior y se nos invita a resolver la ecuación para el menor entero positivo que representa cada fruta. La solución del reto es concatenar «Flag-» a la suma de los valores de las tres frutas.
Análisis inicial
El enunciado es breve pero ya nos adelanta que existen varias soluciones y que además sólo quieren los números más pequeños que podamos encontrar.
Las frutas están muy bien y son muy sanas pero a nosotros se nos hace más sencillo plantear la ecuación con letras.
Para arrojar algo de luz veamos la representación gráfica en 2D y 3D con la ayuda de Desmos.
Las gráficas más que luz nos traen oscuridad de modo que preguntemos a ChatGPT.
ChatGPT
resuelve: (x/y+z)+(y/x+z)+(z/x+y)=4 para enteros positivos
Dado que las variables x, y, z son enteros positivos, podemos intentar encontrar una solución para la ecuación bajo estas condiciones. Sin embargo, encontrar una solución exacta puede ser complejo debido a la naturaleza no lineal de la ecuación. Aun así, podemos intentar algunos enfoques:
Prueba y error: Podemos probar diferentes combinaciones de valores enteros positivos para x, y, z y ver si satisfacen la ecuación.
Análisis de casos específicos: Podemos comenzar analizando casos más simples, como cuando dos de las variables son iguales, y luego ampliar nuestra búsqueda desde allí.
Análisis gráfico o numérico: Utilizando herramientas gráficas o numéricas, podríamos identificar posibles soluciones y luego verificar si son enteros positivos.
Voy a realizar un análisis numérico con un rango limitado de valores para ver si encontramos alguna solución que cumpla con las condiciones. Vamos a probar con valores de 1 a 10 para cada variable.
El análisis numérico para valores de en el rango de 1 a 10 no ha encontrado ninguna solución que satisfaga la ecuación. Esto sugiere que, dentro de este rango, no existen combinaciones de enteros positivos que cumplan con la ecuación.
Dado que la ecuación es bastante compleja y no lineal, es posible que las soluciones, si existen, se encuentren fuera del rango considerado o que requieran un enfoque diferente para ser identificadas. Si tienes un rango específico de valores en mente o si hay alguna otra restricción o contexto relevante, por favor házmelo saber para poder ajustar el análisis en consecuencia.
Básicamente nos está invitando a utilizar prueba y error para encontrar una solución, y el prueba y error de las matemáticas no es más que la fuerza bruta en programación.
El código
Partiendo del problema anterior dame un código en python que realice una comprobación recursiva de todas las variables con un rango de 1 a 999.
soluciones = []
rango_valores_x = range(1, 999)
rango_valores_y = range(1, 999)
rango_valores_z = range(1, 999)
for x in rango_valores_x:
for y in rango_valores_y:
for z in rango_valores_z:
# Calculamos el valor de la expresión para cada combinación de x, y, z
valor = x / (y + z) + y / (x + z) + z / (x + y)
# Comprobamos si el valor es igual a 4 y agregamos la solución a la lista
if abs(valor - 4) < 1e-6: # Usamos una pequeña tolerancia para evitar errores de precisión
soluciones.append((x, y, z))
print(soluciones)
Dejo resaltada la línea 12 del código ya que en ella reside el problema. Está comprobando con un margen de tolerancia de 10-6 ya que el resultado de las diferentes fracciones no da como resultado exacto 4. Esto es un problema ya que nosotros necesitamos que de exactamente 4 para validar los valores enteros de x, y y z. Pongo un ejemplo para el que se haya perdido con una solución válida para la tolerancia 10-6 siendo x=2, y=264 y z=993.
En otras palabras, ChatGPT nos ha brindado una solución aproximada que no sirve para nuestro propósito. Seguimos probando con el código anterior quitando la tolerancia y con rangos mayores hasta que en 106 paro. Me acaba de quedar claro que con la fuerza bruta no vamos a ninguna parte, o más bien, no tenemos capacidad de computación para resolverlo de ésta manera.
¿Qué está pasando?
Lo que pasa es que estamos ante una ecuación algebraica de 3 incógnitas que deben ser enteros positivos cuya solución se alcanza mediante la teoría de curvas elípticas.
Curvas elípticas
Las curvas elípticas son fundamentales en matemáticas avanzadas, representadas por la ecuación y2=x3+Ax+B, donde A y B son constantes. Estas curvas son un punto de encuentro entre la geometría, la teoría de números y el álgebra, ofreciendo un campo rico para la exploración y el análisis. En este CTF, nos enfocaremos en los puntos racionales de las curvas elípticas. Utilizando el método tangente-secante, un procedimiento geométrico iterativo, buscaremos ampliar un conjunto finito de soluciones conocidas a la ecuación de la curva. Este método nos permite indagar en la estructura de las soluciones racionales, que potencialmente pueden ser infinitas. Además, estableceremos una conexión entre las soluciones enteras de las ecuaciones diofánticas y los puntos racionales en las curvas elípticas partiendo de la ecuación (1) especificada en el análisis inicial. A pesar de su aparente simplicidad, esta ecuación es conocida por presentar soluciones mínimas de gran tamaño.
Adecuación
Antes de nada, necesitamos saber el grado de la ecuación, de modo que planteamos la ecuación en forma polinómica estándar deshaciéndonos de los denominadores.
Ahora necesitamos expandir y simplificar para llegar a la conclusión de que estamos ante una ecuación diofántica de grado 3. Este proceso es engorroso por la cantidad de términos a manejar así que vamos a utilizar Mathematica como software de respaldo para finalmente obtener el polinomio en la forma de Weierstrass según la ecuación 4.
\begin{align}
& y^2=x^3+109x^2+224x\\
\end{align}
donde:
\begin{align}
x = \frac{−28(a+b+2c)}{(6a+6b−c)}\\
y = \frac{364(a−b)}{(6a+6b−c)}
\end{align}
Las relación entre la ecuación 3 y los puntos de la curva elíptica se establecen mediante la ecuación 4. Las transformaciones entre las soluciones (a, b, c) y los puntos (x, y) en la curva elíptica vienen dados por las ecuaciones 5 y 6. Con estas transformaciones, cada solución de la ecuación diofántica se puede representar como un punto en la curva elíptica, y las operaciones de suma de puntos en la curva elíptica pueden usarse para encontrar nuevas soluciones de la ecuación diofántica.
Mathematica
El código que tenéis a continuación pertenece al gran trabajo de Aditi Kulkarni [7], que además nos da el resultado para cualquier valor de n. Ojo porque para n=4 el resultado tiene 81 dígitos, para n=6 tiene 134, para n=10 tiene 190 y para n=12 asciende a 2707 dígitos.
(* Asignar un valor numérico a n *)
n = 4;
(* Definir la ecuación de una curva elíptica en términos de n *)
curve4 = y^2 == x^3 + (4*n^2 + 12*n - 3)*x^2 + 32*(n + 3)*x;
(* Encontrar un punto racional en la curva que no sea (4,0) *)
P4 = {x, y} /. First[FindInstance[curve4 && x != 4 && y != 0, {x, y}, Integers]];
(* Función para calcular la pendiente entre dos puntos en la curva,
o la derivada en el punto si son iguales *)
Slope4[{x1_, y1_}, {x2_, y2_}] :=
If[x1 == x2 && y1 == y2,
ImplicitD[curve4, y, x] /. {x -> x1, y -> y1},
(y2 - y1)/(x2 - x1)];
(* Función para calcular la intersección en y de la línea entre dos puntos
o la tangente en el punto si son iguales *)
Intercept4[{x1_, y1_}, {x2_, y2_}] := y1 - Slope4[{x1, y1}, {x2, y2}]*x1;
(* Función para encontrar el siguiente punto racional en la curva *)
nextRational4[{x1_, y1_}, {x2_, y2_}] :=
{Slope4[{x1, y1}, {x2, y2}]^2 - CoefficientList[curve4[[2]], x][[3]] - x1 - x2,
-Slope4[{x1, y1}, {x2, y2}]^3 + Slope4[{x1, y1}, {x2, y2}]*(CoefficientList[curve4[[2]], x][[3]] + x1 + x2) - Intercept4[{x1, y1}, {x2, y2}]};
(* Función para convertir un punto en la curva elíptica a una solución diofántica *)
ellipticToDiophantine[n_, {x_, y_}] :=
{(8*(n + 3) - x + y)/(2*(4 - x)*(n + 3)),
(8*(n + 3) - x - y)/(2*(4 - x)*(n + 3)),
(-4*(n + 3) - (n + 2)*x)/((4 - x)*(n + 3))};
(* Usar nextRational4 para iterar desde P4 hasta encontrar una solución
válida y positiva para la ecuación diofántica *)
sol4 = ellipticToDiophantine[n,
NestWhile[nextRational4[#, P4] &, P4,
! AllTrue[ellipticToDiophantine[n, #], Function[item, item > 0]] &]];
(* Escalar la solución para obtener enteros mínimos *)
MinSol4 = sol4*(LCM @@ Denominator[sol4])
(* Suma de las tres variables*)
Total[MinSol4]
Solución
Concatenando Flag- con el resultado de Mathematica tenemos la ansiada flag.
ChatGPT ha demostrado ser eficaz en el análisis y la resolución de problemas, siempre que se le proporcione el contexto adecuado. Sin embargo, es importante ser conscientes de que la respuesta proporcionada puede ser aproximada, especialmente si la solución requiere una gran cantidad de recursos computacionales. Por ejemplo, al trabajar con una ecuación diofántica y valores específicos para (x) e (y), ChatGPT puede ayudar a calcular puntos como (P), (2P), (3P), etc., pero hay que tener en cuenta que los resultados para estos puntos pueden ser estimaciones.
Finalmente, os invito a leer la solución de Mingliang Z. [4], en la que se resuelve el problema por completo y de forma muy detallada.
He de iniciar esta entrada diciendo que la segunda temporada de Stranger Things es sencillamente genial. Son 9 horas intensas que no dejan indiferente a nadie y además en el capítulo 8 nos han dejado una de esas perlas informáticas que tanto nos gustan.
La escena la protagoniza Bob Newby, un buen hombre amante de la electrónica de aquella época que trabaja en RadioShack y transcurre en el laboratorio secreto de Hawkins. En un momento dado, Bob propone «saltarse» la seguridad del laboratorio y para ello se traslada al sótano donde se encuentran los «servidores».
Para comprender esta escena hay que situarse temporalmente. Estamos hablando de los años 80, en concreto la escena transcurre en 1984 y los equipos de los que dispone el laboratorio son unos maravillosos IBM. No se llega a apreciar bien el modelo de IBM utilizado pero teniendo en cuenta que el monitor que aparece es un terminal IBM 3180, la búsqueda se reduce a los sistemas compatibles S/36, S/38, AS/400, 5294 ó 5394.
IBM 3180 (https://www.argecy.com/3180)
Cracking BASIC or BASIC Cracking?
La escena plantea un ataque de fuerza bruta a un código de 4 dígitos como se puede observar en la imagen a continuación. Esto puede parecer una chorrada hoy día pero podía suponer un pequeño reto para un micro de 8 bits.
Cracking Basic or Basic Cracking?
A simple vista se aprecian una serie de bucles recursivos, una llamada a una función y una sentencia condicional. Desconozco si la sintaxis del lenguaje es la correcta pero mucho me temo que es más bien una mezcla de BASIC y pseudocódigo. Pero lo que más me ha llamado la atención sin duda es que la palabra THEN parece que se sale del monitor como si estuviera realizado en post-producción. Os invito a que ampliéis la imagen y comentéis lo que os parece a vosotr@s.
Os dejo aquí el código para los más curiosos.
10 DIM FourDigitPassword INTEGER
20 FOR i = 0 TO 9
30 FOR j = 0 TO 9
40 FOR k = 0 TO 9
50 FOR l = 0 TO 9
60 FourDigitPassword = getFourDigits (i,j,k,l)
70 IF checkPasswordMatch(FourDigitPassword) = TRUE THEN
80 GOTO 140
90 END
100 NEXT l
110 NEXT k
120 NEXT j
130 NEXT i
140 PRINT FourDigitPassword
Aunque la entrada está dentro del contexto de los Blooper Tech Movies, digamos que en esta ocasión no voy a ir más allá. La escena es creíble y queda bien integrada en la época en la que se desarrolla el capítulo. Por esto mismo, solamente espero que las temporadas venideras sean tan buenas y cuiden tanto los detalles como sus predecesoras.