PS3 non NPDRM to NPDRM .sprx resigning

Glad that you found a way. About the other question, I really don't know the answer. I really would like to know it too. Are you interested in it to avoid the space from install data? I tried to avoid it, but without sucess. When I use the game folder as same where the game install, I got an error, probably cause rewrite problem on the files used.
I'm not sure I understand what you are asking. Example I converted motorstorm 1 to NPDRM, original structure was dev_bdvd/PS3_GAME/USRDIR. Inserting any additional bytes to lengthen the name causes game not to boot. Overwriting the blank spaces with more directory name also causes game not to boot. It seems the padding is necessary and the ELF length cannot change at all. So, I am forced to change structure path to dev_hdd0/game/MS1/USRDIR to preserve length.

my question is, why does it behave this way?
 
I'm not sure I understand what you are asking. Example I converted motorstorm 1 to NPDRM, original structure was dev_bdvd/PS3_GAME/USRDIR. Inserting any additional bytes to lengthen the name causes game not to boot. Overwriting the blank spaces with more directory name also causes game not to boot. It seems the padding is necessary and the ELF length cannot change at all. So, I am forced to change structure path to dev_hdd0/game/MS1/USRDIR to preserve length.

my question is, why does it behave this way?

I got it. Well, when you change the path, the game doesnt boot? I've been always using the path "dev_hdd0/game/XXXXXXXX/USRDIR" (where X is the game folder name I want) and works properly.

By the way, are you using HEN? Cause, if its the case, probably your problem is caused by the eboot.bin version. But it can be really quick converted using True Ancestor.
 
I got it. Well, when you change the path, the game doesnt boot? I've been always using the path "dev_hdd0/game/XXXXXXXX/USRDIR" (where X is the game folder name I want) and works properly.

By the way, are you using HEN? Cause, if its the case, probably your problem is caused by the eboot.bin version. But it can be really quick converted using True Ancestor.
How are you able to make that path without changing length of the eboot? I am full CFW, I want games installed as PSN titles for everything though.
 
How are you able to make that path without changing length of the eboot? I am full CFW, I want games installed as PSN titles for everything though.

I see. When I have to change the path bdvd to hdd0, I simply copy the path, select the path to change and then use the option "Paste insert". This way, I know nothing has changed but path. The lenght of the path does not really a thing. You only have to be cautious to do not erase anything but the path. As example I made the same method for Atelier Arland series games, wich one of the games I used the game folder "RORONA", "TOTORI" and "MERURU". Played all the games without a problem.
 
I see. When I have to change the path bdvd to hdd0, I simply copy the path, select the path to change and then use the option "Paste insert". This way, I know nothing but path has changed. The lenght of the path does not really a thing. You only have to be cautious to do not erase anything but the path. As example I made the same method for Atelier Arland series games, wich one of the games I used the game folder "RORONA", "TOTORI" and "MERURU". Played all the games without a problem.
So you have eboots that work with path changed, for example, from dev_bdvd/PS3_GAME/USRDIR (24 characters) to dev_hdd0/game/NPUA30009/USRDIR (31 characters)? You take the new path, highlight the old path, and paste over?
 
So you have eboots that work with path changed, for example, from dev_bdvd/PS3_GAME/USRDIR (24 characters) to dev_hdd0/game/NPUA30009/USRDIR (31 characters)? You take the new path, highlight the old path, and paste over?

Yes, it works properly. I do this way. But as I said I use the Paste insert function. Cause the Paste function can change other things on eboot. Only one extra point on eboot that has changed (except the path) can result in black screen.
 
Yes, it works properly. I do this way. But as I said I use the Paste insert function. Cause the Paste function can change other things on eboot. Only one extra point on eboot that has changed (except the path) can result in black screen.
I think you mean paste write, and not paste insert.

Paste insert will change the length of the file.
 
Yes, it works properly. I do this way. But as I said I use the Paste insert function. Cause the Paste function can change other things on eboot. Only one extra point on eboot that has changed (except the path) can result in black screen.
Ok, cool, I will try inserting new path and see if eboot boots properly. Is there any special command to encrypt the eboot.elf to eboot.bin? I am using command below:
scetool.exe --verbose --sce-type=SELF --compress-data=FALSE --skip-sections=FALSE --key-revision=01 --self-auth-id=1010000001000003 --self-vendor-id=01000002 --self-type=NPDRM --self-app-version=0001000000000000 --self-fw-version=0002004200000000 --self-add-shdrs=TRUE --self-ctrl-flags=0000000000000000000000000000000000000000000000000000000000000000 --self-cap-flags=00000000000000000000000000000000000000000000003B0000000100040000 --np-license-type=FREE --np-app-type=EXEC --np-content-id=UP0105-BLUS30161_00-ETERNALSONATA001 --np-klicensee=72F990788F9CFF745725F08E4C128387 --np-real-fname=EBOOT.BIN --np-add-sig=FALSE --encrypt EBOOT.ELF EBOOT.BIN

I think you mean paste write, and not paste insert.

Paste insert will change the length of the file.

This is what I mean. I have changed length of the file by using insert for adding additional bytes to accommodate for longer path, but it doesn't work. I have overwritten the path and gone into the (padding?) whitespace and that also caused it not to boot. So that is why I am having trouble comprehending how jvmg got it to work with a 31 character path in a 24 character space.
 
Ok, cool, I will try inserting new path and see if eboot boots properly. Is there any special command to encrypt the eboot.elf to eboot.bin? I am using command below:
scetool.exe --verbose --sce-type=SELF --compress-data=FALSE --skip-sections=FALSE --key-revision=01 --self-auth-id=1010000001000003 --self-vendor-id=01000002 --self-type=NPDRM --self-app-version=0001000000000000 --self-fw-version=0002004200000000 --self-add-shdrs=TRUE --self-ctrl-flags=0000000000000000000000000000000000000000000000000000000000000000 --self-cap-flags=00000000000000000000000000000000000000000000003B0000000100040000 --np-license-type=FREE --np-app-type=EXEC --np-content-id=UP0105-BLUS30161_00-ETERNALSONATA001 --np-klicensee=72F990788F9CFF745725F08E4C128387 --np-real-fname=EBOOT.BIN --np-add-sig=FALSE --encrypt EBOOT.ELF EBOOT.BIN

I use this command. I only change the part:

UP0105-BLUS30161_00-ETERNALSONATA001

To match the game I will play. I use this part on package configuration as well. I change it to:


UP0105-BLUSXXXXX(TITLEID)_00-YYYYYYYYYYYYYYYY (16 CHARACTERS I want)

But I don't know it really is needed. I know it works properly.
 
I use this command. I only change the part:

UP0105-BLUS30161_00-ETERNALSONATA001

To match the game I will play. I use this part on package configuration as well. I change it to:


UP0105-BLUSXXXXX(TITLEID)_00-YYYYYYYYYYYYYYYY (16 CHARACTERS I want)

But I don't know it really is needed. I know it works properly.
Yes that is correct I usually change UP0105-BLUS30161_00-ETERNALSONATA001 to UP9000-NPUAXXXX_00-YYYYYYYYYYYYYYYY (NPUA because it is more correct for region 1 NPDRM games)
 
sorry in advance for double post.

Example default path: /dev_bdvd/PS3_GAME/USRDIR/......FILEPREFIX

Replacement via paste WRITE: /dev_hdd0/game/NPUA30009/USRDIR/FILEPREFIX

As you can see the 6 bytes of padding are gone.....really this eboot will still work?

EDIT

It did not work. As I thought, the padding must be preserved.
 
Last edited:
You guys understand that by extending the path string from 25 to 31 characters, you're affetcing 6 bytes that may contain a useful data, right?
And what is more possible - the disc game code is limited to 25 charaters in path to game files, in folder related game.
The reason why the game may run after such a path change is that the game weren't folder related, and you're lucky that in these 6 extra bytes wasn't stored a useful data. In that case there is no need to change the path string - the game will run without it. Like FFXIII for example.
How were you able to generate the package? psn_package_npdrm complains illegal package, InstallDirectory Needs to have TitleID be the same.
by using -n option key in command line.
Code:
psn_package_npdrm -v -n package.conf XXXX12345
 
You guys understand that by extending the path string from 25 to 31 characters, you're affetcing 6 bytes that may contain a useful data, right?
And what is more possible - the disc game code is limited to 25 charaters in path to game files, in folder related game.
The reason why the game may run after such a path change is that the game weren't folder related, and you're lucky that in these 6 extra bytes wasn't stored a useful data. In that case there is no need to change the path string - the game will run without it. Like FFXIII for example.

by using -n option key in command line.
Code:
psn_package_npdrm -v -n package.conf XXXX12345
I figured out the package thing, but is there a way to pack games as NPDRM WITHOUT hex editing eboot to change the reference paths? I am trying to maintain NPDRM structure, but its impossible if games need hex edit eboot path.
 
Sometimes the EBOOT alows to modify the lenght of the path btw, like what i was explaining in this thread
https://www.psx-place.com/threads/psn-liberator.26134/#post-266784

Is just i was converting the game from PKG to ISO
When i was looking at the decrypted EBOOT in the hexeditor i thought that it was not going to work, because the new path needed 1 more character.... but the original path had a few zeroes at his right, so i just tryed and did work

I think what happened in this case is the path is a string aligned to some bytes boundary... lets say aligned to 16 bytes... this means the number of characters in the string needs to be a multiplyer of 16, incase the string is shorter it fills that bytes with zeroes
And there is a function that doesnt knows the exact lenght of the string, and reads the string in blocks of 16 bytes "character by character" until it finds the first zero (null byte)
Dunno, but it seems in dead space extraction is posible to change the lenght of that path
 
Sometimes the EBOOT alows to modify the lenght of the path btw, like what i was explaining in this thread
https://www.psx-place.com/threads/psn-liberator.26134/#post-266784

Is just i was converting the game from PKG to ISO
When i was looking at the decrypted EBOOT in the hexeditor i thought that it was not going to work, because the new path needed 1 more character.... but the original path had a few zeroes at his right, so i just tryed and did work

I think what happened in this case is the path is a string aligned to some bytes boundary... lets say aligned to 16 bytes... this means the number of characters in the string needs to be a multiplyer of 16, incase the string is shorter it fills that bytes with zeroes
And there is a function that doesnt knows the exact lenght of the string, and reads the string in blocks of 16 bytes "character by character" until it finds the first zero (null byte)
Dunno, but it seems in dead space extraction is posible to change the lenght of that path
So in the example of Full Auto Battlelines 2, no PSN version exists. I have decrypted the eboot, section I need to change:

UNRECOGNIZED COMMAND LINE PARAMETER: %s ..../app_home/....../dev_bdvd/PS3_GAME/USRDIR/......FILEPREFIX: %s, size = %



I have tried to rename /dev_bdvd/PS3_GAME/USRDIR/ to /dev_hdd0/game/NPUA30009/USRDIR/, it cannot fit as we see. adding the six ...... after change length, break eboot. paste overwrite kills all the ...... and also doesn't work. I tried also to change to /dev_hdd0/game/%s/USRDIR/ and added an extra 00 after but that did not work either. Surely there is a way to get this working.

Of course, preserving original length of path exactly, everything works fine. example path change: /dev_hdd0/game/FAB/USRDIR/ everything works 100%
 
If you are using HxD copy that chunk of data again with the option in tab [Edit]--->[Copy as]--->[Editor view]
Then paste it to the forum in between [CODE]pasted_text[/CODE] tags
This way we can have a better view of how are located the paddings
 
If you are using HxD copy that chunk of data again with the option in tab [Edit]--->[Copy as]--->[Editor view]
Then paste it to the forum in between [CODE]pasted_text[/CODE] tags
This way we can have a better view of how are located the paddings

Sure. This is the code block I am modifying. Original is pasted as requested below:


Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

008B3F70  2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A  ****************
008B3F80  2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A  ****************
008B3F90  2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A  ****************
008B3FA0  2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A  ****************
008B3FB0  2A 2A 2A 0A 00 00 00 00 2A 2A 2A 20 55 4E 52 45  ***.....*** UNRE
008B3FC0  43 4F 47 4E 49 5A 45 44 20 43 4F 4D 4D 41 4E 44  COGNIZED COMMAND
008B3FD0  20 4C 49 4E 45 20 50 41 52 41 4D 45 54 45 52 3A  LINE PARAMETER:
008B3FE0  20 25 73 20 0A 00 00 00 2F 61 70 70 5F 68 6F 6D  %s ..../app_hom
008B3FF0  65 2F 00 00 00 00 00 00 2F 64 65 76 5F 62 64 76  e/....../dev_bdv
008B4000  64 2F 50 53 33 5F 47 41 4D 45 2F 55 53 52 44 49  d/PS3_GAME/USRDI
008B4010  52 2F 00 00 00 00 00 00 46 49 4C 45 50 52 45 46  R/......FILEPREF
008B4020  49 58 3A 20 25 73 2C 20 73 69 7A 65 20 3D 20 25  IX: %s, size = %
008B4030  64 2C 20 73 74 72 6C 65 6E 20 3D 20 25 64 00 00  d, strlen = %d..
008B4040  50 53 33 20 49 6E 69 74 2E 2E 2E 20 44 4F 4E 45  PS3 Init... DONE
008B4050  21 0A 41 76 61 69 6C 55 73 65 72 20 4D 65 6D 6F  !.AvailUser Memo
008B4060  72 79 20 25 64 00 00 00 49 6E 69 74 69 61 6C 20  ry %d...Initial 
008B4070  46 72 65 65 4D 65 6D 3A 20 25 2E 33 66 6D 20 28  FreeMem: %.3fm (
008B4080  61 66 74 65 72 20 67 63 6D 20 63 6F 6D 6D 61 6E  after gcm comman
008B4090  64 20 62 75 66 66 65 72 20 61 6E 64 20 50 52 58  d buffer and PRX
008B40A0  29 00 00 00 00 00 00 00 50 72 65 47 66 78 49 6E  ).......PreGfxIn
008B40B0  69 74 40 20 25 2E 32 66 00 00 00 00 00 00 00 00  it@ %.2f........
008B40C0  50 6F 73 74 47 66 78 49 6E 69 74 40 20 25 2E 32  PostGfxInit@ %.2
 
Is the same i was mentioning, are strings aligned to 8 (or 16, not sure)
I think the best experiment you tryed is when you replaced /dev_bdvd/PS3_GAME/USRDIR/ by /dev_hdd0/game/%s/USRDIR/
That "%s" means there is a function that should insert a string in that position (with the TITLE_ID)

Only difference i see with the example i mentioned from dead space extraction is in what i wrote the path is /dev_bdvd/PS3_GAME/USRDIR (without the last / at the ending)... dunno try that

Maybe the problem is the function that is supposed to insert the TITLE_ID in the "%s" is not doing it, dunno, i dont have much experience with this
 
Is the same i was mentioning, are strings aligned to 8 (or 16, not sure)
I think the best experiment you tryed is when you replaced /dev_bdvd/PS3_GAME/USRDIR/ by /dev_hdd0/game/%s/USRDIR/
That "%s" means there is a function that should insert a string in that position (with the TITLE_ID)

Only difference i see with the example i mentioned from dead space extraction is in what i wrote the path is /dev_bdvd/PS3_GAME/USRDIR (without the last / at the ending)... dunno try that

Maybe the problem is the function that is supposed to insert the TITLE_ID in the "%s" is not doing it, dunno, i dont have much experience with this
Yes i tried with %s, it doesn't work, which is weird because I see %s being used elsewhere in the eboot. :(

I will try without the / at the end
 

Similar threads

Back
Top