Vulnerabilities

From PS4 Developer wiki
Jump to navigation Jump to search

See also Bugs for potential vulnerabilities.

See also Exploit Chains for a simpler overview of different Vulnerabilities getting chained together.

Editor's note:
  • The goal of this page is to summarize various Vulnerabilities being discovered for the PlayStation 4, but you can also mention the same effectiveness on another PlayStation console(s).
  • If you add an Vulnerability being released by another developer(s) - especially from one(s) outside of this wiki - please make sure that you credit them accordingly including a source. If they share their own "Credits" on given source, make sure not to modify their text here.
  • However, if you want to share your own findings, based on your own research, you are welcome as well. You will need to separate that information however from the original release of the previously credited developer(s).
  • If you can share additional information, like explanations of a specific Vulnerability, you are welcome to add them here as well. These must also need to be separated from the original release of the previously credited developer(s).
  • Since a "wiki" is a open-collaborative encyclopedia for everyone, it can't be held responsible for content inside this page that is not supposed to be made public. If you edit this page, keep the consequences in your mind. In addition to that, if you are the original author of a specific Vulnerability and you see something that is not supposed to be public, we won't handle any requests of removing content because we don't do any censorship etc. here. It is in your own interest to whom you share your own findings to whomsoever and wheresoever in private.
  • Please avoid any type of "self-promotion" as much as possible here. It is preferred to keep the grammar on this page in a indirect discourse (reported speech).
  • To avoid confusions or questions to the original developer(s), please avoid also mentioning (untested) Vulnerabilities based on pure speculation. If they are for some reason really necessary to be mentioned, please mark them being "speculative".
  • If you are in conflict with edits from another user, feel free to open a discussion on the Talk Page of this article. Please respect each other, no matter if you are a new user or the original author of specific Vulnerability. Thank you.
  • Because of the high traffic, the page and its content is monitored by the Staff. If you have further questions, feel free to contact them.


Usermode Exploits (Game Savedata)[edit | edit source]

PS1 games savedata exploits[edit | edit source]

See PS1 Emulation for a list of candidate games.

See PS1 Dev Wiki for a list of PS1 savedata exploits.

PS2 games savedata exploits[edit | edit source]

See PS2 Emulation for a list of candidate games.

Some PS2 games exploitable on PS4 and PS5 are:

  • Okage: Shadow King UP9000-CUSA02199_00-SCUS971290000001 or EP9000-CUSA02282_00-SCUS971290000001, requires PS4 FW version 3.15, although it was compiled with PS4 SDK version 3.008.000, latest patch requires PS4 FW 4.05 "2016-03-22"
  • Star Wars™: Racer Revenge™ (US version, by Limited Run #290) UP1082-CUSA03474_00-SLUS202680000001. The disc contains patch version 1.02 so requires PS4 4.05 at least.

See PS2 Dev Wiki for a list of PS2 savedata exploits.

PSP games savedata exploits[edit | edit source]

See PSP Emulation for a list of candidate games.

See PSP Dev Wiki for a list of PSP savedata exploits.

PS4/PS5 PS2emu sandbox escape - codename mast1c0re[edit | edit source]

Advantages of the PS4/PS5 PS2emu sandbox escape exploit over most WebKit exploits:

  • Bigger kernel attack surface (more usermode privileges) versus WebKit very restricted and becoming more and more with firmware revisions. For example, the PS2emu process uses libkernel_sys, which supports nmount and so mounting of system partitions, whilst neither libkernel_web nor regular libkernel do.
  • 100% reliable versus WebKit exploits becoming less and less stable with System Software revisions.
  • Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three System Software update.

Drawbacks:

  • Depending on the base PS2 game, triggering the exploit can require user interaction for example in menus to load the savedata or to display highscores.

Credits[edit | edit source]

  • CTurt for discovering these vulnerabilities in September 2021.
  • CTurt for public disclosure on twitter (2022-09-14).
  • flatz, balika011, TheFloW, chicken(s), PlayStation for helping CTurt.
  • McCaulay for sharing publicly his implementation in February 2023.
  • Gezine for leveraging the Lua 5.3 interpreter (2026-01-13)

Analysis[edit | edit source]

Bug Description[edit | edit source]

After getting code execution in a PS2onPS4 game using a savedata exploit, it is possible to exploit the PS2 emulator to get x86-64 usermode ROP execution. It is then possible, without a kernel exploit, to load another PS2 game in the emulator with a compatibility rate based on the PS2 emulator configuration.

One can use the PS2emu sandbox escape to leverage the Lua 5.3 interpreter embedded in the main PS2emu executable. This Lua interpreter is originally intended for the PS2 Classics Configuration Files (Official). Lua scripting simplifies code writing and execution when reusing PS4/PS5 usermode ROP chains written in Lua scripts developed originally for PS4/PS5 game savedata Lua exploit. PS4/PS5 ROP execution via interpreted Lua script is maybe less efficient than compiled PS2 binaries.

Implementation[edit | edit source]

Patched[edit | edit source]

No as of PS4 FW 13.04 and PS5 FW 12.70. Using the PS2onPS4 game Okage Shadow King, the exploit should work starting from PS4 FW 3.15 and PS5 FW 2.00.

PS4/PS5 PS2emu JIT native execution - codename mast1c0re part 2[edit | edit source]

Credits[edit | edit source]

  • CTurt for discovering and disclosing many PS2emu JIT compiler vulnerabilities in September 2021.
  • flatz, balika011, TheFloW, chicken(s), PlayStation for helping CTurt.
  • Gezine for making a working complete PS2emu JIT compiler exploit on 2026-03-14.

Analysis[edit | edit source]

Bug Description[edit | edit source]

After exploiting the PS2 emulator to get x86-64 usermode ROP execution, it is possible to exploit the JIT compiler of the PS2 emulator to write native x86-64 instructions to executable memory.

As of now, the only supported PS2onPS4 game for JIT native execution is Star Wars: Racer Revenge because some other tested games like Okage Shadow King use a newer PS2 emulator that does not seem vulnerable to Gezine's final JIT vulnerability.

Implementation[edit | edit source]

Patched[edit | edit source]

No as of PS4 FW 13.50 and PS5 FW 13.00. Using the PS2onPS4 game Star Wars: Racer Revenge, the exploit should work starting from PS4 FW 4.05 and PS5 FW 2.00.

PS4/PS5 game savedata Lua exploit[edit | edit source]

Credits[edit | edit source]

  • Used by Flatz on 2023-07-27 in his Hypervisor exploit.
  • Used by Flatz on 2024-09-14 in his implementation of the umtx UaF kernel exploit.
  • Lua sandbox escape researchers notably Peter Cawley (corsix), erezto, Morgan Jones (numinit), Maxim Ivanov (ulidtko)
  • Gezine, shahrilnet and null_ptr (n0llptr) for implementations of the Artemis engine PS4 games savedata Lua 5.1 exploit
  • shuffle2 from fail0verflow for the Don't Starve PS4 savedata Lua 5.1.4 exploit released on 2026-03-15
  • earthonion for improvements to the Don't Starve PS4/PS5 savedata Lua 5.1.4 exploit disclosed by fail0verflow

Bug description[edit | edit source]

Some PS4 (and maybe also PS5) games can be exploited since they let an attacker execute Lua code by crafting an evil save data. By running malicious Lua code, the attacker can escape the Lua sandbox and obtain usermode arbitrary read-write then ROP chain execution in usermode. To setup such an exploit, the user has to copy some custom resigned savedata files to the console.

On PS3 and PS Vita, you can simply install the DRM Free demo of a game that uses Lua, the same way as you would install the Bitter Smile demo (see h-encore by TheFloW) on the PS Vita. If you have access to the PS4/PS5 PS Store, meaning that the console has been updated to latest System Software, you can simply download the trial version of a game.

Artemis engine is known to use Lua and so is vulnerable to various sandbox escape exploits. Most of Artemis games automatically load save9999.dat file from save data folder when the game boots. By editing this file, one can load custom Lua scripts. Game boots -> "save9999.dat" is loaded -> "inject.iet" is loaded -> "inject.lua" is loaded. You might have to create a different save9999.dat file for each game as the Lua interpreter version might differ. On Windows, Lua scripts have access to privileged functions like luasocket and os.execute however on PS3/PS Vita/PS4/PS5, they have limited access but can use sandbox escape exploits.

The PSP, PS1 and PS2 emulator for PS4 and PS5 use Lua 5.3 to run Lua scripts. These Lua scripts are usually not stored in savedata but in game data so cannot be exploited directly except on PS3 and PS Vita <=?3.61? where game data could be modified. However, after getting usermode RW in the PSP, PS1 or PS2 emulator for PS4 and PS5, it is possible to get usermode code execution by exploiting the Lua engine as done in #PS4/PS5_PSP/PS1/PS2emu_Lua_sandbox_escape_-_codename_Luac0re Luac0re.

Some Klei Entertainment games such as Don't Starve and Shank use Lua scripts. Some of them like Don't Starve even store Lua scripts into savedata. By injecting a Lua script in decrypted savedata files then reencrypting them, one can execute Lua code then escape the Lua sandbox to execute arbitrary code in usermode.

Confirmed exploitable Artemis Engine games via Lua 5.1 32-bit in savedata:

  • Raspberry Cube (CUSA16074)
  • Aibeya (CUSA17068)
  • Hamidashi Creative (CUSA27389)
  • Hamidashi Creative Trial (CUSA27390)
  • Aikagi Kimi to Issho ni Pack (CUSA16229)
  • Aikagi 2 (CUSA19556)
  • IxSHE Tell (CUSA17112)
  • IxSHE Tell Trial (CUSA17126)
  • Nora to Oujo to Noraneko Heart HD (CUSA13303)
  • Nora to Oujo to Noraneko Heart 2 (CUSA13586)
  • Jinki Resurrection (CUSA25179)
  • Jinki Resurrection Trial (CUSA25180)
  • Fuyu Kiss (CUSA29745)
  • Fuyu Kiss Trial (CUSA29746)
  • Haruoto Alice * Gram: Snow Drop (CUSA14324)
  • Maid-san no Iru Kurashi (CUSA18106)
  • Mikagami Sumika no Seifuku Katsudou (CUSA11481)
  • となりに彼女のいる幸せ～Two Farce～ (CUSA09825)
  • となりに彼女のいる幸せ～Winter Guest～ (CUSA11977)
  • となりに彼女のいる幸せ～Summer Surprise～ (CUSA18998)
  • Sen no Hatō, Tsukisome no Kōki (DEMO) (CUSA09650)
  • Sen no Hatō, Tsukisome no Kōki (CUSA09647)
  • Azayaka na Irodori no Naka de, Kimi Rashiku (CUSA10679)
  • Boku to Joi no Shinsatsu Nisshi (CUSA18107)
  • Boku to Nurse no Kenshuu Nisshi (CUSA12049)
  • Amamane (CUSA17048)
  • Doukyuusei Remake CSver Trial (CUSA47117)
  • Doukyuusei Remake CSver (CUSA45810)
  • Dōkyūsei: Bangin' Summer - Home Edition Trial (CUSA50447, CUSA50448, CUSA50449)
  • Dōkyūsei: Bangin' Summer - Home Edition (CUSA47130, CUSA47131, CUSA47132)
  • Aerial Life (CUSA17122)
  • Aikano ~Yukizora no Triangle~ (CUSA19370)
  • COSPLAY LOVE! : Enchanted princess (CUSA33083)
  • untested: となりに彼女のいる幸せ～Curious Queen～ (CUSA19555)
  • untested: となりに彼女のいる幸せ～i fight with summer～ (CUSA34541)
  • untested: となりに彼女のいる幸せ～in first snow with her～ (CUSA37878)

See also Artemis Engine and Visual Novels for a list of candidate games.

Confirmed exploitable Klei Entertainment games:

  • Don't Starve (CUSA00158), using Lua 5.1.4 ?64-bit? [1]. The PS Vita version (Giant Edition) is also vulnerable to Lua 5.1.4 32-bit script injection via savedata (see the HENkaku wiki) and is very similar to the PS4 version. The PS3 version (Giant Edition) is also vulnerable but savedata files structure differ from the PS Vita and PS4 versions.
  • Maybe other editions of Don't Starve are vulnerable.

Other games that may use Lua scripts:

Analysis[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

No as of PS4 FW 13.04 and PS5 FW 12.70.

PS4/PS5 game savedata Ren'Py exploit - codename YARPE[edit | edit source]

Credits[edit | edit source]

  • People who disclosed Ren'Py vulnerabilities on other platforms than PS4 and PS5, notably on PC
  • Helloyunho, helped by DrYenyen and Gezine for implementing the first RenPy game savedata exploit for PS4 and PS5, named YARPE (Yet another Ren'Py PlayStation exploit) and disclosing it publicly (2025-11-02)

Bug description[edit | edit source]

Some PS4 (and maybe also PS5) games can be exploited since they let an attacker execute Python code by crafting an evil save data. By running malicious Python code, the attacker can escape the Python sandbox and obtain usermode arbitrary read-write then ROP chain execution in usermode.

Vulnerable games[edit | edit source]

See Visual Novels for a list of candidate games.

Confirmed exploitable games:

  • A YEAR OF SPRINGS, PS4 version (CUSA30428, CUSA30429, CUSA30430, CUSA30431)
  • Untested: A YEAR OF SPRINGS, PS5 version (PPSA05310, PPSA05311, PPSA05312, PPSA05313)
  • Arcade Spirits: The New Challengers, PS4 version (CUSA32096, CUSA32097)
  • Arcade Spirits: The New Challengers, PS5 version (PPSA06409, PPSA06410)

Analysis[edit | edit source]

Implementation[edit | edit source]

Related Resources[edit | edit source]

Patched[edit | edit source]

No as of PS4 FW 13.04 and PS5 FW 12.70.

Usermode Exploits (Game Network)[edit | edit source]

See also PS5 Dev Wiki and Bugs.

Usermode Exploits (BD-J)[edit | edit source]

Advantages of most BD-J exploits over most WebKit exploits:

  • Bigger kernel attack surface (more usermode privileges) versus WebKit being very restricted and becoming more and more with firmware revisions. For example, the BD-J process uses libkernel_sys, which supports nmount to mount system partitions, whilst neither libkernel_web nor regular libkernel do.
  • 100% reliable versus WebKit exploits becoming less and less stable with firmware revisions
  • Firmware agnostic (ROP-less code execution) versus almost one WebKit revision every three firmware update
  • JIT enabled in PS4 Java Virtual Machine (JVM) allowing to write a kernel exploit in C versus writing in assembly and JavaScript because JIT was disabled in the PS4 internet browser since around FW 2.00. However, JIT is not enabled in PS5 JVM whilst the PS2emu of some PS2onPS4 games can be exploited to get JIT native execution on PS4 and PS5.

FW <= 13.00 - BD-JB-EX - Sandbox escape via injection in system_ex[edit | edit source]

Credits[edit | edit source]

  • CelesteBlue for proposing exploitation vector #3 (2025-11-23)
  • 15432 for proposing and implementing exploitation vector #1 (2026-02-20)
  • Gezine for proposing and implementing exploitation vector #2 (2026-03-21)

Analysis[edit | edit source]

Bug Description[edit | edit source]

There are vulnerabilities related to internal storage:

  1. Any JAR file in the PlayStation 4 BD-J application lib/ext folder (absolute path /system_ex/app/NPXS20113/bdjstack/lib/ext/) on internal HDD gets maximum permissions.
  2. Some BD-J engine files are unsigned. For example, /system_ex/app/NPXS20113/bdjstack/lib/security/java.security on PS4 or /system_ex/app/NPXS40140/cdc/conf/security/policy/java.security for PS5, is plaintext and is interesting because it has been updated to patch some BD-J vulnerabilities.
  3. It is possible to make a raw backup of the system_ex partition (1 GiB) and to restore it by raw writing to the removed internal HDD if the OS files and encrypted files in that system_ex image are valid for the System Software version to be run.
  4. In case of reinstallation of the same version of the System Software, it is possible to restore the inactive system_ex partition.

There are many vectors to exploit these vulnerabilities:

  1. Inject a malicious 00000.jar to /system_ex/app/NPXS20113/bdjstack/lib/ext/. Thanks to this path, this .jar has AllGranted permissions. This vector, proposed by 15432 on 2026-02-20, has been tested on PS4 <=13.00 and is untested on PS5.
  2. Inject a vulnerable class into /system_ex/app/NPXS20113/bdjstack/bdjstack.jar for PS4 or /system_ex/app/NPXS40140/cdc/bdjstack.jar for PS5. This vector, proposed by Gezine on 2026-03-21, is implemented in BD-UN-JB for PS5 <=12.00 and untested on PS4.
  3. Replace /system_ex/app/NPXS20113/bdjstack/lib/security/java.security or other unsigned BD-J engine files to (re-)enable exploitable classes. This vector, proposed by CelesteBlue on 2025-11-23, is untested on both PS4 and PS5.

The main difficulty in exploiting this vulnerability is that it requires filesystem access to a protected partition of the PS4 internal HDD. The decrypted system_ex partition is mounted as read-only whilst the encrypted system_ex partition is decryptable only with an inaccessible Key handled by AMD SAMU.

The possible methods to write custom files to the decrypted system_ex partition are:

  1. With AES-XTS keys of system_ex encryption, stored in AMD SAMU. This vector is not applicable as of now because there is no known way to dump SAMU keys
  2. With a kernel exploit, it is not only possible to write custom files to the decrypted active system_ex partition but also to the inactive system_ex partition. After updating/downgrading System Software version, it likely is possible. This vector, proposed by CelesteBlue on 2025-11-23, was implemented for PS4 by 15432 on 2026-02-20 and for PS5 by Gezine on 2026-03-21.
  3. With a kernel exploit, it is possible to hijack the System Software updater (see TheoryWrong's works) and this may allow to write to the system_ex partition of the updated System Software where there is potentially no kernel exploit available. This vector, proposed by CelesteBlue on 2025-11-23, is untested. Testing a kernel patch during the System Software process could brick the console and be unrecoverable even with a Serial Flash hardware flasher, because of Syscon.
  4. By removing the internal HDD from the console, then plugging it to a device that can overwrite the encrypted system_ex partition with a valid system_ex image that contains custom files. This system_ex image must be created using a kernel exploit, probably on the same console if system_ex keys are per-console, but not necessarily on the same System Software version as the system_ex keys are probably independent of the System Software version. This vector, proposed by CelesteBlue on 2026-02-21, is untested.

Thanks to these vulnerabilities, BD-JB can be run on any PS4 System Software version, but only if the PS4 used to be on a System Software version that had a kernel exploit.

However, after internal HDD corruption, the console may require to reinstall the System Software on the internal HDD. During the System Software installation process, system_ex is rewritten with an image from the PUP. If an exploit was installed in system_ex, it is removed. Hopefully, if a raw encrypted system_ex backup was made, it is possible to restore this system_ex image by removing the internal HDD from the console and plugging the HDD into a device that can write to it, for example a PC.

Implementation[edit | edit source]

Patched[edit | edit source]

No as of PS4 FW 13.04 and PS5 13.00 but requires a kernel exploit to be installed so limited to PS4 FW <= 13.00 and PS5 12.00 as of now. Probably not patched on PS3, but maybe not affected.

FW <= ?11.00? - PSDescriptorFactory.handles() does not check userprefs path[edit | edit source]

Credits[edit | edit source]

Analysis[edit | edit source]

Bug Description[edit | edit source]

Before the patch (java/com/sony/gemstack/io/factories/ps/PSDescriptorFactory.java on PS4 11.00 and PS3 4.92): 

    public boolean handles(int i, String path) {
        if (tempDir != null && path.startsWith(tempDir)) {
            return false;
        }
        persistentRoot = (String) AccessController.doPrivileged(new PrivilegedAction(this) {
            private final PSDescriptorFactory this$0;
            {
                this.this$0 = this;
            }
            public Object run() {
                return System.getProperty("dvb.persistent.root", "/OS/persistent");
            }
        });
        if (path != null) {
            return path.startsWith(persistentRoot);
        }
        return false;
    }

Before the patch (java/com/sony/gemstack/io/factories/ps/PSDescriptorFactory.java on PS5 12.70): 

   public boolean handles(int i, String path) {
      if (tempDir != null && path.startsWith(tempDir)) {
         return false;
      } else {
         persistentRoot = (String)AccessController.doPrivileged(new 1(this));
         return var2 != null ? path.startsWith(persistentRoot) : false;
      }
   }

Since the patch (java/com/sony/gemstack/io/factories/ps/PSDescriptorFactory.java on PS5 13.00): 

   public boolean handles(int i, String path) {
      if (tempDir != null && path.startsWith(tempDir)) {
         return false;
      } else {
         persistentRoot = (String)AccessController.doPrivileged(new 1(this));
         return var2 != null ? path.startsWith(RootCertManager.getOriginalPersistentRoot()) : false;
      }
   }

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS4 FW ?13.50? and PS5 FW 13.00. Not patched as of PS4 FW 11.00 and PS5 FW 12.70 and PS3 FW 4.92.

FW <= ?9.00? - PSDescriptorFactory.canWriteFile() does not check userprefs path[edit | edit source]

Credits[edit | edit source]

  • CelesteBlue for diffing decompiled 9.00 and 11.00 PS4 BD-J files (2026-03-20)

Analysis[edit | edit source]

Bug Description[edit | edit source]

PSDescriptorFactory.canWriteFile() does not check the userprefs path.

Note that PSDescriptorFactory.canWriteFile() was patched since some PS5 System Software version between 2.00 (unpatched) and 10.01 (patched) but it seems that PSDescriptorFactory.canReadWriteFile() is still unpatched as of PS5 13.00.

Before the patch (java/com/sony/gemstack/io/factories/ps/PSDescriptorFactory.java on PS4 9.00 and PS5 2.00 and PS3 4.92): 

    private static boolean canWriteFile(String userprefsPath) {
        CoreAppId coreAppId = CoreAppContext.getContext().getCoreAppId();
        if (!checkParent(coreAppId, userprefsPath, 2)) {
            return false;
        }
        PSAttributes attributes = PSAttributes.getAttributes(userprefsPath);
        if (attributes != null) {
            return attributes.canAccess(coreAppId, 2);
        }
        PSAttributes.createDefaultAttributes(userprefsPath, coreAppId);
        return true;
    }

Since the patch (java/com/sony/gemstack/io/factories/ps/PSDescriptorFactory.java on PS4 11.00): 

    private static boolean canWriteFile(String userprefsPath) {
        CoreAppId coreAppId = CoreAppContext.getContext().getCoreAppId();
        if (userprefsPath.equals(new StringBuffer().append(RootCertManager.getOriginalPersistentRoot()).append("/userprefs").toString()) || !checkParent(coreAppId, userprefsPath, 2)) {
            return false;
        }
        PSAttributes attributes = PSAttributes.getAttributes(userprefsPath);
        if (attributes != null) {
            return attributes.canAccess(coreAppId, 2);
        }
        PSAttributes.createDefaultAttributes(userprefsPath, coreAppId);
        return true;
    }

Since the patch (java/com/sony/gemstack/io/factories/ps/PSDescriptorFactory.java on PS5 9.60): 

    private static boolean canWriteFile(String userprefsPath) {
        CoreAppId coreAppId = CoreAppContext.getContext().getCoreAppId();
        if (userprefsPath.equals(new StringBuffer().append(RootCertManager.getOriginalPersistentRoot()).append("/userprefs").toString()) || !checkParent(coreAppId, userprefsPath, 2)) {
            return false;
        }
        PSAttributes attributes = PSAttributes.getAttributes(userprefsPath);
        if (attributes != null) {
            return attributes.canAccess(coreAppId, 2);
        }
        PSAttributes.createDefaultAttributes(userprefsPath, coreAppId);
        return true;
    }

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS4 FW 11.00 and maybe earlier and PS5 FW 9.60 and maybe earlier. Not patched as of PS4 FW 9.00, PS5 FW 2.00 and PS3 FW 4.92.

FW 13.04 - BD-JB-13.04 - Path traversal sandbox escape via BDJO and /lib/ext/ .jar infix[edit | edit source]

Credits[edit | edit source]

Analysis[edit | edit source]

Bug Description[edit | edit source]

There is a bug in PS4 BD-J bdjstack.jar/BdjPolicyImpl.java where JAR paths were improperly validated. Using file:///app0/bdjstack/lib/ext/sunjce_provider.jar/../../../../../disc/BDMV/JAR/00000.jar in /disc/BDMV/BDJO/00000.bdjo could trick the runtime into treating an external JAR as if it were $JAVA_HOME/lib/ext/sunjce_provider.jar and grant it AllPermission.

Basing on the BD-JB1 exploit files, in /bdmv/bdjo.xml changing bdjo/applicationManagementTable/baseDirectory to a path of the form file:///app0/bdjstack/lib/ext/sunjce_provider.jar/../../../../../disc/BDMV/JAR/00000.jar allows loading a JAR Java executable file with granted permissions. Due to the Xlet JAR file being loaded relative to $JAVA_HOME/lib/ext/sunjce_provider.jar in bdjo descriptor, com.sony.bdjstack.security.BdjPolicyImpl allows the Xlet JAR to disable security manager.

This vulnerability can efficiently replace the UserPreferenceManagerImpl and BD-JB2 ones to extend the supported System Software versions range.

This vulnerability was introduced in PS4 System Software 13.04 when Sony mitigated BD-JB4.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS4 FW 13.50. Probably not patched on PS3, but maybe not affected.

FW <= 13.02 - BD-JB4 - Path traversal sandbox escape via /lib/ext .jar infix[edit | edit source]

Credits[edit | edit source]

  • Gezine for discovering this vulnerability and disclosing it to the PlayStation HackerOne bug bounty program (2025-12-05) Gezine's tweet
  • zecoxao for diffing decompiled 13.04 and 13.02 BD-J files shared to him by an anonymous (2026-01-28) zecoxao's tweet (2026-01-28)
  • The_Maxu for proposing an exploitation method (2026-01-31)

Analysis[edit | edit source]

Bug Description[edit | edit source]

There is a bug in PS4 BD-J bdjstack.jar/BdjPolicyImpl.java where JAR paths were improperly validated. Using .jar!/../../payload.jar could trick the runtime into treating an external JAR as if it were in lib/ext and grant it AllPermission. In Java, you can use an exclamation mark (!) to access the internal contents of a JAR file and load a specific class. It is called a JAR URL [2][3][4]. It is implemented in JarURLConnection since at least Java version 6. It is one of the easy ways to exploit the bug before the patch. There may be another untested way by using ".jar../../payload.jar" and it could in fact be the one used in BDJB-13.04.

The BD-J stack has a bug in signature verification for nested JARs. When classes are loaded from a nested JAR accessed through JarInputStream, signed JAR files cannot be loaded. Then one has to use unsigned JAR files. When CoreAppId.isSigned() returns false, signature verification is skipped and unsigned class can be loaded. To bypass signature verification, the applicationId in the BDJO file must be > 0x4000 or > 0x7FFFF (outside the ranges 0x0000 to 0x3FFF and 0x80000 to 0xFFFF) as seen in: 

// CoreAppId.java
public boolean isSigned() {
    return (0x4000 <= this.aid && this.aid <= 0x7FFFF);             
}

The bug was partially patched on PS4 System Software 13.04 by trimming the path at .jar before canonicalization. Behaviour on PS4 13.04+: if the path (pointing to a file in $JAVA_HOME+"/ext") contains ".jar", then the path is shortened just after the first occurrence of ".jar" from the left. Example: $JAVA_HOME+"/extWHAT/myjar.jarHELLO.jar" is changed into $JAVA_HOME+"/extWHAT/myjar.jar". This also happen when the ".jar" infix is in a folder name. Example: $JAVA_HOME+"/extWHAT/IamAjarFOLDER.jar/IamAJarFile.jar" is changed into $JAVA_HOME+"/extWHAT/IamAjarFOLDER.jar". By deduction, PS4 <=13.02 BD-J had a vulnerability using a path whose prefix was a privileged .jar.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS4 FW 13.04. Probably not patched on PS3, but maybe not affected.

FW <= 12.50 - BD-JB3 - Sandbox escape via Inter-Xlet Communication (ixc)[edit | edit source]

Credits[edit | edit source]

  • TheFloW for discovering the org.dvb.io.ixc reborn and com.sun.xlet.ixc.WrappedRemote vulnerabilities and reporting them to Sony (2025-04-22)
  • Anonymous for sharing decompiled PS4 12.50 and 12.52 bdjstack.jar, allowing people to see the patched vulnerability by comparison (2025-07-17)
  • Gezine for discovering the com.sun.xlet.ixc.XletManager vulnerability and exploiting it publicly (2025-08-02)
  • Previous BD-JB contributors

Analysis[edit | edit source]

Bug Description[edit | edit source]

There are two implementations for Ixc (Inter-Xlet Communication) in BD-J. One is org.dvb.io.ixc and the other is com.sun.xlet.ixc. By exploiting two vulnerabilities in each of the implementations, it is possible to disable the security manager and escape the Java sandbox.

It was reported afterwards by TheFloW that the com.sun.xlet.ixc vulnerability discovered by Gezine is not the one that TheFloW disclosed at HackerOne on 2025-04-22.

Vulnerability 1 (org.dvb.io.ixc reborn):

To be documented.

Vulnerability 2A (com.sun.xlet.ixc.XletManager):

There is a vulnerability in the createXlet method in XletManager.java. It was discovered by Gezine because in the 12.52 PS4 System Software update, the com.sun.xlet package has been forbidden and it was the only change. This discovery would not have been done publicly this early without Sony patching the System Software thanks to TheFloW's private HackerOne report.

Vulnerability 2B (com.sun.xlet.ixc.WrappedRemote):

The com.sun.xlet.ixc implementation contains a vulnerability that allows privileged method invocation. Namely, the method com_sun_xlet_execute in com.sun.xlet.ixc.WrappedRemote invokes remoteMethod in a AccessController.doPrivileged block: 

		       AccessController.doPrivileged(
			  new PrivilegedExceptionAction() {
			     public Object run() throws RemoteException {
				Throwable err = null;
				try {
				    result[0] = remoteMethod.invoke(targetNow, args);
				} catch (InvocationTargetException ite) {
				    err = ite.getTargetException();
				} catch (Throwable t) {
				    err = t;
				}
				// ...
				return null;
			    }
			}
		       , context);

This method is accessible through the stub class that is generated when registering an object via com.sun.xlet.ixc.IxcClassLoader: 

  public final class StubClass$$42 extends com.sun.xlet.WrappedRemote 
		implements UserIF {

      private static Method com_sun_xlet_method0;
      private static Method com_sun_xlet_method1;


      public static void com_sun_xlet_init(Method findMethodMethod) 
              throws Exception {
       	// findMethodMethod is Utils.findMethod for the ClassLoader
		// where thetarget* Remote object lives.
       
          if (com_sun_xlet_method0 != null) {
	        return;
          }
          com_sun_xlet_method0 = (Method) findMethodMethod.invoke(null,
		new Object[] { "UserIF", "frob", new Object[] { "Something" }});
          com_sun_xlet_method1 = (Method) findMethodMethod.invoke(null,
		new Object[] { "UserIF", "glorp", 
                             new Object[] { java.lang.Float.TYPE }});
      }

      public static void com_sun_xlet_destroy() {
          com_sun_xlet_method0 = null;
          com_sun_xlet_method1 = null;
      }

      public StubClass$$42(Remote target, ImportRegistryImpl registry,
			     RegistryKey key) {
	    super(target, registry, key);
	}

      public void frob(Something arg1) throws org.dvb.ixc.RemoteException {
          com_sun_xlet_execute(com_sun_xlet_method0, 
				   new Object[] { arg1 });
      }

      public int glorp(float arg1) throws org.dvb.ixc.RemoteException {
	    Object r = com_sun_xlet_execute(com_sun_xlet_method1,
					      new Object[] { new Float(arg1) });
          return ((Integer) r).intValue();
      }
  }

To exploit the privileged method invocation, com_sun_xlet_method0 needs to be set to something interesting. Consider the following fake System class: 

public interface SystemInterface extends java.rmi.Remote {
  void setSecurityManager(java.rmi.Remote sm) throws java.rmi.RemoteException;
}

public class SystemImpl implements SystemInterface {
  public void setSecurityManager(java.rmi.Remote sm) {}
}

Create an instance of this class and register it via com.sun.xlet.ixc.IxcRegistryImpl (that is achieved by exploiting Vulnerability 1). On the remote object of the stub class, call com_sun_xlet_destroy to set com_sun_xlet_method0 to null and then call com_sun_xlet_init with a custom findMethod method as argument: 

  public static Object findMethod(String cName, String mName, Object[] types)
      throws NoSuchMethodException {
    return System.class.getMethod(
        "setSecurityManager", new Class[] {SecurityManager.class});
  }

This will set com_sun_xlet_method0 to the real System.setSecurityManager. Now, when calling setSecurityManager(null) on the remote SystemImpl object, the invocation System.SecurityManager(null) will be made instead. This effectively disables the Java sandbox.

Although the com.sun.xlet.ixc vulnerability works on PS4, it does not work on PS5 because com.sun.xlet package is not exported from the PS5 BD-J java.p module.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS4 FW 12.52. Probably not patched on PS3, but maybe not affected.

Since the patch, the blacklist in the text file system_ex/app/NPXS20113/bdjstack/lib/security/java.security has been updated to forbid packages of the namespace com.sun.xlet. ?and how was patched org.dvb.io.ixc?.

FW <= 12.52 - BD-JB2 - Path traversal sandbox escape via BDJO and /cdc/lib/[edit | edit source]

Credits[edit | edit source]

  • TheFloW for the exploits finding (before 2023-09-11), ethical disclose to SCE (2023-09-22) and public disclosure (2023-10-25)
  • Previous BD-JB contributors
  • Gezine for confirming that the path traversal sandbox escape still worked up to PS4 System Software 12.52 and chaining it with BD-JB3 (2025-08-02)

Analysis[edit | edit source]

Bug Description[edit | edit source]

There is a bug in PS4 BD-J bdjstack.jar/BdjPolicyImpl.java where JAR paths were improperly validated. Using file:///app0/cdc/lib/../../../disc/BDMV/JAR/00000.jar in /disc/BDMV/BDJO/00000.bdjo could trick the runtime into treating an external JAR as if it were in $JAVA_HOME/lib/ and grant it AllPermission.

Basing on the BD-JB1 exploit files, in /bdmv/bdjo.xml changing bdjo/applicationManagementTable/baseDirectory to a path of the form file:///app0/cdc/lib/../../../disc/BDMV/JAR/00000.jar allows loading a JAR Java executable file with granted permissions. Due to the Xlet JAR file being loaded relative to $JAVA_HOME/lib/ in bdjo descriptor, com.sony.bdjstack.security.BdjPolicyImpl allows the Xlet JAR to disable security manager.

This vulnerability can efficiently replace the UserPreferenceManagerImpl one to extend the supported System Software versions range.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS4 FW 13.00 and PS5 FW 8.00. Probably not patched on PS3, but maybe not affected (com.sony.bdjstack.security.BdjPolicyImpl is present in PS3 bdjstack.jar).

FW <= 9.00 - BD-JB - Five vulnerabilities chained by TheFloW[edit | edit source]

Credits[edit | edit source]

  • CTurt for FreeDVDBoot exploit on PS2 and the idea to hack BD-J on PS3 and PS4 on twitter (2020-06-27)
  • TheFloW for finding these vulnerabilities (around 2021-10-24) and disclosing them publicly on hackerone and hardwear.io (2022-06-10)
  • Sleirsgoevy for writing the first public implementation for PS4 (2022-06-16) and discovering a sandbox escape for PS5 (2022-07-12)
  • psxdev, sleirsgoevy and John Törnblom for the public implementations

Analysis[edit | edit source]

Bug Description[edit | edit source]

This exploit chain alone does not allow one to run pirated games on PS4 or PS5 as there is not enough RAM allowed in the BD-J process and there are other constraints.

  1. Escalate privileges
    1. Search for AccessController.doPrivileged calls
    2. Trick into loading payload class with all permissions
  2. Disable security manager
    1. Set security manager to null
  3. Install native API
    1. Access native memory using sun.misc.Unsafe ([5], see https://openjdk.org/jeps/498, seems not supported by PS3) or using a custom internal unsafe class and Reflect ([6], [7]) or without using Reflect ([8])
    2. Find native functions using java.lang.ClassLoader$NativeLibrary.findEntry
    3. Call native functions using setjmp and __Ux86_64_setcontext via multi_allocate
  4. Execute arbitrary code (on PS4 only)
    1. Send malicious requests to compiler process to write payload
#1 - com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl userprefs hijack (?PS3?, PS4, PS5)[edit | edit source]

com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl userprefs hijack leads to classes instantiation under privileged context.

The com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl class deserializes the userprefs file under privileged context using readObject() which is insecure: 

    private void initPreferences() {
        try {
            UserPreferenceManagerImpl.preferences = AccessController.doPrivileged((PrivilegedExceptionAction<String[][]>)new ReadPreferenceAction());
        }
        catch (PrivilegedActionException ex) {}
        if (UserPreferenceManagerImpl.preferences == null) {
            UserPreferenceManagerImpl.preferences = new String[UserPreferenceManagerImpl.PREFERENCES.length][];
        }
        if (UserPreferenceManagerImpl.preferences[3] == null) {
            UserPreferenceManagerImpl.preferences[3] = new String[] { "26" };
            this.savePreferences();
        }
    }

    private static class ReadPreferenceAction implements PrivilegedExceptionAction
    {
        public Object run() throws Exception {
            String[][] array = null;
            ObjectInputStream objectInputStream = null;
            try {
                objectInputStream = new ObjectInputStream(new BufferedInputStream(new FileInputStream(RootCertManager.getOriginalPersistentRoot() + "/userprefs")));
                array = (String[][])objectInputStream.readObject();
            }
            finally {
                if (objectInputStream != null) {
                    objectInputStream.close();
                }
            }
            return array;
        }
    }

This vulnerability is powerful on PS4 System Software 5.07 and earlier (and maybe later but before 9.00) where the OpenJDK was not updated with commit commit 020204a (2017-05-19) since an attacker could instantiate a ClassLoader subclass to call defineClass with all permissions and finally bypass the security manager.

On PS4 System Software 5.50 and later and PS5, exploiting this deserialization vulnerability is harder and has not been implemented as of now.

The PS3 is probably also affected because its bdjstack.jar contains com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl, and should also be easily exploited like on PS4 <= 5.07.

The deserialization vulnerability seems to have remained unmitigated til some PS4 System Software version after 11.00 (probably patched on 13.50) and PS5 System Software version 12.70 or 13.00. The mitigation present on PS5 13.00 consists in checking that the structure of the userprefs file is not malformed.

Before the patch (PS4 11.00): 

        public Object run() throws Exception {
            ObjectInputStream objectInputStream = null;
            try {
                objectInputStream = new ObjectInputStream(new BufferedInputStream(new FileInputStream(new StringBuffer().append(RootCertManager.getOriginalPersistentRoot()).append("/userprefs").toString())));
                String[][] ret = (String[][]) objectInputStream.readObject();
                if (objectInputStream != null) {
                    objectInputStream.close();
                }
                return ret;
            } catch (Throwable th) {
                if (objectInputStream != null) {
                    objectInputStream.close();
                }
                throw th;
            }
        }

Before the patch (PS5 12.60): 

   public Object run() throws Exception {
      String[][] ret = (String[][])null;
      ObjectInputStream objectInputStream = null;
      try {
         String userprefsPath = RootCertManager.getOriginalPersistentRoot() + "/userprefs";
         objectInputStream = new ObjectInputStream(new BufferedInputStream(new FileInputStream(userprefsPath)));
         ret = (String[][])objectInputStream.readObject();
      } finally {
         if (objectInputStream != null) {
            objectInputStream.close();
         }
      }
      return ret;
   }

Since the patch (PS5 13.00): 

   private static boolean checkClassDesc(DataInputStream userprefsDataInputStream, String formatString) throws IOException {
      if (userprefsDataInputStream.readByte() != 114) { // offset cur+0: 0x72
         return false;
      } else if (userprefsDataInputStream.readShort() != formatString.length()) { // offset cur+1: 20 (43 in TheFloW's PayloadClassLoader.ser)
         return false;
      } else {
         byte[] userprefsFormatStringBytes = new byte[formatString.length()]; // size = 19 or 20
         userprefsDataInputStream.readFully(userprefsFormatStringBytes); // offset cur+3
         if (!(new String(userprefsFormatStringBytes)).equals(formatString)) { // offset cur+3: "[[Ljava.lang.String;" or "[Ljava.lang.String;" ("com.bdjb.exploit.sandbox.PayloadClassLoader" in TheFloW's PayloadClassLoader.ser)
            return false;
         } else {
            userprefsDataInputStream.readLong(); // offset cur+formatString.length(): does not matter ("AAAAAAAA" in TheFloW's PayloadClassLoader.ser)
            if (userprefsDataInputStream.readByte() != 2) { // offset cur+formatString.length()+8: 2
               return false;
            } else if (userprefsDataInputStream.readShort() != 0) { // offset cur+formatString.length()+9: 00 00
               return false;
            } else if (userprefsDataInputStream.readByte() != 120) { // offset cur+formatString.length()+11: 0x78
               return false;
            } else {
               return userprefsDataInputStream.readByte() == 112; // offset cur+formatString.length()+12: 0x78
            }
         }
      }
   }

   private static boolean checkUserPrefFile(DataInputStream userprefsDataInputStream) throws IOException {
      if (userprefsDataInputStream.readShort() != -21267) { // offset 0: AC ED magic
         return false;
      } else if (userprefsDataInputStream.readShort() != 5) { // offset 2: 00 05 magic
         return false;
      } else if (userprefsDataInputStream.readByte() != 117) { // offset 4: 0x75 (0x73 in TheFloW's PayloadClassLoader.ser)
         return false;
      } else if (!checkClassDesc(userprefsDataInputStream, "[[Ljava.lang.String;")) { // '[' for arrays, 'L' for non-array object types
         return false;
      } else {
         int count = userprefsDataInputStream.readInt(); // offset 0x29: variable
         for(int i = 0; i < count; ++i) {
            if (userprefsDataInputStream.readByte() != 112 && userprefsDataInputStream.readByte() == 117) { // 0x70 or 0x75
               if (!checkClassDesc(userprefsDataInputStream, "[Ljava.lang.String;")) { // '[' for arrays, 'L' for non-array object types
                  return false;
               }
               int count2 = userprefsDataInputStream.readInt();
               for(int j = 0; j < count2; ++j) {
                  if (userprefsDataInputStream.readByte() != 116) { // 0x74
                     return false;
                  }
                  short skipBytesCount = userprefsDataInputStream.readShort();
                  userprefsDataInputStream.skipBytes(skipBytesCount);
               }
            }
         }
         return true;
      }
   }

   static boolean access$100(DataInputStream userprefsDataInputStream) throws IOException {
      return checkUserPrefFile(userprefsDataInputStream);
   }

   public Object run() throws Exception {
      String[][] ret = (String[][])null;
      ObjectInputStream objectInputStream = null;
      try {
         String userprefsPath = RootCertManager.getOriginalPersistentRoot() + "/userprefs";
         DataInputStream dataInputStream = new DataInputStream(new FileInputStream(userprefsPath));
         boolean isValidUserPrefFile = UserPreferenceManagerImpl.access$100(dataInputStream);
         dataInputStream.close();
         if (isValidUserPrefFile) {
            objectInputStream = new ObjectInputStream(new BufferedInputStream(new FileInputStream(userprefsPath)));
            ret = (String[][])objectInputStream.readObject();
         }
      } finally {
         if (objectInputStream != null) {
            objectInputStream.close();
         }
      }
      return ret;
   }
#2 - com.oracle.security.Service leads to privileged constructor call (not PS3, PS4, not PS5)[edit | edit source]

com.oracle.security.Service leads to privileged constructor call.

The class com.oracle.security.Service contains a method newInstance which calls Class.forName on an arbitrary class name. This allows arbitrary classes, even restricted ones (for example in sun.), to be instantiated. This works for all classes with public constructors that have single arguments. The check in newInstance can be bypassed by calling com.oracle.ProviderAdapter.setProviderAccessor on a custom ProviderAccessor implementation. 

        if (!this.registered) {
            if (ProviderAdapter.getService(this.provider, this.type, this.algorithm) != this) {
                throw new NoSuchAlgorithmException("Service not registered with Provider " + this.provider.getName() + ": " + this);
            }
            this.registered = true;
        }
  • The PS3 is probably not affected because it does not have the com.oracle package and does not have the rt.jar file unlike the PS4.
  • The PS5 is not affected because ???
#3 - com.sony.gemstack.org.dvb.io.ixc.IxcProxy leads to privileged method call (?PS3?, PS4, PS5)[edit | edit source]

On the PS4 and PS5, there are two implementations for IXC (Inter-Xlet Communication) in BD-J: org.dvb.io.ixc/com.sony.gemstack.org.dvb.io.ixc (in bdjstack.jar) and com.sun.xlet.ixc (in rt.jar). On the PS3, there are org.dvb.io.ixc (in bdjstack.jar) and com.ibm.oti.xlet.ixc (in pbpuiformhp.jar). By exploiting a vulnerability in org.dvb.io.ixc, it is possible to disable the security manager and escape the Java sandbox. The org.dvb.io.ixc implementation uses com.sony.gemstack.org.dvb.io.ixc.IxcProxy which allows invoking methods in privileged context.

This vulnerability was mitigated since PS4 ?9.50? by checking that the method is called from a call stack that includes the com.sony.gemstack.org.dvb.io.ixc.IxcProxy class. 

      try {
         var4 = (Class[])AccessController.doPrivileged(new IxcProxy.GetCallStackAction());
      } catch (PrivilegedActionException var9) {
      }

      if (var4 != null && var4.length > 2) {
         for(int var5 = 0; var5 < var4.length; ++var5) {
            String var6 = var4[var5].getName();
            if (var6.equals("com.sony.gemstack.org.dvb.io.ixc.IxcProxy")) {
               String var7 = var4[var5 + 1].getName();
               if (!var7.startsWith("org.dvb.io.ixc.") && !var7.startsWith("com.sony.gemstack.org.dvb.io.ixc.")) {
                  throw new SecurityException("illegal call of invokeMethod");
               }
               break;
            }
         }
      }

However, this mitigation was later shown to be insufficient, as methods from a real proxy class (built by com.sony.gemstack.org.dvb.io.ixc.IxcProxyBuilder) are still allowed to be invoked in privileged context. See HackerOne report for the second org.dvb.io.ixc vulnerability by TheFloW (2025-04-22).

#4 - JVM JIT compiler hack (?PS3?, PS4, not PS5)[edit | edit source]

A PS4 JVM JIT compiler hack leads to usermode arbitrary RW and native usermode arbitrary code execution. This has severe implications:

  • An ELF loader can be written to load and execute pirated games. Note that only 32MB (a bit less because of JVM needs) of JIT memory can be allocated by the compiler, a severe limitation in running most PS4 games. Moreover, sleirsgoevy demonstrated that at least 96MB of data were allocatable in BD-J on PS4 (see power-of-bdj).
  • Kernel exploitation on PS4 becomes trivial as there is no SMEP and one can simply jump to a kernel shellcode stored in usermode with a corrupted kernel function pointer.
#5 - UDF buffer overflow (?PS3?, PS4, PS5)[edit | edit source]

The UDF driver in kernel contains a buffer overflow. Note that no implementation of the UDF kernel exploit has ever been done even by TheFloW, only a kernel panic PoC.

  • The PS3 may be vulnerable since it has an UDF driver but it may use a different implementation.

Implementation[edit | edit source]

Patched[edit | edit source]

No as of PS4 FW 9.00 and PS5 FW 4.03. At least partially patched on PS4 FW 9.50 and PS5 FW 5.00.

On PS4 FW 9.03 and PS5 FW ?4.50?, the bug #5 (UDF) has been patched.

Old Java vulnerabilities and write-ups[edit | edit source]

Usermode Exploits (WebKit)[edit | edit source]

FW 6.00-9.60 - FrameLoader::loadInSameDocument() UaF (CVE-2022-22620) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Sergei Glazunov, Google Project Zero, for reporting the bug in 2013-01 and answering Maddie Stone's questions in 2022 (2013)
  • Maddie Stone, Google Project Zero, for sharing a write-up describing this vulnerability (2022-06-14)
  • abc (anonymous) for making an OOM PoC for webkit-gtk, PS4 and PS5 (2023-10-03) then making an arbitrary RW PoC (PSFree) for webkit-gtk, PS4 6.00-9.60 and PS5 1.00-5.50 (2023-10-24)
  • CelesteBlue for testing and porting abc' PSFree to PS4 6.00-9.60 and PS5 1.00-5.50 (2023-11-04)

Analysis[edit | edit source]

Bug Description[edit | edit source]

The History API allows access to (and modification of) a stack of the pages visited in the current frame, and these page states are stored as a SerializedScriptValue. The History API exposes a getter for state, and a method replaceState() which allows overwriting the "most recent" history entry.

The bug is that FrameLoader::loadInSameDocument() takes the state as an argument (stateObject), but does not increase its reference count. Only a HistoryItem object holds a reference to the stateObject. loadInSameDocument() can trigger a callback into user JavaScript through the onblur event. The user's callback can call replaceState() to replace the HistoryItem's state with a new object, therefore dropping the only reference to the stateObject. When the callback returns, loadInSameDocument() will still use this free'd object in its call to statePopped(), leading to the use-after-free.

When loadInSameDocument() is called it changes the focus to the element its scrolling to. If we set the focus on a different element prior to loadInSameDocument()'s execution, the blur event will be fired on that element. Then we can free the stateObject by calling replaceState() in the onblur event handler.

The bug is triggered by history.back() with the target state whose URL contains a hash. Here's a Proof-of-Concept that will crash: 

input = document.body.appendChild(document.createElement('input'));

foo = document.body.appendChild(document.createElement('a'));
foo.id = 'foo';

function pop(event) {
    alert('you get a crash after you close this alert');
    event.state; // use the freed SerializedScriptValue
    alert('WebKit version not vulnerable');
}

addEventListener('popstate', pop);

history.pushState('state1', '', location + '#foo'); // URL with a hash
history.pushState('state2', '');

setTimeout(() => {
    input.focus();
    input.onblur = () => {
        history.replaceState('state3', '')
    };
    setTimeout(() => {
        history.back(); // trigger loadInSameDocument()
    }, 1000);
}, 1000);

The user may then trigger a double free and escalate it into an arbitrary read primitive via spraying WTF::StringImpls like in the buildBubbleTree() UaF exploit. The read primitive is used to create the addrof() primitive and is used to save addresses of buffers that will be used to modify a SerializedScriptValue. After freeing the StringImpl (triple free), SerializedScriptValues are sprayed via the postMessage() JavaScript function until one is allocated using the previously freed memory.

The method used to modify the fields of the StringImpl for arbitrary reads can be used can also be used to modify the SerializedScriptValue. Appropriate fields can modified to have deserialization create a JSC::JSArrayBufferView whose m_vector field will point to another JSArrayBufferView, which will be called the worker. The user can modify the worker's fields for arbitrary read/write. Deserialization is done via msg.data where msg is the MessageEvent from postMessage().

A way to know if the system is vulnerable is the appearance of the input HTML element in the PoC page. If the HTML input field stays focused (blue outline) after the second timeout, then the vulnerability is not present. Note that Maddie Stone's PoC will never trigger any sort of crash on release builds as it was meant for builds with memory sanitation that can detect UaFs.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes on PS4 FW 10.00 and PS5 FW 6.00.

The patch changes the stateObject argument to loadInSameDocument from a raw pointer, SerializedScriptValue*, to a reference-counted pointer, RefPtr<SerializedScriptValue>, so that loadInSameDocument now increments the reference count on the object.

Tested[edit | edit source]

Tested working on PS4 FWs 6.00-9.60 and PS5 FWs 1.00-5.50. PS4 FWs <= 5.56 are invulnerable as the HTML input field stays focused (blue outline) after second timeout whilst it should not if the console were exploitable.

FW 9.00-9.04 - WebCore::CSSFontFaceSet vulnerabilities leading to arbitrary RW[edit | edit source]

There are many FontFaceSet vulnerabilities. Explore [10].

Credits[edit | edit source]

  • Myles C. Maxfield (litherum), Apple, for adding the vulnerability in WebKit (2016-02-22) then fixing and so disclosing the vulnerability (2021-08-26)
  • Maddie Stone, Google Project Zero, for sharing a write-up describing this vulnerability (2021-10-13)
  • PS Test discord server community for testing PoCs of many WebKit vulnerabilities on their PS4s (2021-10-13)
  • sleirsgoevy for making the first exploit PoC for Safari (2021-10-24) and the first exploit PoC for PS4 FW 9.00-9.04 and PS5 FW 3.00-4.50 (2021-10-27)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Description in WebKit fix commit by Myles C. Maxfield:

After r256659, asking for a failed CSSFontFace's families() returns nullopt. It is possible to add a failed font to a CSSFontFaceSet (of course). When we do that, we recognize the font is failed and do not update our internal data structures, because there's no need to - we cannot do anything useful with a failed font. If you _then_ try to remove the font from the CSSFontFace, we do not call families(), but instead just pull out the raw m_families member, and look in our internal data structures for it, but we do not find it, because it was never added.

Description in Maddie Stone's write-up:

The vulnerability is a use-after-free due to an unchecked end() iterator. There was an assert statement: ASSERT(iterator != m_facesLookupTable.end());, but ASSERTs do not do anything in release builds. Therefore, even if iterator == m_facesLookupTable.end() in the release build, nothing would happen and iterator would still be used. In FontFaceSet a FontFace is not added to the faces lookup table in addToFacesLookupTable if the font has already been deemed to be invalid. However, removeFromFacesLookupTable would still attempt to remove the font, leading to the use-after-free. The patch changes the ASSERT to an if clause. The function will return if iterator == m_facesLookupTable.end(), since the item it wishes to remove is not found in the table.

Description by sleirsgoevy:

On PS4 FWs 9.00-9.04 the constructor returns with an exception, but to C++ code that ignores it. That is how an invalid font is created in the first place. On earlier PS4 FWs the exception is propagated to JavaScript.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes on PS4 FW 9.50 and No as of PS5 FW 4.51 (need to test on PS5 FWs >=5.00). Not working on PS4 FWs <9.00 and PS5 FWs <2.10.

Might have been introduced in PS4 FW 3.50 and before PS5 FW 1.00 according to dates (need to check). However the vulnerability cannot be exploited in some conditions depending on how WebKit was compiled. For example, on PS4 FWs 7.55-8.52 and PS5 FWs <= 2.00, the FontFaceSet constructor returns with an exception that is propagated to JavaScript, preventing exploitation this way.

Tested[edit | edit source]

Tested working on PS4 FWs 9.00-9.04 and PS5 FWs 3.00-4.51. Untested: PS5 FWs 2.10-2.70 and >=5.00.

FW 6.00-7.55 - WebCore::ValidationMessage::buildBubbleTree() UaF leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Quentin Meffre (@0xdagger) and Mehdi Talbi (@abu_y0ussef) who are Security Researcher at Synacktiv for fuzzing WebKit, finding a way to exploit the vulnerability on PS4, presenting it on Black Hat Europe 2020 ([11]) and sharing the code (2020-12-10)
  • sleirsgoevy for porting (although with low success rate) to PS4 FWs 7.00-7.02

Analysis[edit | edit source]

Bug Description[edit | edit source]

  • The method buildBubbleTree makes a call to update the layout during which all user registered JS handlers are executed. If the ValidationMessage is destroyed in a JS callback, this could lead to a Use-After-Free situation when we get back to buildBubbleTree code.
  • ValidationMessage::buildBubbleTree is doing layout which can run a script detaching the owner form element, and this ValidationMessage object can be destroyed.

After private disclose by Synacktiv ethical hackers, the vulnerability was fixed in WebKit on September 11st 2020. SIE updated to the patched WebKit with firmware 8.00 released on October 14st 2020.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 8.00 FW.

Tested[edit | edit source]

Tested working on FWs 6.00-7.55, not working on FWs <= 5.56. HTML textarea guessed addresses for FWs 6.70-7.55 are known but not for FWs 6.00-6.51 so an attacker needs to make tests to determine these addresses on FWs 6.00-6.51.

FW 6.00-6.72 - bad_hoist Type Confusion exploit (CVE-2018-4386) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Lokihardt (from Google Project Zer0) for the exploit PoC (Sep 13, 2018)
  • Fire30 for turning the vulnerability into exploit for PS4 (Dec 30, 2019)
  • sleirsgoevy for attempting to stabilize the PS4 exploit with a new implementation (Feb 23, 2020)

Analysis[edit | edit source]

Bug Description[edit | edit source]

WebKit: JSC: BytecodeGenerator::hoistSloppyModeFunctionIfNecessary does not invalidate the ForInContext object.

It is possible to craft Javascript in such a way that allows for an object to be passed as the property variable directly as a string to the op_get_direct_pname handler without being properly validated.

This is a Type Confusion exploit.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 7.00 FW

FW 4.50-6.72 - DOMWindow::open heap UaF (CVE-2021-30849) leading to crash[edit | edit source]

Credits[edit | edit source]

  • Sergei Glazunov (from Google Project Zer0) for the exploit PoC (Jul 1, 2021)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 7.00 FW.

Tested[edit | edit source]

Vulnerable on PS4 FWs 4.50-6.72. Not vulnerable on FWs <= 4.07. Not vulnerable on FWs >=7.00 according to manual tests but need to check WebKit sources.

FW 4.50-6.20 - JSArray::shiftCountWithArrayStorage() OOB RW (CVE-2018-4441) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Lokihardt (from Google Project Zer0) for the exploit PoC (Oct 3, 2018)
  • Specter for the rewriting for PS4 (Mar 8, 2019)
  • St4rk for helping Specter

Analysis[edit | edit source]

Bug Description[edit | edit source]

We would take the fast path for JSArray::shiftCountWithArrayStorage when the array hasHoles(). However, the code for this was wrong. It would incorrectly update ArrayStorage::m_numValuesInVector.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 6.50 FW.

Tested[edit | edit source]

It does not work on <= 4.07 FW PS4 according to tests as the exploit fails at step "Triggering memory corruption".

FW 6.00-6.20 - JSC::arrayProtoPrivateFuncConcatMemcpy() Information Leak (CVE-2018-4358) ?leading to ASLR defeat?[edit | edit source]

Credits[edit | edit source]

  • bkth, niklasb and saelo (from phoenhex Team) for the exploit PoC in Safari (Sep 26, 2018)
  • Vultra for discovering that the exploit worked on PS4 FW 6.00 (Dec 10, 2018)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 6.50 FW

Tested[edit | edit source]

Works on 6.00-6.20. Not working on PS4 FWs <= 5.56 because JSC (JavaScriptCore) was too old.

FW 4.50-5.56 - JSGlobalObject::haveABadTime() Type Confusion (CVE-2017-7005) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Lokihardt (from Google Project Zer0) for the exploit PoC (Mar 20, 2017)
  • ALEXZZZ9 for the first PS4 implementation (on 5.01), and at same time for burning the exploit (Feb 20, 2018)
  • qwertyoruiop for rewriting and porting to 5.05 and 5.50

Analysis[edit | edit source]

Project Zer0 Bug Description

Bug Description[edit | edit source]

When JSGlobalObject::haveABadTime() is called with arrays of a different JSGlobalObject type, type confusion can occur, leading to memory corruption.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 6.00 FW

FW ?.??-4.05-5.56 - Document::adoptNode() UaF (CVE-2017-2468) leading to crash[edit | edit source]

Credits[edit | edit source]

  • Lokihardt (from Google Project Zer0) for the exploit PoC (Jan 23, 2017)
  • CelesteBlue for testing on PS4 and PS Vita (May 9, 2020)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 6.00 FW. Vulnerable at least on PS4 FWs 4.05-5.56 and PS Vita FW 3.60.

FW 4.50-5.56 - WebCore::HTMLFrameElementBase::marginHeight() Heap UaF (CVE-2016-1859) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Liang Chen, wushi of KeenLab, Tencent working with Trend Micro's Zero Day Initiative for discovering this vulnerability (2016-03-16)

Analysis[edit | edit source]

Bug Description[edit | edit source]

The specific flaw exists within the handling of GraphicsContext objects. By manipulating a document's elements an attacker can force this object in memory to be reused after it has been freed. An attacker can leverage this vulnerability to execute code under the context of the current process.

CVE-2016-1859 is a use-after-free vulnerability that existed in the Safari web browser. A GraphicsContext object is used in the setPlatformTextDrawingMode function after it has been freed. The successful triggering of the use-after-free vulnerability itself does not allow the attacker to directly change the control flow or disclose arbitrary memory contents. However, the use-after-free yields an arbitrary-memory-write primitive by hijacking a destination pointer that will be used for the memcpy function. Once the arbitrary-memory-write primitive is achieved, the attacker sprays the heap with string objects to achieve the arbitrary-memory-read primitive. Relying on the pointer width heap alignment, the attacker can accurately predict the exact address of one of the string objects among the heap spray and pinpoint the address of member variable. At this point, the attacker can overwrite the length member variable of a string object and partially disclose the out-of-bound heap area exceeding the buffer address of the string. The partial disclosure of the heap memory allows the attacker to extend the information leak step-by-step and ultimately allows full chaining of ROP, which leads to arbitrary code execution.

Implementation[edit | edit source]

  • PoC publicly available
  • No full exploit publicly available but exploitation description is detailed

Patched[edit | edit source]

Yes in 6.00 FW. Vulnerable on PS4 FWs 4.50-5.56.

FW 4.50-5.01 - Element::setAttributeNodeNS() UaF leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Lokihardt (from Google Project Zer0) for the exploit PoC (Mar 15, 2017)
  • qwertyoruiop for the PS4 exploit (October 2017)
  • Specter for the writeup and implementation (May 27, 2018)

Analysis[edit | edit source]

Bug Description[edit | edit source]

By forcing setAttributeInternal() to call setAttributeNodeNS() twice, an attribute node reference will be added twice to the list. When one is free()'d, the second attribute still contains a duplicate stale reference, leading to a use-after-free (UAF) scenario.

Implementation[edit | edit source]

PS4 5.05 WebKit + Kernel Exploit by Specter (2018-05-27)

Patched[edit | edit source]

Yes in 5.03 FW.

FW 3.15-4.07 - Stack Uninitialized Read UaF leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • qwertyoruiop for the exploit (around 2017-04-03)
  • Specter for the write-up (2017-04-05)
  • TheFloW for the port to PS Vita internet browser (2022-12-27)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Via a specially crafted valueOf() function of an arguments.length() function, non-zero indexes of the stack-allocated array are not initialized, leading to a stack uninitialized read. This can be abused to store a reference that can later be re-obtained post-GC (garbage collection) yielding a use-after-free() (UAF) situation.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 4.50 FW. Not patched on PS Vita internet browser.

Tested[edit | edit source]

Works on 3.15-4.07 and PS Vita 3.30-3.74. Not working on <= 3.11.

FW <= ?4.05? - Type confusion in WebCore::HTMLInputElement::onSearch (CVE-2017-2354)[edit | edit source]

Credits[edit | edit source]

  • Neymar of Tencent's Xuanwu Lab working with Trend Micro's Zero Day Initiative for discovering this vulnerability (2016-11)
  • Brent Fulgham for fixing the bug in WebKit (2016-11-14)
  • Jasiel Spelman (@WanderingGlitch) for his writeup (2017-12-20)

Analysis[edit | edit source]

Bug Description[edit | edit source]

It is possible for JavaScript to change the type property of an input field. WebKit needs to gracefully handle this case.

This bug could have been prevented had it a debug check been used instead of a runtime check. In fact, WebKit has support for this type of assertion already through a RELEASE_ASSERT macro, which would have turned this exploitable bug into a simple denial-of-service by immediately and safely crashing the browser.

The fix commit of the vulnerability adds a type traits specialization so that WebKit can properly downcast InputType elements. This should be used only to call search functions on actual search input types.

Although the access violation in WebCore::TimerBase::heapPop is where we see the result of the bug, it is not the cause of the issue. The crash actually occurs as a result of reading a pointer that comes from the 'this' object. Based on that, it would seem that something is wrong with the Timer object passed into the WebCore::TimerBase::heapPop function.

This vulnerability may be the one used by Chaintin Tech with a kernel exploit on PS4 FW 4.01 at GeekPwn 2016, a Tencent Security's conference, in Shanghai Station at the Pavilion Safety Research Lab, (https://www.chaitin.cn/ps4, https://www.psxhax.com/threads/ps4-4-01-linux-installation-ksploit-demo-at-geekpwn-2016.932/)

Implementation[edit | edit source]

  • PoC by Neymar (2016-11, disclosed publicly by Jasiel Spelman on 2017-12-20):
<input id="m_input" type="search"></input>
<script type="text/javascript">
	first = true;
	m_input.addEventListener("input", function (e) {
		if(first) {
			first = false;
		}
		else {
			m_input["type"] = "image";
		}
	}, false);
</script>

Patched[edit | edit source]

Maybe in 4.06 FW

Tested[edit | edit source]

Not yet.

FW 3.15-3.70 - JSArray::sortCompactedVector() Heap UaF leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • xyz for the original exploit on PS Vita (HENkaku)
  • Fire30 for porting to PS4
  • Specter for improved PS4 playground

Analysis[edit | edit source]

Bug Description[edit | edit source]

When attempting to update a vector via sortCompactedVector() - data is written based on a pointer, though the pointer is not re-updated nor nulled. When this memory in free()'d, the reference is maintained and thus memory corruption can occur.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 4.0?0? FW

Tested[edit | edit source]

Works on 3.15-3.70. Not working on <= 3.11. Maybe working on 4.00.

FW <= 3.50 - WebCore::TimerBase::heapPopMin() Heap UaF leading to crash[edit | edit source]

Credits[edit | edit source]

  • Brent Fulgham for fixing the bug in WebKit (2016-05-16)

Analysis[edit | edit source]

Bug Description[edit | edit source]

"As of firmware version 3.55 a patch has been included to prevent a use-after-free segmentation fault from being exploited. This could have led to a ROP chain and code execution. It would have been cool if someone would have done some real research on it..." qwertyoruiop

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 3.55 FW

Tested[edit | edit source]

Works on 3.15, 3.50 FW. Maybe working on 3.51 FW.

FW <= ?2.50? - JavaScript OnLoad Handler Remote Code Execution Vulnerability (CVE-2005-1790) leading to crash or lag[edit | edit source]

Credits[edit | edit source]

  • Benjamin Tobias Franz for the vulnerability discovery (2005-11-21)
  • Stuart Pearson for the Proof of Concept on Microsoft Internet Explorer
  • Sam Sharps for the Metasploit port (2012-01)
  • Jeerum for disclosing that the vulnerability affects PS4 <=2.50 (2014-10-31).

Analysis[edit | edit source]

Bug Description[edit | edit source]

This bug is triggered when the browser handles a JavaScript 'onLoad' handler in conjunction with an improperly initialized 'window()' JavaScript function. This exploit results in a call to an address lower than the heap. The javascript prompt() places our shellcode near where the call operand points to. We call prompt() multiple times in separate iframes to place our return address. We hide the prompts in a popup window behind the main window. We spray the heap a second time with our shellcode and point the return address to the heap. I use a fairly high address to make this exploit more reliable. Microsoft Internet Explorer will crash when the exploit completes. Also, please note that Microsoft Internet Explorer must allow popups in order to continue exploitation.

Implementation[edit | edit source]

Patched[edit | edit source]

Maybe

Tested[edit | edit source]

  • Working on 1.76-2.50 FW: crash. 3.00-5.50 error CE-36329-3. 4.55 lag in background TV application (for example Netflix application).

FW <= 2.03 - WebCore::CSSSelector Heap Overflow (CVE-2014-1303) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • KeenTeam for finding and documenting the bug
  • Liang Chen from KeenTeam for the writeups
  • xyz for porting to PS Vita FWs 3.30-3.36
  • Fire30 for porting to PS4
  • dreadlyei (unknown person, credited by Fire30)

Analysis[edit | edit source]

Bug Description[edit | edit source]

By forcing addRule() to be called on a CSS Selector via window.getMatchedCSSRules(), a 1-bit OOB write can be achieved and leveraged to corrupt heap memory.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 2.50 FW

Tested[edit | edit source]

  • Working on 2.00-2.03 FW. Might work on 2.04 (99% sure as 2.04 PUP is about same size as 2.03 PUP).
  • Working on AppleWebKit/537.73
  • Maybe not working on FW < 2.00.

FW <= 2.03-? - WebCore::ImageInputType::attach Heap UaF (CVE-2013-2857) leading to ROP execution[edit | edit source]

Credits[edit | edit source]

  • Chromium bugs reporters
  • JumpCallPop, jam1garner, hedgeberg for inital exploit on Wii U
  • yellows8 for ROP on Wii U
  • orboditilt for increasing stability on Wii U
  • zoogie for porting Wii U exploit to New3DS
  • CelesteBlue for testing on PS4 2.03

Analysis[edit | edit source]

Bug Description[edit | edit source]

Use-after-free with input type image. Error event was fired synchronously blowing away the input element from underneath.

Exploiting this vulnerability on PS4 is not convenient because:

  • This vulnerability does not provide arbitrary read-write without code execution, hence ROP chain (at least to stack pivot to JiT code) must be made with a memory dump or decrypted modules for this System Software version, obtained using another vulnerability.
  • There is usermode ASLR since at least System Software version 1.70 so ROP chain gadgets must be relocated at runtime. This means that another vulnerability that would provide an information leak is needed.
  • Even if we get ROP chain to work on PS4 with this UaF vulnerability, there is no evidence that a return to JavaScript from ROP chain is doable, making this exploit less convenient than arbitrary RW exploits method of getting code execution then returning to usermode by restoring vtable.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in ? FW

Tested[edit | edit source]

  • Working on 2.03 FW. Might work on 2.04 (99% sure as 2.04 PUP is about same size as 2.03 PUP).

FW <= 1.76 - JSArray::sort() Heap Overflow (CVE-2012-3748, PSA 2013-0903-1) leading to arbitrary RW[edit | edit source]

Credits[edit | edit source]

  • Vitaliy Toropov for the exploit on Mac OS X Safari (September 4, 2013)
  • nas and Proxima for the first PS4 POC on 1.76 PS4 (October 23, 2014)
  • sony for patching the exploit in FW 2.00 (October 27, 2014)
  • CTurt for the rewriting (PS4 1.76 PlayGround) and implementation with his 1.76 kexploit (December 6, 2015) [19]

Analysis[edit | edit source]

Bug Description[edit | edit source]

By forcing the compare function to reduce the size of the array, trailing items will be written out of bounds (OOB write), leading to heap memory corruption.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 2.00 FW

Tested[edit | edit source]

  • Working on PS4 1.00-1.76 FW, AppleWebKit/531.3-536.26
  • Might work on PS4 FW 0.930.020.

Usermode Exploits (JavaScript engine in applications)[edit | edit source]

Similarly to the WebKit engine contained in the preinstalled Internet Browser of the PS4, some usermode applications can be exploited via vulnerabilities in the JavaScript engine (WebKit).

FW 1.75-13.04 - Multiple vulnerabilities in the PlayStation Vue application for PS4[edit | edit source]

Credits[edit | edit source]

  • Centrino for discovering that the PlayStation Vue application on PS4 had a DRM Free license (2017-12-21)
  • autechre for proposing the idea that the Netflix application for PS4/PS5 could be exploited the same way as on other platforms (2025-10-16)
  • earthonion for implementing the first PoC of custom JavaScript execution in the Netflix application for PS4/PS5 (2025-10-22)
  • earthonion for implementing the first PoC of custom JavaScript execution in the PlayStation Vue application for PS4 (2025-12-17)
  • c0w-ar, earthonion, ufm42, D-Link Turtle, Gezine, Helloyunho and Dr.Yenyen for getting usermode execution in the PlayStation Vue application for PS4 (2026-02-08)

Analysis[edit | edit source]

Bug description[edit | edit source]

The PS4 version of the PlayStation Vue application can be exploited to get usermode ROP execution thanks to a chain of vulnerabilities:

  • it can run with a DRM Free license (/system_ex/app/CUSA00960/app.rif and in /user/license/freeUT0016-CUSA00960_00-COBRAPCKGE000000.rif) to run (unlike other PS4 applications from PS Store, see e.g. YouTube, Netflix),
  • it can be installed via Backup And Restore, OMSK Daemon or USB Extended Storage,
  • it takes advantage of the download cache at /user/download/CUSAxxxxx/download0.dat which is mounted to /mnt/sandbox/CUSAxxxxx/download0 when the application opens,
  • it requires being connected to PSN but that can be bypassed by injecting a custom localstorage.aes file in the internal HDD (in download0.dat for application version 1.01, in savedata for application version >= 1.24),
  • it loads a manifest file from network without requiring a signature which points to the location of a JavaScript script to be executed,
  • on application version >= 1.24, it loads a JavaScript file from the network or HDD download0 folder, whose URL or path is specified in savedata, and executes it without requiring a signature,
  • it uses a JavaScript engine (JavaScript Core ?WebKit?) that have vulnerabilities leading to arbitrary read-write and to ROP chain execution.

The following versions of the PlayStation Vue application for PS4 (Content ID UT0016-CUSA00960_00-COBRAPCKGE000000) are affected by remote man-in-the-middle (MITM) JavaScript code injection:

  • application version 1.00 version 1.01, or later, requiring PS4 System Software version ?1.75? or more recent

The following versions of the PlayStation Vue application for PS4 (Content ID UT0016-CUSA00960_00-COBRAPCKGE000000) are affected by JavaScript code injection using a local file or over the network:

  • application version 1.24, requiring PS4 System Software version 5.05 or more recent

To bypass the PSN connection check in the PlayStation Vue application version 1.01:

  1. Start the PlayStation Vue application.
  2. Copy the custom localstorage.aes to /data/mnt/sandbox/CUSA00960_000/download0/. This requires PS4 usermode code execution.
  3. Close the PlayStation Vue application.
  4. Reopen the PlayStation Vue application.

To bypass the PSN connection check in the PlayStation Vue application version 1.24 and later:

  1. Start the PlayStation Vue application. This creates a savedata.
  2. Close the PlayStation Vue application. This properly closes the savedata files.
  3. Export the savedata files of the PlayStation Vue application. This requires a USB storage device or HDD filesystem access via kernel exploit or knowledge of the EAP HDD Key.
  4. Decrypt the savedata files of the PlayStation Vue application. This requires knowledge of the NP Account ID and decryption keys or a PS4 with a kernel exploit.
  5. Copy the custom localstorage.aes to the savedata.
  6. Encrypt the savedata. This requires knowledge of the NP Account ID and decryption keys or a PS4 with a kernel exploit.
  7. Inject the new savedata into the HDD. This requires a USB storage device or HDD filesystem access via kernel exploit or knowledge of the EAP HDD Key.
  8. Reopen the PlayStation Vue application.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS4 FW 13.50 because the PlayStation Vue application cannot run (exact cause to be studied). The PlayStation Vue application for PS4 does not work on PS5.

FW 5.05-13.04 - Type Confusion in JSC leading to ROP execution (CVE-2017-7117)[edit | edit source]

Credits[edit | edit source]

  • lokihardt of Google Project Zero
  • rebelle3
  • c0w-ar, earthonion, ufm42, D-Link Turtle, Gezine, Helloyunho and Dr.Yenyen for porting it to the PlayStation Vue application for PS4 (2026-02-08)

Analysis[edit | edit source]

Bug description[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since PS4 FW 13.50 because the PlayStation Vue application cannot run (exact cause to be studied).

Usermode securities[edit | edit source]

Usermode ASLR[edit | edit source]

  • Very old firmwares (<= 1.05) do not have ASLR enabled, but it was introduced sometime before firmware 1.70. "Address Space Layout Randomization" (ASLR) is a security technique which causes the base addresses of modules to be different every time you start the PS4.
  • To defeat usermode ASLR on FWs >=1.70, we can use the module imports table to find other modules address once we know SceWebkit2 address.

Module imports table cleaned before execution[edit | edit source]

  • Between 1.76 and 4.05, Sony did that to prevent WebKit exploiters from defeating usermode ASLR easily.
  • Now we have to dump entire usermode sandboxed memory, and by studying it we can defeat ASLR:

1. Chose a function (ex: __stack_chk_fail) imported from libkernel.sprx by libSceWebkit2.sprx

2. Read pointer contained at the address where the call is done

3. Substract to this pointer the offset of the function (ex: __stack_chk_fail) in LibKernel module

4. This result is LibKernel base address. This method works for any imported module.

For FW >= 6.00, for web applications, libkernel.sprx has been replaced by libkernel_web.sprx and libSceWebKit2 by libSceNKWebKit.sprx. libkernel.sprx is still used by other applications.

DEP / NX[edit | edit source]

  • "Data Execution Prevention" / "No eXecute" is enabled on all firmwares. It prevents allocating memory as both RW and RX at same time (RWX) so preventing us from writing shellcode to usermode memory then executing it.
  • 2 ways to bypass this security: JiT vulnerability (FW <= 1.76) or ROP (all FWs).

JIT removed from PS4 Internet Browser[edit | edit source]

  • On PS4 FW <= 1.76, you could map RWX memory from ROP by abusing the JIT functionality and the sys_jitshm_create and sys_jitshm_alias system calls. This however was fixed after 1.76, as WebKit has been split into two processes. One handles JavaScript compilation and the other handles other web page elements like image rendering and DOM. The second process will request JIT memory upon hitting JavaScript via IPC (Inter-Process Communication). Since we no longer have access to the process responsible for JIT, we can no longer (at least currently), map RWX memory for proper code execution unless the kernel is patched.
  • Checking the source code at ps4-oss, starting as early as PS4 FW 6.00, ENABLE_JIT=OFF for -DPORT=PlayStation4. It means that JIT functionality is completely removed from WebKit and there is no JIT coprocess that is allowed to request RWX memory to even attack. Even if there are JIT bugs that can lead us to request RWX memory in other platforms, we cannot on the PS4 as there is no longer any JIT process. Unchecked all source codes, JIT process could have been removed earlier than 6.00. All exploits must use ROP.
  • Workaround is to use return-oriented-programming (ROP) or to get control of JIT in another process, for example in the PS2 emulator shipped with some PS4 games (see mast1c0re part 2).

Syscalls removed[edit | edit source]

Orbis ID Table ID Randomization since FW 2.50[edit | edit source]

See fail0verflow's writeup on the PS4 1.01-4.05 namedobj kernel exploit for type definitions.

Free id_entrys are connected to form a free list (id_entry.handle points to the next free entry) with the id_table pointing to the head (id_table.cur_handle). id_alloc would pop the head while id_free would push the new head. The ID returned by id_alloc is the entry's index in the bucket list. This makes it easy to predict what the next ID is given the LIFO nature of the allocator. To hamper predictability, SCE has added a new counter field to id_entry. It counts how many times the entry got freed. The counter will form the upper 3 bits of the 16-bit ID. Accessors like id_rlock will check if the requested ID's upper bits matches the counter field.

Direct Syscall invocation disabled in PS4 Kernel[edit | edit source]

Between 2.00 and 2.57, SCE has disabled direct system calls by usermode, by adding some checks in the PS4 kernel. An attacker can no longer call any syscall he wants by specifying the call number in the rax register and jump directly to the call instructions part of a syscall stub. Indeed, now the PS4 (but not PS5) implementation of amd64_syscall checks the following:

  • The address in the Instruction Pointer (IP) of the call must be within the memory range of the associated libkernel module of the process,
  • The code pointed by the Instruction Pointer (IP) must follow the syscall stub format,
  • The syscall number passed in argument to amd64_syscall must corresponds to the stub's syscall number. amd64_syscall checks the stub's mov rax, syscall_number instruction.

Since PS4 version 3.00, issuing directly a syscall instruction crashes the application and gives error CE-34878-0, (SCE_KERNEL_ABORT_REASON_SYSTEM_ILLEGAL_FUNCTION_CALL), displaying the message "Kernel: The application directly issues a syscall instruction (24)".

An attacker is now forced to use wrappers provided from the libkernel / libkernel_web / libkernel_sys modules to trigger system calls.

The PS5 does not enforce the passed syscall number and thus any code can directly issue an arbitrary syscall even if the associated libkernel does not provide it.

bpf_write function stripped out of the kernel[edit | edit source]

  • On 4.70, bpfwrite() was stripped out of the kernel entirely to patch kernel vulnerability exploited in 4.55 kexploit.

bpf_open function blocked for unprivileged processes[edit | edit source]

  • On 5.50, opening BPF has been blocked for unprivileged processes such as WebKit and other applications/games. It's still present in the sandbox, however attempting to open it will fail and yield EPERM. This aims at blocking BPF kernel exploits especially qwertyoruiop's BPF double free UAF.

bpf_ioctl function blocked or removed[edit | edit source]

  • On FW 5.50+, opening BPF is still possible in less sandboxed apps like TestKit/DevKits fSELFs. But this is useless because ioctl does not work.

Device access blocked/removed from webbrowser[edit | edit source]

  • Around 6.50-6.70, device access got blocked or removed. Now you can no longer access devices from the web browser.

Pointer poisoning in WebKit on 6.xx firmwares[edit | edit source]

  • For select types implemented by WebKit (such as JSC::JSFunction), certain pointer fields are XOR'ed by a cryptographic key generated at runtime. The key is generated once every process launch, one must recover it to unpoison the pointers.

Flush-to-Zero and Denormals-are-Zero Floating-Point environment[edit | edit source]

Subnormal numbers (also called as denormal numbers in IEEE 754 documents before the 2008 version) are treated as 0 on the PlayStation runtime environment. This isn't technically a security technique but it does inhibit any exploit that uses floating-point numbers for read/write.

An example entrypoint is WebKit where exploits have commonly used double arrays with incorrect length to read/write certain memory areas to gain arbitrary read/write or even code execution. With FTZ/DAZ, the possible 64-bit values one can write have become even more limited. Reads using double arrays are also affected. Even if the bit pattern is nonzero but encodes a subnormal, it will be read by the JavaScript engine as 0.

Kernel[edit | edit source]

FW <= 13.00 - UaF in sys_netcontrol[edit | edit source]

Credits[edit | edit source]

  • 2025-11-02 TheFloW for discovering the vulnerability and releasing publicly an implementation chained with BD-JB3 (PS4) BD-JB2 (PS5)

Analysis[edit | edit source]

None.

Bug Description[edit | edit source]

On PS5, it is required to call the dup system call, whilst on PS4 one can instead use fcntl or ioctl. Note that to call the dup system call, it is required to have libkernel_sys.sprx or libkernel_web.sprx loaded in memory. The libkernel.sprx module does not contain a wrapper to the dup syscall. This restricts which usermode entrypoints can be used on PS5 to trigger this kernel vulnerability: Internet browser has libkernel_web, PS2 emulator and BD-J have libkernel_sys, whilst non-system games and applications have the non-privileged libkernel.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in PS4 13.02 FW and PS5 12.02 FW.

FW <= ?13.00? - udf_readlink should check fentry->inf_len[edit | edit source]

Credits[edit | edit source]

  • 2025-06-29 Robert Morris for discovering the bug in FreeBSD and providing a POC UDF image file.
  • 2025-10-08 zecoxao for reporting that this bug may affect PS4 and PS5 kernel.

Analysis[edit | edit source]

Bug Description[edit | edit source]

In FreeBSD before 2025-07-16, a malformed UDF disk having a symbolic link's File Entry with a huge (negative) inf_len can cause kernel panic, and may lead to kernel exploitation.

According to zecoxao, it seems that Sony developers copied the original vulnerable FreeBSD code into the PS4 and PS5 kernel.

Note that a different UDF vulnerability affecting the PS4 and PS5 kernel was reported by TheFloW as part of his HackerOne bounty for the initial BD-JB.

Implementation[edit | edit source]

None.

Patched[edit | edit source]

Maybe in PS4 13.02 FW and PS5 12.02 FW.

FW <= 12.52 - Filename buffer overflow in pfs_readdir[edit | edit source]

Credits[edit | edit source]

  • zecoxao for diffing 13.00 and 12.52 PS4 kernel and disclosing it ([20]).

Analysis[edit | edit source]

Bug Description[edit | edit source]

The pfs_readdir function (?an IOCTL#pfs IOCTL routine?) is used notably for savedata and game data access. pfs_readdir expects a filename string of maximum 256 bytes but does not check the length and can copy up to 500 bytes, corrupting the kernel ?stack or heap?.

Exploiting this vulnerability would require to plant a ROP or JOP chain in kernel then to trigger the buffer overflow with controlled data compatible with the filename ASCII constraints (notably no zero byte) and possibly also with the filesystem constraints (notably no slash '/') if an actual directory has to be created. This also supposes that pfs_readdir can be called with a custom path, maybe requiring filesystem write access or usermode ROP execution. Attackers may take exFAThax as an example for kernel exploitation techniques.

Implementation[edit | edit source]

None.

Patched[edit | edit source]

Yes in PS4 13.00 FW and PS5 ?12.00? FW. PS5 7.61 FW seems affected.

FW 5.00-12.02 - Double free due to aio_multi_delete() improper locking[edit | edit source]

Credits[edit | edit source]

  • 2025-04-01 Anonymous for sharing 12.02 and 12.50 PS4 kernel dumps for diffing.
  • 2025-04-22 abc (anonymous) for disclosing publicly the aio_multi_delete() Double Free PoC for PS4 that he wrote between 2024-12-08 and 2025-01-11.
  • 2025-05-08 abc (anonymous) for making and releasing the first exploitation code that goes up to patching PS4 kernel.
  • 2025-06-16 shahrilnet and znull_ptr for chaining the exploit with Artemis Lua escape and porting the exploit to PS4 9.00-12.02 and PS5 2.00-10.01.
  • 2025-06-16 AlAzif and EchoStretch for chaining the exploit with PSFree and porting the exploit to PS4 7.00-9.60 and PS5 1.01-5.70.
  • 2025-07-31 iMrDJAi for chaining the exploit with mast1c0re for PS4 5.00-12.02 and PS5 2.00-10.01.
  • 2025-08-25 Gezine for chaining the exploit with BD-JB3 for PS4 5.00-12.02.

Analysis[edit | edit source]

Summary by abc of the bug at aio_multi_delete(): 

void free_queue_entry(struct aio_entry *reqs2) {
    if (reqs2->ar2_spinfo != NULL) {
        printf("[0]%s() line=%d Warning !! split info is here\n", __func__, __LINE__);
    }
    if (reqs2->ar2_file != NULL) {
        // We can potentially delay .fo_close().
        fdrop(reqs2->ar2_file, curthread);
        reqs2->ar2_file = NULL;
    }
    free(reqs2, M_AIO_REQS2);
}

int _aio_multi_delete(struct thread *td, SceKernelAioSubmitId ids[], u_int num_ids, int sce_errors[]) {
    // ...
    struct aio_object *obj = id_rlock(id_tbl, id, 0x160, id_entry);
    // ...
    u_int rem_ids = obj->ao_rem_ids;
    if (rem_ids != 1) {
        // BUG: wlock not acquired on this path
        obj->ao_rem_ids = --rem_ids;
        // ...
        free_queue_entry(obj->ao_entries[req_idx]);
        // The race can crash because of a NULL dereference since this path
        // does not check if the array slot is NULL so we delay free_queue_entry().
        obj->ao_entries[req_idx] = NULL;
    } else {
        // ...
    }
    // ...
}

Bug Description[edit | edit source]

FreeBSD's aio(4) subsystem implements asynchronous I/O. Sony's SceAIO subsystem in PlayStation 4 and 5 is an alternative to FreeBSD's POSIX AIO implementation. In PS4 kernel, aio_multi_delete() has a race condition that leads to a double free.

See also FreeBSD AIO wiki page.

Note that Linux kernel has a module similar to AIO, name io_uring, and that it contained some vulnerabilities like this one.

Implementation[edit | edit source]

// SceAIO submit commands
#define SCE_KERNEL_AIO_CMD_READ     0x001
#define SCE_KERNEL_AIO_CMD_WRITE    0x002
#define SCE_KERNEL_AIO_CMD_MASK     0xfff

// SceAIO submit command flags
#define SCE_KERNEL_AIO_CMD_MULTI 0x1000

#define SCE_KERNEL_AIO_PRIORITY_LOW     1
#define SCE_KERNEL_AIO_PRIORITY_MID     2
#define SCE_KERNEL_AIO_PRIORITY_HIGH    3

typedef struct SceKernelAioResult {
    int64_t returnValue;
    uint32_t state;
} SceKernelAioResult;

typedef struct {
    off_t offset;
    size_t nbyte;
    void *buf;
    struct SceKernelAioResult *result;
    int fd;
} SceKernelAioRWRequest;

typedef int SceKernelAioSubmitId;

int aio_submit_cmd(
    u_int cmd,
    SceKernelAioRWRequest reqs[],
    u_int num_reqs,
    u_int prio,
    SceKernelAioSubmitId ids[]
);

// wait for all (AND) or atleast one (OR) to finish
#define SCE_KERNEL_AIO_WAIT_AND 0x01
#define SCE_KERNEL_AIO_WAIT_OR  0x02

int aio_multi_wait(
    SceKernelAioSubmitId ids[],
    u_int num_ids,
    int sce_errors[],
    // SCE_KERNEL_AIO_WAIT_*
    uint32_t mode,
    useconds_t *usec
);

int aio_multi_delete(
    SceKernelAioSubmitId ids[],
    u_int num_ids,
    int sce_errors[]
);

const int num_reqs = 3;
const int which_req = 0;
const int race_errs[2];
pthread_barrier_t barrier;

void *race_func(void *arg) {
    int *id = (int *)arg;

    pthread_barrier_wait(&barrier);
    aio_multi_delete(id, 1, &race_errs[1]);

    return NULL;
}

int main(void) {
    SceKernelAioRWRequest reqs[num_reqs] = {0};
    int ids[num_reqs] = {0};
    int sce_errs[num_reqs] = {0};

    // bare minimum initialization to succeed in calling aio_submit_cmd()
    for (int i = 0; i < num_reqs; i++)
        reqs[i].fd = -1;

    pthread_barrier_init(&barrier, NULL, 2);

    for (int i = 0; i < 100; i++) {
        // Command and priority do not matter but the MULTI flag is required.
        aio_submit_cmd(
            SCE_KERNEL_AIO_CMD_WRITE | SCE_KERNEL_AIO_CMD_MULTI,
            reqs,
            num_reqs,
            SCE_KERNEL_AIO_PRIORITY_HIGH,
            ids
        );

        // You cannot delete any request that is already being processed by a
        // SceFsstAIO worker thread.
        //
        // We just wait on all of them instead of polling and checking whether
        // a request is being processed. Polling is also error-prone since the
        // result can become out of date.
        aio_multi_wait(ids, num_reqs, sce_errs, SCE_KERNEL_AIO_WAIT_AND, 0);

        pthread_t race_thread;
        pthread_create(&race_thread, NULL, race_func, &ids[which_req]);
        pthread_barrier_wait(&barrier);

        // double delete request which_req
        aio_multi_delete(&ids[which_req], 1, &race_errs[0]);

        pthread_join(race_thread, NULL);

        // Either both are 0 or one of the errors is SCE_KERNEL_ERROR_ESRCH
        // (0x80020003) and the other is 0. You will never get double
        // SCE_KERNEL_ERROR_ESRCH.
        if (race_errs[0] == race_errs[1]) {
            printf("Double Free achieved!\n");
            return 0;
        }
    }
    printf("Double Free failed\n");
    return 0;
}

Patched[edit | edit source]

Yes in PS4 12.50 FW and PS5 10.20 FW. SceAIO syscalls are unimplemented before PS4 5.00. See Syscalls for more information.

FW <= 11.52 - Double file descriptor drop in bnet_netevent_set_queue[edit | edit source]

Credits[edit | edit source]

  • Anonymous for sharing 11.52 and 12.00 PS4 kernel dumps.
  • 2024-09-27 D-Link Turtle for diffing 11.52 and 12.00 PS4 kernel dumps.
  • 2024-10-04 SlidyBat for figuring out the bug in bnet and its impact.
  • 2024-10-04 abc (anonymous) for public analysis of the bug

Analysis[edit | edit source]

Bug Description[edit | edit source]

A double fd drop can happen by racing calls to bnet_netevent_set_queue and bnet_netevent_unset_queue.

The lack of mutexes allowed double fdrop as fdrop is called unconditionally in bnet_netevent_unset_queue. However such a double fdrop is weaker than a double free since files are refcounted and have their own zone. Indeed, there would be more attack options if it was a malloc double free.

It does not affect earlier PS4 System Software versions like ?1.00? since the code is different, though there may be another bug in the old implementation.

See also PS Vita SceNetPs kernel module that uses similar bnet functions.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 12.00 FW. Maybe not working at all on PS5.

The bug was patched in PS4 FW 12.00 by adding some mutexes in bnet_netevent functions.

FW <= 11.00 - Remote vulnerabilities in spp (yielding arbitrary kernel R/W) (CVE-2006-4304 and no-CVE)[edit | edit source]

Credits[edit | edit source]

  • 2006-08-23 Martin Husemann, Pavel Cahyna for discovering the first spp bug (CVE-2006-4304) on FreeBSD 4.11-6.1.
  • 2023-09-22 TheFloW for discovering that PS4 and PS5 are vulnerable to CVE-2006-4304, discovering second spp bug, and chaining them together.
  • 2024-01-27 anonymous for reporting publicly CVE-2006-4304 as working on PS4 and PS5. See [21] and [22].
  • 2024-03 iMrDJAi for porting CVE-2006-4304 to PS4 and PS5.
  • 2024-04-25 TheFloW for disclosing his HackerOne report including the second spp bug description.
  • 2024-04-30 TheFloW for releasing his exploit code for PS4 9.00 and 11.00.

Analysis[edit | edit source]

Bug Description[edit | edit source]

A malicious PPPoE server can cause denial-of-service or remote code execution in kernel context on the PS4/PS5. It does not require any usermode code execution to be triggered. There are two vulnerabilities that can be chained together to cause remote kernel Denial of Service, kernel ASLR defeat or kernel code execution : Heap buffer overwrite and overread in sppp_lcp_RCR and sppp_ipcp_RCR (CVE-2006-4304) and Integer underflow in sppp_pap_input leading to heap-buffer overread (no-CVE).

The PS4/PS5 must be connected using an ethernet cable to a device able to trigger PPPoE requests and analyze the responses.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 11.02 FW

FW <= 9.00 - PPPoE driver remote buffer overflow (CVE-2022-29867)[edit | edit source]

Credits[edit | edit source]

  • 2021-09-24 m00nbsd for finding the vulnerability
  • 2022-05-04 martin of NetBSD for fixing the vulnerability publicly in NetBSD 8 and 9
  • 2022-05-11 m00nbsd for disclosing the vulnerability publicly on HackerOne

Analysis[edit | edit source]

Bug Description[edit | edit source]

The PlayStation 4 has a kernel PPPoE driver, that originates from NetBSD. This driver has a kernel heap overflow vulnerability, that an attacker can remotely trigger over the LAN, with the ability to control both the contents that are overflown and their sizes.

Extract of NetBSD 8.3 changelog: 

sys/net/if_pppoe.c			1.179

	pppoe(4): fix CVE-2022-29867 - discovery phase local network
	mbuf corruption.
	[martin, ticket #1740]

Do not allocate mbuf clusters when the caller (eroneously) asks
for more than MCLBYTES size, instead fail the allocation.

When we have received multiple PADO offer packets in the discovery
phase, do not combine tags from different packets. We are supposed
to pick one PADO packet and continue session establishment with that.

The second bug could cause code to trigger the first and create
invalid response packets and also overwrite data outside of
the allocated mbuf cluster.

Fixes CVE-2022-29867.

Diff after fix commit in NetBSD 8: 

--- src/sys/net/if_pppoe.c	2020/02/13 19:37:39	1.125.6.10
+++ src/sys/net/if_pppoe.c	2022/05/04 15:36:35	1.125.6.11
@@ -1,4 +1,4 @@
-/* $NetBSD: if_pppoe.c,v 1.125.6.10 2020/02/13 19:37:39 martin Exp $ */
+/* $NetBSD: if_pppoe.c,v 1.125.6.11 2022/05/04 15:36:35 sborrill Exp $ */
 
 /*-
  * Copyright (c) 2002, 2008 The NetBSD Foundation, Inc.
@@ -30,7 +30,7 @@
  */
 
 #include <sys/cdefs.h>
-__KERNEL_RCSID(0, "$NetBSD: if_pppoe.c,v 1.125.6.10 2020/02/13 19:37:39 martin Exp $");
+__KERNEL_RCSID(0, "$NetBSD: if_pppoe.c,v 1.125.6.11 2022/05/04 15:36:35 sborrill Exp $");
 
 #ifdef _KERNEL_OPT
 #include "pppoe.h"
@@ -871,6 +871,10 @@ breakbreak:;
 			}
 			sc->sc_ac_cookie_len = ac_cookie_len;
 			memcpy(sc->sc_ac_cookie, ac_cookie, ac_cookie_len);
+		} else if (sc->sc_ac_cookie) {
+			free(sc->sc_ac_cookie, M_DEVBUF);
+			sc->sc_ac_cookie = NULL;
+			sc->sc_ac_cookie_len = 0;
 		}
 		if (relay_sid) {
 			if (sc->sc_relay_sid)
@@ -886,6 +890,10 @@ breakbreak:;
 			}
 			sc->sc_relay_sid_len = relay_sid_len;
 			memcpy(sc->sc_relay_sid, relay_sid, relay_sid_len);
+		} else if (sc->sc_relay_sid) {
+			free(sc->sc_relay_sid, M_DEVBUF);
+			sc->sc_relay_sid = NULL;
+			sc->sc_relay_sid_len = 0;
 		}
 		memcpy(&sc->sc_dest, eh->ether_shost, sizeof sc->sc_dest);
 		callout_stop(&sc->sc_timeout);
@@ -1313,6 +1321,9 @@ pppoe_get_mbuf(size_t len)
 {
 	struct mbuf *m;
 
+	if (len + sizeof(struct ether_header) > MCLBYTES)
+		return NULL;
+
 	MGETHDR(m, M_DONTWAIT, MT_DATA);
 	if (m == NULL)
 		return NULL;

Implementation[edit | edit source]

  • PoC (poc.c) by m00nbsd not disclosed publicly

Patched[edit | edit source]

Yes in 9.03 FW according to Specter by diffing PS4 9.00 and 9.03 kernels

FW <= 9.00 - exFAT driver heap-based buffer overflow[edit | edit source]

Credits[edit | edit source]

  • 2021-09-15 TheFloW for finding the vulnerability
  • 2021-12-02 zecoxao for advicing to exploit the vulnerability after diffing PS4 9.00 and 9.03 kernels
  • 2021-12-13 ChendoChap, Znullptr, Specter for PS4 9.00 kernel exploit implementation release

Analysis[edit | edit source]

See also:

Bug Description[edit | edit source]

The PS4 kernel exFAT driver has a heap-based buffer overflow vulnerability that can be triggered by inserting a malicious USB storage device in PS4 in addition to having usermode code execution. Exploitation requires to flash a crafted exFAT image to a common USB storage device.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in PS4 9.03 FW and PS5 4.50 FW

FW <= 7.55 - IP6_EXTHDR_CHECK Double Free (CVE-2020-9892)[edit | edit source]

Credits[edit | edit source]

  • 2019-09-15 tuexen for finding the FreeBSD vulnerability [23]
  • 2020-07-24 TheFloW for finding CVE-2020-9892 in XNU
  • 2020-07-26 TheFloW for porting CVE-2020-9892 to PS4
  • 2020-07-27 TheFloW for publishing publicly a PoC leading to code execution on XNU. [24]
  • 2021-01-12 TheFloW for disclosing publicly the PS4 vulnerability. [25]
  • 2021-01-20 sleirsgoevy for making a first working exploit for FreeBSD 9 [26]
  • 2021-03-03 sleirsgoevy for making a second working exploit for FreeBSD 9 [27]
  • 2021-03-12 sleirsgoevy for making the first public usable exploit for PS4 7.50-7.55 (https://twitter.com/sleirsgoevy/status/1370481212813348865)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Memory corruption can be achieved by sending fragmented IPv6 packets to loopback interface due to poor and inconsistent use of IP6_EXTHDR_CHECK.

The macro IP6_EXTHDR_CHECK can free the mbuf if the packet is sent to loopback interface. This fact is not considered in dest6_input(), frag6_input() and more. For example in dest6_input(), the double pointer is not updated.

Hence, when parsing next headers, the mbuf can be free'd once again, leading to a double free which behaves like a use-after-free when we allocate mbuf's again.

Normally, this path would not be triggerable, because sending to loopback interface requires SOCK_RAW root privileges. However, for some reason on the PS4 SOCK_RAW sockets can be opened in Webkit process! Moreover, CelesteBlue confirmed that SOCK_RAW sockets can also be opened in PS4 Kit fSELF.

According to TheFloW, the reliability of the FreeBSD 9 PoC is very high, around 80%, whereas the PS4 PoC's is not very high, he guesses around 20%.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 8.00 FW

FW <= 7.02 - IPV6_2292PKTOPTIONS UaF (yielding arbitrary kernel R/W) (CVE-2020-7457)[edit | edit source]

Credits[edit | edit source]

  • 2018-08-18 up to 2020-07-06 Fire30 for finding and keeping the vulnerability as a private 0day for it not to be patched by SIE. [28]
  • 2020-07-06 TheFloW for publishing publicly a PoC leading to code execution on FreeBSD. [29]
  • sleirsgoevy and ChendoChap for porting the PoC to PS4 and chaining it with the 6.72 and 7.02 WebKit exploits.
  • SIE for not patching this vulnerability on PS5 even when patched on PS4.
  • TheFlow for announcing that PS5 kernel was exploited: TheFloW's PS5 kernel exploit announcement (2021-11-07) and later that it was that same vulnerability that was present in PS5 FW 3.00-4.51.

Analysis[edit | edit source]

Bug Description[edit | edit source]

Due to missing locks in option IPV6_2292PKTOPTIONS of setsockopt, it is possible to race and free the struct ip6_pktopts buffer, while it is being handled by ip6_setpktopt. This structure contains pointers (ip6po_pktinfo) that can be hijacked to obtain arbitrary kernel R/W primitives. As a consequence, it is easy to have kernel code execution. This vulnerability is reachable from WebKit sandbox and is available in the latest FW, that is 7.02.

Another description: There is a race and use-after-free vulnerability in the FreeBSD kernel IPv6 socket handling. A missing synchronization lock in the `IPV6_2292PKTOPTIONS` option handling in `setsockopt` permits racing `ip6_setpktopt` access to a freed `ip6_pktopts` struct. This exploit overwrites the `ip6po_pktinfo` pointer of a `ip6_pktopts` struct in freed memory to achieve arbitrary kernel read/write.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in PS4 7.50 FW and in PS5 5.00 or 5.02 FW. Not working in PS5 FWs <= 2.70.

FW <= 5.07 - BPF Race Condition (Yielding Double Free())[edit | edit source]

Analysis[edit | edit source]

Bug Description[edit | edit source]

Due to improper locking, two threads can enter the BPF SETWF ioctl command handler. While the bug is similar to that of 4.55, the method of attack is slightly different. Since write() was removed for BPF in 4.70, instead of triggering a use-after-free with write() - SETWF is ran in parallel via threading. Eventually, both calls will copy the same pointer to the stack, leading to both threads free()'ing the same pointer, poisoning the freelist. This can later be leveraged via heap spraying to corrupt heap memory to obtain arbitrary code execution in supervisor mode (ring0).

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 5.50 FW

FW <= 4.55 - BPF Race Condition (Yielding UaF)[edit | edit source]

Analysis[edit | edit source]

Bug Description[edit | edit source]

Due to improper locking, two threads can enter the BPF ioctl command handlers for setting a new write filter (SETWF) and setting a filter (SETIF). Both threads will reference the same pointer. In specially crafted situations, one thread could free() this pointer while the other thread executes it as a filter post-validation. This allows an unprivileged user to obtain an out-of-bounds (OOB) write on the stack, leading to arbitrary code execution in supervisor mode (ring0).

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 4.70 FW

FW <= 6.00 ?6.02? - sys_getcontext Information Leak (kASLR defeat) (CVE-2018-17155)[edit | edit source]

Analysis[edit | edit source]

Bug Description[edit | edit source]

System call 421 or sys_getcontext() initializes the structure pointed at by ucp to the currently active context. The vulnerability is, some areas of memory copied out are not initialized, and thus the function leaks memory at certain spots. This vector was patched in 6.20, as now before the buffer is used it is initialized to 0 via bzero().

Implementation[edit | edit source]

  • QuickHEN by CelesteBlue (v2 not released yet)
  • KitHEN by CelesteBlue (not released yet)

Patched[edit | edit source]

Yes somewhere between 6.00 and 6.20 FW

FW <= 4.07 - sys_thr_get_ucontext Information Leak (kASLR defeat)[edit | edit source]

Analysis[edit | edit source]

Bug Description[edit | edit source]

System call 634 or sys_thr_get_ucontext() allows to obtain information on a given thread. The vulnerability is, some areas of memory copied out are not initialized, and thus the function leaks memory at certain spots. This vector was patched in 4.50, as now before the buffer is used it is initialized to 0 via bzero().

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 4.50 FW

FW <= 4.05 - NamedObj Type Confusion (Yielding UaF)[edit | edit source]

Credits[edit | edit source]

  • Chaitlin Tech for having been the first to show they had pwned PS4 FW 4.01 at Geekpwn convention. (2016-10-24)

official video, tweet 1, tweet 2, tweet 3 (2016-10-25)

  • fail0verflow for the first writeup (2017-10-19)
  • Specter for rewriting the exploit using a different object, and releasing it publicly (2017-12-27)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Type confusion in the namedobj system once exploited can lead to an arbitrary free() allowing an attacker to craft a use-after-free() (UAF) situation to corrupt kernel memory. This can be leveraged to eventually obtain an arbitrary code execution primitive in supervisor mode (ring0).

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 4.06 FW

Tested[edit | edit source]

Works on FWs 4.00-4.05. On <= 3.70 FW we have not found a way to leak the target object, but it might be doable as Fail0verflow did it on 1.01.

FW <= 3.15 - .symtab kernel table of symbols kept on low FWs[edit | edit source]

Credits[edit | edit source]

  • CelesteBlue for backporting kernel exploits to dump PS4 3.50 kernel (2019-05-09) and 3.15 (2019-05-25)
  • zecoxao and SocraticBliss for analysing kernel dumps

Bug description[edit | edit source]

After that Sony removed .strtab since FW 1.03 and .dynstr/.dynsym since FW 2.50 from PS4 kernel binary, they still kept the .symtab one.

Patched[edit | edit source]

Yes in 3.50 FW.

FW <= 2.04 - .dynstr/.dynsym kernel table of symbols kept on low FWs[edit | edit source]

Bug description[edit | edit source]

After Sony removed .strtab from PS4 kernel binary since FW 1.03, they still kept the .dynstr/.dynsym one.

Patched[edit | edit source]

Yes in 2.50 FW.

FW <= 1.76 - dlclose Kernel Heap Overflow[edit | edit source]

Credits[edit | edit source]

  • Discovered by CTurt.
  • Privately implemented thanks to qwertyoruiop.
  • Explained by CTurt who published a writeup.
  • Exploit publicly implemented by kR105-zz and on another side by Zer0xFF (Thunder07) and Bigboss (psxdev).

Analysis[edit | edit source]

Bug Description[edit | edit source]

Integer overflow in the sys_dynlib_prepare_dlclose() system call can lead to a heap overflow causing memory corruption, allowing an attacker to obtain code execution in supervisor mode (ring0).

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 2.00 FW

FW <= 1.76 - BadIRET (CVE-2014-9322, CVE-2015-5675)[edit | edit source]

Credits[edit | edit source]

  • Andy Lutomirski for CVE-2014-9322 (2014-11-22)
  • Konstantin Belousov, Andrew Lutomirski for CVE-2015-5675 (2015-07-08)
  • Adam Zabrocki (pi3) for asking CTurt to test CVE-2015-5675 on PS4 (2015-08-21) [30], [31]
  • Volodymyr Pikhur for exploiting FreeBSD and PS4 in private (2015-09-24) [32]
  • CTurt for porting the exploit from FreeBSD 9 to PS4 (2015-12-06) [33]
  • kR105-zz for implementing the exploit for PS4 (2016-02-08)

Analysis[edit | edit source]

Bug Description[edit | edit source]

Faults associated with the stack segment (SS) register are not handled properly, allowing unprivileged users to trigger an IRET instruction that accesses a GS Base from usermode memory, providing an attacker with a method of privilege escalation.

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in 2.00 FW

FW ??? - setlogin Information Leak (CVE-2014-8476)[edit | edit source]

Warning: this has not been tested on PS4.

Credits[edit | edit source]

  • Mateusz Guzik for finding the vulnerability
  • Volodymyr Pikhur for advising to use this vulnerability at his Playstation 4 Rest Mode DEMO in REcon Brussels 2018
  • Francisco Falcon for making a PoC on FreeBSD 8.4

Analysis[edit | edit source]

Bug Description[edit | edit source]

The setlogin function in FreeBSD 8.4 through 10.1-RC4 does not initialize the buffer used to store the login name, which allows local users to obtain sensitive information from kernel memory via a call to getlogin, which returns the entire buffer.

When setlogin(2) is called while setting up a new login session, the login name is copied into an uninitialized stack buffer, which is then copied into a buffer of the same size in the session structure. The getlogin(2) system call returns the entire buffer rather than just the portion occupied by the login name associated with the session.

An unprivileged user can access this memory by calling getlogin(2) and reading beyond the terminating NUL character of the resulting string. Up to 16 (FreeBSD 8) or 32 (FreeBSD 9 and 10) bytes of kernel memory may be leaked in this manner for each invocation of setlogin(2).

This memory may contain sensitive information, such as portions of the file cache or terminal buffers, which an attacker might leverage to obtain elevated privileges.

Implementation[edit | edit source]

Patched[edit | edit source]

Maybe.

FW <= 1.02 - .strtab/.symtab kernel table of symbols kept on very low FWs[edit | edit source]

Bug description[edit | edit source]

  • Sony used to have two tables of symbols on very low versions: .strtab/.symtab and .dynstr/.dynsym (.strtab/.symtab had all symbols, .dynstr/.dynsym had around 75% of them).

Patched[edit | edit source]

Yes in 1.03 FW. Vulnerability present in PS4 1.02 DEX kernel.

Kernel securities[edit | edit source]

Kernel ASLR[edit | edit source]

Since 3.50 FW, ASLR (Address Space Layout Randomization) has been enabled in PS4 kernel. This means that to properly exploit the kernel to escalate privileges, an information disclosure vulnerability will most likely be needed to defeat ASLR and locate the kernel in memory.

Kernel SMAP[edit | edit source]

PS4 APU does not support SMEP ("Supervisor Mode Execution Prevention") so there is no way it supports SMAP ("Supervisor Mode Access Prevention"). However, in PS4 5.0x FW and above, a sort of SMAP was added to the kernel to prevent exploiters from pivoting the kernel stack pointer (RSP) to usermode memory: attempting to do so would crash the system. Sony probably added checks into the scheduler to check the stack pointer (RSP) against usermode addresses when running in kernel context. A new exploitation strategy is needed to run kernel ROP chains because an exploiters now needs to get his kernel ROP chain inside kernel memory to be executed.

SMAP bypass method: JOP[edit | edit source]

To bypass PS4 SMAP, qwertyoruiop decided in his 5.05 PS4 kernel exploit to go with the method he used on the Apple iPhone 7 - essentially using JOP to push a bunch of stack frames onto the kernel stack, and memcpy()'ing the kernel ROP chain into RSP. qwertyoruiop explained: "JOP seems to work, but exploit is not reliable enough to repeat it multiple times implementing logic in-between (like on the FW 4.55 kernel bug where every primitive would re-exploit the bug). Using pure JOP logic would be long because of the need to find good instructions gadgets, and would vary a lot from a FW version to another. The strategy chosen is thread-safe and calling-convention aware, but most importantly pivot-less. We use JOP to implement a simple loop based on deref&branch logic. Every iteration runs a function prolog followed by a branch. This pushes lots of stack frames on stack, padding RSP. When loop is done, prepare call to memcpy with RDI = RSP, RSI = controlled pointer, RDX = (size of pushed stack frame * number of iterations - 1). We overwrite all fake frames but one with ROP. Memcpy will return into our first gadget, kickstarting the chain. At tail end of chain we just return into matching function epilog to resume clean execution by popping the one untouched frame. RSP never pivoted so PS4 successfully runs the kernel ROP chain."

SMAP bypass method: cli/sti[edit | edit source]

A PS4 SMAP bypass has been showed by sleirsgoevy in his 6.72 PS4 kernel exploit implementation. It consists in wrapping the main kernel ROP with cli/sti pair, which would prevent it from being preempted. This way the thread's CPU core will not run other kernel code during kernel ROP execution, and other cores have no way of detecting the stack pivot, so the mitigation is defeated.

PS5 SMAP bypass method: CVE-2021-29628[edit | edit source]

A SMAP bypass has been found by m00nbsd while working on FreeBSD 12. It is named CVE-2021-29628 and affects FreeBSD 12.2 and later (til it was patched). It does not work on PS4 because PS4 kernel is based on FreeBSD 9 which did not contain the vulnerability and because PS4 SMAP does not come from FreeBSD but is custom from Sony. It used to work on PS5 before it was disclosed and patched. See CVE-2021-29628 on PS5 Dev Wiki.

CR0.WP protection[edit | edit source]

At least since PS4 System Software version 6.51, Sony instrumented all instructions that write to the CR0 register with checks for attempts to clear CR0.WP (Write Protect), which is necessary for patching the kernel. This is what it looks like in 6.51 kernel: 

  a1b79:       0f 22 c0                mov    cr0,rax
  a1b7c:       48 a9 00 00 01 00       test   rax,0x10000
  a1b82:       75 02                   jne    a1b86 <-- skip the next instruction if CR0.WP is not cleared
  a1b84:       0f 0b                   ud2    <-- #UD exception, causes a kernel panic
  a1b86:       c3                      ret

Note that the check is after the write, to prevent a ROP gadget from pointing straight at the mov and skipping the verification.

Bypasses (in chronological order):

  • Execute an unintended "move to cr0" instruction in the middle of another instruction (e.g. instruction "call $+0x220f1c" (e8 17 0f 22 00) contains an unintended "mov cr0, rax" (0f 22 00)).
  • Use kernel write to give your process JIT permissions, allocate JIT memory, and put entirely custom code there (avoids the problem altogether, as it is specific to ROP). This seems impossible on PS5 with a classic kernel exploit because of XOM.
  • Since the IDT (Interrupt Descriptor Table) is writable on FreeBSD, PS4 and PS5, it is possible to overwrite an exception handler without clearing CR0.WP first. One can overwrite the handler of #UD with a gadget of their choice (a stack pivot, or an "add rsp, ... ; ret" instruction, or whatever), then the UD2 instruction in the mitigation code will happily jump to it instead of the real handler, with CR0.WP cleared. To be precise, one must set up IDT handlers and point the IST (Interrupt Stack) to a ROP chain. It is required to poison the upper 16 bits of a pointer to make it non-canonical. Finally, write a custom page fault handler to run any kernel code you want. This technique proposed by sleirsgoevy since PS4 System Software version 6.51 was later adapted to PS5. However, this method slows down system performance compared to native execution because alone it can just run kernel ROP chains and it requires knowledge of gadgets positions. So on PS4, it is better to only use the IDT trick initially in a kernel exploit to patch kernel and allow non-ROP code execution for example by allowing JIT. On PS5, it is required to bypass XOM so an hypervisor exploit is required. See also this article by Jack Dates on 2022-08-17 that explains how use the IDT to bypass KASLR on x86.

Secure Modules[edit | edit source]

FW <= ?7.55? - Missing HMAC key length check in Secure Kernel leading to Partial SAMU KeyRings bruteforce[edit | edit source]

Credits[edit | edit source]

  • Discovered by yifan lu (2017-02-19), plutoo and Proxima (2018-08-09), Davee (2018-12-29) for PS Vita, by flatz (2021-12-18) for PlayStation 4.

Bug description[edit | edit source]

The PS4 Crypto Coprocessor (CCP) interface in Secure Kernel has a bug that allows to dump (or better saying, bruteforce) key rings from AMD SAMU. A crypto flaw was in the ability to issue HMAC operation with key length stricly lower than 16. For example, by setting it to 1 you can bruteforce key bytes one by one by comparing HMAC result with HMAC result with known partial key.

This trick may work on other crypto hardware as well if it does not restrict key lengths. Amazingly, Intel Secure Key Storage (SKS) of CSME subsystem also has a bug allowing to brute-force any key slot, but the issue exists at hardware level - insecure design of the keys distribution to crypto engines (AES, SHA, RC4). Intel did not recognize the bug arguing that to access SKS the CSME privileged arbitrary code execution is required, but SKS is exactly designed to protect the ROM generated keys from CSME firmware...

This exploit can be used to dump the PFS AES XTS and HMAC keys of a specific PS4 game PKG. Then one can use maxton's LibOrbisPkg or flatz's pkg_pfs_tool to unpack this PKG file.

It also lets one retrieve portability master keys. They decrypt blobs (stored in non-secure world, like in SceShellCore) that contain the portability keys.

Below is a sample code to dump some "raw" keys (as named by flatz). 

unsigned int key_count = 0x160;
unsigned int max_key_size = 0x40;
unsigned int *key_ids = (unsigned int *) malloc (key_count * 4);
unsigned int key_id = 0;
while (key_id < 0x160) {
    key_ids[key_id] = key_id;
    key_id++;
}
uint8_t* key_data = NULL;
size_t key_data_size = 0;
dump_raw_keys(key_ids, key_count, max_key_size, &key_data, &key_data_size);
hexdump(&key_data, &key_data_size);

A sample code to dump portability keys is available on line 908 of kpayload/source/samu_dump.c. Note that not all keys are used as some may be deprecated or added with System Software revisions.

Dumped savedata keys would be per-save, as the dumped key ring should only contain the derivated key (XTS) but not the one used to generate it.

Finally, one can retrieve its per-console VTRM keys (which are notably used for per-account securities like for act.dat and RIF).

However, master keyrings are the 0, 1, and 2 ones and cannot be dump them with this trick because they get locked during the bootprocess and cannot be read nor written nor copied to other keyrings. See also PS Vita keyrings.

Analysis[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Yes since a PS4 FW between 7.55 (unpatched) and 9.00 (patched).

FW <= 4.07 - Crashdumps encryption using symmetrical key and same key across software revisions[edit | edit source]

Credits[edit | edit source]

  • Discovered by ps4_enthusiast of fail0verflow (2017-12-27).

Bug description[edit | edit source]

The PS4 crashdumps encryption keys never changed between 1.01 and 3.15 FWs. Then between 3.50 and 4.07 FWs, Sony developers changed the keys many times but still used symmetrical key.

Analysis[edit | edit source]

Patched[edit | edit source]

Yes on PS4 FW 4.50 by using asymmetrical key. Tested between 1.01 and 4.07 PS4 FWs.

FW <= 3.70 - Reused keys lead to decryption of any PS4 1.00- 3.70 usermode SELF[edit | edit source]

Bug description[edit | edit source]

Sony reused encryption keys from System Software version 1.00 to 3.70 for PS4 usermode modules. As a result, any PS4 usermode module from those FWs can be decrypted on a PS4 running FW between 1.00 and 3.70.

Patched[edit | edit source]

Yes in 4.00 FW with the introduction of new keyset.

FW <= 2.50 - IDPS leak in sceSblAuthMgrDriveData on low retail FWs[edit | edit source]

Credits[edit | edit source]

  • Discovered by flatz (2018-08-27).

Bug description[edit | edit source]

By calling the sceSblAuthMgrDriveData kernel function on a PS4, which is a wrapper to the Authentication Secure Module associated fonction, it is possible to dump its IDPS (Console ID). It is possible because some PlayStation 4 operating system developer from Sony forgot to encrypt sceSblAuthMgrDriveData output by the Authentication Secure Module and that is how it was patched later. The PS4 IDPS is stored encrypted in an EID block in the Serial Flash.

To dump the PS4's IDPS, execute sceSblAuthMgrDriveData(0, in_buf, 0x160, out_buf, 0xA4, 1). Pass 0x160 bytes at 0x90C00 from sflash0s1.crypt into `in_buf` and dump `out_buf`.

Analysis[edit | edit source]

Implementation[edit | edit source]

Patched[edit | edit source]

Yes in PS4 3.00 retail FW. Works on any PS4 TestKit/DevKit FW.

FW <= ?1.62? - Missing version checks allow decryption of any GEN3 PUP[edit | edit source]

Credits[edit | edit source]

  • Discovered by flatz (2016).

Bug description[edit | edit source]

A bug in the Secure Module that handle PUP decryption allows any PS4 GEN3 on FW 1.62 or below to decrypt any GEN3 PUP (retail, TestKit, DevKit, Beta) with a version above 1.00 (post-prototype).https://github.com/SocraticBliss/ps4-pup_decrypt

The Secure Module mailbox code does not reset state after SMI checks failure, so to decrypt an arbitrary PUP, you need to ignore the mailbox error after executing the PupDecryptHeader command (1).

Implementation[edit | edit source]

Any PS4 PUP decryptor kernel payload that ignore the mailbox error could be used. See PUP#Decrypter_(first_step) for implementations.

Patched[edit | edit source]

Yes around PS4 FW 1.70.

Secure Kernel[edit | edit source]

FW <=?3.70? - Kernel ASLR collision leads to decrypted kernel partial leak - Matroska vulnerability[edit | edit source]

Credits[edit | edit source]

  • anonymous for sharing decrypted PS4 6.00b1 kernel file (2019-03-20)
  • shykelit for dumping 3.55 Jig PS4 kernel (2019-04-17)
  • zecoxao for discovering Matroska kernels and giving them that name (2019-04-18)
  • z80 for dumping 3.70 PS4 DevKit kernel (2019-04-18)
  • AlexAltea for reverse engineering kernel, ubios and vbios
  • Many people for sharing dumps of their PS4 kernels
  • CelesteBlue for backporting kernel exploits to dump PS4 4.74 kernel (2018-11-18), 3.50 (2019-05-09), 3.70 (2019-05-15) and 3.15 (2019-05-25)

Bug description[edit | edit source]

The kernel memory contains the kernel fSELF but with decrypted data, which in turn can be decompressed to grab ubios, vbios, kernel boot code and partial kernel.

By dumping PS4 kernel memory with a kernel exploit, in order to dump the x86 kernel, we sometimes find a strange fSELF. This fSELF is only partial: 1.5MB, but should be 17MB if it was the x86 kernel. Luckily it is only compressed, not encrypted. When uncompressing it using offzip, we can see only 1 segment. That is because the other segments have been cutted and the segment is incomplete. But we can see that it is the decrypted x86 kernel, as confirmed by diffing with anonymously shared decrypted full x86 kernel. In the decrypted x86 kernel, you can see a second ELF header. It is once again only compressed and not encrypted, and this is what zecoxao named the "Matroska kernel".

Sadly, this vulnerability is random, as it relies on kernel ASLR which is itself random. So depending on the System Software version, as modules have different sizes, kernel ASLR has more (100% on 3.15, 3.50 and 3.70) or less (1% on ?4.74?) chances to leak the Matroska kernel. It is unknown how we could improve this success rate. Maybe by instead of rebooting, causing a kernel panic or rebooting to recovery, entering rest mode then disconnecting power supply. A way to accelerate the process would be to scan kernel memory and check magics to see if there is a Matroska kernel. If there is, dump it, else reboot and cross fingers.

Note: vbios seems to be the same from 3.50 to 6.00b1 at least.

Analysis[edit | edit source]

Since PS4 3.50 FW, ASLR (Address Space Layout Randomization) has been enabled in PS4 kernel.

During PS4 boot, the following operations are executed:

  • the encrypted x86 kernel is loaded from Serial Flash
  • the secure kernel decrypt the x86 kernel SELF, without uncompressing it to some fixed address: at 0xFFFFFFFF84000000 in the case of 3.xx and 5.xx firmwares or 0xFFFFFFFFC4000000 in the case of 4.xx.
  • the secure kernel randomly chooses a base address for Kernel ASLR, starting from 0xFFFFFFFF80000000.
  • the secure kernel uncompresses the x86 kernel to the address determined by Kernel ASLR.

On some PS4 boots, Kernel ASLR base address can be very near of Matroska kernel address and the lack of memory separation and wipe renders the dump of Matroska kernel possible with only kernel memory read access.

Patched[edit | edit source]

Yes partially in 4.00 FW by increasing the kernel ASLR base address but it might have reappeared in newer versions like since 5.00 or 4.74, but with lower success rate.

It was also not present on 1.76 and below, so probably appeared when Sony worked on adding ASLR in PS4 Kernel. Also note that Matroska kernel is present on 3.15 even though there is no Kernel ASLR in this version.

Hardware[edit | edit source]

PCIe man-in-the-middle attack[edit | edit source]

Syscon glitching[edit | edit source]

It is possible to glitch the Syscon debug interface to allow access and dump keys. It was originally done by an anonymous member of fail0verflow.

Aeolia and Belize (Southbridge) SCA/DPA[edit | edit source]

Side Channel Analysis (SCA) with Differential Power Analysis (DPA) on Aeolia and Belize (PS4 Southbridge revisions) has been shown to be able to recover key material. Since Sony never used private/public key pairs, it is possible to exploit this and gain complete control over the Southbridge. You can attack the main FreeBSD kernel from here.

Nearly same methods are working on recent PS4 Pro motherboard NVB-003 that has Belize Southbridge (CXD90046GG).

Contrarly to Aeolia, Belize has ROM readout protection and clears stack which makes it more secure.

Old notes:

This is a hack to gain unsigned code execution on the Southbridge for all motherboard/console revisions. You might be able to glitch the EMC bootrom in order to bypass further signature checks and break the chain of trust. This hack might involve slowing down the Syscon clock. Timing the glitch based on SPI read accesses then either doing a power glitch or clock glitch to skip signature check. If the glitch fails, then we simply reset. This can be done with a very cheap CPLD/FPGA. Most Xbox 360 glitching modchips used a Xilinx Coolrunner because it is cheap and easy to use (board can cost as low as $5).

Related:

Arbitrary code execution in AMD SMU by incomplete hashing and bounds checking[edit | edit source]

Credits[edit | edit source]

  • Rudolf Marek discovered, disclosed to AMD then publicly through the following timeline:
    • Christmas 2013 - SMU firmware was analyzed from public AMD documentation
    • April 2014 - Bug was found in the SMU firmware
    • 2014-04-30 - Request to AMD sent
    • 2014-05-15 - Reply by AMD
    • 2014-05-16 - Encrypted communication, sending details
    • 2014-07-09 - AMD acknowledges the problem
    • In the meanwhile - Occasional communication
    • 2014-11-25 - AMD sends to Rudolf Marek a list of AMD AGESA versions which contain a fix

Bug description[edit | edit source]

A security vulnerability, discovered by Rudolf Marek in April 2014, in the recent AMD processors (Trinity and Richland, of FM2 socket) allows arbitrary code execution on the AMD System Management Unit (SMU).

It consists in two bugs in the SMU of AMD Trinity and Richland CPUs:

  • The AMD SMU firmware is not padded so some part (256 bytes) of the runtime firmware is not correctly covered by protection cover (0x55 0xaa ...).
  • The AMD SMU request function incorrectly checks bounds.

Similar, but not same problem affected AMD Kabini and Kaveri CPUs. It also likely affects PS4 as its APU is AMD Kabini/Jaguar.

Thanks to this vulnerability, the AMD SMU firmware can be dumped. From the dump, the Keys#AMD_SMU_Keys HMAC-SHA1 key was obtained.

Thanks to the knowledge of this key, the AMD SMU firmware could possibly be replaced by a custom one.

Analysis[edit | edit source]

Patched[edit | edit source]

Maybe after 2014-11-25, SMU vulnerability found by Rudolf Marek could have been patched on PS4 as AMD released patches: the fixed SMU firmware is part of updated AMD AGESA.

Untested - Arbitrary code execution in AMD SMU by custom firmware[edit | edit source]

Credits[edit | edit source]

  • Rudolf Marek for his exploit and documentation (2014)
  • zecoxao for public disclose (2023-05-17)

Bug description[edit | edit source]

It turns out that the "debug key" used to hash "debug" firmwares from AMD SMU effectively works on all retail (CEX) versions of the PS4 AMD SMU firmware as well.

According to zecoxao, as SMU is very privileged in PS4 (but not so privileged in PS5), one could probably dump his own PS4 keys/fuses with AMD SMU code execution. This could possibly lead to decryption of latest PS4 games, SEN access on PS4 running out-of-date System Software, conversion of any PS4 between CEX and DEX, as well as decrypting the PS4 Kernel and derived binaries.

Analysis[edit | edit source]

Patched[edit | edit source]

Maybe on recent PS4 firmwares with a BIOS update that would require a different and possibly more secure digest or signature.

PlayStation Store[edit | edit source]

PS Store leaks PS4 base package URLs[edit | edit source]

Discovered in ?2018? Patched in ?2023? Revealed on 2024-01-27 by PixelButts (see e.g. [34]).

Kamaji PS Store API leaked PS4 base package URLs via unintended URL calls.

This exploit, which was later patched for PS5 URLs, allowed an unusual query to be made which would redirect to an incorrect base package.

Take any game Entitlement ID. Malform the URL with the Content ID of the content of your choice. Ask for the game metdata field. You get base .pkg URL. 

https://catalog.api.np.km.playstation.net/meta/api/v1/us/en/sku/UP5541-CUSA15915_00-SAMURAISPIRITSEA-U001/entitlement/<[[Content ID]]>?fields=game_meta

Normally this exploit needed that the Content ID was of the same game as the Entitlement ID, but the Deep Down game required a different region and different game to get its base package.

This is thanks to this vulnerability that it was discovered that a retail package existed for the cancelled Deep Down game.

Rather than keeping silently publishing a list of URLs, some people ended up publishing the method and it got patched.

Reverse Engineering
Dumps & Strings
Dumps
Strings
Communication
USB
Wifi/LAN
Keys, Commands & Digests
Activation AFV  ·  Activation ACF  ·  Bruteforcing  ·  Crypto / DRM  ·  Keys  ·  Fail Keys   ·  KeySlots  ·  Digests  ·  Magics  ·  AES binaries  ·  --ee-hook  ·  SoftWareUpdater  ·  DualShock 4 HID Commands
Emulation
General
Compatibility Lists
Manuals
System Modules
System libraries
Retrieved from "https://www.psdevwiki.com/ps4/index.php?title=Vulnerabilities&oldid=296971"