Thread: HDD encryption
kboot and Petitboot are basically just small embedded Linux systems that load the "real" (second stage) Linux kernel via kexec. You can inspect otheros.bld - it's an image consisting of the kernel and an initrd (use a hex editor to search for the gzip magic 1f8b for the initrd).
A fully loaded XMB can use up to 128MB of system memory and this thing leaves no room to think that there could be any shared usage of the sysmem by the RSX which has it's own dedicated fullspeed memory.
We're not talking about a cheap OEM system with an embedded video subsystem, on short this thing leads me to belive that GPU only minds to it's own business since it doesn't care to have a part into enc/dec process.
Maybe there could be some leakage into the bootstrap that loads original XMB ? For sure it accepts (at least one) plain command.
However the external bootloader accepts an "alternateOS", not only linux and the XMB IS a 'nix system, really similar to MacOsX and to PsP one, I wonder if could be possible and what could happen installing an unsigned XMB as alternate OS.
I wish to have more time to spend on it.
As for the 4MB, it can even be less than that, later models that still supported OtherOS also only featured a 16MB flash, makes things a tad easier to compare (not all that free space)!
sapperlott and moneymaker seem to know a lot. You guys have been working on the ps3? or work for sony?
A noob question but what is the likelihood of removing encryption completely from the ps3? I.e. the system doesn't look for it and accepts decrypted game files. Yes this would be a way off, just curious.
Replace the decryption algo with our own maybe. Btw all that is needed to decrypt information from the elements in the trust system are all stored on the cell chip?
My question, why ? Because the system need space for programs (game) increasingly hungry for memory, in this scenario is hard to believe they've built the machine with some capability of the GPU to share and then have full access to system memory, mainly to the kernel reserved one, at least it's unbelievable for a GPU with 4x64 GDDR3 dedicated modules built-in.
But never say never.
Every device with its own DMA engine can access all of physical memory unless the IOMMU is programmed to intercept it. The GPU uses this for example to fetch textures out of main memory without bothering the CPU. On other architectures only some memory regions are available for DMA transfers (on Linux have a look at /proc/zoneinfo) but on the Cell the whole effective address space is accessible via DMA since DMA is the only way the SPEs can access main memory.
The SPEs got their own DMA engines but since they can be programmed by the user on Linux they most probably are locked down by the IOMMU. The GPU however is under the control of the Hypervisor and therefore might be able do DMA into HV memory. This might have been possible when the devs were able to access the GPU but this hole has since been fixed.
DMA transfers often pose a security risk. See this article about FireWire:
I don't want to crush your hopes but even if parts of the bootloader could be found in RAM they most probably are encrypted. Take a look at this whitepaper on the Cell security architecture:
If you mean likelihood it's about:
W(number of brain at work)x(moneytheyallcanspendonthis/moneyhavespent$ony)
Better I get back to work now.
I don't want to crush your hope too neiter the ones of the thread starter but... first of first there is no encryption/decryption process involved into files written onto HDD apart from the wecancallit Magic-Gate signature process, when the CPU receives data from BD or NIC it doesn't need to encrypt neither decrypt the system data, only to sign every file encrypted or not probably with the above (patented) technology and encrypting the same way user's file that need addictional copyright protection.
Furthermore if there is any enc/dec process there must be somewhere a buffer of memory involved in the process, it can't be done on the fly by SPUs with their 256KB each keeping performance.
This is what apply for MemoryStick but there is room to think the technology applied is the same. http://www.sony.net/Products/SC-HP/c...l20/pdf/tw.pdf
Try to imagine a song singed in a unknown language with a signature that flattens all the levels, unsigning it you can hear and enjoy it instead of hearing a flat noise but still you doesn't know the meaning of the words cause you haven't learned yet the unknown language.
Hope it helps, best whishes, I'm off for now.
Quick blurt -
I know I've asked/mentioned this before (when the shoutbox was up). We need a dev/lucky guy with access to an SEM (Scanning Electron Microscope).. that right there - instant access to everything on the chip.
No bs. It can read data straight from a flash memory card, a processor, hell, even a RFID card. The only thing known to man that an SEM cannot read (from what I know of..) is an Iron Key flash drive.
When the iron key detects the beam, it destroys all data. Pretty much the "detection" takes place before the "retrieval" on the iron key, but luckily, in our case: The CELL does NOT have such a feature.
If we were to put the CELL under an SEM (or the whole ps3, for that matter), we'd have ALL the keys, everything that was hidden to us would be uncovered instantly.
Why no one has done this yet? I don't know. I'm sure it hasn't either. If it was and not released, then disregard this message. But I'm damn sure this isn't the case.
Ya I have a few friends that know people, but I could never ask for that.
Besides - I sold my PS3 last month because I needed a car more
On top of what I just said, if we had it. We'd have it hacked in minutes (well more like weeks).
Modchips, direct access terminals, ect, are out of question here. We need to sniff this thing HARDCORE style.
Instant hacks? Yes.
If you don't understand anything above I'll be happy to explain.
But an SEM, regardless of what ANYONE says, can read from anything (Besides the iron key, LOL).