hacking DVD firmware ?

[carranzafp]

I have flashed the firmware of my drive, but the only thing that I changed was the key region which I blanked out with all FF. Obviously the drive did not work after that. Do you have any areas you want me to attempt to modify which would affect the hash, I wouldn't think the key area would be part of the signature due to its random nature.

What do you mean with not work.  Your drive still eject/close the tray? or have lost all functionality?

if have lost all functionality maybe was the checksum, if still works so the key was not part of the cheksum

Why not try to swap drives from two 360's (changing only the 16 bytes between them) and see if they recognize the drives. That will probe that the key is not part of the checksum

[TheSpecialist]

I have flashed the firmware of my drive, but the only thing that I changed was the key region which I blanked out with all FF. Obviously the drive did not work after that. Do you have any areas you want me to attempt to modify which would affect the hash, I wouldn't think the key area would be part of the signature due to its random nature.

What model and FW version ? If you're using a Hitachi, I could give you some code adresses you could NOP, drive should still work then

[darkfly]

Its the Toshiba / Sammy 943 (MS25), the same one the dump came from, I just mounted a PLCC socket on the back of my drive and burn the chip with programmer and swap it out.

[TheSpecialist]

Its the Toshiba / Sammy 943 (MS25), the same one the dump came from, I just mounted a PLCC socket on the back of my drive and burn the chip with programmer and swap it out.

Nice
You could try modding the A3 handler (send key), which probably is not used. byte A570 in your firmware is E1 for example. try setting it to some other value, flash it and see if games still boot. If so, we finally know for sure that the code is modifiable

[Tiros]

Just to speculate:
OK maybe you guys are saying that you can't change any byte or drive will fail it's internal checksum test. Easy to patch that, if true. But what if the 16 byte area is calculated using both the drive firmware checksum and the "secret" keys. If you patch the drive firmware, you would need to regenerate a new "marriage" to the "alien" hardware, requiring a new key set. Someone should check right away that a trivial code change is even possible, without requiring new key.

Care must be taken to find out if the code change causes the internal checksum to fail, if there is one, or if the 360 just wont talk to it anymore.

[TheSpecialist]

Just to speculate:
OK maybe you guys are saying that you can't change any byte or drive will fail it's internal checksum test. Easy to patch that, if true. But what if the 16 byte area is calculated using both the drive firmware checksum and the "secret" keys. If you patch the drive firmware, you would need to regenerate a new "marriage" to the "alien" hardware, requiring a new key set. Someone should check right away that a trivial code change is even possible, without requiring new key.

Care must be taken to find out if the code change causes the internal checksum to fail, if there is one, or if the 360 just wont talk to it anymore.

True. That's why we need someone like darkfly to test it. I don't think you even need to modify the checksum. It could very well be possible that this checksum routine is not even part of the code that the FW 'normally' executes, but only in 'fail mode' for example. Darkfly can easily do some testing with his nicely fabricated piece of hardware

[Geremia]

Encryption is used only in x360 mode. And encryption seems to be only used in the following commands / opcodes:

Well, if you swap xbox360 drive, xbox1 game disks are not unlocked and only the dvdvideo part is shown, are you sure that no encryption is involved for xbox1 disk into 360 drive? Does anyone looked at sniffed data between 360 drive and xbox1 disk?

[j005u]

Just to speculate:
OK maybe you guys are saying that you can't change any byte or drive will fail it's internal checksum test. Easy to patch that, if true. But what if the 16 byte area is calculated using both the drive firmware checksum and the "secret" keys. If you patch the drive firmware, you would need to regenerate a new "marriage" to the "alien" hardware, requiring a new key set. Someone should check right away that a trivial code change is even possible, without requiring new key.

Care must be taken to find out if the code change causes the internal checksum to fail, if there is one, or if the 360 just wont talk to it anymore.

a thought just occurred here:
the secret key which is used for the encryption cannot be signed/checksummed. if it were then diffrent firmwares would also have diffrent checksums thus more then one area that is unique per drive.
so that means that the whole firmware can't have a checksum.
tho certain parts still could.

correct? or is my understanding of checksums that much off?

[Tiros]

a thought just occurred here:
the secret key which is used for the encryption cannot be signed/checksummed. if it were then diffrent firmwares would also have diffrent checksums thus more then one area that is unique per drive.
so that means that the whole firmware can't have a checksum.
tho certain parts still could.

correct? or is my understanding of checksums that much off?

The signature and or checksum itself is not included in the calculation, it is the RESULT of it. The worry is that a change to the firmware could require a change to those "keys" as well.

[jumba]

Just to speculate:
OK maybe you guys are saying that you can't change any byte or drive will fail it's internal checksum test. Easy to patch that, if true. But what if the 16 byte area is calculated using both the drive firmware checksum and the "secret" keys. If you patch the drive firmware, you would need to regenerate a new "marriage" to the "alien" hardware, requiring a new key set. Someone should check right away that a trivial code change is even possible, without requiring new key.

Care must be taken to find out if the code change causes the internal checksum to fail, if there is one, or if the 360 just wont talk to it anymore.

a thought just occurred here:
the secret key which is used for the encryption cannot be signed/checksummed. if it were then diffrent firmwares would also have diffrent checksums thus more then one area that is unique per drive.
so that means that the whole firmware can't have a checksum.
tho certain parts still could.

correct? or is my understanding of checksums that much off?

Its fairly simple to test this if the 2nd copy of the f/w is posted then the chksum can be tested. As the key has 16 bytes there are keys that will have neutral effect on chksum then this is not a problem. All one has to do is to find the chksum routine and doctor it. That is just to load the expected chksum and not calculate it. My feeling is still that all the drives come to the M$ factory in a virgin state It must be simple proceedure to have the console and rom to be married together.

[TheSpecialist]

Encryption is used only in x360 mode. And encryption seems to be only used in the following commands / opcodes:

Well, if you swap xbox360 drive, xbox1 game disks are not unlocked and only the dvdvideo part is shown, are you sure that no encryption is involved for xbox1 disk into 360 drive? Does anyone looked at sniffed data between 360 drive and xbox1 disk?

What exactly do you mean ? Did you find a way to get the 360 drive working in windows ?

[TheSpecialist]

About the checksum routine -> yes there is one BUT it is currently unknown what it used for .. Let's just wait for Darkfly experiments, they should reveal some interesting information

[MacDennis]

I have flashed the firmware of my drive, but the only thing that I changed was the key region which I blanked out with all FF. Obviously the drive did not work after that. Do you have any areas you want me to attempt to modify which would affect the hash, I wouldn't think the key area would be part of the signature due to its random nature.

If I had the same setup (flash in socket) then I would get the drive first back in working order and then try the following:
- Change one *bit* at location 0x4019, check if the drive works, return to normal working condition
- Change one *bit* at location 0x401A, check if the drive works, return to normal working condition
- Change one *bit* at location 0x4029, check if the drive works, return to normal working condition
- Change one *bit* at location 0x402A, check if the drive works, return to normal working condition

They key is at 0x401A - 0x0429, I know. But I want to check if the regions next to the key are part of a checksum area.
Note that the LG firmware contains a checksum routine, the region with the key is not part of it.

IF the checksum is part of the key (which I seriously doubt) then the console needs to know the checksum too. In that case the firmware contains a special handler which calculates the checksum and returns it to the console, which I also seriously doubt. Tell me, how can the firmware extract a checksum from an AES key? If this key is completely different between two drives which have (besides the key) exactly the same firmware?! And remember, the console does not send any special identification about itself to the drive. The console is the master so to speak. Logging the firmware access will tell you which areas are checksumed. There's probably a checksum somewhere, like in the LG. But I don't believe it's exacted from the key.

[TheSpecialist]

Groepaz plugin seems to be ok now (and i love it ! ) and I've just started to look into the Hitachi/LG code. First thing I just noticed is that 'read dvd structure' will only encrypt data if the control byte in the received CDB packet is set to 'C0' ($C0 indicates that the xbox wants the control data block from the leadout). More proof to support the theory that only authentication related data gets encrypted....

[fghjj]

There's more than enough free space in the FW's for some code 'extension' by the way

Great! That opens the door for some tinkering.

About the firmware checksumming thing... I didn't want to change the subject of this thread too much in that direction... as the simple NOOP test described earlier by TheSpecialist will prove whether it's done or not. In case it IS being done, I can see only 3 ways:
1- "bootloader" somewhere hidden in a chip checks firmware - unlikely
2- firmware checks itself - only for integrity purposes, like CRC32, not for security (cos we can easily skip the check)
3- x360 dumps the entire firmware to RAM and validates it - unlikely (will slow up boot process?) - will be harder to emulate though

About hotswapping disc: you can't eject the tray, since kernel will reset the 'authentication' bit at an eject. So, you'd have to open your drive, stop disc spinning once the control data block has been read, just before it's going to read the filesystem. I think this is pretty much impossible So, basically, forget about any PS2-like disc swapping trick

You're probably right... but I was thinking... it's the _firmware_ that informs the kernel that the tray is ejected, right? What would the kernel do if the DVD was to say.. just not responding for a while (or responding bogus "please wait, i'm busy" messages)?

pseudo-code:

Code:

//Don't bother with authentication routines at all
HookedReadSector(x) {
static bool FirstTime = TRUE;
if (FirstTime && x == LBA129824) { //first sector of XDVDFS
SpinDown();
EjectTray();
SleepSeconds(10);
CloseTray();
SpinUp();
FirstTime = FALSE;
}
RealReadSector(x);
}

Has anybody inspected the DVD controller board and found leftover traces of a "busy"-LED? Maybe this can be used as a cheap way to signal debug info.

[robinsod]

On the TS-H943 there appears to be a debug serial port (every embedded device I've ever worked on has one), have a look at the underside of PCB between the EliteMT RAM chip and the edge of the PCB. There are four larger than average vias in the PCB on a 0.1" pitch, the black silk screen says TXD, RXD for the 2 inner vias (cant photograph black on green very well the outer two appear to be gnd and +V. Very convenient!

I haven't found any reference to it in the firmware, but I havent fully analysed the ISR yet. Has anyone else spotted a UART in the FW? It's possible that production builds of the FW 'compile out' the UART driver based on some build config flags (in which case we're stuffed)

[TheSpecialist]

In the Hitachi/LG FW, there are 5 calls made to the encryptor (which Takires pointed out). They are:
1. Read Dvd structure physical
2. Mode sense PC = 3B (3B is probably used to check to see if the drive has the correct key)
3. Mode sense PC = 3E (our authentication related mode sense)
4. Mode select using 3B
5. Mode select using 3E

Note that this routine either decrypts or encrypts, depending on the parameters it's called with (it encrypts in the first 3 cases and decrypts in 'mode select', which is pretty logical of course )

So, our little theory about encryption was correct: only these authentication related commands (well, the modeSense/3B is not really disc-authentication related, more 'drive-authentication' related) are using encryption (and only when certain conditions are met, all these routines can operate without encryption)  ...

BTW, I am also happy to be able to report that the encryption routine uses the drive specific 16 bytes at 4F00, so also that theory is now proven to be correct

[darkfly]

Some preliminary results... I left my PLCC extractor in my toolbox at work, I only have a few spares so I dont want to damage any pins trying to get them out with makeshift tools - I already bent the leads  on one pretty bad so I will confirm the rest of this tomorrow provided I have time.

You could try modding the A3 handler (send key), which probably is not used. byte A570 in your firmware is E1 for example. try setting it to some other value, flash it and see if games still boot. If so, we finally know for sure that the code is modifiable

One blank flash burnt with original (non modified) firmware, system operates as normal.

...

Edit: Removed original post - test invalidated due to human error DOH 

[TheSpecialist]

pseudo-code:

Code:

//Don't bother with authentication routines at all
HookedReadSector(x) {
static bool FirstTime = TRUE;
if (FirstTime && x == LBA129824) { //first sector of XDVDFS
SpinDown();
EjectTray();
SleepSeconds(10);
CloseTray();
SpinUp();
FirstTime = FALSE;
}
RealReadSector(x);
}

Yeah, I guess this should work However, I think that it's not a perfect option, since (possible) XBE checks will fail and you'd still need other modifcations. Besides, I think rerouting the FW to look on another sector for the 'control data block' is easier to do than to mod it as you propose. But if everthing else will fail, this might be worth trying sometime

*EDIT* Hmm... somehow I do like this idea ... Would be nice to see if this really would work, in theory it should. However, to do things like spinning up/down the drive, you'll need some good understanding of the hardware in the drive.... Won't be too hard too acquire this knowlegde, but I would need some time .. A project like this has not my priority, but maybe in the future this is worth trying ... Or maybe someone else wants to try something like this ?

[Geremia]

Encryption is used only in x360 mode. And encryption seems to be only used in the following commands / opcodes:

Well, if you swap xbox360 drive, xbox1 game disks are not unlocked and only the dvdvideo part is shown, are you sure that no encryption is involved for xbox1 disk into 360 drive? Does anyone looked at sniffed data between 360 drive and xbox1 disk?

What exactly do you mean ? Did you find a way to get the 360 drive working in windows ?

No, i'ven't an xbox360 dvdrom working under windows.
I'm refering to tests made by Evestu http://www.xboxhacker.net/forums/index.php?topic=76.msg1899#msg1899
He taked dvdrom from another xbox360, and the result was that:

DVD-video = play OK
xbox360 game = video showing to put game on xbox360 console
xbox1 game = video showing to put game into xbox console

It makes me think:
- there is no overall dvdrom device verification/marriage, otherwise dvdvideo would not be played
- xbox1 and 360 games show the video, so unlock process failed and only the normal video part is accessible
- assuming a 128bit AES key only difference between firmwares, unlock process failed because both uses AES key, for sure in 360 disks (the little bird have logs of crypted data), unknown for xbox1 disks (does someone logged it?). Maybe logging xbox1 disks into 360 and comparing with xbox1 (same)disk in xbox1 would help a lot in understanding the crypto process. We know the key (simmetric), we know the (unencrypted) data exchange between xbox1 console and xbox1 disk...if AES is used also for xbox1 game, if it's used the same way for 360disks, it would be hopely not so hard to know how and where encryption is used.


I've no ability to do all this stuff, i'm only trying to help somehow.