Hacking xbox dvd drive firmware

Anyone up to the challenge of sticking it to Microsoft and firguring out the key exchange & decryption that takes place in the xbox dvd drive?

I typed my guts out on a previous post and lost it I think cause I timed out…

I saw your post on XS and I’m very interested, but I don’t really know how you would go about it. You seemed to be on the right track and I don’t know how much I can help, but I know assembly and I know how to extract the kernel from the bios. I sure however, that’s completely different from the Dvd-rom. I don’t know the first thing about cd\dvd firmware.

After reading your post I immediately got the 605 and 616t firmware and compared them with hex edit just to see what was similar. As expected, nothing special. So then I tried to disasemble the firmware, you said an Intel 8051, but when I opened the drive I found a Mediatek MT1326f uP. I can’t find the datasheet as of yet but I’m sure it’s based on someone’s core. It appears to be pretty common throughout dvd-roms so if we get this going, it should open up compatibility for a lot of other drives.

Also in my research I found forum.rpc1.org which seems to be more hardware oriented, you might try there.

does it actually take place in the drive or on the mainboard ?
I assume you are talking abou this firmware ? : http://www.xbox-scene.com/articles/samsung-616t.php

yeah, I think the copy protection scheme is built into the dvd-rom. In fact, I’m almost positive. You can swap the stock dvd-rom with any PC dvd-rom, you just have to figure out how to rewire the eject button to work with that yellow cable on the back of the stock drive. There’s tuts on XS that show you how to do it, its fairly common. Only problem is that you won’t be able to read Original game disks. That was my first clue that it had to be in the dvd firmware.

I managed to extract to system kernel with a guide from xbox-linux, look through it with a disassembler and found the section that mounts the dvd-rom (/device/CDROM0) and reads UDF disks. According to a PDF I found from OSTA, the calls seemed to match the sample code on the bottom of the doc. Plus that wouldn’t explain why you couldn’t read original disks after you swap the drive if the copy protection was in the kernel (after the data comes off the IDE cable). It has to be before, because the drive won’t recognize the disk. A normal computer won’t mount a Xbox DVD anyway, but you can read it with special programs that know what to look for in in the file system.

Something tells me this may be a lot harder than I first thought. It’s not like you have to hunt down a bit and change the value. We probably have to find the jump call to the section that handles reading from the original firmware. Then find the same jump point on a normal drive and replace it withh the new function (assuming the assembler is written like oop).

So everyone fire up IDE and start lookin. :slight_smile:

Hope getting closer…

I’ve made a some progress with the MediaTek firmware on the Samsung 605E in some xboxes. First, just to clarify I’m not trying to maliciously circumvent their copy protection… I just want to move the copy protection to a dvd-rom that’s faster (the original is painstakinly slow) and one that can read my personally burned audio cd backups (2/3 of the drives in an xbox can’t).

As mentioned before, the particular uC that is in this drive (MTK1629E) uses an instruction set compatible to an 8032. That uC is in turn similar to the 8052, or its older counterpart the 8051. There is a pretty good simulator called Simulator 2003 available from www.fstsoftware.com for these series chips.

There is a wealth of knowledge about the chip and how to program it on www.8052.com. On that website I learned that you can only address 64k of memory at a time on the chip. Which seems odd because the firmware for the 605e is 128k and the firmware for the 616t is 256k. If you break the firmware up into 64k chunks you can see by the hex dumps that there is code common to all of them. I’ve read on mailing lists for the MTK13x9 uC that there is code that sets up the stack for paging, and there are jump tables for paging. Setting the common portions of the pages aside there is still a substantial amount of data.

What I’ve been trying to do so far is to try to identify the different subroutines. I’m not sure which subroutine is the main program yet because I don’t have a dump of the eeprom to see the entry point. Once I’ve got a list of subroutines, I’ll then compare the subroutines from the 605e (xbox) with the 616t (generic). Hopefully then I’ll have a better idea of what additionally is required to run an xbox dvd.

btw there is a gnu dissasmbler called d52 thats good for this stuff. get it from http://www.8052.com/users/disasm/.

Black

Any progress?

Interesting!
I have looked on the assambly code for 605B.I’m looking for the booktype check.
Would like to patch the firmware to take dvdr+ booktype.
It may be a good tip to check out the “SCSI Multimedia Commands” http://ftp.t10.org/ftp/t10/drafts/mmc3/mmc3r10g.pdf

Have you found out anyything from looking at the assambly code?

hmm do you have the firmware for 605E?

I honestly believe that the decryption occurs in the firmware, however, the biggest difference between a regular dvd-rom drive is that the xbox drive might actually be spinning in reverse… thus, it’s more of a barrier to get across… I believe that the data is read backwards, but according to the XDVD format, it’s forwards…

Layer1 is read ‘backwards’ to the DVD-Video specification, but correct for the XDVD spec.
Layer0 contains 3.2GB of XDVD-formatted data, and approx 100MB of DVD-Video data. The 3.2GB partition can be used for game data, while the DVD-Video partition is always used for a video file that states something along the lines of “This is an xbox game disc. It cannot be played on this device”…

A regular DVD-Rom drive, connected to a PC, can read the DVD-Video partition, but cannot even SEE the XDVD partition/Layer1.

I’m guessing that the XDVD format is programmed into the drive firmware in a low-level state… it’s the only thing that makes sense.

Thus, both XDVD-formatted and DVD-Video formatted layers can exist on a single disc.

Here’s another interesting thing. Putting the xbox game into the xbox and browsing it with a file explorer or via ftp, you can only see the xbox data, and not the other session.

Actually, sometimes, if your xbox is modded, and manages to not read a game dvd correctly, it can sometimes see the DVD-Video partition… which is always a strange occurance, because we’re not expecting to see something that says VIDEO_TS in a file explorer on an xbox, with an xbox game inserted…

my 616t firmware is 128KB
I too have read up at that yahoo group,
What are your findings till now?
I have managed to find the same botstrap in both 605B and 616T.
Then delete all botstrap, then split the remainding into 64KB chunks,
I will get 1 64KB file and 1 17KB with 8031/8051 bin, dissasmable that, And looking on those asm files, I see that there are many similarityes, many jump adresses are alittle different, but it looks very alike. But I’m very interested in knowing what Black_Like_A_Cat have found out!

anyway I think the secrect of reading xbox discs lies in the arm prossessor code (the bin file consist of 8052,arm, and dsp… or something like that), as I have read on the yahoo group this code is compressed and lies after the bootstrap code. The 12th hex from the bootstrap code will give the number of blocks compressed, I read 3c=60 in my hex editor. But I’m not sure it that is correct. anyway the decompressing code is availeble on the yahoogroup.

If any of you find the routine that has something to do with the booktype reading (4 bits located in the leadin at every dvd disc), please let me know!

It doesn’t spin backward, how would it play DVD’s? The motor hack is on the TRAY motor, which is reversed between the XBOX vs retail Samsung units. Layer 1 of a DVD can be read two different ways, OTP (opposite track path) and PTP (parallel track path), discs are pressed one way or the other. OTP is typical for Video DVD as the head doesn’t have to seek at the layer transition, the head starts at the inner edge, moves to the outer edge, transistions layer, and then moves back to the inner edge. The drive motor does not change direction.

There is no ARM code in MTK drive chipsets, the 8051/ARM chip is used in a stand alone DVD player chipset. The ROMs on the 8051/ARM chips are typically 1MB+, not 128KB

Brother Vlad

Hi there, Thanks!
this clears up some. (on the reverse thing)

hmm no arm code? are you sure?
I know there is a big difference in dvdplayer roms on the size, but there we have, sounds,pictures, menues and all sorts of data.
If there is no arm code, it must have been a coincidence that I found the exact same hex that is the bootstrap in a stand alone dvdplayer rom with mtk chipset.

_

Ah, alright. What I was meaning by the reverse thing: The actual data is read backwards – IE: Big Endian. What gets me, however, is that we can burn xbox dvds, but not read them… If anything, we should be able to read them, but not burn them…

Try 2 check the Starwars extra DVD, it also has Xbox content,but its a video dvd, maybe it helps. (The original trilogy)

Think it’s over now… :(((

can’t writing be a total different engine than the reading engine?

http://www.xbox-scene.com/tutorials.php?p=191|192|#192