• PS3HEN is now supporting 4.93 Firmware

    View Official Release Post for additional information HERE

PS3HEN PS3HEN Open Beta Testing [For Advanced Users Only]

aldostools said:
Yes, the modifications I made were for qCFW. You have 2 options:
a) 2 versions of HEN (normal & modchip)
b) Store in a variable if modchip was detected. Add a condition to use these changes only if the modchip was found.
Click to expand...

qCFW doesn't use hen, it use cobra fork (https://github.com/aomsin2526/Cobra-PS3-qCFW). it is whole custom coreos with evilnat lv2.

But WDSD in ofw mode still use hen, for those who don't want to use qCFW because of risk and more complex install process but still want lv1 stuff (oc/otheros). And for qCFW install (it will be done by xai_plugin of hen that requires lv1 patch for software bank switching).
 
aomsin2526 said:
qCFW doesn't use hen, it use cobra fork (https://github.com/aomsin2526/Cobra-PS3-qCFW). it is whole custom coreos with evilnat lv2.

But WDSD in ofw mode still use hen, for those who don't want to use qCFW because of risk and more complex install process but still want lv1 stuff (oc/otheros). And for qCFW install (it will be done by xai_plugin of hen that requires lv1 patch for software bank switching).
Click to expand...
Awesome, I have a Super Slim ready to experiment with.
 
So the periodic lv2 memory validation, do we know how that works? I wasn't able to find it documented on the wiki. Curious to know if WDSD can overcome it with a hv patch or it happens off in the loaders and any lv2 patches will need to be reverted like with hen.
 
fdm said:
So the periodic lv2 memory validation, do we know how that works? I wasn't able to find it documented on the wiki. Curious to know if WDSD can overcome it with a hv patch or it happens off in the loaders and any lv2 patches will need to be reverted like with hen.
Click to expand...

It can. See: https://github.com/aomsin2526/BadWDSD/blob/wip/BadWDSD-Stage/Stage5.c

Code: 
        uint64_t *lv1_lv2AreaAddrPtr = (uint64_t *)0x370F20;
        uint64_t *lv1_lv2AreaSizePtr = (uint64_t *)0x370F28;

        *lv1_lv2AreaAddrPtr = 0x8000000000000000; // 0x8000000000000000
        *lv1_lv2AreaSizePtr = 16;

        //Sc_Rx: after_lv1_lv2AreaHash[0] = 0xfa60f9a679d561e2
        //Sc_Rx: after_lv1_lv2AreaHash[1] = 0x4766aa39b90084b0
        //Sc_Rx: after_lv1_lv2AreaHash[2] = 0xb27d2ff00000000

        uint64_t *lv1_lv2AreaHashPtr = (uint64_t *)0x370F30;

        lv1_lv2AreaHashPtr[0] = 0xfa60f9a679d561e2;
        lv1_lv2AreaHashPtr[1] = 0x4766aa39b90084b0;
        lv1_lv2AreaHashPtr[2] = 0x0b27d2ff00000000;

As long as first 16 bytes of lv2 is 0. It will work. HEN can use this patch too, but for now only qCFW use them (to load evilnat lv2 + cobra).
 
aomsin2526 said:
qCFW doesn't use hen, it use cobra fork (https://github.com/aomsin2526/Cobra-PS3-qCFW). it is whole custom coreos with evilnat lv2.

But WDSD in ofw mode still use hen, for those who don't want to use qCFW because of risk and more complex install process but still want lv1 stuff (oc/otheros). And for qCFW install (it will be done by xai_plugin of hen that requires lv1 patch for software bank switching).
Click to expand...

Thank you for the clarification. I confused the terms. I meant badWDSD.

@esc0rtd3w Maybe it would be better to leave HEN as it originally was and revert the proposed changes about using lv1 peek/poke.
 
Well.. you can make one but I am unsure if the PS3 will read it using Evilnat's tool to rebuild the PUP PUAD GUI which I think the original maker/maintainer in the past passed it on to him from @DeViL303
All you need is to repack the update files tar with your core os I think...
 
aomsin2526 said:
There won't be PUP. You still can't install custom pup. But qCFW CoreOS will be flashed directly to nor and required files will be copied directly to dev_flash. This will be done through xai_plugin of HEN.
Click to expand...
Does this mean we only need a HW flasher? Also how do we pack it inside a NOR just by using the tool from littlebalup's repo? or is there a different recommendation for that. EDIT: Nvm I read you said xai plugin sorry.
 
Last edited:
aomsin2526 said:
There won't be PUP. You still can't install custom pup. But qCFW CoreOS will be flashed directly to nor and required files will be copied directly to dev_flash. This will be done through xai_plugin of HEN.
Click to expand...
I think I'm starting to get it, qcfwgen_lv2xxxx.sh will create CoreOS.bin, what's the difference between:
qcfwgen_lv2diff.sh,
qcfwgen_lv2self.sh, and
qcfwgen_lv2zfself.sh?
 
Louis Garry said:
I think I'm starting to get it, qcfwgen_lv2xxxx.sh will create CoreOS.bin, what's the difference between:
qcfwgen_lv2diff.sh,
qcfwgen_lv2self.sh, and
qcfwgen_lv2zfself.sh?
Click to expand...

It's how custom lv2 kernel are loaded. qcfwgen_lv2zfself.sh should always be used.

CoreOS space are very tight, and load self directly is very slow due to aes decryption.

And if load decrypted/decompressed as is will be too large to fit inside coreos. So it needs compression. zfself = fself + zlib
 
Okay so for those who don't know though you need to dump your NOR from HEN on a 3.6+ model extract the flash and package your CoreOS from either ros0 or ros1 through flow's tools then you drag and drop it into the dir alongside your decrypted lv1, lv2, lv0. (using the latest Scetool that supports decrypting which I recommend the beta branch) then once those are there simply just drag and drop @Evilnat CEX ROS into it and then rebuild it once your CoreOS is ready you transfer to a PS3 for software flashing if I am correct? it's also recommended to have HW flasher though as it is WIP. ensuring you have the entire ps3toolchain built and the requirements mentioned by zecoxao.
 
RoboKing's Cosmos said:
Okay so for those who don't know though you need to dump your NOR from HEN on a 3.6+ model extract the flash and package your CoreOS from either ros0 or ros1 through flow's tools then you drag and drop it into the dir alongside your decrypted lv1, lv2, lv0. (using the latest Scetool that supports decrypting which I recommend the beta branch) then once those are there simply just drag and drop @Evilnat CEX ROS into it and then rebuild it once your CoreOS is ready you transfer to a PS3 for software flashing if I am correct? it's also recommended to have HW flasher though as it is WIP. ensuring you have the entire ps3toolchain built and the requirements mentioned by zecoxao.
Click to expand...

No you don't, CFW won't work here. qCFW is a new variant of CFW just for this. It is own thing, while using evilnat lv2 and cobra fork to make it work properly. There will be some limitation such as no vsh modules (self/sprx) modding and no custom ps1 emu. Not a big loss because everything else work fine.

You are close but wrong on "Evilnat CEX ROS" part. You don't do this, instead you only use evilnat lv2 here. Not anything else. base ros is OFW.

You can also extract ros from CORE_OS_PACKAGE.pkg. Not just from flash dump.
 
aomsin2526 said:
No you don't, CFW won't work here. qCFW is a new variant of CFW just for this. It is own thing, while using evilnat lv2 and cobra fork to make it work properly. There will be some limitation such as no vsh modules (self/sprx) modding and no custom ps1 emu. Not a big loss because everything else work fine.

You are close but wrong on "Evilnat CEX ROS" part. You don't do this, instead you only use evilnat lv2 here. Not anything else. base ros is OFW.

You can also extract ros from CORE_OS_PACKAGE.pkg. Not just from flash dump.
Click to expand...
Thanks my bad, so you just grab an lv2 from either the PUP or the Cobra repo
So if QA Flagged can you also downgrade to maybe Rebug (without the possibility of converting to DEX of course till ERK pwnage of metldr.2)
 
aomsin2526 said:
Yes, to be accurate, from my repo.
Click to expand...
could there be an update to the toolbox and perhaps the Rebug itself that from the one you forked. the lowest supported is 4.84 for that 8.3 cobra and needs a little cleaning till an ERK does come out if ever to fix all the lv2 for each version? I know sounds like a lot but would be interesting yeah.
 
I'll chime in just about the xai plugin part.

It is still in progress. It was originally using hen xai as base, which is based on old source from mysis. I was having problems with malloc and a few other things.

I have now forked nats xai as base to test with, since its codebase is much more current.

Hopefully should have it working this week. I am testing in between IRL stuff.
 
i see few post before... but now we can set rsx/cpu clock without flash all cfw? im talking about 3.55 console with cfw
 
You must log in or register to reply here.

Similar threads

Back
Top