PS3 [DEV} PS3MFW Builder MOD

[sandungas]

So, is it possible for some insturctions on how to build a standard mfw, using this version? For latest FWs.

It would be awesome, thank you.

I been reading your posts asking for help with this, and honestly i cant help you, but i think i can help clarifying some of your doubts, the problem is everyone of the patches included in MFW is written in a language named TLC and are an individual "task", some of them are "broken" because was intended to work in old firmware versions and since that files was updated by sony in newer firmwares the "patch" doesnt works properly with the new files. If you apply that patch the file is going to be broken and when you install the firmware it could result in a software brick

There are 2 solutions posible to fix MFW... either to update the patches (it needs to be made by someone experienced in TLC, with a flasher, and with some spare time to test all them).... or label them as "broken" temporally or remove them (until someone fixes them properlly)
I dont know which patches are broken so i cant tell which ones are safe to use and which ones doesnt
In few words... MFW is not safe, because it allows to apply patches that are broken

 

[haxxxen]

tbh, back then I have made the mod version mostly for modding existing "flavoured" cfws and not making own mfws.

I have planned to make an update to it, by adding all standard cex patches converted to dex, so you can make your own dex mfw, but still I had no time for this because lack of time and too much other ps3 stuff I have to do. soon I will have lot of time again, so maybe I can also cover an update to my mfwbuilder mod

I have to admit, the current state the tasks are, are not very noob friendly or confusing, but that wasn't my intention in first place and I am a lazy bum

 

[sandungas]

tbh, back then I have made the mod version mostly for modding existing "flavoured" cfws and not making own mfws.

I have planned to make an update to it, by adding all standard cex patches converted to dex, so you can make your own dex mfw, but still I had no time for this because lack of time and too much other ps3 stuff I have to do. soon I will have lot of time again, so maybe I can also cover an update to my mfwbuilder mod

I have to admit, the current state the tasks are, are not very noob friendly or confusing, but that wasn't my intention in first place and I am a lazy bum

Dont take what i said as a critic, i appreciate a lot what you and toolboy did trying to mantain the project alive and improve it, is just i want to advise people that some conbination of tasks could result in a brick

Many time ago the only available version of MFW was completly safe (his initial versions), and that was probably the most awesome feature of it because it allowed many "newcomers" to the PS3 scene to create his firmwares easilly installable and safe
One of the reasons why that initial versions was so safe is because the collection of tasks was very limited (so was reviewed and confirmed working many times by many people), also it was limited to a few firmware versions

Nowadays there is a list of small problems with the tool, but for the people not experienced with it (like me) is almost imposible to figure which features should be labeled as "dont touch this with a 10 feet pole".. and the others that are "safe"
In my oppinion fixing this problem could be the most useful change at this point, im not sure how to achieve it, probably there are several ways to do it (disabling problematic tasks, or listing them under "experimental", or adding a note next to them with warnings, dunno), but the goal would be to be able to talk about MFW as a "safe" tool

 

[haxxxen]

Dont take what i said as a critic

nah, no problem and besides, this tool is so powerful but also risky, so critics and suggestions for further improvements are very welcomed here. I can remember this damn lv0 curve_type brick problem which I wasn't aware of a long time even though I also have encountered brick problems, when I was doing dex ofw tests. only because of a stupid copy and paste mistake on my side. luckilly littlebalup has found the problem in the end without doing major or too much damage

everybody should be aware of when messing with the firmware itself, specifically coreos, there IS a definitive point of no return without proper precautions. that is also why I have added brick warnings to all coreos tasks, in hope these also get noticed

I wanted to make it "safe" and easy to use, but being a one click solution is most times not the best idea

edit
just want to add, back then it was quite disappointing how the scene was looking at this tool, when there was no point for (kakaroto hasn't earned this) and I think it got worse when this 4.xx change happened. to me this was the best tool ever made in ps3 scene. I wanted to let others change their minds by making it easier to use, but still it got disrespect by several users. though, this only does exactly the same a cfw developer does with decryption tools/hexeditor etc. it is just a bunch of automated scripts doing these exact same methods

 

[haxxxen]

update on github:
added decr tarball option and target prefix to pup file

this option about base firmware is important, cause it will decide which tarball version will be used for the modified pup

some afterwords, I've created this mod version in first place for modifying existing cfw versions and I didn't concentrate completely on mfw tasks. I will get this done sooner or later and test all the tasks myself

also decr/dex tasks will be added for mfw

 

[pinky]

update on github:
added decr tarball option and target prefix to pup file

this option about base firmware is important, cause it will decide which tarball version will be used for the modified pup

some afterwords, I've created this mod version in first place for modifying existing cfw versions and I didn't concentrate completely on mfw tasks. I will get this done sooner or later and test all the tasks myself

also decr/dex tasks will be added for mfw

yes, I've made a few nobt and nobd rebug mfw for a few people who had theirs broken. no issues to report.

 

[xanthefin]

Is there still problems with the "I get brick if using self_rebuilder/iso_rebuilder options to resign selfs" still?

As when i first tried build with modifying the famous emer_init.self.elf to another hdd size for linux what it was by now i got with those settings a slightly smaller .PUP than originally so i went ahead (due being highly suspicious why so) and did as littlebalup suggested in github as issues section. Then i got same size as original. But it corrupted my recovery. Couldn't boot at it. Works otherwise.

Missing of signing?

What was my mistake? Yes it is DEX Rebug 4.81.2.

Edit:

212 357 058 bytes (original)
212 352 962 bytes

On WinXP machine doing all.

 

[haxxxen]

hm, I can only tell you, that I have patched emer_init myself on a Rebug 4.21 version in past, which was working as expected, with no problems whatsoever. I have to admit, I should do more testings with recent CFW versions, instead of relying only on 4.21

the real first problem, which was finally identified by littlebalup, was the problem of using wrong curve type for lv0 (must have copied the wrong file for 4.21+ keys and also because of too less tests). the other only problem I have noticed, was, using lv0tool and iso_rebuilder, which do not work together fine. I always got errors about too big filesizes with it and bricked my Tool in the end

I will definately take a look at this and make another OtherOS++ test PUP, to see if there are problems

besides this, self_- and iso_rebuilder should work fine to sign every other .ELF file, but for now, I just recommend to use scetool, which is safe to use

 

[xanthefin]

hm, I can only tell you, that I have patched emer_init myself on a Rebug 4.21 version in past, which was working as expected, with no problems whatsoever. I have to admit, I should do more testings with recent CFW versions, instead of relying only on 4.21

the real first problem, which was finally identified by littlebalup, was the problem of using wrong curve type for lv0 (must have copied the wrong file for 4.21+ keys and also because of too less tests). the other only problem I have noticed, was, using lv0tool and iso_rebuilder, which do not work together fine. I always got errors about too big filesizes with it and bricked my Tool in the end

I will definately take a look at this and make another OtherOS++ test PUP, to see if there are problems

besides this, self_- and iso_rebuilder should work fine to sign every other .ELF file, but for now, I just recommend to use scetool, which is safe to use

Thank you for all and of the progression of the tools for us mortal people.

to fix an already modified mfw/cfw, you have to choose "replace_devflash_manual" task, "replace_devflash3_manual" task and "add folder" task. on replace_devflash_manual task you have to add from every devflash pkg a single file 001-XXX and when script is running, just press ok without any doings. same with replace_devflash3_manual task. just leave it and press ok when script asks for. on add_folder task leave box empty and the script will do its magic

Is this standing or not related to my problem i guess..?


I noticed if i use just sign isolated modules with iso_rebuilder i get once again same size .PUP but not exactly sure how stay on safe side with scetools only (yet). If it is that quick fix what i did and unticket those options then my recovery stays broken i guess.

P.S. tried with 4.82.2 DEX REBUG and same situation it becomes smaller size .PUP.
Gonna learn more about this scetool before trying out more.
-With the default options left on (Sign isolated module(s) with iso_rebuilder / Sign self/sprx(s) with self_rebuilder)

 

[haxxxen]

Thank you for all and of the progression of the tools for us mortal people.

thanks for headup and positive feelings. very appreciated

Is this standing or not related to my problem i guess..?

this post belonged to tarballs only afaik, which should not really make a difference. don't know anymore if there were problems with it, but if so, you only will get "Data corrupted" message without any installation

noticed if i use just sign isolated modules with iso_rebuilder i get once again same size .PUP but not exactly sure how stay on safe side with scetools only (yet). If it is that quick fix what i did and unticket those options then my recovery stays broken i guess.

the thing is, the f0f rebuilders only do replace the elf and change signatures, maintaining the original filesize, where scetool completely resign and recompress the elf files, even using template option. nobody has ever found the right (zlib?) algorithm, which was used by s0ny. I am a person, who wants to stay as "official" as possible, so having same filesize on the self files suits well to me.

P.S. tried with 4.82.2 DEX REBUG and same situation it becomes smaller size .PUP. Should i be worried or try it out?
-With the default options left on (Sign isolated module(s) with iso_rebuilder / Sign self/sprx(s) with self_rebuilder)

the resulting update file will always differ in size, but this is only problem of the custom compression ratio on tarballs/pkgs, at least when using the rebuilders. the resigned self files themselves will always have exact same size like original, unlike using scetool

erm wait, I think I know your problem now. using recent Rebug CFW, you cannot use the rebuilders on the elf files, cause Joonie already has compressed them with scetool, at least on CoreOS, to save space there. there you HAVE to use scetool, unlike on devflash files, which should be all original filesize. you have to verify this yourself first, before using a rebuilder, cause it will break the resulting signed file then

 

[xanthefin]

Thank you for infos(s) i will triple check before trying again with new setup and try do adjustments what i may find.

 

[xanthefin]

Hi i just put notice something if you can say better.


With scetool comparing my original and MFWBuild with as scetool only which i used to flash back to my PS3 earlier when recovery didn't work anymore.

Auth-ID -> changes to completely dfferent from original [emer_init] to some random hex like 0x000... (does this phenomenon break my recovery?)
Control Info: Digest 2 -> changes

 

[haxxxen]

Auth-ID -> changes to completely dfferent from original [emer_init] to some random hex like 0x000... (does this phenomenon break my recovery?)
Control Info: Digest 2 -> changes

well, I have made a test now on 4.81.2 and noticed, there are indeed some changes on resulting self file, when using scetool. if at all, I think the problem lies within the encrypted metadata sections

[*] Metadata Section Headers:
 Idx Offset   Size     Type Index Hashed SHA1 Encrypted Key IV Compressed
 000 00000780 000593BA 02   00    [YES]  00   [YES]     06  07 [YES]
 001 00059B40 0002B5A2 02   01    [YES]  08   [YES]     0E  0F [YES]
 002 000850F0 00000000 02   02    [YES]  10   [YES]     16  17 [NO ]
 003 000850F0 000005C0 01   04    [YES]  18   [NO ]     --  -- [NO ]

vs.

[*] Metadata Section Headers:
 Idx Offset   Size     Type Index Hashed SHA1 Encrypted Key IV Compressed
 000 00000A00 000593B9 02   00    [YES]  00   [YES]     06  07 [YES]
 001 00059DC0 0002B5A2 02   01    [YES]  08   [YES]     0E  0F [YES]
 002 00085370 00000000 02   02    [YES]  10   [YES]     16  17 [NO ]
 003 00085370 00000000 02   03    [YES]  18   [YES]     1E  1F [NO ]
 004 00085370 00000000 02   04    [YES]  20   [YES]     26  27 [NO ]
 005 00085370 00000000 02   05    [YES]  28   [YES]     2E  2F [NO ]
 006 00085370 00000000 02   06    [YES]  30   [YES]     36  37 [NO ]
 007 00085370 000005C0 01   08    [YES]  38   [NO ]     --  -- [NO ]

anyways, using a rebuilder is like you use template on scetool, so I will change scetool routine, to support template option, which is most safe option on any type of self

tbh, I am only using rebuilders on 4.21, cause there are only a few files compressed

btw, if you do not own a flasher and still doing coreos modifications, you are very brave or should I say careless? I do not want to make any promisses for 100% safety on coresos tasks, cause it is way too critical and there can always happen some unforseen problem

 

[xanthefin]

Ah okay i will look more still on those as i didn't yet fully master scetool and thank you. Looking forward.

I don't have hw flasher as i just today put an order of one. I was and i am ready to go full failure.. thats how we learn anyway. No harm to you and i know its not about your fault. I am the fool one. Like how well people made SYSCON access on these. I wouldn't have ever learned that even being there without getting first locked out of PS3 due Recovery Mode Flag while Recovery was corrupted/broken. I was actually happy to learn SYSCON chip and its memory after all.

P.S. I knew i had NOR backup anyway done in safe place before i started all. I knew i was gonna order HW flasher later even if it first time would have completely went bad so i would wait it and recover from failure. I was just too curious still already to try and i tried to do all i can to avoid it like checking what issues may arise and avoid them.


Edit: I made manually update *.PUP via tools unpacking and repacking all down to emer_init but recovery stays broken.

Edit2: Now got scetool template function work after recompiling scetool by itself on macos and winxp with compression level option too. Github has many broken ones and easily break program logic by incorrectly give options. Getting now exactly as should be file. Lets see..

Edit3: pkgtool has funny way corrupt its own .exe if you give it wrong -in path with surprise new line character in middle.

Edit4: Yehey! Now modified recovery boots! And i accomplished what i was looking for too.

 

[haxxxen]

P.S. I knew i had NOR backup anyway done in safe place before i started all. I knew i was gonna order HW flasher later even if it first time would have completely went bad so i would wait it and recover from failure. I was just too curious still already to try and i tried to do all i can to avoid it like checking what issues may arise and avoid them.

good to know, cause I really don't want to let someone brick a console with mfwbuilder. your luck it is 'just' emer_init, cause this won't break bootprocess

Edit: I made manually update *.PUP via tools unpacking and repacking all down to emer_init but recovery stays broken.

Edit2: Now got scetool template function work after recompiling scetool by itself on macos and winxp with compression level option too. Github has many broken ones and easily break program logic by incorrectly give options. Getting now exactly as should be file. Lets see..

Edit3: pkgtool has funny way corrupt its own .exe if you give it wrong -in path with surprise new line character in middle.

Edit4: Yehey! Now modified recovery boots!

does this scetool version of mine not work for you? I have compiled it myself with custom zlib compression level and also custom key path. most of the other exe tools I also have compiled newly with some additions to be easier handled by mfwbuilder

anyways, I have added template option now on mfwbuilder, so now the resulting self's should match original's even more, except the compression ratio. though, before I will upload it on my github, I will make extensive tests myself now, just to be sure everything is fine. (only if someone is interested, I can send privately the changes, cause I dunno how long this will take until I can upload)

 

[pinky]

I've never had issues using this really (made a few no bd/no bt firmwares for others using it), but I've never tried a full fledged mfw. I always modified a cfw like rebug or something.

 

[haxxxen]

I've never had issues using this really (made a few no bd/no bt firmwares for others using it), but I've never tried a full fledged mfw. I always modified a cfw like rebug or something.

and this is also what I always had done and made this mod, to mod existing CFW's, which are (or should be) save to use. tbh, I have felt much safer with 3.55- using this tool, to make an own full blown MFW

 

[pinky]

and this is also what I always had done and made this mod, to mod existing CFW's, which are (or should be) save to use. tbh, I have felt much safer with 3.55- using this tool, to make an own full blown MFW

I think it's probably safe, but I don't know since I've never tried making a full mfw. it may be what people were using when those fake devs were making all those cfws way back then. I wouldn't make a full mfw unless I had an e3 on hand or something, just in case. though, that is true even if doing it by hand. we're all human after all and can make mistakes somewhere.

 

[xanthefin]

good to know, cause I really don't want to let someone brick a console with mfwbuilder. your luck it is 'just' emer_init, cause this won't break bootprocess



does this scetool version of mine not work for you? I have compiled it myself with custom zlib compression level and also custom key path. most of the other exe tools I also have compiled newly with some additions to be easier handled by mfwbuilder

anyways, I have added template option now on mfwbuilder, so now the resulting self's should match original's even more, except the compression ratio. though, before I will upload it on my github, I will make extensive tests myself now, just to be sure everything is fine. (only if someone is interested, I can send privately the changes, cause I dunno how long this will take until I can upload)

You have good heart. I appreciate.

I did now test what mfw comes with and don't worry it looks like works fine on mine end.

And as it gets with scetool template i would feel safe to use it with 4.8x easily (just so user is notified correct way use scetool only template method example on 4.81 REBUG).


Big problem was to me with scetool that it has no any protection like you can write options incorrectly it will either work partially or just crash with no any error message which would make sense to user. If i can say thats bad design should be fixed (i mean if user manually uses it but not necessary for with mfw tool required any such thing).
I only got fully hold of it when playing with sources of scetool and diagnosing what is happening in code i then did catch finally all how to write all options correctly in there. Am i lazy to read help print of scetool? i don't know...

There is been some examples going around like people writing --sce-type=SELF.. but on my case if i put -0=SELF it got that = -symbol in there corrupting the option input. User error? Most likely. Correct was on that -0 SELF.


Anyway i reached my goal and learned again lot. Thank you again

"Forum Noob" report ends.

 

[xanthefin]

Hi again


Is OtherOS coldboot patch working only up to certain firmware level?

I manually put it in and one another patch but this patch did not create effect i waited for like what Glevend reported on him.. should i include some other patches make it work correctly?

By his explanation can boot up to OtherOS++ bootloader directly via power button but it was a miss for me.

Maybe i am missing some?