The Exploit

As the exploit that was used to dump lv0ldr/bootldr/howeveryouliketocallit is public now, let’s have a closer look at it to understand what’s going on. Here is what I have reversed from lv0 (it shares the syscon portion of the code with its SPU counterpart):

//In .data section.
static u8 tmp_pkt[0x800];

//Get size from sc packet.
#define GET_SIZE(pkt) ((pkt[4] << 8) | pkt[5])

int read_cmpl_msg(/*...*/, u8 *payload_buf /*r5*/, int min_size /*r6*/, /*...*/)
{
    u16 pkt_size;

    //Get packet header.
    memcpy_aligned_64(tmp_pkt, MMIO_SC_PKT, 0x10);

    //Check packet size.
    pkt_size = GET_SIZE(tmp_pkt);
    if(pkt_size - 4 < min_size || pkt_size + 8 > 0x800)
        return ERR;

    //Run first sc_checksum.
    if(!sc_checksum(...))
        return ERR;

    //Read packet again (plus header!).
    pkt_size = GET_SIZE(tmp_pkt);
    memcpy_aligned_64(tmp_pkt, MMIO_SC_PKT, size + 0x1B);

    //Get size again (not checked now).
    //I suspect that this is actually a compiler 'quirk' and not a
    //programmer mistake. The original source probably accesses the
    //packet size through a structure and the compiler noticed the
    //non const access of the packet and generated this read of the
    //size member because it could have changed.
    pkt_size = GET_SIZE(tmp_pkt);

    //Let's have some fun (payload_buf on caller stack).
    memcpy(payload_buf, tmp_pkt + 8, size - 4);

    //Run second sc_checksum.
    if(!sc_checksum(...))
        return ERR;

    //...
}

The syscon library implements some high level functions, e.g. to shutdown the console on panic or to read certain configuration values. Every of this functions internally uses another function to exchange packets with syscon and the exchange function uses the read_cmpl_msg one to get the answer packet. The top-level function will pass a fixed size buffer to the exchange function. So if we are able to control syscon packets, e.g. by emulating MMIO (and thanks to IBM we are), we can change the packet size between the two packet readings and overwrite the caller stack. And if we first copy a little stub to shared LS and let the return address point to it, we can easily dump the whole 256 kB.

Nothing more left to say now, let’s wait and see if this is going to be fixed in future firmware versions (we just have to check lv0 fortunately).

Exploiting (?) lv2

A long while ago KaKaRoTo pointed me to a stack overflow he found while reversing lv2_kernel. But there are two problems:

  1. The vulnerability is in a protected syscall (the SELF calling it got to have the 0x40… control flags set). So you’d first need to find a suitable usermode exploit (don’t ask us), that gives you code execution with the right privileges.
  2. The payload data is copied to lv2 heap first and the function will do a free call on it before the payload has any chance to get executed. This might not sound like a problem but it looks like lv2’s heap implementation will overwrite the free’ed space with 0xABADCAFE and thus destroy the payload.

Here is my sample implementation for 3.41 lv2_kernel (although the vulnerability should be present in all versions of lv2 up to the latest firmware), maybe someone of you will find a way to overcome problem (2.) and can get something nice out of it because right now it’s only good to crash lv2.

eEID Cryptography

When metldr is encrypted at factory, a special keyset is set in the binary before encryption. Later when an isolated loader is loaded by metldr, it will copy the keyset to LS offset 0x00000. It consists of eid_root_key and eid_root_iv. To not having to use the same key for all eEID parts, several subkeys are generated from special data called individual information seed. These seeds are stored in the metadata header of isolated modules loaded by isoldr. When isoldr will load a module, it will call a subroutine that encrypts each seed chunk (0x40 bytes) using eid_root_key and eid_root_iv. Then the so-called individual infos are passed in registers r7 to r22 (= 0x100 bytes in total) to the loaded module where they are used further. Usually isolated modules have a seed section of 0x100 bytes but all of them (except sb_iso_spu_module) have all zeroes but the first 0x40 bytes chunk. You can, for example, find the recently published EID0 seed in the metadata section of aim_spu_module. Appliance info manager is used to get e.g. the target ID or the PSID from EID0. This explains why the seed can also be found in isoldr directly, since that one is checking EID0 too.

As you can probably think, a fair amount of reversing time and knowledge has gone into finding this, so stop calling us *swearwords* for not releasing information that could potentially lead to more piracy, because we think that this would do more harm to the “scene” than just keeping some information in private (for now). Also I can only encourage everyone that thinks about us this way or is greedy demanding for developers/reverse engineers to release their stuff, to fire up isoldr in IDA or disassemble it with objdump and try to reverse all this from start to end. We’ll see, who is able to pull this through on his own…

Reversing TB – Part 1: The VM

Thanks to oct0xor we could get our hands on the decrypted TB payload (stage 2). Of course the first thing to do is to fire it up in IDA, our favourite tool of the trade. The entry code of the payload looks like this:

1337C0DE00000000 _start:
1337C0DE00000000
1337C0DE00000000 .set var_58, -0x58
1337C0DE00000000 .set arg_10,  0x10
1337C0DE00000000
1337C0DE00000000         mflr      r0
1337C0DE00000004         bl        loc_1337C0DE00000008
1337C0DE00000008 1337C0DE00000008 loc_1337C0DE00000008:
1337C0DE00000008         mflr      r3
1337C0DE0000000C         lis       r4, 0 # 8
1337C0DE00000010         addi      r4, r4, 8 # 8
1337C0DE00000014         subf.     r3, r4, r3
1337C0DE00000018         beq       skip_reloc
1337C0DE0000001C         li        r6, 0
1337C0DE00000020         oris      r6, r6, 0x1337
1337C0DE00000024         ori       r6, r6, 0xC0DE
1337C0DE00000028         lis       r4, 1 # 0xA848
1337C0DE0000002C         addi      r4, r4, -0x57B8 # 0xA848
1337C0DE00000030         lis       r5, 1 # 0x10D18
1337C0DE00000034         addi      r5, r5, 0xD18 # 0x10D18
1337C0DE00000038         subf.     r5, r4, r5
1337C0DE0000003C         beq       skip_reloc
1337C0DE00000040         srdi.     r5, r5, 3
1337C0DE00000044         mtctr     r5
1337C0DE00000048         add       r4, r4, r3
1337C0DE0000004C
1337C0DE0000004C reloc_loop:
1337C0DE0000004C         ld        r5, 0(r4)
1337C0DE00000050         srdi      r7, r5, 32
1337C0DE00000054         cmpw      r7, r6
1337C0DE00000058         bne       skip_rewrite
1337C0DE0000005C         clrldi    r5, r5, 32
1337C0DE00000060         add       r5, r5, r3
1337C0DE00000064         std       r5, 0(r4)
1337C0DE00000068
1337C0DE00000068 skip_rewrite:
1337C0DE00000068         addi      r4, r4, 8
1337C0DE0000006C         bdnz      reloc_loop
1337C0DE00000070
1337C0DE00000070 skip_reloc:
1337C0DE00000070         std       r0, arg_10(r1)
1337C0DE00000074         stdu      r1, -0x80(r1)
1337C0DE00000078         std       r2, 0x80+var_58(r1)
1337C0DE0000007C         lis       r4, 1 # 0x17E40
1337C0DE00000080         addi      r4, r4, 0x7E40 # 0x17E40
1337C0DE00000084         add       r2, r4, r3
1337C0DE00000088         bl        payload_main

In the first loop it will relocate itself using 0x1337C0DE as an identifier for the upper 32 bits and rewrite that to the actual base. The disassembly above was already loaded using 0x1337C0DE00000000 as base. While scrolling through the data section at the end of the payload one quickly figures out that the RTOC is 0x1337C0DE00017E40.

As I was analyzing the code I found a sub that was basically just a really big switch with random looking case values. Once I reversed the sub at 0x1337C0DE00002578 and some of the following ones and analyzed their usage in the switch sub, I knew that I was looking at a fricking virtual machine.

1337C0DE00002578 vm_push_word_0:
1337C0DE00002578         ld        r11, off_1337C0DE00010128 # stack_ptr
1337C0DE0000257C         ld        r9, 0(r11)
1337C0DE00002580         addi      r0, r9, 4
1337C0DE00002584         std       r0, 0(r11)
1337C0DE00002588         stw       r3, 4(r9)
1337C0DE0000258C         blr

Paranoid TB developers even used XOR-tables to obfuscate the VM instructions and data. The virtual machine is mostly stack based but the instructions let you work using registers too. The next thing to do is to reverse all the instructions and write a disassembler and emulator. Here is some code to unscramble the embeded vm binary for further investigation. I’m going to write more about this topic in the future.

Individual Infos

One of the PS3’s console specific cryptography works as follows:

At factory time there is a console specific key generated, probably from a private constant value and a console specific seed. Maybe that’s the key used for encrypting bootldr and metldr. Fact is, that metldr stores another console specific keyset (key/iv) to LS offset 0x00000. That keyset is probably calculated from the first one. At factory time the isolated root keyset (how I call it) is used to encrypt the console’s “Individual Infos”, like eEID. But not the whole eEID is encrypted the same way, special seeds are used to calculate key/iv pairs for the different sections. And not even that is true for every eEID section, because for e.g. EID0 another step is needed to generate the final section key(set). Each of the isolated modules using such an “Individual Info” has a special section that isoldr uses to generate the derived key(set)s. But the generation works in a way, that the section data is encrypted with aes-cbc using the isolated root keyset, so it is not possible to calculate the isolated root keyset back from the derived key(set)s, because aes shouldn’t allow a known plaintext attack. So far I can decrypt some of EID0’s sections, EID1, EID2 and EID4. EID5 encryption should be similar to EID0’s but I lack the generation keys for that one.