jcorrea
PSX-Place Supporter
Yes, it will let compare with the original eboot. If it's modified, this is the problem you are facing.
- Thread starter Zar
- Start date
The EBOOT is modified to load the sprx. It's also worth mentioning that this isn't just a case of me being a noob... Anyone that has the time to try it will have the same problem.
I doubt anyone will, but here's the steps to produce the problem.
1: format ps3 system/hard drive.
2: install any backup manger (except multiMAN).
3: install any game that has a sprx mod menu available.
4: install sprx mod menu (usually just a sprx in /dev_hdd0/tmp and an eboot replacement).
5: mount and launch the game.
The sprx will not load until the eboot is resigned with managunz, or multiman is installed & opened.
I don't feel like many will pay attention to this issue until a more senior member confirms it
Have you read sandungas post properly?The EBOOT is modified to load the sprx. It's also worth mentioning that this isn't just a case of me being a noob... Anyone that has the time to try it will have the same problem.
...
The sprx will not load until the eboot is resigned with managunz, or multiman is installed & opened.
I don't feel like many will pay attention to this issue until a more senior member confirms it
https://www.psx-place.com/index.php?posts/275290
At first glance, what you describe appears consistent with what he tried to explain to you ie no bug but just a badly signed eboot.
Yes. I tested and the eboot is identical before & after mounting with multiman (maybe the permissions get altered). I also have this problem with multiple games, so that kind of rules out the badly signed eboot.
I appreciate people's offer to help, but any explanation I give, everyone doubts me - which further reinforces what I said at the end of my last post.
We are only trying to understand, nothing more.
How do you compare the eboot contents exactly? If multiman resigns on the fly (as sandy suggested), you may not see any difference by checking the mounted file.
Last edited:
I compared the eboot to the one on my usb with winmerge and they were exactly the same. If patches were applied to memory, rather than the eboot file itself, then deleting the eboot, restarting my ps3 and reinstalling it again would bring the issue back. However, this isn't the case (like I've already said).
What patches are we talking about?
Resigning is not patching.
Anyway could we sum up the situation?
1. Using official game files, all games work fine with all backup managers
2. To use the sprx menu with a number of games, you replace the game's eboot with a custom version & that's when problems appear (with all backup managers except multiman).
3. Using Managunz to resign the eboot solves the problem.
Is this correct so far?
And can you provide a few more details such as
Where did you get the custom eboots from?
Did you copy the custom eboots into the game folders after game installation?
What did you use to copy them?
Have you checked the file permissions of the custom eboot.bins?
Have you tried using a backup manager "fix file permissions" feature?
Have you compared the self signatures between the official & the custom eboots?
Have you compared the self signatures between the custom eboot before & after resigning with Managunz?
In multiman how do you mount/launch those games? What settings?
Last edited:
This reply is going to look extremely messy, but hey... you asked.
I don't know what patches. Clearly I used the wrong terminology.
I would love to.
Partly true, except opening multiMAN fixes the problem in other backup managers, despite not appearing to modify any game files.
http://www.mediafire.com/file/364km5fqu98oc5m/%5BCEX_Cobra%5D_The_Galerium_2.6_by_D57R.rar/file
Yes.
ManaGunZ.
Yes.
Yes.
No.
No.
Default/Unchanged.
sandungas
Developer
For an accurate talk you should mention the MD5 of the EBOOT.BIN because this way we are going to see if is the original and when it was modifyed
You can check the MD5 of the original EBOOT.BIN by clicking in the "files" tab in this web http://jonnysp.bplaced.net/
After that, you can use a (nice) feature of managunz that allows to see the MD5 of your file in the PS3... just open the filemanager inside managunz, click square button on top of the EBOOT.BIN to select it, then click triangle to open the file options, and select the option named "file properties"
If your MD5 matches with the info of the web then it means is the original
After that you should make a copy of the original EBOOT.BIN in your PS3 (rename it to EBOOT.BIN.BAK) and do other experiments with it resigning it manually or automatically with multiman, etc...
-----------
Anyway... there is not any bug related with this, the only way to prevent the problem you are mentioning is by forcing the user to resign the EBOOT.BIN of all his games everytime a new game is mounted by the backup manager
And thats not a "fix" but the other way around... it only could bring problems
The best thing we can do to achieve the max compatibility with the whole PS3 game library is to dont modify any of the game files
The original files are always better than any other resigned file because we are not able to replicate the signature methods used by sony
When we resign a file we are really doing something "dirty" (yeah it works, but is because the CFW's and HEN's are ignoring the signature problems)
You can check the MD5 of the original EBOOT.BIN by clicking in the "files" tab in this web http://jonnysp.bplaced.net/
After that, you can use a (nice) feature of managunz that allows to see the MD5 of your file in the PS3... just open the filemanager inside managunz, click square button on top of the EBOOT.BIN to select it, then click triangle to open the file options, and select the option named "file properties"
If your MD5 matches with the info of the web then it means is the original
After that you should make a copy of the original EBOOT.BIN in your PS3 (rename it to EBOOT.BIN.BAK) and do other experiments with it resigning it manually or automatically with multiman, etc...
-----------
Anyway... there is not any bug related with this, the only way to prevent the problem you are mentioning is by forcing the user to resign the EBOOT.BIN of all his games everytime a new game is mounted by the backup manager
And thats not a "fix" but the other way around... it only could bring problems
The best thing we can do to achieve the max compatibility with the whole PS3 game library is to dont modify any of the game files
The original files are always better than any other resigned file because we are not able to replicate the signature methods used by sony
When we resign a file we are really doing something "dirty" (yeah it works, but is because the CFW's and HEN's are ignoring the signature problems)
haxxxen
Developer
@CFW-Us3r
if you running cobra, you can try my eboot loader, which can load game plugins to game process
usage:
put ebootloader.sprx to bootplugins
lput plugin to /dev_hdd0/tmp/MySPRX_menu.sprx
or put txt file to /dev_hdd0/sprx.txt
in sprx.txt put each line the path to your plugin (you can choose name yourself), example
/dev_hdd0/mypath/myplugin.sprx
when game has started, go to ingame xmb and press R1+O to load the game plugin
edit
for hen, the plugin has to be resigned!
also, if you use this, you HAVE to use original EBOOT and no hooked one
if you running cobra, you can try my eboot loader, which can load game plugins to game process
usage:
put ebootloader.sprx to bootplugins
lput plugin to /dev_hdd0/tmp/MySPRX_menu.sprx
or put txt file to /dev_hdd0/sprx.txt
in sprx.txt put each line the path to your plugin (you can choose name yourself), example
/dev_hdd0/mypath/myplugin.sprx
when game has started, go to ingame xmb and press R1+O to load the game plugin
edit
for hen, the plugin has to be resigned!
also, if you use this, you HAVE to use original EBOOT and no hooked one
Last edited:
Before trying this, I just have one question. Say for example, if I have a sprx for both GTA 5 and BO2, and I add both to sprx.txt, will it try to load both when I start a game?
haxxxen
Developer
jup, it will load all available plugins on txt file. just put a special character, i.e. '#', in front of /dev_hdd0 will make it invalid
haxxxen
Developer
thanks for the feedback
I have changed the plugin a bit and updated the previous post, so no more autoloading and now it uses syscall, since all these menus are simply coded using visual studio. you have to press R1+O ingame xmb, to load the plugin and better to wait until game has loaded fully (have added some auto delay). the rest is the same
can you try this one? I do not have the games, nor am I using those game menus (ok, gta5 I have, but not updated and I don't like these menus)
I will add this function to artsMAN as well, so you don't have to run extra plugin. the code is also on my git
why not add function to cobra? I am using it on my own cobra and it works great
Last edited:
thanks for the feedback
I have changed the plugin a bit and updated the previous post, so no more autoloading and now it uses syscall, since all these menus are simply coded using visual studio. you have to press R1+O ingame xmb, to load the plugin and better to wait until game has loaded fully (have added some auto delay). the rest is the same
can you try this one? I do not have the games, nor am I using those game menus (ok, gta5 I have, but not updated and I don't like these menus)
I will add this function to artsMAN as well, so you don't have to run extra plugin. the code is also on my git
why not add function to cobra? I am using it on my own cobra and it works great
I'll let you know the results later today/tomorrow. Thanks for the update
Similar threads
-
PS5 Porkfolio All in One PS5 Utility (Game Library, Backporks, FTP Transfers, Cheats, Saves, Pa- Started by Red
- Replies: 0
-
-
-
PS3 [Tutorial] Update Frankenstein PS3 Firmware That is Too Low to Initialize RSX (< 3.41) (NAND Models)
- Started by byt3swap
- Replies: 0