PS5 (UPDATE 2 ) Thefl0w discloses"Blu-ray Disc Java Sandbox Escape" vulnerabilities (PS3, PS4, PS5)

Update (See Tabs Below PS3 / PS4): Since the disclosure several developer's have went on the hunt and we have seen PoC releases and TEST payload pushed, We have confirmation the PoC is working on 9.00, other have been testing impact on 9.03/.04. See all the details from developer's like sleirsgoevy / @zecoxao / psxdev (aka bigboss) in the PS4 Tab. Some preliminary discussions about the PS3 impact have been discussed in this thread from various developer's like @bguerville and @zecoxao


.Original Article: Developer TheFl0w who is well known in the Homebrew and Hacking in the PlayStation Community, via the hackerone program the hacker has yet again disclosed details on vulnerabilities (5) "bd-jb Blu-ray Disc Java Sandbox Escape" is affecting PS3, PS4, PS5. Sony has patched these vulnerabilities in recent firmware updates for the PS5 / PS4 with firmware update's of 5.00 FW for the PS5 and 9.50 FW for the PS4. These methods are also likely to work on the PS3 according to thefl0w (likely on the latest firmware).

thefl0w has detailed some advantages this concept provides over a webkit exploit, you can see that information and various details in the "additional info" tab below, along with some clarification due to over hyping some aspects of this exploit..:
-STLcardsWS​

FU6TB0UVUAAjYaL-1536x1157.jpg

  • Hey PlayStation!
    Below are 5 vulnerabilities chained together that allows an attacker to gain JIT capabilities and execute arbitrary payloads. The provided payload triggers a buffer overflow that causes a kernel panic. Please consider each of the vulnerabilities individually. AFAIK, this is the first exploit chain that is being submitted to you :)

    Proof-of-concept
    Attached is the exploit chain bd-jb as a .iso file which demonstrates the exploitation of vulnerabilities 1-4 that demonstrates the ability to run arbitrary payloads. Burn the iso image with UDF 2.5 file system. You can send the payload using nc $PS4IP 1337 < payload.bin. The provided payload causes a kernel panic by triggering vulnerability 5 (the file /PWN/0 has been modified to use internal allocation and has a size of 4MB filled with A). Tested on latest firmware 9.00.

    Impact

    • With these vulnerabilities, it is possible to ship games on bluray discs. That is possible even without a kernel exploit as we have JIT capabilities.


    Update (Slides from presentation):
    Hardwear.io USA 2022 - bd-jb: Blu-ray Disc Java Sandbox Escape:
    https://github.com/TheOfficialFloW/Presentations/blob/master/2022-hardwear-io-bd-jb.pdf
    (Thanks to @Roxanne for the tip)
    Update June 22, 2022: Video Presentation posted online


  • Vulnerabilities
    d
    [MEDIUM][PS4] [PS5] Vulnerability 1
    The class com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl deserializes the userprefs file under privileged context using readObject() which is insecure:
    Code 635 Bytes
    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(); }
    }
    Code 685 Bytes
    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; }
    }

    An attacker can replace the userprefs file with a malicious serialized object to instantiate classes under privileged context. On older firmwares such as 5.05, where the commit https://github.com/openjdk/jdk/comm...9aa065025e753ca2e1f3b7ebc798e0d954de75d995de5 is not present, exploitation of this vulnerability is easy: An attacker can instantiate a ClassLoader subclass to call defineClass with all permissions and finally bypass the security manager.


    [MEDIUM][PS4] Vulnerability 2

    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.
    Code 320 Bytes
    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;
    }

    [MEDIUM][PS4] [PS5] Vulnerability 3

    The class com.sony.gemstack.org.dvb.io.ixc.IxcProxy contains the protected method invokeMethod which can call methods under privileged context. Permission checks in methods can be bypassed if the following conditions are met:
    • The method is public and non-static.
    • The method's class is public, non-final and can be instantiated.
    In such a scenario, an attacker can write a subclass of the target class which implements an interface where the desired method throws RemoteException.
    For example, there are permission checks in File.list(). An attacker can bypass them with the following classes:
    Code 111 Bytes
    class FileImpl extends File implements FileInterface { FileImpl(String pathname) { super(pathname); }
    }
    Code 91 Bytes
    interface FileInterface extends Remote { public String[] list() throws RemoteException;
    }
    This vulnerability can be used to leak the file system structure as well as dumping files (for example from /app0/).

    [HIGH][PS4] Vulnerability 4
    The "compiler receiver thread" receives a structure of size 0x58 bytes from the runtime process:
    Code 603 Bytes
    typedef struct { uint8_t cmd; // 0x00 uint64_t arg0; // 0x08 uint64_t arg1; // 0x10 uint64_t arg2; // 0x18 uint64_t arg3; // 0x20 uint64_t arg4; // 0x28 uintptr_t runtime_data; // 0x30 uintptr_t compiler_data; // 0x38 uint64_t data1; // 0x40 uint64_t data2; // 0x48 uint64_t unk; // 0x50 } CompilerAgentRequest; // 0x58 CompilerAgentRequest req; while (CompilerAgent::readn(s, &req, sizeof(req)) > 0) { uint8_t ack = 0xAA; CompilerAgent::writen(s, &ack, sizeof(ack)); if (req.compiler_data != 0) { memcpy(req.compiler_data + 0x28, &req, sizeof(req)); ... } ...
    }
    This struct contains a pointer at offset 0x38 (we call it compiler_data) from the compiler process which is used to make a backup of the request structure. An attacker can simply send an untrusted pointer and the compiler receiver thread will copy data from the request into its memory. In other words, we have a write-what-where primitive. An attacker can exploit this vulnerability by supplying a pointer to JIT memory and store the content to be written in the request. The compiler will write this data into JIT memory and therefore give us the opportunity to execute arbitrary payloads. This has severe implications:
    • An ELF loader can be written to load and execute games.
    • Kernel exploitation becomes trivial as there is no SMEP and one can simply jump to user with a corrupted function pointer.

    [HIGH][PS4] [PS5] Vulnerability 5

    The UDF driver https://github.com/williamdevries/UDF is used on the PS4 and PS5 which contains a buffer overflow. An attacker can make the size inf_len larger than sector_size (the assumption of internal allocation is that the data is smaller than the sector size) and cause an overflow with memcpy().
    Code 758 Bytes
    int udf_read_internal(struct udf_node *node, uint8_t *blob) { struct file_entry *fe = node->fe; struct extfile_entry *efe = node->efe; struct udf_mount *ump; uint64_t inflen; int addr_type, icbflags; uint32_t sector_size; uint8_t *pos; /* get extent and do some paranoia checks */ ump = node->ump; sector_size = ump->sector_size; if (fe != NULL) { inflen = le64toh(fe->inf_len); pos = &fe->data[0] + le32toh(fe->l_ea); icbflags = le16toh(fe->icbtag.flags); } else { inflen = le64toh(efe->inf_len); pos = &efe->data[0] + le32toh(efe->l_ea); icbflags = le16toh(efe->icbtag.flags); } addr_type = icbflags & UDF_ICB_TAG_FLAGS_ALLOC_MASK; /* copy out info */ memset(blob, 0, sector_size); memcpy(blob, pos, inflen); return (0);
    }



  • via TheFlow's Official Twitter:

    • bd-jb: Blu-ray Disc Java Sandbox Escape affecting PS3, PS4, PS5. My talk at
      @hardwear_io will be uploaded in a few weeks. #hardwear_io via

    • Fixed on PS4 FW 9.50 and PS5 FW 5.00 via

    • I wanted to clarify: Without a kernel exploit, you won't be able to run any games (which would have worked on the PS4 only anyways), because we don't have enough RAM in the bd-j process and there are some other constraints. It was only a theoretical impact via .

    • Advantages of bd-jb compared to WebKit exploit:
      • Works on both PS4/PS5
      • 100% reliable -
      • Firmware-agnostic (ROP-less code execution)
      • Bigger kernel attack surface
      • JIT for executing payloads, so you can write a kernel exploit in C (on PS4 only) via.

    FU6Yru1VUAAoOk4-1536x1157.jpg

    FU6Yr_cUcAAA6bz-1536x1157.jpg

    FU6bzTWVEAA5sHO-1536x1157.jpg



  • Since there has not been as much details about the PS3 Impact other then we know it could affect the PS3, There has been some discussion about the PS3 impact and these findings here in the psx-place forum's as PS3 Hacker / Developer @bguerville shares some of his opinion and thoughts throughout several post with fellow developer @zecoxao. That discussion starts at this post and goes throughout the thread:

    .Update June 20
    via Roxanne : "
    It's an very early POC so far tho thanks to psxdev (bigboss)"

    IMG_0206.JPEG IMG_0205.JPEG



  • For Advanced User's Only A Proof of Concept of the TheFlow's discoveries where released to the public via @sleirsgoevy using published vulnerabiltes from TheFlow #2 (privileged constructor call / #3 (privileged method call / #4 (jit hack​

    via @sleirsgoevy

    Partial reimplementation of BD-JB (without kernel part): https://github.com/sleirsgoevy/bd-jb
    ISO image: https://mega.nz/file/p99hHaYT#i4XxImp4I_ou-dWO5vk6GMX3xn4EqcoIV41jFWZdXdQ
    Built with "PS3 BD-J DevKit": https://mega.nz/folder/A4IFGYg

    via ReadME @ github:
    BD-JB reimplementation based on TheFlow's report and presentation. Implements loading arbitrary .bin payloads using vulnerabilities #2 (privileged constructor call), #3 (privileged method call), #4 (jit hack) from the report. Listens for payloads on port 9019.

    The first (and only) argument to the payload is the address of sceKernelDlsym, which can be used to resolve other symbols. It seems that libkernel_sys.sprx always has id 0x2001, and you can look up other libraries by getting the full list of handles and looking up name of each handle. You can't directly call syscalls due to missing kernel patches.


    https://twitter.com/sleirsgoevy/status/1537230108338970624
    https://github.com/sleirsgoevy/bd-jb
    .UPDATE June - 18

    bd-jb
    (from psxdev aka bigboss)

    bd-jb is a BD-JB reimplementation for prospero based on TheFlow's report and sleirsgoevy base code
    By now only implemented:
    • Vulnerability #2 to list /app0 content
    • Added udp logs you can get it in your pc change host variable on MyXlet.java and use something like this on your pc/mac:
    socat udp-recv:18194 stdout

    See more info @ github: https://github.com/psxdev/bd-jb
    https://twitter.com/psxdev/status/1537947200713412609
    .UPDATE June - 18

    TESTING PURPOSE ONLY
    (use at your risk)
    @zecoxao via twitter:

    those of you with already created bd-jb bluray and that are in 9.03 or 9.04, please test this payload
    https://www17.zippyshare.com/v/awY1gGiJ/file.html


  • https://www.psx-place.com/threads/u...box-escape-vulnerabilities-ps3-ps4-ps5.37554/

 
Last edited by a moderator:
Developer TheFl0w who is well known in the Homebrew and Hacking in the PlayStation Community, via the hackerone program the hacker has yet again disclosed details on vulnerabilities (5) "bd-jb Blu-ray Disc Java Sandbox Escape" is affecting PS3, PS4, PS5. Sony has patched these vulnerabilities in recent firmware updates for the PS5 / PS4 with firmware update's of 5.00 FW for the PS5 and 9.50 FW for the PS4. These methods are also likely to work on the PS3 according to thefl0w (likely on the latest firmware).

thefl0w has detailed some advantages this concept provides over a webkit exploit, you can see that information and various details in the "additional info" tab below, along with some clarification due to over hyping some aspects of this exploit..:
-STLcardsWS​


  • Hey PlayStation!
    Below are 5 vulnerabilities chained together that allows an attacker to gain JIT capabilities and execute arbitrary payloads. The provided payload triggers a buffer overflow that causes a kernel panic. Please consider each of the vulnerabilities individually. AFAIK, this is the first exploit chain that is being submitted to you :)

    Proof-of-concept
    Attached is the exploit chain bd-jb as a .iso file which demonstrates the exploitation of vulnerabilities 1-4 that demonstrates the ability to run arbitrary payloads. Burn the iso image with UDF 2.5 file system. You can send the payload using nc $PS4IP 1337 < payload.bin. The provided payload causes a kernel panic by triggering vulnerability 5 (the file /PWN/0 has been modified to use internal allocation and has a size of 4MB filled with A). Tested on latest firmware 9.00.

    Impact

    • With these vulnerabilities, it is possible to ship games on bluray discs. That is possible even without a kernel exploit as we have JIT capabilities.

  • Vulnerabilities
    d
    [MEDIUM][PS4] [PS5] Vulnerability 1
    The class com.sony.gemstack.org.dvb.user.UserPreferenceManagerImpl deserializes the userprefs file under privileged context using readObject() which is insecure:



    An attacker can replace the userprefs file with a malicious serialized object to instantiate classes under privileged context. On older firmwares such as 5.05, where the commit https://github.com/openjdk/jdk/comm...9aa065025e753ca2e1f3b7ebc798e0d954de75d995de5 is not present, exploitation of this vulnerability is easy: An attacker can instantiate a ClassLoader subclass to call defineClass with all permissions and finally bypass the security manager.


    [MEDIUM][PS4] Vulnerability 2

    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.


    [MEDIUM][PS4] [PS5] Vulnerability 3

    The class com.sony.gemstack.org.dvb.io.ixc.IxcProxy contains the protected method invokeMethod which can call methods under privileged context. Permission checks in methods can be bypassed if the following conditions are met:
    • The method is public and non-static.
    • The method's class is public, non-final and can be instantiated.
    In such a scenario, an attacker can write a subclass of the target class which implements an interface where the desired method throws RemoteException.
    For example, there are permission checks in File.list(). An attacker can bypass them with the following classes:


    [HIGH][PS4] Vulnerability 4
    The "compiler receiver thread" receives a structure of size 0x58 bytes from the runtime process:

    This struct contains a pointer at offset 0x38 (we call it compiler_data) from the compiler process which is used to make a backup of the request structure. An attacker can simply send an untrusted pointer and the compiler receiver thread will copy data from the request into its memory. In other words, we have a write-what-where primitive. An attacker can exploit this vulnerability by supplying a pointer to JIT memory and store the content to be written in the request. The compiler will write this data into JIT memory and therefore give us the opportunity to execute arbitrary payloads. This has severe implications:
    • An ELF loader can be written to load and execute pirated games.
    • Kernel exploitation becomes trivial as there is no SMEP and one can simply jump to user with a corrupted function pointer.

    [HIGH][PS4] [PS5] Vulnerability 5

    The UDF driver https://github.com/williamdevries/UDF is used on the PS4 and PS5 which contains a buffer overflow. An attacker can make the size inf_len larger than sector_size (the assumption of internal allocation is that the data is smaller than the sector size) and cause an overflow with memcpy().




  • via TheFlow's Official Twitter:

    • bd-jb: Blu-ray Disc Java Sandbox Escape affecting PS3, PS4, PS5. My talk at
      @hardwear_io will be uploaded in a few weeks. #hardwear_io via

    • Fixed on PS4 FW 9.50 and PS5 FW 5.00 via

    • I wanted to clarify: Without a kernel exploit, you won't be able to run any pirated games (which would have worked on the PS4 only anyways), because we don't have enough RAM in the bd-j process and there are some other constraints. It was only a theoretical impact via .

    • Advantages of bd-jb compared to WebKit exploit:
      • Works on both PS4/PS5
      • 100% reliable -
      • Firmware-agnostic (ROP-less code execution)
      • Bigger kernel attack surface
      • JIT for executing payloads, so you can write a kernel exploit in C (on PS4 only) via.

    View attachment 37572
    View attachment 37573
    View attachment 37576


But how.does this affect the PS3 all I seen is the thread discussing about the ps4 and PS5?
 
These methods are also likely to work on the PS3 according to thefl0w
Since, it affects the PS3 and if it would lead to a kernel exploit then does it mean on non-BC consoles we could have a not-coldboot but CFW running.
A kernel exploit would also allow decrypted ps2 isos on these models same way it is achieved on CFW.
 
So if this works on PS3, 4, and 5, does it mean it will work on all (disc based) editions like phat, slim, super slim, etc.?
 
Does the iso require to be burned on a BD disc or can it be burned on a DVD disc and also work just fine?
 
Does the iso require to be burned on a BD disc or can it be burned on a DVD disc and also work just fine?

I don't see how it could be burned onto anything other than a BD disc, since a standard DVD would never be able to hold a full AAA game. Indie games maybe, but I don't even know if the PS5 will read a game off of a standard DVD. Maybe someone else knows.
 
I don't see how it could be burned onto anything other than a BD disc, since a standard DVD would never be able to hold a full AAA game. Indie games maybe, but I don't even know if the PS5 will read a game off of a standard DVD. Maybe someone else knows.
I have exploiting ps4 in mind, not running games on ps5.
 
I don't see how it could be burned onto anything other than a BD disc, since a standard DVD would never be able to hold a full AAA game. Indie games maybe, but I don't even know if the PS5 will read a game off of a standard DVD. Maybe someone else knows.

PS3 games can start from DVD-/+R, not only from BD-R on devkits (and hacked retails). So maybe Sony kept this feature on newer devices for handy of developers (early builds and indie gamedevs)?

But, BD-J cannot start from anything else than BD discs right now, so it doesn't really matter anyway.
 
PS3 games can start from DVD-/+R, not only from BD-R on devkits (and hacked retails). So maybe Sony kept this feature on newer devices for handy of developers (early builds and indie gamedevs)?

But, BD-J cannot start from anything else than BD discs right now, so it doesn't really matter anyway.
What's BD-J? Could you explain or send me a link to a resource where I can learn about types of bluray discs?
 
Just like e.g BD-Video, BD-J is just ordinary BD disc (BD-ROM, BD-R LTH/HTL or BD-RE). The names are related to their content, not the physical structure. It is Java signed executable (archives to be precise, *.jar files are ZIP64) AFAIK and the problem is (was?) the signing process to make disc be accepted by consoles and bd players. So it means that on firmware side must exist kind of JRE to understand BD-J and it means keys and the algos are known (?).

Unfortunately it is al what I know. Not much as You can see. :)
 
Basically, this exploit allows unmodded PS4/PS5 consoles (except PS5 digital edition) to run homebrew on discs, kinda like soft-mod on-the-fly via disc.
 
I haven't seen the exploit files or followed much what theFlow had to say about this, I ONLY read the hacker one report, I didn't see any mentions of the PS3 in it but it's not surprising as it's not included in the bounty scheme.

We already know that BD-J is a possible entry point, all those interpreter/jit based apps providing the ability to run user provided code or script are legit targets.
Iirc 2 years ago Cturt said somewhere that he would probably look into BD-j if he were to make a PS3 exploit.

Am a little surprised by the claim that a jit exploit would work though because on PS3, I am not aware of any apps using JIT.
Browser, Flash player, Lua, Regex etc.. all run on interpreters instead.
The reason is quite simple, in userland an app cannot create writeable executable memory, all executable memory is read-only therefore JITs cannot be used.
To make a dynarec for emulators, kernel patches and a custom syscall are used, if there was a way to allocate writeable executable memory without kernel access, it would have been used long ago on CFW, we would have better emu performance in general because most ports would have used dynarec from the start and probably a functional n64 emu port from Vita.

As far as I can make out, BD-j would have to somehow overcome that major problem in order to run on JIT, technically of course they could have implemented something to that effect (I doubt they did though) but then if there were to be exceptions anyway, why not extend it to the browser, flash player etc.. The security risks would have been on par, this bd-j exploit on PS4/PS5 confirms it, so there would be no good reason not to use JITs for all system features needing it.
Unless the entire BD-j thing runs at kernel level, like PS2 emu? Never heard of that though, dvd/bd video functions are hooked in kernel payloads iirc and used in real time so I would not automatically assume it's like PS2 emu, and just for BD-J?
I never bothered looking at the BD-j java engine closely (or the BD engine itself for that matter), we have a minimal devkit, iirc Jason might have tested it, and we could potentially investigate.
A HEN installer/loader based on disc could be nice although that would require a burner, not sure it's better than a local flash or webkit exploit in that regard, it's the main reason that drove me to pursue the Flash player Actionscript option rather than the BD-J Java option back in the 4.83 release days actually.

Either way, a userland and a kernel exploit will not change the current status quo on PS3. I already have another userland exploit and another LV2 exploit but that doesn't help in any way the situation to progress further, what the non CFW compatible PS3 needs now to go beyond HEN and provide more features is a LV1 exploit or similar, and that is unlikely to come from hacker one or PS4/PS5 research..
 
Last edited:
I haven't seen the exploit files or followed much what theFlow had to say about this, I ONLY read the hacker one report, I didn't see any mentions of the PS3 in it but it's not surprising as it's not included in the bounty scheme.

We already know that BD-J is a possible entry point, all those interpreter/jit based apps providing the ability to run user provided code or script are legit targets.
Iirc 2 years ago Cturt said somewhere that he would probably look into BD-j if he were to make a PS3 exploit.

Am a little surprised by the claim that a jit exploit would work though because on PS3, I am not aware of any apps using JIT.
Browser, Flash player, Lua, Regex etc.. all run on interpreters instead.
The reason is quite simple, in userland an app cannot create writeable executable memory, all executable memory is read-only therefore JITs cannot be used.
To make a dynarec for emulators, kernel patches and a custom syscall are used, if there was a way to allocate writeable executable memory without kernel access, it would have been used long ago on CFW, we would have better emu performance in general because most ports would have used dynarec from the start and probably a functional n64 emu port from Vita.

As far as I can make out, BD-j would have to somehow overcome that major problem in order to run on JIT, technically of course they could have implemented something to that effect (I doubt they did though) but then if there were to be exceptions anyway, why not extend it to the browser, flash player etc.. The security risks would have been on par, this bd-j exploit on PS4/PS5 confirms it, so there would be no good reason not to use JITs for all system features needing it.
Unless the entire BD-j thing runs at kernel level, like PS2 emu? Never heard of that though, dvd/bd video functions are hooked in kernel payloads iirc and used in real time so I would not automatically assume it's like PS2 emu, and just for BD-J?
I never bothered looking at the BD-j java engine closely (or the BD engine itself for that matter), we have a minimal devkit, iirc Jason might have tested it, and we could potentially investigate.
A HEN installer/loader based on disc could be nice although that would require a burner, not sure it's better than a local flash or webkit exploit in that regard, it's the main reason that drove me to pursue the Flash player Actionscript option rather than the BD-J Java option back in the 4.83 release days actually.

Either way, a userland and a kernel exploit will not change the current status quo on PS3. I already have another userland exploit and another LV2 exploit but that doesn't help in any way the situation to progress further, what the non CFW compatible PS3 needs now to go beyond HEN and provide more features is a LV1 exploit or similar, and that is unlikely to come from hacker one or PS4/PS5 research..

You can see the vulnerabilities on the bdjstack folder inside the ps3's bdplayer folder. i also believe lv2 has the same UDF exploit though i cannot confirm this with 100% certainty. either way, the exploit is 100% reliable which makes it more useful than webkit, especially for the 3k and superslim models
 
You can see the vulnerabilities on the bdjstack folder inside the ps3's bdplayer folder. i also believe lv2 has the same UDF exploit though i cannot confirm this with 100% certainty. either way, the exploit is 100% reliable which makes it more useful than webkit, especially for the 3k and superslim models
I am curious but I don't have any files to test any of that and I don't have a burner either so my options are limited right now in that regard.
Maybe Jason can test stuff so I can at least look at it.

The userland exploit in HEN works 100% of the time too now that I fixed the scanning issue, so do the flash exploits including the one I use for the Toolset, any crash one may experience would be caused by something else, not the exploits themselves. The next hen installer update will have the fix.

Regarding UDF, that should be investigated of course, it is always nice to have options but I have an exploit of my own ready so I am not sure I will bother with this, especially as s#ny does not bother patching anything anymore, I think I will pass and focus on my own stuff..
 
Last edited:

Featured content

Trending content

Back
Top