Adeus à engenharia reversa de qualquer coisa? Esta skill de 8 KB supera o REA (38% mais rápida)

Autoria: AICodeKing · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: RIP Reverse Engineer Anything! This 8 KB Skill Outperforms REA (38% Faster) · Canal: AICodeKing · 09:50 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Cibersegurança e segurança de software, Claude Code

Resumo

O vídeo apresenta a Lean REA, uma skill de cerca de 8 KB que orienta agents a usar comandos locais para analisar diferentes tipos de arquivos e aplicativos. Em um benchmark com quatro tarefas, ela foi 38% mais rápida, 35% mais barata e usou menos turns que o REA, com resultados de precisão quase iguais. O criador também compara o uso de contexto e o desempenho de ferramentas, explica limitações do teste e relata dois bugs corrigidos na skill. Por fim, mostra como instalá-la e reconhece que parte das técnicas veio do código do REA.

Pontos-chave

A Lean REA é uma única skill de aproximadamente 8 KB, sem MCP server nem ferramentas adicionais.
A skill mapeia tipos de arquivos e aplicativos aos comandos locais mais rápidos e inclui instruções, comandos prontos e regras para avaliar evidências.
No benchmark, a Lean REA concluiu as tarefas em 388 segundos, contra 479 segundos sem skill e 627 segundos com REA.
Em comparação com o REA, a Lean REA foi 38% mais rápida, 35% mais barata e usou 56% menos turns e 60% menos tokens.
A precisão foi semelhante: a Lean REA acertou 74 de 75 pontos, enquanto o REA acertou 75 de 75.
O teste de contexto mostrou que agents que carregam todas as ferramentas do REA no início podem consumir cerca de 400 mil tokens até para responder “okay”.
O benchmark foi limitado a três execuções por tarefa, um modelo e um Mac; o autor recomenda interpretar os resultados com cautela.
A skill está disponível no GitHub como aikocoding/leanria e pode ser instalada com o skills CLI.

Capítulos

Início	Capítulo	Resumo
00:02	REA e a criação da Lean REA	O autor apresenta a Lean REA e explica como ela substitui a camada do REA por comandos locais e uma skill compacta.
02:37	Estrutura da skill e resultados do benchmark	O vídeo descreve os comandos e regras da skill e compara seu desempenho, custo, turns e precisão com o REA e com o uso sem skill.
05:13	Consumo de contexto e limitações dos testes	O autor compara o uso de contexto e o tempo das ferramentas, comenta o desempenho sem skill e ressalta as limitações do benchmark.
07:47	Correções, instalação e conclusão	O vídeo relata bugs corrigidos, explica como instalar a Lean REA e conclui que uma skill pequena pode ser suficiente para orientar os comandos certos.

Citações

No meu benchmark, ela foi 38% mais rápida que o REA e 35% mais barata, com a mesma precisão. — 00:33

Se não encontrou um fato, diz que é desconhecido. Não diz que aquilo está ausente. — 03:08

Só para dizer “okay”. — 06:15

Você não precisa de 207 ferramentas. Precisa dos comandos certos, de algumas notas e de um modelo que consiga executá-los. — 09:20

Conceitos e entidades

REA (repo): Projeto que oferece um MCP server e um CLI com ferramentas para engenharia reversa de diferentes tipos de arquivos.
Lean REA (ferramenta): Skill compacta que direciona o agent a executar comandos locais para investigar aplicativos e arquivos.
Claude Code (ferramenta): Ferramenta usada no benchmark em modo headless e na comparação do consumo de contexto.
Sonic 5.5 (modelo): Modelo mencionado como o utilizado nos testes com Claude Code.
aikocoding/leanria (repo): Repositório no GitHub que contém a Lean REA, os scripts do benchmark e os resultados brutos.
skills CLI (ferramenta): CLI usada no vídeo para instalar a Lean REA em diferentes agents.
Ripgrep (ferramenta): Ferramenta de busca em arquivos cujo sinalizador -u permite incluir arquivos ocultos.
ZSH (ferramenta): Shell padrão no Mac citado no vídeo, cujo tratamento especial de dois sinais de igual causava falha em um comando.

Tradução completa (pt-BR)

00:02 Olá. Bem-vindos a mais um vídeo. Antes de começar, quero dizer que também tenho publicado, com mais regularidade, muitos tutoriais de projetos open source de que gosto em vídeos exclusivos para membros. Então, se quiser apoiar o canal, clique no botão de entrar. Os vídeos estão disponíveis em todos os níveis, a partir do bronze. Então, confira. Agora, de volta ao vídeo. No meu último vídeo, falei sobre REA. REA significa “fazer engenharia reversa de qualquer coisa”. É um projeto muito popular no GitHub.

00:33 Naquele vídeo, eu disse que o REA não é tão útil. Disse que os modelos já conseguem fazer esse trabalho com as ferramentas normais da sua máquina e que um pequeno arquivo de skill pode fazer a mesma coisa. Algumas pessoas me pediram para provar, então eu criei um. Chamei de Lean REA. É um único arquivo de skill. Tem cerca de 8 kilobytes. E, no meu benchmark, foi 38% mais rápido que o REA e 35% mais barato, com a mesma precisão. Então, vamos direto ao assunto. Primeiro, vamos lembrar o que é o REA. REA é um servidor MCP e uma CLI.

01:04 Ele disponibiliza 207 ferramentas para o seu agent. O pacote NPM tem cerca de 25 megabytes, e os arquivos de skill, junto com toda a documentação de referência, têm cerca de 72 kilobytes. Nos bastidores, o REA usa principalmente ferramentas que você já tem. Para um aplicativo Electron, ele usa o pacote ASAR. Para um binário de Mac, usa Otool e NM. Para um binário Go, lê as mesmas informações de build que o comando go version -m lê. Para Android, usa Jadx e APKTool. Então, o REA é uma camada sobre as mesmas ferramentas. O Lean REA

01:34 remove essa camada. Não há servidor MCP. Não há ferramentas extras. O agent usa o shell normal e executa as ferramentas reais diretamente. Agora, vamos falar sobre o que há dentro do arquivo de skill. Para criá-lo, analisei o código-fonte do REA. Mapeei cada recurso do REA para o comando simples que faz a mesma coisa. Depois, mantive apenas o comando mais rápido para cada tipo de alvo. A primeira parte é uma lista curta de regras. Trabalhe em uma cópia do alvo. Verifique primeiro o tipo de arquivo. Não leia um arquivo grande minificado; pesquise dentro dele e leia apenas o trecho de que precisa. E coloque várias verificações pequenas em uma única chamada de shell. A segunda parte é um roteador.

02:06 É uma tabela. À esquerda, você tem o tipo de alvo. À direita, tem o comando mais rápido para ele. Ela abrange aplicativos Electron, bundles web minificados e binários de Mac, Linux e Windows. Abrange Go, Rust, .NET, APKs de Android e Flutter. Também abrange WASM, arquivos SQLite, capturas de pacotes, firmware e sites. A terceira parte é o que chamo de primeiros passos. São comandos prontos que o agent pode copiar e executar. Para um binário de Mac, um comando obtém as bibliotecas vinculadas, as exportações, as

02:37 importações, as strings e a lista completa de funções. Tudo em uma única chamada. E isso importa muito porque, com agents, cada turno custa tempo. Um turno é uma ida e volta entre o modelo e uma ferramenta. Menos turnos significam uma resposta mais rápida. A skill também mantém os truques úteis que estão dentro do código do REA. Por exemplo, como ler os electron fuses, como encontrar as informações de build do Go em um binário e como encontrar o hash do snapshot do Flutter. São detalhes pequenos, mas o modelo pode não percebê-los. Então, eles estão no arquivo. E ele tem regras simples para as evidências. O modelo marca cada afirmação como observada,

03:08 inferida ou desconhecida. Se não encontrou um fato, diz que é desconhecido. Não diz que aquilo está ausente. Essa é a skill inteira. A documentação da skill do REA é cerca de nove vezes maior. Agora, vamos falar do benchmark, porque essa é a parte importante. Usei o Claude code no modo sem interface, com Sonic 5.5. Criei três configurações. A primeira não tem skill nem MCP, apenas o modelo e suas ferramentas normais. A segunda é o Lean REA. A terceira é o REA. Isso significa o servidor MCP do REA mais a skill oficial do REA. Depois, criei quatro

03:39 tarefas. A primeira tarefa usa um aplicativo de desktop Electron real. O modelo precisa rastrear um recurso pelo código do aplicativo. Precisa encontrar a função nativa, a classe que o controla e os canais IPC. IPC é a forma como as partes de um aplicativo Electron se comunicam. A segunda tarefa usa o complemento nativo desse mesmo aplicativo. É um pequeno binário de Mac. O modelo precisa listar as exportações, explicar uma verificação de permissão e explicar como funciona o bloqueio de instância única. >> A terceira tarefa usa um binário Go. Usei a CLI do GitHub. O modelo precisa encontrar a versão do Go e as versões de duas dependências.

04:11 A quarta tarefa é a mais difícil. Ela usa o mesmo complemento nativo, mas, dessa vez, o modelo precisa ler a desmontagem do código. Precisa encontrar o caminho exato de um arquivo de socket, o protocolo de comunicação e como o aplicativo verifica quem está se conectando. Cada configuração executou cada tarefa três vezes. Portanto, foram 36 execuções no total. Conferi cada resposta com um gabarito que fiz manualmente. E aqui estão os resultados. O Lean REA concluiu todas as execuções em 388 segundos. Sem skill, levou 479 segundos. E o REA levou 627 segundos. Em custo, o Lean REA

04:42 custou US$ 2,17. Sem skill, custou US$ 2,21. E o REA custou US$ 3,36. Em turnos, o Lean REA usou 55. Sem skill, foram 81. E o REA usou 124. Então, em comparação com o REA, o Lean REA foi 38% mais rápido. Foi 35% mais barato. Usou 56% menos turnos. E usou 60% menos tokens. E a precisão foi a mesma. O REA acertou 75 de 75. O Lean REA acertou 74 de 75. O único erro foi pequeno. Há duas versões de um canal IPC

05:13 no aplicativo. E, em uma execução, o Lean REA mencionou a versão mais antiga. A maior diferença foi na tarefa do Electron. O Lean REA levou cerca de 35 segundos. O REA levou cerca de 83 segundos. Na tarefa do Go, o Lean REA levou cerca de 12 segundos. O REA levou cerca de 26 segundos. E o motivo é simples. Para isso, o modelo só precisa de um comando. Com o REA, primeiro ele precisa encontrar a ferramenta certa, chamá-la e depois ler um resultado muito grande. Em uma execução do REA, a saída da ferramenta era tão grande que o Claude code a salvou em um arquivo. Depois, o modelo teve que abrir esse arquivo em mais turnos. Então, isso é tempo extra desperdiçado. Agora, vamos falar sobre

05:44 o contexto. Como esse foi um ponto que mencionei no meu último vídeo, enviei uma mensagem simples: “responda com ok”. Depois, medi quantos tokens cada configuração usou. Sem nada, foram cerca de 31.000 tokens. Esse é o system prompt normal do Claude Code. Com o Lean REA, foram cerca de 34.500 tokens. Com o REA, depende do seu agent. O Claude Code tem um recurso chamado busca de ferramentas. Ele carrega as ferramentas MCP apenas quando precisa delas. Com esse recurso ativado, o REA acrescenta cerca de 3.500 tokens. Então, nesse caso, está tudo bem. Mas muitos agents carregam todas as ferramentas no

06:15 início. Então, desativei a busca de ferramentas e, nesse caso, aquela mensagem de “ok” usou cerca de 400.000 tokens. Custou US$ 1,60. Só para dizer “ok”. Esse é o mesmo problema de que falei da última vez. Em um agent que carrega todas as ferramentas, o REA preenche a maior parte do contexto antes que o modelo leia uma linha sequer do seu alvo. Também fiz um pequeno teste com as próprias ferramentas. Mesmo arquivo, mesma tarefa. Uma vez com a CLI do REA, outra vez com o comando simples. Para obter as informações de build do Go, o REA levou cerca de meio segundo. O comando simples go version levou seiscentos avos de

06:47 segundo. Para obter uma visão geral do binário de Mac, o REA levou 3,3 segundos. O comando simples levou quatrocentos avos de segundo. E, para o aplicativo Electron, essa parte é engraçada. O REA não funcionou de primeira. Deu um erro de integridade no aplicativo real. Você precisa adicionar uma flag extra para que ele continue. Com essa flag, levou cerca de 48 segundos. E retornou 140 megabytes de JSON. O jeito simples é extrair o arquivo SR e pesquisá-lo com rip grep. Isso levou cerca de 5 segundos, e a saída teve 24 kilobytes. E ela continha a resposta. Agora,

07:17 Deixe-me ser justo aqui. O modelo sem skill já era muito bom. Ele acertou quase tudo. O Lean REA foi cerca de 19% mais rápido do que o modelo sem skill e usou cerca de 32% menos turnos. Mas o custo foi praticamente o mesmo. Então, a grande vantagem é em relação ao REA, não ao modelo simples. O modelo simples recusou uma tarefa uma vez. Ele achou que a tarefa de desmontagem poderia ajudar alguém a burlar uma verificação de segurança. Com a skill, isso não aconteceu. Mas foi só uma execução, então não leve isso tão a sério. Além disso, este é um benchmark pequeno

07:47 São três execuções por tarefa, um modelo e um Mac. Eu não tinha o Ghidra nem o JADX instalados, então, nas tarefas nativas, usei as ferramentas padrão do Xcode em todas as configurações. E encontrei dois bugs na minha própria skill durante os testes. Quero falar sobre eles porque são boas dicas. O primeiro é sobre o Ripgrep. Por padrão, o Ripgrep ignora pastas ocultas, e muitos apps Electron guardam o código em uma pasta oculta chamada .webpack. Então, minha primeira busca não encontrou nada. Agora, a skill instrui o modelo a usar o Ripgrep

08:18 com a flag -u. Essa flag também busca arquivos ocultos. O segundo é sobre o ZSH, que é o shell padrão no Mac. Usei echo com dois sinais de igual como marcador entre as saídas, mas o ZSH interpreta dois sinais de igual de uma maneira especial, e o comando falhou. Agora, os marcadores ficam entre aspas, então teste seus arquivos de skill. Até um arquivo pequeno pode ter bugs. Agora, vamos falar sobre como instalar. Está no GitHub em aikocoding/leanria. E funciona com o skills CLI. Basta executar NPX skills add aikocoding/leanria. Ele pergunta quais agents você usa. Ele

08:50 é compatível com Claude Code, Codex, Cursor, Gemini CLI, Open Code e outros. Se quiser em todos os projetos, adicione a flag -g. E, se quiser pular as perguntas, adicione a flag -y. Depois, você pode usar com o comando /leanria. Por exemplo: /leanria, “Como funciona o recurso de busca neste app? Mostre as evidências.” O repo também tem o benchmark completo, para você executá-lo por conta própria. Há um script de configuração, um script para executar todas as tarefas e um script para o teste de contexto. E todos os resultados brutos também estão lá. Então, o que eu acho? Acho que isso demonstra o ponto que levantei

09:20 no último vídeo. Os modelos já são bons nisso. Você não precisa de 207 ferramentas. Precisa dos comandos certos, de alguns nós e de um modelo capaz de executá-los. O REA ainda é um bom projeto. A equipe fez um ótimo trabalho, e muitos dos truques da minha skill vieram da leitura do código deles. Então, fica aqui o crédito para eles. Mas, se você é programador, eu usaria a skill pequena. Ela é mais rápida, mais barata, e dá para ler tudo em 2 minutos. No geral, é bem legal. Enfim, conte o que você acha nos comentários. Se gostou deste vídeo, considere fazer uma doação pela opção Super Thanks

09:50 ou se tornar membro clicando no botão de adesão. Além disso, dê um joinha neste vídeo [música] e inscreva-se no meu canal. Vejo você no próximo. Até lá, tchau. >> [música] [música]

Transcrição original

[00:02] Hi. Welcome to another video. Before starting the video, I have been posting many tutorials of open source projects that I like in members only videos as well. I am posting more regularly. So, if you want to support the channel, please hit the join button and the videos are available on all tiers from bronze and up. So, please go ahead and check them out. Now, back to the video. So, in my last video I talked about REA. REA means reverse engineer anything. It is a very popular project on GitHub.

[00:33] In that video, I said that REA is not that useful. I said that models can already do this work with the normal tools on your machine and I said that a small skill file can do the same job. Some people asked me to prove it, so I built it. I call it lean REA. It is one skill file. It is about 8 kilobytes. And in my benchmark, it was 38% faster than REA and 35% cheaper with the same accuracy. So, let’s get right into it. First, let’s remember what REA is. REA is an MCP server and a CLI.

[01:04] It puts 207 tools into your agent. The NPM package is about 25 megabytes and the skill files with all the reference docs are about 72 kilobytes. Under the hood, REA mostly calls tools that you already have. For an electron app, it uses the ASAR package. For a Mac binary, it uses Otool and NM. For a Go binary, it reads the same build info that Go version {dash} M reads. For Android, it uses Jadx and APKTool. So, REA is a layer on top of the same tools. Lean REA

[01:34] removes that layer. There is no MCP server. There are no extra tools. The agent uses its normal shell and it runs the real tools directly. Now, let’s talk about what is inside the skill file. To make it, I went through the REA source code. I mapped each REA feature to the plain command that does the same thing. Then I kept only the fastest command for each target. The first part is a short list of rules. Work on a copy of the target. Check the file type first. Do not read a big minified file, search inside it and read only the part that you need and put many small checks into one shell call. The second part is a router.

[02:06] It is a table. On the left, you have the type of target. On the right, you have the fastest command for It covers electron apps, minified web bundles, and Mac, Linux, and Windows binaries. It covers Go, Rust, .NET, Android APKs, and Flutter. And it also covers WASM, SQLite files, packet captures, firmware, and websites. The third part is what I call first moves. These are ready commands that the agent can paste and run. For a Mac binary, one command gets the linked libraries, the exports, the

[02:37] imports, the strings, and the full list of functions. All of it in one call. And this matters a lot because with agents, each turn costs time. A turn is one round trip between the model and a tool. Fewer turns means a faster answer. The skill also keeps the useful tricks that are inside the REA code. For example, how to read the electron fuses, how to find the Go build info in a binary, how to find the Flutter snapshot hash. These are small details, but the model can miss them. So, they are in the file. And it has simple evidence rules. The model marks each claim as seen,

[03:08] inferred, or unknown. If it did not find a fact, it says unknown. It does not say that the thing is absent. That is the whole skill. The REA skill docs are about nine times bigger. Now, let’s talk about the benchmark because this is the important part. I used Claude code in headless mode with Sonic 5.5. I made three setups. The first setup is no skill and no MCP, just the model and its normal tools. The second setup is Lean REA. The third setup is REA. That means the REA MCP server plus the official REA skill. Then, I made four

[03:39] tasks. The first task uses a real electron desktop app. The model must trace one feature through the app code. It must find the native function, the class that controls it, and the IPC channels. IPC is how the parts of an electron app talk to each other. The second task uses the native add-on from that same app. It is a small Mac binary. The model must list the exports, explain one permission check, and explain how the single instance lock work. >> The third task is a Go binary. I used the GitHub CLI. The model must find the Go version and the versions of two dependencies.

[04:11] The fourth task is the hard one. It uses the same native add-on, but this time the model must read the disassembly. It must find the exact path of a socket file, the wire protocol, and how the app checks who is connecting. Each setup did each task three times. So, that is 36 runs in total. I checked every answer against an answer key that I made by hand. And here are the results. Lean REA finished all the runs in 388 seconds. With no skill, it took 479 seconds. And REA took 627 seconds. For cost, Lean REA

[04:42] was $2.17. No skill was $2.21. And REA was $3.36. For turns, Lean REA used 55 turns. No skill used 81. And REA used 124. So, compared to REA, Lean REA was 38% faster. It was 35% cheaper. It used 56% fewer turns. And it used 60% fewer tokens. And the accuracy was the same. REA got 75 out of 75. Lean REA got 74 out of 75. The one miss was a small one. There are two versions of one IPC

[05:13] channel in the app. And in one run, Lean REA named the older one. The biggest gap was on the electron task. Lean REA took about 35 seconds. REA took about 83 seconds. On the Go task, Lean REA took about 12 seconds. REA took about 26 seconds. And the reason is simple. The model only needs one command for this. With REA, it first has to find the right tool, call it, and then read a very big result. In one REA run, the tool output was so big that Claude code saved it to a file. Then the model had to open that file in more turns. So, that is extra time for nothing. Now, let’s talk about

[05:44] context. Because this was a point in my last video, I sent one simple message, which was reply with okay. Then I measured how many tokens each setup used. With nothing, it was about 31,000 tokens. That is the normal Claude Code system prompt. With Lean REA, it was about 34,500 tokens. With REA, it depends on your agent. Claude Code has a feature called tool search. It loads the MCP tools only when it needs them. With that turned on, REA adds about 3,500 tokens. So, it is fine there. But, many agents load all the tools at

[06:15] the start. So, I turned tool search off, and then that one okay message used about 400,000 tokens. It cost $1.60. Just to say okay. So, that is the same problem that I talked about last time. In an agent that loads all the tools, REA fills most of the context before the model reads one line of your target. I also did a small test on the tools themselves. Same file, same job. One time with the REA CLI, one time with the plain command. For the go build info, REA took about half a second. The plain go version command took 600ths of a

[06:47] second. For the Mac binary overview, REA took 3.3 seconds. The plain command took 400ths of a second. And for the electron app, this one is funny. REA did not work at first. It gave an integrity error on the real app. You have to add an extra flag to make it continue. With that flag, it took about 48 seconds. And it gave back 140 megabytes of JSON. The plain way is to extract the SR file and search it with rip grep. That took about 5 seconds, and the output was 24 kilobytes. And it had the answer. Now,

[07:17] let me be fair here. The model with no skill was already very good. It got almost everything right. Lean REA was about 19% faster than no skill, and it used about 32% fewer turns. But, the cost was about the same. So, the big win is against REA, not against the plain model. The plain model did refuse one task one time. It thought that the disassembly task could help someone defeat a security check. With the skill, that did not happen. But it was only one run, so take it with a grain of salt. Also, this is a small

[07:47] benchmark. It is three runs per task, one model, and one Mac. I did not have Ghidra or Jad God installed, so the native tasks used the normal Xcode tools for all the setups. And I found two bugs in my own skill while I tested it. So, I want to tell you about them because they are good tips. The first one is about Ripgrep. Ripgrep skips hidden folders by default, and many Electron apps keep their code in a hidden folder called .webpack. So, my first search found nothing. Now, the skill tells the model to use Ripgrep

[08:18] with the -u flag. That flag searches hidden files, too. The second one is about ZSH, which is the default shell on a Mac. I used echo with two equal signs as a marker between outputs, but ZSH reads two equal signs in a special way, and the command failed. Now, the markers are in quotes, so test your skill files. Even a small file can have bugs. Now, let’s talk about how to install it. It is on GitHub at aikocoding/leanria. And it works with the skills CLI. Just run NPX skills add aikocoding/leanria. It asks which agents you use. It

[08:50] supports Claude Code, Codex, Cursor, Gemini CLI, Open Code, and more. If you want it in every project, add the -g flag. And if you want to skip the questions, add the -y flag. Then, you can use it with the /leanria command. For example, /leanria, “How does the search feature in this app work? Show me the evidence.” The repo also has the full benchmark, so you can run it yourself. There is a setup script, a script to run all the tasks, and a script for the context test. And all the raw results are in there, too. So, what do I think? I think this shows the point that I made

[09:20] in the last video. Models are good at this already. You do not need 207 tools. You need the right commands, a few nodes, and a model that can run them. REA is still a good project. The team did a lot of good work, and a lot of the tricks in my skill came from reading their code. So, credit to them. But if you are a programmer, I would use the small skill. It is faster, it is cheaper, and you can read the whole thing in 2 minutes. Overall, it’s pretty cool. Anyway, let me know your thoughts in the comments. If you like this video, consider donating through the Super

[09:50] Thanks option or becoming a member by clicking the join button. Also, give this video [music] a thumbs up and subscribe to my channel. I’ll see you in the next one. Until then, bye. >> [music] [music]