Un modelo abierto que no rechaza la ingeniería inversa legítima, el harness dsh en local y REA conectando Ghidra. Le indicas una app y pides tu propia versión.
Esta es una guía para recrear un programa de computadora a tu manera usando tres piezas abiertas: un harness de agente local (el dsh, agente de código de DeepSeek), un modelo abierto «sin trabas» que se ejecuta en Ollama y REA, que le da al agente herramientas de ingeniería inversa como Ghidra. Sirve para quienes programan o estudian y quieren entender cómo funciona una app y hacer su propia versión, sin depender de modelos en la nube que a veces rechazan la solicitud. Todo se ejecuta en tu máquina: necesitas Docker, Ollama, Node 22 y memoria para un modelo de 14 a 24 GB. Espera llegar a alrededor del 80 % de la app, no a los últimos detalles.
El modelo es el cerebro, el harness es el cuerpo con las herramientas y REA son los ojos que ven dentro de la app compilada.
El banco de trabajo donde vive el agente: lee y escribe archivos, ejecuta comandos y llama a herramientas MCP. Aquí se ejecuta en un contenedor, solo en la dirección local, y permite cambiar el modelo.
Una versión «abliterated» de un modelo abierto: le quitaron el reflejo de rechazar. Se ejecuta en Ollama en tu máquina, sin clave de API y sin enviar nada afuera.
REA (Reverse Engineer Anything) es un servidor MCP y una línea de comandos que proporcionan al agente el análisis de la app: módulos, funciones, conexiones, con evidencia y límites.
El agente no necesita ser genial: REA ya organiza las herramientas y el modelo solo ejecuta. Por eso un modelo abierto de tamaño medio puede con buena parte del trabajo.
El reproductor de video de Mac (QuickTime) solo ofrece unas pocas velocidades fijas. El agente estudió la app y creó una nueva, con otro nombre ("Tempo") y otro ícono, con velocidad granular, ondas de audio y ajuste de tono. Unos 80% salieron en un solo pedido; el resto fue fuente, visual y exportación.
Solo lo que existe realmente en la página de Ollama al 12/10/2026 (pestaña "tags" de cada modelo). No se descargó ni midió ninguno en esta máquina: el disco estaba al 98%. Elige según el tamaño que quepa en tu memoria.
| Modelo (comando exacto) | Tamaño | Recursos en la página | Observación |
|---|---|---|---|
ollama pull huihui_ai/Qwen3.8-abliterated:27b | 18 GB (q4_K_M) | tools · thinking · vision | La misma base que qwen3.8:27b, que ya funciona en dsh aquí. Primera opción. no medido |
ollama pull huihui_ai/Qwen3.6-abliterated:35b-a3b | 24 GB | tools · thinking · vision | MoE (3B activos por token): suele ser rápido. no medido |
ollama pull huihui_ai/glm-4.7-flash-abliterated | 19 GB | tools · thinking | Familia GLM, la misma del ejemplo del video (allí se usó una versión más grande, en la nube). no medido |
ollama pull huihui_ai/gpt-oss-abliterated:20b | 14 GB | tools · thinking | El más pequeño de la lista con herramientas. Bueno para una máquina con 32 GB. no medido |
ollama pull huihui_ai/qwen3-coder-abliterated:30b | 19 GB | sin etiqueta "tools" en la página | Enfocado en código, pero verifica la etiqueta tools: sin llamada a herramientas, el agente no usa REA. no medido |
./dsh remoto) que alojan modelos sin restricciones, con crédito de US$ 5 a 10. Así, el código de la app sale de tu máquina, y en el modo remoto dsh no monta ~/projetos a propósito.Probado como referencia en una máquina Linux ARM (DGX GB10, 128 GB de memoria unificada). En otra máquina, los comandos son los mismos; cambia el tamaño de los modelos que caben.
dsh (@deepseek-ai/dsh 0.1.1-rc.1) en un contenedor node:22-slim, límite de 3 GB, usuario sin permisos de root, solo en 127.0.0.1:9080.
cd ~/projetos/dsh-sandbox ./dsh status # modo, container, http, provedores
Puerto 11434, contexto de 32K y caché KV q8_0 en el servicio. Comprueba qué hay ya y el espacio en disco antes de descargar un modelo.
ollama list df -h / # o modelo pede 14 a 24 GB livres
REA requiere Node 22.19+, 24.11+ o 26+. El contenedor de dsh ya incluye el 22.23.
docker run --rm node:22-slim node -v # v22.23.x
Para apps compiladas (C, C++, Swift, Rust). En Linux ARM64, puede que haya que compilar el descompilador nativo por separado. Esta máquina solo tiene JDK 8, así que este camino está no medido. Las apps Electron/JavaScript no necesitan Ghidra.
java -version # precisa ser 21 ou mais novo
Los prompts completos para copiar y pegar están en la carpeta prompts/ del repositorio (en portugués).
El modo local monta ~/projetos en /projetos y deja solo Ollama como proveedor: nada sale de la máquina. Abre el panel y elige el workspace.
cd ~/projetos/dsh-sandbox ./dsh local # ~20 s; después abre http://127.0.0.1:9080 ./dsh status # debe mostrar: modo local, /projetos montado SÍ, proveedores: ollama # desde otra máquina: ssh -L 9080:127.0.0.1:9080 usuario@servidor
Descarga uno de la tabla de arriba. Después añade el modelo en settings.local.yaml (no en work/.dsh/settings.yaml, que se sobrescribe cada vez que cambias de modo), dentro de llm-pi-ai → providers → ollama → models. El id debe coincidir letra por letra con ollama list.
ollama pull huihui_ai/Qwen3.8-abliterated:27b ollama list | grep abliterated
# settings.local.yaml — añade a la lista models del proveedor ollama - id: huihui_ai/Qwen3.8-abliterated:27b name: Qwen3.8 27B sin restricciones contextWindow: 32768 maxTokens: 8192 reasoningEfforts: off: none # "none" explícito: vacío deja el razonamiento ACTIVADO en Ollama low: low high: high max: high
./dsh local # copia settings.local.yaml al contenedor (sin rebuild)
El nuevo modelo aparece en el selector del panel. El bloque compat del proveedor (supportsDeveloperRole: false, maxTokensField: max_tokens) ya está en el archivo y es obligatorio para Ollama.
Ruta A — app Electron/JavaScript, sin Ghidra. El agente ejecuta REA desde la línea de comandos dentro del propio contenedor. Este fue el camino medido aquí: REA 6.3.0 analizó una app Node de 97 archivos en 20 s; REA 6.4.0 analizó una app Electron de 202 archivos JS en 94,5 s (pico de 1,26 GB). Pon el objetivo en una carpeta visible para el contenedor (~/projetos/dsh-sandbox/work/alvos se convierte en /work/alvos) y pega el prompt:
Instala esto y ayúdame a hacer ingeniería inversa de una app: https://github.com/morluto/rea
Usa npx -y rea-agents@6.4.0, siempre con "timeout -k 10 600" delante.
Analiza /work/alvos/<app>.asar con analyze-javascript-application --json,
resume los módulos, las pantallas y dónde está <la función que me interesa>, con la evidencia.
Ruta B — REA como MCP dentro de dsh (no medido). El registro automático rea setup --client dsh todavía no está en el paquete publicado (la doc de REA dice "solo en main, después de la 6.4.0"). La forma manual: instalar REA en una carpeta propia dentro de work/ (sin tocar el node_modules congelado de dsh) y registrar el servidor en el cordis.patch.yml de la casa de dsh.
cd ~/projetos/dsh-sandbox docker run --rm -u 1000:1000 -v "$PWD/work:/work" -w /work \ -e HOME=/work -e NPM_CONFIG_CACHE=/work/.npm --memory=6g \ node:22-slim npm install --prefix /work/rea rea-agents@6.4.0
# ~/projetos/dsh-sandbox/work/.dsh/cordis.patch.yml (en el contenedor: /work/.dsh/cordis.patch.yml) - insert: - id: rea-mcp name: "@deepseek-ai/dsh-mcp-client" config: serverName: rea transport: stdio command: /usr/local/bin/node args: ["/work/rea/node_modules/rea-agents/scripts/rea.mjs", mcp] toolCallTimeoutMs: 600000 # el valor predeterminado es 60 s; un análisis tarda más
Reinicia con ./dsh local; las herramientas aparecen como mcp__rea__…. Para binarios nativos, REA necesita Ghidra 12.1.x y JDK 21 visibles desde dentro del contenedor (GHIDRA_INSTALL_DIR, JAVA_HOME) y más memoria que los 3 GB del contenedor. Eso no se configuró ni se midió aquí.
Empieza por una app pequeña, que uses y de la que eches en falta una sola cosa. Pide una app nueva, con nombre e ícono propios, escrita desde cero y que enumere al final lo que quedó fuera.
A partir del análisis, crea una app NUEVA, con nombre e ícono propios (sin nombre, ícono,
textos ni código del fabricante), que haga lo que hace <app original> en <función principal>
y añada: velocidad de reproducción de 0,1x a 4x, en pasos de 0,05.
Código desde cero en /work/minha-versao. Primero la versión mínima que funcione;
al final, enumera lo que quedó fuera y lo que necesita pruebas manuales.
La primera versión suele funcionar en lo esencial. Lo demás son ajustes: apariencia, exportación, pequeños errores. Un pedido a la vez, probando entre ellos.
Abrí la versión 1. Lo que no funcionó: <lo que viste, con el mensaje de error>.
Corrige solo eso, vuelve a ejecutarlo y dime cómo confirmar que quedó bien.
Detente. Resume en 5 líneas lo que ya intentaste, qué dio error y cuál es la hipótesis. No ejecutes nada más hasta que te responda. # cuando el agente se atasca
Marca cada elemento. Si alguno falla, ve a "Problemas".
./dsh status muestra el modo local, http 200 y /projetos montado.ollama list muestra el modelo sin restricciones con el mismo nombre que el id en el YAML.ls /work (prueba de que llama a herramientas).npx -y rea-agents@6.4.0 --help se ejecuta desde dentro del agente.Los casos que ya aparecieron en esta máquina o que describe la documentación de REA y dsh.
REA 6.3.0 se bloqueó en una app con un único archivo JS enorme e ignoró SIGTERM: hubo que matar el proceso huérfano por el PID. En 6.4.0, la misma app terminó. Aun así, ejecútalo siempre con un límite:
# en el host (systemd-run + timeout) o en el contenedor (timeout): scripts/rea-com-timeout.sh -t 600 -m 6G -- \ npx -y rea-agents@6.4.0 analyze-javascript-application /abs/app.asar --json
Señales: inventa nombres de herramientas, repite el mismo comando, olvida el objetivo. Cambia por uno más grande de la tabla, divide la solicitud en partes más pequeñas y pide al agente que guarde el resumen del análisis en un archivo para volver a leerlo después. El contexto de 32K se llena rápido con JSON grande: pide un resumen, no todo el JSON.
REA acepta Ghidra 12.1.x con JDK 21+ (64 bits, con javac). JDK 8 no sirve. En Linux ARM64, revisa la carpeta Ghidra/Features/Decompiler/os/linux_arm_64. Diagnóstico:
npx -y rea-agents@6.4.0 doctor --provider ghidra --jsonRevisa la ruta de rea.mjs dentro del contenedor, el command de node (/usr/local/bin/node) y que cordis.patch.yml no esté vacío (un archivo solo con comentarios da error). Mira el registro:
docker compose logs --tail=50El id no coincide con ollama list, o editaste work/.dsh/settings.yaml y ./dsh local lo sobrescribió. Edita settings.local.yaml y ejecuta ./dsh local otra vez.
El contenedor solo ve /work y, en modo local, /projetos. Copia la app (o el .asar) a ~/projetos/dsh-sandbox/work/alvos/ y usa la ruta absoluta dentro del contenedor.
REA, Ghidra, dsh y Ollama son gratuitos. Lo que cuesta es el modelo.
| Escenario | Costo | Fuente |
|---|---|---|
| Modelo sin restricciones en la nube (prepago) | US$ 4 en la 1.ª versión + US$ 5 a 6 de ajustes | video de referencia no medido aquí |
| Modelo local en Ollama | R$ 0 por solicitud; solo máquina y energía | sin clave de API |
| Tiempo hasta la 1.ª versión | 20 a 30 min (nube); en local depende del modelo y de la máquina | video de referencia no medido aquí |
| Memoria del modelo local | 14 a 24 GB (tabla de modelos); dsh en sí usa ~85 MB | página de Ollama + medición de dsh-sandbox |
Claude, Codex y Gemini a veces rechazan partes de una ingeniería inversa, aunque sea legítima. La salida es un modelo abierto que no rechaza. Si tu computadora no corre el modelo, estas dos plataformas prepagas lo alojan por ti: cargas US$ 5 a 10 de crédito, tomas la clave y le pides al agente (dsh, Claude Code, Codex) que la use.
Modelos abiertos "abliterated" (sin el reflejo de rechazo en los pesos), por una API compatible con la de OpenAI. Prepago por token o plan mensual.
# Dirección de la API https://api.abliteration.ai/v1
Un enrutador con más de 200 modelos en una sola dirección, igual que OpenRouter. Tiene una versión abierta (MIT) que puedes alojar tú mismo.
Atención: en la nube, tu código sale de tu máquina. Para tu propia app o archivos sensibles, prefiere el modelo local (Ollama). Precios y catálogo cambian: revisa la página antes de cargar crédito.
Sin restricciones quiere decir que el modelo no rechaza tareas legítimas de ingeniería inversa. No es para nada ilegal.
Para que sepas dónde puedes pisar con seguridad.
| Elemento | Estado | Detalle |
|---|---|---|
| dsh en modo local con Ollama | medido | Arranque ~18 s, ~85 MB en reposo, qwen3.8:27b ~18–20 GB (dsh-sandbox, 08/2026). |
| REA, análisis JS sin Ghidra | medido | 6.3.0: 97 archivos en 20 s; 6.4.0: 202 archivos JS en 94,5 s, pico de 1,26 GB (Linux ARM, 10–12/10/2026). |
| REA bloqueado en un archivo JS gigante | medido | 6.3.0 se bloqueó e ignoró SIGTERM; 6.4.0 terminó. Límite con scripts/rea-com-timeout.sh probado en ambos modos. |
| Modelos sin restricciones de la tabla | no medido | Verificados en la página de Ollama; ninguno descargado (disco al 98%). |
| REA como MCP dentro de dsh | no medido | Receta manual según la documentación de REA y de dsh-mcp-client 0.1.1-rc.1. |
| Ghidra en esta máquina | no medido | Solo hay JDK 8; Ghidra 12.1.x requiere JDK 21 y, en ARM64, su propio descompilador nativo. |
| El clon de QuickTime, costos y tiempos | no medido | Cifras del video de referencia (macOS, modelo en la nube). |
Elementos pendientes de esta guía, en el orden en que más impacto tienen.
huihui_ai/Qwen3.8-abliterated:27b cuando haya espacio en disco y ejecutar el camino A en una app pequeña de Electron: tiempo, memoria, cuántas solicitudes hasta la primera versión.cordis.patch.yml, confirmar las herramientas mcp__rea__… en el panel y el valor de toolCallTimeoutMs.linux_arm_64, visibles en el contenedor, para binarios nativos.Guía anterior, con la técnica, los casos y la nueva prueba de 6.4.0: REA, ingeniería inversa con IA (en portugués). Repositorio de REA: morluto/rea (MIT, ~147 mil estrellas al 12/10/2026).