Downgrading the Kernel

[a360]

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.

Finally the hardware man i was waiting for in this thread.....

However another soft option.
What if the (still hidden!?) hyperb*st*rd was updated to check for the 4552 update (as a new base or something ? Sounds like a job for it as long as noone has a disasembly 

[speedy22]

If we consider this block diagram authentic

http://home.btconnect.com/hgi/xbox2/xsys.html

then it really narrows down the location of the hypervisor.

then read this. http://wiki.free60.org/RandomNotes

Where is the Hypervisor now?

We also know the changes can't be in the flash because of robinsod experiments.

If MS is making hardware changes (blowing efuses) update 4552 maybe historic.

Speedy22

[robinsod]

I'm reasonably sure the Hypervisor is in the Flash, it doesn't seem likely, to me at least, that a lot of non volatile memory (i.e. Flash) is built into the CPU/North Bridge/South Bridge. I think I am right in saying it's expensive in terms of silicon real estate....

The Hypervisor only needs to test a flag in the processor (blown eFuse) against a flag in the patch to make a boot/no boot decision, there could be any number of these flags but at a rate of 1 eFuse / year then 32 would be more than ample. There's no need to actually modify the HV code at all

A pity I didn't think about it before upgrading console number 2. It seems quite likely that Speedy is correct and I am now an eFuse believer (pass the tin foil buddy !)

I have just been re-reading:

http://domino.watson.ibm.com/comm/pr.nsf/pages/news.20020507_simcard.html

Since Speedy has been kind enough to identify the eFuse power supply for us perhaps something useful could be learned by observing the supply current while the processor comes up and reads its eFuses? I need to read some more about eFuses but I would speculate that the current drawn is different depending on the state of the eFuse. A simple I to V converter (a resistor springs to mind) and a high input impedance amplifier might allow us to measure those changes in the current drawn. Of course this could be pure BS, I need to do some more reading.....

[speedy22]

I need to clarify, the efuse enable is used to enable the high voltage supply required to pop/blow the efuse. By high voltage I'm refering in CPU terms. CPU Voltage is in the 1.5 volt range while to blow an efuse you need a min of 3 volts. The efuses act like standard memory and probably contain the HID register data as well. I would guess there are 1K-2K worth of efuses.


Also, when you look at the block diagram be sure to check out the main memory to CPU latencies.

Speedy22

[speedy22]

I would not advise anyone at this time to disable the efuse supply unless you have the flash backed up prior to disabling it. The 4552 update may also detect whether the efuse supply has been disabled and could store this info in the flash and/or perform another security measure. (Flash related)

Speedy22

[robinsod]

Agreed, It's highly likely I will end up with a non-functional board. You have been warned

[aholmes187]

it makes one wonder what is special about the 4552 in order for them to feel the need to blow a efuse...i find it intereasting that they havent done it since with everyupdate as a security measure...? i do remember  reading something a long time ago...ie a year?  that someone disabled the power that is used to blow the efuses but never read anything more, i found his post but he hasnt logged on in like 6 months. ah well...   thanks for posting details of your programmer robinsod, ill hopefully have mine finished next week

[robinsod]

Confirmed, downgrading allows the Kiosk disk to run again!

Thanks to Homer for the hardware, this would not be possible without his generosity

So I have now proved that kernel 2.0.2858 (won't boot the kiosk disk) can be downgraded to 2.0.1888 and that WILL boot the kiosk disk (or bits of it) from CD-R. This was proved with a mobo for which the DVD key is NOT known (as noted by others the key is not necessary when booting the kiosk disk, indeed no C/R data is present on the CD I used so the DVD key is not required, side note: can we use any old SATA drive in the same way that a standard PC drive could be used on a modded XBox1?)

Thanks also to Iso-Mick

Happy Hacking

[maximilian0017]

Great work guys
One question:

If you upgrade to a newer FW than 4552 can you still downgrade to 4552?

It would be interesting to see if they "blow a fuse" at every upgrade, that could be an indication that maby something else is happening.

Was all of this done without a harddisk attached?

[robinsod]

If you upgrade to a newer FW than 4552 can you still downgrade to 4552?

4552 is from the 9th of Jan this year, its the latest, planning to look at the HD-DVD upgrade next though

Was all of this done without a harddisk attached?

Yes, the HDD contains the update because the 4552 patch I am using is part of the backward compat upgrade

[robinsod]

I have now removed R6T3 (this is in the 5V line that drives the eFuse supply) from my test 360's motherboard and applied the 2.0.4552 patch. The reported that the patch was applied successfully and the system rebooted ok.

I then dumped the flash and removed the 4552 patch, the 360 fails to boot and throws E71 errors

Replacing the flash with an image that booted ok to version 2.0.1888 boots successfully

I suspect the 360 is picking up the wrong file system (or the correct FS has been overwritten by the update) and that is causing the E71 error.

So it seems that Speedy_22 is quite right and an eFuse is being blown to prevent rolling back. 

[QuiescentWonder]

Does anyone know what updates the 360 is shipping with now?

I guess the real questions are, any idea of how updates are handled at the factory, do they patch from the original kernel/dashboard or are the written from being blank immediately to the newest version? Is this kernel/dashboard version being written to the 360 in that manner at the factory going to blow any efuses?

[probutus]

From what I have seen on dumps it is very likely that the standard base kernel remains intact but the "initial patch" is changed; I have seen a dump of a brand new xbox which already had a patch kernel and xexps in place

[Tiros]

Just a thought.
Robinsod mentions incorrect/overwritten filesystem...

The Tivo system, uses 2 kernel partitions.
When it downloads an update, it marks the old partition inactive, and the newly downloaded/verified partion active.
When the system restarts, the new kernel boots.
Perhaps efuses are used to configure the "active" filesystem or force access to alternate.

[Tiros]

So what kernel version allows the debug messages to poop out the comm port?
(Like in the wiki)

[probutus]

Afaik the wiki was referring to a emergency/rescue cd containing a kernel and a hypervisor...

[TheSpecialist]

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

Do I understand correctly, that if you downgrade the kernel from version B to A and then upgrade it again to B that ONLY the CF and CG regions are changed in flash ? That would mean that different keys are used for the different regions: the key for decrypting the base kernel is different than the one for decryping the patches...  And I'd guess that also some data outside these regions would have changed: the hash that is used to calculate the decryption key (that's obviously different than it was before the down/upgrade, because these sections are now different) must be stored somewhere too ...

[robinsod]

Do I understand correctly, that if you downgrade the kernel from version B to A and then upgrade it again to B that ONLY the CF and CG regions are changed in flash ?

A more detailed descriptiont:

1) Start with a 360 that has had patch versions 2.0.2858 & 2.0.2868 applied, "remove" both by erasing the first 16KB block of both "CF" sections everything else remains unchanged
2) Reboot to 2.0.1888
3) Re-apply 2.0.2868 patch

Now the old 2.0.2868 "CF" patch has been overwritten by the 360, the 32 byte header remains the same:

   0x43, 0x46, 0x0B, 0x34, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x03, 0x60, 0x00, 0x00, 0x44, 0xC0,
   0x07, 0x60, 0x00, 0x00, 0x0B, 0x34, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0xFB, 0x60

BUT the body of the patch is different suggesting that a different key has been used to encrypt it. The "CG" patch is exactly the same. There are also several other chunks of data that have been overwritten/modified but they lack any identifying marks and a new FS root block has also appeared

Since Takires post in the 16MB Layout section it's pretty clear that we need to consider the 16 spare section and a lot of my dumps don't contain this I am currently creating a better tool to allow easier analysis of these dumps then I intend to repeat the experiment - more details to follow. For now we can sy that the "CF" section is definitely encrypted using a different key BUT the "CG" section isn't

So what kernel version allows the debug messages to poop out the comm port?
(Like in the wiki)

No idea but I suspect that is a probably not a retail build, We can test though.....

Just a thought.
When it downloads an update, it marks the old partition inactive, and the newly downloaded/verified partion active.
When the system restarts, the new kernel boots.
Perhaps efuses are used to configure the "active" filesystem or force access to alternate.

No, seems more likely that the version number in the spare 16 bytes is used and the most recent selected but I need to test that. Since my experiments involved removing / invalidating only the "CF" section it would seem that older kernels (i.e. unpatched) are happy to boot with newer filesystems/dash.xex (up until 2.0.4552). But don't forget I only boot to the dash and check the version number. I would guess that problems could occur if I tried to use some of the other apps.

[dc_away]

maybe a silly thought, but could it be that the time and date are used to calculate the decrypt key? first 4-8 bytes could use the same decrypt key as always, then there would be some bitwise calculation to build an encryption key for the patch. you would have to have perfect timing to test this theroy though... down to the frame. nice work so far robinsod.

[mangueboy]

robinsod, i do nothing about rotines of encryption but i was thinking: if a different key has been used to encrypt  CF patch,  can you use a guessing code to find the unencrypt file since you known   CF¹ and CF² ?   
Weak example:  CFx . k1 = CF¹    and    CFx .k2 = CF²

CFx=unencrypt CF