iris/iris-plugins
1
0
Fork 0
Code Issues 17 Pull requests Projects Releases Packages Wiki Activity Actions

iris-ghidra: Installation scheitert mit Ghidra 12.2 (JDK 25, LE/LX-Loader kompiliert nicht) #367

New issue
Open
opened 2026-11-06 12:08:15 +00:00 by alf · 3 comments
alf commented 2026-11-06 12:08:15 +00:00
Owner
Copy link

Befund

Die Installation von iris-ghidra scheitert auf einem frisch eingerichteten Mac im Hook post_install:
post_install: /bin/bash fehlgeschlagen (Exit 1): > Task :compileJava FAILED. Gemeldet auf dem MacBook; dort nicht erreichbar, nachgestellt auf dem Entwicklungs-Mac mit Ghidra 12.2 aus dem Release-Zip.

Zwei Ursachen, beide belegt:

  1. JDK fest auf 21. Homebrew liefert inzwischen Ghidra 12.2 aus (Abhängigkeit openjdk@25). Ghidra nennt sein JDK selbst: application.java.min=21 (12.1.4) und =25 (12.2). Mit JDK 21 meldet Gradle „Ungültiges Quellrelease: 25“; auch jeder spätere analyzeHeadless-Lauf bräuchte JDK 25.
  2. Der LE/LX-Loader kompiliert nicht gegen Ghidra 12.2: ghidra.app.util.bin.format.Writeable gibt es in 12.1.4 (Base.jar), in 12.2 nicht mehr (DOSHeader.java:8). Der Loader ist Fremdcode (yetmorecode/ghidra-lx-loader) und nur für DOS-Programme im LE/LX-Format nötig; sein Fehlschlag bricht aber die ganze Installation ab.

Folge: iris-rea-recherche (braucht iris-ghidra) lässt sich dort ebenfalls nicht installieren.

Ziel

  • Das JDK wird aus application.java.min der installierten Ghidra gelesen (Homebrew openjdk@N, sonst JAVA_HOME, wenn es neu genug ist).
  • Ein fehlgeschlagener Loader-Bau bricht die Installation nicht ab: klare Warnung mit Grund, Log, und der Hinweis, was dann nicht geht (DOS-LE/LX). Mach-O, ELF, PE funktionieren.
  • doctor zeigt den Loader und Gradle als optional.

Warum

Eine Plugin-Installation darf nicht an einer Nebenfunktion scheitern, und der Hook muss mit der Ghidra-Version zurechtkommen, die Homebrew heute ausliefert.

## Befund Die Installation von `iris-ghidra` scheitert auf einem frisch eingerichteten Mac im Hook `post_install`: `post_install: /bin/bash fehlgeschlagen (Exit 1): > Task :compileJava FAILED`. Gemeldet auf dem MacBook; dort nicht erreichbar, nachgestellt auf dem Entwicklungs-Mac mit Ghidra 12.2 aus dem Release-Zip. Zwei Ursachen, beide belegt: 1. **JDK fest auf 21.** Homebrew liefert inzwischen Ghidra 12.2 aus (Abhängigkeit `openjdk@25`). Ghidra nennt sein JDK selbst: `application.java.min=21` (12.1.4) und `=25` (12.2). Mit JDK 21 meldet Gradle „Ungültiges Quellrelease: 25“; auch jeder spätere `analyzeHeadless`-Lauf bräuchte JDK 25. 2. **Der LE/LX-Loader kompiliert nicht gegen Ghidra 12.2**: `ghidra.app.util.bin.format.Writeable` gibt es in 12.1.4 (Base.jar), in 12.2 nicht mehr (`DOSHeader.java:8`). Der Loader ist Fremdcode (yetmorecode/ghidra-lx-loader) und nur für DOS-Programme im LE/LX-Format nötig; sein Fehlschlag bricht aber die ganze Installation ab. Folge: `iris-rea-recherche` (braucht `iris-ghidra`) lässt sich dort ebenfalls nicht installieren. ## Ziel - Das JDK wird aus `application.java.min` der installierten Ghidra gelesen (Homebrew `openjdk@N`, sonst `JAVA_HOME`, wenn es neu genug ist). - Ein fehlgeschlagener Loader-Bau bricht die Installation nicht ab: klare Warnung mit Grund, Log, und der Hinweis, was dann nicht geht (DOS-LE/LX). Mach-O, ELF, PE funktionieren. - `doctor` zeigt den Loader und Gradle als optional. ## Warum Eine Plugin-Installation darf nicht an einer Nebenfunktion scheitern, und der Hook muss mit der Ghidra-Version zurechtkommen, die Homebrew heute ausliefert.
alf commented 2026-11-06 12:21:06 +00:00
Author
Owner
Copy link

PR #368 gemergt: fix(iris-ghidra): JDK nach Ghidra-Version, Loader optional, Import erneut versuchen (0.2.1) (#367)
http://docker:3000/iris/iris-plugins/pulls/368

Commits:

  • fix(iris-ghidra): JDK nach Ghidra-Version, Loader optional, Import erneut versuchen (0.2.1) (#367)

iris-ghidra 0.2.1 ist veröffentlicht und behebt die Installation mit Ghidra 12.2.

Befund: Gemeldet vom MacBook („post_install … Task :compileJava FAILED“). Das MacBook war nicht erreichbar; nachgestellt auf dem Entwicklungs-Mac mit dem Ghidra-12.2-Release-Zip und einem JDK 25, jeweils im Temp-Ordner. Zwei Ursachen, beide belegt:

  1. Der Hook war fest auf JDK 21. Homebrew liefert Ghidra 12.2 aus (hängt an openjdk@25), Ghidra nennt sein JDK selbst (application.java.min 21 bei 12.1.4, 25 bei 12.2). Mit JDK 21 meldet Gradle „Ungültiges Quellrelease: 25“.
  2. Der LE/LX-Loader (Fremdcode) kompiliert gegen Ghidra 12.2 nicht: ghidra.app.util.bin.format.Writeable gibt es in 12.1.4, in 12.2 nicht mehr. Sein Fehlschlag brach die ganze Installation ab, obwohl er nur für DOS-Programme im LE/LX-Format nötig ist.
    Dazu beim Testen gefunden: Ein fehlgeschlagener erster Import hinterließ ein Projekt, das iris-ghidra für fertig hielt (Prüfung auf project.prp); jeder weitere Lauf scheiterte an „program file(s) not found“, bis man --force nahm.

Geändert:

  • Das JDK richtet sich nach application.java.min der installierten Ghidra: Homebrew openjdk@N, sonst ein ausdrücklich gesetztes JAVA_HOME (wenn neu genug), zuletzt das neueste openjdk. install holt bei Bedarf openjdk@N.
  • Der Loader ist optional: schlägt sein Build fehl, endet die Installation trotzdem mit Exit-Code 0, einer Warnung mit Grund (gekürzte Compilerfehler), der Folge (DOS-LE/LX nicht lesbar, Mach-O/ELF/PE gehen) und dem Log unter ~/Library/Application Support/Iris/iris-ghidra/loader-build.log. doctor zeigt Loader und Gradle als optional.
  • has_program prüft die Datenbankdatei unter iris.rep/idata; ein fehlgeschlagener Import wird beim nächsten Lauf neu versucht.
  • Version 0.2.1, Änderungstext, Changelog, Anleitung und Store-Text (nennen kein festes JDK mehr), PLAN.md mit Lessons Learned.

Geprüft: 46 Tests grün (22 neu: JDK-Wahl, Loader-Toleranz, has_program, Wiederherstellung nach einem echten fehlgeschlagenen Import). Drei Regeln ausgebaut (JDK fest 21, Loader-Fehler als Abbruch, alte has_program-Prüfung): die Tests wurden rot. Gegen Ghidra 12.2 mit JDK 25: 23 von 24 alten Tests grün, darunter alle Abfragen (xrefs, callers, callees, find-string, find-const). Der Hook im Fehlerszenario (12.2, Loader baut nicht): Exit-Code 0 mit Warnung. Dry-Run bestanden, Registry nach dem Pull geprüft (0.2.0 und 0.2.1).

Nicht geprüft: Die Installation auf dem MacBook selbst (nicht erreichbar). Der Dekompilierer unter Ghidra 12.2 auf dem Mac: Der Release-Zip enthält die nativen Teile nur für Linux und Windows (die Homebrew-Formel baut sie aus dem Quelltext), der eine Test mit decompile schlug im Zip-Aufbau deshalb fehl, das ist kein Plugin-Fehler, aber auch nicht bestätigt.

Grenzen: Mit Ghidra 12.2 sind DOS-Programme im LE/LX-Format nicht lesbar, solange der Loader nicht für 12.2 angepasst ist (Fremdcode, nicht von uns).

Offen: Erneut installieren auf dem MacBook und das Ergebnis zurückmelden; danach lässt sich iris-rea-recherche dort installieren (es braucht iris-ghidra).

PR #368 gemergt: fix(iris-ghidra): JDK nach Ghidra-Version, Loader optional, Import erneut versuchen (0.2.1) (#367) http://docker:3000/iris/iris-plugins/pulls/368 Commits: - fix(iris-ghidra): JDK nach Ghidra-Version, Loader optional, Import erneut versuchen (0.2.1) (#367) --- **`iris-ghidra` 0.2.1 ist veröffentlicht und behebt die Installation mit Ghidra 12.2.** **Befund:** Gemeldet vom MacBook („post_install … `Task :compileJava` FAILED“). Das MacBook war nicht erreichbar; nachgestellt auf dem Entwicklungs-Mac mit dem Ghidra-12.2-Release-Zip und einem JDK 25, jeweils im Temp-Ordner. Zwei Ursachen, beide belegt: 1. Der Hook war fest auf JDK 21. Homebrew liefert Ghidra 12.2 aus (hängt an `openjdk@25`), Ghidra nennt sein JDK selbst (`application.java.min` 21 bei 12.1.4, 25 bei 12.2). Mit JDK 21 meldet Gradle „Ungültiges Quellrelease: 25“. 2. Der LE/LX-Loader (Fremdcode) kompiliert gegen Ghidra 12.2 nicht: `ghidra.app.util.bin.format.Writeable` gibt es in 12.1.4, in 12.2 nicht mehr. Sein Fehlschlag brach die ganze Installation ab, obwohl er nur für DOS-Programme im LE/LX-Format nötig ist. Dazu beim Testen gefunden: Ein fehlgeschlagener erster Import hinterließ ein Projekt, das `iris-ghidra` für fertig hielt (Prüfung auf `project.prp`); jeder weitere Lauf scheiterte an „program file(s) not found“, bis man `--force` nahm. **Geändert:** - Das JDK richtet sich nach `application.java.min` der installierten Ghidra: Homebrew `openjdk@N`, sonst ein ausdrücklich gesetztes JAVA_HOME (wenn neu genug), zuletzt das neueste `openjdk`. `install` holt bei Bedarf `openjdk@N`. - Der Loader ist optional: schlägt sein Build fehl, endet die Installation trotzdem mit Exit-Code 0, einer Warnung mit Grund (gekürzte Compilerfehler), der Folge (DOS-LE/LX nicht lesbar, Mach-O/ELF/PE gehen) und dem Log unter `~/Library/Application Support/Iris/iris-ghidra/loader-build.log`. `doctor` zeigt Loader und Gradle als optional. - `has_program` prüft die Datenbankdatei unter `iris.rep/idata`; ein fehlgeschlagener Import wird beim nächsten Lauf neu versucht. - Version 0.2.1, Änderungstext, Changelog, Anleitung und Store-Text (nennen kein festes JDK mehr), `PLAN.md` mit Lessons Learned. **Geprüft:** 46 Tests grün (22 neu: JDK-Wahl, Loader-Toleranz, `has_program`, Wiederherstellung nach einem echten fehlgeschlagenen Import). Drei Regeln ausgebaut (JDK fest 21, Loader-Fehler als Abbruch, alte `has_program`-Prüfung): die Tests wurden rot. Gegen **Ghidra 12.2 mit JDK 25**: 23 von 24 alten Tests grün, darunter alle Abfragen (`xrefs`, `callers`, `callees`, `find-string`, `find-const`). Der Hook im Fehlerszenario (12.2, Loader baut nicht): Exit-Code 0 mit Warnung. Dry-Run bestanden, Registry nach dem Pull geprüft (0.2.0 und 0.2.1). **Nicht geprüft:** Die Installation auf dem MacBook selbst (nicht erreichbar). Der Dekompilierer unter Ghidra 12.2 auf dem Mac: Der Release-Zip enthält die nativen Teile nur für Linux und Windows (die Homebrew-Formel baut sie aus dem Quelltext), der eine Test mit `decompile` schlug im Zip-Aufbau deshalb fehl, das ist kein Plugin-Fehler, aber auch nicht bestätigt. **Grenzen:** Mit Ghidra 12.2 sind DOS-Programme im LE/LX-Format nicht lesbar, solange der Loader nicht für 12.2 angepasst ist (Fremdcode, nicht von uns). **Offen:** Erneut installieren auf dem MacBook und das Ergebnis zurückmelden; danach lässt sich `iris-rea-recherche` dort installieren (es braucht `iris-ghidra`).
alf commented 2026-11-06 12:28:35 +00:00
Author
Owner
Copy link

PR #369 gemergt: fix(iris-ghidra): LE/LX-Loader für Ghidra 12.2, gepinnt und mit Korrektur (0.2.2) (#367)
http://docker:3000/iris/iris-plugins/pulls/369

Commits:

  • fix(iris-ghidra): LE/LX-Loader für Ghidra 12.2, gepinnt und mit Korrektur (0.2.2) (#367)

iris-ghidra 0.2.2 ist veröffentlicht: DOS-Programme im LE/LX-Format lassen sich jetzt auch mit Ghidra 12.2 lesen.

Befund: Nach 0.2.1 lief die Installation mit Ghidra 12.2 durch, der LE/LX-Loader (Fremdcode) wurde aber nicht gebaut: Er importiert ghidra.app.util.bin.format.Writeable, die es in 12.2 nicht mehr gibt (nur in DOSHeader.java, drei Stellen). Beim echten Hook-Lauf zusätzlich gefunden: Der Build lief im Verzeichnis l, Gradle benennt die Erweiterung nach dem Verzeichnis, sie landete als Extensions/l, doctor meldete den Loader als fehlend, und jede Installation baute neu.

Geändert:

  • loader/ghidra-12.2.patch (drei Zeilen): DOSHeader implementiert Writeable nicht mehr. Wird vor dem Bau auf den Loader angewendet.
  • Der Loader ist auf den geprüften Commit 60bae51 gepinnt (LOADER_COMMIT), statt bei jeder Installation den jeweils neuesten Fremdcode von GitHub zu bauen.
  • Das Build-Verzeichnis heißt ghidra-lx-loader (LOADER_NAME), die Erweiterung landet dort, wo loader_dir() und doctor sie suchen; ein zweiter Hook-Lauf ist wiederholbar.
  • Build-Skript nimmt loader/*.patch ins Paket; Version 0.2.2, Änderungstext, Changelog, Anleitung, PLAN.md mit Lessons Learned.

Geprüft: 50 Tests grün (4 neu, darunter einer, der den Patch per git apply --check gegen den echten gepinnten Commit prüft). Drei Regeln ausgebaut (Verzeichnisname, Patch nicht angewendet, Commit nicht gepinnt): die Tests wurden rot. Mit Ghidra 12.2 und JDK 25 (Release-Zip und Temurin im Temp-Ordner): der Loader baut; ein echtes DOS4GW-LE-Programm (168 KB, Watcom) wird als watcom:LE:32:default mit 353 Funktionen und 291 Strings importiert, ein großes (1,2 MB) mit 1051 Funktionen und 791 Strings. Der gepatchte Loader baut auch gegen Ghidra 12.1.4 mit JDK 21. Das gebaute Paket entpackt und daraus den Hook gegen 12.2 laufen lassen: Exit-Code 0, doctor erkennt den Loader, danach die Analyse mit dem Skript aus dem Paket. Ghidra 12.2 öffnet Projekte, die 12.1.4 angelegt hat, der Rückweg scheitert mit Ghidras eigener Meldung. Dry-Run bestanden, Registry nach dem Pull geprüft (0.2.0, 0.2.1, 0.2.2).

Nicht geprüft: Die Installation auf dem MacBook (dort nicht erreichbar). Der Dekompilierer unter Ghidra 12.2 auf dem Mac: Der Release-Zip enthält die nativen Teile nur für Linux und Windows, decompile und ein Lauf ohne --ohne-pseudocode ließen sich im Aufbau deshalb nicht prüfen. Ob die Programme unter 12.2 inhaltlich so zerlegt werden wie unter 12.1.4 (nur die Zähler sind gemessen, nicht der Pseudocode).

Grenzen: Der gepinnte Loader-Stand ist von Hand aktualisiert: Wenn Upstream später eine neue Ghidra-Version unterstützt, muss LOADER_COMMIT (und ggf. der Patch) nachgezogen werden.

Offen: Erneut auf dem MacBook installieren und das Ergebnis zurückmelden.

PR #369 gemergt: fix(iris-ghidra): LE/LX-Loader für Ghidra 12.2, gepinnt und mit Korrektur (0.2.2) (#367) http://docker:3000/iris/iris-plugins/pulls/369 Commits: - fix(iris-ghidra): LE/LX-Loader für Ghidra 12.2, gepinnt und mit Korrektur (0.2.2) (#367) --- **`iris-ghidra` 0.2.2 ist veröffentlicht: DOS-Programme im LE/LX-Format lassen sich jetzt auch mit Ghidra 12.2 lesen.** **Befund:** Nach 0.2.1 lief die Installation mit Ghidra 12.2 durch, der LE/LX-Loader (Fremdcode) wurde aber nicht gebaut: Er importiert `ghidra.app.util.bin.format.Writeable`, die es in 12.2 nicht mehr gibt (nur in `DOSHeader.java`, drei Stellen). Beim echten Hook-Lauf zusätzlich gefunden: Der Build lief im Verzeichnis `l`, Gradle benennt die Erweiterung nach dem Verzeichnis, sie landete als `Extensions/l`, `doctor` meldete den Loader als fehlend, und jede Installation baute neu. **Geändert:** - `loader/ghidra-12.2.patch` (drei Zeilen): `DOSHeader` implementiert `Writeable` nicht mehr. Wird vor dem Bau auf den Loader angewendet. - Der Loader ist auf den geprüften Commit `60bae51` gepinnt (`LOADER_COMMIT`), statt bei jeder Installation den jeweils neuesten Fremdcode von GitHub zu bauen. - Das Build-Verzeichnis heißt `ghidra-lx-loader` (`LOADER_NAME`), die Erweiterung landet dort, wo `loader_dir()` und `doctor` sie suchen; ein zweiter Hook-Lauf ist wiederholbar. - Build-Skript nimmt `loader/*.patch` ins Paket; Version 0.2.2, Änderungstext, Changelog, Anleitung, `PLAN.md` mit Lessons Learned. **Geprüft:** 50 Tests grün (4 neu, darunter einer, der den Patch per `git apply --check` gegen den echten gepinnten Commit prüft). Drei Regeln ausgebaut (Verzeichnisname, Patch nicht angewendet, Commit nicht gepinnt): die Tests wurden rot. Mit **Ghidra 12.2 und JDK 25** (Release-Zip und Temurin im Temp-Ordner): der Loader baut; ein echtes DOS4GW-LE-Programm (168 KB, Watcom) wird als `watcom:LE:32:default` mit 353 Funktionen und 291 Strings importiert, ein großes (1,2 MB) mit 1051 Funktionen und 791 Strings. Der gepatchte Loader baut auch gegen Ghidra 12.1.4 mit JDK 21. **Das gebaute Paket** entpackt und daraus den Hook gegen 12.2 laufen lassen: Exit-Code 0, `doctor` erkennt den Loader, danach die Analyse mit dem Skript aus dem Paket. Ghidra 12.2 öffnet Projekte, die 12.1.4 angelegt hat, der Rückweg scheitert mit Ghidras eigener Meldung. Dry-Run bestanden, Registry nach dem Pull geprüft (0.2.0, 0.2.1, 0.2.2). **Nicht geprüft:** Die Installation auf dem MacBook (dort nicht erreichbar). Der Dekompilierer unter Ghidra 12.2 auf dem Mac: Der Release-Zip enthält die nativen Teile nur für Linux und Windows, `decompile` und ein Lauf ohne `--ohne-pseudocode` ließen sich im Aufbau deshalb nicht prüfen. Ob die Programme unter 12.2 inhaltlich so zerlegt werden wie unter 12.1.4 (nur die Zähler sind gemessen, nicht der Pseudocode). **Grenzen:** Der gepinnte Loader-Stand ist von Hand aktualisiert: Wenn Upstream später eine neue Ghidra-Version unterstützt, muss `LOADER_COMMIT` (und ggf. der Patch) nachgezogen werden. **Offen:** Erneut auf dem MacBook installieren und das Ergebnis zurückmelden.
alf commented 2026-11-06 12:54:26 +00:00
Author
Owner
Copy link

Bestätigt vom Nutzer (2026-11-06): iris-ghidra 0.2.2 ist auf dem MacBook installiert (Plugin-Karte „Installiert 0.2.2“). Damit ist die Installation mit Ghidra 12.2 dort belegt. Weiter nicht geprüft: ein echter Lauf (Analyse einer Datei) auf dem MacBook, der Dekompilierer unter Ghidra 12.2 auf dem Mac und DOS-Programme im LE/LX-Format mit dem reparierten Loader dort.

**Bestätigt vom Nutzer (2026-11-06):** `iris-ghidra` 0.2.2 ist auf dem MacBook installiert (Plugin-Karte „Installiert 0.2.2“). Damit ist die Installation mit Ghidra 12.2 dort belegt. **Weiter nicht geprüft:** ein echter Lauf (Analyse einer Datei) auf dem MacBook, der Dekompilierer unter Ghidra 12.2 auf dem Mac und DOS-Programme im LE/LX-Format mit dem reparierten Loader dort.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
  
herkunft/alpha-feedback
Aus Rückmeldungen der Alpha-Tester

  
status
blockiert
 Wartet auf etwas anderes

  
status
zu-testen
 Gebaut, aber noch nicht im echten Einsatz geprüft

  
typ
bug
 Fehler

  
typ
docs
 Dokumentation

  
typ
enhancement
 Verbesserung einer vorhandenen Funktion

  
typ
feature
 Neue Funktion

  
typ
idea
 Idee, noch nicht entschieden

No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
iris/iris-plugins#367
No description provided.