hacking DVD firmware ?

[jasper]

Assuming the calls to check the security placeholders can be identified (some heuristic or even better, a particular function call in the firmware), this method could also be defeated by returning the information gleaned in the ripping process or reading from the table if it contains the same data.  Like:

boolean areAllTheSecurityPlaceHoldersInTheRightPlace() {
  return true;
}

[jasper]

Hi by the way, have been following along since the beginning.  I actually searched out this thread - this was the exact style of hacks I predicted for the 360 and I am very happy to see all the progress already.  Great analyses.  My software skills aare at other levels so I can't contribute anything at this time other than ideas but I'm happy to share those.  Most important I am dying to see the difference between 2 deobfuscated, same-version dumps from 2 different boxes.  I can almost see the future unfold - 2-3 months of firmware hacking to write the new code to emulate the table or look for it elsewhere, clip-on programmers to read/modify/write the drives, etc.  Very exciting.

[Geremia]

tryed to tell you but admins trashed the post

Now thinking and kiddin: what the real problem for having an exact 1:1 copy? not burnable area at beginning of the disk? not burnable crappy data sectors?
What about patching the dvdrom firmware to think that the first readable are is in real a little step forward, in a zone that we can burn with data we want? maybe we need also a modified dvd burner firmware to let us burn raw data, to shift the TOC a little far from the beginning, to write all the pressed stuff in a confortable zone. This way the dvd media will be faked at a lower level.
Don't know if i'm just tellin bull$#!t, in case have a lought and go on  

[TheSpecialist]

What about patching the dvdrom firmware to think that the first readable are is in real a little step forward, in a zone that we can burn with data we want?

That's what I meant with "rerouting the FW to look to another place", but I think that the problem remains -> since a burnable Double Layer-DVD has less sectors than a DVD-ROM (well, I think it has, hasn't it ?) we just can't do a "100% correct emulation" if they're using all bytes on the DVD-ROM ... Only way it could be done I think, is if the burnable DVD would have more sectors than a DVD-ROM, because then we could use some block that's not on the DVD-ROM and 're-route' the FW to look in that block (and hide the block to the system).

Anyway, I'm off to bed, gonna think about this a while

[Geremia]

That's what I meant with "rerouting the FW to look to another place", but I think that the problem remains -> since a burnable Double Layer-DVD has less sectors than a DVD-ROM (well, I think it has, hasn't it ?) we just can't do a "100% correct emulation" if they're using all bytes on the DVD-ROM ... Only way it could be done I think, is if the burnable DVD has more sectors than a DVD-ROM, because then we could use some block that's not on the DVD-ROM and 're-route' the FW to look in that block (and hide the block to the system).

Don't know about sector number difference, have to check, anyway a little overburn could be done.

by the way, applied the Loser decrypter to the combo dvd/cd-rw firmware xored with its own different xor mask, single bytes are correct and bytes 1<->3 5<->7 swapped

Code:

00008000 2D 4C 48 44 53 2D 54 54 44 56 44 2D 4D 4F 52 20 -LHDS-TTDVD-MOR
00008010 70 6F 43 79 67 69 72 68 48 20 74 69 63 61 74 68 poCygirhH ticath
00008020 4C 2C 69 74 32 2E 64 30 20 32 30 41 20 6C 6C 72 L,it2.d0 20A llr
00008030 68 67 69 74 72 20 73 65 72 65 73 76 2E 64 65 20 hgitr seresv.de

[anita999]

Just a crazy idea. What if we can also patch a SATA HDD's firmware? So we can emulate the DVD ROM with any capacity we want. All raw sectors can be stored in a  image(ISO) file, no more capacity issue. The only problem is that to reprogram the HDD firmware to emulate ATAPI device might be a total reprogram. And there is less resources available regarding to those HDD controllers. all datasheet are confidential. Maybe we can have some help from people in the HDD industry. Hope this kind of "team work" can keep on going and having good result soon.

[Rusty]

anita, would one of these help? http://www.ioisata.com/products/prodcategory.asp?ProdCategoryID=1001  The only problems would be ripping the data to the hard drive and writing the firmware for an undocumented device.  I have been looking for an embedded linux system that would enable this type of development, but haven't found one. It would make things like atapi emulation a lot easier.  This is sounding like quite a project though, but it would make it much harder for microsoft to upgrade out of it.  Rather than switch drives, they would have to block the bridge from working.  And it might be easier than working with an even more proprietary hard drive firmware.

[anita999]

looks like a good solution, but again these chips are without datasheet. I also allocate some SATA/IDE bridge on hand, but it seems that they are likely state machine based instead of firmware controlled. it will be gread if we can find a MCU with SATA upper link and IDE down link.

[Rusty]

After a lot of searching, i found a controller that fits the bill http://www.siliconimage.com/docs/SiI%204723%20Prod%20Brief_FINAL.pdf  These have external firmware, so size wouldnt necessarily be an issue.  The main issue would be techincal expertise to get it done, and finding a resonably priced device that incorporates one of these.  The device could rip the games to a file, and implement some sort of mp3 or audio disk based menu system where playing a certain track causes the microcontroller to switch to the game that you want.  Not quite the full system access that is found in current xbox mods.  This sort of attack would present a lot more points open to find buffer overflows, ie anything that is unsigned would be a target, not just user data.

Sorry for getting off topic.

[loser]

im keen just to do what the topic says and "hack the dvd firmware"
hack it for the sake of hacking it, bending it to your will and making it do what you want it to do

it may end up getting hacked to *authenticate* burnt games, but it'd be fun to just make it eject the tray every time a celine dion cd was inserted hehe

[tser]

theoretically, we could modify the firmware also, to redirect the other security placeholders, to a location, where we can burn it.. without letting the software know that..a fter all, they are sending out a commando, and do not do a pfysical examination of the disc

A good and safe location would be to store them inside the first sectors of the disk, since i asume the contents of that movie on the "primary" toc is not checked.

On a side note, a read a story somewhere who goes like this

a) open up a dvd drive, until you can phyiscally put in a dvd yourself from above
b) Insert a very large dvd
c) let it authenticate, wait till it spins down
d) swap it to above with a xbox disc
e) you now can grab all sectors...
(and i wonder if that is also after the lead out!)

I am going to demolisch a ancient dvd player for that today.


And just remember.. There are just bits on the DVD Disc... and bits... we allways could read.
(and specially if they can do, it with sending a command.. we can also send those things

[BlueCop]

I think a modified 8050L firmware(flashed to an 8163B) to auto authenticate orginal discs so they could be easily read in the pc. even make 360 discs read automagicly. It should be possible since they are so similar. At least it would allow people to legally look at the game files off 360 discs.

I just ordered a couple 8163B drives from newegg to play with since i can't get a 360 right now and have a samsung or phillips in my xboxs.

[amadeus]

a) open up a dvd drive, until you can phyiscally put in a dvd yourself from above
b) Insert a very large dvd
c) let it authenticate, wait till it spins down
d) swap it to above with a xbox disc
e) you now can grab all sectors...
(and i wonder if that is also after the lead out!)

If the firmware was hacked to dump the bits the DVD reads to the DVD LED, then could the DVD LED be rewired to a serial port on a pc and dumped 

Or perhaps could the tray signal be rewired, if it can handle higher frequencies, and used to dump the data.

[loser]

i think i read that others looked at similar drive firmwares, but thought i'd post what i found anyway.

i downlaoded and looked at the firmware for the following drive "HL-DT-STDVD-ROM GDR8163B0L230BLBA   04/06/19"
it decrypted ok using the decryptor tool, and i noticed that the first 95 bytes in the resultant file were the same as the first 95 bytes of the xbox360 firmwares we have been looking at. many other bits are also quite similar.

[loser]

i just tried starting up my pc with the xbox 360 dvd drive connected to one of my sata slots while using power/eject from the xbox360 cable.
the drive appears in my bios, but once in windows there is no sign of it.
so not sure if it times out by the time windows loads, or if windows doesnt like it, or what.
(i am running windows xp x64)

[wildje]

i just tried starting up my pc with the xbox 360 dvd drive connected to one of my sata slots while using power/eject from the xbox360 cable.
the drive appears in my bios, but once in windows there is no sign of it.
so not sure if it times out by the time windows loads, or if windows doesnt like it, or what.
(i am running windows xp x64)

The firmware could actually 'lock' the drive if it does not receive a challenge within a set timeframe or somthing.. ?

[FuzzyLogic]

What about patching the dvdrom firmware to think that the first readable are is in real a little step forward, in a zone that we can burn with data we want?

That's what I meant with "rerouting the FW to look to another place", but I think that the problem remains -> since a burnable Double Layer-DVD has less sectors than a DVD-ROM (well, I think it has, hasn't it ?) we just can't do a "100% correct emulation" if they're using all bytes on the DVD-ROM ... Only way it could be done I think, is if the burnable DVD would have more sectors than a DVD-ROM, because then we could use some block that's not on the DVD-ROM and 're-route' the FW to look in that block (and hide the block to the system).

Anyway, I'm off to bed, gonna think about this a while

As they reserve space for their "security placeholders" i think that a Dual Layer DVDR can contain more data, then their pressed DVD-ROM disc can hold.

part of their patent:
"Files stored on a secure disc produced using this format must be placed in the available 3.2 GB of storage per layer provided in the 18 segments defined by the placeholders. The sizes of the segments are not fixed, but instead, typically vary from one DVD to another. Although the placeholders can be moved from their initial position, any change in position must be done in an automated manner, in accord with the predefined rules, which are not made known to a developer. "

3.2GB per layer makes 6,4GB of total effective storage per disc. As i understood from a previous post, each security placeholders data (well atleast the response) is only a couple (11?) of bytes, so their is plenty of storage left on the disc, to store whatever we want.

[tser]

3.2GB per layer makes 6,4GB of total effective storage per disc.

The Amped 3 disc Contains  7,538,376,704 Bytes of Raw data. So Xbox 360 disc can be bigger
However a dual layer DVD+R disc  can hold about 8.5 GB of data. Still, i think we can just store the data in the firs "toc" area.

On a side note.. I just followed today the anandtec guide to open up my xbox.. and it is a bit overdone... don't follow that article to open up your xbox. you can open it with 2/3 of the screw they let you remove. Leave the black screws in place. You don't need a t7 torc either

My Premium xbox contains a  0046DH Rom.

[Geremia]

i think i read that others looked at similar drive firmwares, but thought i'd post what i found anyway.

i downlaoded and looked at the firmware for the following drive "HL-DT-STDVD-ROM GDR8163B0L230BLBA   04/06/19"
it decrypted ok using the decryptor tool, and i noticed that the first 95 bytes in the resultant file were the same as the first 95 bytes of the xbox360 firmwares we have been looking at. many other bits are also quite similar.

I compared 3 MN103 firmwares with different xor masks and different bit swapping order:

- the initial 0x1C bytes are the same without xoring or bitswapping
- after xoring (each with own xor mask) and bitswapping (with loser code), in the 3 firmware the ASCII area have single byte value correct, but bytes are swapped, for example pioneer have OPINREE DDV-112 NPAAMX N0_137S3FPATI.O10S7E20  0PATI.O..01.7 and LG 4241N have -LHDS-TTDVD-MOR poCygirhH ticathL,it2.d0 20A llrhgitr seresv.de

So, as my though:

- seems no phisical level data or address pin (at least firts address line pins) swapping, otherwise first 1C bytes would not be the same for different MN103 chip with different pinout and pin numbers, considering also that ascii area have different byte swapping scheme in each firmware
- could be not , because fisrt 1C bytes have no sens (as far as i read from poster that desassemble it, but...have you also tried to disassemble not xored? hope yes)

[MacDennis]

Questions about the MN103. Does this chip act as both main DVD controller and as the main CPU? Does it also handle the ATA / SATA interface directly?

Could it contain a (custom) boot rom or would it be a better quess that it starts executing directly from the flash at a certain reset vector / offset? Is it known which reset vector similair normal DVD-ROM drives use?

How much RAM do you guess think the MN103 has? It needs at least some because the firmware has to be descambled first and then executed right? It would probably do this in small code chunks.