129w ago -
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
HERE- 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:
- Saal 1 H.264: http://saal1.h264.27c3.fem-net.de/
- Saal 1 WMV: http://wmv.27c3.fem-net.de/saal1
- Saal 1 Audio: http://audio.27c3.fem-net.de/27c3_saal1.ogg
- Saal 1 Slides: http://saal1.slides.27c3.fem-net.de/
PS3 27C3 Hacker Conference 2010 Summary:
- Fail0verFlow is Coming: http://fail0verflow.com/ and http://twitter.com/fail0verflow (Dongle-less PS3 JailBreaking, overflow by replacing PS3 revoke list with a large one at bootup due to Sony's flawed implementation of ECDSA 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) http://twitter.com/marcan42/status/16985058829144065
- Public Private Keys Calculated, Current PS3 Firmware vulnerable and downgradeable
- Signing (SELF Packages) - Not Games (No Apploader Keys), PS3 SELF Decryption Code by ooPo (GIT)
- 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
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
typedef struct
{
uint64_t programAuthId;
uint64_t unknown01;
uint16_t programVersion[4];
uint64_t unknown03;
}
PROGRAMINFO_t;
Control Information
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
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
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
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
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
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
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.
123 Comments - Go to Forum Thread »
No because the copy protection on the blu ray discs hasn't been broken ie if it isnt printed by sony the ps3 won't treat it like a game disc so we cant mess with those files.
even so, a 2TB HDD can hold max 10-20games...
Mate, sorry to say that but ARE YOU CRAZY?
What were you hoping for? A complete CFW? That will come in time mate... This is bigger...