BeOS was awesome back in the day. My desktop OS used to be BeOS 4.5 for a while. Porting Haiku could be fun indeed.
Technological discussion on PS3 security and crack.*
- Thread starter senas8
- Start date
BeOS was awesome back in the day. My desktop OS used to be BeOS 4.5 for a while. Porting Haiku could be fun indeed.
If noone has done an XBMC before, why should they now?
I was asking myself the same question the other day (while reading the piracy ethics [<-- oxymoron] thread).
The people who defended PS3 hack complained about the lack of RSX access. They even sink in the time, as we speak, to hack the HV so that they have "complete" access to the hardware.
Now assuming George Hotz's hack finally opens up PS3 for them (except for the GameOS part). I reckon the same people will now rally among themselves to deliver a RSX-enabled OS, and whatever apps that sit on top.
The people who defended PS3 hack complained about the lack of RSX access. They even sink in the time, as we speak, to hack the HV so that they have "complete" access to the hardware.
Now assuming George Hotz's hack finally opens up PS3 for them (except for the GameOS part). I reckon the same people will now rally among themselves to deliver a RSX-enabled OS, and whatever apps that sit on top.
There's a bunch of people scurrying around trying to replicate the hack that have almost zero electronics or programming knowledge; all they're contributing is a dozen extra PS3 sales next NPD period as they replace the ones they just busted. Geohot can write basic kernel plugins obviously, but he admitted that an RSX driver was a bit much for him. I don't know xorloser's programming experience, but I suspect he's in the same boat as geohot.
The people that can write RSX drivers, the nouveau team, probably don't have any PS3s. Porting the generic 7800 driver to work with the hypervisor (assuming the right calls are found) and RSX probably won't be too horrible though, and it seems there's enough functionality for what most people want.
Of course, there's already Cell-accelerated 2D and 3D libraries available, anyone try compiling XBMC with those?
Moreover, I doubt that even the programmers who are actually interested in PS3 Linux + RSX development are going to modify their PS3 hardware 'en masse', when it is unlikely there will ever be enough users who will benefit and contribute? It's going to be something incredibly niche. At best, perhaps someone will be able to learn enough about the system to find a software loophole, and then perhaps we'll see RSX unlocked in Linux. But at this stage, I'm thinking it'll likely all be too late to matter even just for PS3 Linux.
There are enough people with PS3s and the knowhow to make a basic RSX driver out there though! Make no mistake about that. It's comparatively easy too, with the PC equivalent of the hardware having been reverse engineered years ago iirc.
There are enough people with PS3s and the knowhow to make a basic RSX driver out there though! Make no mistake about that. It's comparatively easy too, with the PC equivalent of the hardware having been reverse engineered years ago iirc.
Whoever was/is championing the virtue of homebrew on PS3 (when George Hotz' exploit went online) would have to coordinate or do the work themselves.
I think archie4oz already hinted at the difficulty of writing PS3 drivers. Not to mention there may not be an exposed OtherOS interfaces on PS3 Slim.
The real pirates are all after GameOS.
If anyone's working on this, it would be mostly for passion. I hesitate to apply economics consideration on these people (yes, probably a very small group).
I think archie4oz already hinted at the difficulty of writing PS3 drivers. Not to mention there may not be an exposed OtherOS interfaces on PS3 Slim.
The real pirates are all after GameOS.
If anyone's working on this, it would be mostly for passion. I hesitate to apply economics consideration on these people (yes, probably a very small group).
I must say that I am a bit confused by all this "RSX access is possible but it's too hard blabla..."
Before firmware 2.10 there was some kind of 'hole' in the RSX access, and a demo showing rudimentary 3d-accelerated graphics (rotating textured cube) was created (see here: http://forums.ps2dev.org/viewtopic.php?t=9429)
What is it with that pre-2.10 hole that made it so much easier to get RSX-3D stuff going compared to this new hack?
If RSX access is indeed possibel to do now, what is preventing the code from that demo from running?
Before firmware 2.10 there was some kind of 'hole' in the RSX access, and a demo showing rudimentary 3d-accelerated graphics (rotating textured cube) was created (see here: http://forums.ps2dev.org/viewtopic.php?t=9429)
What is it with that pre-2.10 hole that made it so much easier to get RSX-3D stuff going compared to this new hack?
If RSX access is indeed possibel to do now, what is preventing the code from that demo from running?
IIRC RSX access on FW < 2.10 was not complete, you could access some RSX registers but not all.
In theory you could have full RSX access with this exploit, but most of the people working on that seem to have focused on reverse engineering of the hypervisor.
Assuming a software exploit is found to enable unrestricted access to the hardware you could try to port the nouveau driver. But I don't see anybody working on RSX anymore. Nothing prevented people from keeping a system stuck at < 2.10 yet not real driver ever came out of it. I guess there was not enough interest.
This could have been exciting in 2007 but so late in the game I don't think people with the know-how care that much anymore.
In theory you could have full RSX access with this exploit, but most of the people working on that seem to have focused on reverse engineering of the hypervisor.
Assuming a software exploit is found to enable unrestricted access to the hardware you could try to port the nouveau driver. But I don't see anybody working on RSX anymore. Nothing prevented people from keeping a system stuck at < 2.10 yet not real driver ever came out of it. I guess there was not enough interest.
This could have been exciting in 2007 but so late in the game I don't think people with the know-how care that much anymore.
What are 'pkgs' and 'selfs'?
Encrypted archives and executables.
pkgs are the games/apps bundles you download from the Playstation Store that are unpacked during installation. selfs are signed/encrypted ELF files.
I read his post but still doesn't make sense. You can load the metldr into an SPU and kickstart isolation mode. So what? Since he claims to have complete control of the hardware you don't need any of that for homebrew. Just write your code, compile it and launch it. What would need the secure loader for?
Unless what he suggests is:
- A) loading GameOS and ask the metldr to decrypt it. Unfortunately GameOS won't run in OtherOS's presence as you cannot load two LPARs at the same time on the PS3.
- B) Using the metldr to decrypt pkgs/selfs and then dump them so they can be ran on another patched PS3. IOW, piracy which he was not supposed to endorse or facilitate. Talk about being a hypocrite.
Also this...
geohot said:
It seems he insists on ignoring the role the root of secrecy and the isolated SPU play in the PS3 security and thinks treating it like a black box from his compromised HV is enough. And he is wrong on the PSP part.
Ah, right. What's an ELF?
So pkgs would lead to homebrew XMB apps in theory. I can see that generating interest in the homebrew community. Hardware access would be complete. What defenses are there for preventing a download title getting ripped as a pkg?Ah, right. What's an ELF?
ELF is the executable file format used by most UNIX systems and most consoles as well.
If you can run unsigned code with full privileges then you don't need to decrypt anything. That could be done from within OtherOS.
Now if you want to run unsigned code from the XMB that's a different story. If Sony did their job properly only a secure loader is allowed to launch encrypted files. If you found a way to decrypt the XMB and patch it so it loads unsigned code you could, in theory, use it to launch homebrew and decrypted/dumped programs.
Again if Sony did their homework the plaintext version of the keys used to decrypt games never leaves the LS of the isolated SPU which only runs trusted code. I guess we'll have to wait.
In the last days there was a news piece doing the rounds. It was about a security researcher cracking a TPM chip. He cracked open the chip, snooped the intra-IC bus and apparently retrieved some keys. That TPM chip is used in the 360.
Sorry, Deutsch: heise.
Considering the market for console piracy, what's stopping the usual suspects (professional chippers, etc.) from trying this on a PS3?
I assume the PS3 cell is quite bigger and complex than a TPM-only chip so it becomes really a needle in a haystack maze. And there is a higher know-how hurdle than decompiling some bytes, heh. OTOH the rewards are tempting ($millions even?).
Does the PS3 cell have a plan (fw upgrades) against root-key comprise? Or does it stop at the isolated SPU level? I havent read the IBM papers referenced in this thread.
Sorry, Deutsch: heise.
- It took him 6 months.
- Quite a few chips were destroyed.
- Estimated cost: $200K
- It's an old TPM chip. Newer infineon TPM chips have better anti-intrusion measures and the intra-IC bus is encrypted.
- Infineon knew about this attack vector and had done it themselves.
Considering the market for console piracy, what's stopping the usual suspects (professional chippers, etc.) from trying this on a PS3?
I assume the PS3 cell is quite bigger and complex than a TPM-only chip so it becomes really a needle in a haystack maze. And there is a higher know-how hurdle than decompiling some bytes, heh. OTOH the rewards are tempting ($millions even?).
Does the PS3 cell have a plan (fw upgrades) against root-key comprise? Or does it stop at the isolated SPU level? I havent read the IBM papers referenced in this thread.
I'm not sure even that's possible. How are they supposed to get a patched PS3 that'll run unsigned code under GameOS? They can tweak the firmware, but they can't sign it to install it on a retail PS3, they can't run the hypervisor hack under GameOS, and I'm reasonably sure even a completely decrypted game won't run under OtherOS without the GameOS support libraries.
Unless it's just piracy for people with Debug units. Granted, I've heard of some groups trying to turn retail PS3s into debug units, but I'm pretty sure that's a dead end.
You would have to add functionality to the HV that allowed you to load an instance of GameOS (I don't know if that's even possible) which you would later patch in memory to enable execution of unsigned code. But this is speculation, I don't know if it's technically possible to do that and it makes the assumption that there are no runtime checks in GameOS (I'm sure there are).
If you could dump selfs that would allow you to study the GameOS APIs and learn how to program for it. Is it doable? Sure. Is it worth it? Maybe for some people with nothing better to do.
That doesn't work, Sony did a good job there. Sadly it seems what most people want out of this is free games. I haven't seen any movement in the ps2dev forums or people excited about how they're going to port $KILLER_APP now that all the hardware is available.
I just checked geohot's twitter and he claims that the PS3 is 100% hacked. I respectfully disagree.
Sad thing is not all the hardware is available yet. Still waiting on a hypervisor dump (there's one getting pushed out for scene release next week) before anybody can dig into it and find RSX hypervisor calls. There's no point in porting anything that requires the Geohot hack IMO. I'm giving the ps2dev forums the benefit of the doubt since they're extremely concerned with clean-room engineering (I suspect there's a few pros that could get in trouble if they're not careful).
I'm still of the opinion that XBMC is doable currently without too much extra effort from the involved groups. I spent the afternoon upgrading my YDL install to 6.2; next step is the Cell-accelerated Mesa OpenGL libraries. If that doesn't work, the Cell-accelerated SDL libraries (assuming XBMC still runs on SDL) are next.
Just don't expect 1080p h.264.
On a pre 2.10 system you can get 70% performance out of the RSX (everything but TILE and ZCOMP setup) yet I've never seen anything useful coming out of it.
That sounds a lot like waiting for others to do the work. What do you think people will do with the extra 30% performance?
All of this has been overblown since day one with all the media coverage and whatnot.
Similar threads
- Locked