Update R4 v1.06 kernel (Test Edition) 2007-1-13
1)Hiding the display of those files and directories with "Hiding" attributes
2)Using L button as same as touching the screen to adjust the brightness
3)Narrowing the display for transditional chinese characters
4)Background light should be turn off while closing DS in save mode
5)Soft reset included (L+R+A+B+X+Y) or touch the soft reset button with R to switch on/off this function
Soft reset for multimedia will be applied on Moonshell 1.6 official release

I have now successfully mounted my HYNIX flash in a socket and developed 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 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

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

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