Recovering challenge response table from sector FD021E

[zobyone]

Hi,

This info won't be new for some of you

Here is some code to recover the challenge response table from sector FD021E :

Code:

        unsigned char sect_FD021E[2064];//You need to fill this table with full sector (including CPRMAI etc)
unsigned long cprmai1234;
unsigned char demux_table[0xD0];
unsigned char challresp_table[0xD0];
int res;

cprmai1234=*((unsigned long*)(sect_FD021E+7));// get the CPRMAI[1-4] datas from FD021E sector
for(int i=0;i<0xD0;i+=4)//Process 9*23 entries
{
//Obfuscated Demux table offset (from start of sector) : 0x73C (0x8003641c)
//Deobfuscate the table by applying xor
(*(unsigned long*)(demux_table+i))=*((unsigned long*)(sect_FD021E+0x73C+i))^cprmai1234;
}

//Now we use the demux_table to recover the challenge resp table from sect_FD021E
//80036E00[i]=8003634D[80036D00[i]]
//Muxed chall-resp table offset (from start of sector) : 0x66D (0x8003634d)
for(int i=0;i<0xD0;i++)//Process 9*23 entries
{
//Reorder bytes using demux table
challresp_table[i]=*(char*)((sect_FD021E+0x66D+demux_table[i]));
}
// challresp_table contains deobsfucated challenge response table

Bye,

[robinsod]

This is decoding the Drive's response table. Sector Decryptor  was posed a while ago - a command line app that decoded both the consolses C/R table for Xb1 (thanks Spec) and the drives response table for XB1 and 360. The same obfuscation is used in both consoles. There are only 21 entries in a 360's tables. Interesting things can be found in the drives response table.....

BTW: I think there are only 0xcf entries in the data (23*9 = 0xcf)

[probutus]

If someone can please pm me a complete log from the switching on of the console starting with the initial INQUIRY  till after the challenge-response mechanism I can try to enhance the linux ide-cd driver module to get this table.. (maybe in conjunction with plscsi) but I need some input to do it...

(sorry for this kind of double posting (see linux driver section) but I do not know which section is better used for this question)

[robinsod]

The drive never sends this table to the console, you cant get it directly. The ReadDVDStruct command returns an RC4 ecrypted struct (xb1, for 360 the crypto's currently unknown) which contains the response table plus the challenges. TheSpecialist released code to retreive the C/R table and decrypt it for xbox 1

This is all in the big thread

Ah crap, I just realised......

[probutus]

Thanks for the info;

what I am just wondering is that if the drive reads the sector; it should be available somewhere in the drives ram area where we can get it by using SeventhSons memory-dump technique...

Do you know if the sector is available in the drive ram somewhere (if a 360-Disc is inserted)

BTW: If I use SeventhSons memdump I always get an DMA-timeout with the complete lockup of the drive... Is this a known issue?

[SpenZerX]

BTW: If I use SeventhSons memdump I always get an DMA-timeout with the complete lockup of the drive... Is this a known issue?

you should check the length in your last line:

plscsi -p -v -x "E7 48 49 54 01 00 81 03 40 00 C0 00" -i xC000 -t 04.bin

My drive never locks up while reading ram.

SpenZer

[SeventhSon]

what I am just wondering is that if the drive reads the sector; it should be available somewhere in the drives ram area where we can get it by using SeventhSons memory-dump technique...

Do you know if the sector is available in the drive ram somewhere (if a 360-Disc is inserted)

The sector is available in one of the RAM 'secret ranges' that I wrote about in my notes. There are range checks to prevent the dumping of this range but they are trivial to bypass as described in my notes. The raw 2064 byte security sector 0xFD021E is available at address 0x80035CE0.

I only started looking at the 360 disc authentication system yesterday (better late then never I guess), but I'm sure somebody will correct me if I'm wrong

BTW: If I use SeventhSons memdump I always get an DMA-timeout with the complete lockup of the drive... Is this a known issue?

Although it is a known issue that I write defective code ;-), this specific issue is not known as far as I know. What's the command line you're using? I'll take a look.

[SpenZerX]

The question is where the drive GDR-3120 reads the sector FD021E. After this we can look what changes
are needed. I think that moving the important data (the data we cant write to dvd-r) to another
 place on the DVD is the best method to fix the problem.


Aktually this is the control data block and the security sector.


Ok, lets start with the control data block


I think the drive reads the control block here:
----------------------------------------


Step 1: The Lens is placed on Layer 0

ROM0:900344BA                 mov     0x2F270, D0     ! PSN Sector


Step 2: Then the PSN 2f280 to 2fe00 are read sector by sector

ROM0:9003451B                 mov     0x2F280, D0
ROM0:90034521                 mov     0x2FE00, D1     ! PSN Sector
ROM0:90034527                 mov     0, A0
ROM0:90034529                 call    ReadPSNArea, [D2,D3], 0x10


Step 3: If the PSN is 2F280 the control data block is read to memory here

ROM0:90021E37 loc_90021E37:                           ! CODE XREF: PSN_GELESEN+15j
ROM0:90021E37                 mov     DISC_Control_Block_Storage, D2 ! Lesen? Zieladresse?
ROM0:90021E3D                 mov     0x7D6, A2       !  7D6 2006
ROM0:90021E40                 bra     loc_90021E4B
ROM0:90021E42 ! ---------------------------------------------------------------------------
ROM0:90021E42
ROM0:90021E42 loc_90021E42:                           ! CODE XREF: PSN_GELESEN+Ej
ROM0:90021E42                                         ! PSN_GELESEN+1Cj
ROM0:90021E42                 mov     Hier_gelesener_810_Byte_Sektor, D2 ! Lesen? Zieladresse?
ROM0:90021E48                 mov     0x7D0, A2       ! Length 7D0 2000
ROM0:90021E4B
ROM0:90021E4B loc_90021E4B:                           ! CODE XREF: PSN_GELESEN+27j
ROM0:90021E4B                 mov     0xFFFFFF, D3
ROM0:90021E51                 mov     0x2F280, A3     ! PSN Wichtiger Block???
ROM0:90021E57                 and     D3, D0
ROM0:90021E59                 cmp     A3, D0
ROM0:90021E5B                 bne     NICHT_LBA_2F280




The next days i will test some patches like this:

ROM0:900344BA                 mov     0x3F270, D0     ! PSN patch

ROM0:9003451B                 mov     0x3F280, D0
ROM0:90034521                 mov     0x3FE00, D1     ! PSN patch

ROM0:90021E51                 mov     0x3F280, A3     ! PSN patch

After this patches the drive will search for the control block at PSN 3F280-3FE00
(3F280 exactly which is writeable on dvd-r)

And when this is done and working i will continue at the security sector.

SpenZer

[SuperMario]

Quote @ Spenzer:  "Aktually this is the control data block and the security sector."

Actually, it is not, it is far more complex than that.  As Ezekiel already has pointed out, these sectors have all been replicated and the protection is far more advanced than just a simple "out of range" sector.

The security areas are intrinsic to the protection and they are where the real meat of the protection and authentication system.

SuperMario.

[probutus]

Wow, that's what I call support  Theres now a lot of data which has to be passed through a small unbuffered flash between my ears....

@SeventhSon: That are NO  bugs but just small incoherencies I appreciate your page and tools very much... GREAT WORK!

@SpenZerX: The command I used to dump the ram was from SeventhSons page:
./memdump /dev/hdc 66048 8 32768 ./ram.bin
Do you have an idea?

BTW: _OT_: I just compiled a kernel for the most recent knoppix 50 kernel (need to test it)... If this succeeds we can at least boot with the GDR into linux (i will incorporate all these wonderful tools into it in step 2) which hopefully allows easy testing and dumping

a very big thank you also goes to robinsod....

[MacDennis]

The question is where the drive GDR-3120 reads the sector FD021E. After this we can look what changes
are needed. I think that moving the important data (the data we cant write to dvd-r) to another
 place on the DVD is the best method to fix the problem.

Yes, it's a good start.

Yes, the normal control data block is read from 0x2F280. Sector 0x2F280 and 0x2F281 are preserved in memory. Sector 0x2F280 contains the Physical Format Information (PFI). Look at ECMA-267 for details. And yes, you can dump the higher RAM region which contains these two sectors. 0x2F280 contains the default physical information of the disc.

Yes, 0xFFFD021E is the PSN of what we generally call the 'security sector'. Just look at the original firmware hacking thread. As was already concluded back then, this sector forms the basis of the authentication. It's part of a range of 16 sectors which are read and preserved in high RAM. Sector 0xFFFD021E is sector '0xE' of this range. Hint: search for 0xFFFD0210 in your firmware ..