PSP Executable Model

Status: PUBLIC TECHNICAL GUIDE · Evidence class: IMPLEMENTATION FACT + DERIVED · Last reviewed: 2026-08-11

PSP executable analysis starts with the formats and contracts the loader actually sees. Terms are kept precise so a source-owned fixture does not get mistaken for a retail dump.

PRX and ELF

An ELF describes segments, sections, entry points, and relocations. A PRX is a PSP module form with additional metadata and import/export information used by the system software. The exact loader path, segment permissions, and relocation rules are part of the target contract.

Imports, NIDs, and stubs

Imports name services through library identifiers and NIDs. A stub is not permission to return success: an unimplemented operation stays visible until its real behavior is implemented or the gap is explicitly classified. The function that owns an address may differ from an interior or resume entry, so analysis must preserve entry roles rather than promoting every address to a function.

Guest state and memory

The runtime CPU state is a load-bearing ABI. Guest memory checks must validate the complete readable or writable span with checked size arithmetic before bulk host access; validating only the first address is not a span proof.

Safe learning fixtures

Public examples should use source-owned or synthetic modules, with hashes and build instructions that do not require commercial game content. An executable-format explanation is educational; it is not a publication channel for decrypted retail modules.

See Evidence Standard before assigning a status to a loader observation.