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.

Page 2 of 2 First 12
  1. #11
    sapperlott Guest
    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
    CodeKiller Guest
    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.

  3. #13
    sapperlott Guest
    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
    CodeKiller Guest
    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
    sapperlott Guest
    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
    CodeKiller Guest
    :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 First 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

Log in