esc0rtd3w
Developer
UPDATE: This has been added to the Open Beta
THIS FEATURE MAY BE CONSIDERED BORDERLINE SKETCHY, AT BEST
First of all, I DO NOT CONDONE OR SUPPORT PIRACY! Lets get that out of the way.
I have been testing a new feature for a couple weeks now, and after lots of tweaking, it seems stable.
Support for rap.bin files has been added to PS3HEN. I would consider this possibly a controversial feature, due to its interaction with RAP files and values, but RAP files are already supported, so it doesnt actually seem too controversial afterall.
GitHub Commit: https://github.com/PS3Xploit/PS3HEN/commit/dc3d659cf51a9853c75b57d19e7de40346cdbeb6
The original idea was to have an easy way to move around rap files and not have to rely on them specifically, but only needing to rely on their values. I know this sounds like piracy, but the feature itself is not. There are many apps that are discontinued or apps like the visualizer that require RAP files to run, including the PSP and PS2 launchers, which are already hardcoded into payload. The default rap.bin file that is currently used only includes these values, which i would not consider piracy, personally.
For example
I would like to get a collection of RAP files to add to the default BIN file that can be considered "OK" and "Not For Piracy". I do understand that people will view this in different ways.
There are 2 scripts that i made to read RAP files to a BIN file, and one script to read the BIN file back out to individual RAP files. It has several checks to verify the Content ID and sizes are valid before adding to bin. It will accept any amount of RAP files as input (root/exdata/)
rap2bin: https://github.com/esc0rtd3w/rap2bin
bin2rap: https://github.com/esc0rtd3w/bin2rap
On the PS3 side, PS3HEN payload checks for the toggle status of rap.bin support and if not enabled, it will continue as normal whenever it is looking for a RAP file, under normal exdata directories. If the toggle is enabled, it will check for the path /dev_hdd0/game/PS3XPLOIT/USRDIR/rap.bin, and if it exists, the current Content ID will be checked against the BIN file, and if the Content ID gets a match, it will use the value from the BIN file. Whenever the same Content ID is used when looking for RAP file, the cached RAP value will be used and not have to read the BIN file again.
In conclusion, if the vote gets a "NO", then i will restore the original make_rif function and not include it officially in next release. If the vote gets a "YES", i will leave it as it currently is, with a toggle and default OFF. It will have to be turned on via HFW Tools, because of a potential slight performance hit (debug version only?) while loading apps the first time (this is a minimal delay that is hardly noticeable from testing various sizes of BIN files)
Be nice now
THIS FEATURE MAY BE CONSIDERED BORDERLINE SKETCHY, AT BEST
First of all, I DO NOT CONDONE OR SUPPORT PIRACY! Lets get that out of the way.
I have been testing a new feature for a couple weeks now, and after lots of tweaking, it seems stable.
Support for rap.bin files has been added to PS3HEN. I would consider this possibly a controversial feature, due to its interaction with RAP files and values, but RAP files are already supported, so it doesnt actually seem too controversial afterall.
GitHub Commit: https://github.com/PS3Xploit/PS3HEN/commit/dc3d659cf51a9853c75b57d19e7de40346cdbeb6
The original idea was to have an easy way to move around rap files and not have to rely on them specifically, but only needing to rely on their values. I know this sounds like piracy, but the feature itself is not. There are many apps that are discontinued or apps like the visualizer that require RAP files to run, including the PSP and PS2 launchers, which are already hardcoded into payload. The default rap.bin file that is currently used only includes these values, which i would not consider piracy, personally.
For example
I would like to get a collection of RAP files to add to the default BIN file that can be considered "OK" and "Not For Piracy". I do understand that people will view this in different ways.
There are 2 scripts that i made to read RAP files to a BIN file, and one script to read the BIN file back out to individual RAP files. It has several checks to verify the Content ID and sizes are valid before adding to bin. It will accept any amount of RAP files as input (root/exdata/)
rap2bin: https://github.com/esc0rtd3w/rap2bin
bin2rap: https://github.com/esc0rtd3w/bin2rap
On the PS3 side, PS3HEN payload checks for the toggle status of rap.bin support and if not enabled, it will continue as normal whenever it is looking for a RAP file, under normal exdata directories. If the toggle is enabled, it will check for the path /dev_hdd0/game/PS3XPLOIT/USRDIR/rap.bin, and if it exists, the current Content ID will be checked against the BIN file, and if the Content ID gets a match, it will use the value from the BIN file. Whenever the same Content ID is used when looking for RAP file, the cached RAP value will be used and not have to read the BIN file again.
In conclusion, if the vote gets a "NO", then i will restore the original make_rif function and not include it officially in next release. If the vote gets a "YES", i will leave it as it currently is, with a toggle and default OFF. It will have to be turned on via HFW Tools, because of a potential slight performance hit (debug version only?) while loading apps the first time (this is a minimal delay that is hardly noticeable from testing various sizes of BIN files)
Be nice now
Last edited:

