kstuff is part of the environment after exploitation. A kernel exploit supplies access; a loader delivers code; kstuff implements additional runtime behavior using that access. Its compatibility list cannot be used to choose an initial entry point. Read the security-layer overview and compatibility evidence together.
Reviewed 10 October 2026. Legacy kstuff, kstuff-lite, bundled copies and development branches must be identified separately.
Why the distinction matters
The original IPv6 research shows that a PS5 kernel read/write primitive can coexist with restrictions on kernel text and ordinary code patches. Later projects can construct useful runtime functionality around those constraints. Seeing a developer discuss a protected memory region does not mean no useful homebrew can run, and seeing a homebrew payload run does not mean all protected regions have been defeated.
Some documentation uses “HEN” for an environment with several functions bundled together. Keep a capability record instead: userland execution, kernel memory access, process privileges, ELF loading, package installation, executable acceptance, filesystem mounting and application launch. This record is more useful than a single “fully jailbroken” label when comparing releases.
Identify the kstuff branch
EchoStretch's legacy kstuff releases document version 1.6.7 for 3.00–10.01. kstuff-lite 1.11 Beta expands the maintainer's stated payload range to 1.00–13.60. The Lite release notes separately mention FPKG work through 11.40, a fix for 11.60 and 13.x changes. This level of detail matters: broad payload-range wording does not establish that every package feature behaves identically throughout it.
The current Lite source documentation discusses user/kernel transitions, per-CPU translation caches, checked memory access, debug-register restoration and preservation of FPU state. These explain why a port involves more than inserting a firmware number. CPU state and kernel layout must agree with the implementation. Copying offsets from a nearby release is not a reliable porting procedure.
Package, executable and application support
A PKG is an installation container. An ELF is an executable format commonly used by payloads. A SELF is a PlayStation executable container, and project documentation uses FSELF/FPKG for modified or development-oriented executable/package handling. Those labels do not establish that a particular commercial application will run on a lower firmware. A successful installer can still be followed by a loader, dependency, entitlement, content-format or runtime failure.
The PS5 installation writeup demonstrates a concrete platform difference: older PS4 BGFT registration calls return an unsupported-API error on PS5, so the implementation uses AppInstUtil and follows asynchronous installation status. Package acceptance, privilege preparation and progress reporting are separate pieces. A transfer-complete notification should not be mistaken for a successfully installed, launchable application.
For native PS5 content, match the application's actual requirements to the console and tool revision. Firmware display spoofing changes a visible value; it does not supply absent operating-system interfaces. A patch or backport must solve the specific incompatibility it claims to address. Keep this wiki's homebrew instructions focused on software you are authorized to use and maintain your own originals.
Byepervisor is a different research route
Byepervisor describes independent low-firmware hypervisor techniques. Its recommended QA-flags route uses suspend/resume to influence reconstructed nested mappings and make guest kernel text readable/writable. The repository describes the 1.x/2.x family, but its included HEN is documented specifically for 2.50. The payload is sent before and after manually entering rest mode. Those narrow requirements cannot be generalized to later consoles or newer firmware.
The distinction is practical: loading kstuff does not imply Byepervisor ran, and a Byepervisor demonstration does not automatically establish a port of your preferred HEN. Kernel dumping and executable decryption are research capabilities with their own code paths. Respect the repository's warning about its commented kernel-dump code encountering unmapped memory rather than treating all examples as ordinary maintenance tools.
Build a controlled application test
Start with a small documented homebrew program, then test one feature at a time. Note the exact payload branch, build tag, loader and firmware. If an application starts before a plugin is added but fails afterward, restore the baseline and compare logs. If package installation fails, preserve the error code and the installer state. If only rest resume fails, test a fresh boot before changing package files. These observations help identify the responsible layer without speculation.
Continue with etaHEN setup for its integrated services or troubleshooting for reproducible failure reports.