Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16



  1. #11
    Registered User sapperlott's Avatar
    Join Date
    Nov 2009
    Posts
    129
    Yeah but that doesn't touch any interesting parts of the SPE. In Linux this is handled by spufs and libspe2 which uses spufs:

    http://lxr.linux.no/#linux+v2.6.34/arch/powerpc/platforms/cell/spufs/spu_save.c
    http://lxr.linux.no/#linux+v2.6.34/arch/powerpc/platforms/cell/spufs/spu_restore.c

  2. #12
    Senior Member CodeKiller's Avatar
    Join Date
    Nov 2009
    Posts
    130
    Ok, so that is completely useless in terms of access, because these needs normal exit of SPE-threads..

    Then take a look at the ps3-flash-util. It can access at least the flag of the os-selector. Maybe it can be more useful with some modifications.

    Sorry, it's just access the /dev/ps3flash.. nothing too hidden there.
    Last edited by CodeKiller; 05-28-2010 at 08:12 PM Reason: Automerged Doublepost

  3. #13
    Registered User sapperlott's Avatar
    Join Date
    Nov 2009
    Posts
    129
    Exactly - there's nothing sensitive on the Linux side of the fence. To get to the interesting stuff you'll have to patch the HV calls in the hypervisor (which is made possible via the exploit).

    How about your PPC assembler skills? Unfortunately, mine are severely lacking

  4. #14
    Senior Member CodeKiller's Avatar
    Join Date
    Nov 2009
    Posts
    130
    Butbutbut-- you can call with C/++. I'm currently looking forward to experiment with the open_device call... sadly it's looks like kernel-level so it's maybe too restrictive (but still lacking my "dev-machine")

  5. #15
    Registered User sapperlott's Avatar
    Join Date
    Nov 2009
    Posts
    129
    Maybe I didn't make myself clear enough. There's very little possibility that you can achieve something useful / interesting by using the standard HV calls available to the Linux side. That's what the HV is for - to make sure you don't do anything Sony doesn't want you to.

    To actually do stuff that Sony wouldn't be all too happy about, you'll have to patch the routines that are called within the HV when you fire off a HV call from the Linux side. Since your only way of knowing what's happening on the HV side is slapping a memdump of the HV in the disassembler of your choice (e.g. IDA) you better know your PPC assembler since that's what you'll be working with.

    BTW that's exactly what the exploit is doing. It inserts two new HV calls into the Hypervisor - lv1_peek/poke by writing the raw machine code strings (peek: 0xE86300004E800020 / poke: 0xF8830000386000004E800020) into the HV memory and creating entries pointing to that code within the HV call table. But instead of adding new calls, you can also patch existing ones.

  6. #16
    Senior Member CodeKiller's Avatar
    Join Date
    Nov 2009
    Posts
    130
    :facepalm: ok, now i get it why the asm..

    But still it needs some C/++ to track down where to start tampering. Then if we (i) reach the limitations of the HV, we can do the patching.
    For the asm the IDA has a very useful feature called auto comment, making the code much more readable so it doesn't need so much asm-knowledge to understand.

 


 
Page 2 of 2 FirstFirst 12