08-25-2010 #1tripellex Guest
A question for the more knowledgeable devs
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.
08-25-2010 #2ionbladez Guest
I'd probably donate the 2 working ps3s I have, for this fact. That being said as long as I get them back LOL.
Anyways, I believe there is a messenger involved before this "knock" occurs.
can't exactly put my finger on it but knowing IBM, it's probably some RSA bs
however I'm not sure, they do all kinds of wicked things with their hardware. who knows?
08-25-2010 #3tripellex Guest
08-25-2010 #4Mafo Guest
Sounds like an OK idea, but brute forcing any real encryption would take forever, even with hundreds of PS3s, no?
08-25-2010 #5whinis Guest
08-25-2010 #6ionbladez Guest
To be honest on my new firmware (current), I removed Life With Playstation and proxy'd [email protected] 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.
08-25-2010 #7tripellex Guest
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?
08-25-2010 #8ionbladez Guest
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.
08-25-2010 #9XiLE Guest
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?
08-25-2010 #10DanielSV Guest
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).