---
title: "REA AI-Reverse-Engineering: Prinzip und Leistungsgrenzen"
locale: de
category: knowledge_base
category_name: "Wissensdatenbank"
translation_status: reviewed
license: cc_by
author: "injoys"
source_url: https://injoys.com/en/articles/rea-ai-reverse-engineering-performance-and-limits
published_at: 2026-10-19T05:55:51+09:00
---

# REA AI-Reverse-Engineering: Prinzip und Leistungsgrenzen

> REA verbindet AI-Agenten mit Reverse-Engineering-Werkzeugen, um das Verhalten von Software zu untersuchen. Der Beitrag unterscheidet zwischen dem Prüfumfang öffentlicher Fallbeispiele und den Grenzen der Serveranalyse. Außerdem erläutert er Sicherheit, Urheberrecht und die Reproduzierbarkeit der Analyseergebnisse.

## Key Points

- REA verbindet AI-Agenten über MCP mit Reverse-Engineering-Werkzeugen, damit sie diese aufrufen können.
- Das Verhalten einer ausführbaren Datei zu verstehen, ist etwas anderes, als den ursprünglichen Quellcode wiederherzustellen.
- Der veröffentlichte DX-Ball-Fall zeigt das Prüfergebnis für eine bestimmte Funktion. Er bedeutet nicht, dass das gesamte Spiel wiederhergestellt wurde.
- Servercode oder nicht öffentlich zugängliche Modelle, die nicht in der App enthalten sind, lassen sich nicht allein durch die Analyse der App beschaffen.
- Für Analyseergebnisse müssen Belege und ungeprüfte Bereiche dokumentiert und das Verhalten mit dem Original verglichen werden.

REA verbindet KI mit Reverse-Engineering-Werkzeugen, damit sie diese aufrufen und das Verhalten von Apps untersuchen kann. Die veröffentlichten Beispiele zeigen, dass sich bestimmte Funktionen analysieren und möglicherweise neu implementieren lassen. Sie sind weder ein Beleg für das Ende der Softwarebranche noch für die vollständige Kopierbarkeit eines Dienstes.

Die Angaben zur Überprüfung von DX-Ball beziehen sich auf die Verlaufsaufzeichnung des offiziellen Fallbeispiels vom 7. Oktober 2026.

## Was ist REA?

REA steht für Reverse Engineer Anything. Das Projekt verbindet Softwareanalyse-Werkzeuge mit KI-Agenten. Es ist kein einzelnes KI-Modell, das sämtliche Analysen selbst durchführt.

Beim Reverse Engineering werden Struktur und Verhalten fertiger Software untersucht. Ziel ist es, die Informationen zu ermitteln, die nötig sind, um Funktionen zu erklären oder Kompatibilität herzustellen.

Bei der Kompilierung wird von Menschen geschriebener Code in eine ausführbare Form umgewandelt. Dabei können Kommentare und manche Informationen zu Namen verloren gehen. Durch Optimierung können sich auch Funktionen und Berechnungen in ihrer Form verändern.

Allerdings bleibt nicht von jeder App nur namenloser Maschinencode übrig. Manche ausgelieferten Programme enthalten JavaScript-Code oder Debugging-Informationen. Die Analysemethode hängt daher vom Dateiformat und den verbliebenen Informationen ab.

| Begriff | Einfache Erklärung | Worauf bei der Bewertung der Ergebnisse zu achten ist |
| --- | --- | --- |
| Disassemblierung | Maschinencode als Assemblerbefehle darstellen | Der Zweck der Befehle muss zusätzlich interpretiert werden |
| Dekompilierung | Ausführbaren Code in einer quellcodeähnlichen Form darstellen | Keine Garantie, dass diese dem ursprünglichen Quellcode entspricht |
| Statische Analyse | Dateien untersuchen, ohne das Programm auszuführen | Von den tatsächlichen Ausführungspfaden unterscheiden |
| Dynamische Analyse | Das Programm ausführen und sein Verhalten beobachten | Verhalten außerhalb der beobachteten Bedingungen bleibt ungeprüft |
| Neuimplementierung | Ermitteltes Verhalten in neuem Code umsetzen | Vergleichende Überprüfung mit dem Original erforderlich |

## Wie werden KI und Ghidra verbunden?

REA übermittelt Analyseanfragen eines Agenten über MCP an Werkzeuge. MCP ist ein Verbindungsstandard, über den KI und externe Werkzeuge Anfragen und Ergebnisse austauschen. Ghidra ist ein Reverse-Engineering-Werkzeug zur Untersuchung ausführbarer Dateien.

Die offizielle README beschreibt neben Ghidra auch die Anbindung von Hopper und IDA. Für die statische Analyse von JavaScript ist keine native Analyse-Engine erforderlich. REA allein als automatisierte Bedienung von Ghidra zu beschreiben, würde seinen Funktionsumfang daher zu eng fassen.

Die Analyse läuft üblicherweise in dieser Reihenfolge ab:

1. Die zu untersuchende App und Funktion festlegen.
2. Anhand von Zeichenketten oder Funktionsaufrufen die relevanten Stellen finden.
3. Befehlen und Datenflüssen folgen, um das Verhalten zu interpretieren.
4. Fehlende Belege durch weitere Werkzeugaufrufe prüfen.
5. Das neu implementierte Ergebnis mit dem Verhalten des Originals vergleichen.

Auch Ghidra verfügt bereits über Funktionen zur automatischen Analyse. REA ermöglicht es einem Agenten, Analyseanfragen fortlaufend zu stellen. Wie genau die Ergebnisse tatsächlich sind, hängt vom Untersuchungsobjekt, der Analyse-Engine, dem Modell und der Prüfmethode ab.

## Analyseumfang je nach Bedingungen

Was sich mit REA überprüfen lässt, hängt von den zugänglichen Dateien und der Ausführungsumgebung ab. Eine lokale App kann Code für die Kommunikation mit einem Server enthalten. Das bedeutet nicht, dass dieser Code auch die interne Implementierung des Servers enthält.

| Analyseobjekt | Was überprüft werden kann | Was sich allein aus der Analyse nicht sicher ableiten lässt |
| --- | --- | --- |
| Lokale ausführbare Datei | Berechnungen, Zeichenketten, Beziehungen zwischen Funktionsaufrufen | Sämtliche ursprünglichen Kommentare und Entwurfsabsichten |
| JavaScript- und Electron-App | Modulstruktur, Verbindung zwischen Oberfläche und interner Verarbeitung | Verarbeitungslogik, die nur auf dem Server vorhanden ist |
| Webseite und Kommunikationsprotokolle | Heruntergeladene Skripte, beobachtete Anfragen und Antworten | Gesamter Serverquellcode und gesamte Datenbank |
| Lokal enthaltene Modelldatei | Struktur und Informationen der zugänglichen Datei | Nicht öffentliches Modell, das nur auf dem Server verwendet wird |
| Zur Laufzeit beobachtete Funktion | Verhalten bei den betreffenden Eingaben und in der betreffenden Umgebung | Verhalten bei allen Eingaben und Fehlerbedingungen |

Für die Neuimplementierung eines Dienstes müssen auch Anforderungen außerhalb der beobachteten Funktionen berücksichtigt werden. Dazu gehören etwa das Verhalten bei Kontoberechtigungen und die Fehlerbehandlung. Selbst wenn eine Oberfläche ähnlich funktioniert, lässt sich daraus nicht schließen, dass der gesamte Dienst gleich ist.

## Was das Taschenrechnerexperiment von 8 Minuten und 41 Sekunden belegt

Die Angabe von 8 Minuten und 41 Sekunden ist eine Behauptung zu einer Vorführung, deren Originalaufzeichnung nicht überprüft wurde. Die dazu genannte Zahl der Werkzeugaufrufe beträgt 17. Auch die Behauptung, vier Rechenregeln gefunden zu haben, konnte nicht unabhängig überprüft werden.

Die Versuchsbedingungen müssten anhand des Originalvideos und der Ausführungsprotokolle überprüft werden. Die benötigte Zeit variiert je nach Modell und Programmgröße. Aus einem einzelnen Erfolg lässt sich weder die allgemeine Analysegeschwindigkeit noch die Genauigkeit beurteilen.

Bei der Analyse eines Taschenrechners reicht es zur Überprüfung nicht aus, Formeln zu lesen. Die Reihenfolge, in der Rabatt und Gutschein angewendet werden, kann das Ergebnis verändern. Auch das Abschneiden bei ganzzahliger Division muss gesondert geprüft werden.

- Reihenfolge der Anwendung von Rabatt und Gutschein
- Betrag, auf dessen Grundlage die Steuer berechnet wird
- Stelle, an der Zwischenergebnisse gerundet oder abgeschnitten werden
- Ausgabe an Grenzwerten, bei denen sich Bedingungen ändern
- Vergleichsprotokolle mit denselben Eingaben für Original und neu implementierten Code

Um eine schnelle Analyse zu belegen, braucht es auch Aufzeichnungen jenseits der erfolgreichen Antwort. Fehlgeschlagene Ausführungen und die Zahl der erneuten Versuche beeinflussen den Vergleich. Die bisher überprüften Belege reichen nicht für eine allgemeine Bewertung aus, wonach das System Menschen überlegen sei.

## In veröffentlichten Beispielen belegte Ergebnisse

Die offiziellen Fallbeispiele zeigen den Zwischenablagepfad von Notion und eine Berechnungsfunktion von DX-Ball. Beide benennen den Umfang der untersuchten Funktion. Dabei ist auch zu berücksichtigen, dass die Aufzeichnungen vom REA-Projekt selbst veröffentlicht wurden.

| Beispiel | In den veröffentlichten Dokumenten belegte Arbeit | Was daraus nicht abgeleitet werden darf |
| --- | --- | --- |
| Notion Desktop 7.6.1 | Den Pfad von einem internen App-Aufruf bis zur Systemzwischenablage nachverfolgt | Kopie des gesamten Notion-Dienstes |
| DX-Ball 1.07 | Funktion neu implementiert, die eine Bildschirmposition in Audiowerte für links und rechts umwandelt | Abgeschlossene Rekonstruktion des gesamten Spiels |
| Schlanke Ersatz-App für Razer Synapse | Bei dieser Prüfung keine konkreten Aufzeichnungen zur Überprüfung am Original gefunden | Als offiziell überprüftes Ergebnis von REA einstufen |
| Folieneditor im Zusammenhang mit Claude | Bei dieser Prüfung Untersuchungsobjekt und Umfang der Neuimplementierung nicht geklärt | Als Rekonstruktion eines nicht öffentlichen Modells von Claude deuten |

Das Notion-Beispiel verfolgt, wie ein Aufruf von der Oberfläche aus die interne Kommunikation durchläuft. Am Ende führt der Pfad zur Funktion von Electron, die in die Zwischenablage schreibt. Das Beispiel erklärt damit den Verarbeitungsweg einer bestimmten Funktion.

Im DX-Ball-Beispiel wurden Funktionseingaben und Berechnungskonstanten anhand der ausführbaren Datei überprüft. Für die betreffende Funktion wurden **3.205 Vergleichstests** durchgeführt. Das Kompilierungsergebnis stimmte unter Berücksichtigung der geprüften Relokationsbehandlung in 63 Bytes überein.

Diese Aufzeichnungen stützen die Neuimplementierung einer bestimmten Funktion. Laut offizieller Dokumentation wird noch an einer lauffähigen Rekonstruktion des gesamten Spiels gearbeitet. Die Überprüfung einzelner Funktionen ist von der Fertigstellung des gesamten Produkts zu unterscheiden.

## Was gewährleisten Kennzeichnungen für Beobachtungen und Schlussfolgerungen?

Belegkennzeichnungen dienen dazu, die Herkunft einer Schlussfolgerung erkennbar zu machen. Die REA-Dokumentation unterscheidet Beobachtungen, Schlussfolgerungen und ungeprüfte Informationen. Allerdings verwenden nicht alle Werkzeuge dieselben vier Kennzeichnungen.

In den offiziellen Dokumenten erscheinen je nach Analyseart unterschiedliche Status- und Vertrauensangaben. Beim Lesen hilft es, die Bedeutungen wie folgt zu unterscheiden. Die Einteilung in der Tabelle dient der Erläuterung.

| Kategorie | Bedeutung | Was zu prüfen ist |
| --- | --- | --- |
| Beobachtung | Direkt anhand einer Datei oder eines Ausführungsergebnisses überprüft | Version des Untersuchungsobjekts und Fundstelle |
| Ableitung | Aus beobachteten Werten und Zusammenhängen berechnetes Ergebnis | Rechenweg und Annahmen |
| Vermutung | Interpretation, die weiterer Überprüfung bedarf | Möglichkeit anderer Erklärungen |
| Ungeprüft | Bereich, für den kein Beleg gesichert werden konnte | Untersuchungsumfang und Grund für die fehlgeschlagene Überprüfung |

Die offizielle DISCLAIMER.md nennt die Grenzen der Analyseergebnisse ausdrücklich.

> Dekompilierung, Rekonstruktion, Heuristiken und KI-gestützte Analysen können unvollständig oder falsch sein.
>
> Quelle: REA DISCLAIMER.md

Das bedeutet, dass Dekompilierung und KI-Analysen unvollständig oder falsch sein können. Auch eine als Beobachtung gekennzeichnete Aussage schließt Werkzeugfehler nicht aus. Der Wert einer Belegkennzeichnung liegt darin, die Stelle für eine erneute Prüfung festzuhalten.

## Häufige Fehler

Ein besonders häufiges Missverständnis besteht darin, ein nachvollziehbar erklärtes Ergebnis als vollständig überprüft anzusehen. Gut lesbarer Code kann sich anders verhalten als das Original. Nicht untersuchte Pfade müssen gesondert ausgewiesen werden.

| Missverständnis | Genauere Einordnung |
| --- | --- |
| Durch Dekompilierung erhält man den ursprünglichen Quellcode zurück | Oft erhält man eine quellcodeähnliche Darstellung |
| Im Code gibt es einen Pfad, also wurde er tatsächlich ausgeführt | Ein statisch erkennbarer Zusammenhang ist keine Beobachtung zur Laufzeit |
| Die Funktion wurde nicht gefunden, also gibt es sie nicht | Der Untersuchungsumfang oder die Werkzeugunterstützung kann unzureichend sein |
| Das Werkzeug wurde erfolgreich beendet, also ist die Analyse vollständig | Auch bei einem erfolgreichen Ergebnis können ungeprüfte Punkte bleiben |
| Das Ergebnis hat Belege, also gibt es keine Halluzinationen | Belege und Interpretation müssen gemeinsam geprüft werden |

Auch die CLI-Dokumentation von REA unterscheidet zwischen erfolgreichem Abschluss und vollständiger Analyse. Selbst nach Abschluss einer Aufgabe können Belege oder Fragen offenbleiben. Prüfen Sie statt der Abschlussmeldung die Einschränkungen des Ergebnisses.

## Aufzeichnungen, mit denen sich Analyseergebnisse erneut prüfen lassen

Zu einer reproduzierbaren Analyse gehören auch die Bedingungen, unter denen die Schlussfolgerungen gewonnen wurden. Selbst bei derselben App kann sich der Code durch Updates ändern. Wird nur die Adresse einer Funktion notiert, lässt sich das Untersuchungsobjekt in einer anderen Version schwer wiederfinden.

Die Evidence-Aufzeichnungen von REA bewahren Identifikationsdaten des Untersuchungsobjekts und Fundstellen der Belege auf. Snapshots ermöglichen es, Analyseergebnisse wiederzuverwenden, wenn die Bedingungen übereinstimmen. Ein gespeichertes Ergebnis bedeutet nicht, dass auch die neueste Version überprüft wurde.

Gehen Sie beim Festhalten der Überprüfung wie folgt vor:

1. Notieren Sie Version und Hash der untersuchten Datei.
2. Halten Sie die Versionen von REA und der Analyse-Engine fest.
3. Verknüpfen Sie jede Schlussfolgerung mit einer Dateiposition oder Funktionsadresse.
4. Bewahren Sie die Ein- und Ausgaben des Originals und des neu implementierten Codes gemeinsam auf.
5. Notieren Sie nicht untersuchte Bedingungen und fehlgeschlagene Tests gesondert.

Ein Hash ist ein Identifikationswert, mit dem sich feststellen lässt, ob Dateien gleich sind. Wenn er festgehalten wird, lässt sich nachvollziehen, auf welche ausgelieferte Version sich eine Beschreibung bezieht. Auch wenn eine KI das Ergebnis später zitiert, kann so sein Geltungsbereich abgegrenzt werden.

## Lokale Analyse und externe Datenübertragung

Eine lokale Analyse schließt nicht aus, dass bei der gesamten Arbeit Daten nach außen übertragen werden. Laut der offiziellen README erfolgt die Analyse des Untersuchungsobjekts durch REA lokal. Die Werkzeugergebnisse erhält der verbundene KI-Agent.

Wird ein externes Modell verwendet, können Analyseergebnisse an dessen Anbieter übermittelt werden. Welche Datenrichtlinien gelten, hängt vom verbundenen Dienst ab. Prüfen Sie bei Unternehmens-Apps oder nicht öffentlichen Dateien zuerst die Übertragungswege.

- Umfang des Codes und der Zeichenketten, die an das Modell übermittelt werden
- Kontodaten und Zugriffstoken in Protokollen
- Personenbezogene Daten in Kommunikationsprotokollen
- Speicherort und Aufbewahrungsrichtlinien für Analyseergebnisse

Auch die statische Untersuchung einer Datei ist von der Ausführung eines Programms zu unterscheiden. Beobachtungen zur Laufzeit können Dateien oder den Zustand eines Kontos beeinflussen. Behandeln Sie nicht vertrauenswürdige Programme in einer isolierten Testumgebung.

## Sicherheit und Rechte: Was Entwickler prüfen sollten

In eine App eingebettete Geheimnisse können durch Reverse Engineering offengelegt werden. OWASP beschreibt das Problem sensibler Informationen in ausgelieferten Paketen. Dieses Risiko bestand schon vor REA.

Insbesondere dürfen keine geheimen API-Schlüssel mit Serverberechtigungen in eine App aufgenommen werden. OWASP empfiehlt, statische Geheimnisse auf dem Server zu belassen. Obfuskation kann das Auslesen erschweren, gewährleistet aber keine Geheimhaltung.

- Prüfen Sie ausgelieferte Dateien auf enthaltene Passwörter und geheime Schlüssel.
- Begrenzen Sie Berechtigungen und Gültigkeitsdauer von Authentifizierungstoken.
- Überprüfen Sie die Berechtigungen der anfragenden Person auf dem Server.
- Ersetzen Sie offengelegte Zugangsdaten.

Welche Formen des Reverse Engineering zulässig sind, hängt vom Land, von Verträgen und von der konkreten Tätigkeit ab. Dass ein Vorhaben der Kompatibilität dient, bedeutet nicht, dass jede Handlung erlaubt ist. Analyse und Weiterverbreitung von Code oder Bildern müssen getrennt geprüft werden.

Die MIT-Lizenz von REA gewährt keine Rechte am untersuchten Objekt. Die Nutzungsgrundsätze des Projekts stehen in der offiziellen DISCLAIMER.md. Prüfen Sie die tatsächlichen Grenzen anhand des anwendbaren Rechts und der Bedingungen der untersuchten Software.

## Was verändert sich für die Softwarebranche?

REA zeigt, dass sich der Aufwand für das Verständnis bestehender Funktionen möglicherweise verringern lässt. Diese Einschätzung lässt sich aus den veröffentlichten Analysebeispielen ableiten. Über das Ausmaß einer Kostensenkung in der gesamten Branche liegen keine bestätigten Zahlen vor.

Selbst wenn die Implementierung einzelner Funktionen bekannt ist, ist der Betrieb eines Dienstes eine andere Aufgabe. Datenqualität und Störungsbehebung lassen sich nicht allein durch die Analyse einer ausführbaren Datei kopieren. Deshalb müssen die Leichtigkeit der Nachahmung von Funktionen und die Wettbewerbsfähigkeit eines Unternehmens getrennt bewertet werden.

| Geschäftsaspekt | Schlussfolgerung aus dem Analyseumfang von REA |
| --- | --- |
| Einzelne Funktion innerhalb einer App | Untersuchung der Implementierung und Neuimplementierung könnten weniger Aufwand erfordern |
| Verarbeitung ausschließlich auf dem Server | Durch Client-Analyse allein schwer zu erschließen |
| Daten und Zugriffsrechte | Müssen unabhängig vom Codeverständnis beschafft und verwaltet werden |
| Stabilität und zuverlässiger Betrieb | Tests, Wartung und Störungsbehebung bleiben erforderlich |
| Erhaltung bestehender Software | Rekonstruktion ist von kleinen Funktionen aus möglich, wenn Belege festgehalten werden |

Die veröffentlichten REA-Beispiele zeigen eine Veränderung darin, wie Software verstanden werden kann. Sie belegen nicht, dass der Bedarf an Entwicklung verschwindet. Auch nach der Neuimplementierung einer Funktion müssen Kompatibilität und Betriebsqualität überprüft werden.

## FAQ

### Ist REA ein eigenes KI-Modell?
REA ist ein Projekt, das KI-Agenten mit Softwareanalysewerkzeugen verbindet. Analyseanfragen und Ergebnisse können über MCP übermittelt werden.

### Brauche ich für REA unbedingt Ghidra?
Das hängt vom Analysegegenstand ab. Für die Analyse nativer Programme wird eine Engine wie Ghidra verwendet. Die statische Analyse von JavaScript ist ohne eine solche Engine möglich.

### Stellt REA den ursprünglichen Quellcode exakt wieder her?
Eine identische Wiederherstellung des ursprünglichen Quellcodes ist nicht garantiert. Bei der Kompilierung können Kommentare oder Informationen über Namen verloren gehen. Das Ergebnis der Dekompilierung sollte als Darstellung gelesen werden, die zum Verständnis der Funktionsweise dient.

### Kann ich durch die Analyse einer App auch den Servercode erhalten?
Servercode, der nicht in der App enthalten ist, lässt sich nicht allein durch die Analyse der App erhalten. Anfragen und Antworten bei der Kommunikation lassen sich beobachten. Diese Aufzeichnungen zeigen jedoch nicht die gesamte interne Implementierung des Servers.

### Kann man in 8 Minuten und 41 Sekunden auch andere Programme analysieren?
Für eine solche Verallgemeinerung gibt es keine Grundlage. Auch die Originalaufzeichnung der betreffenden Taschenrechner-Demonstration konnte nicht überprüft werden. Die benötigte Zeit hängt von der Größe des Analysegegenstands, dem Modell und der Analyseumgebung ab.

### Beseitigt REA KI-Halluzinationen?
Halluzinationen verschwinden dadurch nicht. Wenn Belege und ungeklärte Punkte kenntlich gemacht werden, lassen sich Schlussfolgerungen leichter erneut prüfen. Werkzeugergebnisse und die Interpretation der KI müssen getrennt überprüft werden.

### Wurde im Fall von DX-Ball das gesamte Spiel rekonstruiert?
Die zitierten Zahlen stammen aus der Überprüfung einer bestimmten Funktion zur Audioberechnung. Die offizielle Fallstudie beschreibt 3,205 Vergleichstests. Sie stellt klar, dass die lauffähige Rekonstruktion des gesamten Spiels noch im Gange ist.

### Werden alle Analysen mit REA offline durchgeführt?
Die Analyse des Untersuchungsgegenstands mit REA erfolgt lokal. Der Agent, der die Werkzeugergebnisse empfängt, kann ein externes Modell verwenden. Welche Daten insgesamt übertragen werden, muss beim angebundenen Dienst geprüft werden.

### Darf ich Code, den ich mit REA analysiert habe, in ein kommerzielles Produkt übernehmen?
Allein der Erhalt von Analyseergebnissen begründet kein Nutzungsrecht. Die Rechte und Lizenzen der untersuchten Software müssen geprüft werden. Prüfen Sie auch das anwendbare Recht und die Nutzungsbedingungen der Analysewerkzeuge.

### Wenn REA Open Source ist, ist dann auch die Analyse kostenlos?
Die Lizenz des REA-Codes und die Gesamtkosten der Arbeit sind voneinander zu unterscheiden. Für das angebundene Modell oder kommerzielle Analysewerkzeuge können Kosten anfallen. Die Beträge können Sie den Preisen und Nutzungsbedingungen der jeweiligen Anbieter entnehmen.

### Was muss ich dokumentieren, wenn ich Analyseergebnisse zitieren möchte?
Dokumentieren Sie die Version des Analysegegenstands, den Datei-Hash und die Fundstellen der Belege. Auch die Version der Analysewerkzeuge und die Ergebnisse von Vergleichstests sind erforderlich. Wenn Sie ungeprüfte Bedingungen ebenfalls festhalten, lässt sich der Geltungsbereich der Schlussfolgerungen abgrenzen.

## Sources

- [README des offiziellen REA-Repositorys: Funktionsweise, unterstützte Ziele, lokale Analyse und Richtlinien für Modelldaten](https://github.com/morluto/rea)
- [Offizielle Ghidra-Schulungsunterlagen: Introduction to Ghidra](https://ghidra.re/ghidra_docs/GhidraClass/Beginner/Introduction_to_Ghidra_Student_Guide.html)
- [Offizielles REA-Fallbeispiel: Analyse des Electron-Zwischenablagepfads von Notion](https://rea.tools/showcase/notion/)
- [Offizielles REA-Fallbeispiel: Neuimplementierung der Berechnung der Klangposition in DX-Ball und vergleichende Validierung](https://rea.tools/showcase/dx-ball/)
- [REA Tool Design: Unterscheidung zwischen Beobachtung, Ableitung, Schlussfolgerung und Einschränkungen](https://github.com/morluto/rea/blob/main/docs/tool-design.md)
- [REA JavaScript Application Graph: Belege, Status, Vertrauensgrad und Zielposition](https://github.com/morluto/rea/blob/main/docs/javascript-application-graph.md)
- [REA JavaScript Application Workflows: Unterscheidung zwischen statischen Beziehungen und Überprüfung durch Ausführung](https://github.com/morluto/rea/blob/main/docs/javascript-application-workflows.md)
- [REA CLI and Evidence: Aufbewahrung von Aufzeichnungen, Snapshots und Exit-Status](https://raw.githubusercontent.com/morluto/rea/main/docs/cli.md)
- [REA Disclaimer: Grenzen der Analyse, Nutzungsberechtigung und Rechte an den Ergebnissen](https://raw.githubusercontent.com/morluto/rea/main/DISCLAIMER.md)
- [OWASP MASWE-0004: Sensible Informationen im App-Paket und Gegenmaßnahmen](https://mas.owasp.org/MASWE-0004/)

## Images

![Ein Entwickler vergleicht Ball-und-Schläger-Tests auf zwei Tablets neben einem Laptop.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6Mjk5NzksInB1ciI6ImJsb2JfaWQifX0=--2b1213d9736d5cae1ff35ed8e5e7db570784612e/ai-ab7036b9.webp)
![Ein Ingenieur im dunkelgrauen Pullover zieht ein blaues Netzwerkkabel aus einem kompakten Computer.](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6Mjk5ODUsInB1ciI6ImJsb2JfaWQifX0=--1f2adeb39e8cbbe1342eb9e3c6b1d619bea6e20f/ai-ccb48b79.webp)