Thread: Let's open up this console!
05-27-2010 #11sapperlott 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:
05-28-2010 #12CodeKiller 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.
06-01-2010 #13sapperlott 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
06-01-2010 #14CodeKiller 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")
06-01-2010 #15sapperlott 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.
06-04-2010 #16CodeKiller 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.