PS3 HEN Flash Patcher (development discussion)

[kostirez1]

The two possible approaches therefore are:

Block = 128 KiB, 256 sectors of 512 bytes, minimum size that can be physically erased
Speed to write 1x 256 KiB block (2x 128 KiB blocks) is ~2 seconds. Time to write a single 128 KiB block may or may not take ~1 second.

"DualBoot" approach - replace existing files in flash, no modifications to the file list:

Location	Offset start	Offset end	Block start	Block end	Block count
spu_pkg_rvk_verifier.self	0x0404C8	0x04F7E7	0x040000	0x05FFFF	1
lv0	0x1EE200	0x2B642F	0x1E0000	0x2BFFFF	7

[THEAD] [/THEAD]

Pros: less blocks written (1 block saved), already tested approach
Cons: in case of a power failure => brick
Expected speed: 8 seconds, 8 of them critical

"Low risk" approach - put the two files at the end of the region, modify file list at the end:

Location	Offset start	Offset end	Block start	Block end	Block count
File list	0x000000	0x0004AF	0x000000	0x01FFFF	1
spu_pkg_rvk_verifier.self	0x5A0000	0x5AF31F	0x5A0000	0x5BFFFF	1
lv0	0x5AF320	0x67754F	0x5A0000	0x680000	7 new (+1 shared)

[THEAD] [/THEAD]

Pros: a power failure is tolerated if it happens during writes into the unreferenced area (a brick can still occur while updating the file list - although we need only ~1247 bytes of this block, the rest is ignored)
Cons: more blocks written (1 additional for the file list), currently not tested
Expected speed: 9 seconds, 1 of them critical


Offsets are from nofsm_patch_489.bin, they will be a little bit off in the physical flash (up to +0x30?), since noFSM patches don't contain CoreOS headers

 

[aldostools]

To be honest, I prefer the 2nd approach (if it is feasible). It reduces the dangerous window from 8 seconds to 1.
The cost of 1 additional second is irrelevant compared to the benefit of the safety.

The current patching methods that overwrite the ROS have a longer period of high risk (>1 minute).

I should add that the "Low risk" method is a very clever approach

EDIT:
If you write lv0 + spu_pkg_rvk_verifier.self as a single block (5A0000-677550), you will write only 7 blocks of 128KB (5A0000-680000) + 1 block for filelist. Therefore the cost would be the same for both approaches.

EDIT2:
I think that it is better to write from 600000 to 6E0000-1 instead of 5A0000 to 680000-1.

 

[RoboKing's Cosmos]

Can you give the HEN flasher a skull crossbones icon? & disable exiting to XMB during flash

 

[aldostools]

Can you give the HEN flasher a skull crossbones icon? & disable exiting to XMB during flash

Why do you need a skull crossbones icon? The process is being designed to be safe.

To disable exit to XMB, if I recall correctly it can be done with this command:

sysUtilRegisterCallback(SYSUTIL_EVENT_SLOT0, sys_callback, NULL);

static void sys_callback(uint64_t status, uint64_t param, void* userdata) {

     switch (status)
     {
       case SYSUTIL_EXIT_GAME:
            if(!is_flashing) sysProcessExit(1);
            break;

       default:
            break;
     }
}

 

[kostirez1]

EDIT:
If you write lv0 + spu_pkg_rvk_verifier.self as a single block (5A0000-677550), you will write only 7 blocks of 128KB (5A0000-680000) + 1 block for filelist. Therefore the cost would be the same for both approaches.

EDIT2:
I think that it is better to write from 600000 to 6E0000-1 instead of 5A0000 to 680000-1.

You are right, I forgot to take into account the differences of file sizes in OFW/HFW/DB/Evilnat CoreOSes.

File name	OFW/HFW/DB	Evilnat
spu_pkg_rvk_verifier.self	64 332 bytes	62 240 bytes
lv0	947 712 bytes	819 760 bytes
Total bytes	1 012 044 bytes	882 000 bytes
128 KiB blocks	8 (1 048 576 bytes)	7 (917 504 bytes)

[THEAD] [/THEAD]

I modified the 4.89 CoreOS to include the "Low Risk" patch: https://www67.zippyshare.com/v/CeN9gAEm/file.html (WARNING: Confirmed to cause a brick!)

--- 0x001000 of 0x00 to allow for movement/relocation in physical flash ---
lv0 begins at 0x601000, ends at 0x6E85FF
--- 0x10 of 0x00 as a spacer ---
spu_pkg_rvk_verifier.self begins at 0x6E8610, ends at 0x6F815B

Edit:
The patched files included are from 4.89 Dual boot firmware by @littlebalup .

 

[littlebalup]

In this post from Jan 22, 2016, @playerkp420 confirms that only these 2 files are needed for CFW:
"I have made a DB OFW, that should be better for making coreos patch. The file size is exactly the same as OFW. Even if you unpack it, lv0 and spu_pkg_rvk_verifier.self, they are the same size. (The only 2 files that are patched to allow reinstall of CFW)"

Indeed the software flasher basically needs to replace only these 2 files to allow CFW installation.
Therefore <1MB should be enough to achieve it. 2MB for both ROS regions (~15-20 seconds in theory).

lv0 has bootldr, appldr.self, isoldr.self, lv2ldr.self and .2 headers and spu_pkg_rvk_verifier.self needs to be patched to disable ecdsa protections (based on this post by @littlebalup).

Hi, this is true only if the update is done via a PUP. To patch CoreOS using a flasher you also need lv1 patches to disable syscon hash check. Otherwise you'll brick.
https://github.com/haxxxen/ps3mfw-b...1afb020c0bf6c6476/tasks/02_patch_cos.tcl#L271

 

[RoboKing's Cosmos]

Why do you need a skull crossbones icon? The process is being designed to be safe.

I thought it needed something a little pirate looking considering the song the flasher uses. Otherwise maybe a black flag?

 

[aldostools]

Hi, this is true only if the update is done via a PUP. To patch CoreOS using a flasher you also need lv1 patches to disable syscon hash check. Otherwise you'll brick.
https://github.com/haxxxen/ps3mfw-b...1afb020c0bf6c6476/tasks/02_patch_cos.tcl#L271

I wonder how @kostirez1 managed to flash successfully CoreOS from HEN without these lv1 patches? Could HEN have that patch already applied?

To me the new low risk approach is like the original method that overwrites the full ROS regions.

Both change the hashes, unless there are some bytes included in nofsm patch that force to match the hashes. Is this the case?

 

[kostirez1]

I wonder how @kostirez1 managed to flash successfully CoreOS from HEN without these lv1 patches? Could HEN have that patch already applied?

Because what I wrote was the full noFSM CoreOS based on the Evilnat firmware, that includes lv0, lv1, lv2, spu_* and spp_* patches. This is presumably also what broke the HEN enabler.

I wonder how @kostirez1 managed to flash successfully
To me the new low risk approach is like the original method that overwrites the full ROS regions.

Almost, except that it does not include the lv1 patch that disables the CoreOS hash re-validation later (when?) in the boot chain (where?).

I'm a little bit worried about the "Patch LV1 to disable CoreOS Hash check. Product mode always on (downgrader)", which sounds like it has no role for HFW -> CFW on the same FW version, but I can't tell for sure.

Foreshadowing...

Both change the hashes, unless there are some bytes included in nofsm patch that force to match the hashes. Is this the case?

What I'm assuming is that this has something to do with the hashes stored somewhere in the Syscon EEPROM, that prevent you from downgrading, or maybe changing the CoreOS contents at all. It makes sense that we can at least partially disable that check on old metldr based models, as opposed to metldr.2, where it's impossible. So not even downgrade to an older OFW is possible.

 

[GuilloteTesla]

What I'm assuming is that this has something to do with the hashes stored somewhere in the Syscon EEPROM, that prevent you from downgrading, or maybe changing the CoreOS contents at all. It makes sense that we can at least partially disable that check on old metldr based models, as opposed to metldr.2, where it's impossible. So not even downgrade to an older OFW is possible.

Indeed, the hashes are used for integrity checks. As long as the hashes match and the data is still consistent, for the PS3 everything should be OK.

Regarding downgrade, the way was always using the QA Flags as those are the official way implemented by Sony. Since the official token was leaked, there was no need to reverse engineer the downgrade process.

But with the introduction of metldr.2, the QA Flags token was also changed.

 

[kostirez1]

@aldostools
Even after patching the lv1.self, it doesn't look that bad.

I hope that my settings in MFW Builder are right:


Replacing lv1.self in-place resulted into the following comparison:

Spoiler: Block level comparison

Block 0 is modified [unsafe]
Block 1 is the same
Block 2 is the same
Block 3 is the same
Block 4 is the same
Block 5 is the same
Block 6 is the same
Block 7 is modified [unsafe]
Block 8 is the same
Block 9 is the same
Block 10 is the same
Block 11 is the same
Block 12 is the same
Block 13 is the same
Block 14 is modified [unsafe]
Block 15 is modified [unsafe]
Block 16 is modified [unsafe]
Block 17 is the same
Block 18 is the same
Block 19 is the same
Block 20 is the same
Block 21 is the same
Block 22 is the same
Block 23 is the same
Block 24 is the same
Block 25 is the same
Block 26 is the same
Block 27 is the same
Block 28 is the same
Block 29 is the same
Block 30 is the same
Block 31 is the same
Block 32 is the same
Block 33 is the same
Block 34 is the same
Block 35 is the same
Block 36 is the same
Block 37 is the same
Block 38 is the same
Block 39 is the same
Block 40 is the same
Block 41 is the same
Block 42 is the same
Block 43 is the same
Block 44 is the same
Block 45 is the same
Block 46 is the same
Block 47 is the same
Block 48 is modified [safe]
Block 49 is modified [safe]
Block 50 is modified [safe]
Block 51 is modified [safe]
Block 52 is modified [safe]
Block 53 is modified [safe]
Block 54 is modified [safe]
Block 55 is modified [safe]
Unsafe blocks: 5, safe blocks: 8

To be honest, 4 additional blocks aren't that bad considering that the file modified is 1 280 144 bytes. So most of it is untouched even after patching it.
Updated CoreOS files for "Low Risk" patch: https://www51.zippyshare.com/v/uSmEARmq/file.html


@RoboKing's Cosmos @Kazama @Md Hesam please keep the discussion here centered around PS3HEN based flashers and feedback / questions related to this particular HEN Flash Patcher. CFW for metldr.2 based consoles isn't something that this project aims to solve. Thank you.

 

[RoboKing's Cosmos]

@RoboKing's Cosmos @Kazama @Md Hesam please keep the discussion here centered around PS3HEN based flashers and feedback / questions related to this particular HEN Flash Patcher. CFW for metldr.2 based consoles isn't something that this project aims to solve. Thank you.

Okay

@aldostools
Even after patching the lv1.self, it doesn't look that bad.

I hope that my settings in MFW Builder are right:
View attachment 39342

Can I help out with MFW builder? I would like to convert the older firmware versions to CFW so that your flasher does support older firmware with cross compatibility. I maybe without an old PS3 to test but hope I can help.

 

[aldostools]

Can I help out with MFW builder? I would like to convert the older firmware versions to CFW so that your flasher does support older firmware with cross compatibility. I maybe without an old PS3 to test but hope I can help.

Help is always appreciated. However I don't think older firmware versions should be a priority at this point.

The focus currently is to make the flasher work properly and safely on HFW 4.89 on NOR and NAND.
Users with PS3 models CFW compatible and hardware flasher would be helpful for tests at current stage.

Support for older firmware versions is a secondary goal. Users on older FW can to update to HFW 4.89+HEN.

 

[RoboKing's Cosmos]

Help is always appreciated. However I don't think older firmware versions should be a priority at this point.

The focus currently is to make the flasher work properly and safely on HFW 4.89 on NOR and NAND.
Users with PS3 models CFW compatible and hardware flasher would be helpful for tests at current stage.

Support for older firmware versions is a secondary goal. Users on older FW can to update to HFW 4.89+HEN.

I have my hardware flasher but not a PS3 that is compatible with it.. just a super slim
Idk what my future could be now that my personal problems have gotten so bad recently

Help is always appreciated. However I don't think older firmware versions should be a priority at this point.
Support for older firmware versions is a secondary goal. Users on older FW can to update to HFW 4.89+HEN.

Ik that but what if some users wanted Rebug over HEN 4.84-4.86? So would the flash have to be altered differently than evilnat just for Rebug to be installed?

 

[kostirez1]

Ik that but what if some users wanted Rebug over HEN 4.84-4.86? So would the flash have to be altered differently than evilnat just for Rebug to be installed?

You will be always able to downgrade from 4.89+ CFW to an older one.

 

[RoboKing's Cosmos]

You will be always able to downgrade from 4.89+ CFW to an older one.

I've done that before tbh.. when I used to have my CECH L

 

[aldostools]

I have my hardware flasher but not a PS3 that is compatible with it.. just a super slim
Idk what my future could be now that my personal problems have gotten so bad recently

I hope you can solve your personal problems soon. Many of us here also have problems in different degrees.
Unfortunately you are not a good test candidate at this moment. Maybe if you get a cheap CFW model (fat or 20xx/21xx)

Ik that but what if some users wanted Rebug over HEN 4.84-4.86? So would the flash have to be altered differently than evilnat just for Rebug to be installed?

Once you have CFW 4.89, enable QA flags to upgrade/downgrade to any firmware version.

Evilnat 4.89.3 is going to be released soon anyway, so very few users will need to downgrade for DEX.

 

[Kazama]

@aldostools
Even after patching the lv1.self, it doesn't look that bad.

I hope that my settings in MFW Builder are right:
View attachment 39342

Replacing lv1.self in-place resulted into the following comparison:

Spoiler: Block level comparison

Block 0 is modified [unsafe]
Block 1 is the same
Block 2 is the same
Block 3 is the same
Block 4 is the same
Block 5 is the same
Block 6 is the same
Block 7 is modified [unsafe]
Block 8 is the same
Block 9 is the same
Block 10 is the same
Block 11 is the same
Block 12 is the same
Block 13 is the same
Block 14 is modified [unsafe]
Block 15 is modified [unsafe]
Block 16 is modified [unsafe]
Block 17 is the same
Block 18 is the same
Block 19 is the same
Block 20 is the same
Block 21 is the same
Block 22 is the same
Block 23 is the same
Block 24 is the same
Block 25 is the same
Block 26 is the same
Block 27 is the same
Block 28 is the same
Block 29 is the same
Block 30 is the same
Block 31 is the same
Block 32 is the same
Block 33 is the same
Block 34 is the same
Block 35 is the same
Block 36 is the same
Block 37 is the same
Block 38 is the same
Block 39 is the same
Block 40 is the same
Block 41 is the same
Block 42 is the same
Block 43 is the same
Block 44 is the same
Block 45 is the same
Block 46 is the same
Block 47 is the same
Block 48 is modified [safe]
Block 49 is modified [safe]
Block 50 is modified [safe]
Block 51 is modified [safe]
Block 52 is modified [safe]
Block 53 is modified [safe]
Block 54 is modified [safe]
Block 55 is modified [safe]
Unsafe blocks: 5, safe blocks: 8

To be honest, 4 additional blocks aren't that bad considering that the file modified is 1 280 144 bytes. So most of it is untouched even after patching it.
Updated CoreOS files for "Low Risk" patch: https://www51.zippyshare.com/v/uSmEARmq/file.html


@RoboKing's Cosmos @Kazama @Md Hesam please keep the discussion here centered around PS3HEN based flashers and feedback / questions related to this particular HEN Flash Patcher. CFW for metldr.2 based consoles isn't something that this project aims to solve. Thank you.

Okay. I would like to test this , i have CECH-2503A slim ps3 4.89CFW on it with minverchk 3.40 but i don't have hardware flasher. Can I check it ?

 

[aldostools]

Okay. I would like to test this , i have CECH-2503A slim ps3 4.89CFW on it with minverchk 3.40 but i don't have hardware flasher. Can I check it ?

You don't qualify because your console is already on CFW, and at this stage of development errors still could be found bricking the console if you don't have a hardware flasher to recover it.

 

[Chrooma]

Nice, this tool will be useful for all of us in the ps3 community, I have a doubt, when you enter this homebrew, does the usb stick need to be connected to the ps3 to be able to save nofsm_patch_489.bin?