3.03 - 3.11

These firmware versions all have the same getDiscData 0xffff * 3 * 8 buffer overflow of immediately controllable contents.

3.03

3.03 has a couple of additional tricks going on. There are no jump targets which lie within our controlled range from any buffer overflows, however the jump target 0x15ea540 is very close to the beginning of our IFO file contents (0x15ea620).

The memory between the jump target and the start of the IFO (0x15ea540 - 0x15ea620) is all zeroes, so that's just a NOP-sled. Then the IFO header "DVDVIDEO-VMG" turns out to decode to a conditional relative branch which not only happens to be taken, but also jumps to fully controlled contents later in the IFO:

bnel    s2,a0,pos_015FFF34

In addition, that jump target does not fall within language data, so the 3.03 exploit supports all languages, not just English!

Testing

• 3.03 has only been tested in region E - other regions need dumping and testing,
• 3.04 only region M and J are repacked - they are both different, other regions need dumping and testing,
• 3.10 and 3.11 have both been tested on all regions and work the same,

Conflicts

In order to merge 2 exploits into a single ISO there must be either:

• No conflict between offset of currentDiscBytePointer corruption value in IFO file so that the two versions can specify different addresses (3.10 and 3.11),
• Controlled memory at a common address between the two versions so that currentDiscBytePointer can be written to controlled memory region for both (3.04J and 3.10),

It's more complicated than that, because the currentDiscBytePointer is overwritten byte-by-byte.

< 3.03

These firmwares don't use the same getDiscData stream reader API, instead they manually call getBuffer and then memcpy from that sectorBuffer somewhere else. They still contain the vulnerability, but as it occurs from memcpy of OOB memory into other OOB memory, it is not just immediately possible for the full memory range overflowed with to contain fully controlled contents.

Let's look at 3.02 specifically.

0x256668 - getBufferInternal
0x256888 - getBuffer

Searching calls to getBuffer, it's always a fixed number of sectors, 1 to 4, so as previously stated we can't just overflow straight into fpIndex with controlled contents as in > 3.02.

But, the buffer overflows definitely do still exist. The function at 0x23e560 is a nice self contained one:

long bufferOverflow(void) {
  long lVar1;
  
  lVar1 = getBuffer(s_VIDEO_TS.IFO_0090c210,(long)(int)DAT_013c7840,sectorBuffer,1,0);
  if (lVar1 == 0) {
    someLengthFromIFO = (ushort)sectorBuffer[0] * 0x100 + (ushort)sectorBuffer[1];
    DAT_013c7890 = ((long)(int)((uint)sectorBuffer[4] << 0x18) | (ulong)sectorBuffer[5] << 0x10) +
                   (ulong)sectorBuffer[6] * 0x100 + (ulong)sectorBuffer[7];
    memcpy(&PTR_DAT_013c7898,sectorBuffer + 8,(uint)someLengthFromIFO * 0xc);
    lVar1 = 0;
  }
  return lVar1;
}

The memcpy call can overwrite memory from 0x013c7898 to 0x148788C (0x013c7898 + 0xffff * 0xc). The buffer overflow we are triggering in all other exploits because it gives biggest size is at 0x240284:

      length2 = (ushort)sectorBuffer[uVar33 + 2] * 0x100 + (ushort)sectorBuffer[uVar33 + 3];
      length1 = (ushort)sectorBuffer[uVar33] * 0x100 + (ushort)sectorBuffer[uVar33 + 1];
      length3 = (ushort)sectorBuffer[uVar33 + 4] * 0x100 + (ushort)sectorBuffer[uVar33 + 5];
      DAT_013c9a2e = (ushort)sectorBuffer[uVar33 + 6] * 0x100 + (ushort)sectorBuffer[uVar33 + 7];
      memcpy(&DAT_013c9a30,sectorBuffer + uVar33 + 8,
             ((uint)length1 + (uint)length2 + (uint)length3) * 8);

fpIndex is at 0x13cfaca (leading to OOB call at 0x242f6c), and if we can set that to a controlled value we potentially have an exploit (if there's a good jump target).

fpIndex can be overwritten by either of the memcpy buffer overflows shown with a large enough size, but we're not corrupting it with data coming straight from disc; we only read at most 4 sectors (0x800 * 4) = 0x2000 into sectorBuffer, however we need to memcpy 0x609A bytes from sectorBuffer into 0x13c9a30 to overwrite fpIndex (0x13cfaca-0x13c9a30), so we'll be copying from uncontrolled OOB memory into fpIndex.

So, can we make that OOB memory contain controlled contents? Well, by making use of that buffer overflow, we can shift the question from "can we control fpIndex (0x13cfaca)", to "can we control sectorBuffer + 0x609A = 0x13D331A", since if we control that the memcpy will then copy into fpIndex from an address we can control the contents of.

Looking at all of the copies - maybe you will be lucky and find that it happens to line up that after a series of copies - some value you control ends up in fpIndex. Will need more time on it.

UDF vulnerabilities

The IFO buffer overflows are really easy to find as the IFO parsing is the first thing the DVD player does on EE side. We'll probably want to reverse engineer deeper into things like the actual video decoding, etc, in order to see if more easily exploitable bugs are available; for that, I hope others will help collaborate and share notes.

readPartitionTables stack buffer overflow - Found by ElReino

This is a stack buffer overflow occuring in UDFIO IOP processor module. From 2.10E, at 0xb37e4:

    memcpy(&lengthOfExtendedAttributes,DescriptorBuf + 0xa8,4);
    memcpy(&lengthOfAllocationDescriptors,DescriptorBuf + 0xac,4);
    memset(&AllocationDescriptors,0,8);
    memcpy(&AllocationDescriptors,DescriptorBuf + lengthOfExtendedAttributes + 0xb0,
           lengthOfAllocationDescriptors);

Interestingly, this was actually patched by Sony in firmware 2.14! We see it just uses fixed size of 8 bytes:

  memcpy(local_20,0x5ab8,4);
  memcpy(auStack36,0x5abc,4);
  memset(&local_18,0,8);
  memcpy(&local_18,(int)&PTR_DAT_00005ac0 + local_20[0],8);

To find the vulnerability in an IOP memory dump, search for this instruction sequence:

08 00 06 24       _li        param_3,0x8

Until you get one that matches the memcpy/memset pattern shown above in the decompiler view.

If you are paranoid about cache, there's a really nice ROP gadget in the sound module. To find where the FlushDCache function is in your BIOS, run an IOP RAM dump through this code. Then look for calls to that function to find a nice ROP gadget, for 2.10 it's at 0x57f1c:

        00057f1c 3e 67 01 0c       jal        FlushDCacheWrapper
        00057f20 00 00 00 00       _nop
        00057f24 18 00 bf 8f       lw         ra,local_8(sp)
        00057f28 14 00 b1 8f       lw         s1,local_c(sp)
        00057f2c 10 00 b0 8f       lw         s0,local_10(sp)
        00057f30 01 00 02 24       li         v0,0x1
        00057f34 08 00 e0 03       jr         ra
        00057f38 20 00 bd 27       _addiu     sp,sp,0x20

This will be our initial corrupted return address, then we'll jump to the uncached virtual address of the actual IOP payload entry-point, and first thing will be undoing the corruption from this ROP gadget (sub 0x20 from sp and restore s0/s1). The IOP payload loads a second IOP payload, which loads an ELF into EE RAM, then redirects return address on EE stack and IOP returns gracefully (which resumes EE and triggers EE payload).

Table of addresses for completed ports below. It should be possible to port to all versions from 1.00 - 2.13:

readSectors buffer overflow

In 2.14, Sony removed the bounds check on sizes passed to readSectors, so we can reach the following with controlled sectorCount:

0xb31bc:

iVar1 = readSectors(sectorCount,sectorNumber,0xb6c40);

In PCSX2 emulator, we can exploit this bug by overflowing into the stack (you can just spam payload addresses like 0xa00c0000 to that massive range of controlled memory and it will jump to it).

I was super excited by this, and started writing a nice exploit for 2.14+, but then krHacken burned the disc and found out that it isn't accepted by mechacon as a valid DVD Video, so we can't trigger this bug on the hardware. This makes sense; the change was too random to have been a security regression, especially as 2.14 was a release that fixed the readPartitionTables bug, otherwise it would have seemed too much like a backdoor lol