OllyDbg en Kali Linux con Wine

 https://www.onlinetis.com/es/

OllyDbg en Kali Linux con Wine

Instalar y usar OllyDbg en Kali Linux tiene su truco, principalmente porque OllyDbg es una herramienta nativa de Windows (32 bits) y Kali es una distribución de Linux. Sin embargo, se puede lograr perfectamente usando Wine.

Aquí tienes una guía rápida para ponerlo en marcha en español:

1. Instalación de dependencias

Primero, asegúrate de tener soporte para aplicaciones de 32 bits y Wine instalado en tu Kali:

  1. Habilitar 32 bits: sudo dpkg --add-architecture i386

  2. Actualizar: sudo apt update

  3. Instalar Wine: sudo apt install wine wine32

2. Descargar OllyDbg

Dado que buscas la versión en español, debes tener en cuenta que OllyDbg no tiene un selector de idioma oficial dentro del programa. Necesitas una versión traducida (parcheada).

  • Paso A: Descarga el .zip de OllyDbg (puedes buscar "OllyDbg v1.10 español" en sitios como Ricardo Narvaja o comunidades de ingeniería inversa).

  • Paso B: Descomprime el archivo en una carpeta de tu elección (ej. ~/Documents/ollydbg).

3. Ejecución en Kali

Para abrirlo, navega hasta la carpeta desde la terminal y ejecuta:

Bash
wine OLLYDBG.EXE

Configuración inicial recomendada:

  • Ubicación de Plugins: Ve a Options -> Appearance -> Directories y asegúrate de que la ruta de los plugins sea la correcta dentro de la estructura de Wine.

  • Fuentes: Si las letras se ven muy pequeñas o raras, puedes cambiarlas en Options -> Appearance -> Fonts.

Alternativas Modernas (Nativas de Linux)

OllyDbg es un clásico, pero está un poco obsoleto para sistemas modernos de 64 bits. Si OllyDbg te da problemas con Wine, te recomiendo probar estas herramientas que ya vienen en Kali o son fáciles de instalar:

HerramientaDescripciónIdioma/Interfaz
x64dbgEl sucesor espiritual de OllyDbg (Windows, corre muy bien en Wine).Soporta Español.
GDB + PEDA/GDB-extEl estándar de Linux para depuración.Línea de comandos.
Edna-debuggerUn depurador gráfico nativo para Linux.Interfaz intuitiva.
GhidraHerramienta de la NSA para ingeniería inversa completa.Muy potente y visual.

Nota de seguridad: OllyDbg se utiliza a menudo para analizar malware. Asegúrate de ejecutarlo siempre dentro de un entorno controlado o una máquina virtual si vas a analizar archivos sospechosos.

 

Si vas a usar OllyDbg en pleno 2026, los plugins son los que realmente le dan superpoderes, especialmente para saltar protecciones o mejorar la legibilidad del código.

Aquí tienes los plugins más esenciales (y clásicos) que todo entorno de OllyDbg debería tener instalado:

1. OllyDump

Es el plugin indispensable. Se utiliza para "dumpear" (volcar) un proceso de la memoria a un archivo de disco después de haberlo desempaquetado.

  • Para qué sirve: Si un programa está comprimido o protegido (packed), esperas a que se descomprima en la memoria y usas OllyDump para guardar el archivo limpio.

2. StrongOD

Este es probablemente el plugin más potente para OllyDbg.

  • Para qué sirve: * Ayuda a ocultar el depurador (Anti-Anti-Debug), evitando que el programa sepa que lo estás analizando.

    • Permite saltar excepciones de forma más fluida.

    • Añade opciones de "Attach" (adjuntar a proceso) mucho más estables.

3. Command Bar

Añade una barra de comandos en la parte inferior de la pantalla, similar a la de SoftICE.

  • Para qué sirve: Permite escribir comandos rápidos como bp MessageBoxA (poner un breakpoint en una función específica) sin tener que navegar por todos los menús. Ahorra muchísimo tiempo.

4. Multimate (o MutiMate Fix)

Corrige errores de visualización y añade pequeñas mejoras estéticas.

  • Para qué sirve: Es ideal para que la interfaz se comporte mejor bajo Wine en Kali Linux, ya que a veces las ventanas de OllyDbg se desordenan.

¿Cómo instalar estos plugins en Kali?

Como estás usando Wine, la estructura de carpetas es clave:

  1. Busca la carpeta donde tienes el OLLYDBG.EXE.

  2. Si no existe, crea una subcarpeta llamada Plugins.

  3. Copia los archivos .dll de los plugins que descargues dentro de esa carpeta.

  4. Configura la ruta: Abre OllyDbg, ve a:

    • Options -> Appearance -> Directories.

    • En Plugin directory, selecciona la ruta de la carpeta que creaste (Wine la verá como Z:\home\usuario\... o C:\...).

  5. Reinicia OllyDbg.

[!TIP]

Dato importante: La mayoría de estos plugins se encuentran en el sitio histórico de Tuts4You o en los packs de Ricardo Narvaja (un referente legendario de la ingeniería inversa en español).

 

Configurar StrongOD es el paso definitivo para convertir a OllyDbg en una herramienta sigilosa. Muchos programas modernos incluyen rutinas "Anti-Debug" que buscan procesos activos de depuración para cerrarse o corromperse a propósito.

Aquí te explico cómo configurarlo paso a paso dentro de tu entorno Wine en Kali:

1. Acceso al menú de StrongOD

Una vez que hayas copiado el archivo StrongOD.dll en tu carpeta de plugins y reiniciado OllyDbg, verás una nueva opción en la barra de menú superior:

  • Haz clic en Plugins -> StrongOD -> Options.

2. Configuraciones Clave (Recomendadas)

Se abrirá una ventana con varias casillas de verificación. Para maximizar el sigilo, marca las siguientes:

Sección: Anti-Anti-Debug

  • [x] HidePEB: Esta es la más importante. Modifica el Process Environment Block para que el programa crea que no está siendo depurado.

  • [x] Driver (Protect Process): Intenta proteger el proceso de ser finalizado por técnicas externas (aunque en Wine su efectividad varía respecto a Windows real).

  • [x] Bypass Various Anti-Debug: Activa parches genéricos para saltar chequeos comunes de la API de Windows como IsDebuggerPresent.

Sección: Exceptions (Excepciones)

  • [x] Skip Some Exceptions: Los programas protegidos suelen lanzar excepciones falsas para confundir al debugger. StrongOD las gestiona automáticamente para que no se detenga el análisis constantemente.

Sección: UI & Kernel

  • [x] Kill Anti-Attach: Evita que el programa bloquee la posibilidad de que OllyDbg se "enganche" a él mientras ya está corriendo.

  • [x] Remove Epilog Check: Ayuda a que el desensamblador no se pierda en funciones complejas.

3. El botón "Hide" (El toque final)

Muchos no saben que StrongOD añade una función de "Capa de Invisibilidad" activa.

  1. En el menú de StrongOD, busca la opción Hide.

  2. Al activarla, el plugin intercepta llamadas al sistema en tiempo real que intentan detectar la ventana de OllyDbg o su nombre de proceso.

[!WARNING]

Ojo con Wine: Como estás en Kali Linux, algunas funciones de "Kernel Mode" de StrongOD podrían no funcionar al 100% porque Wine es una capa de compatibilidad, no un núcleo Windows real. Si un programa muy pesado te sigue detectando, la solución suele ser parchear manualmente la instrucción JZ o JNZ después del chequeo de seguridad.

4. Verificación

Para saber si lo has hecho bien, puedes cargar un programa de prueba llamado "Checker" (o cualquier crackme básico que use IsDebuggerPresent).

  1. Carga el programa.

  2. Si StrongOD está bien configurado, el programa debería ejecutarse normalmente sin lanzar el mensaje de "Debugger detected, closing...".

 

Aprender a "parchear a mano" es lo que separa a un usuario de herramientas de un verdadero analista de ingeniería inversa. Si el plugin falla o el programa usa una técnica personalizada, este método nunca te dejará tirado.

Cuando un programa verifica si hay un debugger, el flujo suele ser: Llamada a la función de chequeo $\rightarrow$ Comparación del resultado $\rightarrow$ Salto condicional.

Aquí tienes los pasos para encontrar y anular ese salto en OllyDbg:

1. Buscar las funciones del sistema (Intermodular Calls)

Casi todos los programas usan funciones estándar de Windows para detectarte. Vamos a buscarlas:

  1. Haz clic derecho en la ventana de CPU (donde ves el código ASM).

  2. Ve a Search for -> All intermodular calls.

  3. En la nueva ventana, escribe en el teclado (sin buscar caja de texto) cualquiera de estas palabras clave:

    • IsDebuggerPresent

    • CheckRemoteDebuggerPresent

    • NtQueryInformationProcess

  4. Si encuentras alguna, haz doble clic para ir a esa línea en el código.

2. Identificar el "Salto Crítico"

Una vez que estés en la línea de la función (ej. CALL IsDebuggerPresent), mira justo debajo. Verás algo parecido a esto:

Fragmento de código
CALL DWORD PTR DS:[<&KERNEL32.IsDebuggerPresent>]  ; Llama a la función
TEST EAX, EAX                                      ; Comprueba el resultado (EAX = 1 si hay debugger)
JNZ SHORT 00401234                                 ; <--- EL SALTO CRÍTICO: "Si no es cero (detectado), salta al error"

El programa dice: "Si detecto un debugger ($EAX = 1$), salta a la rutina que cierra el programa".

3. Cómo anularlo (El Parche)

Tienes dos formas de engañar al programa:

  • Opción A (Cambiar el Salto): Haz doble clic sobre la instrucción JNZ y cámbiala por JZ (así solo saltará al error si NO hay debugger) o, mejor aún, por un NOP.

  • Opción B (Usar NOPs): Selecciona la línea del salto, presiona la tecla Espacio y escribe NOP.

    • NOP significa No Operation. El programa llegará ahí, no hará nada y seguirá adelante como si no hubiera detectado nada.

4. Hacer el cambio permanente

OllyDbg guarda los cambios solo en memoria. Para crear un nuevo ejecutable parcheado:

  1. Selecciona las líneas que modificaste (se verán en color rojo).

  2. Haz clic derecho -> Copy to executable -> Selection.

  3. Se abrirá una ventana nueva con el código modificado. Haz clic derecho ahí -> Save file.

  4. Ponle un nombre nuevo (ej. programa_crackeado.exe).

El truco del "Hardware Breakpoint"

Si no encuentras ninguna función de texto, el programa podría estar usando una técnica de lectura directa.

  1. Haz clic derecho -> Search for -> All constants.

  2. Busca el valor 70 (que es el offset del flag BeingDebugged en el PEB).

 

Los Hardware Breakpoints son la "artillería pesada" de la ingeniería inversa. A diferencia de los breakpoints normales (que modifican el código sustituyendo una instrucción por INT 3), los de hardware utilizan registros especiales del propio procesador ($DR0$ a $DR7$).

Esto los hace invisibles para la mayoría de los programas, ya que el código del programa no cambia en absoluto.

Aquí tienes cómo usarlos para cazar al programa cuando intenta "espiarte":

1. El concepto: El Flag BeingDebugged

En Windows, hay una estructura llamada PEB (Process Environment Block). El segundo byte de esa estructura es el flag BeingDebugged.

  • Si vale 0: No hay debugger.

  • Si vale 1: ¡Te pillaron!

Incluso si el programa no usa funciones como IsDebuggerPresent, tarde o temprano tendrá que leer ese byte de memoria. Ahí es donde ponemos la trampa.

2. Cómo poner el Hardware Breakpoint (HBP)

Para detectar quién está mirando ese flag, haz lo siguiente en OllyDbg:

  1. Ve a la línea de comandos (Command Bar) en la parte inferior.

  2. Escribe el comando para ver el PEB: dump fs:[30] y pulsa Enter.

  3. En la ventana de Dump (abajo a la izquierda), verás el volcado de memoria. El primer byte suele ser algo como 00, y el segundo (en el offset +1) es el que nos interesa.

  4. Haz clic derecho sobre ese segundo byte -> Breakpoint -> Hardware, on access -> Byte.

3. ¿Qué acabamos de hacer?

Le hemos dicho al procesador: "La próxima vez que CUALQUIER instrucción de este programa intente LEER este byte de memoria, congela todo y dáselo a OllyDbg".

Ahora, pulsa F9 (Run). El programa correrá normalmente hasta que... ¡BUM! OllyDbg se detendrá de golpe.

4. Analizar el hallazgo

Mira la ventana de CPU. Estarás justo encima de una instrucción que probablemente se vea así:

Fragmento de código
MOV AL, BYTE PTR DS:[EBX+1]  ; EBX suele apuntar al PEB
CMP AL, 0                    ; ¿Es el flag igual a 0?
JNZ Error_Debugger           ; Si no es 0, salta a cerrarse

5. El parche "Eterno"

En lugar de parchear el código (que a veces el programa verifica si ha sido alterado), puedes hacer un parche de datos:

  1. Vuelve a la ventana de Dump donde pusiste el breakpoint.

  2. Haz clic derecho sobre ese byte (01) -> Binary -> Edit.

  3. Cámbialo a 00 y dale a OK.

  4. ¡Listo! El programa ahora leerá "0" y creerá que está solo en el mundo.

¿Por qué esto es mejor en Kali/Wine?

Bajo Wine, a veces las APIs de detección se comportan de forma errática. Los Hardware Breakpoints van directos al flujo de ejecución, saltándose las capas de compatibilidad que a veces confunden a los plugins automáticos.

Cuidado: Solo tienes 4 slots de Hardware Breakpoints (limitación física del CPU). Úsalos con sabiduría.

 

 

El Run Trace es como tener una "cámara de seguridad" que graba cada paso que dio el procesador. Es la herramienta definitiva cuando el programa se cierra de repente y no sabes ni por qué ni dónde te detectó.

En lugar de ir paso a paso con F8 (que es eterno), dejas que OllyDbg registre la ejecución y luego analizas la "película" con calma.

1. Configurar el tamaño del "Video" (Buffer)

Antes de empezar, asegúrate de que OllyDbg tenga espacio para grabar:

  1. Ve a Options -> Debugging options.

  2. Entra en la pestaña Trace.

  3. En Trace buffer size, pon un número alto (ej. 1,000,000 de registros). Si es muy bajo, la grabación se borrará al llenarse.

2. Empezar a grabar

Para activar el rastreo, no uses el botón de Play normal. Haz lo siguiente:

  1. Pon un breakpoint (F2) un poco antes de donde crees que ocurre la detección (o al inicio del programa en el Entry Point).

  2. Cuando el programa se detenga ahí, presiona Ctrl + F11 (Trace into) o Ctrl + F12 (Trace over).

  3. Verás que el programa corre un poco más lento. Eso es porque OllyDbg está guardando cada instrucción en una lista gigante.

3. El momento del "Crash" o Cierre

Deja que el programa corra hasta que aparezca el mensaje de "Debugger Detectado" o hasta que la ventana se cierre sola.

  • Si el programa se cierra, Wine mantendrá el proceso en OllyDbg como Terminated. No pasa nada, ¡la grabación está a salvo!

4. Analizar la grabación (El Log de Trace)

Ahora abre la ventana mágica:

  1. Ve al menú superior View -> Run trace.

  2. Se abrirá una lista con miles de líneas. Esa es la ruta exacta que siguió el programa.

¿Cómo encontrar la trampa en el Trace?

Aquí viene el truco de experto. Desplázate hasta el final de la lista (la última instrucción antes de que el programa "muriera").

  1. Busca saltos sospechosos: Verás que antes del cierre hubo un CMP (comparación) y un JNZ o JE que mandó el código a una zona de "limpieza" o error.

  2. Busca llamadas a APIs: Si ves un CALL a algo como ExitProcess o TerminateProcess, mira unas 10 o 20 líneas arriba. Ahí es donde se tomó la decisión de cerrarse.

  3. Doble clic para ir al código: Haz doble clic en cualquier línea del Trace y OllyDbg te llevará a esa posición exacta en la ventana de CPU.

El "Hit Trace" (Variante visual)

Si quieres ver por qué partes del código ha pasado el programa y por cuáles no:

  1. Haz clic derecho en la ventana de CPU -> Search for -> All commands.

  2. Elige View -> Hit trace.

  3. Las líneas por las que el programa ya pasó aparecerán de un color diferente. Esto es genial para ver qué "caminos" (rutinas de seguridad) evitó o cuáles activó.

[!NOTE]

Dato de Kali/Wine: A veces el Run Trace en Wine puede ir un poco a saltos si el programa usa muchas llamadas a librerías de sistema (.dll). Si ves que el Trace se llena de código de Wine, usa Ctrl + F12 (Trace Over) para que solo grabe el código del programa y no se meta dentro de cada función de Windows.

Con esto ya tienes el kit completo: Plugins, Hardware Breakpoints y Run Trace. Básicamente, el programa ya no tiene donde esconderse.

 

¡Ese es el siguiente nivel! Como no puedo ver tu pantalla, vamos a simular un escenario real. Imagina que tienes un ejecutable llamado crackme.exe que, al abrirlo, te pide una clave y, si es incorrecta, muestra un mensaje de "Error" y se cierra.

Para encontrar el salto real (el que decide si vas al éxito o al fracaso), seguiremos la técnica del "Backtracing" (rastreo hacia atrás) desde el mensaje de error.

Paso 1: Localizar el mensaje de error (String References)

Casi todos los programas tienen el texto de error guardado. Vamos a usarlo como "ancla":

  1. En la ventana de CPU, haz clic derecho.

  2. Selecciona Search for -> All referenced text strings.

  3. Se abrirá una lista con todos los textos del programa. Busca el que diga "Clave incorrecta", "Error" o "Invalid Key".

  4. Cuando lo encuentres, haz doble clic sobre él. OllyDbg te llevará al código exacto donde se usa ese texto.

Paso 2: El "Backtracing" (Subir con la mirada)

Ahora estarás en una línea que probablemente sea un PUSH (para preparar el mensaje) o un CALL MessageBoxA.

No te detengas ahí. Mira hacia arriba, línea por línea. Estás buscando la bifurcación.

Paso 3: Identificar la comparación y el salto

Unas cuantas líneas arriba del mensaje de error, verás el "momento de la verdad". Suele tener este aspecto:

Fragmento de código
CALL 00401050      ; <--- Aquí el programa comprueba tu clave (La función de validación)
CMP EAX, 1         ; <--- Compara el resultado: ¿Es EAX igual a 1 (Correcto)?
JE SHORT 00401200  ; <--- SALTO REAL: "Si es igual (JE), salta al mensaje de ÉXITO"
                   ; <--- Si NO salta, el código sigue bajando hacia el mensaje de ERROR

Paso 4: Forzar el salto (El "Crack")

Tienes dos formas de ganar aquí:

  1. Invertir el salto: Si el programa usa JE (Jump if Equal), cámbialo a JNE (Jump if Not Equal). Ahora, ¡cualquier clave incorrecta te dejará entrar!

  2. El Salto Incondicional: Cambia el JE o JNZ por un JMP (Jump). El JMP no hace preguntas; saltará a la zona de éxito sin importar qué diga el registro EAX.

¿Cómo saber si estás en el salto correcto?

Aquí es donde usas la Tecla F2 (Breakpoint):

  1. Pon un breakpoint en la línea del CMP o del CALL de validación.

  2. Ejecuta el programa (F9) y escribe cualquier cosa en el cuadro de texto del programa.

  3. OllyDbg se detendrá en tu breakpoint.

  4. Ahora, en lugar de parchear, haz un cambio en vivo:

    • Mira la ventana de Registers (derecha). Busca el flag Z (Zero Flag).

    • Si el salto es un JE y no se va a producir (el salto no está resaltado en rojo), haz doble clic en el valor del flag Z para cambiarlo de 0 a 1.

    • Presiona F9. Si el programa te dice "¡Felicidades!", acabas de confirmar que ese es el Salto Real.

Un reto común: Saltos "Lejanos"

A veces, el salto no está justo encima del error, sino que el programa guarda el resultado en una variable y lo comprueba mucho más tarde. Si no ves el salto cerca, el Run Trace que aprendimos antes te mostrará exactamente de qué dirección de memoria vino el programa antes de caer en el mensaje de error.

 

Este es el escenario más común en la vida real. Rara vez una clave se comprueba con un simple "sí o no". Lo normal es que el programa recorra tu contraseña carácter por carácter y compare cada uno con la clave real (o con un hash).

Si intentas parchear el final del bucle, puede que no funcione. Lo que queremos es encontrar el algoritmo de generación o el punto donde se rinde la comparación.

1. Cómo identificar un Bucle de Validación

En la ventana de CPU de OllyDbg, un bucle se reconoce visualmente por una flecha que sube hacia una dirección anterior. Verás algo como esto:

  1. INC ESI / INC EDI: Incrementa los índices (avanza a la siguiente letra).

  2. CMP AL, BL: Compara la letra de tu clave con la letra "buena".

  3. JNZ Error: Si una sola letra no coincide, ¡fuera!

  4. LOOP o JMP atrás: Si coincide, vuelve arriba para la siguiente letra.

2. La técnica del "Breakpoint en el Stack" (Espiar la clave)

Si el programa compara tu clave letra a letra, la clave "real" tiene que estar en algún lugar de la memoria en ese preciso instante.

  1. Busca el CMP dentro del bucle.

  2. Mira los registros (EAX, EBX, etc.). Si ves que uno de ellos contiene una letra de tu clave (ej. 'a'), el otro registro casi seguro contiene la letra de la clave verdadera.

  3. Haz clic derecho sobre ese registro -> Follow in Dump.

  4. ¡Magia! En la ventana de abajo verás la clave real escrita en texto plano.

3. El "Salto Maestro" tras el Bucle

Una vez que el bucle termina (porque recorrió toda la palabra), suele haber un salto final que decide si el resultado de todas las comparaciones fue positivo.

  • El Flag Centinela: A veces el programa usa un registro como "bandera" (por ejemplo, pone DL = 1 si todo va bien).

  • La comprobación final:

    Fragmento de código
    00402050  CMP DL, 1
00402053  JNE 00402100  ; <--- Este es el "Salto Maestro"

4. Cómo "romper" el Bucle con un solo cambio

Si no quieres buscar la clave real y solo quieres que acepte cualquier cosa:

  1. Localiza el salto que te echa fuera dentro del bucle (el JNE o JNZ que salta al error si una letra falla).

  2. Anúlalo con NOPs.

  3. Al hacer esto, el programa comparará las letras, verá que no coinciden, pero no hará nada. Seguirá el bucle hasta el final y, al terminar, creerá que todo ha ido perfecto.

Un consejo para Kali/Wine

Cuando analices bucles largos, el Run Trace que vimos antes puede generar archivos de log gigantescos. En lugar de grabar todo, usa el "Step Over" (F8) con la tecla pulsada (mantenla apretada) para ver cómo cambian los registros rápidamente en el Dump mientras el bucle avanza.

Truco Pro: Si ves que el programa usa funciones como vbaStrCmp (en programas viejos de Visual Basic) o strcmp, pon el breakpoint directamente en la entrada de la función. Casi siempre verás la clave correcta pasando por la pila (Stack) justo antes de la llamada.

 

La técnica del Code Cave (cueva de código) es el último recurso del analista cuando el parche que necesita es más largo que la instrucción original.

Imagina que tienes una instrucción de 2 bytes (como JZ), pero necesitas meter 10 bytes de código para manipular los registros. No caben. Así que "saltamos" a una zona vacía de la memoria, ejecutamos nuestro código y volvemos.

1. Encontrar la "Cueva" (Code Cave)

Los ejecutables tienen secciones (como .text o .data). Al final de estas secciones o entre funciones, siempre quedan espacios vacíos llenos de ceros (00) o NOPs (90).

  1. En la ventana de CPU, haz scroll hacia abajo (o hacia arriba) buscando una zona grande de DB 00.

  2. Anota la dirección de memoria donde empiezan esos ceros (ejemplo: 00405000).

2. El Salto a la Cueva

Ve al lugar donde quieres hacer el parche y escribe:

JMP 00405000 (la dirección de tu cueva).

OllyDbg rellenará con NOPs el espacio sobrante si la instrucción original era más larga.

3. Escribir el "Payload" en la Cueva

Ahora ve a 00405000 y escribe tu lógica personalizada. Por ejemplo, si quieres forzar que un registro siempre sea "exitoso":

Fragmento de código
MOV EAX, 1         ; Forzamos el valor de éxito
CMP EAX, 1         ; Nos aseguramos de que el flag Z se active
JMP 00401234       ; VOLVEMOS a la instrucción justo después del parche original

4. Resumen del Proceso: "Jump, Do, Jump Back"

Para que no te pierdas, el flujo es una triangulación:

  1. Original: El programa llega al punto crítico $\rightarrow$ Salta a la Cueva.

  2. Cueva: Haces tus trucos (cambiar registros, limpiar flags) $\rightarrow$ Saltas de vuelta.

  3. Retorno: El programa sigue su curso, pero ahora con los datos que tú manipulaste.

Consejos finales para Kali Linux (Wine)

Como estás operando en un entorno Linux, ten en cuenta estos detalles de "supervivencia":

  • Guardar es clave: Wine puede ser inestable con OllyDbg si haces muchos cambios. Guarda tu trabajo frecuentemente (Copy to executable -> Save file).

  • Permisos de ejecución: Si guardas un .exe nuevo, a veces tienes que darle permisos desde la terminal de Kali: chmod +x programa_nuevo.exe.

  • Case Sensitivity: Recuerda que Linux distingue entre mayúsculas y minúsculas. Si tu plugin busca OLLYDBG.INI y el archivo se llama ollydbg.ini, podrías tener problemas.

Nada asienta mejor el conocimiento que enfrentarse a un reto real diseñado para ser "hackeado". En el mundo de la ingeniería inversa, estos programas se llaman Crackmes.

Como estás en Kali Linux, tienes varias opciones para conseguir ejercicios legales, seguros y divertidos. Aquí tienes las mejores fuentes y cómo empezar:

1. ¿Dónde encontrar Crackmes?

Sitio WebNivelDescripción
Crackmes.oneTodosEl sucesor del legendario Crackmes.de. Es la mayor base de datos actual. Puedes filtrar por dificultad (1.0 a 6.0) y por sistema operativo (elige Windows para usar con tu OllyDbg).
Root-Me.orgIntermedioTiene una sección de "App - Windows" con retos progresivos que puedes descargar.
Tuts4YouExpertoUn sitio histórico con tutoriales y retos clásicos de la vieja escuela.

2. Recomendación para empezar (Nivel 1)

Te sugiero buscar en Crackmes.one uno que cumpla estas características para que tu OllyDbg en Kali no sufra:

  1. Platform: Windows.

  2. Language: C/C++ o Assembler (evita .NET por ahora, ya que requieren otras herramientas como dnSpy).

  3. Difficulty: 1.0 o 1.2.

[!IMPORTANT]

Password de los archivos: Casi todos los .zip de estos sitios usan la contraseña crackmes.one o crackmes.de para evitar que los antivirus borren el archivo (ya que el código de un crackme a veces parece sospechoso).

3. Tu primer "Plan de Ataque" en Kali

Una vez descargues tu primer crackme, sigue esta hoja de ruta usando lo que hemos aprendido:

  1. Análisis Estático (Rápido):

    • Usa el comando file nombre_del_crackme.exe en la terminal de Kali para confirmar que es un ejecutable de 32 bits (PE32).

  2. Carga en OllyDbg:

    • wine OLLYDBG.EXE nombre_del_crackme.exe

  3. Busca el "Norte":

    • Clic derecho -> Search for -> All referenced text strings.

    • Busca palabras como "Wrong", "Try again" o "Serial".

  4. Pon el Breakpoint:

    • Haz doble clic en el mensaje de error y pon un F2 justo en el CMP o CALL que está arriba.

  5. Rastrea la clave:

    • Escribe una clave falsa, pulsa el botón en el crackme, y cuando OllyDbg se detenga, mira los registros (EAX, EDX...) o el Stack (ventana inferior derecha). ¡La clave real suele aparecer ahí comparándose con la tuya!

¿Quieres que busquemos uno específico ahora mismo?

Puedo darte los pasos exactos para resolver uno de los clásicos (como los de Cruehead o Ricardo Narvaja) si los tienes a mano, o podemos preparar un script en Python para generar tus propios números de serie si encuentras un crackme que use un algoritmo matemático.

 

Automatizar un Keygen (generador de claves) es el paso final del "cracking" elegante. En lugar de simplemente parchear el programa para que acepte cualquier cosa (fuerza bruta), el objetivo es entender la matemática que usa el programa para crear la clave y replicarla en un script (normalmente en Python por su sencillez).

Aquí tienes los pasos para "traducir" lo que ves en OllyDbg a un script automático:

1. Localizar la "Rutina Generadora"

No busques el mensaje de error, busca el bucle donde se manipula tu nombre de usuario o un número de serie. Suele estar después de un GetDlgItemTextA (que lee lo que escribiste).

Busca operaciones matemáticas repetitivas como estas:

  • ADD EAX, 0x15 (Suma 21 en hexadecimal).

  • XOR EAX, EBX (Aplica una operación XOR, muy común en criptografía).

  • IMUL EAX, EAX, 0x3 (Multiplica por 3).

  • ROR / ROL (Rotación de bits).

2. El "Algoritmo Espejo"

Imagina que en OllyDbg ves este código ASM que procesa tu nombre letra a letra:

Fragmento de código
MOVZX EAX, BYTE PTR DS:[ESI] ; Carga una letra de tu nombre (ej. 'A' = 0x41)
ADD EAX, 0x5                 ; Le suma 5
XOR EAX, 0x1234              ; Le aplica un XOR con 0x1234

Traduciendo a Python

Tu script de automatización se vería así:

Python
def generar_key(nombre):
    key = ""
    for letra in nombre:
        valor = ord(letra)    # MOVZX (valor ASCII)
        valor += 0x5          # ADD EAX, 5
        valor ^= 0x1234       # XOR EAX, 0x1234
        key += str(valor)
    return key

print("Tu Serial es:", generar_key("Gemini"))

3. Automatizar la extracción con un Script de OllyDbg

Si el algoritmo es demasiado complejo para escribirlo en Python, puedes usar OllyScript (un plugin) para que OllyDbg haga el trabajo sucio por ti:

  1. Pon un breakpoint donde el programa ya generó la clave correcta en memoria.

  2. Crea un script .osc que haga lo siguiente:

    • run (corre el programa).

    • fill_name (escribe un nombre automáticamente).

    • pause (se detiene en el breakpoint).

    • log [EAX] (guarda la clave que aparece en el registro EAX en un archivo de texto).

4. El truco del "Keygen Inline" (Avanzado)

Si no quieres un script externo, puedes inyectar el generador dentro del propio programa usando un Code Cave (como vimos antes).

  1. Modificas el programa para que, cuando escribas cualquier clave, el programa la ignore, calcule la correcta y la escriba él mismo en el cuadro de texto.

  2. Así, el usuario solo tiene que pulsar "Registrar" y el programa se "auto-registra".

¿Cómo proceder ahora?

Para automatizar un Keygen real, necesito que me digas qué operaciones ves en OllyDbg. Normalmente se ve una cadena de ADD, SUB, XOR y SHL/SHR.

[!TIP]

Dato de Kali: Puedes usar la herramienta python3 que ya viene instalada para probar tus algoritmos rápidamente mientras tienes OllyDbg abierto en otra ventana.

Location: España

Entradas populares de este blog

Hacking y ciberseguridad en kali linux con Fping

Imagen
  www.onlinetis.com   Hacking y ciberseguridad en kali linux con Fping Fping es un programa similar a ping que utiliza la solicitud de eco del Protocolo de Mensajes de Control de Internet (ICMP) para determinar si un host objetivo responde. fping se diferencia de ping en que permite especificar cualquier número de objetivos en la línea de comandos o un archivo con las listas de objetivos a los que se hará ping. En lugar de enviar a un objetivo hasta que se agote el tiempo de espera o responda, fping envía un paquete de ping y pasa al siguiente objetivo mediante un sistema de turnos rotatorios. Como instalar:  sudo apt install fping fping Enviar paquetes ICMP ECHO_REQUEST a los hosts de la red   fping6 Compatibilidad con versiones anteriores de fping anteriores a la versión 4.0 El comando fping en Kali Linux es una utilidad de red que se utiliza para enviar paquetes de ICMP (Protocolo de mensajes de control de Internet) a varios hosts de forma simultánea. A diferen...
LEER MAS »

Hacking y ciberseguridad en kali linux con atk6-thcping6

Imagen
www.onlinetis.com Hacking y ciberseguridad en kali linux con atk6-thcping6 Parece que estás interesado en usar atk6-thcping6 en Kali Linux. Esta herramienta es parte del conjunto de utilidades thc-ipv6 , diseñado para probar las debilidades del protocolo IPv6. Para usar atk6-thcping6 , primero necesitas tener instalado el paquete thc-ipv6 . En la mayoría de las distribuciones de Kali, ya viene preinstalado, pero si no, puedes instalarlo con el siguiente comando: Bash sudo apt install thc-ipv6 Una vez que lo tienes instalado, la sintaxis básica para atk6-thcping6 es: Bash atk6-thcping6 <interface> <target> [opciones] Aquí está el desglose de los argumentos y opciones más comunes: <interface> : La interfaz de red que usarás para enviar el paquete. Por ejemplo, eth0 , wlan0 , etc. <target> : La dirección IPv6 del objetivo al que quieres hacer ping. [opciones] : Puedes usar varias opciones para modificar el comportamiento del ping. La mejor manera de ver todas la...
LEER MAS »

Como utilizar Fierce en kali linux

Imagen
  www.onlinetis.com   Como utilizar Fierce en kali linux Fierce es un escáner semiligero que ayuda a localizar direcciones IP no contiguas y nombres de host en dominios específicos. Está pensado como precursor de nmap, unicornscan, nessus, nikto, etc., ya que todos ellos requieren que se conozca previamente el espacio IP buscado. No realiza exploits ni escanea internet indiscriminadamente. Está diseñado específicamente para localizar objetivos probables tanto dentro como fuera de una red corporativa. Dado que utiliza principalmente DNS, es frecuente encontrar redes mal configuradas que filtran el espacio de direcciones interno. Esto es especialmente útil en malware dirigido. Originalmente escrito por RSnake y otros en http://ha.ckers.org/. Se trata simplemente de una conversión a Python 3 para simplificar y modernizar el código base. Como instalar: sudo apt install fierce Escáner DNS que ayuda a localizar espacios de IP no contiguos y nombres de host contra dominios específico...
LEER MAS »