hacking DVD firmware ?

[svenhag]

Additionaly if the DVD firmware is signed in some way, (and I'll bet it is since we know each drive has different FW), with the secret keys on die, there is little hope of modification. IE: if you need to re-encrypt ANY part (maybe the checksum data?) of the drive rom with the secret keys you are screwed. We know the drives are "married" to the motherboard. Would one really think this marriage occured without the use of the "secret" keys and the firmware checksum?

This is actually what I think should be top priority on the 360 now. What I would like to know is what happens if you switch drive (to one of same model) and what happens if you modify the firmware on a drive. A log of the communication between the 360 and dvd drive is probably necessary to help understand how it detects a swapped drive or modified firmware.

If the firmware is signed then I guess we can give up hope on the 360. Although it would still be nice to modify the xbox1 dvd firmware in order to be able play burned games.

[TheSpecialist]

Additionaly if the DVD firmware is signed in some way, (and I'll bet it is since we know each drive has different FW), with the secret keys on die, there is little hope of modification. IE: if you need to re-encrypt ANY part (maybe the checksum data?) of the drive rom with the secret keys you are screwed. We know the drives are "married" to the motherboard. Would one really think this marriage occured without the use of the "secret" keys and the firmware checksum?

This is actually what I think should be top priority on the 360 now. What I would like to know is what happens if you switch drive (to one of same model) and what happens if you modify the firmware on a drive. A log of the communication between the 360 and dvd drive is probably necessary to help understand how it detects a swapped drive or modified firmware.

If the firmware is signed then I guess we can give up hope on the 360. Although it would still be nice to modify the xbox1 dvd firmware in order to be able play burned games.

I agree, if the FW is signed, that would *probably* be the end of a FW mod. It would still depend on how the signing is done. For example, if the "secret key" and "checksum" are sent to the XBOX to check, then it's easy to mod that. As long as the CPU in the drive is not doing the checks via some internal hardware routines, then there would be still a possibility. 

It would be very nice if people with a flasher could try to alter some data in the FW and reflash it and/or reflash another FW for the same model drive, I agree this should be pretty much priority now.

In this case, the only "solution" will be some kind of emulation device like people have proposed before in this thread (connecting the SATA cable to some PCI card (something that *looks* like this: http://www.ioisata.com/products/proddetail.asp?ProdID=1000007 ) in a PC and let the 360 communicate with the PC instead of a DVD-ROM). All information we gather in this thread will also help in building something like that.

However, I don't agree about the fact that M$ will be able to detect FW modding. As long as they're not using the empty space at the outer ring of the disc (because they feel this way discs get damaged too soon) we have some place to hide our data on disc and can let the FW behave like it's just an original disc in the drive. And no, this is not going to be an easy job, I never said that, but It will be great fun

[Tiros]

However, I don't agree about the fact that M$ will be able to detect FW modding. As long as they're not using the empty space at the outer ring of the disc (because they feel this way discs get damaged too soon) we have some place to hide our data on disc and can let the FW behave like it's just an original disc in the drive. And no, this is not going to be an easy job, I never said that, but It will be great fun

For ONE example,
Why couldn't they just look at this outer ring, where they KNOW there shouldn't be anything, and fail if there is. The check is in the XBE and can't be patched out. Move your storage area, so do they, and now you need a library of firmware for compatiblility.
For another:
Maybe they can query the drive code space by address with a simple drive command (AKA Commodore 1541 ). I don't think I have to explain the impact of something like that

Further speculation,
More than likely the drive will use private/public key for disk control. Maybe not all communication, but some. Again, without key knowledge, the SATA bus will be difficult/impossible to sniff/mimick.

Not givin up
Just being realistic. Personally I think somebody is gonna have to etch those chips apart with acid, and use some kind of wafer probing to get at what needs to be gotten too
WAY out of my league!

[TheSpecialist]

For ONE example,
Why couldn't they just look at this outer ring, where they KNOW there shouldn't be anything, and fail if there is. The check is in the XBE and can't be patched out. Move your storage area, so do they, and now you need a library of firmware for compatiblility.
For another:
Maybe they can query the drive code space by address with a simple drive command (AKA Commodore 1541 ). I don't think I have to explain the impact of something like that

Why would this be a problem ? If for example, there's one command that checks the empty space and returns the result of that command in a register, then we can still overwrite that register value immediately after that command. And if they use 'normal' read routines, then we have to mod that routines and check the sector that's being read -> if it's in our 'hidden' section, just return '0'.

Further speculation,
More than likely the drive will use private/public key for disk control. Maybe not all communication, but some. Again, without key knowledge, the SATA bus will be difficult/impossible to sniff/mimick.
Not givin up
Just being realistic.

While I agree that we should be realistic and keep our feet on the ground and keep in mind that we might encounter some serious difficulties, I also feel that it's WAY too early to draw any conclusions yet. We'll just have to find out

[Disabled]

I read "we just modify the firmware to return this or that" that often that I start to wonder what the FW actually does for the drive and how powerfull the "processor" it works on is.
Do you techy guys here believe that the FW-Processor is actually powerfull enough to do the things like remapping every sector, reading and decoding the response (well it is actually doing this is it?) and checking if a sector is in "our secret area" and all things like this?

[TheSpecialist]

Do you techy guys here believe that the FW-Processor is actually powerfull enough to do the things like remapping every sector, reading and decoding the response (well it is actually doing this is it?) and checking if a sector is in "our secret area" and all things like this?

Don't forget the xbox1 FW is ALREADY doing remapping ! Try reading sector 20 before and after unlock, you'll get different results. That's because the drive doesn't return the 'real' sector 20, it returns data that's mapped to it. ONLY the *drive* knows what's 'really' on sector 20. The 'outside' world (the xbox or the pc) just has to deal with the data the drive is returning for reading a specific sector.

[Tiros]

Why would this be a problem ? If for example, there's one command that checks the empty space and returns the result of that command in a register, then we can still overwrite that register value immediately after that command. And if they use 'normal' read routines, then we have to mod that routines and check the sector that's being read -> if it's in our 'hidden' section, just return '0'.

Not sayin there is a command specifically for this. But they do have control over the device. So you code for one access method/check and they use another in the next disk's XEX. Maybe they put something in "your" disk area next time, and you blocked access to critical data. Maybe they can peek/poke/execute code from drive ram, like the 1541. There are hundreds of ways.
IMHO It's cat and mouse and will not work.

[Tiros]

You might be right, you might be not. At this stage it's all just speculation. We'll have to find out

Exactly,
Until there is more hardware around all we can do is speculate.
I openly encourage any speculation as to why I might be wrong.

[TheSpecialist]

Exactly,
Until there is more hardware around all we can do is speculate.
I openly encourage any speculation as to why I might be wrong.

Well, for instance, M$ left the space near the end of disc INTENTIONALLY blank because they feel that kids would damage discs way too easily if they'd use that space. If they're going to place critical data in that section, they'll have to say 'goodbye' to that idea. I don't know if they're wanting to give that up. If they do, yes, then it will become a 'cat/mouse' game. So, then, M$ is now releasing discs that are getting more easily damaged AND now they're engaging in our little cat/mouse game. I don't think that's good for them either

For the peeking of data part -> of course you might be right that the HW is capable to do this. But then, you just might be not, there's nothing we can say about that right now. Same goes for the "private/public key for disk control"..

[smo]

Ok, here's a new version of the Linux version of the unlocker. You'll need to apply the kernel patch (linux-2.6.14-mediachange.patch) to properly see the unlocked disk capacity. It just adds an IOCTL that calls saw_media_change(). You'll get an error if you don't apply the patch. However, for some reason dd won't produce nice images (maybe it has something to do with its error handling (tried with "dd conv=noerror bs=2048 skip=32 if=/dev/hdd of=disc.img")), so I'll probably need to write a proper dumper that stores the "bad sectors" in a separate file for future purposes.

But wait! There's something more. Perhaps you have heard of FUSE? FUSE stands for Filesystems in Userspace. I wrote a small FUSE driver that allows one to mount the XBOXDVDFS discs directly to the filesystem. You'll need to get FUSE from http://fuse.sourceforge.net and install it ("./configure ; make ; make install ; modprobe fuse" - remember to insert the kernel module). Then you can compile the xboxdvdfs.c driver:

Code:

# gcc -o xboxdvdfs xboxdvdfs.c -lfuse

Now, assuming you have not unlocked the DVD drive yet (which is "/dev/hdd" in this example), you run:

Code:

# ./unlocker /dev/hdd
# mkdir /mnt/xboxdvd
# ./xboxdvdfs /mnt/xboxdvd /dev/hdd
Root directory table at sector 1685288 (size 2048 bytes).
Looks like a XBOXDVDFS filesystem.
# ls -l /mnt/xboxdvd

You can also specify an image file instead of a device to xboxdvdfs (should work, but my images were broken). This stuff should be all moved to kernel space (one IOCTL for unlocking the drive) and the filesystem into a proper kernel filesystem. Sorry for the crappy source (no proper error/exit handling), but it seems to work for now and it's userspace so it shouldn't hurt your system The xboxdvdfs driver should be able to mount Xbox 360 images too, if I've understood correctly (should be the same format?).

Download here:
http://rapidshare.de/files/10211519/unlocker.0.2.tar.gz.html

[TheSpecialist]

Nice SMO

"saw_media_change()" isn't their a windows equivalent kernel routine we can call to do the same ? Would be nice if you could see the disc contents in windows explorer

[smo]

"saw_media_change()" isn't their a windows equivalent kernel routine we can call to do the same ? Would be nice if you could see the disc contents in windows explorer

Apparently Windows doesn't need the equivalent since it'll show the disc capacity properly after unlocking, if I've understood correctly? Linux has the tendency to cache the TOC until it receives a UNIT_ATTENTION sense from the drive. To see the disc contents in Explorer, you'd need a filesystem driver for Windows. And based on what I've read on them, they're really hard to write. I don't think there's an equivalent of FUSE for Windows,

[Tiros]

Well, for instance, M$ left the space near the end of disc INTENTIONALLY blank because they feel that kids would damage discs way too easily if they'd use that space. If they're going to place critical data in that section, they'll have to say 'goodbye' to that idea. I don't know if they're wanting to give that up. If they do, yes, then it will become a 'cat/mouse' game. So, then, M$ is now releasing discs that are getting more easily damaged AND now they're engaging in our little cat/mouse game. I don't think that's good for them either

For the peeking of data part -> of course you might be right that the HW is capable to do this. But then, you just might be not, there's nothing we can say about that right now. Same goes for the "private/public key for disk control"..

Using that area would be a small price to pay to shut down a hack, and that was just ONE of my ideas on how I would shut it down.
I thought that the edge was unused because they fill 'em up from the center->edge. Almost all retail disks use full capacity so what is the basis for your "scratching" speculation?
I was pretty sure I read somewhere that some of the SATA communication was encrypted, if true, why wouldn't they use thier already available secret key?

If you intend to pursue, what will be the next step? It seems pointless (WRT the 360) to further refine the xbox1 unlocker..... So what now?

[smo]

Using that area would be a small price to pay to shut down a hack, and that was just ONE of my ideas on how I would shut it down.

I know it's tempting to think they could easily shut down anything based on hacked DVD firmware, but I believe it's not that easy for them. Currently the data that is used to authenticate the disk is in fact only couple kilobytes. Weak sectors can be emulated. Games can be ripped to fit into less space without disturbing any hash checks (most games don't bother to check videos etc).

In fact, I consider mod chips to be FAR more vulnerable to "shutting down".

I was pretty sure I read somewhere that some of the SATA communication was encrypted, if true, why wouldn't they use thier already available secret key?

Could be, but I doubt it. DVD drive is meant to be a dumb device and key exchange/complex encryption seem be a too large burden for its meager microcontroller and firmware.

If you intend to pursue, what will be the next step? It seems pointless (WRT the 360) to further refine the xbox1 unlocker..... So what now?

It most definately is not pointless. In fact, a hacked Xbox1 DVD firmware forms a solid basis for extending the concept into other devices.

[Tiros]

In fact, I consider mod chips to be FAR more vulnerable to "shutting down".
Could be, but I doubt it. DVD drive is meant to be a dumb device and key exchange/complex encryption seem be a too large burden for its meager microcontroller and firmware.
It most definately is not pointless. In fact, a hacked Xbox1 DVD firmware forms a solid basis for extending the concept into other devices.

I have wondered many times why XBE's don't simply check for modified bios!  Seems trivial, maybe it isnt.
I disagree about the exchange encryption being too complex. Even an 8051 could do it, and this MPU is more powerfull. I'm not saying that ALL comms are encrypted, certainly DMA data xfers can't be encrypted in real time, but CONTROL commands EASILY could since they are rarely sent. Maybe not all, but some. Gee I wonder which ones they are?

I said pointless WRT the 360. The units are completely different. Only the general information, not specific, about X1 authentication MAY be applicable to the 360. That general information is now known sufficiently to apply to 360. If this work was being done on the actual 360 drive my opinion would be different.

So what next?

[smo]

I disagree about the exchange encryption being too complex. Even an 8051 could do it, and this MPU is more powerfull. I'm not saying that ALL comms are encrypted, certainly DMA data xfers can't be encrypted in real time, but CONTROL commands EASILY could since they are rarely sent. Maybe not all, but some. Gee I wonder which ones they are?

Even if the comms were encrypted, I doubt the controller in the DVD drive has a dedicated hardware unit for encryption (after all I think the point for choosing a reasonably standard SATA drive is cost effienciency from not buying completely custom stuff). If it's done in software, you can subvert it by hacking the firmware (since it'll know everything about the encryption).

Next up? A method for upgrading the DVD firmware, something that non-electronics-experienced people can do (since not all hackers are EEs). I believe the fimware was already descrambled?

[TheSpecialist]

I thought that the edge was unused because they fill 'em up from the center->edge. Almost all retail disks use full capacity so what is the basis for your "scratching" speculation?

No. M$ leaves only 6.4 GB on a disc to the game programmers. The rest is used by the 'security placeholders' and the empty space near the end of disc, read more: http://layouts.xbox-scene.com/main/docs/optimize.htm

If you intend to pursue, what will be the next step? It seems pointless (WRT the 360) to further refine the xbox1 unlocker..... So what now?

Well, personally I'm not even close to thinking about giving up now Yes, we might encounter serious difficulties and in the end, a 'simple' FW hack might not be possible, but I feel we have to find out and we might try something else then, like that 'emulation' device. With the things we learned by then, it will be less complex to create something like that.

However I won't be able to pursue this all on my own, hehe, we need smart people to work together on this, like we did before

About the steps to take:

1. we need logs of ATAPI commands for the 360, mainly because:
2. we need to find out if the kernel authenticates a disc on the 360 the same way as the original xbox does
3. we need to find out if data in the FW is signed by flashing modded FW or flashing different FW for the same drive version
4. we need to find out how the drive calculates the responses.
5. we need to find out what 'physical' copy protection is used -> what are these 'bad sectors', how are they done and how does the xbox drive  handle/read them.

That will get us started

[Tiros]

Next up? A method for upgrading the DVD firmware, something that non-electronics-experienced people can do (since not all hackers are EEs). I believe the fimware was already descrambled?

I couldn't agree more!
If you can't even change the firmware (and there may not be a way to if it's signed), you aren't going anywhere. Everything else is moot.
IMHO this is the most importatnt work that needs to be done.

WRT public/private key
If the motherboard has private key, and drive has public key, can they not establish secure comm link? I think the ATM machine can when it contacts the bank.

[TheSpecialist]

I couldn't agree more!
If you can't even change the firmware (and there may not be a way to if it's signed), you aren't going anywhere. Everything else is moot.
IMHO this is the most importatnt work that needs to be done.

Agreed. This is the most important step now. Hopefully someone like Geremia, who desoldered his FW can try to flash it with some modded data.

[smo]

WRT public/private key
If the motherboard has private key, and drive has public key, can they not establish secure comm link? I think the ATM machine can when it contacts the bank.

Yes, in one direction. To establish a two-way secure link, both would need to have private keys and other's public key. And RSA/PKI is usually pretty slow, so it's only used to exchange keys for a regular symmetric cipher. But the data will have to be decrypted in the DVD firmware anyways, so...