Yep. We would have to patch the kernel in order to use syscalls. And syscalls are at this point necessary for existing backup manager.
we have to program a new backup manager without syscalls.
multiman works btw. on 80gb fat pal
What exactly are syscalls? Would patching the kernel be easy to do with all thats been released. It would require modifying the CFW correct?
EDIT: sorry i know what syscalls are now.. "Syscall - In computing, a system call is the mechanism by which a program requests a service from an operating system's kernel."
but would this be easy to modify?
i dont know either many things about it. but syscalls just mounts virtual the "disc" as the normal disc inserted. that was the way why you must have a cd in your drive while playing games.
syscallxx("dev_usb000/gamez/bles128301", "dev_bdvd/") or something like that
i'm just in my education for programmer, but this is not the same
Thanks for the help but would modifying the CFW to modify the kernel be an easy task or would it require additional exploits.
i think it would require additional exploits. we just have to wait if someone managed it without syscalls.
I recall with multiman you could load games directly, since we dont have apps\games above install packages anymore, tho it does not work.. everytime we try launching game without exiting to xmb it is exiting.
could we use the kakarotos cfw with the apps/games thing above pkg installer to do this? or wouldnt it work?
Is there anything that this man canít do? Dean, who brought you multiMAN, the greatest backup manager ever created in the scene is planning to make multiMAN compatible with the latest CFW sensation from Geohot. The ideas came after Dean has tested Geohotís public signing tools with his multiMAN only to find out that it fails. Thatís just not the end of the story though..
I was taking a bath and got some nice ideasÖ apparently while geohot released the signing tools (which donít work for me, but thatís expected since no CLI usage is supplied nor anything useful).
Now as a simple POC (proof of concept) that a game can run without ANY SYSCALLS involved (from internal HDD) I created a small application. Here are the steps:
1) Get a game and write down the game ID (letís say XXXX12345)
2) Copy the game contents to /dev_hdd0/game/XXXX12345 (no PS3_GAME folder involved)
3) Rename /dev_hdd0/game/XXXX12345/USRDIR/EBOOT.BIN to MM_EBOOT.BIN
4) Install the magic MYGAME.pkg (the one I created)
5) Run your game backup from the XMB without a blu-ray game disc inserted and without /app_home or any other mappings (no syscalls used by the small app)
6) Game starts and plays as if it was ran from BD-ROM disc
7) Should you decide to update the game to a later version 2 more steps are requred but you get the general idea.
The good thing is that game saves, tropheys and updates work, since the game is spawned with the original GAME ID.
Btw the Ďmagic appí is just 4 lines of code. Iíll now test a game (Uncharted 2) to check if all is okay when there are ďspecial circumstancesĒ.
Asked whether he will implement eussís method, hereís what he got to say: No, it doesnít require any game EBOOT.BIN modifications. The original, untouched, signed, encrypted game EBOOT.BIN is used.
Not to mention that you canít simply ďreplace dev_bdvd with dev_hdd0/path_to_gameĒ because there is NOT ENOUGH SPACE for the variables used.
And more to his findings on the method. Actually I was using this method for almost a month to test some ideas with NON WORKING GAMES like PriceOfPercia TheForgottenSands. Never thought about it as Ďreal lifeí applicable implementation, since all syscalls and stuff was available via the JB payload. Today it got me thinking. Let me check few other games and Iíll get back to you.
with all this signing and encryption talk, i have a really stupid question.
Ps3 gamesaves, are they like the psp in the sense that they are encrypted via a key on the system? Would it be possable to make an app/homebrew that dissables this or decrypts them as well?