etaHEN adds a homebrew environment after a compatible exploit has succeeded. It is not an initial browser or game-save exploit. Confirm the firmware, kernel route and payload release before sending the file. The compatibility matrix distinguishes exploit support from payload support.
Reviewed 10 October 2026. Official releases list 2.5B as current. The cited notes do not establish universal etaHEN support on every newer firmware accepted by other exploit projects.
Build the correct loader chain
The 2.4B release notes require the Payload SDK ELF loader and document fixes for 8.40–10.01. Follow those requirements even if an older guide sends etaHEN directly to a primitive loader. Record which loader the exploit has actually started. A port number alone does not identify its ABI or supported payload format.
If the selected chain only opens an older loader on 9020, the Payload Dev elfldr guide explains bootstrapping its loader first. Hosts that already start a compatible 9021 loader can use their documented payload menu or sender. Download the chosen binary on your computer, keep the release tag with it and check any maintainer-provided digest. File extensions do not convert formats: renaming an unsupported binary to .elf does not make it compatible.
Deliver etaHEN from Windows
The official repository provides send_payload.ps1, a TCP sender that reads the specified file as bytes. Substitute your saved file and the console's local address:
powershell.exe -ExecutionPolicy Bypass -File .\send_payload.ps1 -Payload ".\etaHEN-2.5B.bin" -IP "192.168.1.50" -Port 9021This invocation sets script policy for that process. Review the downloaded script first. The sender's completed transfer indicates socket delivery; it is not an acknowledgement that the console loaded the payload correctly. Wait for console notifications, check the toolbox and inspect the payload's log before treating the session as healthy. Use a trusted local network and the port required by your actual loader.
Configuration and useful services
The official README places settings at /data/etaHEN/config.ini, created on first execution. It documents FTP on 1337, ELF loading on 9021, optional kernel logging on 9081, Discord RPC on 8000 and Direct PKG Installer v2's Web UI at http://PS5_IP:12800. These services are distinct; an FTP client cannot send a raw ELF to its FTP port.
| INI key | Purpose | README default |
|---|---|---|
FTP | Built-in file transfer | 1 |
PS5Debug | Automatic debugger service | 0 |
toolbox_auto_start | Automatic toolbox injection | 1 |
Allow_data_in_sandbox | Expose /data to application sandboxes | 1 |
DPI_v2 | Direct installer v2 service | 0 |
Klog | Kernel logging | 0 |
Display_tids | Show title identifiers | 0 |
Back up the existing file before editing it. Preserve the sections generated by your installed version, change one option at a time and compare the resulting behavior. A newer release's default is not necessarily applied to an existing configuration. The README describes a runtime update blocker, but it is available only after the environment has loaded; firmware preservation must also be planned outside the active session.
Plugins versus one-shot payloads
The Plugin SDK guide distinguishes single-task ELFs from background plugin daemons. It gives /data/etaHEN/plugins and USB etaHEN/plugins as plugin locations, with USB taking priority. A stale USB copy can therefore explain why an internal replacement appears ineffective. The guide also warns that kstuff-dependent plugin startup can take up to a minute. Wait for the documented startup period before sending duplicate instances.
For a first reliable session, disable optional auto-start plugins and extra network services. Add one plugin, observe it, then save the working configuration. Keep an inventory of plugin title IDs and versions. An auto-start plugin that crashes can make a healthy exploit look broken immediately after etaHEN starts.
Rest mode, updates and release-specific behavior
The 2.5B changes include a beta application dumper, revised webMAN handling and a kstuff-resume option. Treat beta and experimental features according to the release notes; their presence does not prove every title, drive or firmware works. Avoid adjusting fan controls merely because a new menu exposes them. For stability testing, use the default environment before experimenting with optional hardware-related settings.
Record whether a failure occurs at first boot, after toolbox startup, after a plugin loads or only after rest resume. Preserve /data/etaHEN logs before another run overwrites useful evidence. Follow exploit troubleshooting to separate transmission, loader, payload and plugin problems. For what the kstuff component actually changes, read kstuff and hypervisor limits.