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
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
Hoy tenemos un crackme hecho en ensamblador y que cuenta con tres niveles. En el primero de todos nos enfrentamos a una «Splash screen» o nag. El segundo en un serial Hardcodeado y el tercero un número de serie asociado a un nombre.
Abrimos el crackme con Olly y vamos a las «Intermodular Calls«, enseguida vemos la función que crea las ventanas «CreateWindowExA«. Se puede ver lo que parece ser la creación de la pantalla del crackme y al final hay algo que salta a la vista y es la propiedad «WS_TOPMOST», es decir, que se mantenga delante del resto de ventanas.
Pinchamos sobre la función y vamos a parar aquí.
Vemos la llamada a CreateWindowExA que podríamos parchear pero vamos a pensar un poco. Vemos la función GetTickCount y que carga el valor 7D0. 7D0 es 2000 en decimal, que perfectamente pueden ser milisegundos, por lo tanto el parcheo más elegante sería poner la función GetTickCount a 0. En la imagen inferior se puede ver como queda parcheado el valor 7D0.
Probamos y funciona, pasamos a lo siguiente.
El mensaje de error del serial hardcodeado dice «Sorry, please try again». Lo buscamos en las string references y vamos a parar aquí.
Vemos un bucle de comparación que carga unos bytes de la memoria, los bytes dicen «HardCoded«, probamos y prueba superada.
Con el mismo método de las string references localizamos el código que nos interesa. Metemos deurus como nombre y 12345 como serial y empezamos a tracear. Lo primero que hace es una serie de operaciones con nuestro nombre a las que podemos llamar aritmética modular. Aunque en la imagen viene bastante detallado se vé mejor con un ejemplo.
Ejemplo para Nombre: deurus
d e u r u s 64 65 75 72 75 73 -hex 100 101 117 114 117 115 -dec 1ºByte = ((Nombre[0] % 10)^0)+2 2ºByte = ((Nombre[1] % 10)^1)+2 3ºByte = ((Nombre[2] % 10)^2)+2 4ºByte = ((Nombre[3] % 10)^3)+2 5ºByte = ((Nombre[4] % 10)^4)+2 6ºByte = ((Nombre[5] % 10)^5)+2 1ºByte = ((100 Mod 10) Xor 0) + 2 2ºByte = ((101 Mod 10) Xor 1) + 2 3ºByte = ((117 Mod 10) Xor 2) + 2 4ºByte = ((114 Mod 10) Xor 3) + 2 5ºByte = ((117 Mod 10) Xor 4) + 2 6ºByte = ((115 Mod 10) Xor 5) + 2 Si el byte > 10 --> Byte = byte - 10 1ºByte = 2 2ºByte = 2 3ºByte = 7 4ºByte = 9 5ºByte = 5 6ºByte = 2
Lo que nos deja que los Bytes mágicos para deurus son: 227952.
Debido a la naturaleza de la operación IDIV y el bucle en general, llegamos a la conclusión de que para cada letra es un solo byte mágico y que este está comprendido entre 0 y 9.
A continuación realiza las siguientes operaciones con el serial introducido.
Ejemplo para serial: 12345
1 2 3 4 5 31 32 33 34 35 -hex 49 50 51 52 53 -dec 49 mod 10 = 9 50 mod 10 = 0 51 mod 10 = 1 52 mod 10 = 2 53 mod 10 = 3
Los bytes mágicos del serial son: 90123, que difieren bastante de los conseguidos con el nombre.
A continuación compara byte a byte 227952 con 90123.
En resumen, para cada nombre genera un código por cada letra y luego la comprobación del serial la realiza usando el módulo 10 del dígito ascii. Lo primero que se me ocurre es que necesitamos cotejar algún dígito del 0 al 9 para tener cubiertas todas las posibilidades. Realizamos manualmente mod 10 a los números del 0 al 9 y obtenemos sus valores.
(0) 48 mod 10 = 8 (1) 49 mod 10 = 9 (2) 50 mod 10 = 0 (3) 51 mod 10 = 1 (4) 52 mod 10 = 2 (5) 53 mod 10 = 3 (6) 54 mod 10 = 4 (7) 55 mod 10 = 5 (8) 56 mod 10 = 6 (9) 57 mod 10 = 7
Con esto ya podríamos generar un serial válido.
0123456789 - Nuestro alfabeto numérico 8901234567 - Su valor Mod 10
Por lo que para deurus un serial válido sería: 449174. Recordemos que los bytes mágicos para deurus eran «227952», solo hay que sustituir.
Para realizar un KeyGen más interesante, he sacado los valores de un alfabeto mayor y le he añadido una rutina aleatoria para que genere seriales diferentes para un mismo nombre.
'abcdefghijklmnñppqrstuvwxyz0123456789ABCDEFGHIJKLMNÑOPQRSTUVWXYZ - Alfabeto
'7890123456778901234567789018901234567567890123455678901234556880 - Valor
Dim suma As Integer = 0
'Para hacer el serial más divertido
Dim brute() As String = {"2", "3", "4", "5", "6", "7", "8", "9", "0", "1"}
Dim brute2() As String = {"d", "e", "f", "g", "h", "i", "j", "a", "b", "c"}
Dim brute3() As String = {"P", "Q", "R", "S", "T", "U", "j", "a", "D", "E"}
Dim alea As New Random()
txtserial.Text = ""
'Evito nombres mayores de 11 para evitar el BUG comentado en le manual
If Len(txtnombre.Text) > 0 And Len(txtnombre.Text) < 12 Then
For i = 1 To Len(txtnombre.Text)
Dim aleatorio As Integer = alea.Next(0, 9)
suma = (((Asc(Mid(txtnombre.Text, i, 1))) Mod 10) Xor i - 1) + 2
If suma > 9 Then
suma = suma - 10
End If
If (aleatorio) >= 0 And (aleatorio) <= 4 Then
txtserial.Text = txtserial.Text & brute(suma)
ElseIf (aleatorio) > 4 And (aleatorio) <= 7 Then
txtserial.Text = txtserial.Text & brute2(suma)
ElseIf (aleatorio) > 7 And (aleatorio) <= 10 Then
txtserial.Text = txtserial.Text & brute3(suma)
End If
suma = 0
Next
Else
txtserial.Text = "El Nombre..."
End If
Hay un pequeño bug en el almacenaje del nombre y serial y en el guardado de bytes mágicos del serial. Si nos fijamos en los bucles del nombre y el serial, vemos que los bytes mágicos del nombre los guarda a partir de la dirección de memoria 403258 y los bytes mágicos del serial a partir de 40324D. En la siguiente imagen podemos ver seleccionados los 11 primeros bytes donde se almacenan los bytes mágicos del serial. Vemos que hay seleccionados 11 bytes y que el siguiente sería ya 403258, precisamente donde están los bytes mágicos del nombre. Como puedes imaginar si escribes un serial >11 dígitos se solapan bytes y es una chapuza, de modo que el keygen lo he limitado a nombres de 11 dígitos.
Hoy vamos a enfrentarnos a cuatro retos de esteganografía relativamente sencillos, y digo relativamente, debido a que hay tantas formas de esconder información en un archivo, ya sea imagen, vídeo o sonido, que afrontarlos suele ser desesperante. Las cuatro imágenes son aparentemente las mismas que la que se ve en portada.
Una buena práctica cuando te enfrentas a retos stego de tipo imagen es realizar una búsqueda inversa. Una búsqueda inversa consiste en buscar la imagen original mediante buscadores especializados como TinEye o Google. Si conseguimos la imagen original podemos resolver el reto simplemente comparando o nos puede dar una idea del tipo de modificación por su diferencia de tamaño, colores, degradados, etc.
Descargamos la imagen del reto. Se trata de una imagen JPEG de 526×263 y 76.6 KB (78445 bytes). Su hash SHA1 es «89aed5bbc3542bf5c60c4c318fe99cb1489f267a«
Realizamos una búsqueda inversa de la imagen y encontramos sin dificultad la imagen original mediante TinEye.
Características de la imagen original:
Por lo que vemos ha cambiado el tamaño de 78447 bytes a 78445 bytes y su hash SHA1 tampoco coincide obviamente, lo que nos confirma que ha sufrido alguna modificación. Echando un vistazo con un editor hexadecimal te puedes volver loco por lo que vamos a realizar una comparación mediante la herramienta online DiffNow.
Al realizar la comparación sale a relucir lo que buscamos. La clave es una simple cadena de texto.
Lo primero es realizar de nuevo la comparación.
| Imagen | Tamaño | SHA1 |
|---|---|---|
| Original | 78447 bytes | 8924676317077fc07c252ddeec04bd2a0ecfdda4 |
| imagen2.jpeg | 116386 bytes | 7641e3906f795c137269cefef29f30fcb9cb1b07 |
Como vemos, la imagen ha aumentado significativamente, de 76,6 KB a 113 KB. Cuando el aumento de tamaño llama la atención normalmente tenemos otro archivo insertado. Lo primero que suelo hacer yo es fijarme si ha sido modificado el final del archivo con un editor hexadecimal. Los bytes de cola de un archivo jpg/jpeg son FFD9 y en este caso no vemos modificación alguna al final del archivo. Si el archivo no está al final requiere realizar una búsqueda más exhaustiva. Para estos casos tengo una herramienta de creación propia que se llama Ancillary y que sirve para buscar cierto tipo de archivos dentro de otros como imágenes, documentos de Office, Open Office, pdf, etc. Ancillary encuentra otro jpg que es el que le daba el peso extra y que vemos a continuación. La clave es el título de la película (ojo a las mayúsculas/minúsculas).
El tercer reto parece que tiene algún error debido a que el archivo coincide completamente con el original. Pienso que se ha subido la imagen original por error. Se lo he comunicado al admin del dominio y si algún día obtengo respuesta actualizaré la entrada.
| Imagen | Tamaño | SHA1 |
|---|---|---|
| Original | 78447 bytes | 8924676317077fc07c252ddeec04bd2a0ecfdda4 |
| imagen3.jpeg | 78447 bytes | 8924676317077fc07c252ddeec04bd2a0ecfdda4 |
Actualización 21/08/2016
Al parecer, la solución de este reto es llegar a la conclusión de que la imagen no está modificada. La respuesta del Administrador de la web así lo confirma.
desingsecurity [at] gmail [dot] com – Sorry about the delay, is precisely what is intended with that challenge, they can determine if the image is changed or not , the challenge was solved you . We’ll be equal way improving this point.
Greetings and Thanks
Stego 4
Lo primero es realizar de nuevo la comparación.
| Imagen | Tamaño | SHA1 |
|---|---|---|
| Original | 78447 bytes | 8924676317077fc07c252ddeec04bd2a0ecfdda4 |
| imagen4.jpeg | 93174 bytes | a6329ea4562ef997e5afd067f3b53bdab4665851 |
Al igual que en el caso dos el tamaño ha aumentado significativamente de modo que miramos al final del archivo y esta vez si vemos que hay insertado unos bytes tras el final del jpg (recordemos FFD9)
El archivo tiene pinta de ser una hoja de cálculo de Open Office o Libre Office según indica la palabra «spreadsheet«. Lo abrimos con Excel y tras analizar la maraña de datos enseguida vemos una clave que llama la atención.
AperiSolve es un conjunto de herramientas de análisis esteganográfico que nos ayuda a echar un primer vistazo cuando sospechamos que una imagen esconde algo.
Zsteg es una herramienta especializada en la detección y extracción de información oculta en imágenes, especialmente en formatos PNG y BMP. Está orientada a la esteganografía basada en bit-planes y es muy popular en entornos CTF y análisis forense, gracias a su capacidad para automatizar búsquedas exhaustivas de datos escondidos en los bits menos significativos (LSB) y en configuraciones de color poco habituales. Su principal fortaleza es que no se limita a examinar un único plano: prueba sistemáticamente combinaciones de canales (R, G, B, A), número de bits, orden de lectura y posicionamiento, detectando patrones que podrían pasar inadvertidos en una revisión manual.
Entre sus características más destacadas se encuentran la identificación automática de firmas de archivos (ZIP, PNG, texto ASCII, GZIP, etc.), la extracción directa de bitstreams reconstruidos y el soporte para diferentes rutas de exploración, como
b1,rgb,lsb,xy, que describen exactamente cómo se han recuperado los datos. Esta capacidad de correlacionar parámetros técnicos con resultados concretos convierte a zsteg en una herramienta muy eficiente tanto para localizar contenido oculto como para entender la técnica esteganográfica aplicada.
En AperiSolve se utiliza únicamente la parte de Zsteg encargada de ejecutar el análisis automático y devolver todas las detecciones posibles de esteganografía LSB en imágenes PNG y BMP. Concretamente, AperiSolve llama al comando zsteg <imagen> tal como está implementado en el módulo analyze_zsteg , y captura la salida completa línea por línea. Esta salida incluye todas las combinaciones probadas de bit-planes (b1, b2…), canales (r, g, b, a), orden de bits (lsb/msb) y métodos de recorrido (xy), junto con cualquier coincidencia que zsteg reconozca como firma de archivo o texto. Es decir, AperiSolve no aplica filtros ni interpretación adicional: muestra exactamente lo que zsteg detecta y lo organiza para que el usuario pueda identificar rápidamente si existe un archivo embebido, contenido ASCII, o algún patrón de interés.
En AperiSolve veremos algo como esto:
... b1,a,lsb,xy .. b1,a,msb,xy .. b1,rgb,lsb,xy .. file: Zip archive data, at least v1.0 to extract, compression method=store b1,rgb,msb,xy .. b1,bgr,lsb,xy .. b1,bgr,msb,xy .. b1,rgba,lsb,xy .. b1,rgba,msb,xy .. file: OpenPGP Public Key b1,abgr,lsb,xy .. b1,abgr,msb,xy .. file: OpenPGP Secret Key b2,r,lsb,xy .. b2,r,msb,xy .. text: "P@UPUUPAAUU@" b2,g,lsb,xy .. text: "(ahOFyIS!" ...
Para entender mejor a que se refiere todo esto vamos a repasar lo básico.
Cuando hablamos de esteganografía en imágenes PNG/BMP, nos referimos a manipular bits dentro de los canales de color (R, G, B, A). Cada canal tiene un valor de 0–255, es decir, 8 bits:
R = 11001010 G = 00110101 B = 11100001
LSB — Least Significant Bit (bit menos significativo). Es el bit más débil, el de la derecha:
1100101[0] ← LSB
Modificarlo cambia muy poco el color, por eso se usa en esteganografía.
Ejemplo: cambiar 11001010 ↦ 11001011 no cambia el color perceptible.
MSB — Most Significant Bit (bit más significativo). Es el bit más importante, el de la izquierda:
[1]1001010 ← MSB
Modificarlo sí altera mucho el color. A veces se usa pero suele ser detectable.
Cuando Zsteg muestra una línea del estilo b1,rgb,lsb,xy .. file: Zip archive data, está indicando que ha analizado la imagen extrayendo bits según la ruta especificada —en este caso, 1 bit por píxel (b1), combinando los canales rojo, verde y azul (rgb), utilizando el bit menos significativo (lsb) y recorriendo los píxeles en orden normal de lectura (xy)— y que, tras recomponer esos bits, el resultado coincide con la cabecera reconocible de un tipo de archivo real. Por eso aparece “file: Zip archive data”: significa que los bits ocultos forman un flujo válido cuya firma corresponde a un archivo ZIP. En otras ocasiones puede detectar texto ASCII, PNG, JPEG u otros formatos. En resumen, cuando Zsteg muestra esta línea no solo indica dónde se ocultan los datos, sino que confirma que lo recuperado es un archivo auténtico y probablemente extraíble, ya que la estructura binaria coincide con un formato conocido.
Si vemos que Zsteg nos ofrece algo interesante, podemos extraerlo mediante el comando:
zsteg -E b1,rgb,lsb,xy imagen.png > dump.bin
También es habitual usar herramientas como StegSolve. En este caso debemos dirigirnos a Analyse > Data extract para comprobar lo encontrado por zsteg y extraerlo mediante Save Bin.
| Zsteg | > Significado < | StegSolve |
|---|---|---|
| b1 | Extrae 1 bit por canal (bit plano 0, el menos significativo). | En Bit Planes, marca Red 0, Green 0, Blue 0. Solo esos. |
| rgb | Usa R + G + B en ese orden para reconstruir los bytes. | En Bit Plane Order, selecciona RGB. |
| lsb | Lee los bits empezando por el LSB (bit 0) antes que el MSB. | En Bit Order, selecciona LSB First. |
| xy | Recorre la imagen por filas (izquierda → derecha, arriba → abajo). | En Extract By, elige Row. |
Más allá de este caso concreto, conviene recordar que la esteganografía no se limita a los LSB: existen métodos basados en paletas, metadatos, manipulación de PNG chunks, secuencias alfa, audio incrustado o capas completas en formatos no comprimidos. Por ello, un análisis completo debería combinar la búsqueda clásica de LSB con herramientas complementarias como binwalk, foremost, exiftool, strings, o incluso análisis manual de cabeceras hexadecimales.
Hoy tenemos un crackme hecho en ensamblador y que cuenta con tres niveles. En el primero de todos nos enfrentamos a una «Splash screen» o nag. El segundo en un serial Hardcodeado y el tercero un número de serie asociado a un nombre.
Abrimos el crackme con Olly y vamos a las «Intermodular Calls«, enseguida vemos la función que crea las ventanas «CreateWindowExA«. Se puede ver lo que parece ser la creación de la pantalla del crackme y al final hay algo que salta a la vista y es la propiedad «WS_TOPMOST», es decir, que se mantenga delante del resto de ventanas.
Pinchamos sobre la función y vamos a parar aquí.
Vemos la llamada a CreateWindowExA que podríamos parchear pero vamos a pensar un poco. Vemos la función GetTickCount y que carga el valor 7D0. 7D0 es 2000 en decimal, que perfectamente pueden ser milisegundos, por lo tanto el parcheo más elegante sería poner la función GetTickCount a 0. En la imagen inferior se puede ver como queda parcheado el valor 7D0.
Probamos y funciona, pasamos a lo siguiente.
El mensaje de error del serial hardcodeado dice «Sorry, please try again». Lo buscamos en las string references y vamos a parar aquí.
Vemos un bucle de comparación que carga unos bytes de la memoria, los bytes dicen «HardCoded«, probamos y prueba superada.
Con el mismo método de las string references localizamos el código que nos interesa. Metemos deurus como nombre y 12345 como serial y empezamos a tracear. Lo primero que hace es una serie de operaciones con nuestro nombre a las que podemos llamar aritmética modular. Aunque en la imagen viene bastante detallado se vé mejor con un ejemplo.
Ejemplo para Nombre: deurus
d e u r u s 64 65 75 72 75 73 -hex 100 101 117 114 117 115 -dec 1ºByte = ((Nombre[0] % 10)^0)+2 2ºByte = ((Nombre[1] % 10)^1)+2 3ºByte = ((Nombre[2] % 10)^2)+2 4ºByte = ((Nombre[3] % 10)^3)+2 5ºByte = ((Nombre[4] % 10)^4)+2 6ºByte = ((Nombre[5] % 10)^5)+2 1ºByte = ((100 Mod 10) Xor 0) + 2 2ºByte = ((101 Mod 10) Xor 1) + 2 3ºByte = ((117 Mod 10) Xor 2) + 2 4ºByte = ((114 Mod 10) Xor 3) + 2 5ºByte = ((117 Mod 10) Xor 4) + 2 6ºByte = ((115 Mod 10) Xor 5) + 2 Si el byte > 10 --> Byte = byte - 10 1ºByte = 2 2ºByte = 2 3ºByte = 7 4ºByte = 9 5ºByte = 5 6ºByte = 2
Lo que nos deja que los Bytes mágicos para deurus son: 227952.
Debido a la naturaleza de la operación IDIV y el bucle en general, llegamos a la conclusión de que para cada letra es un solo byte mágico y que este está comprendido entre 0 y 9.
A continuación realiza las siguientes operaciones con el serial introducido.
Ejemplo para serial: 12345
1 2 3 4 5 31 32 33 34 35 -hex 49 50 51 52 53 -dec 49 mod 10 = 9 50 mod 10 = 0 51 mod 10 = 1 52 mod 10 = 2 53 mod 10 = 3
Los bytes mágicos del serial son: 90123, que difieren bastante de los conseguidos con el nombre.
A continuación compara byte a byte 227952 con 90123.
En resumen, para cada nombre genera un código por cada letra y luego la comprobación del serial la realiza usando el módulo 10 del dígito ascii. Lo primero que se me ocurre es que necesitamos cotejar algún dígito del 0 al 9 para tener cubiertas todas las posibilidades. Realizamos manualmente mod 10 a los números del 0 al 9 y obtenemos sus valores.
(0) 48 mod 10 = 8 (1) 49 mod 10 = 9 (2) 50 mod 10 = 0 (3) 51 mod 10 = 1 (4) 52 mod 10 = 2 (5) 53 mod 10 = 3 (6) 54 mod 10 = 4 (7) 55 mod 10 = 5 (8) 56 mod 10 = 6 (9) 57 mod 10 = 7
Con esto ya podríamos generar un serial válido.
0123456789 - Nuestro alfabeto numérico 8901234567 - Su valor Mod 10
Por lo que para deurus un serial válido sería: 449174. Recordemos que los bytes mágicos para deurus eran «227952», solo hay que sustituir.
Para realizar un KeyGen más interesante, he sacado los valores de un alfabeto mayor y le he añadido una rutina aleatoria para que genere seriales diferentes para un mismo nombre.
'abcdefghijklmnñppqrstuvwxyz0123456789ABCDEFGHIJKLMNÑOPQRSTUVWXYZ - Alfabeto
'7890123456778901234567789018901234567567890123455678901234556880 - Valor
Dim suma As Integer = 0
'Para hacer el serial más divertido
Dim brute() As String = {"2", "3", "4", "5", "6", "7", "8", "9", "0", "1"}
Dim brute2() As String = {"d", "e", "f", "g", "h", "i", "j", "a", "b", "c"}
Dim brute3() As String = {"P", "Q", "R", "S", "T", "U", "j", "a", "D", "E"}
Dim alea As New Random()
txtserial.Text = ""
'Evito nombres mayores de 11 para evitar el BUG comentado en le manual
If Len(txtnombre.Text) > 0 And Len(txtnombre.Text) < 12 Then
For i = 1 To Len(txtnombre.Text)
Dim aleatorio As Integer = alea.Next(0, 9)
suma = (((Asc(Mid(txtnombre.Text, i, 1))) Mod 10) Xor i - 1) + 2
If suma > 9 Then
suma = suma - 10
End If
If (aleatorio) >= 0 And (aleatorio) <= 4 Then
txtserial.Text = txtserial.Text & brute(suma)
ElseIf (aleatorio) > 4 And (aleatorio) <= 7 Then
txtserial.Text = txtserial.Text & brute2(suma)
ElseIf (aleatorio) > 7 And (aleatorio) <= 10 Then
txtserial.Text = txtserial.Text & brute3(suma)
End If
suma = 0
Next
Else
txtserial.Text = "El Nombre..."
End If
Hay un pequeño bug en el almacenaje del nombre y serial y en el guardado de bytes mágicos del serial. Si nos fijamos en los bucles del nombre y el serial, vemos que los bytes mágicos del nombre los guarda a partir de la dirección de memoria 403258 y los bytes mágicos del serial a partir de 40324D. En la siguiente imagen podemos ver seleccionados los 11 primeros bytes donde se almacenan los bytes mágicos del serial. Vemos que hay seleccionados 11 bytes y que el siguiente sería ya 403258, precisamente donde están los bytes mágicos del nombre. Como puedes imaginar si escribes un serial >11 dígitos se solapan bytes y es una chapuza, de modo que el keygen lo he limitado a nombres de 11 dígitos.
Enemigo público (Enemy of the State) es una película de acción y suspense dirigida por Tony Scott, estrenada en 1998. La historia sigue a Robert Clayton Dean (Will Smith), un abogado de Washington D.C. que se ve atrapado en una conspiración de vigilancia masiva cuando recibe, sin saberlo, una cinta de video que documenta el asesinato de un congresista a manos de un alto funcionario de la Agencia de Seguridad Nacional (NSA), interpretado por Jon Voight. La situación se complica cuando la NSA utiliza toda su tecnología de espionaje para seguir y neutralizar a Dean.
Dean encuentra ayuda en Edward «Brill» Lyle (Gene Hackman), un exanalista de la NSA convertido en un experto en vigilancia que vive en el anonimato. Juntos intentan descubrir la verdad y exponer la conspiración, mientras son perseguidos por la propia NSA. Un papel crucial también lo desempeña el personaje de Daniel Zavitz, interpretado por Jason Lee, un joven investigador que graba accidentalmente el asesinato y termina transmitiendo la evidencia a Dean. El elenco incluye además a Lisa Bonet, Regina King, Jack Black, Barry Pepper, y Seth Green.
En Enemigo Público, la tecnología juega un papel crucial no solo en la trama sino también en la ambientación de la película. La precisión y el realismo de los equipos informáticos utilizados contribuyen a la atmósfera de paranoia y vigilancia que define la narrativa.
Jason Lee, en su papel de Daniel Zavitz, utiliza un PC clónico, claramente identificado por el logo de Sun Microsystems en la torre del ordenador. Sin embargo, el sistema operativo que corre en esta máquina es Windows 3.1, una versión que, para 1998, ya estaba obsoleta, habiendo sido lanzada en 1992. Esta elección subraya el hecho de que Zavitz utiliza equipamiento más económico y anticuado, en contraste con la tecnología más avanzada de otros personajes.
Zavitz también utiliza Media Player, un reproductor de video básico integrado en Windows 3.1. Durante la reproducción del archivo de video crucial para la trama, se puede observar que la extensión del archivo es .CAM. Este tipo de archivo podría implicar un video capturado por una cámara, pero también sugiere (por otros fotogramas de la película) que el codec utilizado para comprimir el video podría ser QuickTime, permitiendo una reproducción cruzada entre diferentes sistemas operativos.
Además, Zavitz utiliza un reproductor portátil NEC Turbo Express, un dispositivo de videojuegos portátil de la época. En la película, este dispositivo es empleado de manera innovadora para reproducir y transferir datos, algo poco realista pero que añade dramatismo a la escena. La tarjeta PCMCIA de 200MB que Zavitz utiliza para almacenar el video es otro ejemplo de la tecnología de la época, reflejando la capacidad de almacenamiento portátil antes de la popularización de los dispositivos USB.
Por su parte, Gene Hackman, en su papel de Brill, maneja un sistema considerablemente más avanzado, utilizando Windows 98. Este sistema operativo, lanzado también en 1998, representaba lo más avanzado en términos de compatibilidad y usabilidad en ese momento, lo que refuerza la imagen de Brill como un experto en tecnología con acceso a mejores recursos.
Aunque en la película no se detalla el hardware específico de Brill, el hecho de que use Windows 98, junto con las capacidades de manipulación y decodificación de video que se muestran, sugiere que tiene acceso a tecnología de alta gama para la época. En una escena clave, se observa cómo Brill decodifica el video utilizando una interfaz gráfica llamativa, diseñada claramente para atraer la atención del espectador, más que para reflejar la realidad de la tecnología disponible en ese momento.
La producción de Enemigo Público es destacable por su atención al detalle en lo referente al equipamiento tecnológico de los personajes. El contraste entre el equipo más antiguo y económico utilizado por Daniel Zavitz (Jason Lee) y el sistema más avanzado de Edward Lyle (Gene Hackman) refleja de manera efectiva el trasfondo de los personajes. Zavitz, como investigador freelance, se maneja con recursos limitados, mientras que Lyle, con su pasado en la NSA y mayor poder adquisitivo, tiene acceso a tecnología más avanzada.
Otro detalle interesante es la diferenciación en el equipamiento dentro de la central de la NSA. Mientras los empleados comunes utilizan monitores CRT, que eran estándar en la época, el personaje de Thomas Reynolds (Jon Voight) dispone de una pantalla plana, lo que subraya su estatus superior dentro de la agencia. Estos detalles de producción contribuyen a la autenticidad y la profundidad visual de la película.
Sin embargo, la película no está exenta de licencias creativas que sacrifican el realismo tecnológico en favor del impacto visual. Un ejemplo claro es cuando un técnico de la NSA, a partir de un fotograma de un vídeo de seguridad, rota la imagen en 3D para simular lo que Zavitz podría haber introducido en la bolsa de Dean. Aunque esta secuencia añade dramatismo, carece de una base tecnológica realista.
Del mismo modo, la escena donde Brill decodifica el vídeo utilizando una interfaz visualmente llamativa es un claro ejemplo de cómo la película opta por elementos más glamurosos para captar la atención del espectador, alejándose de la realidad técnica, donde estos procesos serían mucho menos espectaculares y más funcionales. Además se pueden observar las siguientes curiosidades:
En resumen, Enemigo Público logra un equilibrio eficaz entre el realismo tecnológico y las exigencias dramáticas del cine. A pesar de algunas exageraciones en la representación de la tecnología, la atención al detalle en los aspectos técnicos y la diferenciación de equipos según los personajes y sus circunstancias es un testimonio del buen trabajo de producción que hace que la película siga siendo entretenida, incluso más de dos décadas después de su estreno.
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.
Aquí os dejo un video tutorial. El crackme lo podeis encontrar en crackmes.de.
