Sponsored Links

Sponsored Links

Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 60



Thread: HDD encryption

  1. #41
    Registered User sapperlott's Avatar
    Join Date
    Nov 2009
    Posts
    129
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by moneymaker View Post
    ..and.. for the GPU it's not mandatory to have access to system memory if this is what you meant, for sure not to the reserved memory for example, unless there is something I miss.
    The GPU has its own DMA engine allowing it to access RAM without the CPU even noticing it. That's where the IOMMU comes into play. If it's properly set up it will intercept such unwanted access. But if it's not you can program the GPU to access memory regions that the CPU can't.
    Quote Originally Posted by moneymaker View Post
    ... maybe this lack of shadowing could somehow explain the not sky-high performance of every 'nix system I've seen so far kicked into that box.
    My guess would be that this is because of the very limited amount of RAM and because Linux runs only on the not so spectacular PPU. The dual PowerXCell 8i blades sold by IBM also don't break any speed records running Linux as long as no SPEs are used by programs specifically optimized to do so.
    Quote Originally Posted by moneymaker View Post
    For sure many tries with a very specifically built kernel, crafted on purpose on the machine itself, have already be done, I'm sorry if my clue was pointless but I do believe the only way to decrypt HDD (and everything else before as well) is through a similar path.
    Well - the OtherOS bootloader stored in those 4MB of flash doesn't have anything to do with HDD encryption since the OtherOS partition on the HDD isn't encrypted.

    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).

  2. #42
    Registered User moneymaker's Avatar
    Join Date
    Dec 2009
    Posts
    120
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by CJPC View Post
    Yeah, for what its worth, the PS3 Linux bootloader is stored in the cell_os_ext_area (or something along those lines) on the flash of the system. Its a 4mb area, that gets mounted as dev/sda or /dev/sdb (depends on your system). You can write to it to update the bootloader, if you so please. There are also a few flags in there, for video mode, region, and what system (PS3 or OtherOs) to boot on well, next boot.

    As for getting code to survive the reboot, most chances of that were killed with 2.10, as there was preliminary hope witjh stuffing code in the GPU, but not much came from it.
    Quote Originally Posted by sapperlott View Post
    The GPU has its own DMA engine allowing it to access RAM without the CPU even noticing it. That's where the IOMMU comes into play. If it's properly set up it will intercept such unwanted access. But if it's not you can program the GPU to access memory regions that the CPU can't.
    That's why I don't believe RSX which has it's own 256 embedded MB of GDDR3 and nothing to do with encryption could access system memory which is 256/(512 on some debug ones)MB and for sure include a reserved area, while SCC which is bond to SPE through FlexIO could know something since SPE is (probably?) directly involved into M2 decryption and many other things.

    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.
    Quote Originally Posted by sapperlott View Post
    Well - the OtherOS bootloader stored in those 4MB of flash doesn't have anything to do with HDD encryption since the OtherOS partition on the HDD isn't encrypted.

    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).
    Well, actually we're speaking about a 4MB partition into the 256(128+128)MB NAND in which resides the firmware, the initial bootloader and maybe even the extended BIOS of the machine, whether or not the last one could be shadowed onto system RAM it has to be discovered.

    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.

  3. #43
    Toucan Sam CJPC's Avatar
    Join Date
    Apr 2005
    Posts
    2,174
    Sponsored Links
    Sponsored Links
    Quote Originally Posted by moneymaker View Post
    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.

    Well, actually we're speaking about a 4MB partition into the 256(128+128)MB NAND in which resides the firmware, the initial bootloader and maybe even the extended BIOS of the machine, whether or not the last one could be shadowed onto system RAM it has to be discovered.
    Two quick notes I suppose - now (in current FW's) the kernel only uses about ~16-24MB of memory (plus modules, of course), but that is what is sanctioned off as "kernel memory".

    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)!

  4. #44
    Contributor semitope's Avatar
    Join Date
    Feb 2009
    Posts
    605
    Sponsored Links
    Sponsored Links
    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?

  5. #45
    Registered User moneymaker's Avatar
    Join Date
    Dec 2009
    Posts
    120
    Quote Originally Posted by CJPC View Post
    Two quick notes I suppose - now (in current FW's) the kernel only uses about ~16-24MB of memory (plus modules, of course), but that is what is sanctioned off as "kernel memory".
    Every newer firmware till now seemed to use lesser memory but's not about how much memory the system use for the kernel "now" but at the beginning, thinking at the fact the harware is the same and they cannot change it after sold but they can change the amount of memory needed by the kernel ...and this is what's happened every new firmware.

    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.
    Quote Originally Posted by CJPC View Post
    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)!
    Yep, those versions (till CECHQxx) keeps only bootloaderS on the flash and installs everything else on the HDD... and... ...good thing, those ones are "battle-model" not rare collector items.

  6. #46
    Registered User sapperlott's Avatar
    Join Date
    Nov 2009
    Posts
    129
    Quote Originally Posted by semitope View Post
    sapperlott and moneymaker seem to know a lot. You guys have been working on the ps3? or work for sony?
    Not for Sony
    Quote Originally Posted by moneymaker View Post
    ... 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.
    Again - this is just how DMA works:
    [Register or Login to view links]

    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:
    [Register or Login to view links]

    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:
    [Register or Login to view links]

  7. #47
    Registered User moneymaker's Avatar
    Join Date
    Dec 2009
    Posts
    120
    Quote Originally Posted by semitope View Post
    sapperlott and moneymaker seem to know a lot. You guys have been working on the ps3? or work for sony?
    No, I don't, my business run through another path.
    Quote Originally Posted by semitope View Post
    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.
    If you mean benefits, yes that could be one of them but's not about to remove, better say "to understand". Many ones like to have a more "open" toy, you know... Just for educational purpose, obviously..
    If you mean likelihood it's about:
    W(number of brain at work)x(moneytheyallcanspendonthis/moneyhavespent$ony)
    __________________________________________________ ______________

    Z(moneyhavespent$ony)x(IQofprojectengineer)
    Quote Originally Posted by semitope View Post
    Replace the decryption algo with our own maybe.
    I do believe that "to replace it" is definitely an unuseful concept. The target is understand it or better know it. If the key doesn't match the lock the door will not open. If you change the key you have also to change all the locks.
    Quote Originally Posted by semitope View Post
    Btw all that is needed to decrypt information from the elements in the trust system are all stored on the cell chip?
    Not to be excluded, as it's not to be excluded that the processor have a built in microcode to retrieve the decryption key directly from the file, in this case both keys could be on the file or better explained "the encryption itself is the key or... another example in plain language, maybe the processor doesn't need at all to know the encryption key of the file cause the file simply speaks the same language of the processor, for sure the processor knows by itself how to sign encrypted data to bond at the console but this is nothing new as it's most likely the well known Magic-Gate technology.

    Better I get back to work now.

  8. #48
    Contributor semitope's Avatar
    Join Date
    Feb 2009
    Posts
    605
    Quote Originally Posted by moneymaker View Post
    I do believe that "to replace it" is definitely an unuseful concept. The target is understand it or better know it. If the key doesn't match the lock the door will not open. If you change the key you have also to change all the locks.
    Yeah i figured, you would have to decrypt the files before giving them another encryption for the algo u replaced...

  9. #49
    Registered User moneymaker's Avatar
    Join Date
    Dec 2009
    Posts
    120
    Quote Originally Posted by sapperlott View Post
    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.
    That's why it could be useful to find a way to have the PPU could drink a "gart_iommu_shutdown()" hint.

    Quote Originally Posted by sapperlott View Post
    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:
    [Register or Login to view links]
    Yep, but that's not the only thing to know about CELL. I'm sure you already know this things but... if you want to take a look.

    [Register or Login to view links]

    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. [Register or Login to view links]

    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.

  10. #50
    Contributor ionbladez's Avatar
    Join Date
    Apr 2009
    Posts
    225

    Wink

    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).

 

Sponsored Links

Page 5 of 6 FirstFirst ... 3456 LastLast
Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News