iris-ghidra: „bad instruction data“ bei NEC-V30-Programmen (Raiden II): Ursache klären, dann beheben #382

New issue

Open

opened 2026-11-06 19:38:38 +00:00 by alf · 1 comment

alf commented

2026-11-06 19:38:38 +00:00

Owner

Problem

iris-ghidra dekompiliert das Programm der Raiden-II-Recherche (NEC-V30-Hauptprozessor, 1 MB Bild aus prg0/prg1, geladen als x86:LE:16:Real Mode) nur teilweise: Chat-Export und Workspace auf dem MacBook, 2026-11-06. 242 Funktionen, bei 25 von 241 meldet Ghidra „Control flow encountered bad instruction data“ (55 Warnungen in decompiled.c), darunter die am häufigsten aufgerufene Funktion (FUN_9000_17b4, 36 Aufrufer), die zu „Unsinn“ dekompiliert. Die statische Analyse der Spielelogik ist damit weitgehend wertlos.

Was belegt ist und was nicht

Der Agent erklärt es mit V30-Zusatzbefehlen, die Ghidras x86-16-Decoder nicht kennt, und mit „obfuskierten COP-Segmenten“. Das ist nicht belegt. Prüfung: FUN_9000_009b meldet „Instruction at (ram,0x0009017a) overlaps instruction at (ram,0x00090179)“. Das aus prg0/prg1 verschachtelte Bild hat bei 0x90179 die Bytes 18 08 1d 4a 25 8c 2d ef 39 51 4a 93 56 bd 77 cc …: das sieht nach Daten aus, nicht nach V30-Code. Drei Ursachen sind möglich:

V30-Zusatzbefehle (0F-Gruppe: TEST1/CLR1/SET1/NOT1, ROL4/ROR4, ADD4S/SUB4S/CMP4S, INS/EXT; 8080-Emulationsmodus), die dem Decoder fehlen;
falsche Ladeadresse oder Bank (das Original blendet das ROM über Bankumschaltung ein); dann ist Ghidras Segmentierung von Anfang an falsch;
Daten im Code oder verschlüsselte/geschützte Segmente (COP).

Umfang

Zuerst klären, welche der drei Ursachen es ist: Disassembly-Listing der Fehlerstellen, Abgleich mit dem MAME-Debugger (mame raiden2 -debug, disassembliert den V30 korrekt) und mit der Speicherkarte des Treibers (raiden2.cpp).
Danach je nach Ursache: Ladeadresse/Bank-Vorlage für iris-ghidra, oder eine Erweiterung der x86-Sprachdefinition um die NEC-Befehle (Muster wie beim gepinnten LE/LX-Loader mit Patch), oder ein Hinweis in der Anleitung, wann der Agent Ghidra nicht trauen darf.
Dem Agenten eine Meldung geben, wenn viele Funktionen „bad instruction data“ enthalten (ein Zähler im Export), damit er nicht mit unbrauchbarem Pseudocode weiterarbeitet.

Nicht im Umfang

Der Hinweis im Ablauf von iris-rea-recherche (eigenes Issue). Ein vollständiger V30-Emulator.

## Problem `iris-ghidra` dekompiliert das Programm der Raiden-II-Recherche (NEC-V30-Hauptprozessor, 1 MB Bild aus prg0/prg1, geladen als `x86:LE:16:Real Mode`) nur teilweise: Chat-Export und Workspace auf dem MacBook, 2026-11-06. 242 Funktionen, bei 25 von 241 meldet Ghidra „Control flow encountered bad instruction data“ (55 Warnungen in `decompiled.c`), darunter die am häufigsten aufgerufene Funktion (`FUN_9000_17b4`, 36 Aufrufer), die zu „Unsinn“ dekompiliert. Die statische Analyse der Spielelogik ist damit weitgehend wertlos. ## Was belegt ist und was nicht Der Agent erklärt es mit V30-Zusatzbefehlen, die Ghidras x86-16-Decoder nicht kennt, und mit „obfuskierten COP-Segmenten“. **Das ist nicht belegt.** Prüfung: `FUN_9000_009b` meldet „Instruction at (ram,0x0009017a) overlaps instruction at (ram,0x00090179)“. Das aus prg0/prg1 verschachtelte Bild hat bei 0x90179 die Bytes `18 08 1d 4a 25 8c 2d ef 39 51 4a 93 56 bd 77 cc …`: das sieht nach Daten aus, nicht nach V30-Code. Drei Ursachen sind möglich: 1. V30-Zusatzbefehle (0F-Gruppe: TEST1/CLR1/SET1/NOT1, ROL4/ROR4, ADD4S/SUB4S/CMP4S, INS/EXT; 8080-Emulationsmodus), die dem Decoder fehlen; 2. falsche Ladeadresse oder Bank (das Original blendet das ROM über Bankumschaltung ein); dann ist Ghidras Segmentierung von Anfang an falsch; 3. Daten im Code oder verschlüsselte/geschützte Segmente (COP). ## Umfang - Zuerst klären, welche der drei Ursachen es ist: Disassembly-Listing der Fehlerstellen, Abgleich mit dem MAME-Debugger (`mame raiden2 -debug`, disassembliert den V30 korrekt) und mit der Speicherkarte des Treibers (`raiden2.cpp`). - Danach je nach Ursache: Ladeadresse/Bank-Vorlage für `iris-ghidra`, oder eine Erweiterung der x86-Sprachdefinition um die NEC-Befehle (Muster wie beim gepinnten LE/LX-Loader mit Patch), oder ein Hinweis in der Anleitung, wann der Agent Ghidra nicht trauen darf. - Dem Agenten eine Meldung geben, wenn viele Funktionen „bad instruction data“ enthalten (ein Zähler im Export), damit er nicht mit unbrauchbarem Pseudocode weiterarbeitet. ## Nicht im Umfang Der Hinweis im Ablauf von iris-rea-recherche (eigenes Issue). Ein vollständiger V30-Emulator.

alf added the

typ

feature

label

2026-11-06 19:38:38 +00:00

alf referenced this issue

2026-11-06 19:42:15 +00:00

iris-rea-recherche: Bei Programm-Zielen gehört eine Ghidra-Analyse vor die Befunde zum Programm #381

alf commented

2026-11-06 19:44:14 +00:00

Author

Owner

Nachtrag mit Messungen (Workspace auf dem MacBook, 2026-11-06, nach dem weiteren Verlauf des Chats):

Das Bild stimmt. Das aus prg0 (gerade Bytes) und prg1 (ungerade) verschachtelte 1-MB-Bild hat bei 0xFFFF0 den Reset-Sprung EA 00 00 00 98 = JMP 9800:0000, also Ziel 0x98000. Dort steht lesbarer 8086-Code: FA B8 00 00 8E D8 8E C0 8E D0 BC 00 00 BF 00 00 = CLI; MOV AX,0; MOV DS,AX; MOV ES,AX; MOV SS,AX; MOV SP,0; MOV DI,0. Ursache 2 (falsches Bild/Bank) ist für das Bild selbst damit unwahrscheinlich, die Frage ist, wie es in Ghidra geladen wurde.
Ghidra hat den Einstieg nicht als Anker. functions.txt hat 242 Funktionen nur in den Segmenten 9000 (160), a000 (58), b000 (23) und d000 (1). Die Funktion FUN_9000_7f02 (Start 0x97f02, 362 Bytes) überdeckt 0x98000; zwischen 0x97f02+362 und der nächsten Funktion FUN_9000_894f (0x9894f) liegt nichts. Der Reset-Code liegt also mitten in einer Funktion und nicht an einem Funktionsanfang. Das spricht dafür, dass die Analyse nicht vom Reset-Vektor ausging, sondern Funktionsgrenzen durch Suche fand.
Fehlerstelle bleibt unklar. Bei 0x90179 (FUN_9000_009b, „overlaps instruction“) stehen weiter 39 51 4a 93 56 bd 77 cc 11 92 32 52, was nach Daten aussieht.
V30-Befehle sind plausibel, aber nicht gemessen. Im weiteren Verlauf fand der Agent einen Rust-Kern (neetan/vx0) mit einem extended_0f-Handler (bcd4s, bit1, MOV in Spezialregister 0x20/0x22/0x26), „genau das, was Ghidra fehlte“. Das erklärt höchstens einen Teil der 25 Fehlerfunktionen; welche Opcodes an den 55 Fehlerstellen stehen, ist nicht ermittelt.

Folgerung für die Reihenfolge im Issue: (1) Reset-Vektor als Einstiegspunkt setzen und die Analyse neu laufen lassen (Zähler „bad instruction data“ vorher/nachher), (2) erst dann die verbleibenden Fehlerstellen auf V30-Opcodes prüfen, (3) danach entscheiden, ob die Sprachdefinition ergänzt werden muss.

**Nachtrag mit Messungen (Workspace auf dem MacBook, 2026-11-06, nach dem weiteren Verlauf des Chats):** - **Das Bild stimmt.** Das aus prg0 (gerade Bytes) und prg1 (ungerade) verschachtelte 1-MB-Bild hat bei 0xFFFF0 den Reset-Sprung `EA 00 00 00 98` = `JMP 9800:0000`, also Ziel 0x98000. Dort steht lesbarer 8086-Code: `FA B8 00 00 8E D8 8E C0 8E D0 BC 00 00 BF 00 00` = `CLI; MOV AX,0; MOV DS,AX; MOV ES,AX; MOV SS,AX; MOV SP,0; MOV DI,0`. Ursache 2 (falsches Bild/Bank) ist für das Bild selbst damit unwahrscheinlich, die Frage ist, wie es in Ghidra geladen wurde. - **Ghidra hat den Einstieg nicht als Anker.** `functions.txt` hat 242 Funktionen nur in den Segmenten 9000 (160), a000 (58), b000 (23) und d000 (1). Die Funktion `FUN_9000_7f02` (Start 0x97f02, 362 Bytes) **überdeckt** 0x98000; zwischen 0x97f02+362 und der nächsten Funktion `FUN_9000_894f` (0x9894f) liegt nichts. Der Reset-Code liegt also mitten in einer Funktion und nicht an einem Funktionsanfang. Das spricht dafür, dass die Analyse nicht vom Reset-Vektor ausging, sondern Funktionsgrenzen durch Suche fand. - **Fehlerstelle bleibt unklar.** Bei 0x90179 (`FUN_9000_009b`, „overlaps instruction“) stehen weiter `39 51 4a 93 56 bd 77 cc 11 92 32 52`, was nach Daten aussieht. - **V30-Befehle sind plausibel, aber nicht gemessen.** Im weiteren Verlauf fand der Agent einen Rust-Kern (`neetan`/`vx0`) mit einem `extended_0f`-Handler (`bcd4s`, `bit1`, MOV in Spezialregister 0x20/0x22/0x26), „genau das, was Ghidra fehlte“. Das erklärt höchstens einen Teil der 25 Fehlerfunktionen; welche Opcodes an den 55 Fehlerstellen stehen, ist nicht ermittelt. **Folgerung für die Reihenfolge im Issue:** (1) Reset-Vektor als Einstiegspunkt setzen und die Analyse neu laufen lassen (Zähler „bad instruction data“ vorher/nachher), (2) erst dann die verbleibenden Fehlerstellen auf V30-Opcodes prüfen, (3) danach entscheiden, ob die Sprachdefinition ergänzt werden muss.