re: refute the .embsec_ script candidate; narrow the pak route with 616 hash probes

Both candidates this file named for the missing phase-script bytecode were tested
statically, from the flat-VA .pe and the extracted paks.

REFUTED: the seven .embsec_ sections hold PPC CODE.  Parsed from the section table
(offset 592, 40 bytes apart) they total 129472 bytes, matching this file's own
"~130 KB" estimate, so they are the right sections -- but six of seven begin
7d8802a6 (mflr r12) and all carry the standard prologue (stwu r1,-N(r1), std
r30,-16(r1), bl).  That is not bytecode for a 147-builtin VM.

Also recorded: ".embsec_P" from `strings` is a false lead -- the name field is
exactly ".embsec_" and the P is byte 0x50 of the following VirtualSize (0x1350 =
4944, the fifth section's size).

CORRECTION: this file says grepping for MISSION_START_PRT "returns nothing".  That
grep was over the DISC EXTRACTION; all five MISSION_*_PRT names are present in the
executable image, in an .rdata table reading "SCRIPTS" "GP_SCRIPT" "script load
cancel\n" "MISSION1".."MISSION33".

NARROWED: the paks are name-hash addressed, so names can be probed rather than
eyeballed.  616 distinct hashes -- MISSION1..33 and the five MISSION_*_PRT under
prefixes SCRIPTS\, GP_SCRIPT\, scripts\, script\, SCRIPT\ and none, with suffixes
.prt/.PRT/.scr/.bin and none -- across all 35 paks: ZERO hits.

Left open: the XEX's compressed/encrypted region, or a name outside those guesses.
GP_SCRIPT is the strongest remaining thread -- referenced by code, absent from disc.
This commit is contained in:
Sylpheed RE agent
2026-08-27 04:01:34 +00:00
parent 2c44692ec6
commit b425ddc01e

View File

@@ -115,6 +115,60 @@ in `hidden/MiscBin.pak`.
**Finding it would give the actual per-phase clear condition for every stage**
which is the thing the port needs.
### 🔴 2026-08-27 — the `.embsec_` candidate is REFUTED, and the pak route narrowed
Both named candidates were tested statically, from the flat-VA `.pe` and the
extracted paks. No emulator.
**The seven `.embsec_` sections hold PPC CODE, not bytecode.** Parsed from the
section table (they begin at file offset 592, forty bytes apart):
| RVA | VirtSize |
|---|---|
| `0x84e800` | 39 340 |
| `0x858200` | 42 168 |
| `0x862800` | 7 436 |
| `0x864600` | 23 680 |
| `0x86a400` | 4 944 |
| `0x86b800` | 3 272 |
| `0x86c600` | 8 632 |
Total **129 472 bytes** — matching this file's own "~130 KB" estimate, so these
are the right sections. Their contents are unambiguous machine code: six of the
seven begin `7d8802a6` (`mflr r12`) and every one contains the standard prologue
(`9421ff??` `stwu r1,-N(r1)`, `fbc1fff0` `std r30,-16(r1)`, `4b??????` `bl`).
**Script bytecode for a 147-builtin VM does not look like this.** ❌ Candidate
eliminated.
⚠️ A false lead recorded so it is not chased: `strings` reports `.embsec_P`,
which looks like a longer truncated name. It is not — the name field is exactly
`.embsec_` and the `P` is byte `0x50` of the following `VirtualSize` (`0x1350` =
4 944, the fifth section's size).
**The `MISSION_*_PRT` names ARE in the executable.** This file says grepping
"returns nothing", but that grep was over the *disc extraction*; all five
(`START`/`END`/`UPDATE`/`FAILED`/`RESTART`) are present in the image, in an
`.rdata` string table that reads:
```
"SCRIPTS" "GP_SCRIPT" "script load cancel\n" "MISSION1" … "MISSION33"
```
So the loader's vocabulary is intact and includes a `GP_SCRIPT` archive name.
**But the scripts are not pak records under any obvious name.** The paks are
name-hash addressed (`unitgroup.name_hash`), so candidate names can be probed
directly against every index rather than guessed at by eye: **616 distinct
hashes** — `MISSION1..33` and the five `MISSION_*_PRT`, each under the prefixes
`SCRIPTS\`, `GP_SCRIPT\`, `scripts\`, `script\`, `SCRIPT\` and none, with
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.
## ✅ Tooling correction: the `.pe` is NOT stale
A standing note said "`.pe` STALE vs `sylpheed.db` — DB only". Wrong, and the