Die Produktmanager, die sich gestern noch gegenseitig heftig angefeindet haben, wurden heute alle von REA zu Mitstreitern gezwungen.

Die Produktmanager verschiedener Apps stehen sich stets unversöhnlich gegenüber: „Deine UI ist Müll“, „Diese Interaktion ist für Menschen gemacht?“, „Du nimmst eine pseudo-benutzerzentrierte Perspektive und vertrittst die gesamte Nutzerbasis mit Einzelfällen weniger Nutzer.“

Doch als REA populär wurde, schlossen sich diese Produktmanager sofort zu einer gemeinsamen Front zusammen und richteten sich gemeinsam gegen REA.

Produkte sind das Lebenselixier dieser Produktmanager. Mit REA sind die Schutzbarrieren dieser Produkte fast vollständig verschwunden.

Der französische Technik-Blogger Korben hat REA mit Opus 5.5 praktisch getestet.

Er ließ den Agenten den Pseudocode eines selbst geschriebenen Crackme-Programms lesen. Nach etwa 2 Minuten erstellte der Agent einen Python-Keygen, der die Überprüfung bestand, wobei die API-Kosten nur etwa 0,5 US-Dollar betrugen. Anschließend überprüfte er dies mit 479 zufälligen Benutzernamen – alle bestanden die Prüfung.

Die Umsetzung einer Funktion von Anforderungsdefinition, Terminplanung, Entwicklung, Test bis zur Veröffentlichung dauert oft mehrere Wochen oder sogar Monate. Doch REA kann sie in wenigen Minuten dekompilieren – das ist für niemanden hinnehmbar.

Wie genau wird gegen REA vorgegangen?

Da REA alle gängigen Reverse-Engineering-Programme auf dem Markt kombiniert mit KI umfasst, kann keine Produktdesignweise eine 100-prozentige Sicherheit vor Dekompilierung garantieren.

Da man es nicht aufhalten kann, begannen die Produktmanager, sich zusammenzuschließen und nach Lösungen zu suchen.

Die einfachste und effektivste Maßnahme besteht darin, keine Schlüssel und versteckten Schnittstellen auf der Client-Seite zu hinterlegen.

Früher haben viele Produkte Dinge, die „der Nutzer sowieso nicht sieht“, in das Installationspaket gepackt. Dazu gehörten fest eingebaute Schlüssel, interne Schnittstellen, nur auf der Client-Seite durchgeführte Berechtigungsüberprüfungen und Mitgliedschaftsstatus, die über das Frontend ermittelt werden. Diese Dinge sind vor REA praktisch „nackt“.

Elias Bachaalany, einer der Autoren des Reverse-Engineering-Lehrbuchs Practical Reverse Engineering, erklärte, dass die einzig zuverlässige Methode darin besteht, die kritische Logik auf den Server zu verlagern.

Daher haben diese Produktmanager nach Elias' Methode die wertvollen Komponenten von der Client-Seite verlagert.

Insbesondere werden Vertrauensentscheidungen zurück auf die Serverseite verlagert. Ob ein Nutzer bezahlt hat, ob er auf eine bestimmte Funktion zugreifen darf und ob die aktuelle Anfrage rechtmäßig ist, wird nicht mehr vom Client bestimmt, sondern jedes Mal vom Server abgefragt.

Anschließend verlagerten die Produktmanager die Kernlogik in die Cloud. Empfehlungsalgorithmen, Preisstrategien, Risikokontrollregeln und kritische Datenverarbeitungsvorgänge sorgen dafür, dass der Client nur das Ergebnis erhält, nicht aber den Ablauf.

Zusammengenommen führen diese drei Schritte dazu, dass der Client allmählich zu einer „nur aus Oberfläche bestehenden Hülle“ wird. Die Hülle kann zerlegt und nachgeahmt werden, aber sie enthält keine Inhalte.

Aber es gibt Szenarien, die nicht in die Cloud verlagert werden können, wie eingebettete Geräte und Spiele, die nur lokal ausgeführt werden können.

Daher begannen die Produktmanager, über eine zweite Lösung nachzudenken: Sie versehen den Code mit Packern, Obfuskation, virtualisiertem Schutz und Anti-Debugging-Maßnahmen, sodass das erste, was REA beim Reverse Engineering erhält, „falsch“ ist.

Obwohl REA am Ende das vollständige Produkt reverse engineeren kann, wird der gesamte Reverse-Engineering-Prozess dadurch aufwendiger.

Einige Hersteller haben dieses Geschäft auch erkannt. Nach dem Aufstieg von REA veröffentlichte Thales Sentinel Envelope Plus, das offiziell als Schutzlösung speziell für KI-gestütztes Reverse Engineering bezeichnet wird. Es kann ohne Änderung des Quellcodes mehrschichtige Anti-Dekompilierungs-, Manipulationsschutz- und Laufzeitpräventionsmaßnahmen für bestimmte Teile der Anwendung durchführen.

Thales veröffentlichte zudem eine Reihe kontrollierter Tests: Bei ungeschützten Anwendungen fand der KI-Agent 8 von 10 Schwachstellen; nach Hinzufügung des Schutzes fand der Agent keine einzige, der Token-Verbrauch betrug das 970-fache des vorherigen Werts, und schließlich schlug der Agent selbst vor, die Analyse abzubrechen.

Neben der Verstärkung des Produktschutzes tauschen die Produktmanager auch Methoden untereinander aus und haben auf Discord einen Anti-REA-Kanal erstellt, um Produktmanagern, die nicht wissen, wie sie mit REA umgehen sollen, entsprechende Verfahren zu vermitteln.

Am häufigsten wird der im August veröffentlichte Artikel des Sicherheitsunternehmens Quarkslab mit dem Titel Defeating AI-Assisted Reverse Engineering (or at Least Trying To) zitiert.

Die zentrale Erkenntnis dieses Artikels lautet: Moderne Obfuskation kann die Ergebnisse der Dekompilierung strukturell plausibel erscheinen lassen, ohne dass sie das tatsächliche Verhalten des Programms widerspiegeln. Dadurch wird die KI von dem „einfachen Pfad“ abgebracht und gelangt zu scheinbar plausiblen, aber falschen Schlussfolgerungen.

Das Interessanteste an diesem Ansatz ist: Früher diente die Obfuskation dazu, dass Menschen den Code „nicht verstehen“ – heute ist es wichtiger, dass die KI ihn „falsch versteht“.

Wenn ein Agent auf ein völlig unverständliches Programm stößt, gibt er ehrlich zu, dass er es nicht versteht. Doch eine scheinbar logische, falsche Antwort ist die beste Methode, um KI zu bekämpfen, da der Agent nicht anhalten wird, um sie zu hinterfragen.

Die „gemeinsame Front“ der Produktmanager ist eher ein Ausdruck der Notwendigkeit. Letztendlich kann niemand seinen Client vollständig vor Reverse Engineering schützen – man kann nur den Prozess verlangsamen und die Kosten für das Reverse Engineering erhöhen.

Anschließend folgen Zweifel und Beschimpfungen

Nach dem REA-Rausch bleibt nur ein Chaos zurück.

Nachdem REA viral ging, bewertete Elias es als „Hype“. Die Beweise aus der Community zeigen, dass die Anzahl der Sterne bei REA viel schneller gestiegen ist als die Anzahl der Downloads – es handelt sich um sogenannte „Drive-by-Stars“, bei denen Nutzer den Stern setzen, das Tool aber nie wirklich nutzen.

Anschließend listete Elias eine Reihe bereits lange existierender ähnlicher Tools auf. Elias erklärte, dass Tools wie GhidraMCP und IDA Pro MCP bereits 2025 KI-gestützte Reverse-Engineering-Analysen ermöglichen.

Duncan Ogilvie, Autor des IDA Pro MCP-Plugins und Entwickler des x64dbg-Debuggers, hat die Aufgaben des diesjährigen Flare-On Reverse Engineering Wettbewerbs in etwa einer Stunde gelöst, wobei er ausschließlich IDA Pro MCP nutzte. Das bedeutet, dass es auf dem Markt bereits bessere Reverse-Engineering-Plugins als REA gab.

Doch der Vorteil von REA liegt darin, dass es selbst keine Dekompilierung durchführt, sondern die Orchestrierung übernimmt. Es lässt den Agenten die Reverse-Engineering-Tools wie Ghidra, IDA und Hopper aufrufen, erhält die Ergebnisse und schreibt dann Code und führt Tests durch. Dabei sind es nach wie vor diese etablierten Tools in Kombination mit großen Sprachmodellen, die die eigentliche Reverse-Engineering-Analyse des Ziels durchführen.

Bei praktischen Tests sind die Bewertungen uneinheitlich. Bei Korbens Test haben sowohl REA als auch die Lösung ohne REA, bei der Claude direkt mit Ghidra zusammenarbeitet, alle vier Tests abgeschlossen. REA war bei einigen Projekten schneller, beim Patch-Test hingegen langsamer.

Es gibt noch ein leicht zu übersehendes Detail. Ein praktischer Testartikel auf der DEV Community vom 19. Oktober zeigt, dass nach Aufzeichnung der für die REA-Reverse-Engineering-Analyse erforderlichen Umgebungen Abhängigkeiten wie Ghidra und JDK vom Nutzer selbst bereitgestellt werden müssen.

Im Vergleich zu diesen sachlichen Zweifeln gibt es in der Community unabhängiger Entwickler hauptsächlich reine Beschimpfungen. Die Entwicklungseffizienz unabhängiger Entwickler ist weitaus geringer als die von Unternehmens-Teams: Die Entwicklungszyklen von Unternehmensprodukten betragen in der Regel 2 bis 3 Monate, während viele Projekte unabhängiger Entwickler über Jahre hinweg verfeinert werden.

Wenn REA diese in wenigen Minuten kopieren könnte, würden sie natürlich leicht zusammenbrechen.

Am 10. Oktober erschien im Forum für unabhängige Entwickler im Ausland ein viraler Beitrag mit dem Titel Fxxking Hate the whole new trends of „Reverse Engineer Anything“, was grob bedeutet „Ich hasse diesen neuen Trend von ‚REA‘ von ganzem Herzen“.

Der Beitrag enthält keine Argumente, sondern nur reine Beschimpfungen. Auch die Antworten unter dem Beitrag sind voll von Beschimpfungen – die unabhängigen Entwickler nutzten ihn als Ventil für ihre Emotionen.

Anschließend wurde der gesamte Beitrag gelöscht, da er praktisch zu einem Wörterbuch englischer Schimpfwörter geworden war.

Die wütenden unabhängigen Entwickler haben keine Rechts- und Sicherheitsteams großer Unternehmen und kein Budget, um Schutzlösungen wie die von Thales zu erwerben. Sobald ihre Werke reverse-engineered werden, sind Monate oder sogar Jahre harter Arbeit umsonst.

Experten sagen, dass es nichts Neues ist und nur Hype ist, während normale Menschen der Meinung sind, dass es alles verändert hat.

Mitten in diesem Widerspruch geschieht etwas noch Schlimmeres.

Es gibt bereits Trojaner, die sich als REA ausgeben

Jedes virale Open-Source-Projekt zieht fast Nachahmer an. Beispielsweise gab es nach dem Aufstieg von OpenClaw hunderte von Personen auf GitHub, die das OpenClaw-Repository nachahmten, um Nutzer zum Klicken zu bewegen und denjenigen, die das falsche OpenClaw-Repository herunterladen, Viren zu injizieren.

REA ist keine Ausnahme.

Am 10. Oktober tauchte eine GitHub-Organisation namens rea-tools auf. Dieser Name ahmt bewusst die offizielle Website von REA rea.tools nach, sodass man auf den ersten Blick glaubt, es handele sich um einen weiteren offiziellen Eingang.

Die Nachahmer kopieren das gesamte offizielle README und fügen nur einen Abschnitt mit der Downloadangabe für die „unabhängige Windows-.exe/GUI“ hinzu, die auf ein Release namens „rea-agents: v6.3.0“ verweist.

Das offizielle README von REA enthält überhaupt keine Installationspakete. Zwar wurde in Issue 2136 des offiziellen Repositorys darüber diskutiert, ob eine Ein-Klick-Installationsversion erstellt werden soll, aber das ist nur ein Plan des REA-Autors und wurde nie veröffentlicht.

Das Release der REA-Nachahmer enthält ein 82,6 MB großes Archiv namens rea-x64.7z. Microsoft Defender stuft das Archiv als Trojan:Script/Wacatac.B!ml ein, und die extrahierte rea-x64.exe als Trojan:Win32/Wacatac.B!ml. Auf VirusTotal schlagen 8 von 45 Engines Alarm.

Als der Vorfall gemeldet wurde, wurde diese Datei bereits 172 Mal heruntergeladen. Vergessen Sie nicht, dass sich dieser Virus weiterverbreiten kann – der Schaden, den die Nachahmer verursachen, ist also weitaus größer als die bisher bekannten 172 Downloads.

Am 13. Oktober haben die Betreuer von REA über PR 2429 eine Warnung in das README aufgenommen und klar festgelegt, dass nur drei Eingänge als offiziell anerkannt werden: github.com/morluto/rea, rea.tools und das npm-Paket rea-agents. Sie betonten zudem, dass „ähnliche Repository-Namen oder kopierte READMEs kein Beweis dafür sind, dass der Download offiziell ist“.

Wie das Sprichwort sagt: Die Gesetze sind da, wo sie gebrochen werden. Bis heute tauchen auf GitHub immer wieder Repositorys auf, die REA nachahmen.

Es ist nicht überraschend, dass die Nachahmer REA ausgewählt haben.

Erstens ist die Vorgehensweise bereits erprobt. Wie bereits erwähnt, wurde ein ähnliches Vorgehen schon beim Aufstieg von OpenClaw angewendet. Es ist also nicht verwunderlich, dass sich jetzt bei REA ähnliche Vorfälle ereignen.

Zweitens der Zeitpunkt: Die Popularität von REA ist innerhalb weniger Tage um 100.000 Sterne gestiegen. Man braucht nicht einmal den Namen „REA“ selbst – man kann schon Traffic abgreifen, wenn man nur in der Nähe dieses Namens bleibt.

Drittens bieten die Nachahmer den „Komfort“, den die offizielle Version nicht bietet. Viele Nutzer kommen aufgrund des guten Rufs, wollen aber nicht selbst Ghidra und JDK konfigurieren. Die Angabe „Windows-Installationspaket“ trifft genau ihren Bedarf.

Viertens, und das ist der kritischste Punkt: Die Nutzergruppe von REA besteht ohnehin aus Personen, die mit Agenten arbeiten. Sie kennen MCP, führen npx aus und erteilen Agenten Berechtigungen. Während der Installation von REA wird es in die Konfiguration des Agenten registriert, und der Agent selbst verfügt über Shell-, Datei- und Netzwerkberechtigungen.

Das führt dazu, dass die Viren, die über REA verbreitet werden, weitaus zerstörerischer sind als gewöhnliche Viren im Internet.

Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „Letter AI“, Autor: Miao Zheng, und wird mit Genehmigung von 36Kr veröffentlicht.