178w ago - To follow-up on the
previous article where Sony PlayStation 3 hacker
KaKaRoToKS stated "A solution for 3.60+ will be available soon, so no worries - people just need to be patient" comes some more Tweets today on JailBreaking 3.73 PS3 Firmware.
Below are some of the recent announcement
Tweets from
KaKaRoToKS on JailBreaking PS3 3.73 Firmware, as follows:
- I will reply.. but I didn't read... yes, file managers and FTP should work fine.
- and I'm all for competition, no worries. I do this for fun, not for race or whatever. Also, 3.73 cfw is not possible
- i dont know yet about emulators... All in good time. There s no rush
- yes, that's the point, to run homebrew.. showtime should work fine. not tested yet.
- Nope, completely software based.. I won't say anything more than that for now to avoid them blocking it before release.
- The "kind of" meant I need to fix NPDRM algo for it to run. And no, this will not allow backup managers. And no, it's not a CFW
- 1 - I won't share it until it's ready to use (still a bit complicated + some missing components), 2 - don't update if you're on 3.55.
- Updated my ps3 to 3.73... oh and THEN I jailbroke it! (kind of)
Here is to hoping this is indeed the working solution PS3 scene users have been waiting for, as previously
KaKaRoToKS jumped the gun confirming the
PS3 Downgrade Success from 3.55 to 3.41 Firmware and then Tweeted "sad news.. downgrade worked, but not reliable, only works with one of Xtse's ps3s, but can't reproduce it.. I'm going to look for another way. nope, it only works on one machine, even if same model, it doesn't work on it. No idea what's different about it..."
Since then,
KaKaRoToKS has released a
PS3 Expedite Benchmark Tool and Engine Ports, an
Eskiss PS3 Homebrew Game and a
PlayStation Move Support update for the Eskiss PS3 homebrew game though.
Finally, from IRC on the PlayStation 3 Firmware 3.73 hacking developments:
[KaKaRoTo] heri, docpaul showtime would work fine
[sandungas] kakaroTo, this means new tcl patches for mfw and some changes to manage 3.73 ?
[KaKaRoTo] ddoo, and no I didn't fix the npdrm algo, that's what I'm missing (hence the "kind of") but I'm not
working on that, that's someone else's job
[middleman] gonna debut it at ccc kakaroto or before?
[KaKaRoTo] ddoo, and even if npdrm signing worked.. how do you install your pkg on an OFW 3.73 ?
[heri] so KaKaRoTo, once the NPDRM algo is fixed, a release will come?
[KaKaRoTo] heri, another missing bit, but once that's fixed, yes
[KaKaRoTo] but I'll probably be off country for the next 2 weeks
[KaKaRoTo] so all work will have to be paused
[heri] oh, fair enough. we can all wait 2 weeks hey
we have waited months anyways
[KaKaRoTo] ddoo, that might work.. you could also just install your pkg on 3.55 then upgrade
[KaKaRoTo] ddoo, upgrading doesn't delete any of your packages
[KaKaRoTo] ddoo, issue is, you're lost if you didn't do it before upgrading
[ddoo] but they fail because the npdrm algo is spoted by the checks in 3.56+
[KaKaRoTo] heri, also note, I "announced" it because I was excited to see it work as expected
[KaKaRoTo] doesn't mean it's ready for release
[KaKaRoTo] ddoo, exactly
[heri] yeh thats what we were saying just before you came
[KaKaRoTo] so you need : 1 - npdrm algo fixed, 2 - a way to install stuff
[heri] you only announce when you are confident it works
[KaKaRoTo] 1 has been done by someone else (don't know if he'll share it), and 2.. well, I just did it
[KaKaRoTo] heri, well, I was testing on 3.60 and it worked, but yes, I did upgrade to 3.73 to test that it still
works just to make sure I don't tweet any false hopes
[middleman] but you cant run what you installed until 1 is fixed correct?
[KaKaRoTo] middleman, exactly
[middleman] interesting
[docpaul] nice, thx KaKaRoTo
* KaKaRoTo needs to hide now if he wants to get any work done
[KaKaRoTo] ttyl
In summary,
KaKaRoToKS upcoming PS3 3.73 Firmware JailBreak will be able to install homebrew .PKG files but unfortunately PlayStation 3 backup managers will not work as they require lv1/lv2 patches that won't be included.
From ps3devwiki.com/index.php?title=KaKaRoTo_Kind_of_%C2%B4Jailbreak%C2%B4#Q.26A:
KaKaRoTo PS3 JailBreak Q&A
Q: Will I need special hardware (e.g. flasher, dongle, modchip etc.)?
A: No.
Q: Will homebrew work?
A: With NPDRM fixed, yes. Showtime would certainly be possible.
Q: Will recent games play correct?
A: Yes, its 3.7x, sure it plays all 1.00 - 3.7x games.
Q: Will PSN work?
A: Yes, its 3.7x, sure goes online without problems.
Q: Does it have Peek & Poke?
A: No. Peek & Poke require modifying lv1 and lv2.
Q: Do Backup manangers (e.g. MultiMAN, Rogero etc.) work?
A: No, see previously answer about Peek & Poke.
Q: Will my old homebrew still work?
A: No. All homebrew need the fixed NPDRM. Homebrew that relies on specific other patched functions/syscalls (e.g. Peek&Poke, BDemu etc.) will not work either, see previously answer about Peek & Poke.
Q: Does it gets us keys?
A: No.
Q: Does it gets us "CFW"/MFW?
A: No.
Q: Does OtherOS++ (Linux/FreeBSD) work?
A: No. Sony removed OtherOS feature after 3.15 and OtherOS++ relies on modifying the firmware. See previous "CFW"/MFW question.
Q: Will it allow downgrade?
A: No.
Q: Does it work on all PS3 models?
A: Yes. all current models.
Q: Are there brick risks?
A: No (standard disclaimer: It will be tested rigorously before release as you can expect from anything that KaKaRoTo has put his name on).
Q: Will this only work on 3.7x?
A: No. It was pretested on 3.60 and again confirmed on 3.73 before any public Tweet about it.
Q: What if Sony releases 3.74/3.80 before release
A: In that case it will be pretested on that version.
Q: So why are all the newssites hyping this that it does give CFW?
A: Because they don't read wiki's/blog's xD Besides, every minor news gets 'prolly CFW soon!' tagged by the bad ones.
Q: Is there a release date?
A: No, besides KaKaRoTo not able to work on it for 2 weeks, it also relies on (other people) fixing NPDRM.
The Road beyond... (or what can you and others do to expand the useability of it)
What is missing Prerelease (current state)?
Fixing NPDRM
- Make PKG's install and run the SELFs.
What is missing after release?
Peek & Poke
- lv1/lv2 dumping/patching
- Payloader3
- Backup Managers
Downgrade (already possible with Hardware flashing.
- 3.56+ keys / lv0 decrypted dump
- Modifying firmware files
- OtherOS++
Finally, from
his page he states the following in attempt to clear things up:
Hi all, I've been flooded with questions on twitter and I've read many posts on news sites and I've seen some stuff being said on IRC and I thought I needed to clarify a few things
First of all, I didn't expect to see my tweet front paged on all ps3 hacking news sites.. although I should have expected it.. but anyways, the "jailbreak" is not ready to be used, at all. I only tweeted that because I was excited having it working and I wanted to share my excitement with everyone. But this is a bit equivalent to the day I released that
create_cfw.sh script that created the very first CFW/MFW but it still took a couple of months before a real, easy, multiplatform and fully fledged solution was released : PS3MFW.
We are currently at the same state, I have the proof of concept, it works, but a solution that anyone can use where they just click a button and their PS3 gets jailbroken is still far from ready.
I've seen people say (and even write it in their front page news) that I'll release it in two weeks after I come back from vacation. That is not true and I never said that. What I said was that for the next 2 weeks, the project is on hold until I get back.. but when I get back, then I will continue working on it, and it will then take some more time before it's ready and released.
Some asked if it's based on what gitbrew was doing/suggesting or if I used someone else's exploit or work. No, this solution is my own idea and 100% my own implementation. However, the actual solution for the full jailbreak involves some components on which I will not work, and I expect/hope that someone else will provide the solution for that.
Some speculated it might be what I spoke about back in
March which I later said I wasn't pursuing by lack of motivation.. and yes, you are right. The same hack I had in March is still valid today, I told a few people about it (rms, Mathieulh, an0nym0us, and a couple more), but no one was interested in pursuing it further and actually exploiting that flaw (mainly because it requires a huge amount of work to get a proof of concept working). 10 days ago (I started on the 11th), I got bored and decided to start poking at it again, and yesterday (a lot faster than I thought it would take), I got my first pkg installed on 3.73 firmware.
On twitter, I said "do not update if you are on 3.55″, I said that in response to someone who said he would update. Because of that, people speculated that you need to be on 3.55 first, and then install something before doing the upgrade. No, that's not it, that would be useless. The purpose of my solution is to jailbreak a ps3 that is already on 3.73 firmware and which had never been jailbroken before. I told people not to update because, first of all, it's not yet ready, and second of all, the 3.55 firmware gives you a lot more possibilities than what can be achieved on 3.73.
So what is this jailbreak? I won't say because I don't want Sony to block it in a firmware update (and yes, they potentially could) before it's even released (and yes, I will release it when it's ready). But I will explain this to you : in order to run your homebrew apps, you need two things. First, to be able to install them on the ps3, and second to be able to run it once installed. I did only one of these two things.
Some may say it's not a real jailbreak, but the way I see it, there are three 'jails' on the ps3, I broke the first one which prevents you from installing anything, so now you can install your .pkg, great, but it won't run, that's the second jail. The third jail is being able to modify the firmware (peek&poke).
The second jail (running apps) is something that can be done, but it's not my area of expertise (npdrm algo), so I will not be working on that. I am waiting for someone else to achieve it (some have succeeded but do not wish to release it, at least not for now) then I will release.
The third jail (modifying the firmware) is not possible with my method, this means that you will not have a "CFW", you will run your homebrew applications and games on an official firmware. This also means that without peek&poke support, none of the backup managers will work. So, again, my solution is piracy-free, and as always, I do not plan on working on a way to enable piracy (or even legal backups).
Overall, the purpose will be to allow people who are on 3.73 firmware to enjoy the homebrew games that were released, to play a bit with Eskiss, and to use Showtime for playing their movies. This should be more than enough for everyone.
LOL? You can't be serious.
110$ for a game is freaking expensive. Here we pay them around 50-60$.
PS: HeyManHRU, Brazil is still considered as a third world country at the moment : en.wikipedia.org/wiki/Third_World
Obviously not the case. He means to explain why it's not so simple to have 4.00 OFW accept homebrew as he had promised earlier. Even then, there's always hope for an exploit that gets around it.
honored to see the front page
To quote: To popular demand, I have decided to try and explain how the ECDSA algorithm works. I've been struggling a bit to understand it properly and while I found a lot of documentation about it, I haven't really found any "ECDSA for newbies" anywhere.
So I thought it would be good to explain in simple terms how it works so others can learn from my research. I have found some websites that explain the basic principles but nowhere near enough to actually understand it, others that explains things without any basics, making it incomprehensible, and others that go way too deep into the the mathematics behind it.
ECDSA stands for "Elliptic Curve Digital Signature Algorithm", it's used to create a digital signature of data (a file for example) in order to allow you to verify its authenticity without compromising its security. Think of it like a real signature, you can recognize someone's signature, but you can't forge it without others knowing.
The ECDSA algorithm is basically all about mathematics.. so I think it's important to start by saying : "hey kids, don't slack off at school, listen to your teachers, that stuff might be useful for you some day!" But these maths are fairly complicated, so while I'll try to vulgarize it and make it understandable for non technical people, you will still probably need some knowledge in mathematics to understand it properly.
I will do this in two parts, one that is a sort of high level explanation about how it works, and another where I dig deeper into its inner workings to complete your understanding. Note however that I've just recently learned this stuff, so I'm definitely not an expert on the matter.
So the principle is simple, you have a mathematical equation which draws a curve on a graph, and you choose a random point on that curve and consider that your point of origin. Then you generate a random number, this is your private key, you do some magical mathematical equation using that random number and that "point of origin" and you get a second point on the curve, that's your public key. When you want to sign a file, you will use this private key (the random number) with a hash of the file (a unique number to represent the file) into a magical equation and that will give you your signature. The signature itself is divided into two parts, called R and S.
In order to verify that the signature is correct, you only need the public key (that point on the curve that was generated using the private key) and you put that into another magical equation with one part of the signature (S), and if it was signed correctly using the the private key, it will give you the other part of the signature (R). So to make it short, a signature consists of two numbers, R and S, and you use a private key to generate R and S, and if a mathematical equation using the public key and S gives you R, then the signature is valid. There is no way to know the private key or to create a signature using only the public key.
Alright, now for the more in depth understanding, I suggest you take an aspirin right now as this might hurt!
Let's start with the basics (which may be boring for people who know about it, but is mandatory for those who don't) : ECDSA uses only integer mathematics, there are no floating points (this means possible values are 1, 2, 3, etc.. but not 1.5..), also, the range of the numbers is bound by how many bits are used in the signature (more bits means higher numbers, means more security as it becomes harder to 'guess' the critical numbers used in the equation), as you should know, computers use 'bits' to represent data, a bit is a 'digit' in binary notation (0 and 1) and 8 bits represent one byte.
Every time you add one bit, the maximum number that can be represented doubles, with 4 bits you can represent values 0 to 15 (for a total of 16 possible values), with 5 bits, you can represent 32 values, with 6 bits, you can represent 64 values, etc.. one byte (8 bits) can represent 256 values, and 32 bits can represent 4294967296 values (4 Giga).. Usually ECDSA will use 160 bits total, so that makes well, a very huge number with 49 digits in it
ECDSA is used with a SHA1 cryptographic hash of the message to sign (the file). A hash is simply another mathematical equation that you apply on every byte of data which will give you a number that is unique to your data. Like for example, the sum of the values of all bytes may be considered a very dumb hash function.
So if anything changes in the message (the file) then the hash will be completely different. In the case of the SHA1 hash algorithm, it will always be 20 bytes (160 bits). It's very useful to validate that a file has not been modified or corrupted, you get the 20 bytes hash for a file of any size, and you can easily recalculate that hash to make sure it matches. What ECDSA signs is actually that hash, so if the data changes, the hash changes, and the signature isn't valid anymore.
Now, how does it work? Well Elliptic Curve cryptography is based on an equation of the form : y^2 = (x^3 + a * x + b) mod p
First thing you notice is that there is a modulo and that the 'y' is a square. This means that for any x coordinate, you will have two values of y and that the curve is symmetric on the X axis. The modulo is a prime number and makes sure that all the values are within our range of 160 bits and it allows the use of "modular square root" and "modular multiplicative inverse" mathematics which make calculating stuff easier (I think).
Since we have a modulo (p) , it means that the possible values of y^2 are between 0 and p-1, which gives us p total possible values. However, since we are dealing with integers, only a smaller subset of those values will be a "perfect square" (the square value of two integers), which gives us N possible points on the curve where N < p (N being the number of perfect squares between 0 and p). Since each x will yield two points (positive and negative values of the square-root of y^2), this means that there are N/2 possible 'x' coordinates that are valid and that give a point on the curve.
So this elliptic curve has a finite number of points on it, and it's all because of the integer calculations and the modulus. Another thing you need to know about Elliptic curves, is the notion of "point addition". It is defined as adding one point P to another point Q will lead to a point S such that if you draw a line from P to Q, it will intersect the curve on a third point R which is the negative value of S (remember that the curve is symmetric on the X axis). In this case, we define R = -S to represent the symmetrical point of R on the X axis. This is easier to illustrate with an image :
So you can see a curve of the form y^2 = x^3 + ax + b (where a = -4 and b = 0), which is symmetric on the X axis, and where P+Q is the symmetrical point through X of the point R which is the third intersection of a line going from P to Q. In the same manner, if you do P + P, it will be the symmetrical point of R which is the intersection of the line that is a tangent to the point P.. And P + P + P is the addition between the resulting point of P+P with the point P since P + P + P can be written as (P+P) + P.. This defines the "point multiplication" where k*P is the addition of the point P to itself k times here are two examples showing this :
Here, you can see two elliptic curves, and a point P from which you draw the tangent, it intersects the curve with a third point, and its symmetric point it 2P, then from there, you draw a line from 2P and P and it will intersect the curve, and the symmetrical point is 3P. etc you can keep doing that for the point multiplication. You can also already guess why you need to take the symmetric point of R when doing the addition, otherwise, multiple additions of the same point will always give the same line and the same three intersections.
One particularity of this point multiplication is that if you have a point R = k*P, where you know R and you know P, there is no way to find out what the value of 'k' is. Since there is no point subtraction or point division, you cannot just resolve k = R/P. Also, since you could be doing millions of point additions, you will just end up on another point on the curve, and you'd have no way of knowing "how" you got there. You can't reverse this operation, and you can't find the value 'k' which was multiplied with your point P to give you the resulting point R.
This thing where you can't find the multiplicand even when you know the original and destination points is the whole basis of the security behind the ECDSA algorithm, and the principle is called a "trap door function".
Now that we've handled the "basics", let's talk about the actual ECDSA signature algorithm. For ECDSA, you first need to know your curve parameters, those are a, b, p, N and G. You already know that 'a' and 'b' are the parameters of the curve function (y^2 = x^3 + ax + b), that 'p' is the prime modulus, and that 'N' is the number of points of the curve, but there is also 'G' that is needed for ECDSA, and it represents a 'reference point' or a point of origin if you prefer.
Those curve parameters are important and without knowing them, you obviously can't sign or verify a signature. Yes, verifying a signature isn't just about knowing the public key, you also need to know the curve parameters for which this public key is derived from.
So first of all, you will have a private and a public key.. the private key is a random number (of 20 bytes) that is generated, and the public key is a point on the curve generated from the point multiplication of G with the private key. We set 'dA' as the private key (random number) and 'Qa' as the public key (a point), so we have : Qa = dA * G (where G is the point of reference in the curve parameters).
So how do you sign a file/message ? First, you need to know that the signature is 40 bytes and is represented by two values of 20 bytes each, the first one is called R and the second one is called S.. so the pair (R, S) together is your ECDSA signature.. now here's how you can create those two values in order to sign a file.. first you must generate a random value 'k' (of 20 byes), and use point multiplication to calculate the point P=k*G. That point's x value will represent 'R'. Since the point on the curve P is represented by its (x, y) coordinates (each being 20 bytes long), you only need the 'x' value (20 bytes) for the signature, and that value will be called 'R'. Now all you need is the 'S' value.
To calculate S, you must make a SHA1 hash of the message, this gives you a 20 bytes value that you will consider as a very huge integer number and we'll call it 'z'. Now you can calculate S using the equation : S = k^-1 (z + dA * R) mod p
Note here the k^-1 which is the 'modular multiplicative inverse' of k it's basically the inverse of k, but since we are dealing with integer numbers, then that's not possible, so it's a number such that (k^-1 * k ) mod p is equal to 1. And again, I remind you that k is the random number used to generate R, z is the hash of the message to sign, dA is the private key and R is the x coordinate of k*G (where G is the point of origin of the curve parameters).
Now that you have your signature, you want to verify it, it's also quite simple, and you only need the public key (and curve parameters of course) to do that. You use this equation to calculate a point P : P= S^-1*z*G + S^-1 * R * Qa
If the x coordinate of the point P is equal to R, that means that the signature is valid, otherwise it's not.
Pretty simple, huh? now let's see why and how and this is going to require some mathematics to verify : We have :
P = S^-1*z*G + S^-1 * R *Qa
but Qa = dA*G, so:
P = S^-1*z*G + S^-1 * R * dA*G = S^-1 (z + dA* R) * G
But the x coordinate of P must match R and R is the x coordinate of k * G, which means that :
k*G = S^-1 (z + dA * R) *G
we can simplify by removing G which gives us :
k = S^-1(z + dA * R)
by inverting k and S, we get :
S = k^-1 (z + dA *R)
and that is the equation used to generate the signature.. so it matches, and that is the reason why you can verify the signature with it.
You can note that you need both 'k' (random number) and 'dA' (the private key) in order to calculate S, but you only need R and Qa (public key) to validate the signature. And since R=k*G and Qa = dA*G and because of the trap door function in the ECDSA point multiplication (explained above), we cannot calculate dA or k from knowing Qa and R, this makes the ECDSA algorithm secure, there is no way of finding the private keys, and there is no way of faking a signature without knowing the private key.
The ECDSA algorithm is used everywhere and has not been cracked and it is a vital part of most of today's security.
Now I'll discuss on how and why the ECDSA signatures that Sony used in the PS3 were faulty and how it allowed us to gain access to their private key.
So you remember the equations needed to generate a signature.. R = k*G and S= k^-1(z + dA*R) mod p.. well this equation's strength is in the fact that you have one equation with two unknowns (k and dA) so there is no way to determine either one of those.
However, the security of the algorithm is based on its implementation and it's important to make sure that 'k' is randomly generated and that there is no way that someone can guess, calculate, or use a timing attack or any other type of attack in order to find the random value 'k'. But Sony made a huge mistake in their implementation, they used the same value for 'k' everywhere, which means that if you have two signatures, both with the same k, then they will both have the same R value, and it means that you can calculate k using two S signatures of two files with hashes z and z' and signatures S and S' respectively :
S - S' = k^-1 (z + dA*R) - k^-1 (z' + da*R) = k^-1 (z + da*R - z' -dA*R) = k^-1 (z - z')
So : k = (z - z') / (S - S')
Once you know k, then the equation for S because one equation with one unknown and is then easily resolved for dA :
dA = (S*k - z) / R
Once you know the private key dA, you can now sign your files and the PS3 will recognize it as an authentic file signed by Sony. This is why it's important to make sure that the random number used for generating the signature is actually "cryptographically random". This is also the reason why it is impossible to have a custom firmware above 3.56, simply because since the 3.56 version, Sony have fixed their ECDSA algorithm implementation and used new keys for which it is impossible to find the private key.. if there was a way to find that key, then the security of every computer, website, system may be compromised since a lot of systems are relying on ECDSA for their security, and it is impossible to crack.
Finally! I hope this makes the whole algorithm clearer to many of you.. I know that this is still very complicated and hard to understand. I usually try to make things easy to understand for non technical people, but this algorithm is too complex to be able to explain in any simpler terms. After all that's why I prefer to call it the MFET algorithm (Mathematics For Extra Terrestrials)
But if you are a developer or a mathematician or someone interested in learning about this because you want to help or simple gain knowledge, then I'm sure that this contains enough information for you to get started or to at least understand the concept behind this unknown beast called "ECDSA".
That being said, I'd like to thank a few people who helped me understand all of this, one particularly who wishes to remain anonymous, as well as the many wikipedia pages I linked to throughout this article, and Avi Kak thanks to his paper explaining the mathematics behind ECDSA, and from which I have taken those graph images aboves.
P.s: In this article, I used '20 bytes' in my text to talk about the ECDSA signature because that's what is usually used as it matches the SHA1 hash size of 20 bytes and that's what the PS3 security uses, but the algorithm itself can be used with any size of numbers. There may be other inaccuracies in this article, but like I said, I'm not an expert, I just barely learned all of this in the past week.
More PlayStation 3 News...
SanctumSlayer: I forgive you. No hard feelings.