I had a few questions, and a thought regarding a tactic to gain access to the isolated SPE. Maybe the more knowledgeable devs can clarify if I'm just talking out of my a$$ here...
We know the Jailbreak allows for the running of unsigned code in game/user mode. But I have a few questions...
A) When the Jailbreak is activated upon system boot, is the code loaded during this, the runtime secure boot phase, or is it ran after the fact?
B) If the answer is yes to loading during RSB, would it be possible to execute a program to make brute force calls repeatedly to the isolated SPE to try to break the encryption in normal game mode, or would it need to be elevated to LV2 to execute code against the SPE?
C) Would that software be able to make repeated hits against the "door" of the isolated SPE, or would the system lock out the application upon the first knock?
D) Are we yet aware of exactly what encryption schema the SPE utilizes (SHA1, MD5, etc)?
The idea I'm getting at here is, now that we can run unsigned code, I'm wondering if there might be a way we can use a combination of cloud computing and brute force methods to determine the encryption keys, by having the application make validation requests to the isolated SPE. If we could have hundreds of PS3s with Jailbreaks attempting to brute force the isolated SPE by throwing hashes at it, I'm curious how long it may take before one of them got lucky and found the correct key against said SPE.
Again, if my understanding of how the PS3's security works in regards to running in isolation mode and encryption is incorrect, feel free to correct me.
Sounds like an OK idea, but brute forcing any real encryption would take forever, even with hundreds of PS3s, no?
Considering the military already does so, maybe not. However It would be alot easier to tell the proccesor to give us the password. Maybe by telling it to encrypt a code and using 1000 different codes and comparing them.
Hopefully if this turns out to be a feasible idea, you wouldn't need to send your PS3s to anyone, Ion. You would be able to run it on your own, similar to Folding@Home.
yes but I've also forgotten how it would be hard to brute-force the CELL, I believe checks were in order to block brute-force and low level guessing techniques to stop such behavior, however I don't remember where I've read that, it was a long time ago ;].
To be honest on my new firmware (current), I removed Life With Playstation and proxy'd Folding@Home onto the PS3, not sure but the pkg ID must still be valid on all ps3s. I don't intend to update now unless I were to get another ps3 to play online with only.
What about utilizing both the encrypted and decrypted leaked versions of EBOOT.BINs for some of the games recently released on the newsgroups? Is there any way they can be used to brute force the key using similar concepts (the cloud computing I mean) on a PC? My grasp of encryption may be faulty here, but would it be possible to create a utility that would attempt to brute force the encrypted version, until the MD5 hash of the encrypted version matches that of the decrypted one, thus giving us the key?
I wish it was that simple. Sony only uses MD5 to hash & verify stuff. If pkgs had an MD5 key, they'd have been cracked years ago.
as I mentioned previously I believe CELL uses RSA, bit unknown, but I could be 100% wrong. brute-forcing a key that might be 10000 characters might take 100 years even on 100 PS3's, however it's probably definitely not that long ;]. not to mention it would take a few minutes to verify a pkg with that kind of encryption and what-not.
I don't think tripellex was suggesting that Sony used an MD5 hash
I think he meant that as we now have access to encrypted and unencrypted versions of the same file, you could generate an MD5 hash of the unencrypted file, then repeatedly try and decrypt the encrypted file using random hashes, and then generate an MD5 hash on those attempted decryptions until it matches the MD5 hash you got from the original unencrypted file?
The problem with this approach is that we'd have to know the encryption type used. We should also know the size of the key, to avoid using lots of time, and electrical power, on trying keys that's out of range (too short or too long).