jack44556677
Member
There are rumors and whispers on this site that this can be done, but has anyone done it who can share the process (or help point me in the right direction)?
If I only had one eboot that was manually path fixed to compare against an unfixed one, I might be able to figure it out that way.... Any ideas where to find that?
Further background for those interested :
https://www.psx-place.com/threads/compatibility-list-psn-to-iso-conversions.1300/#post-28730
In the above thread the author of PSN Liberator, Rudi Rastelli, explains that the reason that many PSN games which are converted to ISO/Folder do not work is because the filepaths referenced in the executable(s) are absolute, rather than relative. As a result, the games are still expecting the game content on the internal HDD and crash/hang/black screen when it is not there. This problem is further described / confirmed by aldostools in the same thread (https://www.psx-place.com/threads/compatibility-list-psn-to-iso-conversions.1300/#post-29882).
Both rudi and aldostools talk about the possibility (though they may be speaking speculatively / theoretically) of changing the absolute filepaths to relative ones in order to fix the problem. However, there is almost no further detail.
Bitsbubba also mentions completing the procedure here (https://www.psx-place.com/threads/compatibility-list-psn-to-iso-conversions.1300/page-2#post-100686), but sadly no details on what that procedure consists of (or has consisted of in the past)
Kayot also mentions this in the faq in this post (https://www.psx-place.com/threads/how-to-turn-a-psn-purchased-game-into-a-iso-game-by-kayot.316/), speaking specifically about integrating DLC/Patches into an ISO. They once again confirm that manual editing of the decrypted eboot.bin is required and that the paths are (often?) utf (have padded 00's between hex characters, effectively for most strings). Still no details on the procedure
My progress (or distinct lack thereof) so far :
I've been looking through eboot.bin (decrypted to elf first, of course!) files in both games that work and games that do not work and I am not seeing anything straightforward to change (as one might hope for and/or expect after reading the descriptions of the problem referenced above). Most filepaths present are in regards to error strings, and not relevant. Of course, I am only looking at them manually using a hex editor. If disassembly or machine code interpretation/modification is required - I'm missing it / oblivious.
Getting a handle on this would be useful for a number of reasons
Edit:
I've found a post here outlining the process for one game. Sadly there is no hardcoded filepath as described in the eboots I am struggling to fix. I am still on the hunt for a solution (perhaps there is another way to store filepaths than what is described in this one post - or perhaps scetool decrypts differently than trueancestor, this seems unlikely though) Here is the post which outlines the process, for others who may go looking for the same : https://www.psx-place.com/threads/psn-liberator.26134/#post-266784
If I only had one eboot that was manually path fixed to compare against an unfixed one, I might be able to figure it out that way.... Any ideas where to find that?
Further background for those interested :
https://www.psx-place.com/threads/compatibility-list-psn-to-iso-conversions.1300/#post-28730
In the above thread the author of PSN Liberator, Rudi Rastelli, explains that the reason that many PSN games which are converted to ISO/Folder do not work is because the filepaths referenced in the executable(s) are absolute, rather than relative. As a result, the games are still expecting the game content on the internal HDD and crash/hang/black screen when it is not there. This problem is further described / confirmed by aldostools in the same thread (https://www.psx-place.com/threads/compatibility-list-psn-to-iso-conversions.1300/#post-29882).
Both rudi and aldostools talk about the possibility (though they may be speaking speculatively / theoretically) of changing the absolute filepaths to relative ones in order to fix the problem. However, there is almost no further detail.
Bitsbubba also mentions completing the procedure here (https://www.psx-place.com/threads/compatibility-list-psn-to-iso-conversions.1300/page-2#post-100686), but sadly no details on what that procedure consists of (or has consisted of in the past)
Kayot also mentions this in the faq in this post (https://www.psx-place.com/threads/how-to-turn-a-psn-purchased-game-into-a-iso-game-by-kayot.316/), speaking specifically about integrating DLC/Patches into an ISO. They once again confirm that manual editing of the decrypted eboot.bin is required and that the paths are (often?) utf (have padded 00's between hex characters, effectively for most strings). Still no details on the procedure
My progress (or distinct lack thereof) so far :
I've been looking through eboot.bin (decrypted to elf first, of course!) files in both games that work and games that do not work and I am not seeing anything straightforward to change (as one might hope for and/or expect after reading the descriptions of the problem referenced above). Most filepaths present are in regards to error strings, and not relevant. Of course, I am only looking at them manually using a hex editor. If disassembly or machine code interpretation/modification is required - I'm missing it / oblivious.
Getting a handle on this would be useful for a number of reasons
- Integration of DLC's (as well as mandatory and/or optional game patches / pre-installations - insdir / ps3_extras) into the iso and requiring no internal hdd space usage or wasted time installing.
- Converting (some) stubborn HDD only games (that did not anticipate the future we live in, where emulated external disc media is essentially/effectively as fast as the internal hdd)
- Fixing stupid/broken games, like monkey island collection for instance, which extracts archive.dat (>1.5gb) contents to hdd1 each and every time the game is run. (in this case, eboot.bin looks to execute self files for the individual games in the collection - and it does not crash until one of those games is loaded - suggesting that the self is the file that actually contains the absolute paths to change and not the eboot. Is that possible? In any case, I can't see anything that looks like the filepaths in any of the decrypted elfs)
Edit:
I've found a post here outlining the process for one game. Sadly there is no hardcoded filepath as described in the eboots I am struggling to fix. I am still on the hunt for a solution (perhaps there is another way to store filepaths than what is described in this one post - or perhaps scetool decrypts differently than trueancestor, this seems unlikely though) Here is the post which outlines the process, for others who may go looking for the same : https://www.psx-place.com/threads/psn-liberator.26134/#post-266784
Last edited:
