PS3 Running multiple custom system plugins without Cobra (like xai)

DeViL303

DeViL303

Developer
PSX-Place Supporter
Made this discovery yesterday, mentioned it in XMB mods thread, but I think it deserves its own thread as it might not get seen there.

Basically we can replace quite a few unused system plugins with xai type plugins very easily, I have tested this by running 3 variations of the xai plugin on my console at once.

All you need to do is rename the xai plugins to any one of these:
  • strviewer_plugin.sprx
  • hknw_plugin.sprx
  • edy_plugin.sprx
  • wboard_plugin.sprx
  • bdp_plugin.sprx
  • friendim_plugin.sprx
  • sacd_plugin.sprx
  • kensaku_plugin.sprx
  • etc, Im sure there are more. Only tested these few.
Then just call them in the same way as xai_plugin.sprx
Code: 
 <Pair key="icon_rsc"><String>item_tex_ms_icon</String></Pair>
 <Pair key="title"><String>Enable dev_blind</String></Pair>
 <Pair key="module_name"><String>hknw_plugin</String></Pair>
 <Pair key="module_action"><String>enable_devblind</String></Pair>
 <Pair key="bar_action"><String>none</String></Pair>
 <Pair key="lbl_half"><String>1</String></Pair>

Anyway, thats it. Some of those plugins are not needed on 99.9% of consoles such as
strviewer, sacd, kensaku, hknw, and edy plugin, so these are good candidates for replacement.

Note: Strviewer_plugin seems to have issues with actions other than reboots, it
doesn't crash the console, but it kind of hangs on moving wave after performing the
action, the other plugins all work perfectly as xai replacements.
 
Last edited:
aldostools said:
I think strviewer_plugin cause issues because it doesn't have have MOD0 interface in xmb_plugin.
https://www.psdevwiki.com/ps3/Xmb_plugin

BTW do you have the src of the latest xai_plugin? If it can be modified, you just need to add new module_actions to it ;) instead of replace existing plugins.
Click to expand...
Yeah i know all functions can be added to one, but that requires collaboration, where as there could be multiple independent pluginx that dont clash, and at end of day no one is going to use edy plugin are they? Also its nice that they dont need any rco adding, just one file to swap.

I dont have any source, not sure if there is any available in public. I have the original sprx, an extended version bguerville made, and one from overflow fw the bobby must have made.
 
DeViL303 said:
Yeah i know all functions can be added to one, but that requires collaboration, where as there could be multiple independent pluginx that dont clash, and at end of day no one is going to use edy plugin are they? Also its nice that they dont need any rco adding, just one file to swap.

I dont have any source, not sure if there is any available in public. I have the original sprx, an extended version bguerville made, and one from overflow fw the bobby must have made.
Click to expand...

I understand your point, although as the source code of xai_plugin is publicly available here, the requirement for collaboration would be minimal or null. Only some public consensus would be needed, like happens with other open source projects like cobra, mamba, webman, etc.

@bguerville do you have a source code more recent than this code of xai_plugin?
 
oh thats cool there is source.

and yeah, with collaboration, I just meant if for example bobby creates a great xai plugin, its a way to use it alongside what we have now, for example he uses different names for the functions, so just adding his one will break cfw settings functions, but if you add his as edy plugin, then its fine, both sets of functions work.
 
DeViL303 said:
oh thats cool there is source.

and yeah, with collaboration, I just meant if for example bobby creates a great xai plugin, its a way to use it alongside what we have now, for example he uses different names for the functions, so just adding his one will break cfw settings functions, but if you add his as edy plugin, then its fine, both sets of functions work.
Click to expand...

Yes, that would happen if the new hypothetical plugin removes or change in a significative way the existing functions. But if it adds new features and the source code is shared, everyone wins. That is what I'm proposing ;) Although your point is very valid too.
 
Well yeah, for now he just added lots of direct download functions which I wont go into here. Also bobbies xai plugin is only 10kb too, so it doesn't have the functions mysis added I assume (23kb) , extended is 28kb.

Side note: If we get rid of hknw plugin we gain about 3MB of flash space. :)
 
Another thing that's not so important but could be, it would be nice to be able to enable the original xai plugin and use it for something, Im going to have another look. so anyway having another slot like edy plugin for the current xai plugin is handy if that happens.
 
another method to load a custom plugin is to replace sys_audio.sprx and load original sys_audio manually with this sample code (original sys_audio.sprx renamed to sys_plugin.sprx):

Code: 
  int       res;
   int       modres;
   sys_prx_id_t   id=0;
   id = sys_prx_load_module("/dev_flash/sys/internal/sys_plugin.sprx", 0, NULL);
   if (id < CELL_OK)
   {
     {system_call_3(392, 0x1004, 0xA, 0x1B6); } //3xBeep
   }
   res = sys_prx_start_module(id, 0, NULL, &modres, 0, NULL);
   if (res < CELL_OK)
   {
     {system_call_3(392, 0x1004, 0xA, 0x1B6); } //3xBeep
   }
   else
     {system_call_3(392, 0x1004, 0x4, 0x6); } //1xBeep

though it is important that there is no "_sys_ppu_thread_exit" syscall in custom plugin when main thread is loaded, just like with ccapi webMAN.
 
Another day, another discovery. :D

You might find this interesting @sandungas ..

It turns out there are some other plugins like xai that are no longer included in the firmware now, but have partial support still left in, game_plugin.sprx, system_plugin.sprx and videodownloader_plugin.sprx are a few, they are not in 4.84, but they are in earlier firmware.

There are more too, but i keep soft bricking while testing them, so its slow going testing. :)

So far videodownloader_plugin is only one working perfectly as xai replacement, the others have various issues but they are making clicks and doing stuff, so they still have support in the firmware as far as i can tell.

system_plugin.sprx seems to get loaded on boot up, its not a plugin that gets called in the same way as xai, but that could be useful too for fan control for example?.. anyway.. interesting stuff (i think) :)
 
aldostools said:
I think strviewer_plugin cause issues because it doesn't have have MOD0 interface in xmb_plugin.
https://www.psdevwiki.com/ps3/Xmb_plugin
Click to expand...

Not sure if this correct based on new info, that wiki link shows that videodownloader_plugin doesn't have a MOD0 interface either, yet it works as xai replacement perfectly, not important I suppose, but thought I might as well mention it, seems issue with strviewer is unrelated to MOD0, or maybe wiki is wrong about videodownloader.
 
DeViL303 said:
Not sure if this correct based on new info, that wiki link shows that videodownloader_plugin doesn't have a MOD0 interface either, yet it works as xai replacement perfectly, not important I suppose, but thought I might as well mention it, seems issue with strviewer is unrelated to MOD0, or maybe wiki is wrong about videodownloader.
Click to expand...
The original interfaces are replaced when you replace the .sprx
In other words... the .sprx itself creates the interfaces and makes them availables for other parts of the firmware

The "connections" i was mentioning before (that are going to be missing by most of the .sprx) are as example the files inside dev_flash\vsh\resource\explore\xmb\category_***.xml
To make a custom category we need one file in that path "linked" to a .sprx and i dont know how is made in the firmware... but if we repurpose lets say...
dev_flash\vsh\module\ explore_category_tv.sprx
dev_flash\vsh\resource\explore_category_tv.rco
dev_flash\vsh\resource\explore\xmb\category_tv.xml

Then all the "connections" exists in OFW (the ones we could imagine right now, and maybe more that are needed but we cant imagine right now)

littlebalup said:
I like the idea to have multiple small plugins instead of one big.
For example I would love to see a small plugin only to manage the fan. Compatible with non-cobra FW.
Click to expand...

Btw remember this ? https://github.com/jjolano/prxmb
It was not much successfull as far i know, but it was designed to be some kind of "plugin manager" (or a plugin bridge), it passes the control to other plugins
 
Last edited:
sandungas said:
The original interfaces are replaced when you replace the .sprx
In other words... the .sprx itself creates the interfaces and makes them availables for other parts of the firmware
Click to expand...
Ok, there is still some reason i cant replace strviewer with xai (well it works but has a bug), but i can replace tonnes of others. But i suppose there are other variables, maybe I didnt replace rco.. must do some more tests..

I just fkd up during one of my soft bricks lol, I had been using Starbuged which blocks updates from disk, then I installed older 4.81 CEX FW as a bridge as i got stuck in recovery with soft brick and was getting corrupt data error with starbuged pup, then i did a a few module tests on the 4.81 CEX and soft bricked that too, then i went into recovery and thought it was installing Starbuged 4.84 again from USB..But no.. installed 4.50 OFW from GT6 disc!! how annoying. this soft brick cost me 30 minutes. :)

That is annoying thing about QA flagging.. lol, too easy downgrade.
 
DeViL303 said:
Ok, there is still some reason i cant replace strviewer with xai (well it works but has a bug), but i can replace tonnes of others. But i suppose there are other variables, maybe I didnt replace rco.. must do some more tests..

I just fkd up during one of my soft bricks lol, I had been using Starbuged which blocks updates from disk, then I installed older 4.81 CEX FW as a bridge as i got stuck in recovery with soft brick and was getting corrupt data error with starbuged pup, then i did a a few module tests on the 4.81 CEX and soft bricked that too, then i went into recovery and thought it was installing Starbuged 4.84 again from USB..But no.. installed 4.50 OFW from GT6 disc!! how annoying. this soft brick cost me 30 minutes. :)

That is annoying thing about QA flagging.. lol, too easy downgrade.
Click to expand...


When I do testing like what your doing I normally disable qa flag and use custom pups with 9.99 syscons so they install over eachother but there's no way to get out of the 9.99 loop so only the test pups install.
Good idea you have, I found that having only the xai plugin slot was a bit tricky when wanting to use different versions of xai plugin.
Best way in my opinion is like haxxxen said,
What I was working on quite some time ago was having a non cobra boot plugins txt.
The sys init osd (my custom version) would be loaded by the ps3, then read the boot plugins txt file to load any plugins, then load the original sys_init_osd, you could make the custom osd file load as many plugins as exist in the txt file before loading the original osd and continuing on to load vsh.
The bonus of the sys init osd is that it loads before vsh, you can add really useful stuff in there, one example is on my dex versions of cfw the sys init sets the console id target type back to it's original and you can also add fan control into it.

Long story short lol,
Modified sys_init_osd,
Rename original to say sys_plugin_new,
Modified sys_init_osd is loaded by ps3,
It then looks for and reads a boot_plugins_non_cobra.txt,
Loads any and all plugins listed then loads sys_plugin_new.

I used this for loading an sprx that handles console ids, an sprx that handles copying files from usb to dev_blind and an sprx that handles fan control. Although now I just use one big sprx lol.
If you want when I get some free time (probably be couple of weeks) I can look for the project and tweek it for you so that it runs from xai_plugin instead of sys_init_osd then you just have to put your boot plugins non cobra txt in hdd and put your plugins in the txt document like we do with cobra boot plugins txt.
 
Last edited:
Bobby_Downgrades said:
If you want when I get some free time (probably be couple of weeks) I can look for the project and tweek it for you so that it runs from xai_plugin instead of sys_init_osd then you just have to put your boot plugins non cobra txt in hdd and put your plugins in the txt document like we do with cobra boot plugins txt.
Click to expand...
If you get a chance that would be a cool feature, cheers.

Although the way you have it might be better, Would we be able to load an FTP plugin with sys_init_osd do you think? It would be great if FTP would load before vsh as it would make more soft bricks recoverable..

by the way, I wonder could the unused "system_plugin.sprx" slot be used for this instead, so its independent of all official plugins? system_plugin seems to get loaded early in boot process if it exists. Also it has a good name for a job like this. :)
 
Last edited:
DeViL303 said:
If you get a chance that would be a cool feature, cheers.

Although the way you have it might be better, Would we be able to load an FTP plugin with sys_init_osd do you think? It would be great if FTP would load before vsh as it would make more soft bricks recoverable..

by the way, I wonder could the unused "system_plugin.sprx" slot be used for this instead, so its independent of all official plugins? system_plugin seems to get loaded early in boot process if it exists. Also it has a good name for a job like this. :)
Click to expand...

I'm not sure system_plugin is a thing, I think it may be what ccapi's maker renames a file to take another files place, so I think when you install ccapi it renames sys_audio to sys_plugin and takes the place of sys_audio, I think.
The way I use sys_init_osd means if you say install the mamba payload the load chain stays in place so everything gets loaded, apart from mamba nothing else use the init osd.
Yes if we wrote an ftp sprx then it could be loaded from sys_init_osd before vsh and your right you could ftp replace the soft brick culprit file, good idea, I'm sure webmans ftp section could be used for a solo ftp sprx.
 
Bobby_Downgrades said:
I'm not sure system_plugin is a thing, I think it may be what ccapi's maker renames a file to take another files place, so I think when you install ccapi it renames sys_audio to sys_plugin and takes the place of sys_audio, I think.
The way I use sys_init_osd means if you say install the mamba payload the load chain stays in place so everything gets loaded, apart from mamba nothing else use the init osd.
Yes if we wrote an ftp sprx then it could be loaded from sys_init_osd before vsh and your right you could ftp replace the soft brick culprit file, good idea, I'm sure webmans ftp section could be used for a solo ftp sprx.
Click to expand...
Well its just I discovered that old official firmware has a system_plugin.sprx, and If I rename xai_plugin to system_plugin then it partially works, as I can hear a click when I try to perform functions, that tells me that the console is trying to load system_plugin.sprx. If I try this test with the plugin named randomly I get no click..

Also with some tests it was crashing console, but early in boot process before coolboot, so that makes me think system_plugin is a different type of plugin that gets loaded on at boot time before vsh?
 
Last edited:
When the XMB boots is because has been loaded either xmb_plugin.sprx (normal xmb) or xmb_ingame.sprx (this is a "reduced" xmb that appears when you press PS button inside a game). Both contains a list of other .sprx modules that are loaded inmediatly when the XMB starts
This table shows both lists
https://www.psdevwiki.com/ps3/Template:XMB_Indexed_Modules

The list of modules loaded by the "ingame" version of XMB only includes a few.. but the normal XMB contains a lot (and some of them are names used in old firmwares)
In other words... that lists are making the "connections" to load them, you could decrypt it and modify the entries of the list to add custom names (not sure if mysis tryed this at some point, but my bet right now is probably is not going to be enought)

And this is why mysis did choose xai_plugin.sprx as a guinea pig, because the file doesnt exists in modern PS3 firmwares... but the list inside xmb_plugin.sprx is trying to load it (and in the same way this list is trying to load it, probaby there are more functions in the firmware related with it that are still working)

system_plugin appears in that lists too :encouragement: and it works ingame (because appears in both lists)
And btw, the codename is "system plugin" but the module filename seems to be "basic_plugins.sprx", is the info that appears at left column of the table:

codename -> system_plugin
module name -> basic_plugins.sprx
resources name -> system_plugin.rco
 
Last edited:
Hmmm. the fact it works in game could be interesting for something?

Dont like the idea of it linking to basic_plugins though, dam, it would be better if it was still linked to itself. :) So when i was calling it from the xml i was actually calling basic_plugins.sprx instead.

Im just realized the crash (Soft brick) I was getting was due to the rco , not the sprx, if i just add the sprx to the system, no difference really, if I add the system_plugin.rco too, wont boot at all, dont even see coldboot, just blackscreen and soft brick.

That test was with xai rco, renamed, need to try original system_plugin.rco next, after i unbrick :)

Edit: original system plugin rco also crashes system (soft brick with CFW reinstall required), it gets to wave but crashes before coldboot appears, so a little better with the real rco but still no good, at least it proves support is still in the FW for the rco.

How would we go about changing the list to link system_plugin.sprx to itself, instead of basic_plugins.sprx?
 
Last edited:
You must log in or register to reply here.

Similar threads

Back
Top