PS4 News on Facebook! PS4 News on Twitter! PS4 News on YouTube! PS4 News RSS Feed!

  1. #11
    Yeah but that doesn't touch any interesting parts of the SPE. In Linux this is handled by spufs and libspe2 which uses spufs:

  2. #12
    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
    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
    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
    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
    :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.

+ Reply to Thread
Page 2 of 2 FirstFirst 12


Posting Permissions

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