hacking DVD firmware ?

[TheSpecialist]

Hi,

I was just wondering, wouldn't it be possible to hack the firmware of the DVD-ROM drive so that you could play backups ? I mean, the 360 will execute a (signed) game executable,only if it is loaded from 'secure media' (original xbox DVD rom media). Wouldn't it be possible to hack the firmware in such way that it would always report the mediatype as 'secure medium', so that the 360 would think an original DVD was inserted ?

[BlueCop]

Does anyone know of high resolution pictures or scans of the DVD-Roms internals or just pictures of it taken apart. i currently don't have 360 =( or else i would scan some. anyone willing to take their drive apart and perhaps dump some chips. if you can then make sure to document the rom version. free360 says "0046DH (Core) 0047DJ (Premium)".

also what happens when you trade premium drive with another premium drive or core with core. I guess most of this will be answered in time.

i am more interested in the possibility of moding a game disc data for our own purposes.

[anita999]

frankly speaking, I truely believe that this might be the very first "patch" to xbox360 systems instead of regular "mod".

[alou]

What makes you think XBOX 360 DVD firmware would not be also "signed" by M$? And therefore altering would destroy the "hashed" firmware and therefore not being accepted by hypervisor or whatever?

Just my though on that.

[QuiescentWonder]

What makes you think XBOX 360 DVD firmware would not be also "signed" by M$? And therefore altering would destroy the "hashed" firmware and therefore not being accepted by hypervisor or whatever?

Just my though on that.

Well... I don't really know but I doubt that the drive firmware is signed.

[TheSpecialist]

Well... I don't really know but I doubt that the drive firmware is signed.

I agree. While it is of course possible, I highly doubt that they signed the firmware in the drive. In the original xbox the firmware was not even encrypted, let alone signed. It wasn't a hacking target for the first xbox generation, so there's a very good possibility that M$ didn't focus too much on the DVD drive this time. And even if it was signed, then it's still possible to hack it, since its the CPU in the drive that transfers the signature to the CPU in the 360, at its request. So if the XBOX CPU asks for the signature, just let the DVD-drive send a fake signature back. Only way to make it hack proof is if the CPU in the drive does the signature checking (or the routines to send the signature are inside that CPU), but I *highly* doubt that M$ has also developed that cpu from 'ground up'. And EVEN if they have designed the CPU in the drive from ground up and made it 'unhackable' -> we can always replace the drive with some other, with our own custom firmware

But like I said, i highly doubt the firmware is even signed. Now, we need dumps of the firmware, photo's of the internals of the drive, since I'm personally also still waiting for my 360 

[kday]

I agree. While it is of course possible, I highly doubt that they signed the firmware in the drive. In the original xbox the firmware was not even encrypted, let alone signed. It wasn't a hacking target for the first xbox generation, so there's a very good possibility that M$ didn't focus too much on the DVD drive this time. And even if it was signed, then it's still possible to hack it, since its the CPU in the drive that transfers the signature to the CPU in the 360, at its request. So if the XBOX CPU asks for the signature, just let the DVD-drive send a fake signature back. Only way to make it hack proof is if the CPU in the drive does the signature checking, but I *highly* doubt that M$ has also developed that cpu from 'ground up'. And EVEN if they have designed the CPU in the drive from ground up and made it 'unhackable' -> we can always replace the drive with some other, with our own custom firmware Smiley

But like I said, i highly doubt the firmware is even signed. Now, we need dumps of the firmware, photo's of the internals of the drive, since I'm personally also still waiting for my 360  Smiley

Correct me if I'm wrong, but wouldn't the hypervisor prevent this from happening?

[TheSpecialist]

Correct me if I'm wrong, but wouldn't the hypervisor prevent this from happening?

The supervisor 'supervises' xbox memory, not the internals of the drive. And even if it somehow could, then it would only detect 'unauthorized memory writes' at runtime and it would still not detect a modified bios.

[RuNNiNG_WiLD]

I was discussing on IRC a few nights ago. It does seem quite feasible - to my understanding anyway.
Someone needs to get the firmware (One was or another) and start reading through it. Assuming its not encrypted to any serious degree. (Can you even encrypt firmware?!)

[TheSpecialist]

Now, to get this thing going, we need to understand how exactly the 360 decides that the media in the drive is an original XBOX DVD-ROM. It's probably done in the exact same way as the original XBOX does. So, if someone has details about this process, feel free to share them If not, we just have to find out by either tapping the SATA bus or disassembling the ROM or even better: the combination of these two 'Anita999' already showed in another thread that he had succesfully tapped the communication between the xbox and the DVD-drive, so that's at least one scener that can help

Furthermore, like said before, dumps of the firmware and high res pictures of the drive internals are needed to get this thing started.

[TheSpecialist]

A quote from Anita999:

The mode sense and mode select are implemented with 12 bytes command format. and right after mode select command, the kernel will send out a data string to DVD drive, and the DVD drive will response a data string right after a mode sense command.
here is a general scheme:
1. READ SMART
2. Mode Sense, ret 0x51 error.
3. Request sense
4. Mode sense
5. read DVD structure
6. Mode select and mode sense sequences
7. Read capacity
8. Read block#20h, length 02h,  (this shall be the root directory of xbox disk file system).
9 Read TOC/PMA/ATIP
10. Read blocks based on the info of block#20h.

if you put a burned disk in the xbox, then steps 5,6 and 9 will be skipped.

So, the XBOX knows after the first 4 steps that it's a burned media that's inserted.

[TheSpecialist]

First 4 steps communication (again thanks to Anita999) =>

ATA CMD   Description

B0   Read HDD SMART

A0   PKT CMD 5A Mode Sense
   5A 00 3E 00 00 00 00 00 1C 00 00 00
   page code 3E, subpage code 00, page_0 format required
   Ret Status 51 Error

A0   PKT CMD 03 Request Sense
   03 00 00 00 12 00 00 00 00 00 00 00
   DESC=0 for fixed format, alloc length =12h
   "Return 06 00 06 00 00 0A 00 0A 00 00  00 00
               00 00 00 00 00 00 00 00 00 00 00 00"

A0   PKT CMD 5A Mode Sense
   5A 00 3E 00 00 00 00 00 1C 00 00 00
   page code 3E, subpage code 00, page_0 format required
   "RET 00 00 00 00 00 00 00 00 00 01 00 01
                01 00 01 00 00 00 00 00 00 00 00 00
                00 00 00 00"
   Ret Status 50

A0   PKT CMD AD Read DVD Structure

[TheSpecialist]

A0   PKT CMD 5A Mode Sense
   5A 00 3E 00 00 00 00 00 1C 00 00 00
   page code 3E, subpage code 00, page_0 format required
   Ret Status 51 Error

Like it already says -> $5a is opcode for the 10 byte version of the 'mode'sense command. $3e is the Page Control. $1C is the amount of bytes that reserved for the answer to this command. $1c=28 bytes, which is the amount of bytes it returns the second time.

A0   PKT CMD 03 Request Sense
   03 00 00 00 12 00 00 00 00 00 00 00
   DESC=0 for fixed format, alloc length =12h
   "Return 06 00 06 00 00 0A 00 0A 00 00  00 00
               00 00 00 00 00 00 00 00 00 00 00 00"
Same thing, $03 is opcode for 'request sense', $12 is the allocation length for the response.

If anybody has some insight on the returned data, feel free to share

Note that this is of course data for the original xbox, but it's a beginning

[anita999]

Something to add on.
1. The mode select/mode sense sequence will loops in different times depends on the disk.
2. I believe that the data communicate during these mode sense/mode select is some kind of chanllenge/respnose sequence which enable the DVD drive to read the DVDROM correctly.
3. To reverse engineer the xbox BIOS and DVD drive firmware will help us to understand this more clearly. But in xbox BIOS, this DVD access is indirectly called and very difficult to trace unless there is a real time kernel debugger. And the DVD drive firmware is somehow with some compressed data and as I mentioned there are no resources available for these DVD drive controllers though some of them are 8051 based.

[TheSpecialist]

2. I believe that the data communicate during these mode sense/mode select is some kind of chanllenge/respnose sequence which enable the DVD drive to read the DVDROM correctly.

That certainly seems to be true:

Finaly I am able to read one game DVD using XBOX DVD unit connected to my PC.

Here are some FACTS which I discoverd:
1) First of all, XBOX DVD is not using ATA password protection.

2) XBOX DVD is initialy in "regular DVD" mode, where it behaves like a normal PC DVD. It can't read upper sectors and it reports wrong capacity. The same way your PC DVD behaves.

3) When you insert a game to XBOX, it sends sequence of MODE SENSE/MODE SELECT commands to UNLOCK the DVD! After that sequence all sectors can be read and it reports right capacity. The MODE SELECT commands are sending values which are diffrent for each game DVD. So there is no common values which unlock the DVD for all games. The MODE SENSE/SELECT commands query & sets some vendor specific data as is written in the ATAPI specs.


An anonymous person sent me the Log of what's going on on the IDE cable when game DVD is inserted.

I wrote a program which repeats the sequence of ATAPI commands, so I can read the DVD. It works! However it works only for that game which he inserted when he created the log.
For other games the values send to the DVD in the MODE SELECT are diffrent. It's like each game has different password. This passwords is based on data recieved by READ DVD STRUCT command.
For that there must be some logic/algorithm in the BIOS. It would be easy to figure it out when we have the decrypted BIOS. (How are you guys doing on that in the BIOS department?)

[anita999]

1. The idea of compressed code and DSP unit comes from a message group dedicatef for MTK MT13X9 DVD player controller. They actually developed some utilities to decompress the code.
2. Yes, I logged the command with a standard Logic Analyzer. And I referenced the ATA spec. and made some rough comment. There is a ATA/SATA protocol analyzer which can easily log and identify each ATA command which will save much time when you want to trace it.

your finding seems to be interesting. I will check with my disasm database again to confirm this finding. it's good to have someone work on similar things.

[TheSpecialist]

1. The idea of compressed code and DSP unit comes from a message group dedicatef for MTK MT13X9 DVD player controller. They actually developed some utilities to decompress the code.

Very interesting ! Do you have a link to this group and/or decompression utilities ? Do you have any idea on how the compression works ? I mean, is the firmware 'self decrypting' or does the Mt1329e have some specific routines to do this ?

From my findings, I believe it would be the first option. I found code (like above) in the firmware that seems genuine 8051 code. However, when you trace the jumps and calls long enough, I always end in some 'weird' section, like jumps into the middle of an opcode for example or 'weird' instructions that just don't make sense. So it would very well be possible that a part of the firmware is encrypted.

it's good to have someone work on similar things.

I totally agree

[Mjrweed]

What if someone managed to swap the dvd-rom with a standard pc dvd-rom, wich would probably already have a hacked firmware for easy further development? (I mean if one cant hack the 360 dvdrom firmware)
Just a thought.....

Oh and btw, wont the executable have to be signed for it to run anyway? Even if it reports secure media?

[anita999]

sorry the link is not in my favorite now. but your may search "mt13x9@yahoogroups.com" for the message group.
The MTK controller they're studying is a DVD Player controller which also decode the MPEGII stream. So it require a DSP unit (embedded) and the firmware is way large than a regular DVD drive firmware. There are some documents and utilities which show you how the firware are sectioned/compressed and also some IDA signatures to identify regular routines. But they are not 100% applicable to our target. I tried to apply the decompression tool directly but it didn't work. But IDA signature did recognize some subroutines. I think MTK engineers uses the dvdrom drive controller to develop this DVD player controller. So most of the software resources must be common to each other.
Some thing I found.
1. both MTK controllers use 8051 core.
2. the firmware are sectioned in 64K, which can be switched by the firmware itself to extend the memory space. But some common vectors in the head are the same.
3. There seems to be possible compressed data/code section in the SDG605 firmware which simiilar to the DVD player controller. But the starting offset is not the same.

If we wanna keep on reversing this firmware, then the compressed section must be confirmed/identified/decompressed first. I am nor familiar to 8051, either. It's a little bit difficult for me the trace the code in IDA.

[anita999]

OK, here is the web link to the message group.

 http://groups.yahoo.com/group/mt13x9/

it's totally legal, I think it's OK to post the link here.