PS3HEN [Support Thread] PS3HEN Bugs, Problems, and Other Issues

[esc0rtd3w]

The best solution in this situation would be to enable an option that disables hotkey polling by default.

Spoiler: code

PS3HEN/payload/main.c

if((cellFsStat("/dev_hdd0/hen/hotkeys.off",&stat)!=0))
    {
        check_combo_buttons();
    }

Such options are in an unofficial HEN

Yeah we can add a toggle for disabling polling.

 

[Fredy66]

I´ve edited the category_game.xml in /dev_flash/.. and inserted the 2 blocks but unfortunately it didn´t work.
No mounted game was displayed in the app_home directory.
< Query
class="type:x-xmb/folder-pixmap"
key="seg_gamedebug"
src="#seg_gamedebug"
/>
and
<View id="seg_gamedebug">
<attributes>
<Table key="game_debug">
<Pair key="icon_rsc">tex_album_icon
<Pair key="title_rsc">msg_tool_app_home_ps3_game
<Pair key="child">segment
</Table>
</attributes>
<items>
<Query class="type:x-xcb/game-debug" key="game_debug" attr="game_debug"/>
</items>
</View>

Maybe a developer can check where the problem lies. That would be very nice.

Edit: Today I've tested it again. After these manual changes, * app_home/PS3_GAME was present in XMB but not working. ->
/app_home was not mapped to /dev_bdvd when an ISO was mounted.

Then I did another test with my old working category_game.xml with hardcoded seg_gamedebug from hen 3.0.3. Again
/app_home was not mapped to /dev_bdvd when an ISO was mounted.

Then I changed the PS3HEN.BIN in /dev_flash from 3.2.1 to the version 3.0.3.
/app_home was mapped to /dev_bdvd when an ISO was mounted.

Edit2: Just to clarify. The mapping of a mounted iso to /app_home is always visible in a file manager, but only not available/working on xmb with hen 3.2.1, although the entry ★ /app_home/PS3_GAME is visible.

After a lot of testing I'm sure that in HEN 3.2.1 ★ /app_home/PS3_GAME in xmb does not work as intended.

 

[esc0rtd3w]

After a lot of testing I'm sure that in HEN 3.2.1 ★ /app_home/PS3_GAME in xmb does not work as intended.

What is the goal? We removed that /app_home/ entry a long time ago, from what i remember, when using the DEX version of explore_plugin.sprx. Versions from 3.1.1+ now use CEX version of the explore_plugin.sprx.

 

[aldostools]

After a lot of testing I'm sure that in HEN 3.2.1 ★ /app_home/PS3_GAME in xmb does not work as intended.

/app_home/PS3_GAME by default is not mapped to any application.
If you use webMAN MOD, you can go to /setup.ps3 and set the Home setting to point to the path of any game or application.

For instance I set it to /dev_hdd0/game/RELOADXMB, because I use reload XMB frequently.

You could set it to open your favorite PS3 homebrew. e.g.
multiMAN: /dev_hdd0/game/BLES80608
IRISMAN: /dev_hdd0/game/IRISMAN00
Apollo: /dev_hdd0/game/NP0APOLLO
Movian: /dev_hdd0/game/HTSS00003
prepISO: /dev_hdd0/game/BLES80616

The app_home/PS3_GAME icon is remapped when you mount a new game. The default application set in home is restored when the game is unmounted.

 

[Fredy66]

/app_home/PS3_GAME by default is not mapped to any application.
If you use webMAN MOD, you can go to /setup.ps3 and set the Home setting to point to the path of any game or application.

For instance I set it to /dev_hdd0/game/RELOADXMB, because I use reload XMB frequently.
View attachment 40476

You could set it to open your favorite PS3 homebrew. e.g.
multiMAN: /dev_hdd0/game/BLES80608
IRISMAN: /dev_hdd0/game/IRISMAN00
Apollo: /dev_hdd0/game/NP0APOLLO
Movian: /dev_hdd0/game/HTSS00003
prepISO: /dev_hdd0/game/BLES80616

The app_home/PS3_GAME icon is remapped when you mount a new game. The default application set in home is restored when the game is unmounted.

Unfortunately, this is precisely the point which no longer works. I've set a home application in Webman mod. I can see that mapping in a file manager. But in the xmb I only get the error 80028F14 when I click on /app_home/game.
Also reload does not work anymore.

What is the goal? We removed that /app_home/ entry a long time ago, from what i remember, when using the DEX version of explore_plugin.sprx. Versions from 3.1.1+ now use CEX version of the explore_plugin.sprx.

This /app_home/ entry is needed for some functions of webman mod.

 

[FFF256]

What's good about the app_home link in XMB: In the past, when adding this option, when updating the list of games, it would reload at the same time and there was no need to repeatedly press reloadXMB.

 

[esc0rtd3w]

ive added app_home as an HFW Tools toggle for next release. Im testing it now.

 

[LuanTeles]

@esc0rtd3w isn't a way to make only one .BIN with support for all fw versions, idk autodetect feature to load the right offsets based on the fw version?

 

[aldostools]

@esc0rtd3w isn't a way to make only one .BIN with support for all fw versions, idk autodetect feature to load the right offsets based on the fw version?

The payloads PS3HEN/Cobra/Mamba could be modified to support multiple firmware versions. The problem is that the payload is loaded in a memory area limited to 128KB. Addiing more offsets would be Increasing the size of the payload beyond that limit.

In HEN we also have stack memory file, which is over 1MB per firmware versions and the original system files that are restored for each HFW would make the installer humongous.

 

[LuanTeles]

The payloads PS3HEN/Cobra/Mamba could be modified to support multiple firmware versions. The problem is that the payload is loaded in a memory area limited to 128KB. Addiing more offsets would be Increasing the size of the payload beyond that limit.

In HEN we also have stack memory file, which is over 1MB per firmware versions and the original system files that are restored for each HFW would make the installer humongous.

Got it, but aren't the offsets from 4.82 to 4.89 the same? many firmware versions keeps the same ones, i see they declared at least in hen source and they are pretty much the same and could save some bytes instead of adding offsets from each version.

 

[aldostools]

Got it, but aren't the offsets from 4.82 to 4.89 the same? many firmware versions keeps the same ones, i see they declared at least in hen source and they are pretty much the same and could save some bytes instead of adding offsets from each version.

Indeed the code of the payload uses compilation variables to reuse the code for the different firmware versions. Unless there are exception to the following conditional compilations, the PS3HEN payload for 4.89 should work for 4.81-4.89 and the one for 4.90 should work for 4.80 & 4.90.

#if defined(FIRMWARE_4_81) || defined(FIRMWARE_4_82) || defined(FIRMWARE_4_83)|| defined(FIRMWARE_4_84)|| defined(FIRMWARE_4_85)|| defined(FIRMWARE_4_86)|| defined(FIRMWARE_4_87)|| defined(FIRMWARE_4_88)|| defined(FIRMWARE_4_89)
...
#elif defined(FIRMWARE_4_80) || defined(FIRMWARE_4_90)

As I commented earlier, the payload is not the main issue. It is the stack frame & the supporting files that are firmware specific what forces to have multiple installers per firmware version.

 

[LuanTeles]

Thanks for the clarification Aldo.

 

[RoboKing's Cosmos]

@aldostools So it is technically possible to flash an older firmware on a superslim as long as it contains metldr2? Too bad I can't QA Toggle to 4.60 factory firmware due to being stuck on HEN. And I don't have a 4.60 Flash dump either.

 

[RoboKing's Cosmos]

I know factory firmware is impossible thanks to HFW

 

[esc0rtd3w]

@aldostools So it is technically possible to flash an older firmware on a superslim as long as it contains metldr2? Too bad I can't QA Toggle to 4.60 factory firmware due to being stuck on HEN. And I don't have a 4.60 Flash dump either.

It should be possible to downgrade metldr.2 consoles to their factory version. Habib and I actually tested this a while back, but I ended up bricking a console because I didn't use the e3 flasher one I had. My mistake, but we got far enough that I know its possible. The flash was formatted but their was an error in our test payload. Unfortunately, I don't have the source of Habib's work, but I do have compiled bins. It was using the jaicrab method mostly, with modified lv2 patches

 

[esc0rtd3w]

@esc0rtd3w isn't a way to make only one .BIN with support for all fw versions, idk autodetect feature to load the right offsets based on the fw version?

We have talked about this actually a bit, but as Aldo said, it really comes down to the stackframe. There are really only 7 right now.

4.80 CEX
4.81 CEX
4.82 CEX
4.83 - 4.89 CEX
4.90 CEX

4.82 DEX
4.84 DEX

In was thinking we could put all the resources that are firmware specific into either packages or tarballs and just have hen download and install/extract appropriate one. We could store them locally for developer version, with increased filesize.

The differences are minor and are just the vsh and lv2 offsets.

I think it could be done in some way, but we would have to sit down and figure out the best way.

I'm all for it, as that's one reason I stopped making separate release, debug, and usb packages and just added the 5 different files to the modes folder now in a single package.

 

[bguerville]

Here's my take.

I believe the best way is to construct the stack frames dynamically rather than keep a library of premade files..

You can build them up easily in js and integrate the payload, sprx and stage0 binaries at runtime, those binaries can also be provided in a compressed format if it helps, to be decompressed with js (or even actionscript) when needed.
Even the kernel payload binary might be editable at runtime and offsets modded as appropriate.

Also multi fw version support is not the only reason to build the frames at runtime, as-is HEN uses unallocated browser memory, a practice which is ok for a proof of concept but not for proper releases, being a source of crash and instability with a probability varying according to browser usage..
Building the stack frames dynamically would allow HEN tools to use properly allocated memory as they should always have done ideally.

 

[esc0rtd3w]

Got it, but aren't the offsets from 4.82 to 4.89 the same? many firmware versions keeps the same ones, i see they declared at least in hen source and they are pretty much the same and could save some bytes instead of adding offsets from each version.

Aldo pretty much explained most of it, but i will add a couple things. Also @bguerville 's idea of making dynamic stackframe is most likely the ultimate goal, but for now here is how it is setup.

The CEX VSH and LV2 offsets are different (at least some) for 4.80, 4.81, and 4.82, as also are the hashes in modulespatch.h. 4.83 - 4.89 are basically all the same, except one or two VSH offsets for ps3xploit_key and idps as far as I remember. 4.90 shares LV2 offsets with 4.80, but the module hashes and VSH offsets are different (at least some). 4.80 - 4.82 all have different VSH offsets and module hashes.

The stackframe is basically split into 3 areas in the bin that need offsets updated, depending on FW version. Here is a snippet from the stackframe map that is also on GitHub.

PS3HEN.BIN
0x00000000 - 0x0006FFFF webkit (vsh) gadgets #1: stackframe base
0x0009FFF8 - 0x000A0387 webkit (vsh) gadgets #2: stackframe
0x000FFFE0 - 0x00101FFF stackframe lv2/vsh offsets

https://github.com/PS3Xploit/PS3HEN/tree/master/docs/porting

0x00000000 - 0x0006FFFF webkit (vsh) gadgets #1: stackframe base
0x00070000 - 0x0007FFF7 sprx (max size: 0xFFF8)
0x0007FFF8 - 0x0007FFFF size of stage2 (0x8 bytes)
0x00080000 - 0x0009FFF7 stage2 (max size: 0x1FFF8)
0x0009FFF8 - 0x000A0387 webkit (vsh) gadgets #2: ???
0x000A0388 - 0x000A4FAF padding (all 0s) (0x4C28 bytes)
0x000A4FB0 - 0x000A5EEF socket lv2 value 8000000000670000
0x000A5EF0 - 0x000FFFDF padding (all 0s) (0x5A0F0 bytes)
0x000FFFE0 - 0x00101FFF stackframe lv2/vsh offsets
0x00102000 - 0x0010EFFF stage0 (max size: 0xD000)
0x0010F000 - 0x0010FFFF padding ??? (all Fs) (0x1000 bytes)

TOC Locations
0x000A0044 - 0x000A0047 vsh toc
0x000FFFF4 - 0x000FFFF7 vsh toc

Other offsets in between ranges
0x001008B8 - 0x001008BF size of stage0 (0x8 bytes)

 

[Fredy66]

I have just tested HEN 3.2.2. I can now toggle /app_home.

Unfortunately, the /app_home/ function does not work in Hen 3.2.2 The entry is displayed in the XMB, but the function is not given.

Unfortunately, this is precisely the point which no longer works. I've set a home application in Webman mod. I can see that mapping in a file manager. But in the xmb I only get the error 80028F14 when I click on /app_home/game.
Also reload does not work anymore.

Functions must have been changed in the payload of HEN 3.2.1/3.2.2 , because everything worked in Hen <= 3.11.
You have to mount an iso with webman mod to check it. If you now go to the /app_home entry in the xmb, you should be able to start the game. This still does not work.

The problem wasn't adding the entries in the xmb, but that the entries in xmb no longer had any function. The same entries in HEN 3.1.1 are working.

 

[esc0rtd3w]

I have just tested HEN 3.2.2. I can now toggle /app_home.

Unfortunately, the /app_home/ function does not work in Hen 3.2.2 The entry is displayed in the XMB, but the function is not given.


Functions must have been changed in the payload of HEN 3.2.1/3.2.2 , because everything worked in Hen <= 3.11.
You have to mount an iso with webman mod to check it. If you now go to the /app_home entry in the xmb, you should be able to start the game. This still does not work.

The problem wasn't adding the entries in the xmb, but that the entries in xmb no longer had any function. The same entries in HEN 3.1.1 are working.

Me and other testers were able to get it mounted using multiman. I am still unsure why wmm doesn't do it. @aldostools