Hey there.

So... you use an ad blocker. That's cool. Sometimes we do too.

But without ad revenue, we wouldn't even be here. And we might not be here much longer.

Please disable your ad blocker and click to continue.

  1. #1
    Join Date
    Apr 2005

    PS3MrEnigma on PS3 LV2 Kernel Reversal and Memory Hooks

    Spanish PlayStation 3 developer PS3MrEnigma has recently started a blog (linked above) sharing his experiences with PS3 LV2 kernel reversal and memory hooks.

    Below are the details thus far, roughly translated:

    In this post we will see how to make hooks (hooks) in the LV-2 SYSCALL. The possibilities are endless da hook, only to be limited to our imagination and what we want to achieve with the hook.

    For this section we should bear in mind that we need to meet the following requirements:

    - Having a dump of the entire LV-2, possibly without being modified in any way by a payload.
    - Knowledge of assembler to understand the original SYSCALL to create our hooks.
    - Understand how the / s SYSCALL we will modify.

    For this post'll take the example of a LV-2 3.41 Debug (for it is that I work mostly), but can be applied just as in a LV-2 Retail.

    The first thing you need to know is the beginning of the SYSCALL_TABLE, and the number of SYSCALL we want to put a hook.

    For example put a hook to the SYSCALL 0 × 363 (867) to alter the machine model that we will return.

    The SYSCALL_TABLE is at position 0 × 303130 (at any position in the LV-2 assume that they add the base address 0 × 8000 ...), knowing the number of the SYSCALL (867) and taking into account that each table entry is 8 bytes in the address pointed to multiply 867 * 8 = 6936, so we add that to the SYSCALL_TABLE, 0 × 303130 + 0x1B18 = 0x304C48.

    In this direction we find another memory address, 0x348FB0, we go to the second and we have another memory address, 0x27A368. In this direction starts the code of the SYSCALL. Point out the direction where is the address where the SYSCALL would begin, in this case, 0x348FB4.

    Enter the code in the SYSCALL, knowing that the SYSCALL has 2 parameters, the first command of the operation to be performed and the second a pointer to a buffer to store the result of the call, we can try to see how the SYSCALL.

    The SYSCALL 867 with the command 0 × 19004 returned in the output buffer at position 3 (starting from 0) the byte that indicates the machine model, knowing that we can make our hook inject this value in the output buffer.

    We started writing our hook, for it wrote the preamble to the SYSCALL basing in the original code:

    stdu %sp, -0xB0(%sp) STDU% sp,-0xB0 (% sp)
    mflr %r0 mflr% r0
    std %r30, 0xA0(%sp) std% r30, 0xA0 (% sp)
    std %r31, 0xA8(%sp) std% r31, 0xA8 (% sp)
    std %r29, 0×98(%sp) std% r29, 0 × 98 (% sp)
    std %r0, 0xC0(%sp) std% r0, 0xC0 (% sp)

    Having echo the preamble, we see that we have stored on the stack the registers% r30,% r31,% r29 pudiendolos use for what we need in our hook, as we have in store the Link Register so you could use our hook subllamadas smooth caller to return to the code.

    Need to check that the command you want to modify is the 0 × 19004, so we proceed to create a check:

    lis %r31, 1 lis% r31, 1
    ori %r31, %r31, 0×9004 ori% r31,% r31, 0 × 9004
    cmpw %r31, %r3 cmpw% r31,% r3
    bne _salir_sin_nada bne _salir_sin_nada

    At this point we have two possible flows, which is our command or it may not be. Start by it to be:

    li %r30, 0×85 li% r30, 0 × 85
    li %r29, 1 li% r29, 1

    stb %r29, 1(%r4) stb% r29, 1 (% r4)
    stb %r30, 3(%r4) stb% r30, 3 (% R4)
    stb %r29, 5(%r4) stb% r29, 5 (% r4)
    stb %r29, 7(%r4) stb% r29, 7 (% r4)

    li %r3, 0 li% r3, 0

    ld %r0, 0xC0(%sp) ld% r0, 0xC0 (% sp)
    ld %r29, 0×98(%sp) ld% r29, 0 × 98 (% sp)
    ld %r31, 0xA8(%sp) ld% r31, 0xA8 (% sp)
    ld %r30, 0xA0(%sp) ld% r30, 0xA0 (% sp)
    mtlr %r0 mtlr% r0
    addi %sp, %sp, 0xB0 addi% sp,% sp, 0xB0



    With this code will always let one of the first European Retail submodels.

    Now to implement the code in the event that the command is not checked:

    b (address), here we have to calculate a memory address where the branch is unconditional distance to the target memory address where we go, in this case 0x27A380.

    We will explain the code, if the command was desired, modify the destination buffer filling with a retail eur forced model, the first sub-models, after which he managed the preamble of the function and return without going through the original SYSCALL the SYSCALL caller code.

    In the event that is not the command, do an unconditional jump to the original SYSCALL after its preamble already done in our code, so as the original parameters are untouched, as the SYSCALL finish and proceed to return to its caller, would return to the code the original name as the code itself will correct the preamble SYSCALL ours.

    Once you create the hook, just have to copy it to a memory region in the LV-2 proper, in the case of the debug would begin at 0 × 54408, while retail 0x50B44. Do not forget that the unconditional jump performed at the end of the hook has to be recalculated at the address where the copied.

    Once copied, you need to install the hook so that when the modules call the SYSCALL call our code, in our case as we know where to start our code (0 × 54 408), proceed to write this direction in the second memory address that points that indicate the SYSCALL_TABLE, ie 0x348FB4.

    Once done, any module, homebrew, etc to call that SYSCALL go through our hook, and if the command is 0 × 19004, we will refund a forced Retail Eur.

    For this example, a debug from the XMB produce NO that can launch applications without signing, returning the error VSH not allowed (this problem is patched by PSGROOVE as we will explain in a future post).

    GetSystemParameter (SYSCALL 0x17C (380))

    Hello again to all, in this post we will return to speak about a new SYSCALL including in the list does not publish of the SDK.

    The SYSCALL in particular is 0x17C (or in decimal 380), GetSystemParameter call.

    As its name indicates its function is to obtain the parameters of the system in which it is called.


    The SYSCALL requires 4 parameters, which are 4 local leaders to buffers of each 8 bytes.

    That is to say, for example:

    uint64_t to parameter, parameter2, parameter3, parameter4;

    int ret = system_call_4 (0x17C, to &parameter, &parameter2, &parameter3, &parameter4);

    if (! ret)

    {… blah blah…}

    The SYSCALL returns in %r3 a code of error in problems, or a 0 in case of success. The information, logically, estara kept in buffers.

    Like example, I put a method to know in that system way we are (or Stand-Alone (that is to say Release, retail) or Non-Stand-Alone (or sease Software System)):

    We suppose that we have the same variables that before local, and already we made the call, successfully, being within the conditional one of the success:

    if ((parameter4 & 0×10)! = 0)

    // We are in way of Software System


    // We are in way of Release (normal retail way)

    First of all to consider that the way of Software System is the normal way of use of a machine Debug or Ref Tool, not being available Rep in a Retail.

    By all means other things that can be done, are to know whichever memory has available the machine, if we are in Debugger way (in the case of the Debug or Ref Tool), if we have pressed the button to power for resetear

    the configuration and to enter way normal and to change some config problematic, etc.

    Without doubt a peculiar SYSCALL, another example I practice is to be able to detect the model of machine by means of the code of example of this post, a retail podria not to have the Software System,

    SYSCALL 0×363 (867)

    In this post we will speak of the SYSCALL 0×363 (or in decimal 867).

    A SYSCALL that this in the list does not publish in the SDK, which allows us to conduct an operation of but the interesting thing, to read information about our machine.

    The use that we will give to this SYSCALL in this post informative sera him the one to obtain the machine model, and its subsequent range.


    The SYSCALL requires 2 arguments:

    - The position from that we want to obtain data, in this case the S-value 0×19004, in case the error is not contributed to the devolvera SYSCALL correctly 0×80010002 (Argument I invalidate)

    - A leader to a space in the memory with at least 8 bytes in which sera given back the obtained data to us, in case we do not contribute to this parameter the devolvera SYSCALL the error 0×80010509.

    The SYSCALL us devolvera in %r3 or the code of error, or 0 in case of success, being in the direction of memory contributed in %r4 previously where we will have its information.

    Therefore, the SYSCALL can be used of this form:

    system_call_2 (0×363, 0×19004, to model_buffer); // where to model_buffer it is a local buffer of 8 bytes at least, also can be used 0×19003, but it would change the order of the returned thing.

    Once realised the call, we will happen to verify the result.

    In this case of the model they interest bytes to us 4, 6 and 8.

    In byte 4, or this case of 3 example of model_buffer [], we will have a value of 5 possible ones, that I know at least:

    - 0×81 - > Reference Tool, that is to say machine of development, NOT TO CONFUSE with debug.

    - 0×82 - > Debug Machine, that is to say the machine of testeo and tests.

    - 0×83 - > Japanese Retail.

    - 0×84 - > Retail the USA.

    - 0×85 - > European Retail.

    Simply with this verification already we know to the product model base that our machine has, but everything does not finish here, also we can obtain the submodel within range.

    For this we watched bytes 6 and 8, or in this 7 5 example to model_buffer [] and to model_buffer [].

    - In the case of a Debug of 60 gigas both values tendran 0×1.

    - Byte 6:0 ×1

    - Byte 8:0 ×1

    - In the case of a Reference Tool byte 6 sera 0×9.

    Nevertheless the interesting thing is in the case of the Retail (the few models that I have been able to obtain):

    - Submodelo Phat of 60 Gb (European, with retrocompatibilidad PS2 by Software):

    - Byte 6:0 ×3

    - Byte 8:0 ×4

    - Submodelo Phat of 40 Gb (European, without retrocompatibilidad PS2):

    - Byte 6:0 ×5

    - Byte 8:0 ×1

    - Submodelo Phat of 40 Gb (Japanese, without retrocompatibilidad PS2):

    - Byte 6:0 ×6

    - Byte 8:0 ×4

    - Submodelo Slim of 250Gb (European, without retrocompatibilidad PS2 nor Linux):

    - Byte 6:0 xA

    - Byte 8:0 ×5

    NOTE: In the Debug machines (I also do not know if in the ref Tool) this SYSCALL cannot be used, because devolvera the error 0×80010003 (not implemented).

    Number 9 - Jumper SYSCALL

    As we know to the method of communication between an application homebrew, a game, or any other type of unit of usuary surroundings is realised by means of a call to a system procedure, or also call SYSCALL.

    This procedure allows to call to functions that are only exported of this form by kernel usuary in the LV-2.

    She is for this reason, that me ocurrio the idea to implement a new SYSCALL that allowed with a simple call her to be able “to jump” (of here its Jumper name) to any point that wished of the LV-2.

    The only requirement that is demanded to be able to use it correctly is to know where going and the arguments that were used where we go for a positive result for us.

    Its utility is, then, clear, from homebrew we can call to a function that not this exporting like SYSCALL in the LV-2, to call to another SYSCALL without having to call it directly ofuscando our code therefore, to modify or to create new code soon using other SYSCALL and jumping to that point at any time, etc, the imagination is limits.

    To think of this SYSCALL like a direct open door to any point of the LV-2.


    Any prototype can be used “system_call_x” of the SDK.

    The only requirements are:

    - To place in %r3 (arg1) the memory direction (64bits) to which we want to jump in the LV-2.

    - To place in %r4 - r10 (arg2 - arg9) the arguments that we want to use in the position of the jump in the LV-2, is important to realize that in %r4 we will put the argument that in a direct call to that direction in the serious LV-2 %r3, and so on, %r5 serious %r4 really, etc.

    The SYSCALL would be in charge before making the jump relocate the registries to the correct positions.

    - the SYSCALL returns in %r3 the error 0x8001000D (Direction invalidates) if in %r3 (arg1) we put a null pointer by error, or devolvera in %r3 - %r4…, which gives back the jump realised in the LV-2.

    Of this form we can verify that it is possible to be called from:

    system_call_1 (9, <direccion>); // for a jump to the direction without arguments


    system_call_8 (9, <direccion>, <arg1>, <arg2>….); // for a jump with 7 arguments



    cmpdi %r3, 0
    beq _null_addr

    stdu %sp, -0×10 (%sp)
    mflr %r0
    STD %r0, 8 (%sp)

    mtctr %r3

    mr %r3, %r4
    mr %r4, %r5
    mr %r5, %r6
    mr %r6, %r7
    mr %r7, %r8
    mr %r8, %r9
    mr %r9, %r10


    ld %r0, 8 (%sp)
    addi %sp, %sp, 0×10
    mtlr %r0
    b _exit_9


    lily %r3, 0×8001
    ori %r3, %r3, 0xD



    It is only needed to insert it in payload, and to activate the SYSCALL using the habitual methods.

    More PlayStation 3 News...

  2. #2
    Pcsx2006 Guest
    From this what i understand is that they are making devhook for ps3 just like psp which is just like cfw and you can do many wonderful things with this.. and this is the pathway to cfw, it means we are one more step closer to cfw.

  3. #3
    Join Date
    Apr 2005
    I remember the DevHook PSP days, that said- nice news indeed!

  4. #4
    ricopico Guest
    blimey. This is a hobby?

  5. #5
    Gunner54 Guest
    Quote Originally Posted by Pcsx2006 View Post
    From this what i understand is that they are making devhook for ps3 just like psp which is just like cfw and you can do many wonderful things with this.. and this is the pathway to cfw, it means we are one more step closer to cfw.
    This has got nothing to do with DevHook or CFW... He is simply showing you how to HOOK a SYS FUNCTION using PPC Assembler code.

  6. #6
    cfwprophet Guest
    Gunner54: Yea true he his just explaining...

    But if you combine this method with some nice syscalls to unlock some options like SystemSoftwareMode, ReleaseMode, DebugMode and put some hacked RCO´s with a modified xReg file onto your PS3 you wil have a Retail/Debug Hybrid CFW.

    There are some things they have to be set in the kernel/payload to be able to use it later in a hacked cfw. (to time)

  7. #7
    solrac1974 Guest
    Great news, possible devhooks, future CFW, I like that! PS3 scene is growing really fast!

  8. #8
    drizzt84 Guest
    It's ALL wrong!

    [Register or Login to view code]

    cannot work! system_call_4 is a MACRO!

    you have to do

    [Register or Login to view code]

  9. #9
    Maniac2k Guest
    drizzt84: It's right that his code won't work. But he only used this lines as an explanation how the things work.

    Is there a list where all undocumented syscalls are listed which are already identified so far?

  10. #10
    alexcamrod Guest

    Big Grin

    THIS IS INSANE. I see stuff like this, and it makes my head hurt. I do have to admit i absolutely love this stuff. i wish i could code, and program, and hack, but i can't. I must learn the ways of the coders, the way of the matrix until all you see is... red-head, brunette, blond.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Log in