Sponsored Links

Sponsored Links

Page 1 of 13 12311 ... LastLast
Results 1 to 10 of 124



  1. #1
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    27,648
    Sponsored Links

    Fail0verflow: 27C3 PS3 Exploit Hacker Conference 2010 Highlights

    Sponsored Links
    Update: As planned, today Marcan42 has showed a Fail0verflow live demo (videos below) of him booting up a PS3 Slim to a Linux Kernel during the Lightning Talks as part of Day 4 at the 27C3 PS3 Exploit Hacker Conference.

    Below are the fail0verflow PS3 exploit details along with related 27C3 (Chaos Communication Congress) Hacker Conference 2010 PlayStation 3 highlights.

    Currently it includes an outline and details on PS3 SELF Crypto and PS3 SELF File Format and Decryption, and will be updated throughout the day as new details and video footage (full video now [Register or Login to view links]- Thanks zeromx) arrive.

    As previously reported, the PS3 hacking segment took place today at 16:00 (local time) in Saal 1 and a live stream was available in the following formats:




    PS3 27C3 Hacker Conference 2010 Summary:
    • Fail0verFlow is Coming: [Register or Login to view links] and [Register or Login to view links] (Dongle-less PS3 JailBreaking, overflow by replacing PS3 revoke list with a large one at bootup due to Sony's flawed implementation of [Register or Login to view links] in not having a random K value)
    • Fail0verflow Tweets: Yes, we'll release all our tools as soon as we cleaned them up in January or so. Myth: Geohot -> Sony pulls OtherOS -> JB -> Fail. Fact: Slim had no OtherOS -> Geohot -> ... . Geohot started his work due to the Slim. There is absolutely no doubt in our mind that the PS3 lasted as much as it did due to OtherOS. The security really is terribly broken. Note: we won't be working long-term on CFW or similar. We'll release tools and a PoC, someone else can take over. The fun part is done we only started looking at the ps3 after otheros was killed. the website will launch when it launches. Almost certainly not tomorrow. fail0verflow is the name of our 'group'. We are a bunch of curious hackers who have been working on a bunch of things over the last 3 years. Our goal is to have linux running on all existing PS3 consoles, whatever their firmware versions. Our current PS3 goal: AsbestOS.pup. For all those out there that think fail0verflow.com has been hacked - it hasn't. We're just busy working on a demo for tomorrow. Patience!
    • Marcan42 Tweets: Clarification #4: The random number isn't 4, it's more like 007eabbb79360e14df1457a4194b82f71a0dc39280 (example). But it's still constant. Clarification #3: The private keys refer to keys that Sony HQ uses. PS3s don't have these keys (but we calculated them due to the fail). It's Sony not knowing WTF they're doing when making signatures, and thus mathematically leaking their keys. This is also why we didn't use the term "exploit" or "bug". The PS3 signature fail is neither an exploit nor a bug (in the PS3 firmware). The XKCD "return 4" function that we showed is (essentially) part of the code that Sony HQ runs to sign games, it's not in the PS3 FW. No one can create a new metldr (for an existing console). Not even Sony (unless they have that console's key stashed somewhere).
    • Marcan42 Tweets cont'd: We don't have the game signing key but the same epic fail applies to it. Once someone dumps appldr they can calculate it too. They actually CAN change keys for LV2/LV1, isolated modules, rvklists, spp, but that's useless because you can just downgrade the loaders. Myth #2: Sony can change keys. No, they can't. These aren't encryption keys, they're signing keys. If they change them GAMES STOP WORKING. Myth #1: It took us 3-4 years to do this. Negative, this exploit only took a few months after we started working. We weren't trying before.
    • Marcan42 Tweets cont'd: FWIW lightning talks tomorrow are at 11:30-13:45. PS3 demo will be 4 minutes _somewhere_ within that range (to be determined). They can try to whitelist every existing piece of official PS3 code... but good luck with that. IOW they CANNOT change keys or fix this in a new firmware, because stuff we sign is every bit as good as existing official software. Wii fakesigning vs. PS3 epic fail: Wii issue is a BUG in console code (fixable), PS3 issue is a FAIL in THEIR secret signer (not fixable).
    • Marcan42's PS3 NOR Flash 40-50 Wire Mod (more pictures HERE) [Register or Login to view links]
    • Public Private Keys Calculated, Current PS3 Firmware vulnerable and downgradeable
    • Signing (SELF Packages) - Not Games (No Apploader Keys), PS3 SELF Decryption Code by ooPo ([Register or Login to view links])
    • Live Demo by Marcan42 (confirmed above via Twitter) during Lightning Talks tomorrow- Day 4, Room Saal 3, Start time 11:30, Duration 02:15.
    • MPlayer port to PS3 in the works, confirmed by lantus on IRC.
    • From sven via IRC: Although only PS3 keys up to 3.15 are currently available, it is now possible to build an AsbestOS.PUP. There is an overflow with the revocation lists, we could have put a huge revocation list on the NOR which lv1 will happily load and then use that to break lv2ldr and patch out the signature check but then we found the private key. We don't have lv1 yet because we don't have the lv1 loader key.
    • phiren on IRC states: Well, all currently released ps3's are broken forever. With a bit of effort they could update it to take a new private key, but then they would have to release 2 packages, one signed with the old key and one signed with the new key and their security model is still fundamentally flawed.
    • 27C3 Console Hacking 2010 Presentation Slides (PDF) are now available.





    Updates from PS3 Wiki (ps3wiki.lan.st):

    PS3 SELF Crypto: Here is a small summary on how the self cryptography works.

    Basically here are the steps being involved by the loaders:

    Loaders all have a static key and iv called respectively erk and riv, those are keys for the first decryption step which are used to decrypt the very first 0x40 bytes of the self's metadata using AES256CBC

    Then the result is used as a key and iv to decrypt the rest of the metadata using AES128CTR, finally the decrypted metadata contains the keys and iv for each data sections which are still decrypted through AES128CTR. This security model is based on the fact that the first 0x40 bytes of the self's metadata once decrypted by the static AES256CBC key in the loader should never be the same from one binary to the other. The same goes for any other value used as an AES128CTR key or iv.

    Loaders are also involved with deflating the binaries using zlib.

    The self authenticity is based on other independent steps, HMAC-SHA1 (which I believe to be possible leftovers from the playstation portable's kirk engine code) and ECCDSA for the actual signature.





    PS3 SELF File Format and Decryption:

    File Format

    Notes:
    - Numbers are stored in big endian format.

    SELF Header
    Code:
    typedef struct
    {
    uint32_t magic;                   // "SCE\0"
    uint32_t version;                 // 2
    uint16_t attribute;               // 0x8000 - fself
    uint16_t category;
    uint32_t metadataInfoOffset;
    uint64_t fileOffset;
    uint64_t fileSize;
    uint64_t unknown06;
    uint64_t programInfoOffset;
    uint64_t elfHeaderOffset;
    uint64_t elfProgramHeadersOffset;
    uint64_t elfSectionHeadersOffset;
    uint64_t unknown11;
    uint64_t unknown12;
    uint64_t controlInfoOffset;
    uint64_t controlInfoSize;
    uint64_t unknown15;
    }
    SELFHEADER_t;
    Program Info
    Code:
    typedef struct
    { 
      uint64_t programAuthId;
      uint64_t unknown01;
      uint16_t programVersion[4];
      uint64_t unknown03;
    }
    PROGRAMINFO_t;
    Control Information
    Code:
    typedef struct
    { 
      uint32_t unknown00;
      uint32_t unknown01;
      uint32_t unknown02;
      uint32_t unknown03;
      uint32_t controlFlags[8];
      uint32_t unknown05;
      uint32_t unknown06;
      uint32_t unknown07;
      uint32_t unknown08;
      char digest[64];
      uint32_t unknown10;
      uint32_t unknown11;
    }
    CONTROLINFO_t;
    Metadata Information
    Code:
     
    typedef struct
    {
      uint8_t unknown00[32];
      uint8_t key[32];
      uint8_t ivec[32];
    }
    METADATAINFO_t;
    Notes:
    - The key and ivec fields are encrypted using AES256CBC.

    Metadata Header
    Code:
    typedef struct
    {
      uint32_t unknown00;
      uint32_t size;
      uint32_t unknown02;
      uint32_t sectionCount;
      uint32_t keyCount;
      uint32_t unknown05;
      uint32_t unknown06;
      uint32_t unknown07;
    }
    METADATAHEADER_t;
    Notes:
    - The metadata header is located after the metadata info in the SELF file.
    - It is decrypted using AES128CTR with the key and ivec entries from the metadata information.

    Metadata Section Headers
    Code:
    typedef struct
    {
      uint64_t dataOffset;
      uint64_t dataSize;
      uint32_t unknown02;
      uint32_t programIndex;
      uint32_t unknown04;
      uint32_t sha1Index;
      uint32_t unknown05;
      uint32_t keyIndex;
      uint32_t ivecIndex;
      uint32_t unknown09;
    }
    METADATASECTIONHEADER_t;
    Notes:
    - The metadata section headers are located after the metadata header in the SELF file.
    - The number of sections is indicated by the sectionCount entry in the metadata header.
    - They are decrypted using AES128CTR with the key and ivec entries from the metadata information.
    - Section data is decrypted using AES128CTR with the key and ivec from the metadata keys specified by keyIndex and ivecIndex.
    - Section data will also need to be uncompressed using zlib.

    Metadata Keys
    Code:
    typedef uint8_t METADATAKEY_t [16];
    Notes:
    - The metadata keys are located after the metadata section headers in the SELF file.
    - The number of keys is indicated by the keyCount entry in the metadata header.
    - They are decrypted using AES128CTR with the key and ivec entries from the metadata information.
    - Some keys are 160-bit SHA-1 and span two consecutive keys.

    Extracting an ELF

    ELF Header
    Code:
    Elf64_Ehdr elfHeader;
    
    fseek ( selfFile, fix64 ( selfHeader.elfHeaderOffset ), SEEK_SET );
    fread ( &elfHeader, sizeof ( Elf64_Ehdr ), 1, selfFile );
    
    fseek ( elfFile, 0, SEEK_SET );
    fwrite ( &elfHeader, sizeof ( Elf64_Ehdr ), 1, elfFile );
    Section Headers 
    Elf64_Shdr elfSectionHeaders[100];
    
    fseek ( selfFile, fix64 ( selfHeader.elfSectionHeadersOffset ), SEEK_SET );
    fread ( elfSectionHeaders, sizeof ( Elf64_Shdr ), fix16 ( elfHeader.e_shnum ), selfFile );
    
    fseek ( elfFile, fix64 ( elfHeader.e_shoff ), SEEK_SET );
    fwrite ( elfSectionHeaders, sizeof ( Elf64_Shdr ), fix16 ( elfHeader.e_shnum ), elfFile );
    Section Data

    Notes:
    - Unknown, manually copying the data over works for now.
    - There should be a section data offset somewhere.

    Program Headers
    Code:
    Elf64_Phdr elfProgramHeaders[100];
    
    fseek ( selfFile, fix64 ( selfHeader.elfProgramHeadersOffset ), SEEK_SET );
    fread ( elfProgramHeaders, sizeof ( Elf64_Phdr ), fix16 ( elfHeader.e_phnum ), selfFile );
    
    fseek ( elfFile, fix64 ( elfHeader.e_phoff ), SEEK_SET );
    fwrite ( elfProgramHeaders, sizeof ( Elf64_Phdr ), fix16 ( elfHeader.e_phnum ), elfFile );
    Program Data

    Notes:
    - Load the metadata information and decrypt the key and ivec entries using AES256CBC using erk and riv.
    - Load the metadata header and decrypt it using AES128CTR with the key and ivec entries from the metadata information.
    - Load sectionCount metadata section headers and decrypt them using AES128CTR with the key and ivec entries from the metadata information.
    - Load keyCount metadata keys and decrypt them using AES128CTR with the key and ivec entries from the metadata information.
    - For each metadata section:
    - In the SELF file, fseek to dataOffset and read in dataSize bytes.
    - Decrypt the data using AES128CTR with the key and ivec from the metadata keys specified by keyIndex and ivecIndex from the metadata section header.
    - Uncompress the data using zlib.
    - Write it to the ELF file as the program section specified by sectionIndex in the metadata section header.











    Fail0verflow: 27C3 PS3 Exploit Hacker Conference 2010 Highlights

    More PlayStation 3 News...
    Attached Thumbnails<br><br> Attached Thumbnails

    27c3.jpg   Image0.jpg   Image1.jpg   Image2.jpg   Image3.jpg   Image4.jpg  

    Image5.jpg   Image6.jpg   Image7.jpg  
    Attached Files Attached Files

  2. #2
    Registered User FMAranda's Avatar
    Join Date
    Dec 2009
    Posts
    523
    Sponsored Links
    Sponsored Links
    Yes, in 20 minutes!

  3. #3
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    27,648
    Sponsored Links
    Sponsored Links
    Yep, about 15 now... hopefully the feeds won't die once it begins hehe.

    Here are more pics of Marcan42's PS3 NOR Flash 40-50 Wire Mod also and some presentation slides.

    [Register or Login to view links]

    His previous Twitter hint was: "9e1c3006d4c8f51efdfc36b0412ffb5d12c68542 for the record (you'll find out at 27c3)" 5:36 AM Oct 10th via Choqok.

    From rms: [Register or Login to view links]
    A look at NOR flash

    Hi, so, today’s topic is about the PS3 NOR flash from consoles with vflash enabled, CECHGxx (middle-run) to CECH251x.

    NOR flash is a type of flash that allows random byte access, sort of like a hard disk. NAND, the other type of flash allows block by block access. On PS3s with NAND like the DECHA00A o CECHA00, the StarShip chip (SS2) masks 2 128MB (for a total of 256MB) flash chips as one large 256MB NOR flash.

    NOR flash on PS3 has a special header which can be omitted if you wish to unpack it using cosunpkg or coreos_tool:
    Code:
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    00000010  00 00 00 00 0f ac e0 ff  00 00 00 00 de ad be ef  |................|
    00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 78 00  |..............x.|
    00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    To me, this looks like the Sony partition table header used on the hard disk, in very old firmware, this header was also used for the FAT32 part of flash, dev_flash.

    Now, note, NOR flash is specific to your console, this is because it has 5 files that are relevant to your and only your console, these files are cCSD, cISD, eEID, cvtrm and asecure_loader. These files are in plaintext though. Here’s a directory listing of these files:
    Code:
    -rw-r--r-- 1    190XXX Jan 28 16:41 asecure_loader
    -rw-r--r-- 1      2048 Jan 28 16:41 cCSD
    -rw-r--r-- 1      2048 Jan 28 16:41 cISD
    -rw-r--r-- 1    262144 Jan 28 16:41 cvtrm
    -rw-r--r-- 1     65536 Jan 28 16:41 eEID
    Now, of course, these files, as I told you before are console specific. eEID contains your system model data, your target ID, and your PS3 motherboard revision, in a nice large 64kB file. EID0 and EID4 reside in here I believe, EID0 is needed for loading parameters to isoldr for loading isolated SELF files on a SPE. cISD contains other core information such as Gelic Ethernet MAC address, along with cCSD. Asecure_loader or metldr is stored in a rather fun way.
    Code:
    00000020  6d 65 74 6c 64 72 00 00  00 00 00 00 00 00 00 00  |metldr..........|
    00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    Oh, look, it’s a header, another fun container. Metldr is fully encrypted with the per console key. And that key lies in the Cell/BE microprocessor. And for some reason, GameOS can write to the metldr/eEID region, see graf_chokolo’s documentation on PS3 Hypervisor, it’s in the Indi Info Manager section, command 017014, write to eEID/metldr. This command is probably used during manufacturing to write the initial eEID onto NOR.

    Cvtrm is another file in NOR, it has a special header that I’ve not seen before:
    Code:
    00000000  53 43 45 49 ff ff ff ff  ff ff ff ff ff ff ff ff  |SCEI............|
    00000010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
    ...
    00004000  00 00 00 00 56 54 52 4d  00 00 00 00 00 00 00 04  |....VTRM........|
    I have the faintest clue about what this file does on PS3, apparently, it’s for QA Tokens that are revoked.

    Now, there are 6 more files we have yet to talk about, ros0, ros1, trvk_pkg0, trvk_pkg1, trvk_prg0, trvk_prg1. Ros0 is the current Core OS file image decrypted from CORE_OS_PACKAGE.pkg from a PS3 Update file. Ros1 is a backup Core OS flashed during manufacturing, usually by the Lv2diag.self or Manufacturing_updater_for_reset.self file. Backup Core OS is only used if a certain flag is set in SYSCON EEPROM, the Recovery Mode flag, which is apparently, never set, it’s at offset 0x48C61. Trvk_pkg0 and Trvk_prg0 are the RL_FOR_PACKAGE.img and RL_FOR_PROGRAM.IMG files for the respective Core OS revision. Trvk_pkg1 and Trvk_prg1 are used for backup Core OS RL_FOR_PACKAGE.img and RL_FOR_PROGRAM.IMG.

    Core OS images are 32 bytes larger than they are in the PUP though, they seem to be static:
    Code:
    00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 6f ff e0  |.............o..|
    00000010  00 00 00 01 00 00 00 17  00 00 00 00 00 6f ff e0  |.............o..|
    Here’s my data structure based on what I think it is:
    Code:
    struct {
       unsigned char unknown0[8];
       unsigned int ros_size0;
       unsigned char unknown1[8];
       unsigned int ros_size1;
    } ros_hdr_t;
    Those are the first 32 bytes, everything after is normal Core OS.

    Here’s an entire directory listing:
    Code:
    -rw-r--r-- 1    190XXX Jan 28 16:41 asecure_loader
    -rw-r--r-- 1      2048 Jan 28 16:41 cCSD
    -rw-r--r-- 1      2048 Jan 28 16:41 cISD
    -rw-r--r-- 1    262144 Jan 28 16:41 cvtrm
    -rw-r--r-- 1     65536 Jan 28 16:41 eEID
    -rw-r--r-- 1   7340032 Jan 28 16:41 ros0
    -rw-r--r-- 1   7340032 Jan 28 16:41 ros1
    -rw-r--r-- 1    131072 Jan 28 16:41 trvk_pkg0
    -rw-r--r-- 1    131072 Jan 28 16:41 trvk_pkg1
    -rw-r--r-- 1    131072 Jan 28 16:41 trvk_prg0
    -rw-r--r-- 1    131072 Jan 28 16:41 trvk_prg1
    Oh, and here’s metldr:
    Code:
    -rw-r--r-- 1     59600 Jan 30 15:37 metldr
    NOR Unpkg – The Tool
    Code:
    /*
      # ../norunpkg norflash.bin norflash
      unpacking asecure_loader (size: 190xxx bytes)...
      unpacking eEID (size: 65536 bytes)...
      unpacking cISD (size: 2048 bytes)...
      unpacking cCSD (size: 2048 bytes)...
      unpacking trvk_prg0 (size: 131072 bytes)...
      unpacking trvk_prg1 (size: 131072 bytes)...
      unpacking trvk_pkg0 (size: 131072 bytes)...
      unpacking trvk_pkg1 (size: 131072 bytes)...
      unpacking ros0 (size: 7340032 bytes)...
      unpacking ros1 (size: 7340032 bytes)...
      unpacking cvtrm (size: 262144 bytes)...
    */
    
    // Copyright 2010       Sven Peter
    // Licensed under the terms of the GNU GPL, version 2
    // http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt
    // nor modifications by rms.
    
    #include "tools.h"
    #include "types.h"
    
    #include <stdio.h>
    #include <string.h>
    #include <stdlib.h>
    #include <unistd.h>
    #include <sys/stat.h>
    
    #ifdef WIN32
    #define MKDIR(x,y) mkdir(x)
    #else
    #define MKDIR(x,y) mkdir(x,y)
    #endif
    
    u8 *pkg = NULL;
    
    static void unpack_file(u32 i)
    {
            u8 *ptr;
            u8 name[33];
            u64 offset;
            u64 size;
    
            ptr = pkg + 0x10 + 0x30 * i;
    
            offset = be64(ptr + 0x00);
            size   = be64(ptr + 0x08);
    
            memset(name, 0, sizeof name);
            strncpy((char *)name, (char *)(ptr + 0x10), 0x20);
    
            printf("unpacking %s (size: %d bytes)...\n", name, size);
            memcpy_to_file((char *)name, pkg + offset, size);
    }
    
    static void unpack_pkg(void)
    {
            u32 n_files;
            u64 size;
            u32 i;
    
            n_files = be32(pkg + 4);
            size = be64(pkg + 8);
    
            for (i = 0; i &lt; n_files; i++)
                    unpack_file(i);
    }
    
    int main(int argc, char *argv[])
    {
            if (argc != 3)
                    fail("usage: norunpkg filename.nor target");
    
            pkg = mmap_file(argv[1]);
    
            /* kludge for header, i do not do sanity checks at the moment */
            pkg += 1024;
    
            MKDIR(argv[2], 0777);
    
            if (chdir(argv[2]) != 0)
                    fail("chdir");
    
            unpack_pkg();
    
            return 0;
    }
    Let’s look at SYSCON.

    Hi, today’s PS3 subject is about the SYSCON. SYSCON or SC controls the system, it’s a SM Bus Controller if you think about it. SYSCON controls the System LEDs (Green, Yellow, Blue, and Red), and whether they flash slowly, quickly or are turned off entirely. SYSCON also does temperature control, along with some other fun things, let’s look at them.

    Ok, so in graf_chokolo’s documentation on HV, we see that the SYSCON Manager or SC manager lies in Lv-1, process ID (PID) 5, and controls SYSCON obviously, but we cannot access that due to restrictions in DM or Dispatch Manager in HV. Now, what’s in SC Manager you ask. Once can set RTC, or prepare TRM. TRM in HV decrypts certain keys such as the USB Master Dongle Authentication key, or revoked QA tokens I believe. SC Manager can also set the region of the console, or get the region, along with other fun things. Do note that DM ignores packet requests for services, so you have to use the Update Manager or UM to do things.

    SYSCON EEPROM has several fun offsets:

    Offset / Size / Description

    0x48C06 / 1 / FSELF Control Flag
    0x48C07 / 1 / Product Mode (UM allows to read this offset, it can be also written but only when already in product mode)
    0x48C0A / 1 / QA Flag
    0x48C13 / 1 / Device Type
    0x48C42 / 1 / HDD Copy Mode
    0x48C50 / 010 / Debug Support Flag
    0x48C60 / 1 / Update Status
    0x48C61 / 1 / Recover Mode Flag
    0x48D3E / 050 / QA Token (UM doesn’t allow access to this offset but SC Manager can read/write it)
    0x48C30 / 001 / Number of usable SPEs, usually set to 006, can be set to 007 to enable all 8 SPEs in Cell/BE

    That’s from graf_chokolo’s HV documentation, but do note, it /is/ possible to generate a “working” token for QA token, using another part of the system, but it is what you would call a “false-token”. It does not unlock anything fancy, only the repository node in Lv-1. Token requires a seed and it is formed from that seed and the EID0 of your console I think. QA Flag requires the QA Token to work. FSELF flag controls whether FSELFs can run as “root” or have modified control flags, sort of like the way PSGroove does things with 3.41. Debug Support is currently unexplored territory, but it has to do with debug permissions.

    Recover Flag allows backup (ros1) Core OS in NOR/NAND, (see previous post) to be run instead of ros0 (regular Core OS), I’ve never seen this flag set. Update Status determines whether you are in updater mode, and whether to run ps3swu.self from /dev_hdd0. Device Type controls whether you are in Service mode or not, value 0xFF is retail, and 000 is Factory/Service mode. HDD Copy Mode is pretty much self explanatory.

    It is also possible to visualize this data as a struct if you want to:
    Code:
    struct {
       unsigned char fselfControl;
       unsigned char productMode;
       unsigned char qaFlag;
       unsigned char deviceType;
       unsigned char hddCopyMode;
       unsigned char debugSupport[10];
       unsigned char updaterMode;
       unsigned char recoverRosMode;
       unsigned char qaToken[50];
    } sc_eeprom_t;
    Oh, and token seed is 050 bytes also, it can be calculated also.

    You can still write to SC EEPROM using PSGroove, it’s not really hard, just use some Lv-1 undocumented functions in your payload.

    Well, I’ve been on EFnet for a while now, and I’ve seen many people asking about PS3 Custom Firmware 3.56, well, let me put it in a simple manner, it’s not possible thanks to what Sony did with their ECDSA (Elliptic Curve DSA) cryptography, and the new PUP format along with Cell-OS Lv2 having some extra checks on SELF files now.

    See, when we used to get private keys for earlier fail ECDSA keyset revisions, a variable, r, in the ECDSA signature was static, thus allowing us to get the keys using the signature itself, now, Sony fixed this by making that variable random, so we can no longer use simple algebra to get the private key like before. Do note that to retrieve the older private keys, one needed to use 2 signatures, and simply compare them to get the private key. Now, for those who do not know about private keys and public keys and ERK/RIV, here’s a simple explanation: Private keys are used to create signatures, public keys are used to verify the signature’s authenticity. ERK/RIV is used to decrypt the encrypted SELF data.

    The new PUP format has 2 extra files, one consists of a new tarball with spkg_hdr1 files, ensuring package integrity, so one can no longer create rehashed pups anymore. Until the spkg format is deciphered, and they can be resigned, one’s pretty much stuck with Official Firmware. Core OS also has some new additions, appldr now checks your SELF revision for NPDRM, and Lv2 selfs, they either must be whitelisted or use the new revision 0x0D keyset in 3.56. Lv2 now will also refuse to load older updater or Lv2diag.self files that do not use the 0x0D keyset. Core OS also has two new revoke lists, prog_srvk and pkg_srvk. They have yet to be fully inspected yet.

    So, in the end, Sony pretty much fixed most of the fail, some’s still around though, go look for it.
    Attached Thumbnails<br><br> Attached Thumbnails

    nordone.jpg   nortwl.jpg   cfconn.jpg   normale.jpg   norwires.jpg   norconn.jpg  

    m9EZJ.jpg  
    Attached Files Attached Files

  4. #4
    Senior Member Mbb's Avatar
    Join Date
    Jan 2010
    Posts
    323
    I have WMP ready, it begins now!!!

    If those people going to take there sits quickly we can begin lol

  5. #5
    Registered User FMAranda's Avatar
    Join Date
    Dec 2009
    Posts
    523
    I will have my lunch in front of my computer, lol

    Good, the h264 keep getting 500 Server Error.

  6. #6
    Registered User zeromx's Avatar
    Join Date
    Dec 2008
    Posts
    221
    This is awesome, only been able to watch it from slides...

  7. #7
    Forum Moderator PS3 News's Avatar
    Join Date
    Apr 2005
    Posts
    27,648
    I am getting audio with some occasional slides, so far just a recap mostly though...

  8. #8
    Senior Member Mbb's Avatar
    Join Date
    Jan 2010
    Posts
    323
    Yes only a summery of the last 4 months, this stream [Register or Login to view links] works great with WMP and VLC

    Im also waiting for the PLATINUM TROPHY

    - and 1 minute later, there it is
    Last edited by Mbb; 12-29-2010 at 11:35 AM

  9. #9
    Registered User FMAranda's Avatar
    Join Date
    Dec 2009
    Posts
    523
    Yes, i'm using wmv on vlc and it works very well.

  10. #10
    Senior Member Mbb's Avatar
    Join Date
    Jan 2010
    Posts
    323
    [Register or Login to view links]

 

Sponsored Links
Page 1 of 13 12311 ... LastLast
Affiliates - Contact Us - PS3 Downloads - Privacy Statement - Site Rules - Top - © 2014 PlayStation 3 News