Um modelo aberto que não recusa engenharia reversa legítima, o harness dsh rodando local e o REA ligando o Ghidra. Você aponta um app e pede a sua versão.
Este é um guia em português para recriar um programa de computador do seu jeito usando três peças abertas: um harness de agente local (o dsh, agente de código da DeepSeek), um modelo aberto "sem trava" rodando no Ollama e o REA, que dá ao agente ferramentas de engenharia reversa como o Ghidra. Serve para quem programa ou estuda e quer entender como um app funciona e fazer a própria versão, sem depender de modelos de nuvem que às vezes recusam o pedido. Tudo roda na sua máquina: você precisa de Docker, Ollama, Node 22 e memória para um modelo de 14 a 24 GB. Espere chegar a uns 80% do app, não à última milha.
O modelo é o cérebro, o harness é o corpo com as ferramentas, e o REA são os olhos que enxergam dentro do app compilado.
A bancada onde o agente vive: lê e escreve arquivos, roda comandos e chama ferramentas MCP. Aqui ele roda em container, só no endereço local, e deixa trocar o modelo.
Uma versão "abliterated" de um modelo aberto: tiraram dele o reflexo de recusar. Roda no Ollama da sua máquina, sem chave de API e sem mandar nada para fora.
O REA (Reverse Engineer Anything) é um servidor MCP e uma linha de comando que entregam ao agente a análise do app: módulos, funções, ligações, com evidência e limites.
O agente não precisa ser genial: o REA já organiza as ferramentas, e o modelo só executa. Por isso um modelo aberto de porte médio dá conta de boa parte.
O player de vídeo do Mac (QuickTime) só oferece poucas velocidades fixas. O agente estudou o app e criou um novo, com outro nome ("Tempo") e outro ícone, com velocidade granular, ondas de áudio e ajuste de tom. Uns 80% saíram num pedido só; o resto foi fonte, visual e exportação.
Só o que existe de verdade na página do Ollama em 12/10/2026 (aba "tags" de cada modelo). Nenhum foi baixado nem medido nesta máquina: o disco estava em 98%. Escolha pelo tamanho que cabe na sua memória.
| Modelo (comando exato) | Tamanho | Recursos na página | Observação |
|---|---|---|---|
ollama pull huihui_ai/Qwen3.8-abliterated:27b | 18 GB (q4_K_M) | tools · thinking · vision | Mesma base do qwen3.8:27b que já roda no dsh daqui. Primeira escolha. não medido |
ollama pull huihui_ai/Qwen3.6-abliterated:35b-a3b | 24 GB | tools · thinking · vision | MoE (3B ativos por token): tende a ser rápido. não medido |
ollama pull huihui_ai/glm-4.7-flash-abliterated | 19 GB | tools · thinking | Família GLM, a mesma do exemplo do vídeo (lá foi uma versão maior, na nuvem). não medido |
ollama pull huihui_ai/gpt-oss-abliterated:20b | 14 GB | tools · thinking | O menor da lista com ferramentas. Bom para máquina com 32 GB. não medido |
ollama pull huihui_ai/qwen3-coder-abliterated:30b | 19 GB | sem etiqueta "tools" na página | Focado em código, mas confira a etiqueta tools: sem chamada de ferramenta o agente não usa o REA. não medido |
./dsh remoto) que hospedam modelos sem trava, com crédito de US$ 5 a 10. Aí o código do app sai da sua máquina, e no modo remoto o dsh não monta ~/projetos de propósito.Testado como referência numa máquina Linux ARM (DGX GB10, 128 GB de memória unificada). Em outra máquina, os comandos são os mesmos; mudam os tamanhos que cabem.
O dsh (@deepseek-ai/dsh 0.1.1-rc.1) em container node:22-slim, teto de 3 GB, usuário não-root, só em 127.0.0.1:9080.
cd ~/projetos/dsh-sandbox ./dsh status # modo, container, http, provedores
Porta 11434, contexto de 32K e KV cache q8_0 no serviço. Confira o que já tem e o espaço em disco antes de puxar um modelo.
ollama list df -h / # o modelo pede 14 a 24 GB livres
O REA exige Node 22.19+, 24.11+ ou 26+. O container do dsh já traz o 22.23.
docker run --rm node:22-slim node -v # v22.23.x
Para app compilado (C, C++, Swift, Rust). No Linux ARM64 o decompilador nativo pode precisar ser compilado à parte. Nesta máquina há só o JDK 8, então esse caminho está não medido. App Electron/JavaScript dispensa o Ghidra.
java -version # precisa ser 21 ou mais novo
Os prompts completos para copiar e colar estão na pasta prompts/ do repositório.
O modo local monta ~/projetos em /projetos e deixa só o Ollama como provedor: nada sai da máquina. Abra o painel e escolha o workspace.
cd ~/projetos/dsh-sandbox ./dsh local # ~20 s; depois abra http://127.0.0.1:9080 ./dsh status # deve mostrar: modo local, /projetos montado SIM, provedores: ollama # de outra máquina: ssh -L 9080:127.0.0.1:9080 usuario@servidor
Baixe um da tabela acima. Depois acrescente o modelo em settings.local.yaml (não no work/.dsh/settings.yaml, que é sobrescrito a cada troca de modo), dentro de llm-pi-ai → providers → ollama → models. O id tem de bater letra por letra com o ollama list.
ollama pull huihui_ai/Qwen3.8-abliterated:27b ollama list | grep abliterated
# settings.local.yaml — acrescente na lista models do provedor ollama - id: huihui_ai/Qwen3.8-abliterated:27b name: Qwen3.8 27B sem trava contextWindow: 32768 maxTokens: 8192 reasoningEfforts: off: none # "none" explícito: vazio deixa o raciocínio LIGADO no Ollama low: low high: high max: high
./dsh local # copia o settings.local.yaml para o container (sem rebuild)
No painel, o modelo novo aparece no seletor. O bloco compat do provedor (supportsDeveloperRole: false, maxTokensField: max_tokens) já está no arquivo e é obrigatório para o Ollama.
Caminho A — app Electron/JavaScript, sem Ghidra. O agente roda o REA pela linha de comando dentro do próprio container. Foi o caminho medido aqui: REA 6.3.0 analisou um app Node de 97 arquivos em 20 s; o REA 6.4.0 analisou um app Electron de 202 arquivos JS em 94,5 s (pico de 1,26 GB). Ponha o alvo numa pasta que o container enxerga (~/projetos/dsh-sandbox/work/alvos vira /work/alvos) e cole o prompt:
Instale isto e me ajude a fazer engenharia reversa de um app: https://github.com/morluto/rea
Use npx -y rea-agents@6.4.0, sempre com "timeout -k 10 600" na frente.
Analise /work/alvos/<app>.asar com analyze-javascript-application --json,
resuma módulos, telas e onde fica <a função que me interessa>, com a evidência.
Caminho B — REA como MCP dentro do dsh (não medido). O registro automático rea setup --client dsh ainda não saiu no pacote publicado (a doc do REA diz "só na main, depois da 6.4.0"). O jeito manual: instalar o REA numa pasta própria do work/ (sem mexer no node_modules congelado do dsh) e registrar o servidor no cordis.patch.yml da casa do 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 (no container: /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 # o padrão é 60 s; uma análise passa disso
Reinicie com ./dsh local; as ferramentas aparecem como mcp__rea__…. Para binário nativo, o REA precisa de Ghidra 12.1.x e JDK 21 visíveis de dentro do container (GHIDRA_INSTALL_DIR, JAVA_HOME) e de mais memória que os 3 GB do container. Isso não foi montado nem medido aqui.
Comece por um app pequeno, que você usa e do qual sente falta de uma coisa só. Peça um app novo, com nome e ícone seus, escrito do zero, e que liste no fim o que ficou de fora.
Com base na análise, crie um app NOVO, com nome e ícone próprios (sem nome, ícone,
textos ou código do fabricante), que faça o que <app original> faz em <função principal>
e acrescente: velocidade de reprodução de 0,1x a 4x, em passos de 0,05.
Código do zero em /work/minha-versao. Primeiro a versão mínima que funciona;
no fim, liste o que ficou de fora e o que precisa de teste manual.
A primeira versão costuma funcionar no essencial. O resto é ajuste: aparência, exportação, pequenos erros. Um pedido de cada vez, testando entre eles.
Abri a versão 1. O que não funcionou: <o que viu, com a mensagem de erro>.
Corrija só isso, rode de novo e me diga como confirmar que ficou certo.
Pare. Resuma em 5 linhas o que já tentou, o que deu erro e qual é a hipótese. Não rode mais nada até eu responder. # quando o agente empaca
Marque cada item. Se algum falhar, vá para "Problemas".
./dsh status mostra modo local, http 200 e /projetos montado.ollama list mostra o modelo sem trava com o mesmo nome do id no YAML.ls /work (prova de que chama ferramentas).npx -y rea-agents@6.4.0 --help roda de dentro do agente.Os casos que já apareceram nesta máquina ou que a documentação do REA e do dsh descreve.
O REA 6.3.0 travou num app com um arquivo JS único gigante e ignorou o SIGTERM: foi preciso matar o órfão pelo PID. Na 6.4.0 o mesmo app terminou. Mesmo assim, rode sempre com teto:
# no host (systemd-run + timeout) ou no container (timeout): scripts/rea-com-timeout.sh -t 600 -m 6G -- \ npx -y rea-agents@6.4.0 analyze-javascript-application /abs/app.asar --json
Sinais: inventa o nome de ferramentas, repete o mesmo comando, esquece o objetivo. Troque para um maior da tabela, divida o pedido em partes menores e mande o agente salvar o resumo da análise em arquivo para reler depois. O contexto de 32K enche rápido com JSON grande: peça resumo, não o JSON inteiro.
O REA aceita Ghidra 12.1.x com JDK 21+ (64 bits, com javac). JDK 8 não serve. No Linux ARM64 confira a pasta Ghidra/Features/Decompiler/os/linux_arm_64. Diagnóstico:
npx -y rea-agents@6.4.0 doctor --provider ghidra --jsonConfira o caminho do rea.mjs dentro do container, o command do node (/usr/local/bin/node) e se o cordis.patch.yml não está vazio (arquivo só com comentários dá erro). Veja o log:
docker compose logs --tail=50O id não bate com o ollama list, ou você editou o work/.dsh/settings.yaml e o ./dsh local sobrescreveu. Edite o settings.local.yaml e rode ./dsh local de novo.
O container só enxerga /work e, no modo local, /projetos. Copie o app (ou o .asar) para ~/projetos/dsh-sandbox/work/alvos/ e use o caminho absoluto de dentro do container.
O REA, o Ghidra, o dsh e o Ollama são gratuitos. O que custa é o modelo.
| Cenário | Custo | Fonte |
|---|---|---|
| Modelo sem trava na nuvem (pré-pago) | US$ 4 na 1ª versão + US$ 5 a 6 de ajustes | vídeo de referência não medido aqui |
| Modelo local no Ollama | R$ 0 por pedido; só máquina e energia | sem chave de API |
| Tempo até a 1ª versão | 20 a 30 min (nuvem); local depende do modelo e da máquina | vídeo de referência não medido aqui |
| Memória do modelo local | 14 a 24 GB (tabela de modelos); o dsh em si usa ~85 MB | página do Ollama + medição do dsh-sandbox |
Sem trava quer dizer que o modelo não recusa tarefas legítimas de engenharia reversa. Não é para nada ilegal.
Para você saber em que pisar com segurança.
| Item | Status | Detalhe |
|---|---|---|
| dsh no modo local com Ollama | medido | Boot ~18 s, ~85 MB ocioso, qwen3.8:27b ~18–20 GB (dsh-sandbox, 08/2026). |
| REA, análise JS sem Ghidra | medido | 6.3.0: 97 arquivos em 20 s; 6.4.0: 202 arquivos JS em 94,5 s, pico 1,26 GB (Linux ARM, 10–12/10/2026). |
| REA travando em arquivo JS gigante | medido | 6.3.0 travou e ignorou SIGTERM; 6.4.0 terminou. Teto com scripts/rea-com-timeout.sh testado nos dois modos. |
| Modelos sem trava da tabela | não medido | Conferidos na página do Ollama; nenhum baixado (disco em 98%). |
| REA como MCP dentro do dsh | não medido | Receita manual pela doc do REA e do dsh-mcp-client 0.1.1-rc.1. |
| Ghidra nesta máquina | não medido | Só há JDK 8; Ghidra 12.1.x pede JDK 21 e, no ARM64, decompilador nativo próprio. |
| O clone do QuickTime, custos e tempos | não medido | Números do vídeo de referência (macOS, modelo na nuvem). |
Itens abertos deste guia, na ordem em que fazem mais diferença.
huihui_ai/Qwen3.8-abliterated:27b quando houver disco e rodar o caminho A num app Electron pequeno: tempo, memória, quantos pedidos até a 1ª versão.cordis.patch.yml, confirmar as ferramentas mcp__rea__… no painel e o toolCallTimeoutMs.linux_arm_64, visíveis no container, para binários nativos.Guia anterior, com a técnica, os casos e o reteste da 6.4.0: REA, engenharia reversa com IA. Repositório do REA: morluto/rea (MIT, ~147 mil estrelas em 12/10/2026).