i noticed in a file someone posted in a cex-dex thread (and then had it quickly removed) that it mentioned the use of Matsumoto's TT800 Pseudorandom number generator.
so i was thinking just where is this piece of software that sony uses to generate keys?
is it in the SDK if so i couldnt mention much about it let alone legaly post it on any site.
but no its not in there so where is this number generator that creates keys that i'm sure sony wont want us getting our hands on hidden?
also its free & legal to use & free & legal to download
so what does this mean?
well not much we can generate keys with it but finding the right key is a one in a million chance in other words it is like looking for a neadle in a hay stack in a feild full of hay stacks next to a feild full of hay stacks etc.
so this is all pointless right?
well yes and no.
if one person generates keys and then try's the keys to see if one works then repeats this over and over again then all he will get is older the chances of one person finding it at random is next to impossible.
but what if every user on every site joins in and starts checking ..... well the odds get better.
now this software isnt easy for the adverage joe to use.
it will work on linux and mac by itself on windows you need perl found here:- http://www.perl.org/get.html
but even when you have a linux / mac / windows with perl installed it still isnt easy for the adverage joe to use so having everyone taking part in this wont work
so we need a clever user to create a GUI so its really simple to use.
and away to try the keys the simplist user frendly way to insure a key is try'd correctly.
now i know admins / moderators & devs will say this is all pointless but why not use this thread to send anyone who's asking :-
where is the next cfw/mfw/hen.
asking if a new thread will lead to a new cfw/mfw/hen.
saying a new thread / news article is pointless as it wont give us cfw/mfw/hen.
and devs ppl just pestering you guy's / gals with pointless questions about your work (or other developers not your own)
just send them here
thread rules:-
no attacking other members.
no name calling
no trolling
moderators have final say here. dont like it p/m them dont create drama here!!
Last edited by baileyscream; 04-24-2012 at 09:27 AM.
This is cool and all. But it would be much easier (and way more possible) and take worlds less time if we just broke the chain of trust. I mean, we already have a method apparently. The meta exploit can be used to decrypt the bootldr (according to Mathieulh, im not sure how accurate that is though he could have just been giving false infos), it's just that no one knows how to do so (or is willing to share how). And once bootldr is decrypted, it really would be game over for Sony, at least for already hackable ps3's.
What this relies on is someone or some group organizing all the software blah blah blah, then you would have to have someway of running the newly encrypted software on the a firmware with newer keys, which right now is not possible. I think KaKaRoToS has a method but he never released it. And even after all of that it would take forever to test executables because you would have to run them yourself every time a new key is generated.
thats why i said this need a user friendly GUI and a simple way to test the keys.
so it ends up being really easy / quick to use.
and no math uses other ppl's ideas / exploits then try's to get others to work it out for him by giving "hints" and saying he can do it. but as it was proven with kakaroto math didnt know anything.
kakaroto has a unique way to enable homebrew on current ps3's that he is working hard on getting to work but his HEN isnt about the keys his is an exploit.
ppl pestering devs and de-railing threads out of being bored / frustration / etc is a bigger waste of time. i'm just suggesting a way of getting ppl together to try this scene experiment.
thats why i said this need a user friendly GUI and a simple way to test the keys.
so it ends up being really easy / quick to use.
and no math uses other ppl's ideas / exploits then try's to get others to work it out for him by giving "hints" and saying he can do it. but as it was proven with kakaroto math didnt know anything.
kakaroto has a unique way to enable homebrew on current ps3's that he is working hard on getting to work but his HEN isnt about the keys his is an exploit.
ppl pestering devs and de-railing threads out of being bored / frustration / etc is a bigger waste of time. i'm just suggesting a way of getting ppl together to try this scene experiment.
I don't think you understand what I'm saying. How will you run executables on a PS3 with newer revision keys? You can not just put it on a flash drive and hit execute. That's what I was talking about with KaKaRoToS and his method of installing pkgs.
Since we would have to test on PS3's that are not homebrew-able, there is no way to essentially "network" with the PS3 to mass-test many differently encrypted executables in a sort of "batch" mode. How do you plan on making a GUI for something when it isn't even possible to do with a "manual" method (besides the method KaKaRoToS has)? Even if we had access to KaKaRoToS method, we would still have to go through each newly encrypted executable one by one, proving to be horribly inefficient and essentially a waste of time because of the sheer number of possibilities of keys there could be.
I'm not sure if you are talking about me "pestering" people or de-railing threads, I'm just being realistic. From what I understand no one has ever successfully brute-forced ECDSA and I really don't see that changing at all, esspecially with unusual method of running code on the PS3 making automation essentially impossible.
Not meaning to derail here, but to add on to what afiser was saying, by the time you brute-forced the ECDSA algorithm, you could've just brute-forced other major keys, like bootldr, which has been proven to be able to brute-force.
Don't Feed The Trolls Past Midnight
STOP!!! Before you post that question, 98% of your answers are --->Here<---
Not meaning to derail here, but to add on to what afiser was saying, by the time you brute-forced the ECDSA algorithm, you could've just brute-forced other major keys, like bootldr, which has been proven to be able to brute-force.
Very true, with a decryption type of brute force, you could use a PC (or many PC's) to continuously run decryption keys on bootldr, there-go getting the decryption keys of all levels under bootldr and being able to decrypt all parts of the firmware. Once that is complete, I believe we can encrypt the firmware with 3.55 keys and use it just as we would any other firmware. But i'm sure patches would have to be done, etc. But this is definately the only viable brute force option. With current computers, it would take years to do though.
Interesting. I thought supercomputer will take less time while bruteforcing it (depends on how many characters and numbers are there). I saw a website that reveal the different type of computers and how long its takes to find the right key before breaking into the system.
It would probably take less time with a supercomputer, but lets be realistic. No one with a supercomputer would help this type of effort.
I think the presuppostion is that if it takes 1 computer 1000 years to brute force a key (say for simplicity there is an eboot, a computer, a program to run unself iterates through all possible combinations of values for an app key, checks each unself attempt....) but instead use 1000 computers (split the possible values into 1000 batches, 1 batch per computer) and it would take 1 year (oversimplification), 2000 computers half a year,...200,000 computers 1 sec (<= WTF, ok, that's not linear ).
Putting aside the crude numbers, is this presuppostion correct for batch processing a brute force attempt (or pooling cpu cycles)?
The app key is just for example (not saying it's the best key to get).
As I mentioned previously, there are projects that borrow idle computer time from volunteers (online). Surely that could be modelled.
Yes, your math is fundamentally right, but the problem is that the number of possibilities is so huge that even a distributed computing project wouldn't be of much help.
Assuming that the bootldr key (public) is 320 bits long, it has 2^320 = 2.136*10^96 possible keys. Assuming that you can gather a network of a million computers, each with a 4 GHz CPU, hence theoretically performing 4*10^9 operations per second (let's assume that each operation is a whole key guess), you would take 2.136*10^96/(4*10^9)*10^6 = 5.34*10^80 seconds, which is 6.1*10^75 days = 1.7*10^73 years. Note the ridiculosly optimistic math being used here.
It's abosutely impossible to brute force a key like this.
Yes, your math is fundamentally right, but the problem is that the number of possibilities is so huge that even a distributed computing project wouldn't be of much help.
Assuming that the bootldr key (public) is 320 bits long, it has 2^320 = 2.136*10^96 possible keys. Assuming that you can gather a network of a million computers, each with a 4 GHz CPU, hence theoretically performing 4*10^9 operations per second (let's assume that each operation is a whole key guess), you would take 2.136*10^96/(4*10^9)*10^6 = 5.34*10^80 seconds, which is 6.1*10^75 days = 1.7*10^73 years. Note the ridiculosly optimistic math being used here.
It's abosutely impossible to brute force a key like this.
Not to mention factoring in the correct riv, erk, and curve types
Reply With Quote
Originally Posted by baileyscream
