And
very useful it was too, unfortunately I got over excited with my own research and posted some "discoveries" before I really read your EMail
So credit for a lot of those discoveries should go to GaryOPA (good to see you back on the scene)
>First a 4K header always the same, nothing special.
Not quite, the 4K header contains some interesting numbers starting at 0x00000060...
0x00000000,
0x0006C000, Note 1
0x00020712, Note 2
0x00004000, Note 3
0x00000000,
0x00000000,
0x00003000,
0x00001000 Note 4
Note1: Start address of first patch slot,
Note2: No idea what these are or even if they are a single 32 bit number
Note3: There seems to be something starting here, monitoring the flash bus reveals that the 360 sometimes starts reading at 0x00004000
Note4: Could this indicate the start of the Southbridge code? When I have time I will change this and observe the behaviour when power is first applied
>008000 = "CB" encrypted code -- Bootup cpu code, always starts here. >00E5E0 = "CD" encrypted code -- Sometimes starts at this address: >0E1E0 > ...and first CB is sometimes 26,080 bytes long and on other dumps it is 25,056 bytes long...
It seems there at least 2 versions of the "CB" code out there, they have different lengths. Have MS rev'ed the South Bridge silicon? I need to check some part numbers.
The "CD" section is found at "CB" start + "CB" length
Perhaps we can define some "C" style structs for these section headers and fill in the Unknowns?
typedef struct { char ID[2]; "CB","CD","CE","CG"
word Version;
long Unknown1;
long Unknown2;
long Length;
}Type1Header;
typedef struct { char ID[2]; "CF"
word Version;
long Unknown1; Note 1
long Unknown2;
long Length;
word BaseVersion;
word Unknown3;
word Version;
long Unknown4;
word Unknown5;
long Unknown6;
}Type2Header;
Note1: reviewing my posts I noticed this from the 4552 patch
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 .`...È........ñ.
Unknown1 has the value 0x00004000, all the other "CF" sections I have looked at have a value of 0x00000000.
I noticed while monitoring the flash bus that the 360 scans the flash after selecting and loading a patch, it appears to be looking for filesystem headers (also the dash board settings and something else).
The next question, in my mind at least, is how does it determine which filesystem header to use? i.e. which FS root matches with the selected Kernel patch?
