Category Archives: DRM

Posts related to the evil of digital restriction management

Xbox Sphinx Protocol

I’ve gone down the rabbit hole of trying to read the Xbox DVD drive from Linux. Honestly, I’m trying to remember why I even care at this point. Perhaps it’s just my metagame of trying to understand how games and related technologies operate. In my last post of the matter, I determined that it is possible to hook an Xbox drive up to a PC using a standard 40-pin IDE interface and read data sectors. However, I learned that just because the Xbox optical drive is reading an Xbox disc, that doesn’t mean it’s just going to read the sectors in response to a host request.

Oh goodness, no. The drive is going to make the host work for those sectors.

To help understand the concept of locked/unlocked sectors on an Xbox disc, I offer this simplistic diagram:


Xbox locked disc diagram

Any DVD drive (including the Xbox drive) is free to read those first 6992 sectors (about 14 MB of data) which just contain a short DVD video asking the user to insert the disc into a proper Xbox console. Reading the remaining sectors involves performing a sequence of SCSI commands that I have taken to calling the “Sphinx Protocol” for reasons I will explain later in this post.

References
Doing a little Googling after my last post on the matter produced this site hosting deep, technical Xbox information. It even has a page about exactly what I am trying to achieve: Use an Xbox DVD Drive in Your PC. The page provides a tool named dvdunlocker written by “The Specialist” to perform the necessary unlocking. The archive includes a compiled Windows binary as well as its source code. The source code is written in Delphi Pascal and leverages Windows SCSI APIs. Still, it is well commented and provides a roadmap, which I will try to describe in this post.

Sphinx Protocol
Here is a rough flowchart of the steps that are (probably) involved in the unlocking of those remaining sectors. I reverse engineered this based on the Pascal tool described in the previous section. Disclaimer: at the time of this writing, I haven’t tested all of the steps due to some Linux kernel problems, described later.

Continue reading →

PS3 Notes

I have been working (and occasionally playing) with my PlayStation 3 recently. I upgraded the 80 GB internal hard drive to a 1/2 TB one. Since I have the old 80 GB HD laying around, of course I have to plug it in and see if there’s anything familiar about the data. It’s a short exploration: As you might suspect, the HD is completely impenetrable. No partition table reported through Linux fdisk. No human-readable strings can be seen when running ‘strings’ over the raw HD sectors. Based on forum postings I have read where one PS3 HD can’t successfully be transplanted to another PS3 (and have all the data accessible; the HD could still be reformatted fresh to work in another PS3), I’m guessing that every sector is encrypted with a key derived at least partially from a unique ID embedded in each console. That’s all the effort I plan to put into this exercise. Next stop for this HD is my Eee PC 701 which is currently struggling to run Ubuntu Linux on a mere 4 GB SSD.

I downloaded a free movie trailer through the PlayStation store. When I inspected the information through the PS3’s XMB menu, the filetype was reported as “MNV”. A little Googling ties this format into the paid content format of the PS3 store. I’m not especially confident about this format since the trailer that I downloaded doesn’t even play correctly on the PS3. The video stutters back and forth, almost as though it’s swapping pairs of frames during playback: 1, 0, 3, 2, 5, 4, 7, 6, etc. The XMB allows me to “backup” this media. This option needs to be distinguished from “copy”, which is sometimes an option. “Copy” implies an unlocked version that can be copied onto removable media and used anywhere. “Backup” implies that it can be copied onto removable media but is still keyed to — and can only be used on — this console. I backed it up and was able to inspect the data on the USB drive. It turns out that the MNV file is still a stock MP4 but with custom DRM. When FFmpeg is aimed at this file, this is the result:

[h264 @ 0x1004000]AVC: nal size -2055117847
[h264 @ 0x1004000]no frame!
[...repeated many times...]
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x1002600]max_analyze_duration reached

Seems stream 0 codec frame rate differs from container frame rate:
 48000.00 (48000/1) -> 23.98 (24000/1001)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
 '/Volumes/KINGSTON/PS3/EXPORT/VIDEOBKP/20091220-220733-00000001/20091220-220733-00000001.001':
  Metadata:
    major_brand     : MGSV
    minor_version   : 20842393
    compatible_brands: MGSVmp42isom
  Duration: 00:01:46.64, start: 0.000000, bitrate: 8651 kb/s
    Stream #0.0(und): Video: h264, 2205 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 48k tbc
    Stream #0.1(eng): Audio: aac, 48000 Hz, stereo, s16, 264 kb/s
    Stream #0.2(eng): Audio: aac, 48000 Hz, 5.1, s16, 395 kb/s
    Stream #0.3(und): Data: mp4s / 0x7334706D, 759552 kb/s
Video pixel format is unknown, stream cannot be decoded

I remember some patches flying around the FFmpeg-devel list recently which would allow the program to print warnings and bail out if it encountered a known DRM scheme. When I shove an Apple-encrypted file through FFmpeg, it doesn’t tell me anything special so I don’t think the patch is in yet. However, FFmpeg should probably detect this type of DRM file as well.

DRM Hits Home

This is positive news when viewed from a certain perspective: MLB rips off fans who bought DRM videos. So Major League Baseball (a big deal in American sports) had a media download service that was protected by iron-fisted digital rights management. It was the type of DRM that called home for authorization to check if you still had permission to view the downloaded content. And the mothership had decided to go with a different DRM system or provider.

I wonder if this is high profile enough to set a serious example for the implications of consumer media DRM? I know it’s a wake-up call for me to remember to crack all of Apple iTunes Music Store purchases while the keys are still somewhere on my computer.

According to the discussion linked above, MLB may have relented somewhat and offered existing consumers a means of re-downloading their purchased content under the new system. So maybe this episode won’t provide much of an object lesson after all.

AACS “Cracked”, Finally

Several people have pointed me to the news that claims of cracking AACS (the content protection system protecting both Blu-Ray and HD-DVD discs) have been leveled. Here is a doom9 thread on the matter. My first reaction was, “What took so long?” Conceptually, it should have been pretty straightforward to understand the entire system and recover secret keys since technical documents on the matter are quite openly available. I always considered that rather odd since a large part of DRM’s efficacy hinges on obscurity.

Good news, nonetheless, if it’s accurate.