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
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.
Header = Cabecera
Footer or tail = Pie
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.
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.
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.
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.
Resumidamente, esta técnica consiste en ocultar información en el bit menos significativo de cada uno de los píxeles de una imagen, consiguiendo así que el cambio realizado sea invisible al ojo humano. El problema de esta técnica, es que la información oculta puede obtenerse fácilmente si esta no se ha codificado previamente o si no se sigue un patrón concreto a la hora de ocultarla.
Desde la web del reto nos avisan de que esto es un simple truco pero espectacular. Nos animan a descargar una imágen y a encontrar la solución oculta.
Aprovecho este reto para presentaros una herramienta vital al enfrentaros a ciertos retos sobre esteganografía, steganabara.
Steganabara tiene dos apartados muy interesantes, uno es «color table» y otro «bit mask«, hoy veremos en acción a «bit mask».
No os preocupéis por la solución ya que cambia para cada usuario y sesión.
Abrimos steganabara y empezamos a trastear con bit mask.
Al poco tiempo ya vemos que vamos bien encaminados.
Finalmente no nos cuesta dar con la solución.
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.
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++.
El reto consiste en dos imágenes (v1.png y v2.png) que, a simple vista, parecen contener ruido aleatorio. Sin embargo, ambas forman parte de un sistema de criptografía visual en la que cada imagen contiene información parcial que no es interpretable por separado, pero que al combinarse correctamente revelan información oculta.
La trampa está en que la combinación no se hace con operaciones normales como suma, resta o multiplicación. El autor del reto espera que el jugador use una herramienta como StegSolve y pruebe distintas operaciones tipo XOR, AND o MUL hasta encontrar una transformación en la que uno de los métodos muestre algo significativo. El truco está en llegar a la conclusión de que una de las imágenes hay que invertirla antes de combinar ambas imágenes. Todo esto se puede hacer con StegSolve sin necesidad de utilizar ninguna herramienta adicional, pero voy a aprovechar para hacerlo con python y así de paso entendemos como realiza las operaciones StegSolve. En resumen, para resolver el reto basta con:
La operación MUL no es una multiplicación normalizada, sino una multiplicación de enteros de 24 bits (0xRRGGBB) con overflow, algo que la mayoría de herramientas no replican correctamente.
Las imágenes están preparadas para que ciertos bits de color en una imagen sean el complemento de los de la otra. Por tanto:
La operación MUL de StegSolve no es una multiplicación de píxeles, es decir, no hace:
R = (R1 * R2) / 255
sino:
c1 = 0xRRGGBB (pixel 1) c2 = 0xRRGGBB (pixel 2) resultado = (c1 * c2) & 0xFFFFFF
Con todo esto claro, he preparado un script para combinar las imágenes de forma automática.
import os
import numpy as np
from PIL import Image
# =========================================================
# UTILIDADES
# =========================================================
def ensure_output():
if not os.path.exists("output"):
os.makedirs("output")
def load_rgb(path):
img = Image.open(path).convert("RGB")
return np.array(img, dtype=np.uint32)
def save_rgb(arr, name):
Image.fromarray(arr.astype(np.uint8), "RGB").save(os.path.join("output", name))
def invert_xor(arr):
"""Colour Inversion (Xor) de StegSolve."""
out = arr.copy()
out[..., :3] = 255 - out[..., :3]
return out
# =========================================================
# FUNCIONES DE COMBINER EXACTAS DE STEGSOLVE
# =========================================================
def to24(arr):
"""Convierte RGB → entero 0xRRGGBB."""
return ((arr[..., 0] << 16) |
(arr[..., 1] << 8) |
arr[..., 2])
def from24(c):
"""Convierte entero 0xRRGGBB → RGB."""
R = (c >> 16) & 0xFF
G = (c >> 8) & 0xFF
B = c & 0xFF
return np.stack([R, G, B], axis=-1).astype(np.uint8)
# ------------------------------
# Funciones auxiliares
# ------------------------------
def comb_xor(c1, c2):
return from24((c1 ^ c2) & 0xFFFFFF)
def comb_or(c1, c2):
return from24((c1 | c2) & 0xFFFFFF)
def comb_and(c1, c2):
return from24((c1 & c2) & 0xFFFFFF)
def comb_add(c1, c2):
return from24((c1 + c2) & 0xFFFFFF)
def comb_add_sep(c1, c2):
R = (((c1 >> 16) & 0xFF) + ((c2 >> 16) & 0xFF)) & 0xFF
G = (((c1 >> 8) & 0xFF) + ((c2 >> 8) & 0xFF)) & 0xFF
B = ((c1 & 0xFF) + (c2 & 0xFF)) & 0xFF
return from24((R << 16) | (G << 8) | B)
def comb_sub(c1, c2):
return from24((c1 - c2) & 0xFFFFFF)
def comb_sub_sep(c1, c2):
R = (((c1 >> 16) & 0xFF) - ((c2 >> 16) & 0xFF)) & 0xFF
G = (((c1 >> 8) & 0xFF) - ((c2 >> 8) & 0xFF)) & 0xFF
B = ((c1 & 0xFF) - (c2 & 0xFF)) & 0xFF
return from24((R << 16) | (G << 8) | B)
def comb_mul(c1, c2):
"""MUL EXACTO StegSolve"""
return from24((c1 * c2) & 0xFFFFFF)
def comb_mul_sep(c1, c2):
R = (((c1 >> 16) & 0xFF) * ((c2 >> 16) & 0xFF)) & 0xFF
G = (((c1 >> 8) & 0xFF) * ((c2 >> 8) & 0xFF)) & 0xFF
B = ((c1 & 0xFF) * (c2 & 0xFF)) & 0xFF
return from24((R << 16) | (G << 8) | B)
def comb_lightest(c1, c2):
"""Máximo por canal"""
R = np.maximum((c1 >> 16) & 0xFF, (c2 >> 16) & 0xFF)
G = np.maximum((c1 >> 8) & 0xFF, (c2 >> 8) & 0xFF)
B = np.maximum(c1 & 0xFF, c2 & 0xFF)
return from24((R << 16) | (G << 8) | B)
def comb_darkest(c1, c2):
"""Mínimo por canal"""
R = np.minimum((c1 >> 16) & 0xFF, (c2 >> 16) & 0xFF)
G = np.minimum((c1 >> 8) & 0xFF, (c2 >> 8) & 0xFF)
B = np.minimum(c1 & 0xFF, c2 & 0xFF)
return from24((R << 16) | (G << 8) | B)
# Lista de transformaciones
TRANSFORMS = {
"xor": comb_xor,
"or": comb_or,
"and": comb_and,
"add": comb_add,
"add_sep": comb_add_sep,
"sub": comb_sub,
"sub_sep": comb_sub_sep,
"mul": comb_mul,
"mul_sep": comb_mul_sep,
"lightest": comb_lightest,
"darkest": comb_darkest,
}
# =========================================================
# GENERACIÓN DE TODAS LAS COMBINACIONES
# =========================================================
def generate_all(imA, imB, labelA, labelB):
print(f"Generando combinaciones: {labelA} vs {labelB}")
c1 = to24(imA)
c2 = to24(imB)
for name, fun in TRANSFORMS.items():
out = fun(c1, c2)
save_rgb(out, f"{labelA}__{labelB}__{name}.png")
print(f"{labelA}-{labelB} completado.")
# =========================================================
# MAIN
# =========================================================
ensure_output()
print("Cargando imágenes v1.png y v2.png...")
im1 = load_rgb("v1.png")
im2 = load_rgb("v2.png")
print("Generando invertidas estilo StegSolve...")
im1_x = invert_xor(im1)
im2_x = invert_xor(im2)
save_rgb(im1_x, "v1_xored.png")
save_rgb(im2_x, "v2_xored.png")
# Generar las 52 combinaciones:
generate_all(im1, im2, "v1", "v2")
generate_all(im1_x, im2, "v1x", "v2")
generate_all(im1, im2_x, "v1", "v2x")
generate_all(im1_x, im2_x, "v1x", "v2x")
print("\nResultados en carpeta ./output/")
A continuación os muestro parte de las imágenes generadas por el script. El secreto oculto era un código QR que nos da la solución al reto.
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.
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.
Esta vez vamos a analizar los CrackMes de un antiguo colaborador de Karpoff Spanish Tutor, CrkViZ. En estas cinco soluciones vamos a pelearnos con Visual Basic 5/6 nativo y Pcode, con el registro de Windows y tendremos que parchear algúna rutina antidebug. Los CrackMes son del año 2000 y aunque algunos estaban ya solucionados, los analizaremos igualmente para ver la diferencia que existe con los análisis realizados en aquellos años, sí, estamos hablando del Softice.
Cuando hablamos de Visual Basic 5/6, podemos destacar 3 herramientas que nos facilitan mucho la vida, VB Decompiler, VB Reformer y ExDec. Las dos primeras se defienden bien tanto con código nativo como pcode y ExDec solamente nos sirve para pcode. Aún así, si todo lo demás falla, Ollydbg nos sacará de apuros.
Este primer crackme está compilado en Pcode y hoy día, con las herramientas de que disponemos no supone ninguna dificultad. Tan solo debemos abrirlo con VB Decompiler y ya nos encontramos con el serial válido.
Los opcodes obtenidos con ExDec se ven de la siguiente manera.
...... 402F14: 04 FLdRfVar local_008C 402F17: 21 FLdPrThis 402F18: 0f VCallAd 7b3fc340 402F1B: 19 FStAdFunc local_0088 402F1E: 08 FLdPr local_0088 402F21: 0d VCallHresult 7b3fbe88 402F26: 6c ILdRf local_008C 402F29: 1b LitStr: 57230198 <-------------- 402F2C: Lead0/30 EqStr 402F2E: 2f FFree1Str local_008C 402F31: 1a FFree1Ad local_0088 402F34: 1c BranchF: 403012 402F37: 21 FLdPrThis 402F38: 0d VCallHresult 7b3fc2b0 402F3D: 3a LitVarStr: ( local_00AC ) Gracias por Registrar!! 402F42: Lead2/00 FStVarCopy 402F46: 27 LitVar_Missing 402F49: 27 LitVar_Missing 402F4C: 3a LitVarStr: ( local_00AC ) CrkViz 402F51: 4e FStVarCopyObj local_00BC 402F54: 04 FLdRfVar local_00BC 402F57: f5 LitI4: 0x40 64 (...@) 402F5C: 04 FLdRfVar local_009C 402F5F: 0a ImpAdCallFPR4: _rtcMsgBox 402F64: 36 FFreeVar 402F6D: 27 LitVar_Missing 402F70: 25 PopAdLdVar 402F71: 27 LitVar_Missing ......
Este segundo crackme también está compilado en pcode. La rutina del serial es muy sencilla pero al introducir un número aleatorio nos obliga a parchear. Cargamos el crackme en VB Decompiler y nos muestra esto:
Básicamente vemos que genera un número aleatorio entre 1 y 999999999 y luego le suma 1. La forma de afrontar esto es parcheando. Nos fijamos en el offset aproximado (4037F2) y abrimos el crackme en un editor hexadecimal. La forma de convertir el offset que nos muestra VB Decompiler a lo que nos muestra un editor hexadecimal es la siguiente.
VBdec_offset - Image Base - VirtualOffset + RawOffset = Offset_Editor.H 4037F2 - 400000 - 1000 + 400 = 2BF2
Una vez localizados los bytes, los cambiamos por ceros y guardamos.
Una vez parcheado, el serial correcto es 1.
En esta tercera entrega, CrkViz aumentó la dificultad. El crackme está compilado en código nativo y nos enfrentamos a un serial asociado a un nombre y a una rutina antidebug que en realidad es una Nag, ya que se muestra siempre.
Afrontar la nag es muy sencillo, basta con localizarla y parchear la llamada.
CPU Disasm Address Hex dump Command Comments 004058E2 8D4D DC LEA ECX,[EBP-24] 004058E5 C785 BCFDFFFF B MOV DWORD PTR SS:[EBP-244],CrkMeViz-3.004033B8 ; UNICODE " Debugger detectado!!! " 004058EF C785 B4FDFFFF 0 MOV DWORD PTR SS:[EBP-24C],8 004058F9 FFD7 CALL EDI 004058FB B9 04000280 MOV ECX,80020004 00405900 B8 0A000000 MOV EAX,0A 00405905 898D FCFDFFFF MOV DWORD PTR SS:[EBP-204],ECX 0040590B 898D 0CFEFFFF MOV DWORD PTR SS:[EBP-1F4],ECX 00405911 8D95 B4FDFFFF LEA EDX,[EBP-24C] 00405917 8D8D 14FEFFFF LEA ECX,[EBP-1EC] 0040591D 8985 F4FDFFFF MOV DWORD PTR SS:[EBP-20C],EAX 00405923 8985 04FEFFFF MOV DWORD PTR SS:[EBP-1FC],EAX 00405929 C785 BCFDFFFF 8 MOV DWORD PTR SS:[EBP-244],CrkMeViz-3.00403188 ; UNICODE "Error" 00405933 C785 B4FDFFFF 0 MOV DWORD PTR SS:[EBP-24C],8 0040593D FF15 C8914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarDup>] 00405943 8D85 F4FDFFFF LEA EAX,[EBP-20C] 00405949 8D8D 04FEFFFF LEA ECX,[EBP-1FC] 0040594F 50 PUSH EAX 00405950 8D95 14FEFFFF LEA EDX,[EBP-1EC] 00405956 51 PUSH ECX 00405957 52 PUSH EDX 00405958 8D45 DC LEA EAX,[EBP-24] 0040595B 6A 10 PUSH 10 0040595D 50 PUSH EAX 0040595E FF15 50914000 CALL DWORD PTR DS:[<&MSVBVM50.#595>] ; rtcMsgBox - NOPear para evitar la NAG 00405964 8D8D F4FDFFFF LEA ECX,[EBP-20C]
Antes de llegar al keygen vemos que realiza unas llamadas al registro de Windows, ponemos un breakpoint «bp RegOpenKeyW» y ejecutamos.
CPU Disasm Address Hex dump Command Comments 00405677 |. 8B8D B8FDFFFF MOV ECX,DWORD PTR SS:[EBP-248] 0040567D |. B8 54334000 MOV EAX,CrkMeViz-3.00403354 ; UNICODE "<Unregister>" 00405682 |. 68 B4304000 PUSH CrkMeViz-3.004030B4 ; UNICODE "Serial number" 00405687 |. 894A 04 MOV DWORD PTR DS:[EDX+4],ECX 0040568A |. 8985 BCFDFFFF MOV DWORD PTR SS:[EBP-244],EAX 00405690 |. 68 84304000 PUSH CrkMeViz-3.00403084 ; UNICODE "Register" 00405695 |. 68 58304000 PUSH CrkMeViz-3.00403058 ; UNICODE "CrkMeViz3" 0040569A |. 8942 08 MOV DWORD PTR DS:[EDX+8],EAX 0040569D |. 8B85 C0FDFFFF MOV EAX,DWORD PTR SS:[EBP-240] 004056A3 |. 8942 0C MOV DWORD PTR DS:[EDX+0C],EAX 004056A6 |. FF15 C0914000 CALL DWORD PTR DS:[<&MSVBVM50.#689>] ; rtcGetSetting - Lee el numero de serie del registro ........ 0040574F |. 68 9C304000 PUSH CrkMeViz-3.0040309C ; UNICODE "User Name" 00405754 |. 68 84304000 PUSH CrkMeViz-3.00403084 ; UNICODE "Register" 00405759 |. 68 58304000 PUSH CrkMeViz-3.00403058 ; UNICODE "CrkMeViz3" 0040575E |. 8948 08 MOV DWORD PTR DS:[EAX+8],ECX 00405761 |. 8B8D C0FDFFFF MOV ECX,DWORD PTR SS:[EBP-240] 00405767 |. 8948 0C MOV DWORD PTR DS:[EAX+0C],ECX 0040576A |. FF15 C0914000 CALL DWORD PTR DS:[<&MSVBVM50.#689>] ; rtcGetSetting - Lee el Usuario del registro
Reconstruyendo la llamada al registro vemos que lee de esta ruta: HKEY_CURRENT_USER\Software\VB and VBA Program Settings\CrkMeViz3\Register el contenido de User Name y del Serial number.
Quizá uno de los fallos de éste crackme, es que no comprueba la autenticidad de estos parámetros y si los modificas parece que estás registrado. Un ejemplo:
La rutina de comprobación del serial no es para nada complicada pero recordemos que estamos tratando con VB y éste delega el trabajo duro en otras librerias de modo que tenemos que «meternos» a tracear las llamadas para ver los valores que multiplica y divide.
CPU Disasm Address Hex dump Command Comments 00405A86 FF15 3C914000 CALL DWORD PTR DS:[<&MSVBVM50.#518>] ;MSVBVM50.rtcLowerCaseVar 00405A8C 8D95 14FEFFFF LEA EDX,[EBP-1EC] 00405A92 8D8D ACFEFFFF LEA ECX,[EBP-154] 00405A98 FFD6 CALL ESI 00405A9A 8D95 ACFEFFFF LEA EDX,[EBP-154] 00405AA0 8D8D 4CFEFFFF LEA ECX,[EBP-1B4] 00405AA6 FFD7 CALL EDI 00405AA8 8D95 4CFEFFFF LEA EDX,[EBP-1B4] 00405AAE 8D8D 7CFFFFFF LEA ECX,[EBP-84] 00405AB4 FFD7 CALL EDI 00405AB6 8D85 14FEFFFF LEA EAX,[EBP-1EC] 00405ABC 8D8D 7CFFFFFF LEA ECX,[EBP-84] 00405AC2 50 PUSH EAX 00405AC3 6A 01 PUSH 1 00405AC5 8D95 04FEFFFF LEA EDX,[EBP-1FC] 00405ACB 51 PUSH ECX 00405ACC 52 PUSH EDX 00405ACD C785 1CFEFFFF 0 MOV DWORD PTR SS:[EBP-1E4],1 00405AD7 C785 14FEFFFF 0 MOV DWORD PTR SS:[EBP-1EC],2 00405AE1 FF15 68914000 CALL DWORD PTR DS:[<&MSVBVM50.#632>] ;MSVBVM50.rtcMidCharVar (Esto lo hace 6 veces, lo omito para abreviar.) ........ 00405CE1 FF15 34914000 CALL DWORD PTR DS:[<&MSVBVM50.#516>] ;MSVBVM50.rtcAnsiValueBstr (Lo mismo, otras 6) ........ 00405E7C C785 BCFDFFFF 2 MOV DWORD PTR SS:[EBP-244],52E 00405E86 C785 B4FDFFFF 0 MOV DWORD PTR SS:[EBP-24C],2 00405E90 50 PUSH EAX 00405E91 FF15 84914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>] | ->MSVBVM50.__vbaVarMul ........ 741C19D3 0FB745 FE MOVZX EAX,WORD PTR SS:[EBP-2] ;Valor1 741C19D7 0FB74D F2 MOVZX ECX,WORD PTR SS:[EBP-0E] ;Valor2 741C19DB 6BC0 12 IMUL EAX,EAX,12 ;Valor1*Valor2 ........ 00405E97 8D8D 04FEFFFF LEA ECX,[EBP-1FC] 00405E9D 50 PUSH EAX 00405E9E 51 PUSH ECX 00405E9F FF15 84914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>] 00405EA5 8D95 F4FDFFFF LEA EDX,[EBP-20C] 00405EAB 50 PUSH EAX 00405EAC 52 PUSH EDX 00405EAD FF15 84914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>] 00405EB3 50 PUSH EAX 00405EB4 8D85 E4FDFFFF LEA EAX,[EBP-21C] 00405EBA 50 PUSH EAX 00405EBB FF15 84914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>] 00405EC1 8D8D D4FDFFFF LEA ECX,[EBP-22C] 00405EC7 50 PUSH EAX 00405EC8 51 PUSH ECX 00405EC9 FF15 84914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>] 00405ECF 50 PUSH EAX 00405ED0 8D95 B4FDFFFF LEA EDX,[EBP-24C] 00405ED6 8D85 C4FDFFFF LEA EAX,[EBP-23C] 00405EDC 52 PUSH EDX 00405EDD 50 PUSH EAX 00405EDE FF15 94914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarDiv>] | ->MSVBVM50.__vbaVarDiv ........ 741C8094 DD43 08 FLD QWORD PTR DS:[EBX+8] ;Recupera el resultado de las multiplicaciones anteriores 741C8097 0FBF47 08 MOVSX EAX,WORD PTR DS:[EDI+8] ;EAX = 1326 (52E) 741C809B 8945 F8 MOV DWORD PTR SS:[EBP-8],EAX 741C809E DA75 F8 FIDIV DWORD PTR SS:[EBP-8] ;Divide los dos resultados 741C80A1 DD5E 08 FSTP QWORD PTR DS:[ESI+8] ........ 00405F44 FF15 24914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaLenBstr>] ;Len(nombre) ........ 00405F85 FF15 94914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarDiv>] ;Resultado anterior / Len(nombre) ........
En resumen:
Ejemplo para deurus
64*65*75*72*75*73 = 1A605D70EB8 1A605D70EB8 / 52E = 5179FBF4 5179FBF4 / 6 = D9454A9
Al estar correctamente registrados desaparece el botón de registrar.
El cuarto crackme es prácticamente igual que el tercero salvo que en vez de nag ahora contamos con limitación de ejecuciones. Del mismo modo utiliza el registro de Windows para guardar los datos de registro y las ejecuciones que llevamos.
Ponemos un breakpoint «bp RegOpenKeyW» y llegamos a la conclusión de que la ruta es HKEY_CURRENT_USER\Software\VB and VBA Program Settings\ODBC\Register y los valores se guardan en Counter, User Name y Serial number respectivamente. Este crackme hereda el fallo del anterior y si alteramos los valores el crackme nos muestra como usuarios autorizados, aunque sabemos que no estamos registrados ya que seguimos limitados por ejecuciones. Ni que decir tiene que lo mismo que modificamos el nombre y número de serie, podemos modificar el contador a nuestro favor. Crear un archivo «Reiniciar_contador.reg» con el siguiente contenido sería suficiente.
Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\VB and VBA Program Settings\ODBC] [HKEY_CURRENT_USER\Software\VB and VBA Program Settings\ODBC\Register] "Counter"="0" "User Name"="deurus" "Serial number"="12345"
El keygen es prácticamente igual que en el crackme anterior, solo cambia el divisor.
CPU Disasm
Address Hex dump Command Comments
........
00404BD2 C785 BCFDFFFF C MOV DWORD PTR SS:[EBP-244],6C1
00404BDC C785 B4FDFFFF 0 MOV DWORD PTR SS:[EBP-24C],2
00404BE6 FF15 A0914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>]
|
->MSVBVM50.__vbaVarMul
741C19F9 0FBF4F 08 MOVSX ECX,WORD PTR DS:[EDI+8] ;Valor1
741C19FD 0FBF43 08 MOVSX EAX,WORD PTR DS:[EBX+8] ;Valor2
741C1A01 0FAFC8 IMUL ECX,EAX ;Valor1*Valor2
........
00404BEC 8D8D 04FEFFFF LEA ECX,[EBP-1FC]
00404BF2 50 PUSH EAX
00404BF3 51 PUSH ECX
00404BF4 FF15 A0914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>]
00404BFA 8D95 F4FDFFFF LEA EDX,[EBP-20C]
00404C00 50 PUSH EAX
00404C01 52 PUSH EDX
00404C02 FF15 A0914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>]
00404C08 50 PUSH EAX
00404C09 8D85 E4FDFFFF LEA EAX,[EBP-21C]
00404C0F 50 PUSH EAX
00404C10 FF15 A0914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>]
00404C16 8D8D D4FDFFFF LEA ECX,[EBP-22C]
00404C1C 50 PUSH EAX
00404C1D 51 PUSH ECX
00404C1E FF15 A0914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarMul>]
00404C24 50 PUSH EAX
00404C25 8D95 B4FDFFFF LEA EDX,[EBP-24C]
00404C2B 8D85 C4FDFFFF LEA EAX,[EBP-23C]
00404C31 52 PUSH EDX
00404C32 50 PUSH EAX
00404C33 FF15 B0914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarDiv>]
|
->MSVBVM50.__vbaVarDiv
741C8094 DD43 08 FLD QWORD PTR DS:[EBX+8] ; Recupera el resultado de las multiplicaciones anteriores
741C8097 0FBF47 08 MOVSX EAX,WORD PTR DS:[EDI+8] ; EAX = 1729 (6C1)
741C809B 8945 F8 MOV DWORD PTR SS:[EBP-8],EAX
741C809E DA75 F8 FIDIV DWORD PTR SS:[EBP-8]
00404C39 8BD0 MOV EDX,EAX
........
00404CA0 FF15 3C914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaLenBstr>] ;Len(nombre)
........
00404CF1 FF15 B0914000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVarDiv>] ;Resultado anterior / Len(nombre)
En resumen:
Ejemplo para deurus
64*65*75*72*75*73 = 1A605D70EB8 1A605D70EB8 / 6C1 = 3E7C594A 3E7C594A / 6 = A6A0EE2
Este último crackme está compilado en código nativo y simplemente se trata de una comparación lineal. La única diferencia reside en que no hay botón de registro, la comprobación la gestiona un evento «On Change«, de modo que está comprobando el tamaño del serial que introducimos y cuando éste tiene 8 dígitos llegamos aquí.
........ 0040A64F . C745 9C CDD4DD02 MOV DWORD PTR SS:[EBP-64],2DDD4CD ;2DDD4CD = 48092365 0040A656 . C745 94 03800000 MOV DWORD PTR SS:[EBP-6C],8003 0040A65D . FF15 08C14000 CALL DWORD PTR DS:[<&MSVBVM50.__vbaVa> ;MSVBVM50.__vbaVarTstEq 0040A663 . 66:85C0 TEST AX,AX 0040A666 . 0F84 BA000000 JE CrkMeViZ.0040A726 ;Si salta BAD BOY ........
Luego el serial correcto es 48092365.
¿Ha sido indoloro no?, claro que sí, Visual Basic es un coñazo de tracear pero hay que reconocer que con el tiempo las herramientas han mejorado mucho y nuestra vida es mucho más sencilla. Bueno, pués esto ha sido todo, como siempre os dejo todo el material utilizado y un Keygen.
