[Release] PSN Maker (5 games supported)

[Kayot]

Since the Project has been completely redone, I'm remaking this first post.

PSN Maker v0.05 -> PSN_Maker005.7z

Source -> PSN_Maker005SRC.7z See Note 1

It has Tooltips for most of the options. It currently supports the following games:

3D Dot Game Hero's - HDD/LP/USB
Armored Core 4 - HDD/LP/USB
Bayonetta - HDD/LP
Naughty Bear - HDD/LP/USB
Sonic's Ultimate Genesis Collection - HDD
Trinity Universe - HDD/LP/USB

HDD - From game id path
LP - Lower path, ex: G/E00000
USB - Runs from USB

You can select where the game install. In the case of LP games, you have to run a program on the PS3 which processes the command.cfg script that preinstalls with the pkg.

You can delete said program after it runs.

You can select to not have data in the PKG file if you wish to FTP it to the system. When doing so it will put the data in a sub folder of where ever this program is ran from with the general location of where the data should go on the PS3. When using USB mode it will put the data into a folder named XMB which goes on the root of the USB device. Make sure to set all of the games you wish to run off of USB to use the same USB slot as there isn't an easy way to see which port it needs after it's installed.

There is a datagrid that will list games that this program supports. To use it, select the drive letter and tell it to scan for games. Then after it freezes for about 15sec's (On a fully pack 2TB drive) you push save list and as long as the data is where it should be, you can quickly process games.

There is a bug with the datagrid, you have to click on the text of the game name, other wise it fails to note the change in the upper boxes.

I've done a bunch of testing, and it should work fine. All current games can be installed to the HDD full path and if you have the HD space I suggest doing so. Otherwise, AC4 runs fine from USB. As do a bunch of the rest.

The program that runs PS3 side can now join files and as such, I can now do games like FF13 and Cross Edge. It doesn't have any really good feedback other than a message that clearly states that it's merging files. It runs a little faster than normal mainly because it jumps into the merge by adding the other pieces to the first piece. So if a file is 4.5GB, the first file will be 3.9GB and the program will only process .6GB instead of the whole 4.5GB.

Please test this out and report back.

[Note 1] The Source Code is in VB.NET and very messing. It doesn't conform to standard practices and is overall a mess. I'm cleaning it up still.

[siggen]

Does this put a link in the xmb so you can launch it from there?

[Kayot]

Update: I've been working on a method to make life easyier for BDVD to PSN with games that have to move their data folder to a shorter path.

**********************************************
MAKE A BACKUP OF THE GAME BEFORE DOING THIS!!!
**********************************************

To use this BDVD to PSN Title maker, you must first select which game you're doing it to in the selection list. Only select one. Then target the PS3_GAME folder of the dumped game.

Currently Supported Games:
3D Dot Game Hero [BLES00875]
Bayonetta [BLUS30367] [Note 1]
Naughty Bear [BLES00945] [Note 2]
Sonic's Ultimate Genesis Collection [BLUS30259] [Note 3]
Trinity Universe [BLUS30535] [Note 1]

Note 1 - This game moves files with an application. Said application shows a console regarding what it is probably doing. This isn't robust as of yet and is being worked on.
Note 2 - This game moves files with an application. Said application only briefly shows a black screen then dumps back to the XMB. There is an issue that prevents the console from showing up for some unknown reason.
Note 3 - When this game is processed, the PSN maker will remove certain files to save space. These files are usually fill files (Nothing but 0's) or interviews.

This program will attempt to copy the contents of the game to this programs location. Hence, make sure there is enough space to copy said game.
If there are special instructions a text file will be created with the same file name as the pkg file with said instructions inside.

This also utilizes an experimental feature. On first run of marked games, a program will run in place of the game that will copy the data folder to the correct folder on the drive. Special notes above.

Basically this will turn a game into one or more pkg files. These pkg files are installed in order. If the game needs files moved, those files are moved the first time the game is ran. After the mover runs the user is dumped back to XMB, but the next time they run the game it will be the game instead of the copier.

There are two know bugs as of now.
1. If the folder (/dev_hdd0/G/GameShortID/USRDIR) exists the data wont copy as the copy function is actually renaming a folder to that folder and will fail if that folder already exists. At that point the user would have to manually move the data.
2. Naughty Bear [BLES00945]- For some reason the console version of the copy program won't work with this game. The no-console version works fine. I'm unable to see what is causing the problem. I hope this is an isolated case. I'm going to need the console for when I start joining files and using 7zip compression. Not for myself, but so the end user knows the system isn't locked up.

I'd like to figure out how progress bars and message boxes are used. Those would be much better then the console is now.

Here is the 0.02 version of the program -> In main Topic Above

==== How this program works ====

I was getting miffed about how every one is trading EBOOT.BIN files that are patched. I was miffed not because of the legality or that kind of crap, but becuase EBOOT.BIN files are freaking huge. It also seems that no one even considered using patch files.

Here's and Example:
Naughty Bear [BLES00945] - Original EBOOT.BIN Size - 21,617,944b
Naughty Bear [BLES00945] - After makeself EBOOT.BIN Size - 6,669,248b

The patch file I used between the steps? 228 bytes. That's right, only 228 bytes. I also have one that's 145 bytes for the Sfo file. For all five games I've done, when the patch data is compressed it's only 1,363 bytes.

If I used all the EBOOT.BIN files, that would be well over twenty megs. To add insult, those EBOOT.BIN files don't compress worth a dam due to already being compressed.

So I made this solution.


The patch is applied with bspatch.exe on both the EBOOT.BIN and PARAM.SFO from premade patch files. The program that moves the data on first launch of the game was made using PSL1ght SDK Tools.

Please test this out. If you wish to help with future development there are a few ways you can help.

Getting Patch Data:
Before Hex editing the EBOOT.ELF, make a copy of it.
After hex editing but before make_self, run bsdiff on the two files, the pre hex edited and post hex edited files.
Do the same for the PARAM.SFO files.

Mention any required steps, such as moving data around. Please adhere to the naming style of G/RNNNNN, G is default, R is region such as UJER, and N is the numbers. Only use this if the data can't be inside the USRDIR directory due to string length. If the string can fit, do that instead, such as 3D Dot Game Hero's can actually use the full path and as such doesn't need to move files.

Working on the Move File App that runs on the PS3:
I'm doing the best I can, but any help would be nice. I'm including the source files below. Please note that I won't explain how to setup the programing environment as there is a good tutorial here -> TutorialInstallebian - PSL1GHT

I also can't help teach anyone how to program in C as I'm still learning. A good source of information is here -> cplusplus.com - The C++ Resources Network

Source Code -> finish_install-source.7z

Working on the NSIS Script:
This one is one I'm doing myself. I pretty much rewrite the entire thing every game so it's not a good idea to get caught up in keeping up. I will release the source, however don't attempt to submit changes as by the time you make them, they're probably irrelevant.

As for me, I'm still looking into adding every game on the list mentioned in the topic. After that, who knows. For now, I'm looking at a joining function option for games with files bigger than 4gb.

[talmagal]

bug report blus30259 doesnt work with method i've tried installing the package file created with this program and all it created was a unsupported data file on the xmb.Ive tried making the package file two different times and i got two different sized files each time neither working
first one was 45 meg second one was 101 megs
idk how much you cut from the game but something isnt being run properly

Works fine with naughty bear though

[Kayot]

Could you ftp the folder out of /dev_hdd0/game/BLUS30259 and check the md5's on them?

/dev_hdd0/game/BLUS30259

705107dc19de5acae0ac87d33aa4d546 *ICON0.PNG
94552796b729d066aa300dfd831c0cf4 *PARAM.SFO
6fe3086bec5391dcd9e6e332297b0080 *PIC0.PNG
6d282fec3238849415db5fedfee0f5c9 *PIC1.PNG
62a3ca99fde0861c582c0c768d76cf52 *PIC2.PNG
0aad59dba6c06f041b8d1e579bda2c32 *PS3LOGO.DAT
a0b5b3f698c99e92e2837f64cf6a9cea *SND0.AT3

/dev_hdd0/game/BLUS30259/USRDIR

858c78d062857bf85d2215f03c52932b *EBOOT.BIN
ba6d5e14a37cab6a7eb0a9be05ae6776 *flog_c.fpg
aceff03d0aea88a8478850defb87a026 *flog_u.fpg

I need to know what went wrong. The EBOOT.BIN may fail, not sure why but the file can be different.

On a side note, could someone send me an md5 checklist for Assissin's Creed [BLES00158] - I'm using the US version which should be identical and I'm getting a data is corrupt message.

[talmagal]

Could you ftp the folder out of /dev_hdd0/game/BLUS30259 and check the md5's on them?

/dev_hdd0/game/BLUS30259

705107dc19de5acae0ac87d33aa4d546 *ICON0.PNG
94552796b729d066aa300dfd831c0cf4 *PARAM.SFO
6fe3086bec5391dcd9e6e332297b0080 *PIC0.PNG
6d282fec3238849415db5fedfee0f5c9 *PIC1.PNG
62a3ca99fde0861c582c0c768d76cf52 *PIC2.PNG
0aad59dba6c06f041b8d1e579bda2c32 *PS3LOGO.DAT
a0b5b3f698c99e92e2837f64cf6a9cea *SND0.AT3

/dev_hdd0/game/BLUS30259/USRDIR

858c78d062857bf85d2215f03c52932b *EBOOT.BIN
ba6d5e14a37cab6a7eb0a9be05ae6776 *flog_c.fpg
aceff03d0aea88a8478850defb87a026 *flog_u.fpg

I need to know what went wrong. The EBOOT.BIN may fail, not sure why but the file can be different.

On a side note, could someone send me an md5 checklist for Assissin's Creed [BLES00158] - I'm using the US version which should be identical and I'm getting a data is corrupt message.

705107DC19DE5ACAE0AC87D33AA4D546 *ICON0.PNG
9719F771E07D0F7FE56CF0F78B51A1AB *PARAM.SFO
6FE3086BEC5391DCD9E6E332297B0080 *PIC0.PNG
6D282FEC3238849415DB5FEDFEE0F5C9 *PIC1.PNG
62A3CA99FDE0861C582C0C768D76CF52 *PIC2.PNG
0AAD59DBA6C06F041B8D1E579BDA2C32 *PS3LOGO.DAT
A0B5B3F698C99E92E2837F64CF6A9CEA *SND0.AT3

16C8D0A099D1EB61023B765C5C060145 *EBOOT.BIN
BA6D5E14A37CAB6A7EB0A9BE05AE6776 *flog_c.fpg
ACEFF03D0AEA88A8478850DEFB87A026 *flog_u.fpg

both the eboot.bin and param.sfo are wrong or the two most important files

[Kayot]

How big was the pkg file you made?

[talmagal]

108mb (113,991,088 bytes )

why under the sfo is the game listed as lg instead of hg for game type

should it be a harddisk game

[Kayot]

That's what I'm wondering. The game in question is BLUS30259, yet the SFO and EBOOT patch failed. I'm wondering why. What was the EBOOT.BIN's MD5 in the game dump, and if you could get the PARAM.SFO MD5 as well that would be great in figuring out what is going wrong.

My original MD5's

6d426983f6c2bc0b57997e20fdf73008 *PARAM.SFO
569230b3d29ea5c27e3f46b747fa21d4 *EBOOT.BIN

My only guess is that there are different versions of the game floating around. If that's the case then the MD5's won't match, and I'll need both your EBOOT.BIN and PARAM.SFO so I can put a new function in my scripts that will check MD5's and patch the correct patch for said version.

I was thinking that might be a good idea for a new feature. Instead of selecting the game, you just select the directory and it will do a hash check and pick the right game. The odd's of two games having the same MD5 is flat out impossible.

[talmagal]

That's what I'm wondering. The game in question is BLUS30259, yet the SFO and EBOOT patch failed. I'm wondering why. What was the EBOOT.BIN's MD5 in the game dump, and if you could get the PARAM.SFO MD5 as well that would be great in figuring out what is going wrong.

My original MD5's

6d426983f6c2bc0b57997e20fdf73008 *PARAM.SFO
569230b3d29ea5c27e3f46b747fa21d4 *EBOOT.BIN

My only guess is that there are different versions of the game floating around. If that's the case then the MD5's won't match, and I'll need both your EBOOT.BIN and PARAM.SFO so I can put a new function in my scripts that will check MD5's and patch the correct patch for said version.

I was thinking that might be a good idea for a new feature. Instead of selecting the game, you just select the directory and it will do a hash check and pick the right game. The odd's of two games having the same MD5 is flat out impossible.

My original MD5

848A979818DDEB241AF17B410E244473 *PARAM.SFO
569230B3D29EA5C27E3F46B747FA21D4 *EBOOT.BIN

Alright its seems the param.sfo that is giving the issue here. Once it is patched and gives a version LG instead of HG.
Ill try ripping another param.sfo off the disc and trying it that way

EDIT: I think i figured out why ur program is messing up as long as it not truly checking the file for a proper md5 hash i might be able to trick it. will report back in a moment

EDIT2:Alright figured out what was wrong and there is something you should change in you file patch if you can.
Dont tell it to count the first letter in the param.sfo(ex.AG+4=EG)Tell it to check the actual letter Then patch from there. My param.sfo was edited some time back for the game to make it a HG game instead of a DG(was trying to get the game running while back) and when u patched it it went from HG to LG instead of DG to HG(exactly 4 letters forward)

What you could do is for the game instead of making it rip all the files give the users a choice is they want to rip the files or not(interviews and stuff)