Official PS3 BD-J Homebrew Thread

[adrianc1982]

Originally Posted by trion Hmm when i get home i want to try it with JavaOs (http://en.wikipedia.org/wiki/JavaOS) Hope that is uses all the power on the playstation and is faster then linux. and here are some emulators that run on Java: http://www.aep-emu.de/Emus-file-emus_os-system-Java.html

So we can run all this emulators with this hack? Sorry for the stupid question, havent tested out the file posted.

[CJPC]

Older versions, no you couldn't run unsigned code. As for OtherOS, it isnt a sandbox per-se, it is running on the cell hardware, with access through the Hypervisor, it is just under a different access policy than the PS3 OS, so it has less power over what it can do.

And remember, the PS3 was also designed to prevent against any type of overflow, thats one of the points of having a Hypervisor, to look over everything, and make sure nobody tries to break in.

In theory emulators could be made I suppose, but it depends on how fast the VM actually is, I dont think it was designed in mind to have NES and Genesis games running thru it! Its like having an armed guard inside a bank safe, even if someone gets in, they will be stopped once the door is open!

[kakarotoks]

Older versions, no you couldn't run unsigned code. As for OtherOS, it isnt a sandbox per-se, it is running on the cell hardware, with access through the Hypervisor, it is just under a different access policy than the PS3 OS, so it has less power over what it can do.

- Yeah, it's the hypervisor the main issue... But I thought the hypervisor was a layer on top of OtherOS, preventing access to the ps3 graphics hardware.. And I was thinking that the Hypervisor was running only on top of OtherOS, so I was guessing the PS3's FW OS was not behind the hypervisor, which would ease breaking in through an exploit.. although I might be wrong, maybe the hypervisor is always running and the FW OS simply asks the Hypervisor to give it access to the hardware providing some key/authentication, in which case, we're back to square one. You're in a better position to know how this all works in reality.

And remember, the PS3 was also designed to prevent against any type of overflow, thats one of the points of having a Hypervisor, to look over everything, and make sure nobody tries to break in.

humm.. if there's buffer overflow protection from the cpu/kernel side, then yep, it's another story, of course, executing code in the .data section of an ELF can be easily checked by flagging memory segments with the executable flag, but if there's a buffer overflow that allows overwriting the code in the .text section, then that might be possible (change the stack ret value to go to a legitimate function/code from the OS FW that would call hypervisor_disable() or game_start or something.. and put the right values in the stack to pass it the right parameters, like the device path for example (a /dev/bd should be readable the same as a .iso file...))... although, again, Sony might have been smart enough to make their compiler wrap every function called by a stub which would check the stack before and after every function call... it adds overhead, but adds security against those types of overflow...

In theory emulators could be made I suppose, but it depends on how fast the VM actually is, I dont think it was designed in mind to have NES and Genesis games running thru it! Its like having an armed guard inside a bank safe, even if someone gets in, they will be stopped once the door is open!

hehe, I don't think an emulator would be fast enough on that VM and I don't think that our purpose is a SNES emulator (I can have that on my PC). The interesting part would be to get full access to the hardware... it's also much more challenging

By the way, I said earlier that the FW OS might run under the hypervisor and it just asks the hypervisor access to the hardware through key/auth/other alg. If that's the case, since we got firmware dumps, couldn't that algorithm be retreive by reverse engineering the assembly from the firmware and simply reproduce whatever it does to get the hypervisor disabled? It wouldn't be that hard as far as I can tell.. I mean, yes, if there's some complex algorithm involved, it might be hard to RE, but it would be much easier to just copy the raw binary of the firmware into an ELF and simply call the function pointers directly and let the code be run without even having the need to RE that ASM into C...

What are your thoughts about this ? Should I open a new thread about this to avoid off-topic-ing ? in which case, where should I open it (I can't access the dev section yet).

Thanks,
KaKaRoTo

[mickyparu]

It does not seem to be compatible with PAL

[hellotonothing]

i tested on a pal ps3 and it really doesnt work.. any tips ?

[CJPC]

The HV is "above" all LV2 stuff (PS3 OS, OtherOS etc), and its just a matter of how much access each mode has, PS3 OS Kernel has more access than OS User, which has more access than OtherOS.

And it does always run, even to access the BD drive, it is done through the Hypervisor, as is accessing the HDD, network, everything!

[kakarotoks]

Humm.. ok cool!, thanks for letting me know about that. Now I guess the challenge would be to fool the HV into giving us more right than we deserve from OtherOS.

I'm also guessing that the HV is run from the bootloader, which makes it go into the specific security mode when you boot depending if you boot OtherOS or the XMB.. and I'm also guessing you can spawn a process with a lower security (XMB has more access than a game or the BD-J for example), but not the opposite obviously...

Again just throwing some ideas, what about disabling the HV completely instead of trying to get throught it... I see two possibilities (again, correct me if I'm wrong) :

1 - the HV is in the bootloader or is run by the bootloader prior to running any OS...
2 - the HV is a hardware chip that monitors everything somehow (less likely).

For the first possibility, we could flash the bootloader and implement a non-HV bootloader to get our OS running without the HV behind it. I know that flashing the bootloader can be a risky process, but it might be the solution.. Also, if the flashing is done by an infectus/other chip, it might not be as risky as a software flash (which itself would probably not be doable at this time).

Second possibility, could be disabled by a hardware mod.

Anyways, I joined #ps3news@irc.efnet, maybe we can talk about this in IRC instead, as I feel the forums are not suited for me throwing random ideas while knowing so little about the system itself.

An interactive chat could give me more answers and I could come up with better (less stupid/non-realistic) solutions. Whenever I'm available and see you on IRC, I'll say hi, in the meantime, I'll be idling there.

p.s.: I know that probably everything I say was already thought of by someone else from your team. I'm not trying to sound like "I'm the one who can give you the answer", I know there are a lot of people out there (you guys) who are way smarter than me, I'm just trying to brainstorm about this, simply because I think it's fun.

Thanks for reading,
KaKaRoTo

[PS3 News]

Originally Posted by kakarotoks Anyways, I joined #ps3news@irc.efnet, maybe we can talk about this in IRC instead, as I feel the forums are not suited for me throwing random ideas while knowing so little about the system itself.

We saw you in there tonight, but we have been busy with some other (non-Dev) stuff so weren't able to chat... perhaps we can shoot for tomorrow, or CJPC anyway, to PM ya there.

[RexVF5]

It works with 60GB PAL without any problems.

[mickyparu]

I have a 60GB PAL and the screen is black and white.