hacking DVD firmware ?

[smo]

So, it almost looks like the drive is decrypting the challenge/response table itself, which would make no sense in my opinion ... More on this later ..

Wouldn't it need to do this in order to verify that proper challenges are sent?

[TheSpecialist]

Wouldn't it need to do this in order to verify that proper challenges are sent?

It certainly looks like it But I'm going to find exactly what's happening here I always believed that it performed some algorithm to 'verify' that the challenge was correct (using some data from disc). If it's just decrypting the table, that would be a rather lame protection in my eyes

[smo]

It certainly looks like it But I'm going to find exactly what's happening here I always believed that it performed some algorithm to 'verify' that the challenge was correct (using some data from disc). If it's just decrypting the table, that would be a rather lame protection in my eyes

I guess because the key generation is sort-of-a-secret, it constitutes a shared secret between the Xbox and DVD drive. So it's like a weak two-way trust verification system.

[oz_paulb]

Anyway, like MacDennis and Anita999 are saying: someone has send me the logged data from the x360 communication, containing this read dvd structure block. If his logging was correct, then the x360 drive ENCRYPTS the data, because his log contained completely other data then you guys are showing (it didn't contain the large zero sections for example). We'll have to find out if encryption is done in the FW or in the MPU hardware.

I can confirm that the read dvd structure command contains code to encrypt data. The encryption key is taken from 90004F00, still need to figure out what kind of encryption is being used. The first 20 bytes are not encrypted.

Takires -

Can you post some more addresses from the firmware, like the address of the encryption function, and where you determined the first 20 bytes are not encrypted?

I would suspect RC4 encryption is being used, just because MS has used it a lot in the past.  But, that's really just a 'wild guess' at this point.

Thanks,

- Paulb

[chaos]

With encryption, this means that each XBox 360 console/DVD-drive pair could have a _different_ key could it not?

atm this is xbox only, not xbox360! but concerning the xbox360, maybe ... i can't remember, did anyone successfully swap the dvd-drives between two boxes yet? 

i know this is more "general talk", feel free to delete - sorry 

[oz_paulb]

I just finished working my way through a *HUGE* decryption routine, still don't know exactly how it works, but it seems to be some RC4/SHA1 routine. I'm not really into encryption, I'd have to spend quite some time on this routine to understand how it exactly works.

RC4 code is typically pretty small.  SHA-1 can be pretty huge.

Some 'standard' constant values used in SHA-1 initialization code are:

    0x67452301;
    0xEFCDAB89;
    0x98BADCFE;
    0x10325476;
    0xC3D2E1F0;

If you see these values in the code you're looking at, I'd guess it's SHA-1 code (or, both SHA-1 and RC4).

- Paulb

[Stealth]

Question for fellow IDA users.. what device name should be chosen for the 8051 dump.  Also any specific processor settings or rom/ram settings need to be changed?

[jumba]

What do you mean with 8051 dump? Do you perhaps mean XBOX1 8050 DVD-ROM firmware dump?

No, now they are saying they got MTK chipsets on new (tosh/sam) 360 drives. Since 605 (SammyXB1) was also MTK, very similar number, and 605 was 8051, figured maybe those MTK FW tools might work, and further hoped it is also 8051 processor.

My experience with 605f f/w MTKflash will not download f/w as some flag is set to defeat this proceedure. Download the f/w one could attach a sata to ide convertor and then connect to a pc ide port. I have managed to reflash a 605f drive without removing the 020. So my method possibly could be used to download the f/w!

[jumba]

Just tried the DOS mtkflash utility, not sure if I need to set some specific command line parameters but it reported unknown flash type and the dump is 65536 bytes.

Also just noticed the Mini ITX board im working with has a SST 39SF020A in a PLCC socket, I assume for the BIOS. Perhaps I could do a hot swap and use uniflash.

Yes this is the result of the download facility being disabled as in the 605f rom. As I donot have this drive, is anyone prepared to use my technique?

[jumba]

A question about the (8051) SJMP command: how does it exactly calculate the adress to jump to ?

For example, I have this code in IDA:

000191AB                 sjmp    code_9148
000191AD
Ofcourse the 9148 is not correct (because of bank switching). Now, the opcode for this instruction is 809b -> 80 = opcode for the SJMP instruction and $9b specifies the 'relative' adress. I thought the sjmp should jump to 191AD + 9b = 19248. However, it seems that the correct jump (judging by the code in the routine) should be 19148. Can someone explain this ? Thanks.

Hi yes its a relative jump.  It works by using two's complemtry arithmetic. So numbers 00h to 7Fh are added to the program counter to calculate the forward address. Numbers 80h to FFh are used to calculate backward jumps.
Here's an example

loop_back:
0001000     80 FE        sjmp   loop_back ; 0001000h

Just to clarify bank switching as the 8051 has a program limitaion of 64k to over come this one employs bank switching this done by executing code in what is called a common code area.. Here the higher address are set up; then this line is generally executed

          jmp @a+dptr         ; where dptr contains the destination address

[Takires]

Anyway, like MacDennis and Anita999 are saying: someone has send me the logged data from the x360 communication, containing this read dvd structure block. If his logging was correct, then the x360 drive ENCRYPTS the data, because his log contained completely other data then you guys are showing (it didn't contain the large zero sections for example). We'll have to find out if encryption is done in the FW or in the MPU hardware.

I can confirm that the read dvd structure command contains code to encrypt data. The encryption key is taken from 90004F00, still need to figure out what kind of encryption is being used. The first 20 bytes are not encrypted.

Takires -

Can you post some more addresses from the firmware, like the address of the encryption function, and where you determined the first 20 bytes are not encrypted?

These addresses are from the 009 firmware:

9002E137 - This is ReadDVDStructurePhysical, it is called if the format field of read dvd structure command is set to 0 (Physical)
This function sends 06 66 00 00 or 08 02 00 00 back to the host depending on the control field of the command. If 0xABF has
bit 5 set, it calls the code for the encrypted version, if it is not set it calls the code for the unencrypted version.

Unencrypted version: 9002E211 -> 2E29F
Not much to comment on this, it sends first 0x65C bytes and then additional 7 bytes back.

Encrypted version: 9002E2F7 -> 9002E33C -> 9002E366 -> 9002E387
It sends back the first 16 bytes unencrypted, encrypts the next 0x650 bytes and sends them back. It finishes with sending
back 3 bytes.

The encryption routine is at 90031083 and is called from 9002E350, 90032A08, 90032AB1, 90032AE1, 90032B0E.

[anita999]

In the TS-H943 firmware, offset 20B4, there is a string starting from 0x05, 80, 00, 32, 5b, 00, 00,00, and the DVDmodel name with firmware version. ...... This is a default response to the 360's "Inquiry" ATAPI command. ( the actual response string is 36 bytes long. I am not quite sure whether the string starts from 05, 80, or 00, 32 because the log I saw is not stable so far).

In Hitachi drive 0047DH firmware you can search the 0x5b, 00, 00,00 string and you can find similar result.

When the system starts, it will issue a "Inquiry" command first, then the drive will response this specific string. This string is not a standard response format. It's simply a 0x05, 80, 00, 32 ,5b,00,00,00 header with the model name and the firmware version. I am suspecting (hoping) that the system is only married to the drive's model and firmware version instead of using a unique key pair. If this is true then it will be much easier for our job. Unfortunately I couldn't find any Xref to this string in IDA result. And the MTK chip seems use 64K full page banking for the flash mamory space. you can see there are the same header for every 64K bank.

[Takires]

I can confirm that the read dvd structure command contains code to encrypt data. The encryption key is taken from 90004F00, still need to figure out what kind of encryption is being used. The first 20 bytes are not encrypted.

The encryption algorithm is Rijndael. Encryption key, key size and number of rounds are being set by a mode select command.

[anita999]

I can confirm that the read dvd structure command contains code to encrypt data. The encryption key is taken from 90004F00, still need to figure out what kind of encryption is being used. The first 20 bytes are not encrypted.

The encryption algorithm is Rijndael. Encryption key, key size and number of rounds are being set by a mode select command.

Takires: is it Rijndael or AES? and which routine handls this mode select command? There are two kinds of mode select in 360 to drive communication. During the boost, the 360 keep on polling the drive with mode selece and the DMA data length is 3Ah. After the disk was inserted, a new sequence of mode select command will be issued with DMA data length 2Ah. I suspect that the 3Ah one is transfering the key to the drive because each time it sends out different data. And the 2Ah one shall be challenges similar to xbox1.

[smo]

Ok, here's the first version of my MN103 disassembler (soon to be emulator). I've included a precompiled Windows binary and sources (and a Makefile) for Linux. See attached README for information.

Download here: http://rapidshare.de/files/10650090/mn103emu-0.1.tar.gz.html

[Takires]

Takires: is it Rijndael or AES? and which routine handls this mode select command? There are two kinds of mode select in 360 to drive communication. During the boost, the 360 keep on polling the drive with mode selece and the DMA data length is 3Ah. After the disk was inserted, a new sequence of mode select command will be issued with DMA data length 2Ah. I suspect that the 3Ah one is transfering the key to the drive because each time it sends out different data. And the 2Ah one shall be challenges similar to xbox1.

AES is Rijndael, the difference between these two is that AES defines 3 combinations of key size and rounds. The FW has code for 6 other combinations.

[Tiros]

Just to clarify bank switching as the 8051 has a program limitaion of 64k to over come this one employs bank switching this done by executing code in what is called a common code area.. Here the higher address are set up; then this line is generally executed
          jmp @a+dptr         ; where dptr contains the destination address

Sometimes the bank switched area is only 32k to allow for memory mapped devices to be in non bank switched space.
Wen you see movx, your pretty sure it's a memory mapped register. (unless it's ram mapped to external space)

[jumba]

Nice! Just downloaded the bin file. Disassembled using DIS8051 that created 226500 rows of assembly  Really hard to understand! I have mirrored the firmware here: http://www.darkmoon.org/GDR-3120L_0047DH.rar if the previous link doesn't work.

I also just disassembled it with 8051, but it's not correct code, the reset vector jump isn't even there. It's very good possible that it's not even 8051 (and/or encrypted/packed). Do we have any info on the MCU in the drive yet ? Manufacturer etc ? Would be really great if someone could open his drive and make a photo of the chips inside.

8051 does not have a reset vector as other processors do, at reset code is exceuted from 0000'h

[jumba]

Just to clarify bank switching as the 8051 has a program limitaion of 64k to over come this one employs bank switching this done by executing code in what is called a common code area.. Here the higher address are set up; then this line is generally executed
          jmp @a+dptr         ; where dptr contains the destination address

Sometimes the bank switched area is only 32k to allow for memory mapped devices to be in non bank switched space.
Wen you see movx, your pretty sure it's a memory mapped register. (unless it's ram mapped to external space)

There is no memory mapping for hardware in the program memory code its generally done thru' dedicated pins. The 8051 is structured differently from other micro's there is separate area for program and ext ram; 64k is allocated for each. The DVD rom hardware is structured
1. Flash eeprom contains uncompressed code and is bank switched. Some of the code is repeated in other banks and is refered to as common code.
2 the external ram is follows
a) 0000'h to 7fff'h no ram; could be area used for IDE hosting have not determined this
b) 8000'h to bfff'h is banked ext ram
c) cfff'h to ffff  no ram is reserved for SFR see SAA7817 data sheet

[TheSpecialist]

Something that I never really understood in the Philips FW:

code:0000C962                 mov     R0, #0x8B
code:0000C964                 mov     @R0, #2

I always thought that you could not do this. on www.8052.com they say:

MOV R0,#99h ;Load the address of the serial port
MOV @R0,#01h ;Send 01 to the serial port -- WRONG!!

This is not valid. Since indirect addressing always refers to Internal RAM these two instructions would write the value 01h to Internal RAM address 99h on an 8052. On an 8051 these two instructions would produce an undefined result since the 8051 only has 128 bytes of Internal RAM

So, if it produces 'undefined results', then why do i see this happening all over the place in the Philips FW ? It makes me believe that the Philips MCU has more than 128 bytes internal ram (excluding the SFR's of course). However, that would mean that the internal ram is overlapping the SFR's, since $8b in the example above is also an SFR (TL1) !?!?

I'm sure there's someone here that can explain this Thanks.