The Last of Us Part II Remastered (PPSA15508)

[eliasbruno124-dev]

Existing thread

• I searched this category for the title ID and no thread exists for this title on any platform.

Title

The Last of Us Part II Remastered (PPSA15508)

Content version tested

01.002.000

AnyPS5 commit

2026-10-13 run: main dacd785, with the rebased #3897 SSL library at 0a91eb31a34f511c4a5256622431b2b233fa5c47 and #3925 HTTP2 library at 35cf2fd. Full Windows runtime builds; relinker from dacd785. #3965 is not included. The later upstream 0aa4cb1 was not the base of this run.

System tested

Windows 11 Pro x64, build 26300; NVIDIA GeForce RTX 3060 Laptop GPU, driver 617.14; WinLibs MinGW-w64 GCC 15.2.0, Release; GDB 17.1.

Furthest point

Stops before the first frame

What is shown

No game image was produced. Breakpoints at sceVideoOutOpen and sceVideoOutSubmitFlip were resolved and enabled before the original entry point, and both recorded zero calls through termination. This is instrumented startup evidence, not a screen recording. FPS is not applicable; audio, controls, saves and gameplay were not assessed.

Current blocker

The candidate terminates with a null read at game.exe+0x1c60f2 (original guest VA 0x1b60f2). This is the same stop previously traced to the low Windows main-stack region and addressed by #3965, whose review and independent validation remain pending.

The paired run isolates #3925: with the same runtime and #3897, baseline HTTP2 throws at sceHttp2SendRequestAsync with both option pointers null. Replacing only libSceHttp2.prx with #3925 lets send and wait return 0 and delivers the existing offline completion 0x80436063, then reaches the null read above. In both runs #3897 loads the title's one 1,408-byte PEM CA and returns 0.

Open prerequisites in this observation: #3897 (certificate import) and #3925 (HTTP2 direct waiting). Next proposed fix: #3965 (not tested in this run). The earlier memory stop is tracked in #2883; #3713 and #3509 are already in the tested main. No menu or playability claim.

How it was run

Separate generated Windows artifacts, with the original executable/module payloads unchanged. The available containers were staged as readable ELF inputs; resources kept their original names. The app0 test layout uses unchanged small-file copies and same-name directory junctions to the original resources, so this does not establish direct original-folder launching.

relinker --windows --windows-diagnostics --to-intel --registry --rpath <private-runtime> --sce-module-path <input-root> <input-root>/eboot.bin <trial>/game.exe
gdb --batch -nx -x startup.gdb <trial>/game.exe

The observer checked loaded modules and recorded original entry, SSL/HTTP2 calls and returns, and VideoOut calls. No registers, return values or user inputs were substituted. Each run had a separate profile/temp directory. Baseline and candidate used the same generated executable and runtime except for libSceHttp2.prx. The baseline cleanup encountered a transient DLL lock after the recorded abort; the private overlay was restored after process exit without replaying the run. Candidate cleanup completed normally. Original code hashes and generated artifacts were rechecked; no proprietary content or private paths are attached.

Prepared with AI assistance.