Dumping Security Sector with H-943A

[robinsod]

As noted by others, the Security Sector is located at PSN 0xFD021E which it is not possible to read with a normal DVD drive. One approach is to hack the 360’s DVD firmware such that it will copy Security Sector from DRAM to Flash as soon as possible after it has been read. The following snippet of 8051 assembler will do just that, but please note

1)   It’s not for Noobs. You must be able to program and then read back the Flash device from your TS H-943 DVD drive to be able to use this hack.

2)   It may not be complete. There appears to be no data from 0x0007 to 0x000A and TheSpecialist (hallowed be his name) observed: “BTW, I'm sure you noticed, but to make your analysis complete: &Sector[0x07] -&Sector[0x0A]  contain the unencrypted challenge.” Possibly I am too late dumping DRAM to Flash and it has been overwritten.

3)   The interrupts are disabled when the dump begins, I don’t know what state the hardware is in when this happens, possibly the laser is on and the mechanics are active. Maybe damage can result if interrupts are disabled for a long time. Who knows? Use this at your own risk!!! I monitor the WE line with a ‘scope and turn off the ‘360 ASAP after the data has been written.

4)   It’s intrusive. The ‘360 will no longer boot games. You must reflash the drive with your original firmware afterwards.

To use: overwrite the existing code at 0xc3f6, this will invoke the copy to flash function

0xc3f6:   
   mov   r6,#0eah   ; c3f6   7e ea     
   mov   r7,#0      ; c3f8   7f 00     
   lcall   0xe479      ; c3fa   12 e4 79    Copy to code to RAM?
   clr   c      ; c3fd   c3         
   mov   ea,c      ; c3fe   92 af         Disable interrupts
   lcall   Xea00      ; c400   12 ea 00      Copy to Flash
0xc403:   
   nop         ; c403   00         
   nop         ; c403   00         
   nop         ; c403   00         
   ljmp   Xc403      ; c406   02 c4 03      Loop forever

The actual payload is then inserted at 0xEA00 (not inserted, sorry, overwrite)

Xea00:   mov   dptr,#X4039   ; ea00   90 40 39   
   mov   a,#1      ; ea03   74 01     
   movx   @dptr,a   ; ea05   f0         
   mov   a,#50h      ; ea06   74 50   
   mov   38h,a      ; ea08   f5 38   
   clr   a      ; ea0a   e4         
   mov   39h,a      ; ea0b   f5 39   
   setb   p1.5      ; ea0d   d2 95   
Xea0f:   mov   dptr,#X4000   ; ea0f   90 40 00   
   movx   a,@dptr   ; ea12   e0         
   jb   acc.7,Xea0f   ; ea13   20 e7 f9   
   mov   dptr,#X4c0e   ; ea16   90 4c 0e   
   movx   a,@dptr   ; ea19   e0         
   addc   a,#7ch      ; ea1a   34 7c   
   mov   dptr,#X404b   ; ea1c   90 40 4b   
   movx   @dptr,a   ; ea1f   f0         
   mov   dptr,#X4c0d   ; ea20   90 4c 0d   
   movx   a,@dptr   ; ea23   e0         
   addc   a,#9ah      ; ea24   34 9a     
   mov   dptr,#X404a   ; ea26   90 40 4a   
   movx   @dptr,a   ; ea29   f0         
   mov   dptr,#X4c0c   ; ea2a   90 4c 0c
   movx   a,@dptr   ; ea2d   e0       
   mov   dptr,#X4049   ; ea2e   90 40 49   
   movx   @dptr,a   ; ea31   f0         
Xea32:   setb   p1.5      ; ea32   d2 95     
   mov   dptr,#X4060   ; ea34   90 40 60
   movx   a,@dptr   ; ea37   e0         
   mov   r7,a      ; ea38   ff         
Xea39:   mov   dptr,#X4000   ; ea39   90 40 00   
   movx   a,@dptr   ; ea3c   e0         
   jb   acc.7,Xea39   ; ea3d   20 e7 f9   
   clr   p1.5      ; ea40   c2 95     
   mov   dptr,#X5555   ; ea42   90 55 55   
   mov   a,#0aah   ; ea45   74 aa     
   movx   @dptr,a   ; ea47   f0         
   mov   dptr,#X2aaa   ; ea48   90 2a aa   
   mov   a,#55h      ; ea4b   74 55     
   movx   @dptr,a   ; ea4d   f0       
   mov   dptr,#X5555   ; ea4e   90 55 55   
   mov   a,#0a0h   ; ea51   74 a0     
   movx   @dptr,a   ; ea53   f0         
   nop         ; ea54   00       
   nop         ; ea55   00       
   mov   a,38h      ; ea56   e5 38     
   mov   dph,a      ; ea58   f5 83     
   mov   a,39h      ; ea5a   e5 39     
   mov   dpl,a      ; ea5c   f5 82     
   nop         ; ea5e   00         
   nop         ; ea5f   00         
   mov   a,r7      ; ea60   ef         
   movx   @dptr,a   ; ea61   f0         
   mov   dptr,#X0000   ; ea62   90 00 00 
   movx   a,@dptr   ; ea65   e0       
Xea66:   mov   dptr,#X0000   ; ea66   90 00 00   
   movx   a,@dptr   ; ea69   e0       
   mov   r7,a      ; ea6a   ff         
   movx   a,@dptr   ; ea6b   e0       
   xrl   a,r7      ; ea6c   6f         
   jb   acc.6,Xea66   ; ea6d   20 e6 f6   
   nop         ; ea70   00         
   nop         ; ea71   00         
   inc   39h      ; ea72   05 39     
   mov   a,39h      ; ea74   e5 39     
   jnz   Xea7a      ; ea76   70 02     
   inc   38h      ; ea78   05 38     
Xea7a:   clr   c      ; ea7a   c3         
   subb   a,#0      ; ea7b   94 00     
   mov   a,38h      ; ea7d   e5 38     
   subb   a,#58h      ; ea7f   94 58     
   jc   Xea32      ; ea81   40 af     
   ret         ; ea83   22         

I typically start the system by ejecting the DVD (to check firmware is good) then insert the DVD. Once this code has been run the Security Sector from the inserted Xbox1/360 disk will be written to 0x5000 – 0x57ff. Extract this 2K byte chunk from the flash image.

In order to validate this hack it was necessary to decrypt the challenge/response table that would be copied into the ReadDVDStructure command response. In order to do this I have hacked together a VC++ project that will do just that. It is a horrible hack, built from TheSpecialist’s (amen) unlock code, smo’s Linux code with a twist of Robinsod. I make no apologies for the state of the code, it is purely for validating the data I extracted. Run it from the command line and pass 1 parameter, the name of a 2K byte file that was extracted from the Flash.

I have extracted the sector from 1 Xbox1 game and 1 ‘360 game, as observed by others, the version number has been up revved to 2. The decrypt code doesn’t seem to work for ‘360 security sector data. Smart ‘crypto people step up here

The data following the ReadDVDStructure should be useful too but I have not had time to look at it in detail. I believe it is the remainder of the security sector which is not available via the ReadDVDStructure.

Since I have no usable Xbox1 drive and only 1 original Xbox1 and ‘360 game disk I would be grateful if someone with both  drives and more games could verify my findings.

Big up to Tiros for all his help

[nokaktsawa]

Thanks for sharing your results, Robinsod!

By the way, I have troubles opening your attached code. After I rename it in .zip extension, when I try to open it using winrar 3.51 it tells me the following: "SectorDecryptor.zip: Unexpected end of archive".
Winzip refuses to open it too 

[robinsod]

Damaged archive then. You could try downloading again or possibly some kind moderator will drift by and offer to host it properly (hint, hint) or maybe even PM me wiith you email address.....

I might try and figure out how to produce a PPF patch file, that will save a bit of typing

[nokaktsawa]

As noted by others, the Security Sector is located at PSN 0xFD021E which it is not possible to read with a normal DVD drive. One approach is to hack the 360’s DVD firmware such that it will copy Security Sector from DRAM to Flash as soon as possible after it has been read. The following snippet of 8051 assembler will do just that, but please note

...

2)   It may not be complete. There appears to be no data from 0x0007 to 0x000A and TheSpecialist (hallowed be his name) observed: “BTW, I'm sure you noticed, but to make your analysis complete: &Sector[0x07] -&Sector[0x0A]  contain the unencrypted challenge.” Possibly I am too late dumping DRAM to Flash and it has been overwritten.
...

Excuse me for a possibly n00b question, maybe I missed something, but are we 100% sure that the control data block's written on the 360 game disc's are located at the very same address (PSN 0xFD021E) where it was located on xbox1 disc's? And that the challenge is located on the very same sectors (&Sector[0x07] -&Sector[0x0A]) for both xbox1 and 360 discs?

[robinsod]

No, I'm not 100% sure of the PSN & it's a good question. FD021E sticks out like a sore thumb in the firmware, its read from the Flash using a small utility function. The same function is used in several other places to read constants from Flash so it could be that another PSN is used. I ddin't notice any numbers that looked like sectors in the lead out (I am confident that it's in the leadout.) but I will check again tonight 

However, the data dumped to flash IS copied from the correct area of DRAM. The firmware copies part of this 2K block to generate the response to a ReadDVDStructure. Looking at the code I think that the security sector is contiguous in DRAM so the data following the encrypted C/R table may well be useful. The 0's at 0x07 - 0x0A are a puzzle though

[FuzzyLogic]

Very well done!

I used a different approach:

Modify the firmware of a HL8164 (PC DVD-ROM), so that all LBA/PSN checks are removed, and i can read beyond the last data sector on the disc.
Now you can just use your favourite tool (plscsi or DVDinfopro) to read any sector in the lead-out.

I noticed a few things:
The SecuritySector is located at FD021E, followed by a sector (FD021F) which looks like a "04H Disc Manufacturing Info" sector.
However, the last part of this sector is different from the one on layer 0 (Lead-in).

I'm not sure if this is used, but it's better to know that it exists

Another thing is, that there are multiple copies of the SecuritySector. Every 20H sectors further into the lead-out there is a copy.
So you'll find this sector at FD023E, FD025E, FD027E etc..
I compared these with the one at PSN FD021E, but there is no difference.

[nokaktsawa]

Well, your solution seems safer, Fuzzylogic. At least the precious xbox360 drive doesn't take any risks.

The PC drive you used is very popular. Are you willing to release a firmware patch?
AFAIK there is nothig wrong with it. Is it?

Also, I wonder what's the purpose to duplicate the secutity sector multiple times on the disc. But providing there's a reason, it should mean that the 360 drive fw could potentially contain pieces of code that addresses to any of them and not only the one in PSN FD021E, right?

[Geremia]

I noticed a few things:
The SecuritySector is located at FD021E, followed by a sector (FD021F) which looks like a "04H Disc Manufacturing Info" sector.
However, the last part of this sector is different from the one on layer 0 (Lead-in).

I'm not sure if this is used, but it's better to know that it exists

Another thing is, that there are multiple copies of the SecuritySector. Every 20H sectors further into the lead-out there is a copy.
So you'll find this sector at FD023E, FD025E, FD027E etc..
I compared these with the one at PSN FD021E, but there is no difference.

Seems like the leadout zone is structured quite similar to the leadin but sectors writed backwards (from dvd spec (page 45)) where in leadin the control data zone is 16sectors repeated 192 times. This 16 sectors in leadin are:
- 1 sector - phisical information
- 1 sector - disk manufacturing information
- 14 sectors - content provider information

I've not looked at leadout sectors, but seems like backward the FD021E is the first of the 14 sectors, then FD021F is the disk manufacturing sector....right? can you confirm?
What about sector FD0220? is it empty or does it contain the "game partition" phisical structure? If not, where is it? in leadin content provider information?!?
Can you try to hotswap with a blank DVD+R DL and see if sectors after FCFFFF are pre-recorded or recordable?..hum....

[Tiros]

I might try and figure out how to produce a PPF patch file, that will save a bit of typing

I think I good idea is to use an assembler that that produces the intel hex file. An .org directive can be used to overwrite any instructions, for patching. Another org sets the new executable address space. The .HEX file will only contain data for addresses targeted by the assembler. So you first load the full bin into your programmer software, then you load the .HEX on top of it, like an overlay. Make sure you don't have your software set to "clear buffer" when youl load the .HEX file. Additionally hex files are ASCII text so they could be posted right onto the board for copy/pasting.

[FuzzyLogic]

Seems like the leadout zone is structured quite similar to the leadin but sectors writed backwards (from dvd spec (page 45)) where in leadin the control data zone is 16sectors repeated 192 times. This 16 sectors in leadin are:
- 1 sector - phisical information
- 1 sector - disk manufacturing information
- 14 sectors - content provider information

I've not looked at leadout sectors, but seems like backward the FD021E is the first of the 14 sectors, then FD021F is the disk manufacturing sector....right? can you confirm?

What about sector FD0220? is it empty or does it contain the "game partition" phisical structure? If not, where is it? in leadin content provider information?!?
Can you try to hotswap with a blank DVD+R DL and see if sectors after FCFFFF are pre-recorded or recordable?..hum....

There are only these two sectors that are filled with data. The remaining 30 are empty.
The game partition physical structure, is located in the first 16 bytes of sector FD021E:
E1 0F 31 10 00 04 FB 20 00 FB 04 DF 00 20 33 9F

btw the SecuritySector is repeated 80 times in the leadout.

[robinsod]

I got some security sectors from another source today and my flash code appears to read 13 bytes too early (should start copying from 9a89 I think not 9a7c) so the Sector Decryptor has been fixed to agree with what is on the disk.

So change
   addc   a,#7ch      ; ea1a   34 7c   
to
   addc   a,#89h      ; ea1a   34 89

BTW: I assemble these patches by hand (when I were a lad we were too poor to afford such luxuries as an assembler) and I dont have an Intel Hex switch

Sector Decryptor now available here: http://www.bigupload.com/php/download.php?id_upload=547D2C7E

Laters.....

[TheSpecialist]

Great minds think alike ? In this case, the "great minds" followed different paths to Rome I like the different ways both you guys succeeded in dumping the security sector, respect !

I followed a 3rd approach, by patching the 'read dvd struct' handler to return what I thought was the 'complete security sector'. However, comparing our results leads to a very interesting difference: these 07-0A bytes, the unencrypted challenge ! Since in both the Philips and the 8050L the security sector data starts in memory at byte X+$10 (and the challenge at X+7 to X+$A), I assumed that these first $10 bytes were the first $10 bytes of the security sector, but apparently they are not and the security sector data starts in memory at byte X+$10 and NOT at 'X' (what I suspected to be the case) ....


So the interesting puzzle now is: where do these first few bytes (containing the unencrypted challenge) come from ?

[MacDennis]

So the interesting puzzle now is: where do these first $10 bytes (containing the unencrypted challenge) come from ?

Can I have a go? Can I? 

Taken from:
http://www.deluxemedia.com/images/dvdintroduction.pdf
"The data on a DVD disc are divided into sectors each containing 2048 bytes of user data plus 12 bytes of header data and 4 bytes of error detection code (EDC) making a total of 2064 bytes per sector."

It's my guess that the challenge value is stored in the header of sector FD021E. We can't read this header by normal means as far as I know, only the normal 2048 'user data' bytes.

*edit*
Structure of header:

ID: 4 bytes - Sector type, data type, layer number and sector number
IED: 2 bytes - ID error correction code
CPR_MAI: 6 bytes - Copy protection and region code (for DVD-Video)

Looking at some full (2064) bytes raw sector dumps of sector FD021E (which were not made by me), it's now pretty much confirmed that in case of a xbox1 disc the header of this sector contains the sector number in the field ID (value: FD021E) and that the challenge value is located in the CPR_MAI field. It's not possible to read this header without a dvd-rom firmware modification.

*edit2*
More information can be found in ECMA-267:
http://www.ecma-international.org/publications/standards/Ecma-267.htm
Look at chapter 16, Data Frames.

[robinsod]

Comparing the data I captured with a security sector it looks like the last 2 sections ($D0 & $D1 LBA range check and plain text response table ?) are incorrect so either (1) I am too late and it's gone or (2) it wasn't there to start with

Looks like this mediocre mind stopped of at Milan on the way (dreadful place, went there once, I met this tranny ho and  ....... Oops! thats for a different thread)

[TheSpecialist]

@ MacDennis: seems the puzzle is solved, congratulations Wow, finally they (MS) did something good. I like their idea of putting information into the CPR_MAI field, since it's going to be pretty hard to mod a burner to write specific data to that field However, it's a piece of cake to patch the xbox FW, hehe, but at least, I like the idea ! At least they did their best to make sure you can't simply burn a correct backup and get it running without modded FW.

Rest of their security implementation pretty much failed, of course That is for the xbox 1 at least, I wouldn't know about the 360

[xDREAM]

TheSpecialist: just to clear up one thing, your xbox1 firmware does it allow you to play every game or only the game the Security Sector came from?

[TheSpecialist]

TheSpecialist: just to clear up one thing, your xbox1 firmware does it allow you to play every game or only the game the Security Sector came from?

The security sector and the game are NOT linked, so you can use the security sector from game A to get game B authenticated. I just could not believe it, that MS didn't link these, but hey, I also just could NOT believe that the 16 byte key is dumpable via software

However, I only tested it for 1 game, it might very well be possible that 'newer' games DO link the security sector to the game (via the 'new' media check), haven't verified this, so it might be possible that for these games you'll have to save the sector to disk instead of FW

[xDREAM]

Ok thats good for us =)
So i guess this is true for 360 games also since they are based on the same system no?

[MacDennis]

So i guess this is true for 360 games also since they are based on the same system no?

That's just wild speculation. Please find out if this is true or not and report back here.

On topic: higher RAM dumping IS possible on the 8050L. Simply change the MSB of the address from 0x80 to 0x81. Yes, security sector header dump is then possible without any modification so I have to retract my previous claim. 

[xDREAM]

So i guess this is true for 360 games also since they are based on the same system no?

That's just wild speculation. Please find out if this is true or not and report back here.

Well i just started looking into this xbox "hacking" altho im pretty decent with assembler only coded it in windows. I do have a 360 and will sure test things out. Thanks guys for all the info.