Make a backup of your existing dev_flash on your PS3 via FTP, or use MultiMan's file manager to copy it to a flash drive and dump the contents on your computer. This will give you a point of reference to explore. Figure out which files you want to modify/delete, and make a text file on your computer with a list in unix format (which MFM builder uses). For example, if you wanted to change your coldboot files:
On your Windows machine, your dev_flash export from your PS3 might look like: "C:\PS3 Dump\dev_flash\vsh\resource\coldboot.raf". In your text file, you would type out: dev_flash/vsh/resource/coldboot.raf
Continue to add items to this text file of everything you plan on changing, with a return after each item in a neat list. Save the text file when you have completed the list of items. Copy the entire text file contents to the clipboard, and open up MFW builder. Find the option in the task list "change a specific file manually", and paste the contents of your text file in the configure box. Disable the other tasks as needed. Process your base PUP, and MFM will pause at each item on your list prompting you to change the file it extracted to the temp location. Simply delete the file from the temp output, and it won't be repacked into the firmware.
Now, understanding this next part will save you a lot of time. The PS3 PUP pack is broken up into micro pkg blocks, sized specifically for the block pattern of the PS3 NAND, if you're lucky enough to have one of the original consoles before they switched to the cheaper NOR flash. MFM builder is programmed to check for an existing destination file in the temp folder first, before trying to extract the file from one of the PKG's. If it exists already, it won't extract it because it assumes that micro block has already been extracted, and any files changed before it would be overwritten. The pkg extraction tool cannot extract one specific file by itself. It can only extract that entire block section at once. This functionality will provide some time saving for you.
As I mentioned before, the pkg tool will fail if the temp folder is open when you resume the script (pressing "ok"). This means, you'll be repeatedly opening and closing the temp folder for every file change; however if you navigate to the temp to change the file, and notice in the same folder another file you wanted to change there also, you can modified that file at the same time since it came from the same micro block. Then when you resume the script, and MFM builder prompts for that next file to be modified, since it wasn't overwritten (as it already existed in temp), your changes are still intact, and you can safely press "ok" to move on to the next file. This will save a lot of time opening and closing your temp. (This is the long and boring way of doing this. Running linux as a virtual machine, and using the failoverflow tools through bash is MUCH faster, but I'm not going to detail that.)
To add a file to the firmware, simply reference another already existing file in the block/location you want to add it, paste it into the temp folder along side it. For example, I was mentioning you can add the new Rebug selector quite easily.
In MFM builder, list:
1.5 exists already in the PUP. It will be extracted to the temp. Navigate to the temp folder, and in the same operation delete 1.5 from the temp and paste in 1.6
Resume the script, and having detected 1.6 existing in the temp already, it will prompt to change without error (despite the fact it doesn't exist in the original PUP).
The pkg tool just repacks that temp folder verbatim as that block.
Your line of questioning though, is *not* very confidence inspiring, and you are just asking to brick your PS3 beyond repair if you monkey around too much. If you damage the files that control the recovery menu, you are dead in the water.
I've broken my PS3 boot a few times, by injecting files in a block it had no business being in, but safely restored it through a clean system update from recovery mode. I'll have to write out a guide sometime on how to add new blocks to the tail end of the NAND, and explain how the mapping table works. I haven't looked into which files fill the 16 megs of the NOR version though yet.
wmxp your are the greatest, this tut saves me alot of time and thank you for your time to explain.:dance: