PS3 [RESEARCH] Downloading all unknown file types to HDD and Flash

That might sounds a stupid question but well : are you sure that device_path means the complete location where the file will be downloaded (full path) ?
Yes, ive tested it , a lot. works 100% to dev_blind/dev_flash2, and it works until 100% on all other paths (with deletion), and it works with background downloading to hdd to 100% with 99% error.

The reason i dont think its related to logical scheme is i can put anything in there.


Test it out, its 2 xmls that work on OFW. :)
 
I think it will be easy to just patch the sprx, disable cellfsunlink or if it's extension check we can always return true
Downloading directly to dev_blind is cool feature that already works, imagine how easy that would make han installer type apps.

It seems to be related to file system, as fat32 is fine on any partition. But it is writing file to dev_hdd perfectly too which is good thing, just stupid check.

By the way, can we mount dev_hdd1? Because that could be used as a cache for files up to 2GB, and is fat32.
 
Downloading directly to dev_blind is cool feature that already works, imagine how easy that would make han installer type apps.

It seems to be related to file system, as fat32 is fine on any partition. But it is writing file to dev_hdd perfectly too. By the way, can we mount dev_hdd1? Because that could be used as cache for files up to 2GB, and is fat32.
Yes dev hdd1 mount is possible obviously. Confirm this if you shut your ps3 off in between file transfer does the incomplete file retain? Does it only delete on 100% download success?
 
Yes dev hdd1 mount is possible obviously. Confirm this if you shut your ps3 off in between file transfer does the incomplete file retain? Does it only delete on 100% download success?
Yes, incomplete file is there if i turn off or crash ps3 during download, or copy it off while still downloading. Also 100% of the file is there if you background download, it just says 99% on XMB, but pkgs work etc, so every byte is there. At least with BGDL it does not delete the file.
 
The third method, is a remap method. This might not work, i just want to see if i can get more info on symlinks, remapping etc.

So, in this method, i have a usb stick set up with the same folder structure as dev_hdd0, so i can browse it freely and choose anywhere in any path, as deep as i want. I could also add a folder structure for dev_flash etc.

The things is, can we remap, so that when i do this, it actually writes to dev_hdd0? Maybe this method is a stupid idea? but my plan was, maybe we could mount fake dev_usb020 for example, with fake folder structure that replicates dev_hdd0, and we could use that as browser for dev_hdd0 then?

So is this possible or worth exploring?

 
Last edited:
  • File is being deleted
  • background download uses random folder
  • must add hard coded paths

About the random folder, have you tried cleaning the folder vsh/task to 0 files/folders each time? Maybe the counter is based in the last folder found.

I see the hard coded paths as a good point, because it forces the user to download to specific paths. Then they can be moved to the final location. I suppose the paths is a XML file that can be edited easily. So if we get to support *.iso, *.pkg and *.pup in specific paths, we can download almost all file types (because these types are file containers).


The third method, is a remap method. This might not work, i just want to see if i can get more info on symlinks, remapping etc.

So, in this method, i have a usb stick set up with the same folder structure as dev_hdd0, so i can browse it freely and choose anywhere in any path, as deep as i want. I could also add a folder structure for dev_flash etc.

The things is, can we remap, so that when i do this, it actually writes to dev_hdd0? Maybe this method is a stupid idea? but my plan was, maybe we could mount fake dev_usb020 for example, with fake folder structure that replicates dev_hdd0, and we could use that as browser for dev_hdd0 then?

So is this possible or worth exploring?

I have used this method before and it works fine. Indeed I added that remap to webMAN.xml long time ago
https://github.com/aldostools/webMA...ts_/updater/pkgfiles/USRDIR/webMAN_EN.xml#L76

It requires to mount a fake /dev_usb000 or plug a pendrive, so the file system detect the /dev_usb000

This is the command it uses: /remap.ps3/dev_usb000&to=/dev_hdd0/packages
 
Last edited:
About the random folder, have you tried cleaning the folder vsh/task to 0 files/folders each time? Maybe the counter is based in the last folder found.
Still seems to count up, even if its the only folder, sometimes it resets, i dont know why. :)

I have used this method before and it works fine. Indeed I added that remap to webMAN.xml long time ago
https://github.com/aldostools/webMA...ts_/updater/pkgfiles/USRDIR/webMAN_EN.xml#L76

It requires to mount a fake /dev_usb000 or plug a pendrive, so the file system detect the /dev_hdd0

This is the command it uses: /remap.ps3/dev_usb000&to=/dev_hdd0/packages
I seen that remap in webman, but that is one folder, can I use it to browse from root like i did in the video, and choose any folder. I suppose I should try remap root, I thought I tried and it would always write to the usb not the hdd.
 
Still seems to count up, even if its the only folder, sometimes it resets, i dont know why. :)


I seen that remap in webman, but that is one folder, can I use it to browse from root like i did in the video, and choose any folder. I suppose I should try remap root, I thought I tried and it would always write to the usb not the hdd.

The /remap.ps3 simply redirects the content of /dev_usb000 to the path that you indicate. In this case /dev_hdd0/packages, but you can change it to root /

BTW have you tried to patching the .sprx listed in the download_plugin? I suspect they are the ones that validate the download and cause the deletion.

Also have you checked with stage2 debug which modules are accessed when the file gets deleted?

EDIT:
By patching the .sprx I mean changing the path to a non-existing one.
 
Last edited:
Yes, incomplete file is there if i turn off or crash ps3 during download, or copy it off while still downloading. Also 100% of the file is there if you background download, it just says 99% on XMB, but pkgs work etc, so every byte is there. At least with BGDL it does not delete the file.
I'll check this out. Seems like there is just an extension check going on. As for han users not being able to utilize this, HAN is temporary, it was never meant to be long term solution. I guess these people can wait ;)
 
I see the hard coded paths as a good point, because it forces the user to download to specific paths. Then they can be moved to the final location. I suppose the paths is a XML file that can be edited easily. So if we get to support *.iso, *.pkg and *.pup in specific paths, we can download almost all file types (because these types are file containers).
Yeah, this is all xml, and we can download ANY file type already to any location, if i hard code the path, which is not an issue. I can hard code every folder on ps3 if we need to. Just the dam deletion bug which we get on dev_hdd0.

True, hard coded paths is ok and good in a way, but being able to browse complete file system dynamically, depending on what exists, is much better. See my remap video.

Can I use webman to mount dev_hdd1 so i can do some tests? I expect dev_hdd1 will work 100% already with no mods.
BTW have you tried to patching the .sprx listed in the download_plugin? I suspect they are the ones that validate the download and cause the deletion.
I have not, and i will try that, thanks for the tip.
Also have you checked with stage2 debug which modules are accessed when the file gets deleted?
No, I have not yet, I will try get that set up too.
 
Off topic: Joonie, I see this in download plugin, i wonder could this be used to mess with spoofing ps3 into treating patch.pup like full.pup or vice versa.

upload_2019-4-11_20-52-7.png


I have discovered that the download_plugin does more than just download, or it can help in other areas, for a start, it allowed me to copy pkgs from the XMB, that was the only file patched in that mod.

That mod is separate to all of these 3 methods. That is method 4, forcing ps3 to treat other file types like videos.
 
Another off-topic: @lmn7 I found the following example in https://www.psdevwiki.com/ps3/Files_on_the_PS3

Do you have time to test it? If it works, it could be interesting for OFW or as an alternative to symbolic links.
Example: mount("CELL_FS_PATH:/dev_hdd0/game/ABCD00000","dummy", "/dev_bdvd/PS3_GAME",0,0,0,0)
I tried, it does work. Though files in folders looked weird for some reason but root directory was fine
Also kernel can distinguish e.g you can't redirect bdvd and expect kernel to load the path lol
 
I tried, it does work. Though files in folders looked weird for some reason but root directory was fine
Also kernel can distinguish e.g you can't redirect bdvd and expect kernel to load the path lol
hmm that's interesting, I tried many variations and not one worked. you sure you were using mount syscall and not sys_map_path?
 
I tried, it does work. Though files in folders looked weird for some reason but root directory was fine
Also kernel can distinguish e.g you can't redirect bdvd and expect kernel to load the path lol

Files in /dev_bdvd are encrypted, maybe it's treating them the same way... I bypass that encrypt calling this syscall in webMAN:
{system_call_1(36, (u64) "/dev_bdvd");} // decrypt dev_bdvd files

Why do you want to redirect bdvd if you already redirected a folder to bdvd with the mount?

Additionally to dummy, have you tried passing other file systems? Like the CELL_FS_UDF for files stored in /dev_hdd0?
 
Last edited:
About the random folder, have you tried cleaning the folder vsh/task to 0 files/folders each time? Maybe the counter is based in the last folder found.

I see the hard coded paths as a good point, because it forces the user to download to specific paths. Then they can be moved to the final location. I suppose the paths is a XML file that can be edited easily. So if we get to support *.iso, *.pkg and *.pup in specific paths, we can download almost all file types (because these types are file containers).




I have used this method before and it works fine. Indeed I added that remap to webMAN.xml long time ago
https://github.com/aldostools/webMA...ts_/updater/pkgfiles/USRDIR/webMAN_EN.xml#L76

It requires to mount a fake /dev_usb000 or plug a pendrive, so the file system detect the /dev_usb000

This is the command it uses: /remap.ps3/dev_usb000&to=/dev_hdd0/packages


O was thinking, If i remap " dev_ntfsX/PS2ISO to dev_hdd0/PS2ISO " could it load my PS2 games from USB in NTFS ?
 
Back
Top