PS3 Fail0verflow CORE OS PS3Tools COSPKG and COSUnPKG Updated

[PS3 News]

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.

Download: PS3 Fail0verflow CORE OS PS3Tools COSPKG and COSUnPKG Updated / PS3 Fail0verflow CORE OS PS3Tools COSPKG and COSUnPKG Updated (Mirror) / CYGDLLs (Required cygwin1.dll, cygz.dll, and cyggcc_s-1.dll)

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:

unpkg 341firm/CORE_OS_PACKAGE.pkg 341firm/cos

This will generate 3 files in the folder "cos": info0, info1 and content

The content of "content" is extracted by the utility cosunpkg this:

cosunpkg 341firm/cos/content 341firm/cos/files

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)

To package would proceed as follows:

cospkg 341firm/cos/content 341firm/cos/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


More PlayStation 3 News...

[JOshISPoser]

well, i don't understand most, but from what i did, it sounds like it might help us create firmwares that shouldn't brick, but who knows.

anyways, all these behind the scenes stuff that the average user can't use is usually what i love most cause it just unlocks possibilities.

also, would be nice to get a better translation

i'm sure someone will be able to sum it up nicely and tell everyone what this really means if i'm not correct (which i probably am)

[PS3 News]

Yep, that was with Google Translate as always, if someone speaks Spanish fluently here and can do a better one I will link to it in the main article and +Rep ya!

[daveribz]

Here you go Boss, I translated it:

Hello,

When the fail0verflow team published their tools, it was clear that they were not all functionnal 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:

unpkg 341firm/CORE_OS_PACKAGE.pkg 341firm/cos

This command should generate 3 files in the "cos" folder: "info0", "info1" and "content". The "content" file can be further unpacked using cosunpkg like this:

cosunpkg 341firm/cos/content 341firm/cos/files

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).

To pack a firmware, proceed as follows:

cospkg 341firm/cos/content 341firm/cos/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 anwser them.

Regards

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

[PS3 News]

Nice job, I added a link to yours in the main article now and +Rep for taking the time to do it too daveribz!

[JOshISPoser]

you definitely wrote it way more clearly than most people who natively speak english

anyways, it came out a bit different than i understood the first time. so, did file sizes change in his program before and that caused bricks?

the thing that confused me was he went on saying that there's a problem getting filesizes down if it is bigger... wouldn't that be impossible to do pretty much?

idk, interesting stuff. i just hope it helps by giving more brick-free firmwares.