PS3HEN PS3HEN Open Beta Testing [For Advanced Users Only]

[esc0rtd3w]

@esc0rtd3w Thank you for the update.
Now that you have added LV1 support to PS3HEN, I wanted to let you know that sycall 8 needs to be updated to support partial LV1 peek like Cobra, for proper compatibility with Cobra.

The following lines in main.c of Cobra need to be implemented in PS3HEN
https://github.com/aldostools/Cobra-PS3/blob/master/8.5/4.92/EVILNAT/PEX/SRC/stage2/main.c#L465-L466
https://github.com/aldostools/Cobra-PS3/blob/master/8.5/4.92/EVILNAT/PEX/SRC/stage2/main.c#L508-L510
https://github.com/aldostools/Cobra-PS3/blob/master/8.5/4.92/EVILNAT/PEX/SRC/stage2/main.c#L545-L552
https://github.com/aldostools/Cobra....92/EVILNAT/PEX/SRC/stage2/main.c#L1088-L1089

After consulting with @Joonie , we won't be adding the disable cobra or partial sc8 disable code, but these are the edits that are done.

Can you confirm the tmp_lv1peek should remain?

 

[aldostools]

After consulting with @Joonie , we won't be adding the disable cobra or partial sc8 disable code, but these are the edits that are done.

View attachment 45886

Can you confirm the tmp_lv1peek should remain?

The initial code was needed for dumping LV1 memory using syscall 8 (LV1 peek). If I recall correctly it was implemented before syscall 11 was added.

The most important part is this one:
https://github.com/aldostools/Cobra....92/EVILNAT/PEX/SRC/stage2/main.c#L1088-L1089

It performs a lv1_peek to the address that don't match with any of the previous addresses used as opcodes (most of them are intentionally unaligned values).

EDIT:
The code below is equivalent to the code above. It was added for better performance. It does not require to check all the opcodes to return lv1_peekd(function). It requires to first call the opcode SYSCALL8_OPCODE_DISABLE_COBRA to disable_cobra temporarily. The opcode SYSCALL8_OPCODE_ENABLE_COBRA is used to re-enable cobra.
https://github.com/aldostools/Cobra-PS3/blob/master/8.5/4.92/EVILNAT/PEX/SRC/stage2/main.c#L465-L466

 

[ashmodeo]

Tried 3.4.1 Open Beta Test 13 on a hfw 4.92 slim non compatible cfw model, i've tried one of the options to overclock rsx core and memory clock to 700 but it seems it is not working or making any change.

 

[GuilloteTesla]

Tried 3.4.1 Open Beta Test 13 on a hfw 4.92 slim non compatible cfw model, i've tried one of the options to overclock rsx core and memory clock to 700 but it seems it is not working or making any change.

You need to apply the BadHTAB exploit first: https://www.psx-place.com/threads/p...advanced-users-only.37363/page-11#post-411388

 

[esc0rtd3w]

3.4.1 Open Beta Test #14 (05-18-2025): (4.80 - 4.92 CEX / 4.82 & 4.84 DEX)

New Changes:

- Added support and config options for BadWDSD (thanks to @aomsin2526 )
- Added detection of BadWDSD to HEN Plugin to check for LV1 elevated privileges on HEN enable
- Added support for using tmp_lv1peek and PS3MAPI LV1 PEEK/POKE for compatibility with WMM (thanks @aldostools )


Older Changes:

- Added minimal support for BadHTAB LV1 Exploit
- Enabled LV1 Peek(11)/Poke(9) in PS3HEN payload (will change in the future to be toggled)
- Added options to HFW Tools (xai) menu for easier testing LV1 exploit glitch
- Fixed lv1_peek and lv1_peek32 notify values
- Added 32-bit and 64-bit lv1 peek and poke options to xai

Please see this thread for info on BadHTAB: https://www.psx-place.com/threads/p...-software-based-hypervisor-lv1-exploit.47282/

Please see this thread for info on BadWDSD: https://www.psx-place.com/threads/b...-with-latest-software-hardware-exploit.47475/

4.80 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_debug-480C.pkg
4.81 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_debug-481C.pkg
4.82 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-482C.pkg
4.83 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-483C.pkg
4.84 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-484C.pkg
4.85 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-485C.pkg
4.86 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-486C.pkg
4.87 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-487C.pkg
4.88 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-488C.pkg
4.89 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-489C.pkg
4.90 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-490C.pkg
4.91 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-491C.pkg
4.92 CEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_signed-492C.pkg

4.82 DEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_debug-482D.pkg
4.84 DEX: http://ps3xploit.me/hen/openbeta/Latest_HEN_Installer_3.4.1_test14ze_debug-484D.pkg

 

[Fabreth]

So with this beta we can try overclocking on superslim models without any additional hardware or mod chip?

 

[STLcardsWS]

So with this beta we can try overclocking on superslim models without any additional hardware or mod chip?

Just look up a few post,
Same Question asked and answered already.

https://www.psx-place.com/threads/p...advanced-users-only.37363/page-12#post-411628

 

[aldostools]

So with this beta we can try overclocking on superslim models without any additional hardware or mod chip?

The new BadHTAB exploit for superslim and slims 3xxx/25xx (3.60+) is a hardware + software exploit.

You will need a "mod chip" device to cause the glitch that enables the read/write access to LV1 memory.
Once it is enabled, it will let you apply LV1 patches like oveclocking, install Linux, dump LV1, etc.
This method will allow to inject CFW-like patches when the system starts, resulting in a "qCFW".

According to the devs, ERK dump is not possible yet (and it could not be possible with this method).

 

[Fabreth]

Oh ok. Got it!

Hopefully one day the exploit can be installed via software

 

[aldostools]

3.4.1 Open Beta Test #14 (05-18-2025): (4.80 - 4.92 CEX / 4.82 & 4.84 DEX)

New Changes:
- Added support for using tmp_lv1peek and PS3MAPI LV1 PEEK/POKE for compatibility with WMM (thanks @aldostools )

I posted a PR with some fixes. Please check them.
https://github.com/PS3Xploit/PS3HEN/pull/73

 

[RoboKing's Cosmos]

Could you add like some way to remove HEN automatically upon detection of BADWDSD?
Also congrats to @aomsin2526 for the implementations of a Factory Service Mode i thought could never be achieved

 

[aomsin2526]

Could you add like some way to remove HEN automatically upon detection of BADWDSD?
Also congrats to @aomsin2526 for the implementations of a Factory Service Mode i thought could never be achieved

BadWDSD in OFW mode will be useless without HEN

 

[Louis Garry]

BadWDSD in OFW mode will be useless without HEN

Master, does BadWDSD support unsign self in modules (not coreOS), like vsh.self?

 

[aomsin2526]

Master, does BadWDSD support unsign self in modules (not coreOS), like vsh.self?

Now? No, you can't modify vsh self/sprx.

Not without extensive lv2 patching. I think its possible through but I don't have skill to do it.

Funnily enough, working with lv2 seems to be much more difficult than making the whole modchip and patching the whole bootchain.

 

[esc0rtd3w]

I posted a PR with some fixes. Please check them.
https://github.com/PS3Xploit/PS3HEN/pull/73

I didnt test before committing that lol, but wanted to try and fix it anyways. For some reason peekd and poked crash. I had issues with those testing lv1 stuff earlier, and i dont fully understand what their purpose is or why it doesnt work with hen. Maybe something is commented out thats needed, or missing? @Joonie

I didnt get socat log yet, but will need to add some debug info anyways probably.

https://github.com/PS3Xploit/PS3HEN/commit/b4f907cc4ab309731d7beccdef58d5d300e0e6ca

 

[aldostools]

I didnt test before committing that lol, but wanted to try and fix it anyways. For some reason peekd and poked crash. I had issues with those testing lv1 stuff earlier, and i dont fully understand what their purpose is or why it doesnt work with hen. Maybe something is commented out thats needed, or missing? @Joonie

I didnt get socat log yet, but will need to add some debug info anyways probably.

https://github.com/PS3Xploit/PS3HEN/commit/b4f907cc4ab309731d7beccdef58d5d300e0e6ca

Let me explain you the changes. If you need additional details, just ask me.

In that commit, the most important change is the line 1175 (line 1174 should be commented)

return lv1_peekd(function); // returns the lv1_peekd of the address (similar to syscall 11), except that this happen only when the address (function) is not a cobra opcode found in the previous cases. As the opcodes are non-aligned addresses, that line 1175 is used for most of LV1 peeks that use syscall 8.

Line 823 was removed because it was a commented return.

Line 826 return SUCCEEDED; is equivalent to return 0. If this line is omited, the opcode PS3MAPI_OPCODE_LV1_POKE will reach the line 1181 that return ENOSYS;

Line 829 can be reverted to return *(uint64_t *)param2; It was changed only to make it identical to the opcode PS3MAPI_OPCODE_LV2_PEEK in Cobra.

Line 834 can be changed to *(uint64_t *)param2=param3; or if you prefer revert the opcode PS3MAPI_OPCODE_LV2_POKE to the original code. This opcode will not be compatible with cobra for address lower or equal to than hash_checked_area.

 

[aomsin2526]

Let me explain you the changes. If you need additional details, just ask me.

In that commit, the most important change is the line 1175 (line 1174 should be commented)

return lv1_peekd(function); // returns the lv1_peekd of the address (similar to syscall 11), except that this happen only when the address (function) is not a cobra opcode found in the previous cases. As the opcodes are non-aligned addresses, that line 1175 is used for most of LV1 peeks that use syscall 8.

Line 823 was removed because it was a commented return.

Line 826 return SUCCEEDED; is equivalent to return 0. If this line is omited, the opcode PS3MAPI_OPCODE_LV1_POKE will reach the line 1181 that return ENOSYS;

Line 829 can be reverted to return *(uint64_t *)param2; It was changed only to make it identical to the opcode PS3MAPI_OPCODE_LV2_PEEK in Cobra.

Line 834 can be changed to *(uint64_t *)param2=param3; or if you prefer revert the opcode PS3MAPI_OPCODE_LV2_POKE to the original code. This opcode will not be compatible with cobra for address lower or equal to than hash_checked_area.

lv1_peekd(param2 + 0x8000000ULL); is wrong, this is correct on CFW but not on OFW. Because on CFW/qCFW, lv2 initial lpar size changed from 16M to 128M. (for otheros to work).

CFW did it by editing default.spp, qCFW did it by patching lv1 memory while booting.

The result ra becomes 0x8000000. but on OFW it's actually 0x1000000.

 

[RoboKing's Cosmos]

lv1_peekd(param2 + 0x8000000ULL); is wrong, this is correct on CFW but not on OFW. Because on CFW/qCFW, lv2 initial lpar size changed from 16M to 128M. (for otheros to work).

CFW did it by editing default.spp, qCFW did it by patching lv1 memory while booting.

The result ra becomes 0x8000000. but on OFW it's actually 0x1000000.

Does this mean we might have another sigfail for PS3 3.60+ like especially since Sony patched it years ago? I mean not now but soon?

 

[esc0rtd3w]

lv1_peekd(param2 + 0x8000000ULL); is wrong, this is correct on CFW but not on OFW. Because on CFW/qCFW, lv2 initial lpar size changed from 16M to 128M. (for otheros to work).

CFW did it by editing default.spp, qCFW did it by patching lv1 memory while booting.

The result ra becomes 0x8000000. but on OFW it's actually 0x1000000.

This seemed to fix it @aldotools

case PS3MAPI_OPCODE_LV2_PEEK:
return lv1_peekd(param2 + 0x1000000ULL);
break;
case PS3MAPI_OPCODE_LV2_POKE:
lv1_poked(param2 + 0x1000000ULL, param3);
return SUCCEEDED;
break;

Well, it doesnt crash anymore lol

https://github.com/PS3Xploit/PS3HEN/commit/3654000f5e9ba42e017c9fd064f74582772230b0

Edit: I'm told that we dont need the lv2 modifications because it will only work with modchip anyways.

 

[aldostools]

I'm told that we dont need the lv2 modifications because it will only work with modchip anyways.

Yes, the modifications I made were for qCFWbadWDSD. 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.