Safety and responsibility
This project is research. It patches a running kernel, and that is the whole risk. Read this page before your first attempt.
You run this at your own responsibility. Every consequence belongs to you: a panic, a corrupted save, an unbootable console, a voided warranty, or a PlayStation Network ban. I publish the artifacts and the measurements I made, and I take no responsibility for what happens on your hardware. If that trade is unacceptable, stop reading and do not burn a disc.
This is a research project
The purpose is to document how a BD-J disc reaches kernel execution on firmware 14.00, and to keep the artifact reproducible and checkable. It carries no protected content and circumvents no content protection. It is not a way to play copied games. Whether exploiting your own console is lawful where you live is your question to answer, and the answer differs by jurisdiction. I am not able to advise you on it.
One attempt per boot, and why
The payload states the rule three times in its own strings [V]:
One attempt only; restart after any failure.
No retry in this boot. Cold reboot before another attempt.
There is no automatic retry.The native stage adds arms MISSED … Cold reboot clears them. A failed attempt leaves state inside the kernel that a soft restart does not clear, so a second attempt in the same boot runs on top of the wreckage of the first. The design has no retry loop at all, which is a structural choice rather than a policy: the result ledger stops the sequence when a stage reports something unexpected.
After any failure: hold the power button until the console is fully off, or unplug it for thirty seconds. Then power on and make one attempt. Restart from the menu and rest mode both fail to clear it.
A failed run can still write kernel memory
The notice on the disc says it directly, and it is the least obvious hazard in the flow:
The Hx stage may write unknown kernel objects even on a failed pairing run.So Hx reported failed pairing is not a clean no. Treat the console as dirty after any attempt until it has been cold-rebooted and boots normally.
What HEN changes on the system
Taken from the native stage's own embedded strings and comments:
| Change | Consequence |
|---|---|
Syscall sysent[11] redirected to a kernel-exec helper, establishing uid 0 | The widest thing HEN does. A bug here shows up as a panic rather than an error message. |
/update unmounted when you enable Block firmware updates | Updates cannot land, which is the point, and also means an unexpected reboot can behave oddly. |
| Memory mapping and plugin loading behaviour altered | These are the same paths the OS uses for its own code, so instability can show up far from the exploit. |
| HEN plugin PRX files written to the internal drive | Files on disk that survive the reboot, unlike the kernel patches. |
The kernel patches themselves are temporary. HEN does not survive a power-off and does not write a persistent bootloader, so you re-run the disc after every reboot.
Reported success needs your own check
The payload declines to certify itself. Its best line reads Hx reports HEN start. Verify menu and kernel R/W separately. and the on-disc notice says a displayed success report must be verified independently on the console. Believing the screen is how people end up running a half-patched kernel. Step 8 of the tutorial gives the two-part check.
Network and account
Going online with a patched kernel risks a PSN ban, and that risk is yours. Keeping the console offline during experiments also stops an update quietly moving you off 14.00.
This build makes no network call, and the security page shows the four measurements behind that claim along with the one host you may want to block at your firewall as a precaution.
Reduce the blast radius first
- Copy important saves to USB or cloud.
- Confirm firmware is exactly 14.00 before you burn anything.
- Burn at the slowest supported speed with verify-after-write on. Most failures people blame on an exploit are bad optics.
- Photograph the screen on every attempt. The exact last line is the difference between a diagnosis and a guess.
- Do not run this on a console you cannot afford to re-initialise.
What I have verified, and how
I ran this disc on my own PS4 at firmware 14.00 and it worked: the preflight passed, one press of X started the sequence, and HEN applied. That is my machine, my burner and one brand of disc.
Everything else on this site is either measured from the published files (sizes, digests, the 78-entry JAR, the 38 file extents, the signature, the twenty-five preflight checks, the absence of any caller of the remote-control routine) or read off the disc's own structures. The order of the messages on screen comes from those structures rather than from a recording of your console. Anyone telling you a kernel exploit is safe is selling something.