From 13117df0bdd6d31233e1f45c8dacc9e124f050d2 Mon Sep 17 00:00:00 2001
From: Sylpheed RE agent <agent@localhost>
Date: Thu, 27 Aug 2026 04:09:18 +0000
Subject: [PATCH] re: close the pak route properly (41 paks) and read the
 script loader's own code

My earlier negative was under-scoped: it probed 35 paks, missing hidden/resource3d/
and dat/movie/.  Redone across every *.pak on the disc -- 41 archives, 26443
indexed records, 768 distinct name hashes -- still ZERO hits.  The scripts are not
a pak record under any of those names.

Located the three loader strings by VA (the .pe is a flat VA dump, VA = 0x82000000
+ offset) and pulled their xrefs from sylpheed.db:

  SCRIPTS   0x820a823c  <- 0x8225f1b8, 0x82262374
  GP_SCRIPT 0x820a8244  <- 0x8225f168, 0x822622bc
  MISSION1  0x820a8264  <- 0x8225eed8

Disassembling sub_8225EE20 shows both archive-name references call THE SAME
routine 0x82448AA0 with (object, string) and test the result with cmpi -- so the
loader COMPARES a name against an already-open archive rather than building a path
like dat\GP_SCRIPT.pak.  That fits GP_SCRIPT being a name an archive reports,
which is why no such file exists to find.

Next concrete steps recorded: identify 0x82448AA0 (strcmp/strstr/hash-compare) and
its neighbours 0x82448C50 / 0x8216F218, and trace [r31+80] -- the object being
name-tested -- back to whoever opened it.  That names the container.
---
 docs/re/mission-phase-advance.md | 46 +++++++++++++++++++++++++++++---
 1 file changed, 42 insertions(+), 4 deletions(-)

diff --git a/docs/re/mission-phase-advance.md b/docs/re/mission-phase-advance.md
index 935d294d..1e9f962f 100644
--- a/docs/re/mission-phase-advance.md
+++ b/docs/re/mission-phase-advance.md
@@ -164,10 +164,48 @@ hashes** — `MISSION1..33` and the five `MISSION_*_PRT`, each under the prefixe
 the suffixes `.prt`, `.PRT`, `.scr`, `.bin` and none — across **all 35 paks** in
 `dat/` and `hidden/`. **Zero hits.**
 
-❔ What is left: the payload is in the XEX's compressed/encrypted region (this
-file notes the retail `default.xex` was never decrypted), or under a name none of
-those 616 guesses covered. The `GP_SCRIPT` string is the strongest remaining
-thread — a pak of that name is referenced by the code but absent from the disc.
+### The pak route is now properly closed, and the loader's own code read
+
+**All 41 paks, not 35.** The first sweep missed `hidden/resource3d/` and
+`dat/movie/`. Redone across every `*.pak` on the disc — **41 archives, 26 443
+indexed records, 768 distinct name hashes** — still **zero hits**. The scripts are
+not a pak record under any of those names.
+
+**The loader compares names; it does not build a path.** The three strings live at
+known VAs (the `.pe` is a flat VA dump, so `VA = 0x82000000 + offset`):
+
+| string | VA | referenced from |
+|---|---|---|
+| `SCRIPTS` | `0x820a823c` | `0x8225f1b8`, `0x82262374` |
+| `GP_SCRIPT` | `0x820a8244` | `0x8225f168`, `0x822622bc` |
+| `MISSION1` | `0x820a8264` | `0x8225eed8` |
+
+All three references inside `sub_8225EE20` disassemble to the same shape:
+
+```
+8225F160  addis r11, r0, 0x820B
+8225F164  lwz   r3, 80(r31)          ; an object
+8225F168  addi  r4, r11, -32188      ; = 0x820A8244  "GP_SCRIPT"
+8225F16C  bl    0x82448AA0
+...
+8225F1B0  addis r11, r0, 0x820B
+8225F1B4  lwz   r3, 0(r25)
+8225F1B8  addi  r4, r11, -32196      ; = 0x820A823C  "SCRIPTS"
+8225F1BC  bl    0x82448AA0
+8225F1C0  cmpi  cr6, 0, r3, 0        ; result tested as a comparison
+```
+
+Both call **the same routine `0x82448AA0`** with `(object, string)` and test the
+result — so this is a *name comparison* against an already-open archive, not the
+construction of `dat\GP_SCRIPT.pak`. That is consistent with `GP_SCRIPT` being
+the name the engine expects an archive to *report*, which is why no file of that
+name exists to be found.
+
+❔ Still open, with the next concrete steps: identify `0x82448AA0` (strcmp vs
+strstr vs a hash-compare) and `0x82448C50`/`0x8216F218` around it, and follow
+`[r31+80]` — the object whose name is being tested — back to whoever opened it.
+That names the container. The XEX's compressed/encrypted region remains the other
+candidate; the retail `default.xex` has never been decrypted here.
 
 ## ✅ Tooling correction: the `.pe` is NOT stale