Technological discussion on PS3 security and crack.*

[manux]

Codecs are there only to decode/uncompress video that has been compressed by those codecs. As well it probably could handle
SB

And that is the tricky part when it comes to ps3 and h264 avc(internet rips) support. PS3 on linux had barely enough grunt to decode 720p mkv's when using special magic codes. OpenSource community would need to optimize codecs to use spu's to make 720 and 1080p videos work flawlessly. And at least before no one was willing to do that as it is a lot of work for no money and very little gain. Intel atom + nvidia ion boxes changed the game for mediacenters.

Only thing I can see making xmbc happen now is that if someone figures out a way to use sonys codecs to decode videos. handle the container part on custom code on cell and use sony codecs for raw data.

Access to RSX has pretty much nothing to do with how good or bad ps3 based mediacenters can be. It's all in the cell optimized code...

Much like Windows Linux needs access to the GPU in order to accelerate even 2D video. Try playing back full motion uncompressed video on Windows XP with the standard video driver (or just turn off GPU acceleration in display properties) which has access to only the most basic video card features. It doesn't matter how powerful your CPU is or what video codecs you have installed, it just isn't going to happen

Frankly this is untrue for PS3. Go check spumedialib. It has plenty fast spu optimized functions for scaling, blitting and so on to make the otheros linux display driver blitting/flipping speed irrelevant(even for 1080p). This SPUMedialib was used for example in mediaplayer to shift bottleneck of video playback to decoding process which no one was willing to optimize for spu's. There were people who tried but no one finished. The end result was that with highly optimized codes and dualthreaded codec some 720p videos played back ok and some didn't... The main cpu in cell is Really weak for this video decoding task.

 

[manux]

SPU medialib http://wiki.ps2dev.org/ps3:spu-medialib

example implementation of yuvscaler using yuv420 source currently does 150FPS scaling @1080p
example implementation of yuvscaler + yuv2rgb converting using yuv420 source and two spu’s currently does 150FPS scaling @ 1080p

PS3 cell is plenty fast in otheros to do video decoding, required processing and blitting... It's just the little matter of writing spu optimized parallelized codecs which is not so easy. RSX access will not make porting xmbc any easier than it was before.

 

[betan]

Codecs are there only to decode/uncompress video that has been compressed by those codecs. As well as enable more advanced video processing. But can't do much by itself without access to the video display unit.

They do have access.

Perhaps Sony included 2D video acceleration in their OtherOS driver for RSX but I find that doubtful considering complaints about how slow RSX video feed is without access to the GPU.

It has multiple reasons the most important being unoptimized libs for PPE. Even the fake framebuffer access was more than fast enough.

Much like Windows Linux needs access to the GPU in order to accelerate even 2D video. Try playing back full motion uncompressed video on Windows XP with the standard video driver (or just turn off GPU acceleration in display properties) which has access to only the most basic video card features. It doesn't matter how powerful your CPU is or what video codecs you have installed, it just isn't going to happen.

A cursory search on Linux reveals roughly the same requirement. At least some level of hardware access to the video card in order to playback video of any kind no matter how powerful your CPU.

I'm not sure why you insist on this. I have been using linux desktop for more than a decade for the most part with little GPU hw support, the only thing typical linux media playback apps (mplayer, vlc, gstreamer front ends ) and libs (ala ffmpeg) need from GPU is hw scaling. If you don't scale they work same.

If your CPU is powerful enough and with a decent parallelised software scaling, you don't need help from GPU. Of course it costs more memory.

For XMBC though, the only reason you don't have it (yet?) is optimisation. The same reason it wasn't available when Linux was officially supported on PS3.

 

[Silent_Buddha]

Frankly this is untrue for PS3. Go check spumedialib. It has plenty fast spu optimized functions for scaling, blitting and so on to make the otheros linux display driver blitting/flipping speed irrelevant(even for 1080p). This SPUMedialib was used for example in mediaplayer to shift bottleneck of video playback to decoding process which no one was willing to optimize for spu's. There were people who tried but no one finished. The end result was that with highly optimized codes and dualthreaded codec some 720p videos played back ok and some didn't... The main cpu in cell is Really weak for this video decoding task.

Ah, gotcha, so they did provide for at least some 2D video acceleration from RSX. SPUMediaLib was the part I was unaware of. Now I have a jumping off point to go look at things more closely... Shame it seems most initial excitement and developement died off about 3 years ago from my first cursory glance.

Shame as if they had been able to get XBMC working back then, I may or may not have made my file server also serve as an HTPC and instead gotten a PS3.

Regards,
SB

 

[patsu]

Ah, gotcha, so they did provide for at least some 2D video acceleration from RSX.

On the PS3 Linux side ? I don't think so. RSX is off limit. ^_^

I remember the so-called RSX-accelerated driver was a temporary FIFO queue hack. It was shut down in firmware 2.10 or so. Only lasted for a short while.

It's all driven by Cell. They did (re)use the video memory for VM though:
https://patchwork.kernel.org/patch/9858/

Add ps3vram-ng driver, which exposes unused video RAM on the PS3 as a block
device suitable for storage or swap. Fast data transfer is achieved
using a local cache in system RAM and DMA transfers via the GPU.

As long as the devs can hide the DMA latency, the SPUs should be able to speed through highly parallelizable code + data in the Local Store.

 

[Scott_Arm]

Sony fucked up royally. Hackers have found a way to unban their consoles and potentially ban other people's legit consoles. I'm not posting a source, because I don't want to post a link where someone might potentially post the information on how to do this.

 

[AlphaWolf]

Sony fucked up royally. Hackers have found a way to unban their consoles and potentially ban other people's legit consoles. I'm not posting a source, because I don't want to post a link where someone might potentially post the information on how to do this.

ya this is going to get ugly

 

[I.S.T.]

Sony fucked up royally. Hackers have found a way to unban their consoles and potentially ban other people's legit consoles. I'm not posting a source, because I don't want to post a link where someone might potentially post the information on how to do this.

Oh goddammit.

 

[BRiT]

It's going to get extremely ugly if they find a way of harvesting console id's through multiplayer sessions.

 

[corduroygt]

If JTAG 360's can't hack XBL I don't see how jailbroken PS3's can hack PSN. Or similarly if WOW isn't hacked, and that's on a PC, I don't see how it's possible on PSN either.

 

[BRiT]

You simply don't have a full picture of things which is why you can't imagine the reality of the situation.

Part of the login packets to PSN is the Console ID. The crackers merely spoof a different Console ID in the packets that go out using the typical PSN Proxy setup. Sony then determines the console isn't running legit firmware and then tosses that spoofed Console ID into the PSN BAN Hopper. The Console ID is also how the COD: Black Ops are done as using a different one allows previously banned users to play once more.

In the case of MS Xbox360 they seem to have a more stringent keyvault/console id/banning/multiple verification steps in their process to detect JTags that as of yet is not vulnerable to such simplistic change.

Short summary: Sony PS3 and PSN security seems to be way off the mark where as the MS Xbox360 and Live security seems to be closer to the mark.

 

[bomlat]

It is not so hard to solve.
Each console need a certificate,issued by the new sony key,with an individual public/private key-pair.

The new certificate canused to signature each on-line session.

That's it.

If the sony didn't implemented this,then they can do it easily,because this method part of the more than 10 year old ssl standard.

 

[patsu]

I saw a post which mentioned that Sony has a customer service tool to ban and unban users. There was a screenshot. If true, it probably requires a customer service exec's login id and password, which can be revoked. Should wait for the dust to settle to see what the real deal is.

 

[Gitaroo]

think I saw those on psx scene a couple days ago, they already confirmed it only works if you got someone else' clean console ID, however you will just get ban again when PSN detect cfw unless theres a stealth method to bypass the check. And you can't just simply randomly generate a console ID either to match a real console ID neither. Its the same thing happened on Xbox, some people actually sold their own console ID cuz they have no desire of going online; not really anything new.

 

[patsu]

Does the tool contact Sony servers to ban/unban a console ? Or swap the console ID of the local PS3 ?

 

[Gitaroo]

swap your PS3 ID I believe, it show the status of your console, the screen shot says "suspended" with a drop out option. You can't hack PSN, or Sony side (at least not yet XD). And I think someone mention there are 4 ID check, console ID, main circuit board ID, bd drive id and mac address. Sony probably have a white list of real ID the assign to each console so people can't just randomly generate one. I read a few more recent posts, the trick doesn't seems to work, banned console are still banned, even when they tried to replace their ID from a clean console (probably only replace the console ID but not the rest). One interesting thing is that console that haven't been banned has no effect when a person try to change his real ID to fake one (unless the person is lying). Maybe Sony is going by the black list first when you connect to PSN, so if anyone of the 4 ID match what they have on the black list your console will be blocked from PSN?

update: seems like someone replace a banned ID to a clean console and the clean console is able to go online still. (unless that person is lying, and also a very old post)

 

[bomlat]

It mean that the PSN have client side certificate to authenticate the console.

 

[makattack]

It is not so hard to solve.
Each console need a certificate,issued by the new sony key,with an individual public/private key-pair.
The new certificate canused to signature each on-line session.
That's it.
If the sony didn't implemented this,then they can do it easily,because this method part of the more than 10 year old ssl standard.

Edited to add: Just saw your most recent clarification (my point stands):
It mean that the PSN have client side certificate to authenticate the console.

How can you possibly think this is easy to implement? Do you know what it takes to implement and manage a client certificate for authentication and authorization type scheme? I'm not saying it can't be done, but *if* PS3/PSN security were based on client certificate authentication, you effectively wouldn't need a PSN password. Also, if you're PSN account is using a client certificate for authentication, you would have to install this certificate in all your devices that access PSN (PSP, PC, etc)

Now, if you're saying there's a console specific client certificate used just for *authorization* a console for access to PSN (and not user authentication, so it isn't associated with ones PSN account), you still have a massive key management issue. How do you re-key all consoles?

The nature of all the hacks on PSN after the root key was exposed shows that the PS3's PSN security model is much more straight-forward, and mostly relies on the concept of user accounts with secret key/hashed passwords for authentication, coupled with a SSL type network transport. There is definitely some part of their application protocol that allows the exchange of hardware / software information, but if the transport is insecure, this data will also be subject to man-in-the-middle type data insertion/manipulation attacks.

 

[bomlat]

How can you possibly think this is easy to implement? Do you know what it takes to implement and manage a client certificate for authentication and authorization type scheme? I'm not saying it can't be done, but *if* PS3/PSN security were based on client certificate authentication, you effectively wouldn't need a PSN password. Also, if you're PSN account is using a client certificate for authentication, you would have to install this certificate in all your devices that access PSN (PSP, PC, etc)

Now, if you're saying there's a console specific client certificate used just for *authorization* a console for access to PSN (and not user authentication, so it isn't associated with ones PSN account), you still have a massive key management issue. How do you re-key all consoles?

The nature of all the hacks on PSN after the root key was exposed shows that the PS3's PSN security model is much more straight-forward, and mostly relies on the concept of user accounts with secret key/hashed passwords for authentication, coupled with a SSL type network transport. There is definitely some part of their application protocol that allows the exchange of hardware / software information, but if the transport is insecure, this data will also be subject to man-in-the-middle type data insertion/manipulation attacks.

You mixing up several things.
The PSP have similar scheme: you can install keys from the PSP keyvault onto you computer

The network ID itself not enough for the proper authentication.
I'm sure about that either they have same signatured key +ID .

The PSN password different item:that identify the user,the client certificate the hardware (The verisign can issue to you client certificate )

The change easy again,when you log in to the PSN,it will issue to you a new key.


The SSL sensitive for the man-in-middle only if you can install your certificate onto the PS3 -and that requiring modification,and you have to be stupid enough to install it.

 

[AlphaWolf]

You mixing up several things.
The PSP have similar scheme: you can install keys from the PSP keyvault onto you computer

The network ID itself not enough for the proper authentication.
I'm sure about that either they have same signatured key +ID .

The PSN password different item:that identify the user,the client certificate the hardware (The verisign can issue to you client certificate )

The change easy again,when you log in to the PSN,it will issue to you a new key.


The SSL sensitive for the man-in-middle only if you can install your certificate onto the PS3 -and that requiring modification,and you have to be stupid enough to install it.

and how do you do all this when the system is already compromised? If you don't know which consoles are legitimate you are passing out keys to compromised systems.