PS3 Fail0verflow CORE OS PS3Tools COSPKG and COSUnPKG Updated
Today Spanish PS3 homebrew developer Estwald has updated the COSPKG and COSUnPKG PlayStation 3 CORE OS PS3Tools originally released by Sven Peter of Fail0verflow attempting to fix some of the prevailing bugs.
Below is a rough translation, as follows with a better one HERE courtesy of daveribz: Hello, when the team fail0verflow published his tools, it was clear that not all were functional, or lack of certain bugs. Waninkoko had the "honor" to check in their own flesh (unfortunately) when your CFW few bricks caused due to incorrect operation of certain tools.
Recently brought new CFW that apparently have the same problem when composing the CORE OS package (and at least I could check in on Rogero cospkg being used ...) and honestly, but I'm fine in 3.41 the time and I have no intention of returning to the scene of PS3, say you had some obligation "moral" and here is the reason for the thread and the application (well, I have no desire for it tomorrow if I install a CFW these new, I enladrille console for CORE OS raruno )
Extracting CORE OS
After unpacking the. Pup and extracted content. Unpkg tar utility to unpack the CORE OS can this:
Now inside the folder "cos" have the folder "files" where we proceed by example, to patch lv1 or lv2.
However, once patched, we proceed to repackage the CORE OS and this is where the problems begin.
When introduced its CFW 3.55 flukes1 I noticed that in your python program was more or less what I have shown, but then proceeded to patch the "content" original with new content instead of using the utility "cospkg" . So I did the same with the CFW 341 and as we saw, there were bricks on consoles for that reason.
This technique has a drawback: the modified self, not to exceed in size to the original, because we fit them into the "hole" of the ancients. The advantage is that it respects the order of the files and the original lineup (why should the ordinary cospkg discard), but what happens if for some reason we get files with a size greater than the original?
Well, we have no choice but to fix utilities and cosunpkg cospkg to generate the "content" exactly as you would the original.
To do this I proceeded with several official firmwares to try and test the results, obviously, if I extract the content and recompose just like, I get the same data (both files are the same) and the number of firmwares used to view little peculiarities and exceptions that serve to determine how to proceed correctly (without failure a utility FIRMS with different nuances, indicates that we are on track)
The utility "cosunpkg" attached, works just like the original that generates a file called "list.txt" contains the number of entries and the list of files in the order of "content".
The utility "cospkg" generated "content" with the list and applies the corresponding alignment based on the observation of the following test firmwares I've used: 1.02, 3.15, 3.41, 3.50, 3.55 ancients and moderns 4.21, 4.25, 4.30 (A small detection based on the name of some important files)
If the original desempaquetaramos empaquetaramos in "Content2" without having changed anything, no difference should be compared in any of the cases and that is what I have seen with these firmwares and the methodology used.
That if, as I have no flasher, no interest in making a CFW, or consoles that risk, I can not guarantee that if you change the content otherwise may fail. In principle, it should not, but I would not put my hand in the fire and guess who is going to create a CFW has the means and knowledge to perform and can reverse the errors by flasher.
So Use it responsibly and understand that although the original files generated correctly, that the changes can not, if you change sizes, or has some other problem you have to fix utility (that may be a fault occur in addition, obviously, to generate either the pkg, tar or pup)
Deputy: the sources cosunpkg.cy cospkg.c ps3tools modified and executables compiled for Cygwin. I hope you find it useful and please refrain from using such applications unless you know what you're doing or do not have possibility to fix a potential problem.
Ah! and do not understand one iota of what I'm saying, you can save the questions do not apply equally
When the fail0verflow team published their tools, it was clear that they were not all functional and bug-free. Waninkoko had the "honor" of realizing this on his own when releasing the first true custom firmware, which unfortunately left a couple of users with bricked PS3s since the tools were not really working correctly.
More recently, we have seen new custom firmwares being pushed that seem to be having the same problem when rebuilding the CORE OS package (it's clear, for example, that a not-fully-working version of cospkg was used for building Rogero's 4.21 CFW, inevitably bricking more consoles) and to be honest, although I'm still doing fine on 3.41 and have no intention of returning to the PS3 scene, I feel like I have some sort of "moral" obligation so I'm opening a thread regarding updates to the tools.
Extracting CORE OS
After unpacking the .PUP and extracting the contents of the .tar file with unpkg, we can unpack CORE OS like this:
We now have a new folder named "files" inside the "cos" folder, where we could now proceed to patch lv1 or lv2 for example. Once these are patched, we need to repack CORE OS, and this is when the problems arise.
When flukes1 introduced his 3.55 CFW, it came to my attention that his python program used to build his PUP behaved differently of the technique I had shown him, but he still managed to patch the original contents of the firmware with new content without using the "cospkg" utility.
So I did the same with 3.41 CFW and, as we can see, there were no bricks reported for that reason.
This technique has a drawback though: filesize for modified selfs cannot exceed the size of the original selfs, because they need to fit in the "hole" of the old one.
The advantage is that it respects the order of the files and keeps the the original lineup (something that cospkg discards). But what happens if for some reason we need to pack files with a size greater than the original?
Well, we have no choice but to fix cosunpkg and cospkg to generate the "content" exactly as it was in the original.
To achieve this, I had to try and test with multiple official firmwares because obviously, if I extract the contents of the update and repackage them exactly like they were, I should obtain the same data (both files are equal). By using a bunch of different firmwares, I was able to detect any small differences and particularities that needed to be implemented in the repackaging process. (A tool which never fails in firmwares with really sublte differences means we're on the right track).
The "cosunpkg" tool that is attached works just like the original one, exept that it generates a file named "list.txt", which contains the number of entries and a list of files in the original content's order.
"cospkg" then generates the new contents with that list and applies the corresponding alignment following my tests on the following firmware versions: 1.02, 3.15, 3.41, 3.50, 3.55, 4.21, 4.21 and 4.30 (after a small detection based on the name of a couple of important files).
If we unpack the original firmware and repack it without having changed anything, there shouldn't be any differences at all between them and that is what I have seen with these firmwares. That is, since I have no hardware flash, no interest in making a CFW and no console to risk, I CANNOT GUARANTEE THAT IT WILL NEVER FAIL. In principle, it should not, but I wouldn't play with fire and I guess that someone that develops a CFW has the means and knowledge to test and reverse the possible errors that could occur with a hardware flasher.
So use it responsibly and understand that even though original files are regenerated correctly, it may not work with modified files if you change the filesize. Or there might be a problem in another tool that has to be fixed (there might be a problem somewhere else in the process, either in the making of the PKG, the tar archive or the PUP)
Attached are the sources of the modified ps3tools cosunpkg.c and cospkg.c, and the executables compiled for Cygwin. I hope that you find them useful and please refrain from using such tools if you don't know what you're doing or do not have the possibility to fix a potential problem.
Oh, and if you can't understand one iota of what I'm saying, you can keep your questions to yourself as I will not answer them.
Hope it makes sense! English and Spanish are only my second and third language, but I'm very fluent so it should be bang on
I guess it's better than Google
Last edited by daveribz; 10-27-2012 at 08:40 PMReason: Automerged Doublepost
scekrit2.exe adds support for npdrm type free to scekrit.exe; calculates the private key used to sign self headers.
sceverify2.exe adds support for npdrm type free to sceverify.exe; verifies the signature of self header.
scekrit_npdrm.exe calculates the private key used for the npdrm footer signature of npdrm selfs.
sceverify_npdrm.exe verifies the npdrm footer signature of npdrm selfs.
scekrit2 self1 self2
scekrit_npdrm self1 self2 [public key file] [curve type file]
sceverify_npdrm input.self [public key file] [curve type file]
Ps3 tools use the key directory specified by the environment variable "PS3_KEYS" (if defined) or else home/username/ps3keys or home/username/.ps3
[public key file] and [curve type] only need to be specified for selfs signed with custom keys.
Place custom keys in the exe directory.
The 2 selfs used with scekrit must be signed with the same key and have the same r value in the signature.
Since I couldn't find 2 npdrm self having the same r value in the footer signature, scekrit_npdrm was tested on npdrm self signed with custom keys and random fail.
I don't know why these weren't included in the original release. Support for npdrm self only requires adding about one C statement. (if app type equals NPDRM, decrypt header) Support for the footer signature requires pointing the app at the end of the self instead of the end of the header.
Includes source, compiles on linux or mingw/windows
edits to original source preceded by the characters //***
unpack source somewhere under /home/username/
the source files will be in two folders, ps3tools and updates.
copy all files from the updates folder, overwriting original files in ps3tools folder.
run these commands in /ps3tools: ./autogen.sh (wait .....) make