• PS3HEN is now supporting 4.93 Firmware

    View Official Release Post for additional information HERE

PS3HEN PS3HEN Open Beta Testing [For Advanced Users Only]

Why are 100 directories scanned in this cycle?

Wouldn't it be better to get a list of directories and only check them? And the number of users definitely cannot be more than 100?
Of course it would be better to get an exhaustive list of profile directories to process than blindly iterate through a number of directories that may or may not even exist.
The initial version of this feature just iterated through all the directory entries found in /dev_hdd0/home however that didn't work correctly in practice, it was tested thoroughly however I am not sure whether the issue was ever fully investigated/explained.
Anyway, I think maybe we could do a better job using a xRegistry.sys query to get the list of existing user profile ids kept by the system rather than to scan the file system for directories.

Btw some changes were pushed in a recent commit, the code now checks profile IDs from 1 to 255, it's still not ideal but more often than not, users don't have that many user profiles anyway.
And it no longer copies the act.dat/bak files contents, it now uses symlinks instead.

https://github.com/PS3Xploit/PS3HEN...2388bb4#diff-5EE508DF8B522BEA8706B1554DF0A0B2
 
Last edited:
Yeah that probably would be better. There is a PR that has been included that scans 256 users.
https://github.com/PS3Xploit/PS3HEN/pull/45

If someone wants to submit a PR that gets a list of directories, then feel free to do so. The current method seems to work with @bucanero updated PR.

Beware, the directory scan was removed from the original version due to an infinite loop situation. Doing a file link or file creation while inside the directory scan seemed to break things up, and leaving an infinite loop situation where the scan never ends.

The forced for(....) loop was made to avoid the infinite loop and be sure that the code continues.
Aldostools did a different fix and added a counter inside the directory scan, if the counter reach "2000" then it breaks.

Anyways, I'd keep it like this as in the latest PR #45, it's simple, it works, and avoids any possible infinite loop case.
 
Beware, the directory scan was removed from the original version due to an infinite loop situation. Doing a file link or file creation while inside the directory scan seemed to break things up, and leaving an infinite loop situation where the scan never ends.

The forced for(....) loop was made to avoid the infinite loop and be sure that the code continues.
Aldostools did a different fix and added a counter inside the directory scan, if the counter reach "2000" then it breaks.

Anyways, I'd keep it like this as in the latest PR #45, it's simple, it works, and avoids any possible infinite loop case.
We could probably rely on the xRegistry vsh export that extracts as a linked list all the registry entries matching a certain pattern.
I can provide the details needed to set something like this up, I REd the arguments a few months ago for the xRegistry Editor feature and the Toolset now uses that export function routinely.
xRegistrygetList is the x3 export 0x12B480D0.

As far as I can tell, if we extracted the list of registry entries following a pattern along the lines of /setting/user/*/, we should in theory have everything we need to construct an exhaustive list of all act.dat file paths expected by the system that we can then process.

Just an idea.
 
We could probably rely on the xRegistry vsh export that extracts as a linked list all the registry entries matching a certain pattern.
I can provide the details needed to set something like this up, I REd the arguments a few months ago for the xRegistry Editor feature and the Toolset now uses that export function routinely.
xRegistrygetList is the x3 export 0x12B480D0.

As far as I can tell, if we extracted the list of registry entries following a pattern along the lines of /setting/user/*/, we should in theory have everything we need to construct an exhaustive list of all act.dat file paths expected by the system that we can then process.

Just an idea.

The export sounds interesting for other uses. It would be nice to see some examples using it.

Unless a refactor using that export could help to get a smaller code, I would keep bucanero's code.
It's simple and gets the expected result with little code.
 
Can you please tell me what font was used on the hen icon? I want to make the inscription "hen on" and "hen off". Loved your style :)
 
@esc0rtd3w if L2 is held on hen launch it will disable the map_paths?

Edit: It's commented out, i was just cheking the commits now i saw the code
 
Last edited:
@esc0rtd3w if L2 is held on hen launch it will disable the map_paths?
Well, that was tested and works fine, but was commented out due to stage2 size. You may be able to build it for release and it will not be over the size limit, but the debug build with DPRINTF statements make it too large. Some can be commented if you want to test it, but I dont think it should be in release version. The button for disabling plugins is still active.
 
@esc0rtd3w in general those are the changes?

# v3.2.0
### Plugin:
-Added: Automatic reboot after successful initial HEN installation from Network and USB
-Added: Blacklist access to homebrews NP0APOLLO / NP00PKGI3 when CFW syscalls are disabled by @aldostools.<br>
-Added: Mamba 8.4 changes by @OsirizX.<br>
-Added: Libcrypt Support for PS1 games (LSF/SBI files).
-Added: PSX Bios patched with product code 0x85 for PAL games
-Added: Support for .RAP extension (in addition to .rap) by @aldostools.<br>
-Added: Toggle for Audio Patch.
-Added: Toggle for Build types. (DEV/Release)
-Added: Toggle to clean Web Browser user information on HEN activation. (Auth, Cache,Cookies, History)
-Improved: Simplified Backup/Restore of the act.dat on every boot by @bucanero.<br>

### Payload:
-Added: Pad Detection (Hold R2 to disable boot_plugins.txt and Hold L2 to disable map_path.)
-Added: Improved open_path status.
-Improved: Map_path.
-Improved: PS3MAPI.

### Others:
-Added: PS3HEN GEN patch to build on linux/mac/*nix by @bucanero

the OsirizX/GEN patch I got from the bucanero's PR.

I noticed dynarec is not on hen ps3_mapi will it be added ? (Add dynarec · bucanero/ps3mapi-lib@6e32e38 (github.com))
 
Last edited:
@esc0rtd3w other questions i saw hen_plugin_stop and stop_prx_module are these releated to a way to disable the hen? if so, how can i unload it?

and any news about the .BIN zlib compression?
 
Last edited:
@esc0rtd3w and @bguerville, seems like i still have problems with map_paths.

EDIT: Remember when I said in the past that map_path problems are more likely to happen when my system is very hot? that seems to be the problem, i use webMAN'S dynamic fan control, now i set it to manual mode and the problems are gone again.

and seems like we still can't map xmls from flash to flash right? why this happens?

eg: map_path("/dev_flash/vsh/resource/explore/xmb/category_game_hen.xml","/dev_flash/hen/xml/hen_enabled.xml",FLAG_MAX_PRIORITY|FLAG_PROTECT)

vpIRUHi.png


Some times it got stuck:
gsaPoft.png

ruYUObg.png
 
Last edited:
@esc0rtd3w and @bguerville, seems like i still have problems with map_paths.

EDIT: Remember when I said in the past that map_path problems are more likely to happen when my system is very hot? that seems to be the problem, i use webMAN'S dynamic fan control, now i set it to manual mode and the problems are gone again.

and seems like we still can't map xmls from flash to flash right? why this happens?

eg: map_path("/dev_flash/vsh/resource/explore/xmb/category_game_hen.xml","/dev_flash/hen/xml/hen_enabled.xml",FLAG_MAX_PRIORITY|FLAG_PROTECT)

vpIRUHi.png


Some times it got stuck:
gsaPoft.png

ruYUObg.png
I would bet it's a wmm issue with dynamic fan control. I have tested with wmm and without and weird issues always seem to pop up with wmm. Whenever I check socat log, the last entry is when it checks that file, I can't remember what the name is off hand.
 
Will the sources be available only after the release? Or can you check them out now?
The current source is available in the dev branch. That was made to push changes over the past few months, just in case something were to happen to either myself or Ben. In theory, most of that code is solid and has been tested, but probably not ready for release yet.
 
@esc0rtd3w and @bguerville, seems like i still have problems with map_paths.

EDIT: Remember when I said in the past that map_path problems are more likely to happen when my system is very hot? that seems to be the problem, i use webMAN'S dynamic fan control, now i set it to manual mode and the problems are gone again.

and seems like we still can't map xmls from flash to flash right? why this happens?

eg: map_path("/dev_flash/vsh/resource/explore/xmb/category_game_hen.xml","/dev_flash/hen/xml/hen_enabled.xml",FLAG_MAX_PRIORITY|FLAG_PROTECT)

vpIRUHi.png


Some times it got stuck:
gsaPoft.png

ruYUObg.png
The flash to flash mappings we never figured out what the deal is with that. We tested several scenarios and for some reason it dont work
 
I would bet it's a wmm issue with dynamic fan control. I have tested with wmm and without and weird issues always seem to pop up with wmm. Whenever I check socat log, the last entry is when it checks that file, I can't remember what the name is off hand.

@aldostools is there anything that can be done besides using manual mode?
 
The flash to flash mappings we never figured out what the deal is with that. We tested several scenarios and for some reason it dont work

At least the AAA folder is an exception this is the only way i found to make flash to flash mappings. (except for xmls)
 
Last edited:
Could be added the possibility to disable/switch off hen? might clicking hen ogg, because actually there's not the possibility to disable it, if you click on hen ogg the ps3 will reboot so disabling hen too obviously but i wish disable hen without ps3 rebooting, because if i need to make some test with hen disabled i can't reboot the ps3 each time lol

Inviato dal mio SM-G973F utilizzando Tapatalk
 
Back
Top