PS3 pkg_custom 1.4

aldostools said:
Are you including the PARAM.SFO and ICON0.PNG in the "root" of the CUSTOM folder?

Something like this:
Code: 
CUSTOM
|__ PARAM.SFO
|__ICON0.PNG
|__USRDIR
|    |__EBOOT.BIN
|__dev_hdd0
     |__boot_plugins.txt


Yeap,

Code: 
CUSTOM
|__ PARAM.SFO
|__ PARAM.HIS
|__ICON0.PNG
|__ PIC1_00.PNG
.
.
.|__ PIC1_18.PNG
|__MANUAL
|__USRDIR
|    |__EBOOT.BIN
|__dev_hdd0
     |__.
     |__.
     |__.
Click to expand...

EDIT: Seems like it only works installing the PKG twice, the first time it will install

|__USRDIR
| |__EBOOT.BIN
|__dev_hdd0
|__. content

pg1QqSw.png


and the rest of the content will be in a temp folder game/_INSTALL_date........ and will be only installed if the package is installed again

|__ PARAM.SFO
|__ PARAM.HIS
|__ICON0.PNG
|__ PIC1_00.PNG
.
.
.|__ PIC1_18.PNG
|__MANUAL


you can check the pkg here: https://www.mediafire.com/file/3670rfftoqbh8dv/TEST_-_WORKS_ONLY_INSTALLED_TWICE.pkg/file



BAIYrGM.png

bmTgLoR.png
 
Last edited:
LuanTeles said:
EDIT: Seems like it only works installing the PKG twice, the first time it will install

|__USRDIR
| |__EBOOT.BIN
|__dev_hdd0
|__. content

and the rest of the content will be in a temp folder game/_INSTALL_date........ and will be only installed if the package is installed again

|__ PARAM.SFO
|__ PARAM.HIS
|__ICON0.PNG
|__ PIC1_00.PNG
.
.
.|__ PIC1_18.PNG
|__MANUAL
Click to expand...

It looks like your issue is because your PKG is installing by default in PS34KPROX and you have also dev_hdd0/game/PS34KPROX in the same package. It is causing a conflict because the PKG is copying to the same folder twice.

If I recall correctly, when you install a game, the game folder is first renamed to _INST_timestamp, then the folder is renamed back to the original game folder. But as you're copying to that folder using the directory traversal exploit (../../..), the folder exists and the folder _INST_ cannot be renamed back to the original name, because the folder already exists.

Move the folder dev_hdd0/game/PS34KPROX/USRDIR/TOOLBOX in the PKG to USRDIR/TOOLBOX.
 
aldostools said:
It looks like your issue is because your PKG is installing by default in PS34KPROX and you have also dev_hdd0/game/PS34KPROX in the same package. It is causing a conflict because the PKG is copying to the same folder twice.

If I recall correctly, when you install a game, the game folder is first renamed to _INST_timestamp, then the folder is renamed back to the original game folder. But as you're copying to that folder using the directory traversal exploit (../../..), the folder exists and the folder _INST_ cannot be renamed back to the original name, because the folder already exists.

Move the folder dev_hdd0/game/PS34KPROX/USRDIR/TOOLBOX in the PKG to USRDIR/TOOLBOX.
Click to expand...


I can't believe that was the problem :facepalm:

I thought about it, but as some package was working so I discarded the possibility, until i realized that they worked because in the second go it install just the missing files.

Thanks ALDO , you're a life saver :P

I wasted about 5 days on it.
 
I've been testing pkg_custom.py on linux, and I believe I found a couple of bugs in the code.

First of all, when I try to extract the pkg of Apollo Save Tool, I get a "segmentation fault" from the compiled pkgcrypt.so. Using gdb, I tracked down the error to line 360 of pkg_custom.py, when calling the crypt method. Inside crypt.c the error occurs in line 57. I noticed that input[offset] would eventually overflow since offset eventually increases to a value greater than the size of input, thus the segmentation fault. I think this is happening because crypt is taking in as a variable the filesize rather than the data size from the header in line 360, and so the program will try to access memory beyond reach.

Apollo Save Tool extracts normally using the original pkg.py with the crypt method using the size from the header. However, I'm not sure why length is being passed to the crypt function at all. Couldn't the size of the input array be used directly on the loop? Or is the length passed to the crypt function expected to be less than input? I'm not sure if it is required to change crypt.c in this case. Though, keep in mind I am not very familiar with the code nor the pkd structure.
 
AlexRhine said:
I've been testing pkg_custom.py on linux, and I believe I found a couple of bugs in the code.

First of all, when I try to extract the pkg of Apollo Save Tool, I get a "segmentation fault" from the compiled pkgcrypt.so. Using gdb, I tracked down the error to line 360 of pkg_custom.py, when calling the crypt method. Inside crypt.c the error occurs in line 57. I noticed that input[offset] would eventually overflow since offset eventually increases to a value greater than the size of input, thus the segmentation fault. I think this is happening because crypt is taking in as a variable the filesize rather than the data size from the header in line 360, and so the program will try to access memory beyond reach.

Apollo Save Tool extracts normally using the original pkg.py with the crypt method using the size from the header. However, I'm not sure why length is being passed to the crypt function at all. Couldn't the size of the input array be used directly on the loop? Or is the length passed to the crypt function expected to be less than input? I'm not sure if it is required to change crypt.c in this case. Though, keep in mind I am not very familiar with the code nor the pkd structure.
Click to expand...
Must be specific to Linux or an issue with aldo's extraction optimizations. I have older code that extracts the pkg just fine (more specifically, code that extracts pkgs in chunks regardless of the size, rather than extracting the entire pkg if the size is reasonably small).
 
AlexRhine said:
I've been testing pkg_custom.py on linux, and I believe I found a couple of bugs in the code.

First of all, when I try to extract the pkg of Apollo Save Tool, I get a "segmentation fault" from the compiled pkgcrypt.so. Using gdb, I tracked down the error to line 360 of pkg_custom.py, when calling the crypt method. Inside crypt.c the error occurs in line 57. I noticed that input[offset] would eventually overflow since offset eventually increases to a value greater than the size of input, thus the segmentation fault. I think this is happening because crypt is taking in as a variable the filesize rather than the data size from the header in line 360, and so the program will try to access memory beyond reach.

Apollo Save Tool extracts normally using the original pkg.py with the crypt method using the size from the header. However, I'm not sure why length is being passed to the crypt function at all. Couldn't the size of the input array be used directly on the loop? Or is the length passed to the crypt function expected to be less than input? I'm not sure if it is required to change crypt.c in this case. Though, keep in mind I am not very familiar with the code nor the pkd structure.
Click to expand...

Thank you for the bug report. The issue was in the size parameter of the call to crypt() function in lines 332 and 360..
It was working fine with other packages, but for some reason that package of Apollo returns a pkgData smaller than the fileSize.

Here is the updated source code with the fix.
 

Attachments

aldostools said:
Thank you for the bug report. The issue was in the size parameter of the call to crypt() function in lines 332 and 360..
It was working fine with other packages, but for some reason that package of Apollo returns a pkgData smaller than the fileSize.

Here is the updated source code with the fix.
Click to expand...
Thanks for the fix Aldo.

By the way, for anyone wanting to run pkg_custom.py on Linux, here's the steps you need to take.

1. Install Python 2.7 and gcc
2. Compile pkgcrypt.c as a python extension (pkgcrypt.so). Grab setup.py from psl1ght's version of pkgpy, rename pkgcrypt.c as crypt.c, and run "python2.7 setup.py build_ext". The created binary will be inside the build/lib folder from your path. Now replace pkgcrypt.pyd with your pkgcrypt.so. Alternatively, you could also just use the makefile from psl1ght's pypkg and switch crypt.c with pkgcrypt.c from Aldo's source (renaming it to crypt.c).
3. Inside pkg_custom.py, remove "import msvcrt". It's only used inside the wait() function to ask for a user's input when a problem is encountered, so it won't break the program. You'll then need to either leave the wait function empty, or delete the function and remove any calls to it.

After that, you should be able to run pkg_custom.py without any problems using python2.7.

PSL1GHT's pypkg: https://github.com/ps3dev/PSL1GHT/tree/master/tools/ps3py
 
Last edited:
I wonder if we can install avatars via custom package, how download an avatar is installed by official means? as it installs to the current user home folders.
 
Fedor Wearing A Fedora said:
@aldostools you might have seen it, but there is also a python3 version ps3py available here.
Click to expand...

Thank you for the link. That version of the script looks like the original pkg.py

The one that I linked in my repository is based on the fork of @lmn7 with several optimizations and features added.

I feel comfortable with python 2.7, so I don't find necessary to port it to 3.0. Maybe someone with free time could port it.
 
aldostools said:
Thank you for the link. That version of the script looks like the original pkg.py

The one that I linked in my repository is based on the fork of @lmn7 with several optimizations and features added.

I feel comfortable with python 2.7, so I don't find necessary to port it to 3.0. Maybe someone with free time could port it.
Click to expand...

you're correct, it is the original version and not the lmn7 version. Besides the obvious syntax changes the C module is also rewritten to read/write/convert the binary data as it is accepted in python3. I made a py3 version of pkg_custom somewhere during the summer last year. I think there aren't many differences in the C module between the link i send to you and my version. I think i can port pkg_custom 1.4.7 to py3 this weekend...would you also like the compiled .pyd and .so files?
 
You must log in or register to reply here.

Similar threads

Back
Top