168w ago - Following up on his previous work, today AerialXTweeted that the beginnings of a PS3 LV2 Userland (GameOS) patch framework dubbed Kammy are available for PSGroove linked above at Github or directly below.
To quote: Kammy is a system for loading patches to lv2 (PlayStation 3's Game OS) from a user application, using PSGroove or any other implementation of the exploit that adds the peek/poke syscalls. Kammy was inspired by Treeki's Nintendo Wii game patching system, Kamek.
Building Building Kammy requires three different gcc compiler toolchains.
• gcc: A normal host gcc is required to build the raw2h application.
• ppu-lv2-gcc: Used to compile the loader, only available from Sony.
• ppu-gcc, ppu-binutils: A version of gcc that will compile 64bit PowerPC instructions is required to build the patches. Linux packages can be found on BSC.es. (note: ppu-lv2-gcc may suffice for this, untested)
• xxd: Creating patch bin files requires the xxd tool to be installed.
With these dependencies installed, you can build Kammy by simply cd'ing to the loader directory and running:
Usage Kammy must be used with a payload that supports poke/peek. This includes PSGroove and most of its forks - including my own - among others. To apply a Kammy patch, a loader application must be started on the PS3. This is usually done from XMB from an installed package, or from USB using my PSGroove fork's apploader payload.
Customizing Kammy is made up of two main components:
• lv2: This folder contains the lv2 patches to be built. See the main kammy patch for an example. It is up to the patch to apply any hooks needed to lv2.
• libkammy: This is the basic library that handles the loading of Kammy patches.
The loader/ folder contains an example of using libkammy to load a patch from the lv2 folder.
Notes Internally, Kammy obliderates syscalls 8 and 9, so try not to run it with payloads that provide those syscalls (like my debug payload).
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!
Well, i'm more attracted to what the end result of patching can achieve.
Ok, so the way we run unsigned code with psgroove is because the return value for Hypercall 99 was patched.
Here is a list of Hypercalls that returned the same value as Hypercall 99 when they were called. (LV1_DENIED_BY_POLICY) (wiki.ps2dev.org/?do=search&id=denied):
Hypercalls 62, 63, 99, 137, 138, 167, 168, 200, 201, 209 all returned LV1_DENIED_BY_POLICY , maybe we could benefit from removing the return value of these hypercalls as well ? Maybe it would allow us to do more things, maybe run licensed content ?
I have looked at the patching system used in the payload (described on the ps3wiki) but i do not understand how we can tell that its hypercall 99 that is patched by looking at this :
# ld r4,3848(r2) } Patches return from
# ld r3,32(r28) } Hypercall 99 so that
# std r3,0(r4) } we can launch unsigned apps
I understand that it is patched to 0, LV1_SUCCESS return value, but how can we tell that its hypercall 99 that was patched?
Let's remove all the LV1_DENIED_BY_POLICY returns!
Hopefully we will get a homebrew dashboard soon to replace the XMB, and a payload that auto-boots it. I was never fond of the XMB, and implementing an ftp server into a homebrew dash is much simpler than a background daemon.