fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

re: close the pak route properly (41 paks) and read the script loader's own code

Browse Source 
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.
This commit is contained in:
Sylpheed RE agent
2026-08-27 04:09:18 +00:00
parent d9032af5be
commit 6d6766db18
1 changed files with 42 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
docs/re/mission-phase-advance.md
View File

@@ -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