3.03 - 3.11

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

3.03 3.04J 3.04M 3.10 3.11
Symbols
getDiscData 0x243438 0x23e150 0x23e138 0x25c9f0 0x258b98
getDiscByte 0x243368 0x23e080 0x23e068 0x25c920 0x258ac8
currentDiscBytePointer 0x15f42a4 0x1273ae4 0x16ceee4 0x1411fe4 0x143b3e4
endDiscBytePointer 0x15f42a8 0x1273ae8 0x16ceee8 0x1411fe8 0x143b3e8
0xff * 3 * 8 overflow 0x241d0c 0x23cb1c 0x23cb04 0x25b3bc 0x257564
fpIndex 0x15f4b0a 0x127434a 0x16cf74a 0x141284a 0x143bc4a
fpArray 0x923d88 0x6d4e68 0x95ace8 0x5b9d40 0x3b3050
OOB call 0x0244E1C 0x23fad4 0x23faac 0x25e388 0x25ab44
getBufferInternal 0x262360 0x261560 0x261548 0x2986a0 0x2952f0
pointToIFO 0x2432c8 0x23dfe0 0x23dfc8 0x25c880 0x258a28
SifIopReboot 0x291528
SifInitRpc 0x2082a0 0x208260 0x84180 0x208d80
SifExitRpc 0x208440 0x208400 0x84310 0x208f20
SifIopReset 0x291fb8 0x291358 0x84fe0 0x20e7d8
SifIopSync 0x292138 0x2914d8 0x85110 0x20e958
Controlled memory ranges
Destination of large copy 0x15ec890 0x126d8d4 0x16c8cd4 0x140bdd4 0x14351cc
Destination + max size 0x176C878 0x12AD8D0 0x1848CBC 0x158BDBC 0x15B51B4
Exploit values
currentDiscBytePointer value at overwrite 0x015f1008 0x01273044 0x016ce444 0x01411544 0x0143a94c
Jump target 0x15ea540 0x0126b7e0 0x01800180 0x01500014 0x01500014
Address of jump target 0x928D24 0x6D9C3C 0x95CF40 0x5f1f38 0x3EA438
Intermediate jump location 0x012811E4 Not required Not required Not required
Intermediate jump target 0x01281340 Not required Not required Not required
IFO offsets
currentDiscBytePointer 0x1c6c (4 bytes) 0x2744 (2 bytes), 0x2c26 (2 bytes) 0x2744 () 0x2744 (4 bytes) 0x277c (4 bytes)
fpIndex 0x24D2 0x29ea 0x2faa 0x2faa 0x2fe2
Payload 0x0e8c 0x2880 0x2d00 0x2bb4 0x2954

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


Conflicts

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

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.


Hunting for new vulnerabilities

Those buffer overflows are really easy to find as the IFO parsing is the first thing the DVD player does. 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.