To quote, roughly translated, on SmallLoader: "TheTool offers a loader used shortcuts in the XMB to rip up a game in the drive without going through virtual BR open the backup manager or manager.
• Edit file game.ini located in the folder PS3_GAME/USRDIR:
• In the path variable, specify the path of your games (Ex: path = / dev_usb000/gamez/BLES12345). You can also delete the line path, smallLoader use the GAME folder which is in USRDIR (just copy your games in that folder).
• In variable autolaunch, enter 1 if you want smallLoader start the game automatically switches to "No AB" and 0 if you want to go back to XMB after the game is installed.
• In the folder PS3_GAME, copy the file ICON0.PNG, PIC1.PNG .....
• Using PS3SFOEdit , edit the file located in PARAM.SFO PS3_GAME
• In "Basic Setting", change the value by that title id you want
• In alt-(default) specify the name of your game
• Click on save and overwrite the old file PARAM.SFO
• Open the file has smallloader.conf using notepad for example.
• In line Product_ID, replace BLES12345 by title id values you have filled in the file PARAM.SFO
• You can save and close this file.
• Now you can generate the PKG file using the command "make_package_npdrm smallloader.conf PS3_GAME /" (without the quotes and the command prompt windows).
• Added fix for the problem of controller.. to enable or disable it, change the line 'fix =' in file game.ini (untested, with no games involved in this problem)
• Added a function to restore the normal functioning of BR player, just run the shortcut by pressing the button .
Note: Sources are also included in the archive.
Finally, from the XMBoot ReadMe file, to quote:
XMBoot is a stripped down backup app which will allow you to create the equivalent of a 360 QuickBoot container. This allows you to create a custom entry on your XMB with the original audio/video from your backup with which you can either boot DIRECTLY into your game (if supported), or mount it for launching via XMB.
To load the original XMB video/icon/sound/etc you will need to copy that content out of the /PS3_GAME/ directory of your backup and place it in the subdir of this package prior to compiling.
NOTE: If using the backups original .SFO file you will need to edit it to report itself as HG (Harddisk Game) rather than DG (Disc Game).
If not using the original SFO from a backup, be sure to edit the included SFO to specify your game title.
Also be sure to edit the package.conf and SFO so that your new package has a unique Title ID.
You will need to set three options in the main.ccp file prior to compiling your package:
game_path is the path to the backup you wish to use
The app does NOT scan for usb device #'s, so you will have to hardcode it to the usb slot you use. direct_boot is the option to attempt launching the EBOOT without booting back into XMB. Does not work with all games, but will let you direct boot games on which it does! use_hermes is an option to apply the Hermes F1/SFIV/etc fix at runtime, doesn't work with every game.
Because these options are stored in main.cpp you MUST recompile in order to change your container setup. These options 'could' be moved to be stored in the SFO file instead, which would allow you to simply edit the SFO instead, bypassing any need for an SDK setup.
Greetings to PS3News. Do not support piracy, purchase the games you love. Winners don't use drugs.
Stay tuned for more PS3 Hacks and PS3 CFW news, follow us on Twitter and be sure to drop by the PS3 Hacks and PS3 Custom Firmware Forums for the latest PlayStation 3 scene updates and homebrew releases!
I did some further testing. I made a second dump of gh4, the files are the same to the dump yesterday. I modified the pcap to elf tool from kakaroto a little bit, so that it's prefix the output files with a number to get the right order they are received over ethernet.
A 14MB file is the first (and almost complete part) of the eboot.bin in decrypted form. It's followed by a 2MB file, which seems to fit direct at the end of the first. Compared to the debug elf of gh4 this seems to be correct. Compared to the encrypted eboot.bin size we are now missing about 1MB. But just adding the next files which were captured didn't work.
I tried to capture a debug eboot.bin from some games i modified to run as a hdd game, but i only got a 3MB dump each time.
Here is a short howto of the steps i've done, maybe someone else will give it a try too.
compiled a hex with the dump_elf_payload from PL3 from Kakaroto
flashed this hex to my jb device
started the Ps3 with this jb device
hooked up my laptop and started wireshark on it
configured wireshark to only log the broadcast messages
connected my laptop with a cross over ethernet cable to the ps3
instered a game to ps3 and selected it in the xmb but i didn't start it yet
started the logging in wireshark and started the game on the ps3
when the game was booted i stopped the logging in wireshark and saved the log to a pcap file
converted the pcap file with Kakarots pcap to elf tool
the biggest file was always the beginning of the eboot.bin and the second seems to fit at the end fo this, like described above
I think if we could identify which of the other generated files are needed and in which order they have to be appended, we should be able to obtain the complete decrypted elf file.
i have the 1.92 SDK installed and working properly, i can compile pkg's with ease.
xmboot will create the open_manager.elf, but i have to manually make it eboot.bin with your tool, then either use your tool or MSYS to create the pkg. Would like to just click the .bat and be able to make the pkg. was hoping to tweak the makefile & get it working properly but for now i have to do the work manually which kinda sucks when you have 40+ games you want to make xmboot shortcuts for... lol
/bin/sh: c:usrlocalcell/host-win32/bin/make_felf.exe: No such file or directory
this seems to be the problem, for some reason its looking in c:usrlocalcell for make_fself.exe. It should be looking in c:\usr\local\cell.