[Update] Install Multiple PKG at Once in OFW become Possible

afaik, install all is a debug setting. I tried this on ferrox. I'm not sure if qa flagging (the button combo, which is needed on ferrox) would have any barring.
 
If you can do it, the bonus would be background download. Very cool feature.

Not sure if you saw my post in the other redirecting pkgs thread but background downloading pkgs is possible, although the process is not as refined as I'd like it to be. It basically involves downloading the pkg with a png file extension then renaming it afterwards.

I would love to look into the pdb files though, and have ran some tests with them but didn't have a lot of success. What you suggested is definitely possible though, in fact there was a tool created back in 2010 called something like PSN demo installer, it can generate custom pdb files. You can of course hex edit the files too if you want.
 
Yes, that is an option, and PKG Linker could handle the PC side of it in theory, rename the pkgs, serve them, and generate the xmls with the png links and exploits for renaming, its just custom exploits to rename the png to pkg that need to be created, I suppose if we had one we could auto generate more easily based on it , that is all that is needed to complete the method really. it could be done.
 
Yes, that is an option, and PKG Linker could handle the PC side of it in theory, rename the pkgs, serve them, and generate the xmls with the png links and exploits for renaming, its just custom exploits to rename the png to pkg that need to be created, I suppose if we had one we could auto generate more easily based on it , that is all that is needed to complete the method really. it could be done.
Yeah I already edited a script to automatically rename the pkgs, currently it only works with one pkg at a time but it can definitely be improved to rename more than one. The way it works atm is you download the pkg as download.png, that is saved into the photo directory. Because the directory name is dynamic based on the date you downloaded the photo, the script automatically grabs the current date and renames the file to /dev_hdd0/packages/download.pkg.
 
Yeah I already edited a script to automatically rename the pkgs, currently it only works with one pkg at a time but it can definitely be improved to rename more than one. The way it works atm is you download the pkg as download.png, that is saved into the photo directory. Because the directory name is dynamic based on the date you downloaded the photo, the script automatically grabs the current date and renames the file to /dev_hdd0/packages/download.pkg.
That is why .p3t might be better, the folder is always dev_hdd0/theme, so its simpler, and same result i think.

Also, there could be an exploit generated for each pkg, so its a 2 step situation, download, then rename, 2 icons on XMB for each pkg basically.
 
That is why .p3t might be better, the folder is always dev_hdd0/theme, so its simpler, and same result i think.

Also, there could be an exploit generated for each pkg, so its a 2 step situation, download, then rename, 2 icons on XMB for each pkg basically.
Yes themes may be the better choice, I just wasn't sure if themes were allowed with the background download method. It isn't a huge problem to do it with png files either, the only issue would be if the pkg was downloaded one day and then renamed on another.

About generating exploits, do you mean editing a base js file and replacing the file paths accordingly, then hosting that on the PKG Linker webserver so it can be accessed on the PS3? If so, we could do that.

I was thinking, since we need to use the silk browser to perform background downloads, maybe an XMB link to open the silk browser with a simple local javascript page containing a textbox for the download link would work. Then the user could fill the textbox with the DL link, hit a button and the download starts, just a thought. There is probably a better way to do it though.
 
es themes may be the better choice, I just wasn't sure if themes were allowed with the background download method. It isn't a huge problem to do it with png files either, the only issue would be if the pkg was downloaded one day and then renamed on another.
I am not sure, either, can you test. logically it should work as themes are bigger than pngs, so if it works for pngs...but you never know.
About generating exploits, do you mean editing a base js file and replacing the file paths accordingly, then hosting that on the PKG Linker webserver so it can be accessed on the PS3? If so, we could do that.
I was thinking, since we need to use the silk browser to perform background downloads, maybe an XMB link to open the silk browser with a simple local javascript page containing a textbox for the download link would work. Then the user could fill the textbox with the DL link, hit a button and the download starts, just a thought.
We can do that aswell, for custom on the fly links, but ideally an app like pkg linker would auto generate all png links and renaming exploits based on a folder of packages, just like it does now, but with renaming and exploits built in too.

The advantage to the bubble method is that its a 1 step process (i think) , just inject the bubble, or install it via served pkg which is even better. so its a better method probably if we can use bubbles, as adding pkg, could be easy as installing a 100kb pkg. and will probably allow icons, and proper pkg info etc in download management. So we should still consider the bubble method too.
 
afaik, install all is a debug setting. I tried this on ferrox. I'm not sure if qa flagging (the button combo, which is needed on ferrox) would have any barring.

Yes i read it the wiki as i mention in previous post in first page
Install package files under debug setting isn't the same as the one on game category. and this can't be done without qa flag.

Maybe possible to unlock the menu without qa flag though.
From what place can we start ?! any ideas !
 
I am not sure, either, can you test. logically it should work as themes are bigger than pngs, so if it works for pngs...but you never know.


We can do that aswell, for custom on the fly links, but ideally an app like pkg linker would auto generate all png links and renaming exploits based on a folder of packages, just like it does now, but with renaming and exploits built in too.

The advantage to the bubble method is that its a 1 step process (i think) , just inject the bubble, or install it via served pkg which is even better. so its a better method probably if we can use bubbles, as adding pkg, could be easy as installing a 100kb pkg. and will probably allow icons, and proper pkg info etc in download management. So we should still consider the bubble method too.

I think the biggest problem with the bubble method is getting the pdb files on the console on the first place. We can do it with pkgs I guess, but what I had in mind was editing the offline rebuild db exploit to instead create those files. I tested this already, it doesn't work. I assume it's because the size of the bytes is too large. If we do this with pkgs it will be a huge mess, we would have to use the ForcedInstallTo pkg parameter which creates an empty entry on the XMB, which requires a database rebuild to get rid of.

To prevent issues with the bubble method, all variables like pkg names would have to be a static length, I'm unsure if this is already the case with pkg linker. Some more testing needs to be done with pdb files for sure.

Edit: I forgot that I did some testing with the make_pkg Python scripts to install pkg files to any location. This does work, and it doesn't create an entry on the XMB. But something went wrong during testing which corrupted all of the contents on my PS3 HDD... this would have to be tested more for sure LOL.
 
@DeViL303

So it looks like it's accessing following plugins when using IPF under debug settings (retail vsh)

Code:
open_path /dev_flash/vsh/module/nas_plugin.sprx
open_path /dev_flash/vsh/resource/nas_plugin.rco
open_path /dev_flash/vsh/resource/qgl/rhm.qrc
open_path /dev_flash/vsh/resource/game_plugin.rco

upload_2019-4-4_16-32-13.png
 
f we do this with pkgs it will be a huge mess, we would have to use the ForcedInstallTo pkg parameter which creates an empty entry on the XMB, which requires a database rebuild to get rid of.
I wouldnt say huge mess, we could have them all using same ID maybe, so its just one blank space, and maybe there is a way to have icon in the blank space somehow. I know its not ideal, its just less "hacky" then renaming pngs, Do we have full download control whenb downloading pkgs as pngs? Like pause resume etc?

Also, we could have pkg linker generate and host exploits to inject the bubbles, so you just have list of exploits instead of list of bubbles. possible you have to install 1 game data pkg first, that contains all the files to be injected
 
@DeViL303

So it looks like it's accessing following plugins when using IPF under debug settings (retail vsh)

Code:
open_path /dev_flash/vsh/module/nas_plugin.sprx
open_path /dev_flash/vsh/resource/nas_plugin.rco
open_path /dev_flash/vsh/resource/qgl/rhm.qrc
open_path /dev_flash/vsh/resource/game_plugin.rco
You mean when you use the install all package files option.

Interesting. I will look as nas_plugin.rco to see if there is any page names i can swap to enable it. Can you look at the sprx for possible patches that could be done with HAN exploit?
 
You mean when you use the install all package files option.

Interesting. I will look as nas_plugin.rco to see if there is any page names i can swap to enable it. Can you look at the sprx for possible patches that could be done with HAN exploit?
for nas_plugin.sprx patches (for cfw) :
* Allow installation of pseudo-retail packages on CEX-DEX
* Allow installation of retail packages on CEX-DEX
* Allow installation of Debug packages
* Disable ECDSA Check

and none of those would work cause the sprx need to be resigned again so no sprx patches on OFW possible for now
 
this is a thread of Bubble pkg make i see last year in psxhax and now i remember it and navigate back to that page @esc0rtd3w can talk about ?
Link : https://www.psxhax.com/threads/ps3-ofw-bubble-maker-for-dtu-method-by-esc0rtd3w.2608/page-2

https://github.com/esc0rtd3w/ps3-ofw-bubble-maker/releases/tag/0.2


View attachment 16159
for nas_plugin.sprx patches (for cfw) :
* Allow installation of pseudo-retail packages on CEX-DEX
* Allow installation of retail packages on CEX-DEX
* Allow installation of Debug packages
* Disable ECDSA Check

and none of those would work cause the sprx need to be resigned again so no sprx patches on OFW possible for now
sprx patches can be done in RAM with exploits like han enabler as far as i know, that is how it enables debug pkgs for example.

@Joonie correct me if im wrong. But we can patch sprx files in RAM cant we?
 
I wouldnt say huge mess, we could have them all using same ID maybe, so its just one blank space, and maybe there is a way to have icon in the blank space somehow. I know its not ideal, its just less "hacky" then renaming pngs, Do we have full download control whenb downloading pkgs as pngs? Like pause resume etc?

Also, we could have pkg linker generate and host exploits to inject the bubbles, so you just have list of exploits instead of list of bubbles. possible you have to install 1 game data pkg first, that contains all the files to be injected

Even when you install the same pkg twice, it creates two empty entries on the XMB, and you can't get an icon (or title) to show up AFAIK. Honestly, renaming pkgs is hacky but it's probably the best solution for now, unless I did more testing with the Python scripts. Problem is, I really don't want to lose all my HDD contents again lol.

AFAIK the background download method turns the download into a bubble when you select background download, I haven't actually tested it myself but this is what I would imagine it would be doing. I think the only background download method the PS3 has uses the bubbles. If that's the case, pausing and resuming should all work fine.

The issue with generating multiple exploits for this is the success rate isn't always reliable, especially when hosted locally with a webserver, You will see the best success through offline local scripts.
 
@DeViL303

So it looks like it's accessing following plugins when using IPF under debug settings (retail vsh)

Code:
open_path /dev_flash/vsh/module/nas_plugin.sprx
open_path /dev_flash/vsh/resource/nas_plugin.rco
open_path /dev_flash/vsh/resource/qgl/rhm.qrc
open_path /dev_flash/vsh/resource/game_plugin.rco

View attachment 16161
So when using Package Manger or old Install Packages Files one sprx,2 rco and qrc files will be called for the installtion to be executed ,right ? we can edit the rco or qrc but we can't apply patch to sprx cause it needs officiel signature and that we don't have it so why won't we make an tools that patch the nas_plugin.sprx externaly like Debug Package Enabler and HAN Enabler cause :
* Allow installation of Debug packages (CFW) = Debug Package Enabler (OFW) for no signed packages
* Allow installation of pseudo-retail packages (CFW= HAN Enabler(OFW) for HAN signed packages
...
 
sprx patches can be done in RAM with exploits like han enabler as far as i know, that is how it enables debug pkgs for example.

@Joonie correct me if im wrong. But we can patch sprx files in RAM cant we?
Yup thats what i am talking about we can't touch the sprx directly but we can get contact with him using external exploit :)
 
Back
Top