Official PS3 BD-J Homebrew Thread

Official PS3 BD-J Homebrew Thread

I saw this and i just want to share with you.

Originally Posted by silenoz

I've managed to launch a simple java game on Game Os, with the BD-J functionality, thanks to the HDCookBook (https://hdcookbook.dev.java.net/) project. You just need to copy some files on a usb key and you're good to go.

Aside from the whole Virtual Machine thing that the Java runs upon, which makes it nearly impossible to "break out" from, theres not a whole lot we can do.

Sure, we can run some code in the Virtual Machine, but nothing that we can use to "escape" and gain access to the PS3.

Not to mention, I DOUBT that Sony would not think about this and add extra safeguards against it being hacked, having HDD storage is fine, but where that storage (through the virtual machine) is assigned to the PS3 HDD is mostlikely set by the HV/Kernel, which we again don't have access to change, so we would only be able to access temporary files created right then and there.

So, in summary, interesting but it most likely wont let us achieve our goals!

Unzip the file on the root of an usb or flash drive. Go to the device in the video menu and launch "AVCHD" it's like a mini DVD, with a BD-J game on the "BONUS" section.

This might lead to something or not who knows.. at least we have some homebrew.

tmaster is the "AVCHD" from silenoz too, or did you add that here yourself based upon what you quoted from him? The reason I ask is I plan to mention this in the Site News, but want to either credit you or him for it. From what I'm seeing, the typical scene lamers are crying about "stealing credit" when in fact it appears they may have stolen the file from here labeling it as their own to go with a post made by silenoz.

Here is a brief guide as well, written by myself:

1) Download it HERE and UnZip it.
2) Copy it to the root of a USB/Flash drive.
3) Go to the device in the video menu and launch "AVCHD".
4) Go to BONUS and click GAME to launch Blaster Bunny.

It has also been confirmed that this method has been working on all PS3's regardless of Firmware and region, including 2.41 apparently.

Finally, THANKS CJPC for the clarification... and for not yelling "exploit" when infact it isn't one at all.

I came up with the idea of attempting to use BD-J for accessing to PS3 however as I do not have BD-R writer and I couldn't make up AVCHD start BD-J code. Until this moment I have been waiting for arrival of BD-J disk from Sun that should contain BD-J code providing functionality to upload more code via TCP/IP and thus far avoiding the need to burn new media with each iteration.

I will start testing some ideas and possible weaknesses. There is access to storage and via BD-J code you should be able to obtain absolute path on the filesystem (although the JVM should prevent you from coming to other parts of the filesystem). Native code provides some possibilities. So I wouldn't give up on this path yet.

Humm.. this is interesting! Although CJPC says that it can't be used to gain access, and I don't want to sound like I know better than him, but I still have some questions about the feasability of this. Am I right in saying that this is the first "code" that we can run on the PS3 ? whether java or native or something ?

If yes, then it's still a new door by which we could access the ps3, IF we (==you) can find an exploit in the virtual machine... maybe it's sun's JVM, in which case, which version? or maybe it's Sony's custom implementation, any known exploit affecting a JVM.. anyhow, there might be a buffer overflow that can be used, or something else...

And what about JNI.. is it disabled for the BD-J and can't be used or are we in a full JVM implementation ? I'm guessing we're sandboxed, but is there a way to break through ? (think about a signed .jar, maybe there's a similar way to break through the sandbox).

Well, you raise good points, and yes, your forgetting about OtherOS, it runs our code on PS3 hardware too!

But yes, if we could break out of the virtual machine, we would be running code on the system, but we may only get stuck in a lowlevel mode, in which not much can be done (think user mode). Sure it would run code, but nothing to really enough to "tinker" with the system.

Thats the issue however, breaking out of the virtual machine, its designed not to be broken out from, and the system could be watching for any "breakouts" from the VM, and could halt the system if it detects any, putting us back to square one.

If the VM could be broken out from, and If the PS3 was none the wiser, it would be great, but its like breaking out of a solitary jail cell (VM), then having to break out of the building that the cell was in (User/Kernel mode), then having to scale the fence of the Jail to get "full" access (Toppling the beloved HV).

Glad my points were good, was afraid it would be flagged as stupid rambling

Yes, I understand the difficulty of getting out of VM and everything involved (user/kernel space/etc..) but who knows, it's still worth the shot.. I mean, yes the VM was designed not to be broken out from, but the whole PS3 was designed that way too..

By the way, when I said "the first code we can execute", I meant "from the XMB firmware OS".
Also, about OtherOS, it's not the same thing, IMHO. I'm not in the loop with the PS3 dev stuff (and I still can't access the dev forum ) but I was guessing that the OtherOS was running as native code on the processor in it's own space, we could break through there, that's one door, one opportunity, but the VM is just yet another door that might not be as secure as the OtherOS system... They probably put a lot of security over OtherOS because they knew people would try to break in from there.. maybe they didn't put as much effort in the BD-J VM since it's not the "natural" way to go for breaking in...

Also the VM is running from the firmware OS, so maybe it's already one step closer to the kernel... In either case, it's better to be slamming two doors at once rather than just one, whichever breaks first will be the gate to our freedom!

Anyways, I'm just thinking of a buffer overflow, you get your code run from there and you can execute whatever you want, any sandbox or watchdog or whatever would not be able to prevent/protect a buffer overflow, unless the kernel/processor has a specific 'sandbox' flag that can be set on a process... but again, maybe we could use the buffer overflow to inject code into another higher-level security process and use that instead to gain access..

To conclude: nothing is 100% secure! I just hope you guys didn't completely drop this opportunity.

p.s.: Wasn't there also some other way to execute unsigned code from an older firmware version ?