Ok, das hat mich kurz erwischt: Ein Framework, das die klassischen Disassembler, Ghidra, Hopper, IDA, mit einem Coding-Agenten verbindet. Man zeigt auf eine Funktion in einer fremden App, die Datenbank-Ansicht, ein Interface-Element, und der Agent analysiert, wie sie funktioniert, und baut sie in eigenem Code nach. Ohne Quellcode. Lokal auf dem Rechner. Es heisst „Reverse Engineer Anything", und der Name ist nicht einmal übertrieben. Ich finde das heftig. Nicht weil es neu wäre. Weil es nichts mehr kostet.
Was das Werkzeug tut
Der Ansatz ist klug, weil er klein denkt. Nicht die ganze Anwendung zerlegen, sondern eine Funktion isolieren. Man benutzt das Feature in der App, damit es sichtbar ist, dann lässt man die Werkzeuge den Binärcode, die Aufrufe und die Datenflüsse dazu einsammeln, und der Agent übersetzt das in etwas, das ein Mensch lesen kann: So funktioniert das, das sind die Schnittstellen, das sind die Schritte. Daraus entsteht eine Spezifikation, und aus der Spezifikation eigener Code. Eine Funktion nach der anderen. Mit der Anweisung, Belege zu liefern statt Vermutungen, und mit dem Hinweis, das Ganze lokal laufen zu lassen, damit nichts das Haus verlässt.
Ich habe den Artikel gelesen, nicht das Repo ausprobiert. Also nehme ich die Demo als das, was sie ist: eine Demo. Aber die Bausteine kenne ich alle, und sie funktionieren einzeln. Dass sie zusammen funktionieren, ist für mich keine Frage mehr, nur noch eine Frage der Reichweite.
Wie es funktioniert, in fünf Schritten
Am Rande, für die, die es technisch wissen wollen. Nichts davon ist Zauberei, es ist die Arbeit, die ein Reverse Engineer früher von Hand gemacht hat, nur aufgeteilt zwischen Werkzeug und Agent.
Die Funktion auslösen. Man startet die App und benutzt genau das Feature, das man verstehen will. Dabei schaut ein Tracer zu: welche Funktionen im Binärcode laufen, welche Aufrufe ins System gehen, was über das Netz geht, was auf die Platte geschrieben wird. Das grenzt ein. Von Millionen Zeilen bleiben die paar hundert, die wirklich mit dem Feature zu tun haben.
Den Code lesbar machen. Ein Disassembler wie Ghidra nimmt die Binärdatei und übersetzt die Maschinenbefehle zurück in etwas, das aussieht wie Code: Funktionen, Variablen, Aufrufgraphen, mit erfundenen Namen, weil die echten beim Kompilieren verloren gingen. Das war früher der Teil, für den man Jahre Erfahrung brauchte, um darin etwas zu erkennen.
Dem Agenten nur den Ausschnitt geben. Nicht die ganze Anwendung, nur die Funktionen aus Schritt eins, in der Form aus Schritt zwei, plus die beobachteten Aufrufe. Das ist der kluge Teil des Frameworks: Der Agent bekommt wenig Kontext und eine klare Frage, und genau so arbeiten Modelle am besten. Ich habe beim MCP-Artikel beschrieben, warum.
Beschreiben mit Belegen. Der Agent schreibt auf, was die Funktion tut: Eingabe, Ausgabe, Zwischenschritte, welche Daten sie liest, welche Schnittstellen sie ruft. Und zu jeder Aussage die Stelle im zerlegten Code oder den beobachteten Aufruf, aus dem sie kommt. Ohne diesen Beleg ist die Beschreibung eine Vermutung, mit ihm ist sie eine Spezifikation.
Neu bauen und gegen das Verhalten testen. Aus der Spezifikation entsteht eigener Code, in der Sprache, die man will. Und dann der Teil, den viele weglassen: dieselben Eingaben wie in Schritt eins, und prüfen, ob dieselben Ausgaben kommen. Wenn nicht, war die Beschreibung falsch, nicht der Code.
Was daran neu ist, und was nicht
Reverse Engineering gibt es seit Jahrzehnten. Ich habe selber Protokolle nachgebaut, weil die Dokumentation fehlte, und Binärdateien gelesen, weil der Hersteller nicht mehr existierte. Es war immer möglich. Es war nur teuer: Spezialisten, Wochen, Werkzeuge mit einer Lernkurve wie eine Wand. Diese Kosten waren der Schutz. Nicht das Recht, nicht die Verschlüsselung. Die Kosten.
Das ist dieselbe Bewegung wie beim Code selber. Ich habe geschrieben, dass Code billig wird und Wissen nicht. Hier wird jetzt auch das Lesen von fremdem Code billig. Und damit fällt ein Schutz, von dem viele nicht wussten, dass sie ihn hatten.
Wen es trifft
Nicht alle gleich. Es trifft die Firmen, deren Vorsprung aus einem Feature besteht, das man sehen kann. Die hübsche Datenbank-Ansicht, der clevere Export, die eine Funktion, für die Leute das Abo bezahlen. Wenn ein Agent die an einem Nachmittag analysiert und nachbaut, ist der Vorsprung ein Nachmittag. Das Abo-Modell für kleine Werkzeuge, das auf „wir haben dieses eine Feature" beruht, steht damit unter Druck, und zwar nicht von grossen Konkurrenten, sondern von jedem einzelnen Kunden, der es sich selber bauen kann.
Es trifft nicht die Firmen, deren Wert woanders liegt. Dazu gleich. Aber es trifft auch die Sicherheit, und das ist der Teil, den der Artikel nur streift: Wer eine Funktion verstehen kann, kann auch ihre Schwachstelle verstehen. Dieselbe Kostensenkung gilt für den Angreifer. Das ist kein Argument gegen das Werkzeug, Angreifer hatten die Spezialisten schon immer. Es ist ein Argument dafür, Sicherheit nicht mehr auf „das versteht sowieso niemand" zu bauen. Das war schon immer eine schlechte Idee. Jetzt ist es eine falsche.
Wo es nicht funktioniert
Ich will das nicht grösser machen, als es ist. Vier Grenzen, die ich sehe, aus Erfahrung mit genau dieser Arbeit.
Das Backend. Was auf dem Server passiert, sieht der Agent nicht. Er sieht die Anfrage und die Antwort. Die Logik dazwischen, die Geschäftsregeln, die Daten, auf denen sie beruhen, bleiben unsichtbar. Für die meisten ernsthaften Anwendungen ist das der Teil, der zählt.
Das, was nicht im Code steht. Warum die Funktion so gebaut ist. Welche Sonderfälle aus zehn Jahren Kundenbetrieb drinstecken. Der Agent baut nach, was er sieht. Er baut nicht nach, was jemand gelernt hat. Das ist das Prozesswissen, über das ich bei „Mensch mal KI" geschrieben habe, und es ist nicht in der Binärdatei.
Die Belege. Der Artikel sagt richtig: Immer nach Belegen fragen. Ich sage: Das reicht nicht. Ein Agent, der eine Funktion falsch versteht und sie trotzdem plausibel nachbaut, liefert Code, der aussieht wie das Original und sich anders verhält. Das merkt man nicht beim Lesen. Das merkt man beim Kunden.
„Lokal" ist nicht automatisch privat. Das Werkzeug läuft lokal. Der Agent dahinter ruft ein Modell in der Cloud. Was er analysiert, geht zum Modell. Wer fremde Software untersucht, um seine eigene zu schützen, schickt dabei vielleicht gerade seine eigene mit. Lokal heisst nur dann lokal, wenn auch das Modell lokal ist.
Was ich damit machen würde
Ich sehe eine Verwendung, die mich wirklich interessiert, und sie hat nichts mit fremder Software zu tun. Fast jede Firma, mit der ich arbeite, hat Altsysteme, die niemand mehr versteht. Der Hersteller ist weg, der Entwickler ist pensioniert, der Quellcode ist da, aber er erklärt nichts, oder er ist nicht da, und die Binärdatei läuft seit zwölf Jahren, weil niemand sich traut, sie anzufassen. Das ist das System, bei dem alle sagen: Das können wir nicht ablösen, wir wissen nicht, was es tut.
Genau dort würde ich so einen Agenten einsetzen. Nicht um nachzubauen, sondern um zu verstehen: Funktion für Funktion eine Spezifikation erzeugen, mit Belegen, welche Eingabe zu welcher Ausgabe führt, welche Schnittstellen angesprochen werden, welche Sonderfälle im Code stecken. Dann hat man zum ersten Mal seit zwölf Jahren eine Beschreibung dessen, was das Ding tut. Und erst dann, mit Menschen, die die Sonderfälle einordnen können, baut man neu.
Das ist die Idee, die ich für NeoCoder prüfen will: ein Software-Understanding-Agent für eigene Altsysteme. Mit zwei Dingen, die das Framework aus dem Artikel nicht hat. Erstens eine Rechteprüfung vorneweg: Der Agent arbeitet nur an Systemen, für die ein Nachweis vorliegt, dass sie uns oder dem Kunden gehören. Nicht als Prompt, als Gate. Zweitens die Belege als Kette: Jede Aussage in der Spezifikation zeigt auf die Stelle im Code oder den beobachteten Aufruf, aus dem sie kommt. So wie bei uns alles belegt sein muss. Ein Agent, der mir erklärt, was ein Altsystem tut, ohne zu zeigen, woher er das weiss, ist ein Agent, der rät.
Was ich nicht damit machen würde
Fremde Produkte nachbauen, um sie zu verkaufen. Und hier muss ich genau sein, weil der Reflex „das ist verboten" zu kurz greift. Was der Agent hier macht, ist kein Kopieren von Code. Er schaut, was eine Funktion tut, und baut sie neu, in eigenem Code, vielleicht in einer anderen Sprache. Das Urheberrecht schützt den Code, nicht die Idee und nicht die Funktion, das habe ich beim Urheberrecht beschrieben, und ein sauberer Neubau nach beobachtetem Verhalten ist seit Jahrzehnten eine bekannte und oft erlaubte Praxis. Ich bin kein Jurist. Aber so viel weiss ich: Es ist nicht automatisch verboten, und es ist auch nicht automatisch erlaubt. Dazwischen liegen Lizenzbedingungen, die das Zerlegen oft untersagen, Patente auf einzelne Verfahren, Marken, Geschäftsgeheimnisse, und die Frage, ob der Agent beim Analysieren nicht doch Stücke des Originals mitgenommen hat. Wer das gewerblich tut, braucht jemanden, der das prüft. Darum würde ich es nicht tun. Und zweitens, weil es nichts bringt. Wer ein Feature nachbaut, hat ein Feature. Er hat nicht die Kunden, nicht das Wissen, nicht die zwölf Jahre Sonderfälle. Ich habe beim Urheberrecht geschrieben, was ein Softwareunternehmen in Zukunft noch verkauft: Architektur, Entscheidungen, Verständnis, Pflege. Keines davon kann man aus einer Binärdatei ziehen.
Was dein Code in fünf Jahren wert ist
Und damit zur Frage, die mich am meisten beschäftigt, weil sie über das Werkzeug hinausgeht. Wenn ein Agent fremde Software verstehen, nachbauen und dann verbessern kann, was ist der reine Quellcode eines Softwareunternehmens in fünf Jahren noch wert?
Ich glaube: wenig. Er war schon vorher nicht das, was man dachte, ich habe das beim Urheberrecht beschrieben: Rein maschinell erzeugter Code gehört niemandem, und zwei Firmen mit demselben Modell bekommen dieselbe Software. Jetzt kommt dazu, dass auch von Menschen geschriebener Code nachgebaut werden kann, von jedem, an einem Nachmittag. Was bleibt, ist dasselbe wie dort: das Wissen, warum es so gebaut ist, die Leute, die es erklären können, und die Fähigkeit, es über Jahre weiterzuentwickeln, ohne dass es kippt. Das ist der Film, nicht das Foto. Ein Agent mit Disassembler sieht ein sehr gutes Foto.
Was bleibt
Das Werkzeug ist heftig, und es ist da. Ich würde es für das eine benutzen, wofür es wirklich gut ist: eigene Altsysteme verstehen, die niemand mehr versteht, mit Belegen, mit Rechteprüfung, mit Menschen, die danach die Sonderfälle einordnen. Ich würde es nicht benutzen, um fremde Produkte nachzubauen, nicht weil es automatisch verboten wäre, sondern weil die Grauzone gross ist und weil es nichts bringt. Und ich würde aufhören, Quellcode als Vorsprung zu betrachten. Das war er schon lange nicht mehr. Jetzt merkt man es nur.
Reverse Engineering gab es immer, der Preis war der Schutz, und der Preis ist weg. Wen es trifft: Firmen, deren Vorsprung ein sichtbares Feature ist. Wen nicht: Firmen, deren Wert im Wissen um das System liegt. Ich würde das Werkzeug auf unsere eigenen Altsysteme richten, mit Belegen und Rechteprüfung, und auf nichts anderes. Der Code war nie der Schatz. Das Verstehen ist es.
Quelle: Julian Horsey, „Pair REA with Claude Code to Analyze Apps Without Source Code", Geeky Gadgets, 22. Oktober 2026, über das Framework „Reverse Engineer Anything" von Zinho Automates. Gelesen, nicht ausprobiert. geeky-gadgets.com
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.