Downgrading the Kernel

[robinsod]

I have now successfully mounted my HYNIX flash in a socket and developped code to read, erase and reflash areas of that flash. I have also been sniffing the flash bus during the 360's power on sequence.

I believe my 360 was last updated from the NFS:Carbon game disk. The Kernel and Dash versions are reported as:
D 2.0.2868.0
K 2.0.2868.0
BK 2.0.1888.0

The read sequence I observed agrees broadly with that posted on free60 (http://www.free60.org/oldwiki/FlashReadOrder) and when "condensed" it looks like this:

Power On:
Reads 0x000000 - 0x0001FF
Reads 0x008000 - 0x00E1FF      ---"CB"
Reads 0x000000 - 0x0001FF
Reads 0x001000 - 0x003FFF      
Reads 0x00C000 - 0x00C1FF
Reads 0x00E000 - 0x0699FF                                 
Reads 0x06C000 - 0x06C1FF      ---"CF"
Reads 0x07C000 - 0x07C1FF      ---"CF"      As per free60.org upto here
Reads 0x06C000 - 0x07BFF0      ---"CF"         My log differs from free60.org from here

Notice how the 360 reads the first 0x200 bytes of the blocks marked "CF" and then selects one to read completely. This suggests that the 360 is reading the version numbers of kernel patches and selecting the most recent. In this case the patch at 0x06C000 is read. To test the theory I erased

1) 16KB block of Flash at 0x06C000, result:
D 2.0.2858.0
K 2.0.2858.0
BK 2.0.1888.0

2) 16KB block of Flash at 0x06C000 and 0x07C000, result:
K 2.0.1888.0

3) Inserted the NFS:C disk and reapplied the 2.0.2868.0 update, result:
D 2.0.2868.0
K 2.0.2868.0
BK 2.0.1888.0

Dumping the flash after 3 showed that the kernel patch at 0x6C000 had been replaced. The first 0x20 byte header is identical to my original dump (prior to 1 above) and looks like this:

0006C000   43 46 0B 34 00 00 00 00  00 00 03 60 00 00 44 C0   CF.4.......`..DÀ
0006C010   07 60 00 00 0B 34 00 00  00 00 00 00 00 01 FB 60   .`...4........û`

0x0B34 = 2868 Version number?!

Then follows 0x44BF bytes of data, this does not match the same number of bytes from my original dump (presumably a different key was used to encrypt this section) . This is followed by a section marked "CG"

The header at 0x7C00 (from my original dump):

0007C000   43 46 0B 2A 00 00 00 00  00 00 03 60 00 00 44 C0   CF.*.......`..DÀ
0007C010   07 60 00 00 0B 2A 00 00  00 00 00 00 00 01 E9 00   .`...*........é.

0x0B2A = 2858 Version number?!

Then follows 0x44BF bytes of data. This if followed by a section marked "CG"

At 0xE1E0 I found this header:

0000E1E0   43 44 07 60 00 00 00 00  00 00 02 60 00 00 56 F0   CD.`.......`..Vð
0000E1F0   D0 D8 F8 E2 2B 95 3B 33  08 6E 68 6F A5 A6 BF 50   ÐØøâ+•;3.nho¥¦¿P

0x0760 = 1888 Version number?!

So now I need to find a suitable test software to verify that the console really is downgraded to 2.0.1888.0. The kiosk disk perhaps........

[robinsod]

Downloaded and applied 2.0.4552.0 update, patch header at 0x7c000 was overwritten:

0007C000   43 46 11 C8 00 00 40 00  00 00 03 60 00 00 44 C0   CF.È..@....`..DÀ
0007C010   07 60 00 00 11 C8 00 00  00 00 00 00 00 02 F1 00   .`...È........ñ.

0x11C8 = 4552 Version number?!

[TheSpecialist]

I'd like to toss in my theory about the 'patches'. There are 2 questions here:

1. Why does MS upgrade via 'patches' and not just by sending the whole files and
2. Why don't they just patch the files in flash, but instead, keep the original files + patches in flash ?

There are various good answers to question one, but I think the best answer is that it has to do with the limited space. Now, it is very easy to roll back the kernel: they always keep the original file, so they can hold various kernel versions in the Flash, because the patches are relatively small. If they wouldn't use patches, but complete files, then they wouldn't probably have space enough for 2 kernels !

About the answer to question 2 I am pretty sure: they simply can NOT patch the exe files themselves on the flash ! Because doing so, would break the signature, so they would need ro resign the files and MS is not going to send us the private key to do so Besides, another reason would be that rolling back would be more difficult.

So, to conclude, the filesystem always contains the V1.0 version of the files (well: 2.0.1888.0  November 22, 2005  Original shipped version), plus the patches. The 360 scans for the latest patch, loads both the original exe and the latest patch, checks BOTH files for their signature (at least, that is what i EXPECT) and then creates the new, 'patched' exe in its memory.

This of course is quite an usual way of patching and it seems like a very interesting process  ...

[robinsod]

Just noticed a couple more things:

0006C000   43 46 0B 34 00 00 00 00  00 00 03 60 00 00 44 C0   CF.4.......`..DÀ
0006C010   07 60 00 00 0B 34 00 00  00 00 00 00 00 01 FB 60   .`...4........û`

0x0B34 = 2868 Version number?!
0x0760 = 1888 Version of Kernel this patch can be applied to?
0x44C0 = Length (6C000 + 44C0 = 704C0, start of "CG" section)

Doing this yourself:

1) You need to mount the flash in a socket
2) You need a programmer that can support this flash - I made my own. You MUST be able to write both the 512 & 16 byte areas
3) Dump the flash and Identify the "CD" & 2 "CF" (CD appears to be the kernel and the CF sections are part of the patches) sections and the version numbers of each
4) Damage/corrupt/erase the patch(es) you want to invalidate, in other words break the signature so the 360 does not load the patch
5) Prayer, I appear to have made myself a curvy beige brick by applying and removing the 4552 patch

Does anyone know how the ECC bytes are calculated? We need to understand the format of the 16 byte "spare data" in the flash before anything beyond copying/erasing blocks of memory can be done. The general format of this data is

  AA BB 00 00 00 FF 00 00 00 00 00 00 ZZ ZZ ZZ ZZ

Where
AA BB is the block number (AA = LSB, BB = MSB)
FF is the bad page marker (if this is not FF the page is invalid)
ZZ ZZ ZZ ZZ This appears to be some kind of ECC code, anyone know how it is calculated?

[fragreaver]

2. Why don't they just patch the files in flash, but instead, keep the original files + patches in flash ?

I don't know if there's actually a extra space for dashboard-backups (in case, something goes very wrong during the flash), but I'd say, keeping the original and the patched files is only for backup-puposes

correct me, if I'm wrong

[Tiros]

Great Work!

Specualtion:
Since this method trashes only part of the update, I wonder if there is some kind of "fat" that shows those sections as still being occupied. Possible fragmentation, or other possibly uncorrectable problems could occur with this method "as is"? I suppose you could confirm/deny such possibilities through experiments with your device.

[mterlouw]

2. Why don't they just patch the files in flash, but instead, keep the original files + patches in flash ?
...
About the answer to question 2 I am pretty sure: they simply can NOT patch the exe files themselves on the flash ! Because doing so, would break the signature, so they would need ro resign the files and MS is not going to send us the private key to do so Besides, another reason would be that rolling back would be more difficult.

They could just patch the signature as well, no need to sign the kernel on the client side.

I think the reason has more to do with optimizing for the available space. For instance, if you split the storage in half, and use half for the original/failsafe kernel, then without using patches you can only release new kernels that don't exceed the size of the original kernel. But if you had a system in place for patching, you could form a kernel image that is almost double the size of the original. So you get the best of both worlds: the ability to use almost the whole chip for your kernel image, and the ability to roll back to the original kernel in the case of a failed flash or other problem. Of course if your patch masks part of the original image, the amount of virtual space (post-patched image size) decreases.

[probutus]

just got my dump!

Concerning the ZZ ZZ ZZ ZZ bytes:

These bytes are C0 B8 88 22 if the complete 512 byte page is all 0x00. Does anyone know which algorithm spits such a checksum out? CRC32 doesnt and the hamming codes I know for nand flashes all use 6 bytes ECC instead of four (for a 512 byte page)

[robinsod]

I now have 2 360s which have been upgraded to the 2.0.4552.0 Kernel. Neither box will boot if a flash without the 4552 patch is used!!! I verified this with a brand new 360 Core (This one was bought in Munich, today and came with K/D 2.0.2241.0 and a Samsung MS25 - there's still some old stock floating around)

Test procedure:

1) Remove flash and dump, copy to spare flash
2) Install update 2.0.4552.0 (using copy on spare flash)
3) Reinstall original flash (2.0.2241.0) 360 will not boot, black screen for approx 45 seconds followed by flashing red lights
4) Reinstall updated copy on spare flash (2.0.4552.0) and 360 boots normally

WTF??? The original (completely untouched) flash delivered with the console will NOT boot after the 4552 patch has been applied. Something has been changed outside the flash that invalidates the Kernel if the 4552 patch is absent. Analysing the bus activity shows that the read sequence has changed, the Kernel is loaded as normal and both patches are read fully (previously only the most recent was loaded) the boot sequence then repeats.

One other oddity observed in the new flash is in the 512 byte at page 0

Bytes from block 0 of Xbox A:

00000000   FF 4F 07 60 00 00 00 00  00 00 80 00 00 06 C0 00   ÿO.`......€...À.
00000016   A9 20 32 30 30 34 2D 32  30 30 35 20 4D 69 63 72   © 2004-2005 Micr
00000032   6F 73 6F 66 74 20 43 6F  72 70 6F 72 61 74 69 6F   osoft Corporatio
00000048   6E 2E 20 41 6C 6C 20 72  69 67 68 74 73 20 72 65   n. All rights re
00000064   73 65 72 76 65 64 2E 00  00 00 00 00 00 00 00 00   served..........
00000080   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00000096   00 00 00 00 00 06 C0 00  00 02 07 12 00 00 40 00   ......À.......@.
00000112   00 00 00 00 00 00 00 00  00 00 30 00 00 00 10 00   ..........0.....

Base Kernel is 2.0.1888.0 (0x760)
Bring up code ("CB" Section) is at 0x8000, length 0x61E0, Version 1888
Kernel ("CD" Section) is at 0xE1E0
Patches ("CF" Sections) are at 0x6c000 and 0x7c000

Bytes from block 0 of Xbox B:

00000000   FF 4F 07 60 00 00 00 00  00 00 80 00 00 07 00 00   ÿO.`......€.....
00000010   A9 20 32 30 30 34 2D 32  30 30 35 20 4D 69 63 72   © 2004-2005 Micr
00000020   6F 73 6F 66 74 20 43 6F  72 70 6F 72 61 74 69 6F   osoft Corporatio
00000030   6E 2E 20 41 6C 6C 20 72  69 67 68 74 73 20 72 65   n. All rights re
00000040   73 65 72 76 65 64 2E 00  00 00 00 00 00 00 00 00   served..........
00000050   00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00000060   00 00 00 00 00 07 00 00  00 02 07 12 00 00 40 00   ..............@.
00000070   00 00 00 00 00 00 00 00  00 00 30 00 00 00 10 00   ..........0.....

Base Kernel is 2.0.1888.0 (0x760)
Bring up code ("CB" Section) is at 0x8000, length 0x9310, Version 1903
Kernel ("CD" Section) is at 0x11310
Patches ("CF" Sections) are at 0x70000 and 0x80000

The "CB" code is aparently used to boot the main CPU

So, yeah Tiros, there is at least a pointer to the first patch and the second is always found 0x10000 bytes later

Pictures of my modified 360: http://rapidshare.com/files/11603130/motherboard.rar.html. The pin header on the motherboard connects via 40 way ribbon to a board on the top of the 360 that carries the flash.

As for the programmer, really it's just the Embedded Artists LPC2148 module plus prototype board and some pin headers. See the "homegrown hynix reader" thread

[robinsod]

Concerning the ZZ ZZ ZZ ZZ bytes:

These bytes are C0 B8 88 22 if the complete 512 byte page is all 0x00. Does anyone know which algorithm spits such a checksum out? CRC32 doesnt and the hamming codes I know for nand flashes all use 6 bytes ECC instead of four (for a 512 byte page)

No, the ECC bytes for an all 0 page varies depending on where it is in memory but seem constant within a block. Since the block number is written into the first 2 bytes of the 16 spare bytes in each page of a block I suspect this is also included in the ECC bytes somehow. No idea how though

[modrobert]

Further speculation on the 4 byte ECC...

I stumbled across this patent while searching:

Preferably the reversible transformation of input data which results in the flash data is an XOR function combining bytes of information data and overhead data. For example, 4 bytes of overhead data may be XORd with each of the succession of 128 4 byte sequences which from the 512 bytes of information data to provide 512 bytes of flash data whilst these 512 bytes of flash data are used to generate a 4 byte ECC function which is XORd with the 4 bytes of overhead data to produce a further 4 bytes of flash data.

http://www.freepatentsonline.com/20030099140.html (pdf)


I also found this NAND Flash 512Byte ECC Algorithm draft from Samsung, but it doesn't seem to match the 16 Byte header here, only 3 Bytes ECC.

http://www.samsung.com/Products/Semiconductor/Memory/appnote/ecc_algorithm_for_web_512b.pdf

Sample source here:

http://www.samsung.com/Products/Semiconductor/Memory/appnote/samsung_new_ecc_for_512byte_256word.txt

[probutus]

I compiled and compared the samsung ecc mechanism and see no correlation between the samsung mechanism and the flash checksum but I noticed the following:

consider the bytes of ZZ as Z1Z2Z3Z4Z5Z6Z7Z8
Z1 is in all blocks ether 0xC0, 0x00, 0x40 or 0x80

dont know what that means yet...

[DrMatrix]

The ECC algorithm is:

Code:

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 = (void*)edc;
                        v = ~*data++; /* byte order: LE */
                }
                val ^= v & 1;
                v>>=1;
                if (val & 1)
                        val ^= 0x6954559;
                val >>= 1;
        }

        val = ~val;

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

Feel free to improve / analyze (in fact technically, it's not ECC but an EDC.) Also, there was no real magic involved into reversing this, just taking some more-or-less-public code and throwing it into a disassembler.


Further, it looks like MS really deactivated downgrades. Could you please check the "POST"-port? It's the 8 vias in front of the CPU, near the (missing or not) eeprom. It usually counts up to, i think 0x77, but in case of an error, the highest bits get set and the rest is the error code. Every type of "red light" should have it's own error code.

[robinsod]

Nice work & thank you

In most cases the 16 spare bytes take the form:

AA BB 00 00 00 FF 00 00 00 00 00 00 ZZ ZZ ZZ ZZ

Where
AA BB is the block number (AA = LSB, BB = MSB)
FF is the bad page marker (if this is not FF the page is invalid)
ZZ ZZ ZZ ZZ ECC code

And the code posted above works fine BUT there are some spare bytes with the form

AA BB CC 00 00 FF 00 00 DD EE 00 00 ZZ ZZ ZZ ZZ

Where CC is non zero and DD EE may or may not be 0.

For example

A3 01 01 00 00 FF 00 00 04 1A 00 00 34 81 82 D2

In this case the poseted code produces the result C0 C1 83 A1 and not 34 81 82 D2

Perhaps I am being dumb?

[Gobelet]

Maybe they somehow updated the CPU microcode, which could explain why you can't use the older kernel. But then, having a Base Kernel wouldn't be of any use, if it's used as a rescue code base.

[robinsod]

A small update:

During power on the 360 loads the base Kernel from the "CB" section (could this also contain the dreaded Hypervisor?) examines the 2 patch slots (specifically the header of the "CF" sections) and selects the most recent to apply to the base Kernel. The address of the patch slot is in the first 512 byte page, the second slot occurs 0x10000 bytes later, typically these are at:

 0x6c000 and 0x7c000 for "CB" section (version 1888, length 0x61E0) or
 0x70000 and 0x80000 for "CB" section (version 1903, length 0x9310, even though "CB" section header indicate version 1903 the dash reports BK as 1888)

So what's in the rest of the flash and how does the correct data get loaded?

Quote from GaryOPA:
"The 16mb NAND flash is not completely encrypted, it basically is a Microsoft compressed ROMDISK system.

It contains a small header, then a "encrypted" loader, and then a number of stored files in a "compact flash" file system, these files match byte for byte the updated files in the "system_update", and are basically the dashboard files in stored signed-XEX2 file format."

So how does the 360 find it's ROM file syatem?

Within my Flash dump I can see a total of four "root directories" at:

0xD9C000
0xD98000
0xABC000
0xA20000

During the boot process (shortly after the most upto date patch is selected and loaded) the 360 scans it's entire ROM from 0xFFC000 to 0x000000 in 0x4000 byte or NAND flash block sized chunks. When it finds something "interesting" in the first page of that block it reads the whole 0x4000 bytes in page sized chunks. In my 360 I see the following "interesting" blocks being read:

D9C000      Start of FS root? Contains xex, xexp2 & xttp2 files
AC0000      Start of Dashboard Settings? (hehe, the dashboard video resolution is visible in here)
A20000      Start of FS root? Contains xex, xexp1, xexp2, xttp1 & xttp2 files
91C000      Unknown

Note: Every time the dashboard settings are modified (I changed video settings) a new 3*512 block is appended to the end of the list starting at 0xAC0000, presumably the 360 scans this list and picks the last valid one. How the FS root is selected is currently unknown and FFS

When an update is applied the patch data is copied to the "CF" section and encrypted (applying the same patch twice results in different data, presumably the encrytion key changes each time, the associated "CG" section appears to remain the same). The xexp files found in the system update folder are copied to the ROM FS and renamed either xexp1 or xexp2. It seems that the xexp1/2 file extension is selected based on the patch slot. In my case slot 1 (0x6c000) was to be  populated and xexp patch files are renamed xexp1 when copied to the ROM FS.

When a file, such as bootanim.xex is read from the ROM filesystem a check appears to be made and if a patch is being applied the corresponding xexp1/2 file is also read (there is speculation with a fair degree of certainty that these two files are then combined in RAM to give the correct version). The choice of xexp1 or 2 is fixed by the patch slot selected 

[Surrido]

if you forge a "bad Flash" which could likely be caused when power suddenly shuts down during update via live from M$, it should go to a fallback kernel, right?

can we just f*** up the area where the latest flash sits and use this to cause the xbox to jump to the baclup kernel?

[robinsod]

Until the 4552 update that is exactly what I was doing, erasing/corrupting part of the patch and rebooting. The 360 fell back to the previous patch or, if no patch has been applied, the base Kernel.

After the 4552 the 360 WILL NOT BOOT unless the 4552 patch is present in flash


 

[robinsod]

or does it only change things on the flash itself ?
then a 16mb backup of the flash before the update could be flashed on it right ? to set things back ?

Read the thread again But a quick summary - Removed flash and copied it to a spare. Updated 360 with 4552, replaced original flash, 360 no worky!!!! Something other than the flash has changed and you can't roll back to an earlier version

just curious here and are there any dumps available on the net for research ? im still working on a programmer but i have a very low budget so it can take a while 

Would be interested in that too.

They are copyrighted material, and so you should not ask for them here

[speedy22]

More than likely MS has blown an efuse or two with the 4552 update. The efuses are located in the CPU. Anyone interested in learning more should download my 360 CPU datasheet V1.5 from the beginning of March 2005.

My real life is extremely busy right now but I hope to confirm this in the next week.

Speedy22