PS3 [SOLVED] Can I load Mamba from "OFW" on CFW compatible models ?

aldostools said:
I uploaded the commit with the changes for the PoC (and other improvements to Mamba)
https://github.com/aldostools/Mamba/commit/79e0bdedacf902bec839edf155267c3192107e41

The way I implemented the partial redirection in map_path() it is possible to remap the entire /dev_flash or any other folder / subfolder.

Example: /remap.ps3/dev_flash/vsh&to=//dev_hdd0/shadow_vsh
or /remap.ps3/dev_flash/vsh/resource &to=//dev_hdd0/shadow_resources

If the file doesn't exist in hdd0, then the original file in /dev_flash is used.

If the redirection doesn't cause issues, something like this could be added in main.c:
map_path("/dev_flash", "//dev_hdd0/flash", 0);
Click to expand...
I need to avoid remappings because I wish the shadow directory to contain only the customised files the user wishes to use at any given time, every path not found in shadow dir would get processed in /dev_flash by default.

I am not sure yet but I think I can only do that by stat-ing the path at runtime whenever a path gets opened.
 
bguerville said:
I need to avoid remappings because I wish the shadow directory to contain only the customised files the user wishes to use at any given time, every path not found in shadow dir would get processed in /dev_flash by default.

I am not sure yet but I think I can only do that by stat-ing the path at runtime whenever a path gets opened.
Click to expand...

The stat is precisely what I implemented. The files in the shadow folder are optional.
I use the variable avoid_recursive_calls to prevent recursive calls to open_path_hook when cellFsStat is used inside the hook.

Here is the snippet that I added years ago to open_path_hook to implement the seek in the "shadow" path
Code: 
#ifdef DO_PARTIAL_MAP_PATH
// -- AV: use partial folder remapping when newpath starts with double '/' like //dev_hdd0/blah...
if(map_table[i].newpath[1] == '/')
{
    CellFsStat stat;
    if(cellFsStat(map_table[i].newpath, &stat) != CELL_FS_SUCCEEDED)
    {
        #ifdef DEBUG
        DPRINTF("open_path %s\n", path0);
        #endif
        avoid_recursive_calls = 0;
        return; // Do not remap / Use the original file when redirected file does not exist
    }
}
#endif

Here is that code in github's mamba repository:
https://github.com/aldostools/Mamba/blob/master/stage2/mappath.c#L401-L415
 
aldostools said:
The stat is precisely what I implemented. The files in the shadow folder are optional.
I use the variable avoid_recursive_calls to prevent recursive calls to open_path_hook when cellFsStat is used inside the hook.

Here is the snippet that I added years ago to open_path_hook to implement the seek in the "shadow" path
Code: 
#ifdef DO_PARTIAL_MAP_PATH
// -- AV: use partial folder remapping when newpath starts with double '/' like //dev_hdd0/blah...
if(map_table[i].newpath[1] == '/')
{
    CellFsStat stat;
    if(cellFsStat(map_table[i].newpath, &stat) != CELL_FS_SUCCEEDED)
    {
        #ifdef DEBUG
        DPRINTF("open_path %s\n", path0);
        #endif
        avoid_recursive_calls = 0;
        return; // Do not remap / Use the original file when redirected file does not exist
    }
}
#endif

Here is that code in github's mamba repository:
https://github.com/aldostools/Mamba/blob/master/stage2/mappath.c#L401-L415
Click to expand...
Yes that's exactly where I would stat the path ie in LV2_HOOKED_FUNCTION_POSTCALL_2(void, open_path_hook, (char *path0, int mode))

In short & at this stage I cannot say whether it would be sufficient but what I am thinking about doing is to first, when the hook is called, manipulate the path argument to reconstruct the equivalent path in the shadow directory, then stat that resulting shadow path, if the path exists & it is a file, then I would swap the path argument with the shadow path.
Then after, the existing remapping code would get executed, something along those lines so that remappings aren't impacted by the shadow directory.

Edit: sorry I just realise now reading the code, I think the stat would have to go in a precall hook to open_path, not in a postcall hook. Like I said I need to look closer.

Btw not sure if you know this, you might already but just in case, when adding calls like stat, log to file/tty for debugging or whatever to this kind of lv2 hooks, the kernel might panic & the system crashes even though the code is legit, very often it is a kernel stack related issue, the kernel thread is basically running out of stack space to accommodate the execution of extra code we add, when this happens you can solve the issue with an extend_kstack call.
 
Last edited:
bguerville said:
Edit: sorry I just realise now reading the code, I think the stat would have to go in a precall hook to open_path, not in a postcall hook. Like I said I need to look closer.

Btw not sure if you know this, you might already but just in case, when adding calls like stat, log to file/tty for debugging or whatever to this kind of lv2 hooks, the kernel might panic & the system crashes even though the code is legit, very often it is a kernel stack related issue, the kernel thread is basically running out of stack space to accommodate the execution of extra code we add, when this happens you can solve the issue with an extend_kstack call.
Click to expand...

I don't think it should be a precall hook, because the code basically checks if the file opened exists in the shadow folder.
If it doesn't exists, it aborts the hook. If the file exists in the shadow folder, it performs the map as in the original code.

The variable avoid_recursive_calls is used to prevent the recursive calls that could cause out of stack space error in kernel.
Maybe it also needs extend_kstack(0); but as I mentioned earlier, I haven't done much tests of that code.
 
And for safety, aside from the stat code in the precall hook, whenever the shadow file is a sprx or self we could also rename that shadow file temporarily just after open_path & rename back when the load_module & equivalent function for self has succeeded.
That way after a crash caused by loading a shadow custom executable file, the system will automatically use the OFW version.

We could also use a config file system to decide the shadow root directory at runtime & turn on/off the shadow feature entirely.

It's only ideas at this stage but I think the concept is sound, that kind of system could mature nicely with time.
 
Last edited:
bguerville said:
And for safety, aside from the stat code in the precall hook, whenever the shadow file is a sprx or self we could also rename that shadow file temporarily just after open_path & rename back when the load_module & equivalent function for self has succeeded.
That way after a crash caused by loading a shadow custom executable file, the system will automatically use the OFW version.

We could also use a config file system to decide the shadow root directory at runtime & turn on/off the shadow feature entirely.

It's only ideas at this stage but I think the concept is sound, that kind of system could mature nicely with time.
Click to expand...

The way I implemented the added features to sys_map_path (syscall 35), they do not require configuration files.
They uses the standard parameters. Each mapped path is capable to perform a "standard map", "shadow path" or a permanent map.

Examples:
sys_map_path("/dev_bdvd", "/dev_hdd0/VIDEOS"); <= standard mapping: path starts with /
sys_map_path("/dev_hdd0/game", "//dev_usb000/GAMEI"); <= shadow path: path starts with //
sys_map_path("/dev_flash/sys/external/libaudio.sprx", "/./dev_hdd0/tmp/libaudio.sprx"); <= permanent map: path starts with /./
 
aldostools said:
The way I implemented the added features to sys_map_path (syscall 35), they do not require configuration files.
They uses the standard parameters. Each mapped path is capable to perform a "standard map", "shadow path" or a permanent map.

Examples:
sys_map_path("/dev_bdvd", "/dev_hdd0/VIDEOS"); <= standard mapping: path starts with /
sys_map_path("/dev_hdd0/game", "//dev_usb000/GAMEI"); <= shadow path: path starts with //
sys_map_path("/dev_flash/sys/external/libaudio.sprx", "/./dev_hdd0/tmp/libaudio.sprx"); <= permanent map: path starts with /./
Click to expand...
Then I suppose you already have all you need to deploy shadow XMB files once Mamba is loaded, you don't need to add any extra code, you just need to be able to load Mamba in order to start using the shadow XMB files.

Am I wrong then in assuming that you could already just swap CoreOS OFW/HFW & CFW and use a shadow directory to load OFW XMB, CFW XMB or some hybrid XMB?
The shadow directory contents & the CoreOS you use could be used strategically to enable/disable Cobra/Mamba ie for instance have stage2.bin.bak in a Cobra CFW & Mamba autoloader set up...
Or you might also use a standard CEX CFW CoreOS & only Mamba.
 
Last edited:
bguerville said:
Then I suppose you already have all you need to deploy shadow XMB files once Mamba is loaded, you don't need to add any extra code, you just need to be able to load Mamba in order to start using the shadow XMB files.

Am I wrong then in assuming that you could already just swap CoreOS OFW/HFW & CFW and use a shadow directory to load OFW XMB, CFW XMB or some hybrid XMB?
The shadow directory contents & the CoreOS you use could be used strategically to enable/disable Cobra/Mamba ie for instance have stage2.bin.bak in a Cobra CFW & Mamba autoloader set up...
Or you might also use a standard CEX CFW CoreOS & only Mamba.
Click to expand...

I think the "fake OFW" using the modified Mamba payload does what I was looking for.

The modified XMB items don't bother me and I don't need the official CoreOS since the main purpose was PSN, not development.

I still have to experiment, but I guess that if I put the official lv2_kernel.self in the tool used by Evilnat to test Cobra, it would load the OFW lv2 kernel and it would be another method to have OFW although I don't know if it would support the "fake OFW" Mamba.

About the "shadow directories" for VSH resources (sprx, rco, xml, etc) I still have to experiment, but that's not a priority for me right now.

EDIT:
Loading the OFW lv2_kernel.self didn't work. The loaded installs the lv2 kernel, but when it reboots to load it the system shows an error screen. It reboots again to the original kernel.

The sys_map_path feature for "shadow directory" works fine redirecting /dev_hdd0 folders.
However /dev_flash redirection list the files fine from /dev_hdd0, but when I load them they I get that the file does not exist for the new files. The existing files read the ones from /dev_flash.

If I add a double / at the end of the folder, the system freezes :confused:o_O

However, the individual files redirection works fine.

I was testing the "shadow directory" using this web command:
/remap.ps3/dev_flash/vsh/resource/theme&to=//dev_hdd0/test

Something cool is that adding / to the end of both path, we list the original folder but we get the files from the "shadow directory" when the file exists. Example:
/remap.ps3/dev_hdd0/packages/&to=//dev_usb000/updated_pkgs/
 
Last edited:
aldostools said:
@bguerville I did some tests but they failed.. I edited the post above.
Click to expand...
I see.
I think more tests are needed but I am pretty sure it is feasible.

I spoke briefly with esc0 yesterday, he said that HEN v1 used to rely on a full shadow directory ie with all the dev_flash files deployed in it so, even though it was not implemented the way I would do it, that concept has already been used successfully before, I had already walked out on HEN development at that point which explains why I wasn't aware of it.
 
Last edited:
bguerville said:
I see.
I think more tests are needed but I am pretty sure it's is feasible.

I spoke briefly with esc0 yesterday, he said that HEN v1 used to rely on a full shadow directory ie with all the dev_flash files deployed in it so, even though it was not implemented the way I would do it, that concept has already been used successfully before, I had already walked out on HEN development at that point which explains why I wasn't aware of it.
Click to expand...

I don't know what's wrong in my tests... in works with hdd0. The issue is only with ./dev_flash.

Maybe it works and the way I'm validating the test is what is failing.
The mapped files are listed fine. The error happens when I try to download the files (it could be some bug in the http server),
 
SpaceAgeHero said:
Hi guys,
will this bring any benefits for Super Slim users?
Click to expand...

No. HEN users already boot on OFW mode.

CFW users always have CFW syscalls enabled (with Cobra enabled or disabled).
What I have been researching is a way to boot without CFW syscalls, so it is not required to keep pressing R2+TRIANGLE everytime.

"boot_fake_ofw.pkg" provides practically the same PSN safety features than PSNpatch. It is not better or worse.

Unlike the dual-boot FW this has the option to re-enable CFW features without reboot or fan control handled by kernel payload (so it's not required to launch webman or other fan control plugins).

However, this is not a pure OFW solution like dual-boot FW, due lv1/lv2 kernels is still from CFW:
- Homebrews are blocked by the payload, but they are actually playable if they are whitelisted or if they use official game ids.
- VSH & kernel plugins also work if loaded through boot_plugins_nocobra.txt or mamba_plugins_kernel_nocobra.txt
- The rap auto-activation from hdd0/exdata works too because it's handled by the kernel payload.
- XMB modifications are still present (pkg install, CFW Tools, webMAN games, etc.)
- CFW features are re-enabled just entering to System Update through XMB Settings.

I think this alternative can be useful for users that mainly use PKG games, retail discs or mainly use the PS3 to watch movies.
 
Last edited:
aldostools said:
No. HEN users already boot on OFW mode.

CFW users always have CFW syscalls enabled (with Cobra enabled or disabled).
What I have been researching is a way to boot without CFW syscalls, so it is not required to keep pressing R2+TRIANGLE everytime.

"boot_fake_ofw.pkg" provides practically the same PSN safety features than PSNpatch. It is not better or worse.

Unlike the dual-boot FW this has the option to re-enable CFW features without reboot or fan control handled by kernel payload (so it's not required to launch webman or other fan control plugins).

However, this is not a pure OFW solution like dual-boot FW, due lv1/lv2 kernels is still from CFW:
- Homebrews are blocked by the payload, but they are actually playable if they are whitelisted or if they use official game ids.
- VSH & kernel plugins also work if loaded through boot_plugins_nocobra.txt or mamba_plugins_kernel_nocobra.txt
- The rap auto-activation from hdd0/exdata works too because it's handled by the kernel payload.
- XMB modifications are still present (pkg install, CFW Tools, webMAN games, etc.)
- CFW features are re-enabled just entering to System Update through XMB Settings.

I think this alternative can be useful for users that mainly use PKG games, retail discs or mainly use the PS3 to watch movies.
Click to expand...

Aldo, How about a HENish alternative for CFW, it boots without CFW syscalls enabled, no plugins support and etc, just like a OFW

And we add a item on the XMB to ENABLE CFW via xai plugin that will enable everthing
 
LuanTeles said:
Aldo, How about a HENish alternative for CFW, it boots without CFW syscalls enabled, no plugins support and etc, just like a OFW

And we add a item on the XMB to ENABLE CFW via xai plugin that will enable everthing
Click to expand...
How would your custom xai_plugin be able to load and enable CFW features from OFW (without custom executable support)?

This might be doable if you could activate fself support from OFW but that would require kernel patches which themselves imply other low level patches, in other words a custom CoreOS ie CFW!

It might be possible to limit the required customisations to lv1 (and whatever lower level patch(es) needed to load a custom lv1.self) only in theory, this would need to be investigated and tested, it would be quite stealthy overall although still easily detectable from userland code unfortunately as CoreOS files can be hashed and compared to expected OFW values.
If this worked, we could consider a lv1 payload concept similar to what Cobra can do with lv2, it could be useful for other purposes too such as ps2emu runtime modding.
 
Last edited:
LuanTeles said:
Aldo, How about a HENish alternative for CFW, it boots without CFW syscalls enabled, no plugins support and etc, just like a OFW

And we add a item on the XMB to ENABLE CFW via xai plugin that will enable everthing
Click to expand...

I don't think that is necessary:
- boot_fake_ofw.pkg already boots with CFW syscalls disabled.
- If you don't want the plugins, just remove boot_plugins.txt and mamba_plugins.txt. I don't see why we should remove a feature that isn't a known cause for banning.
- To re-enable CFW syscalls you just have to enter to System Update and exit.

If you want to re-enable with an icon in Game column, install xai_plugin from Evilnat and add this to your XML:
<view>
<Table key="cobra_create_syscalls">
<Pair key="icon_rsc"><String>tex_cobra_syscalls</String></Pair>
<Pair key="title_rsc"><String>msg_create_syscalls_title</String></Pair>
<Pair key="info_rsc"><String>msg_create_syscalls_info</String></Pair>
<Pair key="module_name"><String>xai_plugin</String></Pair>
<Pair key="module_action"><String>create_syscalls</String></Pair>
<Pair key="bar_action"><String>none</String></Pair>
<Pair key="lbl_half"><String>1</String></Pair>
</Table>
<Item class="type:x-xmb/module-action" key="cobra_create_syscalls" attr="cobra_create_syscalls" />
</view>

This option is already found in Evilnat's CFW 4.88.2 CFW Tools > Cobra Tools

BTW all the kernel patches, mappath, hooks are applied.
In summary it is like start Cobra and press R2+△ immediately after boot.

bguerville said:
How would your custom xai_plugin be able to load and enable CFW features from OFW (without custom executable support)?
Click to expand...
In the case of boot_fake_ofw.pkg the mappath & hooks are in memory.
In open_path_hook there is a custom condition that creates the CFW syscall hooks when /dev_flash/vsh/module/software_update_plugin.sprx is accessed.

So there is no need for custom executable support. The CFW syscalls can be re-enabled internally by the payload when that event is triggered.

I could have used other trigger method, but I chose it because the system update is an option not frequently used and easy to access from the XMB menu (it's the first option in the Settings menu).
 
Last edited:
So now I changed my hdd hard drive to ssd as soon as I turn on my PS3, it tells me to plug in a controller, then after to do the update 4.91 or +.
As soon as I do "start" + "select" it tells me "Verification in progress please wait ..." and it lasts, it lasts but nothing!
If anyone has a solution please
 
You must log in or register to reply here.

Similar threads

Back
Top