hacking DVD firmware ?

[haute]

Hi, darkfly you can post the dvd firmware´s Mod?
How you have solder the socket PLCC to flash chip?
or any scheme of the circuit.
i´d like to make it too.
I think it is near, the next step is the checksum of the fimrware and test some mod firmwares...

thx, sorry for my english

[MacDennis]

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,

All three points are actually FACTS now.   

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...

Nice to see someone using common sense.  Yes your points are very valid.

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.

http://www.xboxhacker.net/index.php?option=com_content&task=view&id=101&Itemid=26
Short answer: yes xbox1 boots have been logged. A tool has been written to decode the raw logs to a human friendly format. AES is not used at all in xbox1 mode.

Reminder for the new people (not you Geremia), this is a technical discussion forum / thread. Please refrain from posting wild quesses or wild speculation. It hinders overall flow and progress.

[anita999]

*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 ?

hey hey, in the begining I thought this approach is not a good idea. But after thinking it twice, I thoguht it might be a good approach, too.
In the authentication process, there is a flag inside the firmware which keep tracking the authentication status. This flag will be reset when the eject was pushed.
And actually the eject handling is by a external interrupt routing. For an 8051 core, it's very easy to locate which interrupt was used for the eject.
all the necessary routines can be found via the eject handling routine.
what we need to do is

1.keep the drive not resetting the authentication flag while eject/reload new disk. this will require a firmware modification.
2.keep the system from not awaring the disk reloading. this will require a firmware modification to reaponse a "busy" status, and a hardware modification to skip the tray out/tray in signal from being sent to 360( I am not sure for this one, becuase someone claimed that they can hot swap the originals with the backup disk. if they can do it without intercepting the tray out/tray in signal, then this hardware modification is not necessary.)

but frankly speaking, I still prefer to relocate the control block address, which might be a more quicker/easier way to do.

[jumba]

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)

Billiant observation!
 
No! there are no comms routines in the f/w.

I have developed an ice monitor to work on a mt1358e cpu. It would not take much work to adapt it to mt 1359se. All that would need to be married to 943 f/w and some extra h/w to have a working ice. As the 360 is not slated for release for months, has anyone a dead rom to donate will pay for the shipping.
 

[Tiros]

I have developed an ice monitor to work on a mt1358e cpu.

Can you post the source?

[jumba]

I have developed an ice monitor to work on a mt1358e cpu.

Can you post the source?

Could do that! it's a bit long for a post don't know how attach a zip file to a post; don't have anyone who will host this file. Lastly one needs to modify the cct board by adding an rs 232c interface then replacing the flash with a socket with a view of replacing the flash with a romulator. Thats why I asked for a donation, its too complicated for a novice to attempt. If someone can get me a cct board by hook or cook will glagly develop a unit and publish a how to!
 

[Gael360]

( I am not sure for this one, becuase someone claimed that they can hot swap the originals with the backup disk. if they can do it without intercepting the tray out/tray in signal, then this hardware modification is not necessary.)

Maybe you speak about these threads :
http://gueux-forum.net/index.php?showtopic=88355&hl=
http://gueux-forum.net/index.php?showtopic=89870&hl=
What we did is make a dump of the original of PGR3, modify some language entry and video, then burn the modified ISO. After we load the original in the drive, stop the game by going back the dash board, and hotswap the original by the burned DVD, but we didn't open the tray.

The disc never stop spinning but after few minutes, the laser power shutdown.
We found 2 different ways to do the hotswap : quickly without waiting the laser to shutdown, we stop the disc rotation and change it, but we must be really fast, otherwise the drive produce a read error event. The second method is to wait for the laser to shutdown. This this we can take the time we wand to replace the DVD, but we can't stop the motor spinning otherwise the xbox ... I don't remember what the xbox do, I think it reboot but I have to confirm with sliders58 (the guy who make the hotswap).

BTW, we always need to hotswap with the SAME game than the original. If we try with another game, the xbox fail with a read error.

[MacDennis]

Tiros,

You wrote in this thread that you made a 'flash emulator':

Hardware, will work with no worries for 8051 or MN103.

Could you describe this setup for us? Which hardware is involved? How are you using it with a pc?
I'm sure many people would like to build the same thing to experiment. I certainly want to build the same thing eventually but
need some pointers on where to start, which also saves research time.

It might be a good idea to get a Samsung 616T. I know you have a substantial time investment in Phillips, but the 360 drive is Sammy.
I am working on the 605FW for SammyX1 (in a flashed 616T). It seems like there are portions between it and the 360 that are VERY similar
You should also think about what assembler to use, make sure that your disassemlber is comapatible with the assembler! I gave up on IDA,
and I can now assemble my disassembly, to get the same bin!

I agree that the Samsung is still our best target.

Some questions:
- Which disassembler are you currently using?
- Which assembler are you using?
- What's the problem with IDA? Code can be disassembled at 0x000, looks valid to me. Weird thing is, it doesn't disassemble the whole file, only
a really small part. But DIS8051 doesn't seem to have a problem with it?! I quickly looked at xbox1 Samsung firmware.
Anyone else happen to know how IDA must be used to disassembly a xbox1 samsung firmware? Any IDA experts? I prefer IDA.
- Did you find any interesting routines and/or handlers yet in the Samsung FW? If so, could you provide some details?

If anyone else discovered interesting facts about the Samsung firmware, please share! Doing so prevents us doing the same work. 

*EDIT*
Ok, IDA can be used after all. It doesn't disassemble all code automatically. Simply press 'C' at code which you want to disassemble. This is probably due to bank switching. Learning as we go ..

[anita999]

One more possible question/problem:
The layer break point of original disk is supposed to be hard coded inside the firmware. If we patch the firmware to look for another location for the control block, but the layer break point of DVDRs won't be the same as the original DVD9. This means that the layer break point must be modified, too. But after these modification, we might loss the capability of reading originals. But according to Gael, you can keep on playing the game as long as you want when you hot swap to a backup. This violate the hard coded layerbreak point theory. I asked Gael360 to confirm this issue. maybe anyone who were able to test this hot swap trick can try to play the game till the whole game finish. And please make sure the original's data exceed the layer break point. I hope the drive's firmare can have some sort of "auto layer break point adjustment", but this sounds too good to be true. Anyway, we need the results of hot swap experiments to identify this. Or maybe with further REs we can check it directly from the firmware.

[TheSpecialist]

One more possible question/problem:
The layer break point of original disk is supposed to be hard coded inside the firmware. If we patch the firmware to look for another location for the control block, but the layer break point of DVDRs won't be the same as the original DVD9. This means that the layer break point must be modified, too. But after these modification, we might loss the capability of reading originals. But according to Gael, you can keep on playing the game as long as you want when you hot swap to a backup. This violate the hard coded layerbreak point theory. I asked Gael360 to confirm this issue. maybe anyone who were able to test this hot swap trick can try to play the game till the whole game finish. And please make sure the original's data exceed the layer break point. I hope the drive's firmare can have some sort of "auto layer break point adjustment", but this sounds too good to be true. Anyway, we need the results of hot swap experiments to identify this. Or maybe with further REs we can check it directly from the firmware.

Starting sector Layer 0 and Layer break point are NOT hard coded in the firmware. Drive reads them from the control data block. For example, for xbox 1 ->

0: 06 64 00 00 D1 0F 31 10 - 00 06 06 00 00 F9 F9 FF
16: 00 20 33 AF 00 00 00 00 - 00 00 00 00 00 00 00 00
32: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

Start sector = PSN 60600, layer breakpoint = 2033AF (= end sector layer 0). First sector Layer 1 = F9F9FF (which is also the complement of 60600, so seems a bit unnecessary to save this to the control data block, dont know why M$ did this)

Only thing that is hard coded into the FW is start sector for 'normal' DVD's -> PSN 30000

[TheSpecialist]

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

I've found out why XBOX 1 discs don't work after swapping the DVD-drive. All communication is unencrypted for XBOX 1 except for 1 step: the drive starts with a 'Mode select' and 'Mode Sense' Page Code 3B (and uses encryption here). In short, communication for both xbox 360 and xbox 1 is:

1. Mode select/Mode Sense 3B
2. Mode sense 3E
3. Read DVD struct
4. Mode sense/Mode Select 3E session (challenge/response 'session')
5. Read game

As you can see, only difference from the original xbox is that this first step has been added.

Now for XBOX 360 games,  step 1,2,3 and 4 are encrypted. For original XBOX games only step 1 uses encryption. This step is done to make sure that the drive has the correct key. That's why you can't swap drives and load an original xbox (or 360) game. I haven't had much time yet to look into this 'page code 3B' step. I assumed that the xbox would send a random data block to the drive, so that the drive could encrypt it with its key, send it back so that the xbox could check if it was encrypted with the right key. HOWEVER, it seems that the drive DECRYPTS data in that very first mode select data block it receives from the xbox and then encrypts some parts and send it back... So, this seems a bit weird to me, I will look into this

About encryption: only a part of the packets are encrypted. For the page code 3B this is $20 bytes, for pagecode 3E this is $10 bytes and for read DVD struct this is $64e bytes.

[Tiros]

Tiros,
You wrote in this thread that you made a 'flash emulator':
Could you describe this setup for us? Which hardware is involved? How are you using it with a pc?
I'm sure many people would like to build the same thing to experiment. I certainly want to build the same thing eventually but
need some pointers on where to start, which also saves research time.

Well here is one for less than $100
http://www.futurlec.com/EPROMEmulator.shtml
I use something called a "Promjet", it just has some extra features. Google for eprom emulator, prom emulator, etc.
Basically you just connect it up instead of the rom, then you can DL into it whatever you want. Since it replaces the rom, you can use it in any drive, for any CPU. It connect's to my laptop parallel port for uploading and downloading rom images.

I agree that the Samsung is still our best target.

Some questions:
- Which disassembler are you currently using?
- Which assembler are you using?
- What's the problem with IDA? Code can be disassembled at 0x000, looks valid to me. Weird thing is, it doesn't disassemble the whole file, only
a really small part. But DIS8051 doesn't seem to have a problem with it?! I quickly looked at xbox1 Samsung firmware.
Anyone else happen to know how IDA must be used to disassembly a xbox1 samsung firmware? Any IDA experts? I prefer IDA.
- Did you find any interesting routines and/or handlers yet in the Samsung FW? If so, could you provide some details?

If anyone else discovered interesting facts about the Samsung firmware, please share! Doing so prevents us doing the same work. 

1)Dis8051
http://bit.kuas.edu.tw/~8051/
2)Asem51 by W.W. Hienz
http://plit.de/asem-51/
I split the bin into 64K banks before disassembly. The resultant output can be compiled by asem51 to produce the same bin for that bank. You can write/cut/copy your own code, assemble to Intel hex, and patch/overwrite portions of the rom. Beings I had to make connections for all addr/data I connect up LA to those points also. That way I can break the LA on any fragment of code I want. If/when I get a 360, I will just move the wires to it's rom.
I will be providing more info soon on how the Sammy works. Still trying to get the big picture on it. Seems like it IS using memory mapped I/O even though another here said this is not the case. Anybody with info on $8000, $C000, $4000 I/O or DRAM management areas let us know. I have some ideas, but I wont post until I KNOW.

BTW:
Just because you see an XRL against an CDB opcode and it's in large switch statement, don't think that that is the whole function or that that code will even exec.. There are multiple places the Opcodes are tested, and many branches are NOT taken, even though it looks like they should be. Maybe later I can provide specific examples, time is running short for me today.

[jumba]

Could you describe this setup for us? Which hardware is involved? How are you using it with a pc?
I'm sure many people would like to build the same thing to experiment. I certainly want to build the same thing eventually but
need some pointers on where to start, which also saves research time.

Well here is one for less than $100
http://www.futurlec.com/EPROMEmulator.shtml

The romulator comes out std dip package there is a special adpapter that translates plcc male to dip female thats farily expensive. Mine cost few hundred dollars a number of years ago.

[Tiros]

The romulator comes out std dip package there is a special adpapter that translates plcc male to dip female thats farily expensive. Mine cost few hundred dollars a number of years ago.

Just take a 32 pin DIP wire wrap socket, wire wrap 32 wires onto each leg leaving 2 or 3 inch tail, solder each wire to correct prom chip pins. First connect CS or OE to VCC on existing chip to disable it. More specifically the OE signal trace leading to existing rom needs to be cut, and the OE pin strapped to VCC. Connect other side of the cut trace to the romulator OE. You have to make those connections anyway and soldering wire wrap wire onto prom legs is not to difficult. Then plug romulator into the Dip socket. You could also use this same method to use a regular DIP flash as well, if you have a DIP programmer. Just plug a dip rom into the wire wrap socket. That's also a good way to check the socket wiring. Maybe some can experiment that way too.
If this is not specific enough, just ask and I will provide more detail.

Also you mentioned you have ICE for romulator use that you developed......MT1358 you said, so you know I/O map and your Ice is bank switch aware?
I think we "novices" can handle it
Please provide additional information.

[djhuevo]

this thread is geting very large and hard to review (wiki plz  )

I was playing with a GDR-8163B coz is the closest to an 8050L, and I can see:

we must discard the 0x4F80-0x4FFF range, coz it is used in the non-XBOX GDR-8163B (also can be read with READ BUFFER), maybe is something to do with CSS.

any facts about 0x4000-0x4003 and 0x4F00-0x4F0F yet?


I have succefully dumped the 0x40000000 area with the HITACHI debug command pointed by DaveX.

the content seem to be valid MN103 code at 40010000 area (and some valid tables starting from 0x40017920), the 0x40000000 is also mapped to 0x40020000, what do to thing that the embeded rom is 128KB.

Question: Is the reset vector of MN103S94 at 0x40000000 as has been speculated?

as 0x40000000-0x40010000 is filled of 0xff, is possible that as 0xff is an mn103 invalid instruction this area is used has delay until all the peripherials get ready?

a little offtopic:
anybody know where I can find info about DVD video disc structure, PSNs, etc?

[MacDennis]

First of all, great work! 

I was playing with a GDR-8163B coz is the closest to an 8050L, and I can see:
we must discard the 0x4F80-0x4FFF range, coz it is used in the non-XBOX GDR-8163B (also can be read with READ BUFFER), maybe is something to do with CSS.

Good point! Yes, each DVD-ROM is also a dvd player. Each dvd player contains a manufacturer player key which could be stored in the 0x4F80-0x4FFF range.

any facts about 0x4000-0x4003 and 0x4F00-0x4F0F yet?

Yes! AES key is at 0x4F00. The following was mentioned by 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. 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."

I have succefully dumped the 0x40000000 area with the HITACHI debug command pointed by DaveX here is the dump:

the content seem to be valid MN103 code at 40010000 area (and some valid tables starting from 0x40017920), the 0x40000000 is also mapped to 0x40020000, what do to thing that the embeded rom is 128KB.

Very nice! I'm sure the people with the mn103 knowledge will have fun with this dump. Any chance you could share your tool which can make the dump?

anybody know where I can find info about DVD video disc structure, PSNs, etc?

http://www.le-hacker.org/dvd.html
http://www.ecma-international.org/publications/files/ECMA-TR/TR-071.pdf

[anita999]

Starting sector Layer 0 and Layer break point are NOT hard coded in the firmware. Drive reads them from the control data block. For example, for xbox 1 ->

0: 06 64 00 00 D1 0F 31 10 - 00 06 06 00 00 F9 F9 FF
16: 00 20 33 AF 00 00 00 00 - 00 00 00 00 00 00 00 00
32: 00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

Start sector = PSN 60600, layer breakpoint = 2033AF (= end sector layer 0). First sector Layer 1 = F9F9FF (which is also the complement of 60600, so seems a bit unnecessary to save this to the control data block, dont know why M$ did this)

Only thing that is hard coded into the FW is start sector for 'normal' DVD's -> PSN 30000

Great. So we may modify this portion to let the drive pick up the correct layer break point. So far we know that the challenge/response tatle is hashed/decrypted. How about this portion, is it also hashed?

[TheSpecialist]

Seems that the $10 bytes that get encrypted in the mode select/sense 3E session (="challenge response session")  are:

1. partition nr.
2. IsControlBlockCorrect byte
3. Authenticated byte
4. DiscCategory
5. This byte always set to $3

6. Challenge ID

7. Challenge 1st byte
8. Challenge 2nd byte
9. Challenge 3rd byte
10. Challenge 4th byte

11. Response 1st byte
12. Response 2nd byte
13. Response 3rd byte
14. Response 4th byte

15. This byte always set to 0
16. This byte always set to 0

Note that I'm not 100% sure of this yet, but it surely looks like it That byte that's set to 3 and the bytes that are set to 0, I got from the FW. I took a look at a log someone sent me (for xbox 1 game in a 360, so above info was unencrypted) and based on that log it looks pretty much that above info is correct (but I'll have to verify it with the FW RE-ing results).

In the Hitachi, depending on "btst 0x20, (0xABF)" it's either going to encrypt these 16 bytes or send them unencrypted (so that specific bit probably indicates whether it's a 360 game or a xbox 1 game).

[TheSpecialist]

Great. So we may modify this portion to let the drive pick up the correct layer break point. So far we know that the challenge/response tatle is hashed/decrypted. How about this portion, is it also hashed?

No, this info is unencrypted (start PSN layer 0, end PSN layer 0, start PSN layer 1). The bytes after this info get encrypted.

[MacDennis]

One more possible question/problem:
The layer break point of original disk is supposed to be hard coded inside the firmware. If we patch the firmware to look for another location for the control block, but the layer break point of DVDRs won't be the same as the original DVD9. This means that the layer break point must be modified, too.

Can you explain why the layer break point will change if we move the control block sector? Are you thinking of adding a new sector or replacing an existing sector?
Let's make a full raw dump (around 7 gig). Then overwrite the last sector with control block data. Write the new full raw dump to a DVD+R DL disc. Patch the firmware to look in this sector. I always assumed (looking at the unlocker output posted here) that the layer breakpoint was the same for each x360 disc.

It's known in advance were the layer breakpoint will be when discs are pressed. Otherwise this information couldn't be present in the control block. The question is, can we or can't we control the position of the layer breakpoint when writing a raw dump to a DVD+R DL disc. Can someone clarify?

*EDIT*
Gear seems to be able to support custom layer breakpoints ..
http://www.gearsoftware.com/support/documentation/dvdvideobreakpoint.cfm
GEAR PRO Mastering Edition 7.0
ROM, Data Storage, System Backup: Complete control of DVD-9 layer break setting

*EDIT2*
A forum user called cdmania told me that the free program called imgburn also allows you to set a custom layer breakpoint.
http://www.imgburn.com/
Look in Tools > Settings > Write