REA zebrało 300 tysięcy gwiazdek w dwa tygodnie. Najcenniejsza jest w nim lista tego, czego nie wie

Projekt REA, czyli Reverse Engineer Anything, opiera się na jednym zdaniu. Zobacz funkcję, która ci się podoba, i zrozum, jak działa, aż do poziomu binarki. W październiku to zdanie zrobiło z mało znanego repozytorium najszybciej rosnący projekt na GitHubie. Pod hasłem „koniec oprogramowania” kryje się jednak uczciwe i przydatne narzędzie o dość wąskim zadaniu.

Od 41 do 360 tysięcy gwiazdek w trzy tygodnie

Repozytorium morluto/rea powstało 14 kwietnia 2026 roku i przez pół roku prawie nikt go nie zauważył. Według danych GH Archive zebranych przez Moe Luekera 2 października miało 41 gwiazdek. Tydzień później ponad 45 tysięcy, a 12 października przybyło niemal 52 tysiące w ciągu jednego dnia. Na 22 października GitHub pokazuje ponad 365 tysięcy gwiazdek i 91 tysięcy forków. Pakiet instalacyjny rea-agents miał według npm w najlepsze dni ponad 100 tysięcy pobrań dziennie. Ludzie naprawdę go uruchamiali.

Lawinę uruchomiły media społecznościowe. 8 października Matthew Berman napisał na X: „Reverse Engineer Anything 😂 Software is done.” Wpis ma 2,8 miliona wyświetleń. Potem przyszły filmy z milionami odsłon oraz chińskie i japońskie wątki, które ogłosiły repozytorium najgorętszym na GitHubie. Fireship dorzucił film „Every app on Earth is now open source”. Ten jednak mówi głównie o klonach aplikacji Adobe, które powstały inaczej i REA nie potrzebowały. Obie historie i tak zlały się w jedno wrażenie: zamknięte oprogramowanie przestało być zamknięte.

Autor występuje jako morluto, a jego prawdziwe nazwisko nie zostało ujawnione. Projekt otwarcie powstaje z pomocą agentów. AgentBreaking naliczył od początku października do 12 października 263 commity z Claude Opus 5.5 podpisanym jako współautor. W osiem dni projekt przeskoczył z wersji 3.2.1 do 6.4.0, a dziś dostępna jest 6.7.0.

Dekompilację wciąż robi Ghidra. REA dodaje dowody

REA nie ma własnego dekompilatora. Przy programach natywnych steruje Ghidrą, Hopperem albo IDA, które już masz. Do tego analizuje JavaScript i Electron, .NET, aplikacje na Androida, firmware, strony internetowe i zapisy ruchu sieciowego. Agent dostaje w ten sposób około 140 narzędzi przez jeden serwer MCP, a instalacja to jedno polecenie npx rea-agents setup.

Nowością nie jest więc to, że AI potrafi sterować Ghidrą. GhidraMCP i ida-pro-mcp robią to od marca 2025 roku. Nowe jest opakowanie, a przede wszystkim forma odpowiedzi. Każde ustalenie niesie dowód, skąd pochodzi, a agent zapisuje też to, czego nie udało się ustalić. Zamiast przekonującego domysłu powstaje lista niewiadomych. Przy narzędziu, które czyta kod maszynowy, to ważniejsza cecha niż liczba obsługiwanych formatów.

Sam projekt pokazuje wyniki precyzyjne, ale małe. W grze DX-Ball z 1996 roku agent przepisał do C obliczanie panoramy dźwięku stereo. Wynik przeszedł 3205 testów względem oryginalnego kodu x86 i zgadza się we wszystkich 63 bajtach skompilowanej funkcji. Całego programu nikt jednak nie odtworzył i README tego nie obiecuje. REA zwraca pseudokod, asembler i powiązania między modułami, a nie oryginalne źródła.

Niezależny test: na małych programach agent nie potrzebował REA

9 października serwis GitTested porównał agenta z REA i agenta ze zwykłymi narzędziami, takimi jak objdump. Testowano cztery małe binarki bez symboli i trzy aplikacje w Electronie. Odpowiedzi oceniano według faktów spisanych wcześniej z prawdziwych źródeł. Przy programach natywnych agent bez REA zdobył 74 z 75 punktów, a z REA 73 z 75. Zużył przy tym mniej więcej 2,5 razy więcej tokenów. Recenzenci zalecają więc ostrożność: kod, który agent przeczyta sam, nie potrzebuje pomocy REA.

Podobnie wypadł wiralowy pokaz. Użytkownik @AIWarper napisał, że REA z Opusem zdekompilował kupioną grę ze Steama i w 30 minut uruchomił ją w Unity. W odpowiedziach pytano, czy to był build Mono. Takie gry zawierają kod pośredni C#, który darmowe narzędzia dekompilują od dwudziestu lat. Odpowiedź w wątku nie padła. Kolejną granicę stawia model, a nie narzędzie. Kilku użytkowników opisało, że Claude odmówił dalszej pracy, na przykład przy protokole cudzej baterii.

Fałszywa kopia z trojanem i granica prawa

Sukces przyciągnął też oszustów. Według przeglądu Pasquale Pillitteriego 13 października pojawiła się kopia repozytorium pod organizacją rea-tools. Do skopiowanego README dodała sekcję z osobnym plikiem .exe dla Windows. Do czasu zgłoszenia archiwum pobrano 172 razy, a Microsoft Defender oznaczył je jako trojana z rodziny Wacatac. Oficjalne README ostrzega teraz, że podobna nazwa ani skopiowany tekst niczego nie dowodzą. REA należy pobierać tylko z github.com/morluto/rea, z rea.tools albo z pakietu rea-agents na npm.

Nawet prawdziwa wersja nie jest piaskownicą, co wprost zapisano w jej dokumentacji bezpieczeństwa. Instalacja zmienia konfigurację wszystkich wybranych agentów. Analiza w czasie działania uruchamia badany program z twoimi uprawnieniami. A zależności zmieniają się codziennie, więc warto przypiąć konkretną wersję.

Prawnie najważniejsze jest to, czyj program rozbierasz. W UE dyrektywa 2009/24/WE pozwala dekompilować program, gdy jest to niezbędne dla interoperacyjności, a potrzebne informacje nie są dostępne inaczej. Umowa nie może tego prawa wyłączyć. Napisanie na tej podstawie programu zasadniczo podobnego do oryginału jest już jednak niedozwolone. Zastrzeżenia REA zabraniają obchodzenia DRM i kontroli licencji. Marketing projektu kusi przy tym hasłem „zbuduj podobną funkcję we własnym produkcie”. Właśnie tej szarej strefy boją się na Reddicie niezależni twórcy gier.

Werdykt Lilith

REA to dobre narzędzie, które stało się memem. Gwiazdki mierzą wiralowość, nie audyt, a najlepsza jest w nim skromna lista rzeczy, których nie wie. Kto musi zobaczyć, co program naprawdę robi, niech odpali go w maszynie wirtualnej na własnej aplikacji i z przypiętą wersją. Kto chciał „po prostu sklonować cokolwiek”, dostanie głównie pseudokod i rachunek za tokeny.