04-06-2010 #51Banned User
- Join Date
- Mar 2008
awsome work. very nice.
How about using a network shell with the ps3sdk instead of linux to dump the level 2?
Exploration Pic by Demonhades:
However each system has it's own Achille's heel, if the isolated SPU cannot be manipulated in regular ways it doesn't mean it has not the ability to decrypt it's own content if it should be feeded to the SPU itself through the normal channel, it's "isolated" between quotes cause it actually decrypts everything is /needed/feeded ...if introduced in the right way....
Next step is to dump the SPU cache, it's a pain, I admit it... but bare metal assembler code it's really powerful... maybe it's not impossible...
SPU Isolation is a hardware feature - not much you can do about it in software (even if it's written in Assembler ).
Isolated my rear, let we say it only executes fixed tasks (among which there is also one task we could like to show Kanna her's system is not forced to be unbreakable cause everyone thinks it's unbreakable...
By "hardware" it means it should not be any bus connections between the SPU and the rest of the processor and you have to connect directly on the SPU bus to reach it... and this is not true...cause actually it performs action (de/cypher) on data that runs "through" it... if it were truly isolated it could act only as an hardware replacement protection...
Furthermore there is no hardware that runs by itself "without" software, and both of them could be initialized someway and what proprietary software can also self written LM can...
Yeah, it's a very secure system but's not WrathofGod-proof...
It CAN be found an appropriate use for it's potential, believe me or not, unfortunately I'm not at the level to gain more out of this my idea, specially in theese ones that are hard times for me.
So, any ideas how to start making a better dump? At least telling kernel to not to use first 36 MB of RAM?
Well - here's how I understand it after reading through the docs (and spufs sources):
When an SPU enters isolation mode, it fetches the encrypted / signed (with the hardware root key) binary (normally a loader) from memory (via DMA) into its Local Store, decrypts it there and runs it. When in isolated mode, only a very small window of its Local Store is accessible through DMA by the other components (other SPUs, PPU, RSX, etc) while outbound DMA requests aren't restricted.
The rest of the Local Store is protected and can only be accessed by the code running on the isolated SPU itself. So if the programmer of the isolated SPU code isn't a complete idiot and does perform proper sanity checks on the (probably malicious) data that enters the SPU through that window there's very little chance to mess with it.
The IBM isolation loader for example expects you to write the memory address where the encrypted binary (to be decrypted by the loader code already running) resides into the accessible Local Store window. After doing so the SPU fetches the encrypted binary via DMA, decrypts it into the inaccessible regions of its Local Store and runs it. It seems plausible that METLDR uses a similar mechanism.
I'd be interested in how you think this could be circumvented without the keys necessary to create own signed / encrypted binaries.
So in order to have such tight control over memory allocation I guess one would have to patch the hypervisor.