PS3 hacked by famous hacker

[joeorc]

Netyaroze said:
No its in no way useless. If he achieved what he claimed he opened the system. if you look at his blog and later in twitter the guy who critizised him and the people from ps3news believe that he probably achieved something. if he is correct then he found a way to crack the PS3

It maybe bad for Sony he may be wrong but if you read all the sources everybody take it as granted that he cracked the PS3.

I dont now much about this stuff but I am smart enough to recognize how the people which know more about this stuff react.

And they definetly think he achieved something even the people which joerc quoted said later that he probably found something.

The Hack could be useless but he is already known as one big hacker this guy seems to be a wunderkind. Or he had just luck.

We will see in the next weeks how it turns out I have the feeling he did it. If this exploit will be useful for the standard consumer is not sure.

I think he will publish this stuff sooner or later he has not sold his knowledge from the Iphone he gave it for free.

The guy which doubted him in the beginnig and later said on twitter that he talked with geohot and he had to admit that it seems like he cracked the PS3 is mateulh this guy cracked the PSP.

http://twitter.com/Mathieulh/status/8097806925

Everybody who is interested in it should read this thread and then decide for yourself:


http://www.ps3news.com/forums/ps3-hacks/playstation-3-hacked-george-hotz-hello-hypervisor-im-geohot-109519.html

if he indeed crack something the big problem is not the crack it's dumping the data inside that vault  that is just part of the problem. your trying to gain access to part of the system that is designed with the ability that outside code cannot Access data inside that vault an if it tries to do so it is flushed. the SPE restarts.

its:

What IBM an other chip maker's like Intel call

meshed era redundancy technology

not only is this self healing, IE: designed so the system is not to go down, but also add's to its security

Example:

One of the most important aspects of system security is how keys are managed. Keys are the linchpin for system security and data protection.  Applications use them to encrypt data in system memory, to decrypt movies, or to establish a secure communication channel.  If the keys can be easily exposed, the entire security scheme falls apart.

Despite their critical role, keys are usually stored in plain text form in storage.  Ideally, instead of in this naked state, the keys will be sealed in an envelope (in other words, encrypted) when in storage, and only unsealed when given to an application that has been authenticated.  However, this implies that another key is used for the sealing and unsealing (in other words, for encrypting and decrypting the first key);  how is this key stored?  Eventually, there must be a key that is not encrypted, and because this is the key that is at the root of all unsealings, we will refer to it as the root key.

Because of the root key's importance in keeping all other keys hidden, it must be robustly protected.  The Cell BE processor accomplishes this with its Hardware Root of Secrecy.  The root key is embedded in the hardware, and you cannot access it with software means; only a hardware decryption facility has access to it.  This makes it much more difficult for software to be somehow manipulated so that the root key is exposed, and of course, the hardware functionality cannot be changed so that the key is exposed.

 

 

 

THIS IS VERY IMPORTANT READ ON!

Furthermore, the activation of the hardware decryption using this root key is tightly integrated with the SPE isolation mode.  When an SPE enters isolation mode, the hardware decryption facility is kick-started to fetch the encrypted data into the isolated SPE and decrypt the data using the hardware root key. The decrypted data is placed within the protected Local Store and is available for an isolated SPE application to use.  In fact, the decryption based on the root key can only happen within an isolated SPE and not outside of it;  no access to the root key is available, by hardware or software means, from a non-isolated SPE or the PPE.

 

1) 

First, this implies that a system designer can force all data decryptions by the root key to happen within the protected environment of the Secure Processing Vault;  the keys unsealed by the root key will always be placed (at least initially) in the Vault only.  Second, only applications that have successfully passed the Runtime Secure Boot authentication are given access to the keys unsealed by the root key.  Any software that might have been adversely modified will not be given access to the unsealed keys.  Because the foundation of this control is grounded in both the Runtime Secure Boot and Hardware Root of Secrecy features, the process is more resistant to manipulation than with a pure software-controlled access mechanism.

2)

Another advantage of this feature answers the question, what prevents an adversary from taking an application intended to run within the Vault and executing it outside of the Vault?  The answer is to encrypt a portion of the application code using the hardware root key. Because the code is encrypted, it cannot be captured and directly executed on a regular, non-isolated SPE. The code needs to be decrypted, and therefore has to execute within the Vault where it can be decrypted by the root key.  This reassures the application writer that a particular application will only execute within a Secure Processing Vault.

 

IF there is a way for EXPLOIT this is the best way, but there is a big problem !

read on!

The Secure Processing Vault is best exploited by the Encrypt-in, Encrypt-out usage model where the incoming data is decrypted, an operation is done on the data, and the data is re-encrypted before it is placed outside of the Vault. In this model, the data is in its vulnerable, plain text form only within the Secure Processing Vault;  the only code that has access to this plain text data is authenticated through the Runtime Secure Boot;  and the keys used for decryption and encryption are hidden from the system using the Hardware Root of Secrecy.  With this usage model of the Vault, existing system functions such as file operations and network operations can be used as is without sacrificing on security.  Because the data is already encrypted by the time it is accessed as a payload to these operations, even if these system operations are somehow compromised, the secrecy and authenticity of the data can be ensured.

 

This part is very important!

please read closely.

These system functions that are outside of the Vault are treated as part of the untrusted environment, and traditional cryptographic-based methods are used for the Vaulted application to securely communicate to itself at a later time (for storage functions), to a server on the network (for network functions), or to another device in the system (for I/O functions).  In addition to the usual use of a public and private key pair (see Resources) and a certificate revocation list (a list of identities that have been revoked and should not be trusted), the secure, authenticated communication is achieved by the three core security features and also an on-chip hardware random number generator.  

For example, the Vault feature can ensure that the process of authenticating its communication partner is not manipulated by an adversary. The runtime secure boot can protect the certificate revocation list (think of this as the list of bad guys) from modification (a particular bad guy might be removed from the list, for example).

 

One of the most largest problem's faced!

 The hardware root of secrecy can ensure that the private key is not exposed by an attacker. (If the private key is obtained, all communication addressed to the private key owner will be exposed to the attacker).   The hardware random number generator protects against replay attacks (see Resources) by marking the current communication with a time stamp.  A replay attack is where an adversary takes an old communication message and sends it again through the unsecured communication channel.  Because the authentication protocol will verify that the message is authentic, a robust time stamping feature is the only way for the communication partners to realize that there is a man-in-the-middle attack happening.

 

http://www.ibm.com/developerworks/power/library/pa-cellsecurity/

 

once again I will wait and see exactly what this or if ever Hack was able to attain. IF he has indeed done it my hat's off to the man good show.

but what your able to do or even ever be able to do with the hack is another story all together