Ps3xport released!

Update : The method I spoke about below for getting your IDPs from an OFW console was released by flatz, look for his idpstealer release.  I have also fixed a major bug in ps3xport’s ExtractFile which corrupted data and ported ps3xport for windows. You can find the latest version (0.2 at the moment) on the github repository and I’ve built windows binaries here. Enjoy!

 

Hello everyone!

It’s been quite a long time and I’m very happy about that :p
Let’s do the boring part first! This is my final release for the scene, I am not “coming back” or anything like that, so don’t get your hopes up, but I needed to release this so I’d be officially done. I have never actually announced that I’m leaving the scene but everyone figured it out. It wasn’t originally done intentionally actually, but life caught up with me, work, family, lack of time, etc.. so I had little time to work on the ps3. Also, my motivation was mostly gone due to not finding anything interesting anymore, a lot of drama and I’m not a huge fan of all the attention this all brings. I got into the scene because I was curious and I wanted to learn, and I have to say I’ve learned a lot of things these past years and it was an incredible journey, but as I had lack of time and started breathing, I realized that I’ve had enough of it so I left and I am very happy with that decision because you have absolutely no idea how much of a time drain and headache this was :p
Anyways, there was one thing I did just before I left, but I never got to release it, but today is your lucky day as it’s release O’clock where I am!. This release is a way to say Merry Christmas, Happy Holidays, etc.. to everyone, and a way for me to also say “I’m done for good, I don’t have anything left for you in a drawer somewhere” :). I’ve wanted to release this for a while now, and I even made a poll on ps3hax back in March 2012 asking people if I should (looks like ps3hax is down right now so here’s the google cache version) and the general response was not to release it until it can be useful (when an npdrm workaround is found) with some people saying to release if nothing new happens in the scene.. and I think I’ve waited long enough now to know nothing new on that front will happen.

So.. since I’ve announced the release, I’ve seen a lot of speculation about what it is and what it could be.. a lot of people seem to think (or mostly, want/hope for) a downgrade method, unfortunately that’s not the case. I’ve seen some ridiculous suggestions too, like someone asking if it’s a way to run PS4 and Xbox One games on PS3.. I’m sorry to say, that’s not it either :p As I’ve said in a tweet shortly after, this is nothing groundbreaking, this is code that hasn’t been touched in 3 years, so it’s already 3 years old, but I think it’s still something that can be very useful to the community.

So here it is, I’m introducing to you : PS3xport! I’ve uploaded it to my github account here : https://github.com/kakaroto/ps3xport

What does it do? Well, it’s basically a tool for manipulating the PS3 backup data. When I say “PS3 backup”, I’m not talking about a “backup” of a game, no.. I’m talking about the full PS3 hard drive backup that you can do by going to “System Settings->Backup Utility” on your XMB. That creates an encrypted directory on your FAT32 hard drive which allows you to format your PS3 and then Restore it just like it was before. I’ve reverse engineered the file format and encryption and PS3xport allows you to create new backup data from scratch, or dump existing ones, or delete specific files from a backup or do a whole lot of other things to your backup folders. This gives you total control over your /dev_hdd0 and /dev_flash2 filesystems, which will let you install homebrew on any console, even if it’s the latest OFW version. Unfortunately, just like it was 3 years ago, you wouldn’t be able to run those homebrew apps you install due to the NPDRM ECDSA signature missing. If you have your IDPS though for example, it could let you restore a backup from one PS3 to another PS3 without losing any of your data in the transfer.

So.. what’s this about “your IDPS”? yes, the backup has two sets of files, some can be decrypted right away and some can’t because they are encrypted with your IDPS (your unique ps3 device id) which is why they can’t be restored on a different ps3. If you have a CFW, you can easily get your IDPS (I’ve written a small tool to do that, released on github, but apparently MM and Webman will also give you that information) and that will give you total control over your backup data as you would be able to decrypt and reencrypt it. If you have OFW and can’t get your IDPS, then you will not be able to dump/decode all the files from your backup, but you will still be able to create a backup that can be restored on your PS3 with no limitations (this means for example that you can restore a backup from a CFW into an OFW without any issues). I was told however that someone can get IDPS from OFW consoles and in light of this release, they might release their method soon, I can’t say more than that though, but be patient and good things come to those who wait 🙂

So my release is in two parts. First, the documentation of the file format was added to the ps3devwiki so any developer can understand how the backup archive files are created and can create their own tools. Reverse engineering that format took months of work and I won’t go into too much details about what had to be done to figure out the format but it was an incredibly long and difficult task to do that I had a lot of fun in doing. The second part of the release is of course the release of the ps3xport tool. The tool is quite powerful and you can do a lot of things with it, but it’s a command line only tool and I honestly just tested it on Linux, it’s not really my job at this point to make a windows build, or make a GUI around it, etc.. but I’m sure it won’t be long before others in the scene pick it up and make a nice GUI for it and release windows binaries. I’ve written a nice README file so everyone can understand how the tool works and what it can do. I remember though that 3 years ago just before I stopped working on it, I wanted to add a “AddPKG” command to it which would just ‘install’ a pkg into the backup data automatically, unfortunately, I never got to do it, but it should be easy to do. While I’m at it, I’m also releasing a pkg extraction tool which I found in an old directory (cool thing is the -p option in it, try it…) as well which is a PKG extraction tool that uses the PagedFile mechanism (see below) to allow for very fast pkg file access with very little memory usage even for huge pkg files, any dev can probably mix those two together to add the AddPKG feature to ps3xport.

On the software front, ps3xport.c will parse the commands then use the archive_* API which is in archive.c. That will contain all the functions needed to manipulate the archive files. It uses a ChainedList which is my rudimentary implementation of a GList-like ordered list and the archive API also uses PagedFile objects which are pretty cool. PagedFiles are a wrapper around a file which allows you to read/write to a file using pages (I set it to 64KB per page I think) so it limits the hard drive access. The cool thing about it is that it has encryption and hashing built in, so you can just set the encryption key or ask for the file to be hashed, and whenever you read/write, the encryption will be done transparently, and the coolest thing about it is that you can actually seek in the encrypted file and it will still work (it recalculates the required IV whenever you seek). The encryption there works on the stream, so you don’t need to write blocks of 16 bytes every time (thanks to the paging of the data) and it has a cool ‘splice’ method which allows you to copy data from one PagedFile to another easily, so you could in theory re-encrypt a file using a different key using 5 function calls (open *2, set_key*2, splice).

That’s about it.

I’m really happy about this release, and I want to say Merry Christmas/Happy New Year to everyone, and of course..

So long, and thanks for all the fish!

 

Eleganz release for Cobra ODE

Hi everyone,

It’s been a long time since I last blogged. Today I have some exciting news for you, as I have ported Eleganz, my homebrew manager, to the Cobra ODE.

A little while ago, I tweeted that if Cobra ever released their device and did provide an open source library for integration of other managers, I would port Eleganz to it, and today I am fulfilling that promise. I would like to thank the guys over at ps3crunch.net and ps3hax.net for testing this for me, particularly Abkarino, hyappon, freddy, magneto and Xodus69.

When I released Eleganz in November 2011, I left out one small thing on the TODO list, I wanted to see someone pick it up and add the code to exitspawn to actually make Eleganz execute the homebrew apps, but no one did that in almost a year now. I am a bit disappointed that the ps3 scene (homebrew devs, not users) didn’t pick it up, but it looked like no one was interested in maintaining Eleganz in my place. Today, I am happy to see that Eleganz is not throw-away code, as it can be useful to ODE users.

I can understand why Eleganz didn’t have much appeal in the world of CFW (it was originally intended to run on OFW if my HEN ever worked), but with the ODEs running on OFW, it’s perfect for the job. It’s simple, it’s beautiful and customizable!

Not only can Eleganz list the games from the Cobra ODE and allow you to select your iso, but it will also allow you to list and run homebrew apps that you can embed in the ISO file. This way you can get access to all your homebrew in a single place, without the need to restart the PS3 or boot the homebrew’s iso from the ODE. You can just extract the eleganz iso, and add homebrew apps (that are re-signed for running from a BD drive) to the iso’s PS3_GAME/USRDIR/HOMEBREW directory and recreate the iso with the cobra tool, and that’s it.

Note that this is not an indication of me getting back into the hacking scene. I have given up on the HEN long ago as I realized that there was no way (that I could find) to run homebrew on OFW, unless they are running from a disc. I may keep improving Eleganz in the near future, but I do not plan to do anything more than that for the ps3 scene at this point.

I would also like to tell everyone that there’s no need to worry, Eleganz will not become cobra-specific, as any feature I’d implement will benefit CFW as well as ODE users. I will be releasing an updated version for CFW users soon.

I’d also like to thank magneto and the Cobra team for offering to send me a Cobra ODE as a gift for porting Eleganz to it. Once I receive it, I plan on adding disc dumping capabilities to Eleganz and improve the user experience a little without relying on others to test it for me.

You can find the latest source code on github as always and compile it yourself or you can download the pre-compiled iso file from this link : http://www.multiupload.nl/GXBBI19VOL

I hope it gets used now and you all can enjoy it and I hope I can see some cool themes created for it now!

KaKaRoTo

Eleganz: The Elegant Homebrew Manager

Hi everyone,

Last year, in January, I decided to have some fun and write a homebrew application using the EFL libraries. I decided to work on a homebrew manager.. basically a replacement to the XMB. It went really well, and the development was really fast, and it was all thanks to the awesome API and capabilities of the EFL libraries. However, I became busy and was unable to continue… also, it was a bit slow and without proper hardware acceleration, it wouldn’t be as good as I hoped for, so I put the project on the side.
After many months, in September, thanks to gzorin’s work, we finally had a working and usable GL implementation and the EFL apps automatically gained from it by becoming hardware accelerated. My homebrew manager was much better! but I still needed to finish a few things and I didn’t have time so I put to rest again.

Today, I have decided to release this homebrew application, *as is* for everyone’s enjoyment! This means that it is not fully working, it might still have some bugs here and there, but it is still a homebrew app that people can use and have some fun with. Most importantly it will serve 4 purposes :

  • Maybe re-awaken  this dying PS3 homebrew scene
  • Be a good “exercise to the community” for finishing it up
  • Be a good example of what can be done with the EFL
  • Bring non-developers into writing EFL themes for the app

 

I introduce to you, Eleganz! The Elegant Homebrew Manager! A little homebrew app that lets you install pkg files and run your games directly from it. Here is the mandatory screencast video :


YouTube Link toEleganz screencast

 

I have published my app in both github and on ps3dev’s gitorious. and you can also download a pre-compiled .pkg for your PS3 to have fun with it.

Here are some highglights of the application (features, limitations and bugs) :

  • The whole User Interface is completely customizable with themes
  • Installs .pkg files locally to its own data directory (won’t be visible in the real XMB, unless someone reverses the database format)
  • Does not yet run games (it’s for you to do it, use ps3load as reference maybe…)
  • Current theme is missing proper theme/images for the progressbar windows (default exquisite/E17 theme used)
  • System freezes for a few milliseconds when it tries to load a game’s background image (might be fixed if we implement a pthread library and threading support in the EFL)
  • Apparently crashes when it exits (bug)

The homebrew app comes with two themes, a dark and light theme. I like the dark one so I chose that as the default (oh, ignore that grey background ‘default’ one from that screencast video, that was just for testing). I wrote the user interface for the theme (the Edje files) while opium designed all the graphics. The theme engine in the EFL is extremely powerful, so I hope I will see tons of themes popping up. And I do not mean “change the images” themes, I want real themes, where the whole UI is different, a vertical XMB, a circular one, a 3D theme with perspective/depth for the icons, a dynamic/moving background, etc… You can learn about the .edj/.edc file format here and don’t forget to check the EDC reference wiki.

I hope to see the community pick this up and have fun with it!

That’s about it, enjoy it, and send me your patches! I’ll be waiting 🙂

KaKaRoTo

 

p.s: Forgot to say that the rules/naming conventions/etc.. of the EDC files are explained here. If a .edj file doesn’t have the appropriate parts/groups, then it will be ignored and will not show on the UI.

p.p.s: You can install the EFL on windows and have access to edje_cc to compile your .edc into .edj.

p.p.p.s: Damn, I  keep forgetting stuff.. by the way, the whole Eleganz application works just fine on the PC too, I did all my development on the PC (that screencast was actually on Linux), *then* I tried it on the PS3 and it just worked.. so for theme development, it should be pretty easy to test without the need of a PS3.

RSXGL working and usable

Hi everyone!

When the PS3 homebrew scene started, a lot of people were complaining that it wasn’t possible to write 3D games for the PS3 because of its lack of OpenGL library.
Almost a year ago, Alex Betts thought he would tackle this problem and he started working on RSXGL… an implementation of the OpenGL 3.1 specification written from scratch targeting the PS3’s RSX. Anyone in their right mind would say that it’s impossible, that it’s too much work, but Alex spent the last year working on it, alone, until it became usable. You can read some news about it here.
For some reason though, no one used it to build their own apps. Maybe the status of the project was scaring them, it was said to be incomplete, there was no GLSL support, etc…
I am writing today to tell you that RSXGL is perfectly usable! It supports online GLSL compilation, as well as any feature you might want. As proof, I have written a new hardware accelerated engine for the EFL using RSXGL and it worked great! Alex and I spent a lot of time testing and fixing all the issues that were in RSXGL that were made visible by the EFL’s GL engine and I am happy to say that it’s working now. Expedite is able to run most of its tests at 50 to 60 fps on 1080p resolution (instead of the average of 5 to 10 fps it had on 720p before).
You can see performance tests right here (Running some tests from expedite) :
Software rendering: http://dl.dropbox.com/u/22642664/expedite_psl1ght.log
RSXGL rendering: http://dl.dropbox.com/u/22642664/expedite_rsxgl.log

Please give RSXGL a try. Also, you can get the latest EFL version from my repository, which includes the gl engine for ps3. Now, any EFL application will be automatically hardware accelerated thanks to RSXGL. I hope we can see some new games (or old GL games being ported) soon!

RSXGL : https://github.com/gzorin/RSXGL
EFL : https://github.com/kakaroto/e17

Enjoy!

Exquisite tool becomes a library!

The exquisite tool that comes with Enlightenment is a nice, pure edje application that is used for showing boot process splash screens. I thought it was a nice splash screen and more generally, a nice progress bar and wanted to use it in my own apps.

I have modified the exquisite tool to become a library so it can be used by others in their applications, while keeping the exquisite and exquisite-writer tools intact (they will now depend on libexquisite.so though).

Since it’s a very simple feature (only a couple hundred lines of code), the API is simple as well. Here’s an example of use :

  Evas_Object *obj = exquisite_object_add (evas, theme);
  evas_object_show (obj);

  exquisite_object_title_set (obj, "Title of the screen");
  exquisite_object_message_set (obj, "My Message");

  int test_id = exquisite_object_text_add (obj, "First test");
  int second_test = exquisite_object_text_add (obj, "Second text!");
  exquisite_object_status_set (obj, test_id, "FAIL", EXQUISITE_STATUS_TYPE_FAILURE);
  exquisite_object_status_set (obj, second_test, "OK", EXQUISITE_STATUS_TYPE_SUCCESS);

  exquisite_object_pulsate (obj);
  exquisite_object_progress_set (obj, 0.95);

That’s it, and you get a nice screen with title, message, text area for status messages (if you want it), and a progress bar. This also means you can use the default theme from exquisite or write your own using the same theme specification which can later on be used by others.

Please review the API provided, and this is the right time to suggest any changes to the API or to improve on the library, so let us know what you think!

How the ECDSA algorithm works

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.

Status update on the PS3 4.0 HEN

Here’s a “quick” status update on the 4.00 HEN (Homebrew ENabler) for PS3.

Following my clarifications from almost 2 months ago here, there has been a lot of progress. We have not been slacking off, we’re a group of about 10 developers working together for the last 2 months, for sometimes 15 hours everyday in order to bring back homebrew support to the latest version of the PS3.

There are three major parts to the HEN, first, getting the packages to install on the PS3, that part is done, completed, tested, debugged, etc.. the second part is to get the apps to run, that one still has major issues… the last part is something I will not discuss for now (it’s a surprise) but it’s about 60% to 70% done (and it has nothing to do with peek&poke and has nothing to do with backup managers or anything like that. This is and will stay a piracy-free solution for the PS3).

Now, running apps is the biggest challenge that we’ve been working on for the past 2 months. As some of you know, if you’ve been following me on Twitter, we originally had hoped for Mathieulh to give us the “npdrm hash algorithm” that was necessary to run the apps, but he was reluctant, he kept doing his usual whore so people would kiss his feet (or something else) so he’d feel good about himself. But in the end, he said that he refuses to give us the needed “npdrm hash algorithm” to make it work… So what I initially thought would be “this will be released next week” ended up taking a lot more time than expected, and we’re still nowhere near ready to make it work.

Mathieulh kept tossing his usual “riddles” which he thinks are “very helpful for those who have a brain”, and which pisses off anyone who actually does… so he told us that the solution to all our problems was to look in appldr of the 3.56 firmware.. and that it was something lv1 was sending appldr which made the “hash check” verified or not… so we spent one month and a lot of sweat and after killing a few of our brain cells out of exhaustion, we finally concluded that it was all bullshit. After one month of reading assembly code and checking and double-checking our results, we finally were able to confirm that that hash algorithm was NOT in the 3.56 firmware like he told us (at all).

He said  that it was an AES OMAC hash, but after tracking all the uses of the OMAC functions in appldr, we found that it was not used for the “hash”…  he then said “oh, I meant HMAC“, so we do that again and again come up with the same conclusion, then we’re sure it’s not in appldr, and then he says “ah no, it’s in lv1“.. have a look for yourself to what he decided to write : http://www.ps3devwiki.com/index.php?title=Talk:KaKaRoTo_Kind_of_%C2%B4Jailbreak%C2%B4

That happened after the huge twitter fight I had with him for being his usual arrogant ass and claiming that he “shared” something (For your information, the code that he shared was not his own, I have proof of that too (can’t show you the proof because even if I don’t respect him, I gave him my word to not share what he gave me, and I respect my word) since he forgot to remove the name of the original developer from one of the files… also it was completely useless and was not used at all, just made me waste a day reading the crappy undocumented code. So why is he still trying to force his “advice” through these riddles even after we had that fight? Well to sabotage us and make us lose all those months of hard work!

So anyways, we had all accepted that Mathieulh was full of shit (we knew before, but we gave him the benefit of the doubt) and decided to continue working without considering any of his useless riddles. So we then tried to exploit/decrypt the 3.60+ firmware in order to get the algorithm from there.

Now, a few more weeks later, we finally have succeeded in fully understanding that missing piece from the “npdrm hash algorithm”,  and here it is for everyone’s pleasure with some prerequisite explanation :

A game on the PS3 is an executable file in a format called a “SELF“file (kind of like .exe on windows), those “self” files are cryptographically signed and encrypted.. For PSN games (games that do not run from a bluray disc), they need to have an additional security layer called “NPDRM”. So a “npdrm self” is basically an executable that is encrypted and signed, then re-encrypetd again with some additional information. On 3.55 and lower, we were able to encrypt and sign our own self files so they would look like original (made by sony) “npdrm self” files, and the PS3 would run them without problem. However, it wasn’t really like an original file.. a real NPDRM self file had some additional information that the PS3 simply ignored, it did not check for that information, so we could put anything in it, and it worked. Since the 3.60 version, the PS3 now also validates this additional information, so it can now differentiate between NPDRM self files created by sony and the ones that we create ourselves for homebrew. That’s the “npdrm hash algorithm” that we have been trying to figure out, because once we can duplicate that information in the proper manner, then the PS3 will again think that those files are authentic and will let us play them.

Another important point to explain, I said a few times that the files are “signed”.. this means that there is an “ECDSA signature” in the file which the PS3 can verify. The ECDSA signature is something that allows the PS3 to verify if the file has been modified or not.. it is easy to validate the signature, but impossible to create one without having access to the “private keys” (think of it like a real signature, you can see your dad’s signature and recognize it, but you can’t sign it exactly like him, and you can recognize if your brother tried to forge his signature). So how were we able to sign the self files that were properly authenticated on 3.55? That’s because this “ECDSA signature” is just a very complicated mathematical equation (my head still hurts trying to fully understand it, but I might blog about it in the future and try to explain it in simple terms if people are interested you can learn about it here), and one very important part of this mathematical equation is that you need to use a random number to generate the signature, but Sony had failed and used the same number every time.. by doing that, it was easy to just find the private key (which allows us to forge perfectly the signature) by doing some mathematical equation on it. So to summarize, a “signed file” is a file which is digitally signed with an “ECDSA signature” that cannot be forged, unless you have the “private key” for it, which is impossible to obtain usually, but we were able to obtain it because Sony failed in implementing it properly.

Now, back on topic.. so what is this missing “npdrm hash algorithm” that we need? well it turns out that the “npdrm self” has a second signature, so it’s a “encrypted and signed self file” with an additional layer of security (the NPDRM layer) which re-encrypts it and re-signs it again. That second signature was not verified in 3.55 and is now verified since the 3.60 version of the PS3 firmware.

One important thing to note is that Sony did NOT make the same mistake with this signature, they always used a random number, so it it technically impossible to figure out the private key for it. To be more exact, this is the exact same case as the .pkg packages you install on the PS3, you need to patch the firmware (making it cfw) so that those .pkg files can be installed, and that’s because the .pkg files are signed with an ECDSA signature for which no one was able to get the private key. That’s why we call them “pseudo-retail packages” or “unsigned packages”.

The signature on the NPDRM self file uses the exact same ECDSA curve and the same key as the one used in PS3 .pkg files, so no one has (or could have) the private key for it. What this means is that, even though we finally figured out the missing piece and we now know how the NPDRM self is built, we simply cannot duplicate it.

The reason we wasted 2 months on this is because Mathieulh lied by saying that he can do it.. remember when the 4.0 was out and I said “I can confirm that my method still works” then he also confirmed that his “npdrm hash algorithm” still works too? well he didn’t do anything to confirm, he just lied about it because there is no way that he could have verified it because he doesn’t have the private key.

I said I will provide proof of the lies that Mathieulh gave us, so here they are : he said it’s in 3.56, that was a lie, he said it’s an AES OMAC, that was a lie,  he said it’s an HMAC, that was a lie, he said it’s in appldr, that was a lie, he said it’s in lv1, that was a lie, he said that he can do it, that was a lie, he said that “it takes one hour to figure it out if you have a brain”, that was a lie, he said that he verified it to work on 4.0, that was a lie, he said that he had the algorithm/keys, that was a lie, he said that once we know the algorithm used, we can reproduce it, that was a lie, he kept referring to it as “the hash”, that was wrong. The proof ? It’s an ECDSA signature, it’s not a hash (two very different terms for different things), it was verified by vsh.self, it was not in lv2, or lv1, or appldr, and the private key is unaccessible, so there is no way he could build his own npdrm self files. Now you know the real reason why he refused to “share” what he had.. it’s because he didn’t have it…

So why do all this? was it because his arrogance didn’t allow him to admit not knowing something? or was it because he wanted to make us lose all this time? To me, it looks like pure sabotage, it was misleading information to steer us away from the real part of the code that holds the solution…. That is of course, if we are kind enough to assume that he knew what/where it was in the first place.  In the end, he wasn’t smart enough to only lie about things that we could not verify.. now we know (we always knew, but now we have proof to back it) that he’s a liar, and I do not think that anyone will believe his lies anymore.

 

Enough talking about liars and drama queens, back to the 4.0 HEN solution… so what next? well, we now know that we can’t sign the file, so we can’t run our apps on 3.60+ (it can work on 3.56 though). What we will do is look for a different way, a completely new exploit that would allow the files we install to actual run on the PS3. We will also be looking for possible “signature collisions” and for that we will need the help of the community, hopefully there is a collision (same random number used twice) which will allow us to calculate the private key, and if that happens, then we can move forward with a release.

When will the “jailbreak” be released? If I knew, I’d tell you, but I don’t know.. I would have said in last november, then december, then before christmas, then before new year, etc… but as you can see, it’s impossible to predict what we will find.. we might get lucky and have it ready in a couple of days, or we may not and it will not be ready for another couple of months.. so all you need to do is : BE PATIENT (and please stop asking me about an estimated release date)!

I would like to thank the team who helped on this task for all this time and who never got discouraged, and I’d like to thank an anonymous contributor who recently joined us and who was instrumental in figuring it all out. We all believe that freedom starts with knowledge, and that knowledge should be open and available to all, that is why we are sharing this information with the world. We got the confirmation (by finding the public key used and verifying the signatures) yesterday and since sharing this information will not help Sony in any way to block our efforts in a future release, we have decided to share it with you.  We believe in transparency, we believe in openness, we believe in a free world, and we want you to be part of it.

If you want to know more about this ECDSA signature algorithm, I tried to explain it in a blog post here, also, you can read this interesting paper that explains it in detail, and you can also watch Team Fail0verflow’s CCC presentation that first explained Sony’s mistake in their implementation, which made custom firmwares possible.

 

Thanks for reading,

KaKaRoTo

 

Clarifications about 3.73 (and 4.0) “jailbreak”

Update:
I tested the jailbreak on the latest firmware 4.0 since it was released and I can confirm that it still works.

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.

Finally, I will conclude by replying to another question I received : Do you accept donations? The answer is yes. I do accept donations but I do not seek them out. I will include a donate button to the bottom of this post, so if anyone wishes to donate, they can do so, however, I want to make it clear that whether or not you donate does not and will not affect in any way, the release, or the progress of the work I’m doing. If you donate, you would do it as a sign of appreciation of my efforts, and not in exchange of any favors or anything crazy like that.

That’s about it I think… If you have any more questions, please refrain from asking them, I get enough as it is already.. I also said everything I needed to say and I don’t want to give any more information than that (for now).

KaKaRoTo

Eskiss for PS3 with PS Move support

Hi all,

I’m releasing Eskiss with Move support and I think the instructions on how  to use it require a bit more than what twitter allows (from my usual small updates).

You can download here the Eskiss package for PS3 3.55, and here the package for PS3 3.41.

The instructions are simple, you can still play with a normal mouse if you want, or use the controller to emulate the mouse, just like before. But, if you have a PS Eye camera plugged in, then it will also be ready to handle the Move.

If it detects a move controller, the ball on the controller will be white, at that point, you must press the Action button while pointing the controller to the camera (there’s no image feedback on the screen, so just point and press the action button). This will calibrate the controller and the ball will change color. At this point, moving the controller will also move the cursor on screen.

You can press the Action button at any time to recalibrate the controller (useful if the tracking stops working correctly, or camera falls off), and you can press the Start button at anytime to center the cursor on screen. Pressing the T button trigger will emulate a click.

You have the choice between two tracking modes, the first one (the one selected by default) is the 3D coordinate system, which means the cursor appears on screen with 1 to 1 precision (kind of) with where the controller is located in the room, so you have to move the whole controller to move the cursor (and even maybe stretch your arms to get to the corners), the second tracking mode is using the internal gyroscope of the controller, in other words, you can move the cursor just by pointing or rotating the controller without moving the whole controller in 3D space.

You can switch from one tracking mode to another at any time by pressing the Select button. Try them both and see which one you like best.

P.s:  When you press the Action button to calibrate, the ball will change colors a few times, you must not move the controller while it’s doing that, do not move until it becomes a solid, stable color. If the ball becomes white again, it means you moved and the calibration failed… in that case, try again.

P.p.s: In this release, I have also fixed the crash that you might have had in the previous version, so the game should be a lot more stable. While it still might crash, it is now very rare and shouldn’t break the gameplay like it did before.

And here’s a video demo of the game running with the Move controller, courtesy of fungos :

Enjoy,

KaKaRoTo

The Humble Homebrew Collection

Finally, after almost 2 months of hard work, I’m proud and happy to announce the release of the Homebrew game I’ve been working on : SGT Puzzles. It’s a collection of portable puzzle games for Windows, Mac, Linux, Android, PocketPC, Android, etc.. and I’ve ported it to the PS3 too!

The release of this homebrew game comes with the  release of The Humble Homebrew Collection which is inspired by the Humble Indie Bundle Initiative (but not endorsed by it). The difference here is that you don’t have to pay anything in order to enjoy the games, they are free to download by anyone, but you are also able to donate any amount to the developer of the puzzle games (Simon Tatham) as well as the PS3 port developer (me!) and the EFF. You decide who to send the money to just like with the Humble Bundle. I’ve also linked to the game’s Windows, Mac and Android ports if you want them (they are already available in most Linux distributions).

The addition here and probably the most important part is a petition where yo get to sign and send a message to Sony asking for a legitimate way of having homebrew games on the PS3. Every signature will send an email to SCEE, SCEA, SCE Australia, SCE New Zealand and Kazuo Hirai, the CEO of Sony Computer Entertainment.  This is done in the hopes that Sony will finally see the light, learn from the mistakes they’ve been doing these past few years, and finally give us a legitimate and officially supported way of developing homebrew applications for our PS3 Systems.

Sony would be stupid not to answer to that, considering that Apple complied, Microsoft complied and Google complied, and they are all generating huge revenues thanks to homebrewers, with zero investment from their part. I know that the Sony execs only understand when you talk about money, so I hope this is a good enough incentive for them. Clearly, they do not care about their customers, so I don’t think they’ll change anything only to do what is right.

The SGT Puzzles game includes 33 puzzles, which are excellent for the most part. My favorite is and always will be Pattern, as I’ve spent countless hours playing it. I’ve recently also discovered Rectangles and Net which are also very good (in higher difficulties). I suggest you give those puzzles a try. Above all, I hope everyone can enjoy these games.

This all started about 2 months ago when I found a copy of Pattern on my PC and started playing it again. I tweeted about it and asked if someone wanted to port it to the PS3. Clement Bouvet (@TeToNN) quickly made a proof of concept using cairo. That got me excited and I decided to help him. We ended up writing a PS3 application over Simon Tatham’s Portable Puzzle Collection which, I must say, is very well written and made porting it to the PS3 very easy. It took maybe a day or two and the first game was playable on the PS3. At that point, I discovered the Cairo Drawing API which I loved and and I decided to invest myself entirely in this. It took 3 more weeks of hard work to get the whole system working (choose your puzzle game, change difficulty (Select) and writing the whole menu system for the game). I’ve received various help, Surenix made the designs for the menu graphics and buttons, and BeGamer helped design the HHC website.

The game still lacks a few things, and I will continue to work on it and improve it so everyone can enjoy a quality homebrew game, that, I hope, will make the anti-homebrew purists jealous.

The funny thing is that since day one, the source code for this game was available on my github account, but no one noticed it. Only a few people who accidently ended up on my github page found it, but no news website author found it or reported on it. I’m glad, because it allowed me to make this happen the way I wanted it to and launch this HHC initiative when it became ready. I’d like to ask the various websites out there not to link directly to the games (even if you are allowed to) and instead link to humblehomebrew.com so people can sign the petition while downloading.

Most of the code is licensed under the MIT license. Parts of the code (the cairo menu system) is licensed under the LGPL license and I plan on extracting that into its own library for other developers to use in their applications.

The website took about 3 weeks to code. I learned two valuable lessons.. first, HTML coding is crap… secondly, it’s much more complicated than it looks. I hope people will appreciate this effort and I hope the Humble Homebrew Collection will make a difference.

In the future, I hope to enhance it by adding new homebrew games whenever I find something of quality, and keep the website and this whole initiative going for a long time, for as long as necessary.

 

So.. go ahead, download the games, sign the petition, maybe donate if you’re feeling generous, and most importantly, have fun!

Thank you!