PS3HEN PS3HEN - Official Release Thread (Homebrew Enabler for the PS3) v3.5.0 (4.93 support)

[bguerville]

I need some time to try to understand how HEN works. Both HFW and sprx fix was done from PC without touching source code of the HEN. I will share new HFW if/when new OFW is released for sure. Already checked all OFWs for the silk_webkit file. It appears in the 4.10 and was updated in 4.50 and 4.83 for a second time.

Like I said before we would welcome such a move, we have been waiting for people to take over this kinda stuff (updates) ever since the very first ps3xploit release years ago, long before HEN came along.. in vain so far.
I am pretty sure that esc0 will agree with me, we cannot always be there for everyone and take care of everything each time there is a need. The HEN project is open source for a good reason, it's way past time for others to step in and take it forward otherwise what would the point be?
The obvious lack of interest so far in contributing to open source ps3xploit projects explains in part why I keep my PS3 Toolset source closed, why open a project if nobody is going to improve it, build upon it or even update it?

WebKit was introduced in 4.10, before that there was only the silk browser which btw is also exploitable, either through js/css etc.. or via the Flash player 9 plugin, I already made a proof of concept that runs ROP on silk browser (OFW without webkit swap) about 2 or 3 years ago.

The 4.83 update to webkit is minimal, iirc only a few bytes to fix the NaN vulnerability that was exploited with parseFloat, everything else is identical.

If you are serious about this, you need to know that privately, there's a better installer/enabler on the back burner which will change a number of things outside the actual HEN payload itself.

 

[esc0rtd3w]

i don't mind doing the updates, as its easier to get everything together and uploaded, but i am open to any help that others want to contribute. As far as HEN src, and other visual issues that we run into, having others help figure out stuff and submit PR in github is better. The final making of the pkgs, updating hen_version.bin, and the other version specific things that need updated in HTML, JS, and on website is usually easier to just do it myself.

 

[Edw590]

@esc0rtd3w Hi. Will you get bored again and update HAN offsets so that I can see if HAN Toolbox offsets need to be updated xD? If not no problem, it's just to have some sort of confirmation, if you can give any.

 

[esc0rtd3w]

@esc0rtd3w Hi. Will you get bored again and update HAN offsets so that I can see if HAN Toolbox offsets need to be updated xD? If not no problem, it's just to have some sort of confirmation, if you can give any.

yeah lol

after the HEN situation gets sorted out

 

[LuanTeles]

yeah lol

after the HEN situation gets sorted out

Did you test my unofficial build?

 

[esc0rtd3w]

@esc0rtd3w Hi. Will you get bored again and update HAN offsets so that I can see if HAN Toolbox offsets need to be updated xD? If not no problem, it's just to have some sort of confirmation, if you can give any.

actually, here. Try this and tell me if it works?

http://**ps3xploit.com >Domain no L...it.me =new)/han/test/etHANol-v3.0.6-test2.zip <- Using HEN RCO
http://**ps3xploit.com >Domain no L...it.me =new)/han/test/etHANol-v3.0.6-test3.zip <- Using "Without Custom Icons" RCO

i updated the HAN Support Files zip. I removed the dex explore_plugin.sprx and replaced the explore_plugin_full.rco with the one @sandungas made for HEN, for 4.89 only.

EDIT #1: Please tell me if the Package Manager is broken

EDIT #2: Please try test3 zip. I updated the RCO to use the "without custom icons" from @sandungas

 

[esc0rtd3w]

Did you test my unofficial build?

not yet. After talking with @bguerville , he suggests that we only use map_path when absolutely needed...or something along those lines . I don't know the reason(s) why, other than it can be a performance hit? If there is a better way to do it and its stable, then i am all for it for a few items that would be beneficial. However, if there is another way to achieve the hiding and swapping of icons and xml menu items, then i am also for that. He mentioned @DeViL303 also for his way of perhaps doing this exact thing, without map_path.

I am fully open to suggestions on both why we can't use map_path, because it is cool and easy to use, and if we can do the swapping of at least xml and icons, without the need for it.

EDIT: I am also interested in how you achieved each thing, ie code or resources, just as much, if not more than the actual compiled files

 

[sandungas]

...and replaced the explore_plugin_full.rco with the one @sandungas made for HEN, for 4.89 only.

The one that was temporally named "with custom icon", or the other "without custom icons" ?
In any case, i guess you changed also the <Pair key> with the name of that icon in category_game.xml

Im asking mostly because im not sure if you decided to move that custom icon outside of the rco as a .png
You know... is not a custom icon, is the official "white folder + blue smartie" recovered from 4.88 and using a custom name
We was talking about loading it as a .png but im not sure if you already did it... thats one of the things that could simplify it a bit

In other words... i think the version "without custom icons" is better... and actually we could name it "with translated package manager texts" because thats his only purpose after removing the icon
You know.. the only custom edit in the "without custom icons" version is to add 20 text strings to the xml language files
As burgerville said the other day... this multilanguage support of the package manager could be distributed as an "addon" PKG... and it would be a single .rco for all the languages (same PKG installer for everyone), is just that installer should contain the custom .rco + the category_game.xml

I mean... the goal of what im suggesting would be to not include the custom explore_plugin_full.rco either in the HEN installers.... so you would need to "hardcode" the texts inside the default HEN category_game.xml... either directly in it, or with the "standalone" version i made or something similar
And the "addong PKG" for multilanguage support in the package manager should replace that static texts in category_game.xml by references to the contents of the custom rco

 

[esc0rtd3w]

The one that was temporally named "with custom icon", or the other "without custom icons" ?
In any case, i guess you changed also the <Pair key> with the name of that icon in category_game.xml

Im asking mostly because im not sure if you decided to move that custom icon outside of the rco as a .png
You know... is not a custom icon, is the official "white folder + blue smartie" recovered from 4.88 and using a custom name
We was talking about loading it as a .png but not sure if you already did it... thats one of the things that could simplify it a bit

In other words... i think the version "without custom icons" is better... and actually we could name it "with translated pacake manager texts" because thats his only purpose after removing the icon
You know.. the only custom edit in the "without custom icons" version is to add 20 text strings to the xml language files
As burgerville said the other day... this multilanguage support of the package manager could be distributed as an "addon" PKG... and it would be a single .rco for all the languages (same PKG installer for everyone), is just that installer should contain the custom .rco + the category_game.xml

I mean... the goal of what im suggesting would be to not include the custom explore_plugin_full.rco either in the HEN installers.... so you would be to "hardcode" the texts inside the default HEN category_game.xml... either directly in it, or with the "standalone" version i made or something similar

no, i forgot about the xml edit. But i can also just use the "without custom icons" one for HAN, now that you mention it. Was more of a test to see if HAN version edits worked, but i thought of the sprx/rco situation after that.

 

[LuanTeles]

not yet. After talking with @bguerville , he suggests that we only use map_path when absolutely needed...or something along those lines . I don't know the reason(s) why, other than it can be a performance hit? If there is a better way to do it and its stable, then i am all for it for a few items that would be beneficial. However, if there is another way to achieve the hiding and swapping of icons and xml menu items, then i am also for that. He mentioned @DeViL303 also for his way of perhaps doing this exact thing, without map_path.

I am fully open to suggestions on both why we can't use map_path, because it is cool and easy to use, and if we can do the swapping of at least xml and icons, without the need for it.

EDIT: I am also interested in how you achieved each thing, ie code or resources, just as much, if not more than the actual compiled files

Fair enough

Here the release + src of the #3 variant

I just used map_patch + the explorer plugin "reload_category_item" command.

 

[esc0rtd3w]

@esc0rtd3w Hi. Will you get bored again and update HAN offsets so that I can see if HAN Toolbox offsets need to be updated xD? If not no problem, it's just to have some sort of confirmation, if you can give any.

Please try test3 zip. I updated the RCO to use the "without custom icons" from @sandungas
http://**ps3xploit.com >Domain no L...it.me =new)/han/test/etHANol-v3.0.6-test2.zip <- Using HEN RCO
http://**ps3xploit.com >Domain no L...it.me =new)/han/test/etHANol-v3.0.6-test3.zip <- Using "Without Custom Icons" RCO

that should at least get you happy with HAN until any issues can be addressed later on.

 

[bguerville]

What I would suggest is to get rid of DEX explore plugin sprx and rco altogether.
Enable the PKG manager when HEN gets enabled (the trade off being that users won't be able to install official PKG files when hen is disabled) and fix the stuttering and other possible issues with HEN patch(es) on the CEX plugin files, that will require debugging those issues of course to understand what's going on.

map_path is a work around, it might work and we might use that temporarily to solve the current issues but what we really need is something less cumbersome, a permanent fix relying only on official updated CEX files.
Ideally we would need to remove all the DEX files dependencies in HEN whenever possible.

 

[LuanTeles]

What I would suggest is to get rid of DEX explore plugin sprx and rco altogether.
Enable the PKG manager when HEN gets enabled (the trade off being that users won't be able to install official PKG files when hen is disabled) and fix the stuttering and other possible issues with HEN patch(es) on the CEX plugin files.

map_path is a work around, it might work and we might use that temporarily to solve the current issues but what we really need is something less cumbersome, a permanent fix relying only on official updated CEX files.

The only thing i suggest if the map_path is used as a temporary fix, is to update it using @aldostools code, it is more efficient and consumes less memory.

I tried to use it in my personal Hen from the PRO MOD, but I couldn't compile because my system lacks some libs? (i dunno), using current map_path from HEN code may have some errors using more than 6 or 7 map_path (in my case) and it prevents webMAN MOD from launching games for example, but if the same remaps are used via webMAN, they will work fine.

The solution for me was to reduce the use of map paths to just 5, curiously for the remap of the Hen icon, I had to remove 3 map_paths that I used, otherwise it would have issues with webMAN.

Anyway the Unofficial build that i compiled is working fine.

 

[sandungas]

I think the only payback of removing the multilanguage support of the package manager is the "addon PKG" needs to overwrite the category_game.xml
I mean... is not just a matter of overwriting the official explore_plugin_full.rco by the custom one with the custom strings
As something conceptual... we are patching category_game.xml to load the strings statically (by default in english for everyone) to dinamic (loaded from inside the custom rco)

Thats not a big problem in itself, is just eventually could happen some incompatibilities because the custom rco doesnt needs much attention other than updating it incase sony breaks the layout.txt files again... but as we are overwriting category_game.xml entirelly there are more probabilities to create mistmatchs with it because category_game.xml could be updated eventually if you or someone else adds or removes something
In other words... it could happen that after the installation of that addon PKG the resulting XMB look of the new category_game.xml differs from the previous (in theory it should differ only in the translated strings of the package manager)

But long story short... i guess this can be prevented with a good versioning of the addon packages.. you know the goal would be to tell explicitelly that "this addon PKG is for a specific HEN version"

 

[esc0rtd3w]

Fair enough

Here the release + src of the #3 variant

I just used map_patch + the explorer plugin "reload_category_item" command.

you are using the same edited map_path_slot from the egg swap test, and i dont mind that method, but cant we just swap the XML and the reload will use the new icon? It would take us having to use map_path 3 times, to only 2 times. I think only 2 swaps would be fine, with my limited understanding of how map_path works, but also understanding that i had no issues with original egg swap test, but you tried multiple ones and had issues. So the breaking point isnt that high, really.

Then we have to also now swap in the Package Manager, so now we are back to 3 (or 4, if icon requires a separate swap). I like it, but i think 3 will be pushing some limit, and make it more unstable. I could be totally wrong, of course.

The other stuff for gameboot and audio headset probably wont be added to releases, but i could see those being used in xai for HFW Tools at some point. The gameboot stuff is cool, and the audio fix, is that the one we disabled a while back? I think those are better as toggles

 

[SG-17]

I have a CECHK01 PS3, do I have to downgrade to use unsigned code or can I use HEN?

 

[LuanTeles]

you are using the same edited map_path_slot from the egg swap test, and i dont mind that method, but cant we just swap the XML and the reload will use the new icon? It would take us having to use map_path 3 times, to only 2 times. I think only 2 swaps would be fine, with my limited understanding of how map_path works, but also understanding that i had no issues with original egg swap test, but you tried multiple ones and had issues. So the breaking point isnt that high, really.

Then we have to also now swap in the Package Manager, so now we are back to 3 (or 4, if icon requires a separate swap). I like it, but i think 3 will be pushing some limit, and make it more unstable. I could be totally wrong, of course.

The other stuff for gameboot and audio headset probably wont be added to releases, but i could see those being used in xai for HFW Tools at some point. The gameboot stuff is cool, and the audio fix, is that the one we disabled a while back? I think those are better as toggles

Actually we can use just two map_paths, one for hfw tools (we can include the package manager inside of it too) i just separated it just to make it more organized and the second one is the icon swap.

I think keeping the xml swap is also valid because it blocks the icon after a XMB reload, also we can just use it without a xml file, so the Hen Entry will disappear after a reload, just like my #4 build, i called it FAKE CFW .

As far as a tested using the 3 map_paths i said is completely stable, but the gameboot one is not ( when launching a game 1 out 15 or so, it can be stuck with the XMB clock spinning)

I thought about including a toggle for gameboot stuff (using @bguerville extended xia plugin) but I made these builds quickly to fix the layout problems. @Coro once shared a patch for gameboot but @DeViL303 said the patch needs to be applied in two different places. (this could solve the stability problem), so i ended up using map_path to a patched game_ext

About the audio patch, yep i just uncommented the already included code ( i commented it back in the src i sent to you)


Question: All the problems I have using map paths usually happen when my fan speed is high, can this affect the memory in any way?

Because most friends who use hen from my MOD PRO have no problems, but i usually have when I'm on hen and i realized that it usually happens when my fan speed is high.

but cant we just swap the XML and the reload will use the new icon?

if we only use the xml it will need the user to reload the xmb to get the new icon, using map_path for the icons + "reload_category_item game", will instantly swap the icon but not the xml ( i tried everything to make the xml to be reloaded, but seems it's impossible)

 

[esc0rtd3w]

Actually we can use just two map_paths, one for hfw tools (we can include the package manager inside of it too) i just separated it just to make it more organized and the second one is the icon swap.

I think keeping the xml swap is also valid because it blocks the icon after a XMB reload, also we can just use it without a xml file, so the Hen Entry will disappear after a reload, just like my #4 build, i called it FAKE CFW .

As far as a tested using the 3 map_paths i said is completely stable, but the gameboot one is not ( when launching a game 1 out 15 or so, it can be stuck with the XMB clock spinning)

I thought about including a toggle for gameboot stuff (using @bguerville extended xia plugin) but I made these builds quickly to fix the layout problems. @Coro once shared a patch for gameboot but @DeViL303 said the patch needs to be applied in two different places. (this could solve the stability problem)

About the audio patch, yep i just uncommented the already included code ( i commented it back in the src i sent to you)


Question: All the problems I have using map paths usually happen when my fan speed is high, can this affect the memory in any way?

Because most friends who use hen from my MOD PRO have no problems, but i usually have when I'm on hen and i realized that it usually happens when my fan speed is high.

i also do like the idea of hiding the Enable HEN icon, instead of swapping icons

 

[esc0rtd3w]

I think the only payback of removing the multilanguage support of the package manager is the "addon PKG" needs to overwrite the category_game.xm

what if we just added a stub (in category_game.xml), like for HEN Toolbox, and moved the package manager into a separate xml file? Then the category_game.xml wouldn't need updated, but the external package manager xml would, right?

 

[bguerville]

you are using the same edited map_path_slot from the egg swap test, and i dont mind that method, but cant we just swap the XML and the reload will use the new icon? It would take us having to use map_path 3 times, to only 2 times. I think only 2 swaps would be fine, with my limited understanding of how map_path works, but also understanding that i had no issues with original egg swap test, but you tried multiple ones and had issues. So the breaking point isnt that high, really.

Then we have to also now swap in the Package Manager, so now we are back to 3. I like it, but i think 3 will be pushing some limit, and make it more unstable. I could be totally wrong, of course.

I remember looking into the map_path code before and there was something that bothered me in its implementation at the time, a behaviour that can lead to issues, but that was a while ago and I cannot remember the details now.
In any case, being limited to 3 remaps when the limit is supposed to be > 10 does not sound right, one way or another.
Tbph I don't particularly like using that remapping concept in the first place as it uses a fair amount of CPU cycles every time a path is processed by the kernel but in some rare cases, it may be the most practical way to solve a problem so it's got its uses, still I think other ways should be favoured whenever possible.

...
edited
...

The other stuff for gameboot and audio headset probably wont be added to releases, but i could see those being used in xai for HFW Tools at some point. The gameboot stuff is cool, and the audio fix, is that the one we disabled a while back? I think those are better as toggles

I agree, that should go into xai plugin.