CB hash position in degraded 1888 image?

[jz_5_3]

I recently got a working xenon motherboard but no dvd key. I would like to do a timing attack using a home made degraded tool ( a xilinx board and a level shifter). The functions of duming/flashing nand and reading post code are working now. I am just wondering where is the the CB hash position in degraded 1888 image? so I can add code to flash that particular page in the nand. I did a search but I cannot find very useful information on it. If you happen to know it, please share with or PM me. thanks

[Redline99]

the "CB" is the 2BL and its pointer is at offset 0x8 at the beginning of the nand (Page 0) The pointer is the offset into the nand (not counting the metadata.  So lets say the pointer is saying 0x00008000.

That would be Page 0x40 (0x8000 offset / 0x200 page size).

In a raw dump its (0x8000 offset / 0x200 page size) = Page 0x40 then (Page 0x40 * 0x10) equating a file offset of 0x8400.

I believe the hash of 2BL is stored at offset 0x30 from the beginning of the 2BL.  Raw File 0x8430 for a length of 0x10 or in the nand at Page 0x40 + 0x30 for a length of 0x10.  This should be part of the encrypted "data starting at 0x20" part of the 2bl so you need the key form 1BL, some hmacsha1 and rc4.

Remember there are 0x20 pages per block in these console and you have to fixup the ECC in the metadata for the page you are modifying.

I haven't looked at this stuff in a long time, so take my info and verify/double check it.

[jz_5_3]

that is great, thanks, you are right at the numbers. see the CB section below (the first one is original image, the second is 1888 degraded image)


"This should be part of the encrypted "data starting at 0x20" part of the 2bl so you need the key form 1BL, some hmacsha1 and rc4."
--> so 2BL data started from 0x20 offset is encrypted with 1BL key (using hmacsha1 and rc4), and after decryption, I should see all 0x00 for 0x10 bytes at offset 0x8430 in the degraded image?  I am just curious why only this 0x10 bytes are different, based on the above image.

"Remember there are 0x20 pages per block in these console and you have to fixup the ECC in the metadata for the page you are modifying."
thanks for reminding me this. I seem to have a copy of the code someone posted before.

[Redline99]

because it is encrypted

the data from 0x20 till end of section is rc4 encrypted, including the hash at 0x30

(To the best of my knowledge)

[jz_5_3]

thanks, I have decrypted the cb. after comparison using cmp command, I found there is one more difference between the decrypted CB and the original one (see the picture at offset 0x8423). what is the meaning of this field? 

I do not have RC4 key to re-encrypt the CB back after changing the hash. how could I obtain that? but It seem I do not really need to have the RC4 encryption key. considering 16-byte difference (or 17 including the above one), I just change the bytes in the line of hash, should this work?

$ cmp -l nand.org.bin.cb.encrypt nand.1888.bin.cb.encrypt
   36 327 322
   49 163 103
   50 304 333
   51 357 244
   52 151 176
   53  67 237
   54 204  22
   55 355 332
   56  36 137
   57 251 115
   58 306 241
   59 370 170
   60  64 135
   61  12  23
   62 347 111
   63 101  53
   64  23 207

$ cmp -l nand.org.bin.cb.decrypt nand.1888.bin.cb.decrypt
   36   0   5
   49  60   0
   50  37   0
   51 113   0
   52  27   0
   53 250   0
   54 226   0
   55  67   0
   56 101   0
   57 344   0
   58 147   0
   59 200   0
   60 151   0
   61  31   0
   62 256   0
   63 152   0
   64 224   0

[Shaun]

looking at my cb bookmark and trying to rem, 0x8420-8422 is the pairing data, 0x8423 is the LDV value (ie fuse counter) albeit in its crypted form

[jz_5_3]

thanks, you are right, shaun! that field is modified by degraded program.

by the way, does anyone have the latest ECC algorithm? the one on this site (the "ugly" version) does not seem to work on my firmware.

[Redline99]

Here is my vb6 version, dont laugh... hehe

Code:

Public Function CalcECC(aData() As Byte, ByVal Start As Long)
Dim i As Long, p As Long
Dim v As Long, val As Long
   
    p = Start
    For i = 0 To &H1066 - 1
        If (i And &H1F) = 0 Then
            If i = &H1000 Then
                'Force pointer to beginning of
                'metadata for this page
                p = Start + &H200
            End If
           
            CopyMemory v, aData(p), 4
            v = Not v
            p = p + 4 'Advance pointer
        End If
       
        val = val Xor (v And 1)
        v = RShift(v, 1)
       
        If (val And 1) = 1 Then
            val = val Xor &H6954559
        End If
       
        val = RShift(val, 1)
    Next i

    val = Not val
   
    aData(Start + &H200 + &HC) = ((aData(Start + &H200 + &HC) And &H3F) Or _
                                 LShift(val, 6)) And &HFF
    aData(Start + &H200 + &HD) = RShift(val, 2) And &HFF
    aData(Start + &H200 + &HE) = RShift(val, 10) And &HFF
    aData(Start + &H200 + &HF) = RShift(val, 18) And &HFF
   
End Function

Little Endian, Thanks DrMatrix and Seventhson

Code:

// Thanks go to DrMatrix for this function.
// I modified it slightly to preserve the block
// type field in the 6 least significant bits of
// spare[0xC]
void calcecc(unsigned long *data, unsigned char  *edc)
{
        int i=0, val=0;

        unsigned long v;

        for (i = 0; i < 0x1066; i++)
        {
                if (!(i & 31))
                {
                        if (i == 0x1000)
                                data = (unsigned long *)edc;
                        v = ~*data++; /* byte order: LE */
                }
                val ^= v & 1;
                v>>=1;
                if (val & 1)
                        val ^= 0x6954559;
                val >>= 1;
        }

        val = ~val;

        edc[0xC] = ((val << 6) | (edc[0xC] & 0x3F)) & 0xFF;
        edc[0xD] = (val >> 2) & 0xFF;
        edc[0xE] = (val >> 10) & 0xFF;
        edc[0xF] = (val >> 18) & 0xFF;
}

Big Endian 64bit compatible of Previous, for use in Xell for example

Code:

// ECC calc function for big endian CPU
void SfcEncodeECC(unsigned int *data, unsigned char  *edc) {
        int i=0, val=0;
        unsigned int v=0;

        for (i = 0; i < 0x1066; i++)
        {
                if (!(i & 31))
                {
                        if (i == 0x1000)
                                data = (unsigned int *)edc;
                        v = ~*data++;           // byte order: LE
                        v = bswap_32(v);
                }
                val ^= v & 1;
                v>>=1;
                if (val & 1)
                        val ^= 0x6954559;
                val >>= 1;
        }
        val = ~val;

        edc[0xC] = ((val << 6) | (edc[0xC] & 0x3F)) & 0xFF;
        edc[0xD] = (val >> 2) & 0xFF;
        edc[0xE] = (val >> 10) & 0xFF;
        edc[0xF] = (val >> 18) & 0xFF;
}

Source: Microsoft Kernel, extracted for learning
Big Endian of Previous, ppc64 asm, for use in Xell for example

Code:

SfcEncodeECC
                // %r3=PageData, %r4=MetaData
                li      %r10, 0
                li      %r11, 0
                li      %r9, 0

Location_1:
                clrlwi. %r8, %r9, 27
                bne     Location_3
                cmplwi  cr6, %r9, 0x1000
                bne     cr6, Location_2
                mr      %r3, %r4

Location_2:
                mr      %r11, %r3
                addi    %r3, %r3, 4
                lwbrx   %r11, %r0, %r11
                not     %r11, %r11

Location_3:
                clrlwi  %r8, %r11, 31
                srwi    %r11, %r11, 1
                xor     %r10, %r8, %r10
                clrlwi. %r8, %r10, 31
                beq     Location_4
                xoris   %r10, %r10, 0x695
                xori    %r10, %r10, 0x4559

Location_4:
                addi    %r9, %r9, 1
                srwi    %r10, %r10, 1
                cmplwi  cr6, %r9, 0x1066
                blt     cr6, Location_1
                not     %r11, %r10
                lbz     %r10, 0xC(%r4)
                srwi    %r9, %r11, 2
                srwi    %r8, %r11, 10
                insrwi  %r10, %r11, 26,0
                srwi    %r11, %r11, 18
                stb     %r9, 0xD(%r4)
                stb     %r8, 0xE(%r4)
                stb     %r10, 0xC(%r4)
                stb     %r11, 0xF(%r4)
                blr

[jz_5_3]

hmm, I found your code is similar to what I got from somewhere else. so I tried to debug it, and found out the problem: my x86_64 linux treats "unsigned long" as 8 bytes, not 4. so I changed that to uint32_t and then it worked well. thanks a lot for the help.

[Redline99]

Updated my post to show other variants