O REA põe um agente de IA a desmontar binários, e isso pode valer mais para o direito à reparação do que a directiva que Portugal ainda não transpôs…

Olá a todos!

Prefácio do costume, hoje com três camadas e icing ao fim por causa das calorias. A primeira já a conhecem: corro modelos locais, desconfio por defeito de tudo o que só funciona enquanto o servidor de outra pessoa estiver ligado, e tenho uma gaveta com aparelhos em perfeito estado que não servem para nada. A segunda: não sou advogado, e este post fala bastante de lei. Onde cito diplomas, cito-os com o cuidado de quem leu o texto, não com a autoridade de quem o defende em tribunal. A terceira, e esta é a que mais importa: a ferramenta de que vou falar é de duplo uso. Serve para preservar, reparar e tornar coisas interoperáveis, e serve também para coisas que eu não queria ver ninguém a fazer. Vou falar das duas, porque esconder uma das metades é a forma mais rápida de perder a discussão.
Notem ainda que este deve ter sido dos posts mais compridos que já escrevi. Não porque estava muito chatty, mas porque o assunto é mesmo muito complexo em vários capítulos.

No dia 9 de Dezembro de 2024, quem ligou um Spotify Car Thing deu com uma frase seca no ecrã a dizer que o aparelho estava descontinuado e já não funcionava. Não havia avaria. O ecrã acendia, o botão rodava, o processador Amlogic com 512 MB de RAM fazia exactamente o que fazia na véspera. A única coisa que tinha mudado era do outro lado: a Spotify tinha desligado a autenticação no servidor, e um objecto vendido a 89,99 dólares passou, de um dia para o outro, a ser um botão de volume com ecrã incluído.

A história tem um segundo capítulo, e é por causa dele que escrevo isto. Uma comunidade de entusiastas pegou no aparelho, percebeu como funcionava por dentro e escreveu firmware novo. O Nocturne arrancou em Outubro de 2024, ainda antes da data fatídica, e foi lançando versões até ter funcionamento offline. Em Agosto de 2026 saiu o Mira 1.0, outro firmware aberto que corre no próprio Car Thing e dispensa qualquer infraestrutura da Spotify. O hardware que a empresa mandou reciclar voltou a funcionar, e em alguns aspectos melhor do que antes.

Ninguém deu a estas pessoas o código fonte. Tiveram de o ler a partir do binário.

Há um mês escrevi aqui sobre o CERN e sobre a ideia de que, quando o hardware vive mais tempo do que o roteiro do fornecedor, quem controla o relógio de substituição vale mais do que quem promete a data de fim de suporte mais distante. Este post é a versão doméstica dessa conversa. Só que aqui não há uma equipa de engenheiros do CERN para preparar o plano B. Há um utilizador, uma gaveta e, desde há uns meses, um agente de IA com acesso a um desmontador.

Como a pizaria diria, cortemos isto em fatias.

O que é o REA, sem o marketing

O REA (de Reverse Engineer Anything) é um projecto aberto, em licença MIT, alojado em github.com/morluto/rea. Na altura em que escrevo tem mais de 170 mil estrelas, cerca de 40 mil forks e mais de 2600 commits, o que para uma ferramenta de engenharia reversa é um número que eu nunca pensei ver. O README está traduzido em dezanove línguas, incluindo português do Brasil. Português de Portugal, nem vê-lo. Fica a sugestão para quem tiver uma tarde livre.

Tecnicamente, o REA é duas coisas ao mesmo tempo. É um servidor MCP, ou seja, um conjunto de ferramentas que um agente de IA (Claude Code, Codex, Cursor, Gemini CLI, Grok Build e outros que falem MCP local) pode chamar por si. E é uma linha de comandos, o rea, que expõe os mesmos fluxos de trabalho a quem prefere o terminal. O pacote npm chama-se Rea-Agents e o projecto está também publicado no registo oficial de MCP como io.github.morluto/rea.

A parte interessante é o que está por baixo. O REA não reinventa o descompilador. Liga o agente a ferramentas que já existem e que quem faz isto há anos conhece bem: Hopper, Ghidra ou IDA para binários nativos, JADX para APKs de Android, Binwalk e Unblob para firmware, TShark para capturas de rede, sigrok para sinais lógicos gravados, adb para dispositivos Android, e mais umas quantas. Por cima disso, acrescenta leitores próprios para formatos onde não precisa de motor externo: aplicações JavaScript e Electron, assemblies .NET, binários Go, WebAssembly, bytecode EVM, bases de dados SQLite, ficheiros HAR de navegador, aplicações Flutter. O Ghidra, via REA, chega a analisar programas de DOS em 16 bits.

Dito de outra forma: é uma camada que transforma uma caixa de ferramentas dispersa, cada uma com a sua sintaxe, as suas manias e o seu manual de duzentas páginas, numa coisa a que um agente pode fazer perguntas em linguagem natural e receber respostas com prova.

E o “com prova” é a parte que me fez sorrir preversamente. Cada conclusão que o REA devolve vem acompanhada das evidências em que assenta (endereços, referências cruzadas, digests SHA-256 dos ficheiros analisados, versões das ferramentas usadas) e, sobretudo, das limitações. Quando não sabe, diz que não sabe. Quando uma chamada é computada e não dá para resolver estaticamente, fica marcada como desconhecida em vez de ser adivinhada. Quem já viu um LLM inventar uma função que não existe percebe porque é que isto importa.

Agora a parte de que menis me agrada. O pitch oficial do projecto é, em resumo, este: vês uma funcionalidade numa aplicação de que gostas, pedes ao agente que a investigue com o REA, ele explica-te como funciona e constrói uma versão para o teu produto. O exemplo do README é literalmente perceber como funciona a pesquisa na aplicação Notas e fazer uma igual.

Percebo o apelo comercial. Mas é exactamente o ângulo que menos me interessa e o que mais vai alimentar os críticos. O próprio projecto parece saber disso: o ficheiro DISCLAIMER.md diz preto no branco que o REA não ajuda a contornar DRM, verificações de licença ou anti-cheat, não ajuda a copiar software proprietário nem a reproduzir o seu código protegido, e lista como usos legítimos a investigação de segurança, a análise de malware, a educação, a interoperabilidade e a preservação de software. Pedidos para os usos proibidos são fechados sem resposta.

Interoperabilidade e preservação. Guardem estas duas palavras, que vão voltar.

Quando os case studies dizem mais que a publicidade

Se o pitch é sobre copiar funcionalidades, os casos de estudo que o projecto escolheu mostrar são sobre outra coisa. E acho isso muito revelador.

O primeiro é o DX-Ball, um jogo de partir tijolos para Windows que muitos de nós jogou em computadores de escola. O agente seguiu uma chamada de som até à função que calcula o panorama estéreo a partir da posição da bola, inspeccionou as instruções x86 e transformou pseudocódigo incompleto em C. A reconstrução passa 3205 casos de teste contra o original e reproduz byte a byte os 63 bytes da função compilada.

O segundo é o TH04, um jogo da série Touhou para o PC-98, uma plataforma japonesa que a maior parte das pessoas nunca viu ao vivo. Instruções de 16 bits, cálculos de ângulos de projécteis recuperados e comparados com a saída do compilador histórico.

O terceiro é o Notion, e aqui é uma aplicação Electron moderna: seguir a API de área de transferência do renderer, através do preload e do IPC, até ao processo principal.

Dois em três são exercícios de arqueologia. Software cujos autores já não o mantêm, para plataformas que já não existem, reconstruído com precisão suficiente para ser verificado. Isto é preservação de software no sentido mais literal, e é o mesmo conjunto de competências de que precisa quem quer manter vivo um aparelho cujo fabricante desapareceu.

Como se instala

A instalação é das coisas mais bem pensadas que vi num projecto deste género, e digo isto como alguém que tem por hábito ler os instaladores antes de os correr.

Os requisitos base são Node.js 22.x (a partir da 22.19), 24.x (a partir da 24.11) ou 26 e posteriores, mais o npm que vem com o runtime. O REA não actualiza Node, npm nem Homebrew por vocês, o que agradeço.

O ponto de entrada recomendado é este:

npx --yes rea-agents@latest setup

O @latest explícito está lá de propósito: evita que uma dependência de projecto ou uma cache velha do npx escolham a versão do setup por vocês.

O que acontece a seguir não é um instalador que despeja coisas no sistema. O setup detecta os agentes que tem instalados, mostra um plano com tudo o que vai mudar (caminhos de configuração de cada agente, destino da skill, software externo, origens de rede, digests de integridade) e só escreve depois de aprovação explícita. Faz backup das configurações existentes, preserva entradas que não são suas, usa substituição atómica e verifica o resultado. Se a configuração existente estiver malformada, aborta antes de tocar em qualquer ficheiro.

Se quiserem o comando rea disponível na shell para uso regular:

npm install --global rea-agents  
Reo --help

Atenção a um detalhe que apanha muita gente: npm install rea-agents sem --global instala o executável apenas no node_modules/.bin do projecto actual. Não fica no PATH.

Existe também um instalador por curl. Não sou fã do padrão curl | bash, e já o disse aqui várias vezes, mas este pelo menos aceita --dry-run e mostra versão, runtime e destino antes de instalar:

curl -fsSL https://raw.githubusercontent.com/morluto/rea/main/install.sh | bash -s -- --dry-run

A minha recomendação continua a ser a de sempre: descarreguem o install.sh, leiam-no, e só depois o corram.

Para verificar o estado da instalação, o comando é estritamente de leitura:

Reo doctor --json

Os motores de análise nativa

Análise estática de JavaScript, Electron e .NET funciona sem mais nada. Para binários nativos é preciso um motor, e aqui há escolhas com consequências.

O Hopper é software comercial com modo demo. Em macOS, o setup pode descarregar o DMG oficial, verificar tamanho e digest, e instalá-lo em ~/Applications sem pedir privilégios de administrador. Em Linux, verifica o pacote oficial antes de chamar o gestor de pacotes e corre a versão demo num display Xvfb privado. Numa primeira execução em macOS, há um diálogo do Hopper a pedir modo demo ou licença, e tem de ser respondido na mesma sessão de utilizador antes de qualquer trabalho automático.

O Ghidra é o caminho aberto, e é o que eu escolheria, mas o suporte é estreito: Linux x64, com a versão oficial 12.1.4 exacta e um JDK 21 completo. macOS não é host admitido para o Ghidra e o suporte em Windows x64 é experimental. O REA não descarrega nem instala o Ghidra por vocês. Extraem-no, instalam o JDK e exportam os caminhos:

export GHIDRA_INSTALL_DIR=/opt/ghidra_12.1.4_PUBLIC  
export JAVA_HOME=/usr/lib/jvm/jdk-21  
Reo doctor --json  
Rea setup

O IDA é suportado, mas o README é claro: ferramentas comerciais têm de ser obtidas e licenciadas legalmente. Cópias crackadas, chaves partilhadas ou contornar restrições de licença não são autorizados pelo projecto. Gosto que esteja escrito.

Registo manual e firmware

Para um cliente MCP que não seja detectado automaticamente, o registo manual é o habitual:

{  
  "mcpServers": {  
    "rea": {  
      "command": "npx",  
      "args": ["-y", "Rea-Agents@latest", "mcp"]  
    }  
  }  
}

Em produção, ou em qualquer sítio onde queiram resultados reprodutíveis, troquem o @latest por uma versão exacta.

A análise de firmware, que é a parte mais relevante para este post, usa Binwalk 3.1.x para inspecção de regiões e Unblob 26.6.x para extracção. Está verificada em Linux x64 e as ferramentas são vossas, fornecidas por caminho absoluto:

export REA_BINWALK_COMMAND=/usr/local/bin/binwalk  
export REA_UNBLOB_COMMAND=/usr/local/bin/unblob  
Reo inspect-firmware-regions /caminho/firmware.bin  
Reo extract-firmware /caminho/firmware.bin /caminho/nova-pasta --max-depth 3

Não precisa de root, não monta nada, não emula nem executa os programas extraídos. Ficheiros até 128 MiB, prazo de 120 segundos, limites de memória por processo via prlimit, e a pasta de destino nunca é sobrescrita. Depois podem pegar num ELF extraído e passá-lo à análise nativa.

Para manter actualizado, Reo update numa instalação global, ou voltar a correr o setup com @latest se usam npx. Para remover, Reo uninstall tira apenas as registações e ficheiros do próprio REA, e --purge-data limpa também cache e estado.

Um último conselho prático, que o próprio disclaimer sugere: alvos que não conhecem analisam-se num ambiente apropriado. Uma VM descartável, um container sem rede, uma máquina do homelab que não tenha mais nada de valor. Análise estática lê ficheiros; captura em runtime executa coisas com as vossas permissões.

O padrão que querem combater: o hardware sobrevive, o servidor onde o hardware se ligava não

O Car Thing não é um caso isolado. É um género.

Em Abril de 2022, a Insteon, empresa de domótica da Califórnia, desligou os servidores praticamente sem aviso. Hubs, termóstatos e tomadas deixaram de responder à aplicação de um dia para o outro. Houve um final relativamente feliz: um grupo de utilizadores comprou o que restava e voltou a pôr o serviço a funcionar. Mas isso foi sorte, não método.

Em Março de 2024, a Gigaset desligou os servidores da sua linha de casa inteligente depois de um processo de insolvência, porque o comprador não tinha interesse nessa parte do negócio. Os dispositivos dependiam da cloud para tudo, não tinham modo local, e a documentação que existia foi retirada.

A Neato tinha prometido manter a cloud dos seus aspiradores robô até 2028. Em Outubro de 2025 anunciou que a fechava antes do fim desse ano, três anos mais cedo do que o prometido.

E a 31 de Janeiro deste ano, a Belkin desligou a cloud e a aplicação da maior parte da linha Wemo, produzida entre 2011 e 2023. Quem tinha configurado os aparelhos no Apple HomeKit antes dessa data manteve controlo local. Quem não tinha, ficou com tomadas que já não se configuram nem se controlam pela aplicação. Os que ainda estavam em garantia puderam pedir um reembolso parcial. A integração local do Home Assistant, que muita gente já usava com os Wemo fechados numa VLAN sem saída para a internet, ficou como tábua de salvação para os restantes.

Reparem na anatomia, porque é sempre a mesma. Há um aparelho físico com um processador, um firmware e um protocolo de comunicação. Há uma aplicação no telemóvel que fala com uma API. E há um servidor no meio que autentica, guarda configuração, faz de ponte. Quando o servidor desaparece, nenhuma das outras peças avaria. Simplesmente deixam de ter com quem falar.

Para devolver a vida a um aparelho destes, é preciso responder a três perguntas: o que é que o aparelho diz ao servidor, o que é que o servidor lhe responde, e onde é que o firmware decide o que fazer com essa resposta. E estas três perguntas mapeiam quase uma a uma nas capacidades do REA. Capturas de rede e ficheiros HAR mostram o que passa no fio. A descompilação do APK da aplicação oficial mostra a API, os endpoints e o formato das mensagens. A extracção do firmware e a análise nativa do daemon que corre no aparelho mostram a lógica do outro lado. Com isso, constrói-se um servidor substituto local, ou um firmware alternativo, ou uma integração para o Home Assistant.

Isto sempre foi possível. A diferença é sempre o custo.

Até há pouco tempo, este trabalho exigia alguém que soubesse ler assembly ARM, que conhecesse os formatos de firmware, que tivesse paciência para semanas de anotações no Ghidra. Pessoas raras, normalmente a trabalhar de borla nas horas vagas, e por isso só os produtos com comunidades grandes e apaixonadas eram salvos. O Car Thing tinha essa comunidade. A maior parte dos aparelhos não tem.

Um agente com acesso às ferramentas certas não substitui essas pessoas. Mas comprime brutalmente o tempo que demoram, e baixa a fasquia de quem consegue começar. É essa mudança de custo, e não a ferramenta em si, que me parece socialmente relevante.

Há uma nota de honestidade que tenho de deixar aqui. O melhor desfecho possível não é a engenharia reversa. É o fabricante abrir o código. Quando a Google libertou o código do PebbleOS em Janeiro de 2025, o próprio fundador da Pebble, Eric Migicovsky, disse que foi isso que tornou possível o regresso do relógio. E em Novembro de 2025, a nova empresa dele, a Core Devices, publicou a pilha de software inteira e os esquemas eléctricos do Pebble 2 Duo. Antes disso, durante anos, o projecto Rebble manteve vivos os serviços do Pebble reimplementando-os do zero. A engenharia reversa é o plano B. O problema é que, na esmagadora maioria dos casos, não há plano A.

O que a lei europeia já permite, e é mais do que se pensa

Aqui entra a parte que pouca gente conhece e que muda completamente a conversa.

A Directiva 2009/24/CE, a directiva dos programas de computador, tem desde a sua primeira versão de 1991 duas portas abertas para a engenharia reversa. O artigo 5.º permite a quem tem o direito de usar um programa observar, estudar e testar o seu funcionamento para perceber as ideias e princípios que estão por trás de qualquer elemento, desde que o faça enquanto executa operações que está autorizado a executar. E o artigo 6.º permite a descompilação quando ela é indispensável para obter a informação necessária à interoperabilidade de um programa criado de forma independente com outros programas.

O artigo 6.º tem condições. Tem de ser feito por quem tem o direito de usar o programa. A informação não pode estar já facilmente disponível. A descompilação tem de se limitar às partes necessárias para a interoperabilidade. E a informação obtida não pode ser usada para outros fins, nem dada a terceiros a não ser que seja necessário para a interoperabilidade, nem usada para fazer um programa substancialmente semelhante na sua expressão. O artigo 8.º acrescenta um pormenor de ouro: cláusulas contratuais que contrariem estas excepções são nulas. Ou seja, o EULA que diz “proibido fazer engenharia reversa” não vale, nesta parte, o papel em que está escrito.

Em Portugal, isto está no Decreto-Lei n.º 252/94, o regime de protecção jurídica dos programas de computador, que tem um artigo próprio sobre descompilação.

Em Outubro de 2021, o Tribunal de Justiça da União Europeia foi ainda mais longe, no caso Top System contra o Estado belga. Um organismo público belga tinha descompilado parte de um programa licenciado para corrigir erros que afectavam o seu funcionamento. O fornecedor processou-o. O tribunal decidiu que o adquirente legítimo de um programa pode descompilá-lo, total ou parcialmente, para corrigir erros, ao abrigo do artigo 5.º e sem ter de cumprir as condições do artigo 6.º. Com um limite claro: o resultado só pode ser usado para corrigir esses erros.

Juntem as peças. Um aparelho que deixou de funcionar porque o servidor desapareceu tem um problema que é, literalmente, de interoperabilidade: o firmware que lá está precisa de falar com um programa que já não existe, e quem o comprou quer fazê-lo falar com outro, criado de forma independente. É o caso de manual para o artigo 6.º. E é exactamente a palavra que o disclaimer do REA usa.

Mas há um limite que convém dizer em voz alta, porque é onde muita gente tropeça. Contornar medidas técnicas de protecção é outro campeonato. Cifra de firmware, assinaturas que impedem correr código alternativo, verificações de licença: o direito europeu protege essas medidas, e a excepção de interoperabilidade não as varre automaticamente. É precisamente por isso que o REA diz que não ajuda com DRM nem licenças. A ferramenta serve muito bem quando o obstáculo é um protocolo não documentado. Serve pouco, por desenho, quando o obstáculo é um cadeado.

O direito à reparação europeu: parafusos sim, servidores nem sempre

Agora o componente que devia ter mudado neste Verão que acabou á pouco tempo.

A Directiva (UE) 2024/1799, a chamada directiva do direito à reparação, foi aprovada a 13 de Junho de 2024, entrou em vigor a 30 de Julho desse ano, e os Estados-membros tinham até 31 de Julho de 2026 para a transpor e começar a aplicá-la. É de harmonização plena, o que significa pouca margem para cada país inventar.

Em traços largos, faz quatro coisas. Obriga os fabricantes a reparar, fora da garantia, os produtos para os quais o direito europeu já define requisitos de reparabilidade, listados no Anexo II: máquinas de lavar, frigoríficos, ecrãs, aspiradores, smartphones, tablets, e entretanto também aquecedores locais, acrescentados por uma directiva delegada. Proíbe cláusulas contratuais, técnicas de hardware ou de software que impeçam a reparação, salvo justificação objectiva. Estende em doze meses a garantia legal, uma única vez, quando o consumidor escolhe reparar em vez de substituir. E cria um formulário europeu de informação sobre reparação e uma plataforma europeia de reparadores, cuja interface comum a Comissão tem de ter pronta até 31 de Julho de 2027, com funcionamento pleno a partir de 1 de Janeiro de 2028.

Portugal falhou o prazo. No final de Julho, a Zero, a Circular Economy Portugal e a Quercus alertaram publicamente para isso, e a DECO escreveu ao Governo. No fim de Setembro, a Comissão Europeia abriu processos de infracção contra 18 Estados-membros que não tinham notificado a transposição completa, e Portugal está na lista, com uma segunda carta pela directiva delegada dos aquecedores. Há dois meses para responder. À data em que escrevo, não encontrei notícia de que o diploma português tenha sido aprovado. Quem acompanha isto há anos não se surpreende: o painel do mercado interno coloca Portugal com um défice de transposição acima da média europeia, e já houve condenações em milhões de euros por atrasos semelhantes.

E há outras peças em vigor. Desde 20 de Junho de 2025, o regulamento de ecodesign para smartphones e tablets obriga a disponibilizar peças críticas durante sete anos após o fim de vendas de um modelo, entregues em cinco a dez dias úteis, e a manter actualizações de sistema operativo durante pelo menos cinco anos após o último exemplar ser colocado no mercado. Com uma nuance que vale a conhecer: o texto obriga a que, se o fabricante fornecer actualizações, as dê gratuitamente a todas as unidades do modelo durante esse período. A leitura literal não é exactamente “cinco anos de actualizações garantidas”, e já há quem esteja a explorar a diferença.

O Regulamento de Ciber-resiliência acrescenta outra camada: a partir de 11 de Dezembro de 2027, quem vende produtos com elementos digitais na UE terá de declarar um período de suporte de segurança de pelo menos cinco anos, ou o tempo de vida esperado do produto se for mais curto. As obrigações de reporte de vulnerabilidades activamente exploradas aplicam-se desde 11 de Setembro deste ano.

E em Portugal, desde 2022, o Decreto-Lei n.º 84/2021 obriga o produtor a disponibilizar peças sobresselentes durante dez anos após a colocação da última unidade de um bem no mercado. Um prazo que, curiosamente, é mais generoso do que o de muitos regulamentos europeus.

Leiam esta lista outra vez e reparem no que estava a faltar.

Peças, sim. Manuais, sim. Preços razoáveis, sim. Actualizações de segurança durante um período declarado, sim. Mas nenhuma destas peças obriga uma empresa a manter um servidor ligado, nem a publicar o protocolo, nem a libertar as chaves, nem a deixar um modo local a funcionar quando decide acabar com um produto. O Car Thing não tinha um parafuso partido. Tinha um servidor desligado. E para esse tipo de avaria, a lei europeia ainda não tem resposta directa.

A prova mais transparente chegou em Junho. A iniciativa de cidadania europeia Stop Destroying Videogames, nascida da revolta com o fecho dos servidores de The Crew pela Ubisoft, juntou 1 294 188 assinaturas validadas em 24 Estados-membros. Pedia uma coisa simples: que os jogos vendidos na UE ficassem em estado jogável depois de o editor deixar de os suportar. A 16 de Junho de 2026, a Comissão respondeu que, nesta fase, não pode propor uma obrigação legal nesse sentido, e comprometeu-se em alternativa a lançar até ao fim do ano conversas com a indústria para um código de conduta voluntário sobre o fim de vida dos jogos. Os organizadores mudaram imediatamente de alvo e estão agora a tentar que as suas exigências entrem no Digital Fairness Act, que ainda está a ser desenhado.

Não é só sobre jogos. É exactamente o mesmo problema do Wemo, do Car Thing e do Insteon, numa embalagem diferente. E enquanto a resposta política for um código de conduta voluntário, a resposta prática continua a ser a mesma de sempre: alguém, algures, a ler o binário.

E no resto do mundo?

Nos Estados Unidos, o obstáculo central é a secção 1201 do DMCA, que proíbe contornar medidas técnicas de protecção. A válvula de escape é um processo trienal no Copyright Office, que concede isenções temporárias para casos específicos. O nono ciclo terminou em Outubro de 2024 com a renovação de todas as isenções pedidas, incluindo as de reparação de veículos, de dispositivos médicos e de equipamento comercial de preparação de comida (sim, as famosas máquinas de gelados que estavam sempre avariadas). O décimo ciclo já arrancou: as petições tinham de entrar até 24 de Agosto de 2026, e o iFixit, a Public Knowledge e associações de reparadores de equipamento médico pediram a renovação das isenções actuais, que caducam em Outubro de 2027 se nada for feito. É um sistema que funciona, mas que obriga a pedir licença de três em três anos para fazer coisas que deviam ser óbvias.

Sem lei federal, os estados avançaram sozinhos. Em Julho de 2026 eram treze os estados com alguma forma de lei de direito à reparação, e nove deles cobrem electrónica de consumo: Califórnia, Colorado, Connecticut, Kansas, Minnesota, Nova Iorque, Oregon, Texas e Washington. Com as leis do Connecticut e do Texas em vigor desde este Verão, a PIRG estima que mais de um terço dos americanos viva num estado com protecção efectiva. O Oregon e o Colorado foram mais longe e proibiram o chamado parts pairing, a prática de bloquear por software peças originais vindas de outro aparelho. E a Califórnia tem em discussão o Protect Our Games Act, que obrigaria quem vende jogos digitais no estado a garantir uso normal durante três anos depois da última venda. Três anos é pouco, mas é mais do que a Comissão Europeia se dispôs a pedir.

O caso que mais me interessa, porém, é o do Canadá. A 7 de Novembro de 2024, duas leis de iniciativa parlamentar, a C-244 e a C-294, receberam assentimento real e alteraram a lei de direitos de autor canadiana. A primeira permite contornar medidas técnicas de protecção para diagnóstico, manutenção e reparação. A segunda permite contorná-las para tornar um programa ou o aparelho onde ele está embebido interoperável com outro programa, aparelho ou componente. O Canadá legislou, numa frase, exactamente o que a Europa ainda trata com pinças: o direito de abrir o cadeado quando o objectivo é interoperar. Os agricultores canadianos, presos há anos a tractores que só o concessionário podia diagnosticar, foram dos principais motores desta mudança.

Porque é que isto importa para lá do gadget esquecido na nossa gaveta

Seria fácil ler tudo isto como uma conversa de nicho, sobre entusiastas e o seu brinquedo de oitenta dólares. Não é.

Lembram-se da fábrica na Marinha Grande ou em Águeda de que falei no post do CERN? Aquela com um computador ligado a uma máquina de produção de seis dígitos, a correr software de uma empresa que já não existe, em que ninguém quer tocar? Esse é o mesmo problema, com mais zeros. Quando essa máquina precisar de falar com um sistema novo, ou quando a licença do software de controlo deixar de poder ser renovada porque o servidor de activação desapareceu, a escolha vai ser entre deitar fora equipamento que funciona ou perceber, a partir do binário, como é que o software fala com a máquina. A segunda opção é legal ao abrigo do artigo 6.º, e acabou de ficar muito mais barata.

O mesmo vale para equipamento hospitalar, que é precisamente uma das áreas onde as isenções americanas de reparação têm sido mais disputadas. Vale para a agricultura, como os canadianos já perceberam. Vale para o sector público, que compra sistemas com ciclos de contratação mais longos do que o ciclo de vida dos fornecedores. E vale, claro, para o lixo electrónico, porque cada aparelho que morre por decisão administrativa e não por avaria é matéria-prima, energia e emissões deitadas fora sem motivo técnico.

E há a questão que atravessa mais de metade dos posts deste blog: soberania. Um objecto que só funciona enquanto um servidor nos Estados Unidos ou na China responder não é inteiramente nosso. É um contrato de serviço com uma caixa de plástico à volta. Aquilo que a engenharia reversa faz, no fundo, é converter um serviço de volta num objecto. A lei europeia já reconhece que isso é legítimo para fins de interoperabilidade. O que faltava era tornar a capacidade de o fazer acessível a mais do que meia dúzia de especialistas.

É por isso que digo, meio a sério e meio a provocar, que uma ferramenta destas pode valer mais para o direito à reparação do que a directiva que Portugal ainda não transpôs. A directiva cobre os produtos certos, com os fabricantes certos, enquanto o fabricante existir. Quando o fabricante desaparece, quem é que se obriga a reparar? Ninguém. Aí, o único direito à reparação que sobra é o direito de perceber como a coisa funciona, e a capacidade prática de o exercer.

As desvantagens, que existem e são reais

Não tenhamos ideias apenas cor de rosa e achar que isto é um passeio.

Primeiro, a lei não é um cheque em branco. O artigo 6.º tem condições estritas, a excepção do artigo 5.º só cobre correcção de erros, e contornar protecções técnicas é terreno minado. Nos Estados Unidos, a secção 1201 pode transformar um projecto de preservação num problema jurídico. Quem publica o resultado de uma descompilação tem ainda de pensar nos direitos sobre o próprio output. O disclaimer do REA lembra, e bem, que obter algo parecido com código fonte não dá direitos sobre o programa original.

Segundo, o agente pode estar errado. Descompilação, heurísticas e análise assistida por IA podem ser incompletas ou incorrectas, e o projecto diz isso explicitamente. A disciplina de evidências ajuda muito, mas não dispensa alguém que saiba ler o que o agente devolve. Um servidor substituto mal reconstruído pode fazer pior do que nada, sobretudo se mexer com fechaduras, aquecimento ou equipamento médico.

Terceiro, os dados. O REA analisa localmente, mas o vosso agente recebe os resultados, e o fornecedor do modelo tem a sua própria política de dados. O README diz isto com todas as letras. Se estão a analisar firmware de um cliente, código de uma empresa ou capturas de rede com dados pessoais, isso vai parar ao modelo. Quem me lê sabe qual é a minha resposta: modelos locais, ou pelo menos uma conversa séria sobre onde vão parar os dados antes de começar. Um agente que fale MCP local não precisa de estar ligado a um modelo na cloud.

Quarto, o duplo uso é real e não se resolve com um disclaimer. O mesmo fluxo que reconstrói o protocolo de um aspirador abandonado encontra vulnerabilidades num router que ainda está à venda. O mesmo pitch que fala em perceber uma funcionalidade fala em reproduzi-la noutro produto, e a fronteira entre inspirar-se e copiar não é tão clara como o marketing sugere. Baixar o custo da engenharia reversa baixa-o para toda a gente.

Quinto, the lulz do tema. Uma ferramenta que serve para fugir à dependência de fornecedores apoia-se, para a análise nativa mais profunda, em desmontadores comerciais como o Hopper e o IDA. O Ghidra é a alternativa aberta, mas com suporte apenas em Linux x64 e uma versão exacta. E o primeiro marco de firmware ainda não descompila MIPS, PowerPC nem RISC-V, que são precisamente as arquitecturas de muitos routers e aparelhos de domótica baratos. Há caminho para andar.

Sexto, a velocidade. O próprio projecto avisa que muda depressa e que as versões novas trazem correcções frequentes. Centenas de issues e pull requests abertos são sinal de vitalidade, mas também de uma coisa que ainda não estabilizou. Fixem versões e não corram @latest em nada de que dependam.

Sétimo, e talvez o mais importante: reconstruir não é manter. Um servidor substituto precisa de alguém que o mantenha durante anos. A história do Pebble mostra isso melhor do que qualquer teoria: o Rebble manteve os serviços vivos durante quase uma década, e mesmo depois de o código ter sido aberto, houve uma disputa feia sobre dados, licenças e quem pagava o quê, até a Core Devices concordar em pagar vinte cêntimos de dólar por utilizador por mês para sustentar a infraestrutura comunitária. A engenharia reversa resolve o problema técnico de um dia. O problema de sustentabilidade fica.

Mas afinal onde é que isto nos deixa?

Fico com três conclusões práticas, e com uma pergunta.

A primeira é para quem compra. Antes de levar para casa qualquer coisa com Wi-Fi, perguntem se aquilo funciona sem a empresa. Sem a aplicação, sem a cloud, sem conta. Protocolos abertos como Matter, integração local no Home Assistant, firmware que se possa substituir: tudo isso é seguro de vida. Um aparelho que só fala com o servidor do fabricante tem prazo de validade, apenas não vem impresso na caixa.

A segunda é para quem já tem o aparelho, e é a mais útil de todo o post. Se têm em casa algo que depende de uma cloud, gravem o tráfego enquanto o servidor ainda responde. Uma captura de rede do vosso próprio aparelho a falar com o servidor, feita hoje, vale muito mais do que qualquer análise feita depois de o servidor desaparecer, porque depois já não há respostas para observar. Guardem também o firmware e o APK da versão que funciona. Façam-no com o vosso equipamento, na vossa rede, e com atenção aos dados pessoais que vão dentro das capturas. É um backup de interoperabilidade, e custa uma tarde.

A terceira é política. Portugal tem de transpor a directiva, e como sempre já vai tarde. Mas a transposição é a parte fácil, porque a directiva é de harmonização plena e há pouco para decidir. A parte interessante é a medida nacional de promoção da reparação que cada Estado tem de adoptar e comunicar até 2029. Seria uma óptima altura para alguém em Lisboa perceber que reparar também é manter software a funcionar, e que apoiar comunidades de reparação, cafés de reparação e projectos de firmware aberto é política industrial, não caridade. E no Digital Fairness Act, a Europa tem a oportunidade de fazer o que recusou fazer em Junho: obrigar quem desliga um produto a deixar uma porta aberta. Um modo local, a documentação do protocolo, as chaves, o código. Qualquer uma destas coisas chegava para que ninguém precisasse de ler binários para continuar a usar o que comprou.

Até lá, a reparação que a lei ainda não garante vai continuar a ser feita por quem sabe ler o que a empresa não quis explicar. O REA não cria esse direito. Apenas torna mais barato exercê-lo.

A pergunta que deixo é esta: quantos dos aparelhos que têm agora ligados à vossa rede continuariam a funcionar amanhã se o fabricante fechasse hoje? E, para os que não continuariam, quem é que vai fazer o trabalho de os trazer de volta?

Se a resposta for ninguém, isso não é um problema de tecnologia. É um problema de propriedade, e resolve-se antes de acontecer, que é a única altura em que é barato.

Até ao próximo post!
Nuno

Documentação:

O REA

https://github.com/morluto/rea (repositório, README, tabela de alvos suportados e casos de estudo)
https://github.com/morluto/rea/blob/main/docs/installation.md (instalação, setup, Hopper, Ghidra, registo MCP, actualização e remoção)
https://github.com/morluto/rea/blob/main/docs/firmware-analysis.md (análise de firmware com Binwalk e Unblob, limites e verificação)
https://github.com/morluto/rea/blob/main/DISCLAIMER.md (usos permitidos, usos que o projecto recusa, responsabilidade do utilizador)
https://rea.tools/showcase/ (DX-Ball, Notion e TH04)

Aparelhos abandonados e quem os salvou

https://www.androidauthority.com/spotify-car-thing-dead-community-workarounds-3507315/ (o dia em que o Car Thing parou)
https://www.notebookcheck.net/Abandoned-Spotify-Car-Thing-revived-by-free-firmware-that-restores-original-functionality-and-then-some.1085973.html (Nocturne)
https://hifi.fan/stories/mira-1-0-open-source-firmware-revives-discontinued-spotify-car-thing (Mira 1.0)
https://www.belkin.com/support/wemo (o fim da cloud Wemo, contado pelo próprio fabricante)
https://hackaday.com/tag/insteon/ (Insteon)
https://hackaday.com/tag/gigaset/ (Gigaset)
https://9to5mac.com/2025/10/27/neato-cloud-shutdown-is-the-latest-example-of-a-failed-company-bricking-smart-products/ (Neato)
https://www.opensourceforu.com/2025/11/pebble-releases-complete-os-and-schematics-for-community-control/ (Pebble totalmente aberto)
https://512pixels.net/page/10/?page=110 (o conflito entre Rebble e Core Devices)

Lei europeia e portuguesa

https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX:32009L0024 (Directiva 2009/24/CE, artigos 5.º, 6.º e 8.º)
https://www.wiggin.co.uk/?p=17651 (resumo do acórdão Top System, C-13/20)
https://eur-lex.europa.eu/eli/dir/2024/1799/oj (Directiva (UE) 2024/1799, direito à reparação)
https://repair.eu/news/the-right-to-repair-directive/ (o que a directiva faz e não faz, pela Right to Repair Europe)
https://www.eunews.it/en/?p=466091 (os 18 processos de infracção)
https://4gnews.pt/direito-a-reparacao-portugal-falhou-o-prazo-e-comissao-europeia-deixa-serio-aviso/ (Portugal na lista)
https://observador.pt/2026/07/30/ue-ambientalistas-alertam-para-falha-na-transposicao-de-diretiva-sobre-reparacao-de-quipamentos-eletricos/ (o alerta da Zero, CEP e Quercus)
https://tek.sapo.pt/opiniao/artigos/pesquisa-diretiva-transposta-refresh-e-nada/ (o défice de transposição português e a carta da DECO)
https://cms.law/en/knowledge/publications/2026/11/recent-amendments-to-canadian-copyright-act (as leis canadianas C-244 e C-294)

Nota: Este post foi feito com o auxílio de um LLM.# O REA põe um agente de IA a desmontar binários, e isso pode valer mais para o direito à reparação do que a directiva que Portugal ainda não transpôs

Olá a todos!

Prefácio do costume, e hoje com três camadas. A primeira já a conhecem: corro modelos locais, desconfio por defeito de tudo o que só funciona enquanto o servidor de outra pessoa estiver ligado, e tenho uma gaveta com aparelhos em perfeito estado que não servem para nada. A segunda: não sou advogado, e este post fala bastante de lei. Onde cito diplomas, cito-os com o cuidado de quem leu o texto, não com a autoridade de quem o defende em tribunal. A terceira, e esta é a que mais importa: a ferramenta de que vou falar é de duplo uso. Serve para preservar, reparar e tornar coisas interoperáveis, e serve também para coisas que eu não queria ver ninguém a fazer. Vou falar das duas, porque esconder uma das metades é a forma mais rápida de perder a discussão.

Ninguém deu a estas pessoas o código fonte. Tiveram de o ler a partir do binário.

Como Jack diria, vamos por partes.

O que é o REA, sem o marketing

A parte interessante é o que está por baixo. O REA não reinventa o desmontador. Liga o agente a ferramentas que já existem e que quem faz isto há anos conhece bem: Hopper, Ghidra ou IDA para binários nativos, JADX para APKs de Android, Binwalk e Unblob para firmware, TShark para capturas de rede, sigrok para sinais lógicos gravados, adb para dispositivos Android, e mais umas quantas. Por cima disso, acrescenta leitores próprios para formatos onde não precisa de motor externo: aplicações JavaScript e Electron, assemblies .NET, binários Go, WebAssembly, bytecode EVM, bases de dados SQLite, ficheiros HAR de navegador, aplicações Flutter. O Ghidra, via REA, chega a analisar programas de DOS em 16 bits.

E o “com prova” é a parte que me fez levar isto a sério. Cada conclusão que o REA devolve vem acompanhada das evidências em que assenta (endereços, referências cruzadas, digests SHA-256 dos ficheiros analisados, versões das ferramentas usadas) e, sobretudo, das limitações. Quando não sabe, diz que não sabe. Quando uma chamada é computada e não dá para resolver estaticamente, fica marcada como desconhecida em vez de ser adivinhada. Quem já viu um LLM inventar uma função que não existe percebe porque é que isto importa.

Agora a parte de que gosto menos. O pitch oficial do projecto é, em resumo, este: vês uma funcionalidade numa aplicação de que gostas, pedes ao agente que a investigue com o REA, ele explica-te como funciona e constrói uma versão para o teu produto. O exemplo do README é literalmente perceber como funciona a pesquisa na aplicação Notas e fazer uma igual.

Interoperabilidade e preservação. Guardem estas duas palavras, que vão voltar.

Os casos de estudo dizem mais do que o slogan

Se o pitch é sobre copiar funcionalidades, os casos de estudo que o projecto escolheu mostrar são sobre outra coisa. E acho isso revelador.

O terceiro é o Notion, e aqui é uma aplicação Electron moderna: seguir a API de área de transferência do renderer, através do preload e do IPC, até ao processo principal.

Como se instala

A instalação é das coisas mais bem pensadas que vi num projecto deste género, e digo isto como alguém que tem por hábito ler os instaladores antes de os correr.

O ponto de entrada recomendado é este:

npx --yes rea-agents@latest setup

O @latest explícito está lá de propósito: evita que uma dependência de projecto ou uma cache velha do npx escolham a versão do setup por vocês.

Se quiserem o comando rea disponível na shell para uso regular:

npm install --global rea-agents  
Reo --help

Atenção a um detalhe que apanha muita gente: npm install rea-agents sem --global instala o executável apenas no node_modules/.bin do projecto actual. Não fica no PATH.

curl -fsSL https://raw.githubusercontent.com/morluto/rea/main/install.sh | bash -s -- --dry-run

A minha recomendação continua a ser a de sempre: descarreguem o install.sh, leiam-no, e só depois o corram.

Para verificar o estado da instalação, o comando é estritamente de leitura:

Reo doctor --json

Os motores de análise nativa

Análise estática de JavaScript, Electron e .NET funciona sem mais nada. Para binários nativos é preciso um motor, e aqui há escolhas com consequências.

export GHIDRA_INSTALL_DIR=/opt/ghidra_12.1.4_PUBLIC  
export JAVA_HOME=/usr/lib/jvm/jdk-21  
Reo doctor --json  
Rea setup

Registo manual e firmware

Para um cliente MCP que não seja detectado automaticamente, o registo manual é o habitual:

{  
  "mcpServers": {  
    "rea": {  
      "command": "npx",  
      "args": ["-y", "Rea-Agents@latest", "mcp"]  
    }  
  }  
}

Em produção, ou em qualquer sítio onde queiram resultados reprodutíveis, troquem o @latest por uma versão exacta.

export REA_BINWALK_COMMAND=/usr/local/bin/binwalk  
export REA_UNBLOB_COMMAND=/usr/local/bin/unblob  
Reo inspect-firmware-regions /caminho/firmware.bin  
Reo extract-firmware /caminho/firmware.bin /caminho/nova-pasta --max-depth 3

O padrão: o hardware sobrevive, o servidor não

O Car Thing não é um caso isolado. É um género.

A Neato tinha prometido manter a cloud dos seus aspiradores robô até 2028. Em Outubro de 2025 anunciou que a fechava antes do fim desse ano, três anos mais cedo do que o prometido.

Isto sempre foi possível. A diferença é o custo.

O que a lei europeia já permite, e é mais do que se pensa

Aqui entra a parte que quase ninguém conhece e que muda a conversa.

Em Portugal, isto está no Decreto-Lei n.º 252/94, o regime de protecção jurídica dos programas de computador, que tem um artigo próprio sobre descompilação.

O direito à reparação europeu: parafusos sim, servidores nem sempre

Agora a peça que devia ter mudado tudo neste Verão.

Leiam esta lista outra vez e reparem no que falta.

A prova mais clara chegou em Junho. A iniciativa de cidadania europeia Stop Destroying Videogames, nascida da revolta com o fecho dos servidores de The Crew pela Ubisoft, juntou 1 294 188 assinaturas validadas em 24 Estados-membros. Pedia uma coisa simples: que os jogos vendidos na UE ficassem em estado jogável depois de o editor deixar de os suportar. A 16 de Junho de 2026, a Comissão respondeu que, nesta fase, não pode propor uma obrigação legal nesse sentido, e comprometeu-se em alternativa a lançar até ao fim do ano conversas com a indústria para um código de conduta voluntário sobre o fim de vida dos jogos. Os organizadores mudaram imediatamente de alvo e estão agora a tentar que as suas exigências entrem no Digital Fairness Act, que ainda está a ser desenhado.

E no resto do mundo

Porque é que isto importa para lá do gadget na gaveta

Seria fácil ler tudo isto como uma conversa de nicho, sobre entusiastas e o seu brinquedo de oitenta dólares. Não é.

O mesmo vale para equipamento hospitalar, que é precisamente uma das áreas onde as isenções americanas de reparação têm sido mais disputadas. Vale para a agricultura, como os canadianos perceberam. Vale para o sector público, que compra sistemas com ciclos de contratação mais longos do que o ciclo de vida dos fornecedores. E vale, claro, para o lixo electrónico, porque cada aparelho que morre por decisão administrativa e não por avaria é matéria-prima, energia e emissões deitadas fora sem motivo técnico.

E há a questão que atravessa metade dos posts deste blog: soberania. Um objecto que só funciona enquanto um servidor nos Estados Unidos ou na China responder não é inteiramente nosso. É um contrato de serviço com uma caixa de plástico à volta. Aquilo que a engenharia reversa faz, no fundo, é converter um serviço de volta num objecto. A lei europeia já reconhece que isso é legítimo para fins de interoperabilidade. O que faltava era tornar a capacidade de o fazer acessível a mais do que meia dúzia de especialistas.

As desvantagens, que existem e são reais

Não vou fazer de conta que isto é um passeio.

Quinto, uma ironia que não me escapa. Uma ferramenta que serve para fugir à dependência de fornecedores apoia-se, para a análise nativa mais profunda, em desmontadores comerciais como o Hopper e o IDA. O# O REA põe um agente de IA a desmontar binários, e isso pode valer mais para o direito à reparação do que a directiva que Portugal ainda não transpôs

Olá a todos!

Ninguém deu a estas pessoas o código fonte. Tiveram de o ler a partir do binário.

Como Jack diria, vamos por partes.

O que é o REA, sem o marketing

Interoperabilidade e preservação. Guardem estas duas palavras, que vão voltar.

Os casos de estudo dizem mais do que o slogan

Se o pitch é sobre copiar funcionalidades, os casos de estudo que o projecto escolheu mostrar são sobre outra coisa. E acho isso revelador.

O terceiro é o Notion, e aqui é uma aplicação Electron moderna: seguir a API de área de transferência do renderer, através do preload e do IPC, até ao processo principal.

Como se instala

A instalação é das coisas mais bem pensadas que vi num projecto deste género, e digo isto como alguém que tem por hábito ler os instaladores antes de os correr.

O ponto de entrada recomendado é este:

npx --yes rea-agents@latest setup

O @latest explícito está lá de propósito: evita que uma dependência de projecto ou uma cache velha do npx escolham a versão do setup por vocês.

Se quiserem o comando rea disponível na shell para uso regular:

npm install --global rea-agents  
Reo --help

Atenção a um detalhe que apanha muita gente: npm install rea-agents sem --global instala o executável apenas no node_modules/.bin do projecto actual. Não fica no PATH.

curl -fsSL https://raw.githubusercontent.com/morluto/rea/main/install.sh | bash -s -- --dry-run

A minha recomendação continua a ser a de sempre: descarreguem o install.sh, leiam-no, e só depois o corram.

Para verificar o estado da instalação, o comando é estritamente de leitura:

Reo doctor --json

Os motores de análise nativa

Análise estática de JavaScript, Electron e .NET funciona sem mais nada. Para binários nativos é preciso um motor, e aqui há escolhas com consequências.

export GHIDRA_INSTALL_DIR=/opt/ghidra_12.1.4_PUBLIC  
export JAVA_HOME=/usr/lib/jvm/jdk-21  
Reo doctor --json  
Rea setup

Registo manual e firmware

Para um cliente MCP que não seja detectado automaticamente, o registo manual é o habitual:

{  
  "mcpServers": {  
    "rea": {  
      "command": "npx",  
      "args": ["-y", "Rea-Agents@latest", "mcp"]  
    }  
  }  
}

Em produção, ou em qualquer sítio onde queiram resultados reprodutíveis, troquem o @latest por uma versão exacta.

export REA_BINWALK_COMMAND=/usr/local/bin/binwalk  
export REA_UNBLOB_COMMAND=/usr/local/bin/unblob  
Reo inspect-firmware-regions /caminho/firmware.bin  
Reo extract-firmware /caminho/firmware.bin /caminho/nova-pasta --max-depth 3

O padrão: o hardware sobrevive, o servidor não

O Car Thing não é um caso isolado. É um género.

A Neato tinha prometido manter a cloud dos seus aspiradores robô até 2028. Em Outubro de 2025 anunciou que a fechava antes do fim desse ano, três anos mais cedo do que o prometido.

Isto sempre foi possível. A diferença é o custo.

O que a lei europeia já permite, e é mais do que se pensa

Aqui entra a parte que quase ninguém conhece e que muda a conversa.

Em Portugal, isto está no Decreto-Lei n.º 252/94, o regime de protecção jurídica dos programas de computador, que tem um artigo próprio sobre descompilação.

O direito à reparação europeu: parafusos sim, servidores nem sempre

Agora a peça que devia ter mudado tudo neste Verão.

Leiam esta lista outra vez e reparem no que falta.

E no resto do mundo

Porque é que isto importa para lá do gadget na gaveta

Seria fácil ler tudo isto como uma conversa de nicho, sobre entusiastas e o seu brinquedo de oitenta dólares. Não é.

O mesmo vale para equipamento hospitalar, que é precisamente uma das áreas onde as isenções americanas de reparação têm sido mais disputadas. Vale para a agricultura, como os canadianos perceberam. Vale para o sector público, que compra sistemas com ciclos de contratação mais longos do que o ciclo de vida dos fornecedores. E vale, claro, para o lixo electrónico, porque cada aparelho que morre por decisão administrativa e não por avaria é matéria-prima, energia e emissões deitadas fora sem motivo técnico.

As desvantagens, que existem e são reais

Não vou fazer de conta que isto é um passeio.

Quinto, uma ironia que não me escapa. Uma ferramenta que serve para fugir à dependência de fornecedores apoia-se, para a análise nativa mais profunda, em desmontadores comerciais como o Hopper e o IDA. O Ghidra é a alternativa aberta, mas com suporte apenas em Linux x64 e uma versão exacta. E o primeiro marco de firmware ainda não descompila MIPS, PowerPC nem RISC-V, que são precisamente as arquitecturas de muitos routers e aparelhos de domótica baratos. Há caminho para andar.

Onde é que isto nos deixa

Fico com três conclusões práticas, e com uma pergunta.

A terceira é política. Portugal tem de transpor a directiva, e já vai tarde. Mas a transposição é a parte fácil, porque a directiva é de harmonização plena e há pouco para decidir. A parte interessante é a medida nacional de promoção da reparação que cada Estado tem de adoptar e comunicar até 2029. Seria uma óptima altura para alguém em Lisboa perceber que reparar também é manter software a funcionar, e que apoiar comunidades de reparação, cafés de reparação e projectos de firmware aberto é política industrial, não caridade. E no Digital Fairness Act, a Europa tem a oportunidade de fazer o que recusou fazer em Junho: obrigar quem desliga um produto a deixar uma porta aberta. Um modo local, a documentação do protocolo, as chaves, o código. Qualquer uma destas coisas chegava para que ninguém precisasse de ler binários para continuar a usar o que comprou.

Até lá, a reparação que a lei ainda não garante vai continuar a ser feita por quem sabe ler o que a empresa não quis explicar. O REA não cria esse direito. Apenas torna mais barato exercê-lo.

Se a resposta for ninguém, isso não é um problema de tecnologia. É um problema de propriedade, e resolve-se antes de acontecer, que é a única altura em que é barato.

Até ao próximo post!
Nuno

Documentação:

O REA

https://github.com/morluto/rea (repositório, README, tabela de alvos suportados e casos de estudo)
https://github.com/morluto/rea/blob/main/docs/installation.md (instalação, setup, Hopper, Ghidra, registo MCP, actualização e remoção)
https://github.com/morluto/rea/blob/main/docs/firmware-analysis.md (análise de firmware com Binwalk e Unblob, limites e verificação)
https://github.com/morluto/rea/blob/main/DISCLAIMER.md (usos permitidos, usos que o projecto recusa, responsabilidade do utilizador)
https://rea.tools/showcase/ (DX-Ball, Notion e TH04)

Aparelhos abandonados e quem os salvou

https://www.androidauthority.com/spotify-car-thing-dead-community-workarounds-3507315/ (o dia em que o Car Thing parou)
https://www.notebookcheck.net/Abandoned-Spotify-Car-Thing-revived-by-free-firmware-that-restores-original-functionality-and-then-some.1085973.html (Nocturne)
https://hifi.fan/stories/mira-1-0-open-source-firmware-revives-discontinued-spotify-car-thing (Mira 1.0)
https://www.belkin.com/support/wemo (o fim da cloud Wemo, contado pelo próprio fabricante)
https://hackaday.com/tag/insteon/ (Insteon)
https://hackaday.com/tag/gigaset/ (Gigaset)
https://9to5mac.com/2025/10/27/neato-cloud-shutdown-is-the-latest-example-of-a-failed-company-bricking-smart-products/ (Neato)
https://www.opensourceforu.com/2025/11/pebble-releases-complete-os-and-schematics-for-community-control/ (Pebble totalmente aberto)
https://512pixels.net/page/10/?page=110 (o conflito entre Rebble e Core Devices)

Lei europeia e portuguesa

https://eur-lex.europa.eu/legal-content/PT/TXT/?uri=CELEX:32009L0024 (Directiva 2009/24/CE, artigos 5.º, 6.º e 8.º)
https://www.wiggin.co.uk/?p=17651 (resumo do acórdão Top System, C-13/20)
https://eur-lex.europa.eu/eli/dir/2024/1799/oj (Directiva (UE) 2024/1799, direito à reparação)
https://repair.eu/news/the-right-to-repair-directive/ (o que a directiva faz e não faz, pela Right to Repair Europe)
https://www.eunews.it/en/?p=466091 (os 18 processos de infracção)
https://4gnews.pt/direito-a-reparacao-portugal-falhou-o-prazo-e-comissao-europeia-deixa-serio-aviso/ (Portugal na lista)
https://observador.pt/2026/07/30/ue-ambientalistas-alertam-para-falha-na-transposicao-de-diretiva-sobre-reparacao-de-quipamentos-eletricos/ (o alerta da Zero, CEP e Quercus)
https://tek.sapo.pt/opiniao/artigos/pesquisa-diretiva-transposta-refresh-e-nada/ (o défice de transposição português e a carta da DECO)
https://cms.law/en/knowledge/publications/2026/11/recent-amendments-to-canadian-copyright-act (as leis canadianas C-244 e C-294)

Nota: Este post foi feito com o auxílio de um LLM privado.

O que é o REA, sem o marketing

Quando os case studies dizem mais que a publicidade

Como se instala

Os motores de análise nativa

Registo manual e firmware

O padrão que querem combater: o hardware sobrevive, o servidor onde o hardware se ligava não

O que a lei europeia já permite, e é mais do que se pensa

O direito à reparação europeu: parafusos sim, servidores nem sempre

E no resto do mundo?

Porque é que isto importa para lá do gadget esquecido na nossa gaveta

As desvantagens, que existem e são reais

Mas afinal onde é que isto nos deixa?

O que é o REA, sem o marketing

Os casos de estudo dizem mais do que o slogan

Como se instala

Os motores de análise nativa

Registo manual e firmware

O padrão: o hardware sobrevive, o servidor não

O que a lei europeia já permite, e é mais do que se pensa

O direito à reparação europeu: parafusos sim, servidores nem sempre

E no resto do mundo

Porque é que isto importa para lá do gadget na gaveta

As desvantagens, que existem e são reais

O que é o REA, sem o marketing

Os casos de estudo dizem mais do que o slogan

Como se instala

Os motores de análise nativa

Registo manual e firmware

O padrão: o hardware sobrevive, o servidor não

O que a lei europeia já permite, e é mais do que se pensa

O direito à reparação europeu: parafusos sim, servidores nem sempre

E no resto do mundo

Porque é que isto importa para lá do gadget na gaveta

As desvantagens, que existem e são reais

Onde é que isto nos deixa

Related Posts

O modelo é um insider: porque é que o Satya Nadella quer que confiemos menos na IA

DCM – Docker Compose Maker: Template everything!

Uma mulher na Florida usava o Claude como diário, e uma das entradas foi parar à polícia: um chatbot não é um caderno, tem leitores que tu não escolheste