PS3HEN PS3HEN Open Beta Testing [For Advanced Users Only]

[bguerville]

Keeping in mind that's the kplugin template above is ONLY a temporary test template, it should NOT be used for deployment, for that we need to make something better.

The map_path changes however are likely to be deployed in all kernel payloads (maybe after some more tweaks) in order to allow passing kernel based strings as path arguments, fundamentally there is no reason to limit the mappath syscall arguments to 32 bit userland strings, even if that is what most devs would use.

 

[sandungas]

Keeping in mind that's the kplugin template above is ONLY a temporary test template, it should NOT be used for deployment, for that we need to make something better.

The map_path changes however are likely to be deployed in all kernel payloads (maybe after some more tweaks) in order to allow passing kernel based strings as path arguments, fundamentally there is no reason to limit the mappath syscall arguments to 32 bit userland strings, even if that is what most devs would use.

I remember discussing time ago about using the remaps to "fake" the gamedata installations (only in the games that performs the gamedata installation by copying the exact same files from the ISO/JB disc image ---> to dev_hdd0/game)

I think thats a good argument why is nice to be able to do a lot of remaps (sometimes that installations contains lot of files)

The idea was to use a procedure like this (made by the backup managers)
1) Allow the game to perform the gamedata installation normally
2) scan the gamedata installation path, and compare it with the files inside the ISO/JB disc image to find which ones are identical
3) replace the identical files from inside the gamedata installation path by the remaps (to the ISO/JB)

When i was discussing this idea i was thinking mostly in replacing the identical files by (linux filesystems) hardlinks or softlinks... but i guess the same concept should work with virtual remaps

This is specially useful if the game ISO/JB is located in the internal hdd... basically it could eliminate 95% of the gamedata installations for most games

 

[LuanTeles]

@LuanTeles

Here are 2 BIN files for you to test, if you like.

The original one uses this in mappath.c

LV2_SYSCALL2(int, sys_map_path, (char *oldpath, char *newpath, uint32_t flags))
{
    extend_kstack(0);
    return map_path_user(oldpath, newpath, flags);
}

The modified one uses this currently, to choose between user and kernel (its just a rough testing example for now)

LV2_SYSCALL2(int, sys_map_path, (char *oldpath, char *newpath, uint32_t flags))
{
    uint64_t ptr = (uint64_t)(uint64_t*)oldpath;
    #ifdef DEBUG
        //DPRINTF ("sys_map_path ptr 0x%8lx\n", ptr);
    #endif
 
    if(((ptr & 0xFF00000000000000ULL) >> 56)== 0x80)
    {
        return map_path(oldpath, newpath, flags);// kernel
    }
    else
    {
        extend_kstack(0);
        return map_path_user(oldpath, newpath, flags);// user
    }
}

The sample kplugin template included, MUST use the modified BIN, for the below sys_map_path example, and others using this syscall, or it will crash!

I should note that in testing only the FIRST mapping works, please let me know if that is the same for you.

sys_map_path("/dev_bdvd/PS3_UPDATE", "/dev_flash/vsh/resource/AAA",0);

You can also use the 2 new flags, which is what the default payload for HEN does now, to preserve mappings. Note that HEN uses map_path, while the kplugin uses sys_map_path.

map_path("/dev_hdd0/hen/xml/hfw_settings.xml","/dev_flash/hen/remap/xml/hfw_settings.xml",FLAG_MAX_PRIORITY|FLAG_PROTECT);

Sorry for the delay, my pc broke

I just tested it here, the kplugin loaded successfully and indeed only the first mapping worked.

 

[LuanTeles]

@esc0rtd3w @bguerville

Can a failsafe flag be added if the mapping target does not exist?

Let's use libaudio patch that is very popular as example:

sys_map_path("/dev_flash/sys/external/libaudio.sprx", "/dev_flash/vsh/resource/AAA/libaudio.sprx",FLAG_IF_EXISTS)

So if the destination file is not found the mapping is not performanced, so the user can just add the patched libaudio to the path to make it work. we can use extended xai plugin to move it there.

Or just a flag on the hen source, eg:

if dev_flash/hen/xml/audiopatch.on file exists it applies the memory patch


For my tests I used

sys_map_path("/dev_flash/vsh/module/xmb_plugin.sprx", "/dev_flash/vsh/resource/AAA/xmb_plugin.sprZ",0);

as the target file was not found, the system went into recovery mode. ( i use this for the IP address on the xmb and as i modded it, it only works if mapped on hen)



webMAN MOD mappings have a check if file exists before mapping them

 

[bguerville]

@esc0rtd3w @bguerville

Can a failsafe flag be added if the mapping target does not exist?

Let's use libaudio patch that is very popular as example:

sys_map_path("/dev_flash/sys/external/libaudio.sprx", "/dev_flash/vsh/resource/AAA/libaudio.sprx",FLAG_IF_EXISTS)

So if the destination file is not found the mapping is not performed, so the user can just add the patched libaudio to the path to make it work. we can use extended xai plugin to move it there.

Or just a flag on the hen source, eg:

if dev_flash/hen/xml/audiopatch.on file exists it applies the memory patch


For my tests I used

sys_map_path("/dev_flash/vsh/module/xmb_plugin.sprx", "/dev_flash/vsh/resource/AAA/xmb_plugin.sprZ",0);

as the target file was not found, the system went into recovery mode. ( i use this for the IP address on the xmb and as i modded it, it only works if mapped on hen)



webMAN MOD mappings have a check if file exists before mapping them

Currently, the kernel payload mapping system does not check the file system at any point and I don't think it should for a number of reasons including performance and the fact that the open_path hook gets executed every time you access a file.
With the current behaviour, mapping to a missing file can be dangerous, it's up to the devs to use the mappings they make appropriately.

In theory, what you are proposing should be possible, in the hook, any mapping with the proposed "failsafe" flag would need to have its redirected path stat-ed and in case of stat failure a fall back to the original path would be executed, all this without triggering the hook to avoid infinite looping.
Of course, any such implementation would only work with new payloads though.

 

[bucanero]

I'd say that the file check should be done in your own code, so for example:

int my_file_check(const char* path)
{ // do check if the file exists
  return 0;
}

...
// then in your main code
...


if (my_file_check("/dev_flash/sys/external/libaudio.sprx") == 0)
    sys_map_path("/dev_flash/sys/external/libaudio.sprx", "/dev_flash/vsh/resource/AAA/libaudio.sprx", 0);

that way you will only call sys_map_path if the file actually exists.

As a general design rule, in C the functions always assume the parameters are valid, so it's the developer's duty to validate first before calling.

 

[bguerville]

I'd say that the file check should be done in your own code, so for example:

int my_file_check(const char* path)
{ // do check if the file exists
  return 0;
}

...
// then in your main code
...


if (my_file_check("/dev_flash/sys/external/libaudio.sprx") == 0)
    sys_map_path("/dev_flash/sys/external/libaudio.sprx", "/dev_flash/vsh/resource/AAA/libaudio.sprx", 0);

that way you will only call sys_map_path if the file actually exists.

As a general design rule, in C the functions always assume the parameters are valid, so it's the developer's duty to validate first before calling.

Totally.
But of course there's always the case where a file might not exist at the time when you apply the mapping but may exist later on which is more complicated to deal with if the code doesn't control itself whether the file exists or not. I suppose one could argue that in this case, it's just bad programming concepts to begin with.

 

[DeViL303]

This is kind of related, I wonder could THIS "brick resistant" patch be implemented at a system level in Cobra/HEN. It turns out many times when you get kicked to recovery due to a missing file on flash its really not a proper "crash" where the system can not continue, it's more like a security check failing, this check is really only done on paths that start with "/dev_flash". However if the path starts with "//dev_flash" the security check is not done and the system continues loading what it can.

Not sure if this would be possible? but IF its really not a true crash, and its just a security check, it would be great if this could be patched out altogether, or redirected so instead of it kicking us to recovery when a file is missing it simply shows a "file missing" notification, or does nothing. This would make the system hardier and less sensitive to bad remaps, corrupt files, maybe bad blocks on hdd/flash?

This can also be seen with xai_plugin, if you add the xai sprx to flash, you must add the rco too or you will get kicked to recovery. But really the xai plugin rco is just a dummy rco and nothing gets loaded from it, so its just another pointless check to see if the file exists.

 

[bguerville]

This is kind of related, I wonder could THIS "brick resistant" patch be implemented at a system level in Cobra/HEN. It turns out many times when you get kicked to recovery due to a missing file on flash its really not a proper "crash" where the system can not continue, it's more like a security check failing, this check is really only done on paths that start with "/dev_flash". However if the path starts with "//dev_flash" the security check is not done and the system continues loading what it can.

Not sure if this would be possible? but IF its really not a true crash, and its just a security check, it would be great if this could be patched out altogether, or redirected so instead of it kicking us to recovery when a file is missing it simply shows a "file missing" notification, or does nothing. This would make the system hardier and less sensitive to bad remaps, corrupt files, maybe bad blocks on hdd/flash?

This can also be seen with xai_plugin, if you add the xai sprx to flash, you must add the rco too or you will get kicked to recovery. But really the xai plugin rco is just a dummy rco and nothing gets loaded from it, so its just another pointless check that the file exists.

I think the problem with this is that when a system file cannot be accessed, all the calling code that needed that system file in the first place cannot continue to run properly.
Even if you applied a patch to avoid the jump to recovery, depending on the needs of the calling code you would most likely still get errors at best or a panic and crash at worst anyway.

This is all theoretical first impressions of course, it doesn't mean the idea should not be investigated.

 

[esc0rtd3w]

Just my 2 cents on the missing file thing. In some instances, this is the desired behavior, such as remapping XML to show an xmb entry on HEN enable, like with hfw_settings and package manager.

The above example is having the missing file for oldpath, and the file existing for newpath.

The only time I can see this as a problem is for system files, where the ps3 will panic if missing (mapped file for newpath not existing, but original oldpath is there). I have seen the recovery crash when files are missing for XML and sprx especially, and the ps3 is expecting them to be there to run code or load some value.

 

[Louis Garry]

@bguerville, I just tried btoolset, a very good app.
The question is, why is the exploit not used for this HEN? So HEN supports OFW (not only HFW).
Thank you .

 

[bguerville]

@bguerville, I just tried btoolset, a very good app.
The question is, why is the exploit not used for this HEN? So HEN supports OFW (not only HFW).
Thank you .

Because historically speaking, I removed myself from HEN development.
Without the initial HEN leak, you would have had HEN for OFW relying on Flash 9 exploits and no HFW business, that was the original plan as the Flash exploits themselves were ready to deploy at the time, but the intentional leak and the team fallout that followed ensured that you didn't.

In recent months, I have been giving esc0 a hand with some of the HEN stuff, I wrote a new HEN installer last year that we still need to polish and release in coming weeks, but still based on HFW and old exploits.
I don't have any plans to add HEN to the Toolset for the time being, even though I could in theory, I would rather focus on the future, I don't think HEN will survive very long once lv1 gets exploited anyway. But then again, one should probably never say never, who knows what the future will bring, and I could always change my mind.

 

[LuanTeles]

@esc0rtd3w @bguerville

I'll leave here some suggestions for the next release, some have already been mentioned but I'm putting them together in just one post as i'm seeing more devs coming.

So if anyone is interested in these features, they can also submit a pull request via github.

• Gameboot logo + gameboot sound toggle.
• Custom update server for downloading/updating the hfw via official option.
• Game audio toggle (@in1975 already did it, please if you can, make a pull request)
• Automatic logo swap after enabling hen that disappears after a xmb reload. (fake cfw)
• Updated cobra to 8.30 + mamba 8.4 new features. (Convert save data, fan control, fake act.dat and etc)
• Esc0's no-psn memory patches. (I implemented it on PS3 Pro and it's very popular function). would be nice to see it on the official release.
• Hen Mode swap (Debug/USB/Release).

Not related to HEN

• A single project for Cobra/HEN with different make files.
• A single xai all-in-one plugin with texts/images stored in xai plugin.rco, currently we have many variants of it such as
  • @Evilnat's from 4.84.3. (misys xai features + nat's ones + rebug ones (not available on his Regular xai plugin from EvilNat 4.88/9))
  • @bguerville extended version (copy,move,delete operations)
  • @mysis s' one .
  • @mysis' poc xai plugin (led control)
  • @esc0rtd3w w's (no-psn patches)

 

[esc0rtd3w]

@esc0rtd3w @bguerville

I'll leave here some suggestions for the next release, some have already been mentioned but I'm putting them together in just one post as i'm seeing more devs coming.

So if anyone is interested in these features, they can also submit a pull request via github.

• Gameboot logo + gameboot sound toggle.
• Custom update server for downloading/updating the hfw via official option.
• Game audio toggle (@in1975 already did it, please if you can, make a pull request)
• Automatic logo swap after enabling hen that disappears after a xmb reload. (fake cfw)
• Updated cobra to 8.30 + mamba 8.4 new features. (Convert save data, fan control, fake act.dat and etc)
• Esc0's no-psn memory patches. (I implemented it on PS3 Pro and it's very popular function). would be nice to see it on the official release.
• Hen Mode swap (Debug/USB/Release).

Not related to HEN

• A single project for Cobra/HEN with different make files.
• A single xai all-in-one plugin with texts/images stored in xai plugin.rco, currently we have many variants of it such as
  • @Evilnat's from 4.84.3. (misys xai features + nat's ones + rebug ones (not available on his Regular xai plugin from EvilNat 4.88/9))
  • @bguerville extended version (copy,move,delete operations)
  • @mysis s' one .
  • @mysis' poc xai plugin (led control)
  • @esc0rtd3w w's (no-psn patches)

Thanks for the suggestion list. I have included the game audio toggle now in current internal beta build, as mentioned by yourself and @in1975.

The automatic logo swap will probably not be done unless we get the refresh working properly, which we are actually testing a few things now, from earlier feedback. Right now, the logo just disappears, as you have done in your "fake cfw".

The HEN mode swap will probably be done in upcoming beta as well.

The custom server HFW update option could also probably be added in upcoming beta, but I've never personally tried it yet.

The NoPSN memory patches could be added to HFW Tools, but they were really just an experiment and were never completed.

The gameboot stuff could be added as a toggle, but that will probably be done after the mappath stuff is completely sorted out.

Adding new cobra features are welcome if anyone wants to take the time to submit a PR.

As far as the merging of cobra/hen projects, that's definitely on the table some day.

And lastly, merging the xai stuff idk how feasible that is currently. The different ones you mentioned kinda do their own thing right now, for different situations.

 

[Coro]

I have included the game audio toggle now

sweet.

 

[LuanTeles]

Thanks for the suggestion list. I have included the game audio toggle now in current internal beta build, as mentioned by yourself and @in1975.

.

Nice =)

The automatic logo swap will probably not be done unless we get the refresh working properly, which we are actually testing a few things now, from earlier feedback. Right now, the logo just disappears, as you have done in your "fake cfw".

.

It doesn't need a refresh, at least only the logo, the xml and tittle will remain the same until a xmb reload, but if we change ENABLE HEN, to HEN EXPLOIT it doesn't need to be refreshed at first, the logo will say wether it's enabled or not.

The HEN mode swap will probably be done in upcoming beta as well.

I'm really exited for it, i'm using it on my mod, but i had to make tons of . audio on/off for debug/retail and usb versions.

I already made a plugin to change the logo and I'm waiting for a kplugin template to load all my remaps, at least I won't need to mess with hen, the user being able to use my modifications while on the official one is cool, less things to care about.

The custom server HFW update option could also probably be added in upcoming beta, but I've never personally tried it yet.

It's really nice i use it with the help of a remap to load the unlocked rco when hen is enabled + webman mod + custom ps3-updatelist.txt. (on cfw i edited the vsh.self)

If we not declare the version in SystemSoftwareVersion=, we can reinstall the same firmware from there too.

The NoPSN memory patches could be added to HFW Tools, but they were really just an experiment and were never completed.

But it's still cool as it is, I know a lot of people who use it.

As far as the merging of cobra/hen projects, that's definitely on the table some day.

This would avoid problems with features that are available there but not here and vice versa.

And lastly, merging the xai stuff idk how feasible that is currently. The different ones you mentioned kinda do their own thing right now, for different situations.

To be honest, Nat's xai plugin included in his Unofficial Rebug 4.84.3 just lacks the no-psn memory patches, @bguerville's copy/move/ operations ( a version with more than 3 operations is still needed, sometimes it freezes with just 2 if the path is too long) and mysis led control.

 

[LuanTeles]

@esc0rtd3w I don't know if it's interesting or not, at least it's not a very popular feature, but if you think it's worth it it would be a nice addition

Just focus on the recently played section (the other tiles are from another mod of my own) , when a homebrew game is launched this section is cleared because the ID is not found in the sony database so I've included 308 new IDS for Homebrews, now they appear there and can be launched from it.

PS3 - Extended "Recently Played" | PSX-Place


Well, now with the mappings working properly I can release it as an add-on.

 

[LuanTeles]

Btw custom what's new would be nice too, (the patch is already in the code anyway)

It could advice when a fw is out, a hen version with changelogs, new bgtoolset version is out and etc

 

[FFF256]

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?

 

[esc0rtd3w]

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?

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.