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:
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).
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.
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.
- 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.
- 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.
- 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.
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:
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:
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.
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 0×17014, 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:
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:
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 / 0×10 / Debug Support Flag
0x48C60 / 1 / Update Status
0x48C61 / 1 / Recover Mode Flag
0x48D3E / 0×50 / QA Token (UM doesn’t allow access to this offset but SC Manager can read/write it)
0x48C30 / 0×01 / Number of usable SPEs, usually set to 0×06, can be set to 0×07 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 0×00 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:
Oh, and token seed is 0×50 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.