hacking DVD firmware ?

[robinsod]

Hi

There was no specualtion in the previous post, and there's no ARM processor either I've spent the last couple of weeks disassembling that rom image and can tell you that for certain. The standalone player uses the ARM to handle the user interface and there aint one in the H943 (not in mine at least !).

You're right in that the 8051 does not directly handle the SATA interface, instead it loads the offset into DRAM of the data to be sent into custom hardware and that takes care of transmission to the host. Consider the INQUIRY CMD  , the handler is at offset 0xe1dd. Right at the end of the function the DMA controller is setup:

   mov   r6,#4   ; e220   7e 04      r6 = 0x04
   mov   r7,a     ; e222   ff         r7 = 0x00
   lcall   Xcf9d      ; e223   12 cf 9d   
Xe226:   ret      ; e226   22         return

Examining the startup code we see that the following table (an INQUIRY response by the looks) is copied to DRAM at offset 0x400 from ROM offset 0x20b4

0x05, Peripheral Data Type = 5 C/DVD
0x80, Removable Media Bit = 1
0x00, ISO Ver = 0 ECMA Ver = 0 ANSI Ver = 0
0x32, ATAPI Ver = 3 Response Data Format = 2*
0x5B, Additional Length (total = 0x60)
0x00, Reserved
0x00, Reserved
0x00, Reserved
"TSSTCorp" Vendor ID
"DVD-ROM TS-H943A" Product ID
"ms25" Product Revision Level

 0x20, 0x20, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00,
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 0x00, 0x00, 0x00, 0x00, Vendor Specific

 0x00, Major Version
 0x00, Minor Version

 0x16, 0x00, 0x03, 0xA0, 0x00, 0x00, 0x00, 0x00,
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 Vendor Specific params

NOTE:
*Data Format should be 1, but before anyone gets too excited I've already tried reflashing the H-943 with the Response Data Format = 1 and Windows didn't recognise it

[MacDennis]

Examining the startup code we see that the following table (an INQUIRY response by the looks) is copied to DRAM at offset 0x400 from ROM offset 0x20b4

Nice work!
And yes, I can confirm that you are looking at the default response to an INQUIRY command.

[TheSpecialist]

0x32, ATAPI Ver = 3 Response Data Format = 2*

I've checked this for a lot of drives. Drives that work in windows (like the sammy 605 and I checked some PC drives) all have this byte set to $31, drives that don't work in windows (most xbox drives) all have this set to $32... It certainly seems it has at least something to do with it ...

BTW, there are 2 ways to communicate with a DVD drive: ATAPI and 'direct IDE'. Like MTK's flasher tool, can flash via ATAPI and via 'direct IDE'. However, I could not find any info on this last way of communication, how it exactly works. Is there anyone with info about this process or with any interesting links ? Thanks.

[Tiros]

Hi
There was no specualtion in the previous post, and there's no ARM processor either I've spent the last couple of weeks disassembling that rom image and can tell you that for certain. The standalone player uses the ARM to handle the user interface and there aint one in the H943 (not in mine at least !).

You're right in that the 8051 does not directly handle the SATA interface, instead it loads the offset into DRAM of the data to be sent into custom hardware and that takes care of transmission to the host. Consider the INQUIRY CMD  , the handler is at offset 0xe1dd. Right at the end of the function the DMA controller is setup:

I agree about the ARM, I got a little confused @yahoo groups
A great post BTW!
I have sucessfully hijacked the "eject" command. Right now I have it rigged to peek locations in the drive and am working up a little map. I accomplish this by writing the data I'm interested in to the DRAM area the where the response to command (12 INQ) data is stored.  This dram writing is triggered by the eject command. I can then retrieve the data I peeked at by using the INQ command.
This may seem trivial, but it is the framework for bigger things. Right now at least I can run my own code in the drive, hijack a command, and return data. What Fun!!

BTW the 605 works fine in Windows, it returns ATAPI x031 as well, so maybe Spec is on to something. Does bios detect it? I use PLSCSI for all comms with the drive, and IIRC there are a couple of options (switches) on what I/O method is used to send commands. Spec, have you tried them?

[robinsod]

That Response Data Format = 2 looked like a good candidate didn't it? I just checked some 616F Firmware (definitely a PC drive), sadly that has Response Data Format = 2 as well

My PC's BIOS recognises the H-943 drive correctly but WinXP SP2 hangs whilst booting. When I examine the Event log I see the that during the failed boot the PC is continuously attempting to access the drive and failing. The Event ID is 7 and the source is Cdrom, the Description states "The Device, \Device\CdRom0, has a bad block." The data associated with this log entry is:

0000: 03 00 68 00 01 00 b8 00   ..h...¸.
0008: 00 00 00 00 07 00 04 c0   .......À
0010: 00 01 00 00 9c 00 00 c0   ....œ..À
0018: 00 00 00 00 00 00 00 00   ........
0020: 00 68 6e d6 00 00 00 00   .hnÖ....
0028: 69 df 92 01 00 00 00 00   iß’.....
0030: ff ff ff ff 00 00 00 00   ÿÿÿÿ....
0038: 40 00 00 84 02 00 00 00   @..„....
0040: 00 20 0a 12 48 02 00 00   . ..H...
0048: 00 00 00 00 88 13 00 00   ....ˆ...
0050: f8 dc ad 01 a8 d2 8a 86   øÜ­.¨ÒŠ†
0058: 00 00 00 00 88 18 87 86   ....ˆ.‡†
0060: 02 00 00 00 cd cd 1a 00   ....ÍÍ..
0068: 28 00 00 1a cd cd 00 00   (...ÍÍ..
0070: 40 00 00 00 00 00 00 00   @.......
0078: 70 00 03 00 00 00 00 0a   p.......
0080: 00 00 00 00 11 00 00 00   ........
0088: 00 00 00 00 00 00 00 00   ........

MS Provide info to decode such messages here (http://support.microsoft.com/?id=244780) and whilst this is headlined Event ID 51 it appears valid for 7 too. My deocde of this is:

Command:
28                    Its a read
00
00 1a cd cd       LBA = 0x1acdcd
00
00 40               Length = 0x0040
00

Response (mode check):
70
00 obsolete
03 sense key = medium error
00 00 00 00 0a 00 00 00 00 11 00 00 00 00 00 00 00 00 00 00 00

A medium error, this squares neatly with the results I get when I google "The Device, \Device\CdRom0, has a bad block." since the typical response to questions on the subject is "your drive is dying/disk is dirty"

Any ideas anyone?

[SiliconIce]

I am going to post a suggestion:

If you have new material that is related but could fork into another line of discussion, please consider creating a new thread on your specific topic.

At this point, the DVD thread is unmanageable. I am going to add a DVD-specific forum so that all of the DVD-related posts may be collected together.

The new DVD sub-forum is here: http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&board=10.0

Also, the Wiki people were interested in is now up and editable by all:
http://www.xboxhacker.net/index.php?option=com_jd-wiki&Itemid=37

[TheSpecialist]

That Response Data Format = 2 looked like a good candidate didn't it? I just checked some 616F Firmware (definitely a PC drive), sadly that has Response Data Format = 2 as well

Hmm... that's too bad I checked it for about 6 drives, the 'theory' held true for these ...

About your error message:
Using the information on the site, I decode the message as:

0000: 03 00 68 00 01 00 b8 00   ..h...¸.
0008: 00 00 00 00

NTSTATUS Error Code
07 00 04 c0   .......À

Unique Error Value
0010: 00 01 00 00

9c 00 00 c0   ....œ..À
0018: 00 00 00 00 00 00 00 00   ........

Byte offset to bad sector, if any:
0020: 00 68 6e d6 00 00 00 00   .hnÖ....

0028: 69 df 92 01 00 00 00 00   iß’.....
0030: ff ff ff ff 00 00 00 00   ÿÿÿÿ....

SCSI request block structure:
0038: 40 00 00 84 02 00 00 00   @..„....
0040: 00 20 0a 12 48 02 00 00   . ..H...
0048: 00 00 00 00 88 13 00 00   ....ˆ...
0050: f8 dc ad 01 a8 d2 8a 86   øÜ­.¨ÒŠ†
0058: 00 00 00 00 88 18 87 86   ....ˆ.‡†
0060: 02 00 00 00 cd cd 1a 00   ....ÍÍ..
0068: 28 00 00 1a cd cd 00 00   (...ÍÍ..
0070: 40 00 00 00 00 00 00 00   @.......

Sense data structure:
0078: 70 00 03 00 00 00 00 0a   p.......
0080: 00 00 00 00 11 00 00 00   ........
0088: 00 00 00 00 00 00 00 00   ........


Now that NTSTATUS error (c0040007) is interesting. Searching on google I find interpretation of this error as: OPC_E_UNKNOWNITEMID and

"this ItemID is not known. (C0040007)." So, it looks like windows suddenly can't find the drive anymore !?!?!

[TheSpecialist]

Hi
There was no specualtion in the previous post, and there's no ARM processor either I've spent the last couple of weeks disassembling that rom image and can tell you that for certain. The standalone player uses the ARM to handle the user interface and there aint one in the H943 (not in mine at least !).

You're right in that the 8051 does not directly handle the SATA interface, instead it loads the offset into DRAM of the data to be sent into custom hardware and that takes care of transmission to the host. Consider the INQUIRY CMD  , the handler is at offset 0xe1dd. Right at the end of the function the DMA controller is setup:

I agree about the ARM, I got a little confused @yahoo groups
A great post BTW!
I have sucessfully hijacked the "eject" command. Right now I have it rigged to peek locations in the drive and am working up a little map. I accomplish this by writing the data I'm interested in to the DRAM area the where the response to command (12 INQ) data is stored.  This dram writing is triggered by the eject command. I can then retrieve the data I peeked at by using the INQ command.
This may seem trivial, but it is the framework for bigger things. Right now at least I can run my own code in the drive, hijack a command, and return data. What Fun!!

BTW the 605 works fine in Windows, it returns ATAPI x031 as well, so maybe Spec is on to something. Does bios detect it? I use PLSCSI for all comms with the drive, and IIRC there are a couple of options (switches) on what I/O method is used to send commands. Spec, have you tried them?

Very interesting work, Tiros !
Abou the options for I/O methods: you mean the different options for sending ATAPI commands ?

[TheSpecialist]

I am going to post a suggestion:

If you have new material that is related but could fork into another line of discussion, please consider creating a new thread on your specific topic.

At this point, the DVD thread is unmanageable. I am going to add a DVD-specific forum so that all of the DVD-related posts may be collected together.

The new DVD sub-forum is here: http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&board=10.0

Also, the Wiki people were interested in is now up and editable by all:
http://www.xboxhacker.net/index.php?option=com_jd-wiki&Itemid=37

I think this is a very good idea

*EDIT* I've started a subthread on getting the drives working in windows: http://www.xboxhacker.net/index.php?option=com_smf&Itemid=33&topic=258.0

[SiliconIce]

I also think we would benefit if I lock this thread in a few days.

This would help force specific topics to fork into their own threads. In the mean-time, posters should try to organize specific lines of discussion into new threads (for example: discussion of media, multiple brand-specific firmwares, software tools, windows/unix interaction ... many things could probably benefit from diverging into their own threads.)

Please let me know (by PM as to avoid further clutter!)  if you have serious objections, I'll wait a couple days at least before locking anything. I just want to keep this monster from suffocating itself

[MacDennis]

I have looked at a third TS-H943 dump and compared it with the other dumps. Again, only 16 bytes are different. Ths pretty much confirms the unique 'key' story.
It is believed believed this key is used in the following procedure:

• At console start, console creates random data.
• Console sends the random data to drive by using a mode select command.
• Drive uses it's own key and the random data to create a new session key.
• Console sends a mode sense command to read this session key.
• Both console and drive now use this session key to encrypt/decrypt further authentication related x360 communication.

Console re-uses the random data when a different disc is used without power down the console. This results in the same session key being used again.

And Spec, great work again! 

[j005u]

on a side note i thought i'd mention an idea i had a while ago.
i didn't want to make a seperat thread for this nor do i know if this would actually work but here goes:

maybe there'd be a way to make the controller self-flash? asin read a new firmware from the dvd and then flash itself.
now i know this wouldn't be all that easy since the dvd drive itself doesn't handle the filesystem etc. but my idea was that we could, for example burn a fake booktype or media information, which gets read from the leadin and then insert raw data after that, which would be in a fixed format. of course a checksum would be a good idea to insure that you haven't scratched your flashing disc and don't nuke your dvd drive.

heck, i don't even know if the firmware can overwrite itself like that.

but just an idea for easy future updates. probably very utopian. could this be done guys?

edit: .. the leadin could also have the offset for the unique key that each drive has. therefor it could reflash itself with its own key. this would remove the need for a way to dump each unique firmware... although this probably isn't as important since you already need to know your key since you'd first need to flash this firmware onto the chip with other methods.

[InterestedHacker]

That's an elegant solution! =D

[Geremia]

On the legal side, i personally think that a modified dvdburner firmware to write custom data into the leadout would be the safest choice, because illegal will be the way users will use it, not the firmware itself that simply expands capability of the device.

[uberfry]

On the legal side, i personally think that a modified dvdburner firmware to write custom data into the leadout would be the safest choice, because illegal will be the way users will use it, not the firmware itself that simply expands capability of the device.

i thought the media has pre-burnt data that can't be modified?

[NghtShd]

anyway, no offense on the specialist, great work, but, if he would manage to hack the x360 dvd firmware, he wouldn't share it...
wouldn't it be better if we all coded a new firmware from scratch? that would at least be legal...

The problem isn't copyright. A patch wouldn't violate the firmware copyright. So if the problem is the fear of being prosecuted for breaking copy protection then I'm not sure what we're all doing here. You have to get over some hurdles in order to get an alternative OS onto the machine. There may be a few paths we can take on the way in, but I think DVD media is as good a choice as any other at this point, and it seems perfectly legitimate to consider the media type check the first barrier on that path.

Congrats to TheSpecialist. It isn't my ass on the line and I won't tell someone else to hang his out. I'm just thinking it's kind of sad to blueprint the work and then leave it to the modchip people to profit from it.

[T-Snipez]

Evening

I have reassembled the entire original thread and have put it in a ZIP file available for download for anyone wishing to view this thread offline:

http://hyperupload.com/download/899b1762/XH_Firmware_Hack_-_Original_Thread.zip.html

The numbering sequence for the filenames may looking strange at first, but the filename is simply the number after 76. in the page link.  For example, file 820 would be page 42 and the link for page 42 is http://www.xboxhacker.net/forums/index.php?topic=76.820
Well I hope this information benefits those who choose to use it, and I believe the archive date of the thread is the 31st of January.

Best regards,
T-Snipez