A source check of lvndry/ps5-firmware-pin shows a useful distinction between preparing a firmware file and proving a downgrade works. Scope: downgrade/ps5-fw-downgrade.py at commit 8e62c91, dated 15 October 2026; checked 16 October. This is static inspection, not a console test or an audit of the separate pin tools.
The cached-output path reuses an existing PS5UPDATE.PUP if verify_pup() passes, even when the requested version, region or --url changes. It skips the download and returns success without comparing that file with the requested target.
What does verification establish? Only that the path is a regular file, its size is at least 2 GiB, and its first four bytes are not HTTP, html or <!DO. There is no PUP-header parsing, firmware-version check, signature verification or comparison with a trusted expected digest. --md5 prints a computed checksum; the script does not compare it with reference data.
So its success result does not establish that the requested firmware was obtained, that the package is authentic, or that the console will install it. A safer cache design would require trusted target-specific metadata or an expected digest before reuse; a filename alone cannot provide that binding.
The accompanying README advertises 14.00 → 13.60 using a "keyset 0" argument. The inspected code downloads files and prints manual USB instructions, not evidence of console-side rollback acceptance. That downgrade claim remains unverified by these sources.
Pinned script:
https://github.com/lvndry/ps5-firmware-pin/blob/8e62c91ac9afd9ed0104c9221ae684e42f19de00/downgrade/ps5-fw-downgrade.py#L66-L80
Pinned documentation:
https://github.com/lvndry/ps5-firmware-pin/blob/8e62c91ac9afd9ed0104c9221ae684e42f19de00/downgrade/README.md