1.0-1.5 TSOP recover BIOS: tsop_m7.bin

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

1.0-1.5 TSOP recover BIOS: tsop_m7.bin

Post by Archive » June 26th, 2019, 7:55 pm

posted by The Tweed Monk on Jan 15, 2019:
If only this was in english....
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

1.0-1.5 TSOP recover BIOS: tsop_m7.bin

Post by Archive » June 26th, 2019, 7:55 pm

posted by obcd on Jan 21, 2019:

Is this trick using some unknown feature of the mcpx chip?
What's special about a "tsop recover" flash bios compared to a normal one?
Just trying to understand how this might work to understand better if it doesn't work, why so.
I mean, I read somewhere that some parts of the tsop flash still need to work properly. That's what puzzling me.
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

1.0-1.5 TSOP recover BIOS: tsop_m7.bin

Post by Archive » June 26th, 2019, 7:55 pm

posted by bennydiamond on Jan 22, 2019:

Oh boy, tons of assumptions and guessing coming up.

The first thing to know is that every Xbox BIOS have 2 "executables" packed together. The actual Xbox Kernel based on Windows 2000 source of course but also a small bootloader, called 2bl.

The job of the 2bl is to answer a couple of security challenges to (try to) prevent tampering of the boot process and then to unpack the Xbox Kernel (essentially a stripped .cab archive), verify it's integrity and jump to it. From that point, the Xbox kernel takes on and it's at that point that you'll see the flubber animation. That's verified info.

The rest is mostly speculative (mostly by me and my understanding of the process).

The magic of the tsop recovery BIOSes all lies in the 2bl. The 2bl embedded in the tsop_recovery BIOS contains some instructions to toggle a signal line on the LPC modchip (A15 pad) which in turn will ground the A15 address line of the Xbox onboard TSOP. After doing that, it tell the modchip to release D0 control and soft-reset the console in order to allow booting from TSOP.

At that point, the 2bl on the TSOP just try to do it's job like normal but will ultimately fail as grounding the A15 line will corrupt the packed Xbox kernel. It corrupts it because if the MCPX is not able to toggle correctly the A15 address signal of the TSOP, it will not actually receive the correct data when A15 is expected to be at "1" or 3.3V.

My assumption is that grounding A15 specifically results in failing to unpack the kernel at a critical point in the process where the MCPX decides to branch to another state than generating a FRAG(normal behavior when trying to load a corrupt kernel). During implementation of this feature on my modchip, I experimented grounding other address lines on the TSOP and found that neighboring address signals could also be used successfully (A15 to A18 if I remember correctly). Anything other than that would not make it work and would result in a FRAG.

Continuing on this, another assumption is that after a couple (unsuccessful) retries unpacking the kernel on the TSOP, the MCPX is programmed to switch to LPC bus temporarily without reseting the system thus keeping the 2bl active in memory. With the normal 2bl in memory and LPC bus being active, the 2bl fetches the packed (hacked) kernel from the modchip and does its job with it. After a while, the MCPX switch back to TSOP access.

You're now in a state where you loaded a hacked kernel but MCPX still points to TSOP, containing a corrupt/stock packed kernel. From then on, you need to either launch Evolution-X dashboard or XBlast OS in order to release modchip's hold on A15 signal (done on launching either program).

At that point, you now have full access to flash the TSOP, providing the write enable points are soldered of course.

In order to make this work, the part of the TSOP containing the 2bl must be valid. The rest can be corrupted.
Second, the Xbox kernel embedded in the tsop_recovery BIOS must be packed as such as the 2bl contained on the TSOP will be able to unpack it. It needs to be encrypted using the same key contained in the 2bl and packed archive must be at most the same size as the stock kernel (because size of the packed image is contained in the 2bl itself and thus cannot be changed on the fly).

Since Evox M8 X2 5xxx and some later BIOSes radically changed how the Xbox kernel is packed (because they use a custom 2bl, I don't know why...), you cannot use the current tsop_recovery images to repair a corrupt TSOP that contain either of those. My theory is you could make it work if you'd manually pack a tsop_recovery BIOS containing the magic 2bl and a packed kernel that was packed using evox's 2bl "standard". So far, I have not been able to make this work. I have not dissassembled this evox 2bl to see how it ticks but there is something fishy going in there when it comes to unpacking the kernel.

My guess is this TSOP recovery process takes advantage of a manufacturing loophole set in place in the MCPX to easily flash the Xbox TSOP through the LPC port while on the asembly line, or during QA testing. There is probably a way to send a signal to the MCPX in order to fully control that loophole but I guess nobody ever found it.
It's quite common practice in electronics manufacturing to automate flash programming while in production. Coupled with the fact that in this case, this process must remain hidden away from the public, finding how to trigger it is always a challenge or takes a really long time to figure out. Just look at the Pandora Battery exploit on PSP or the PS3 jailbreak dongles in the early days of PS3 hacking. Both were likely purposedly put in place in order to facilitate programming in production or service them in repair centers.
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

1.0-1.5 TSOP recover BIOS: tsop_m7.bin

Post by Archive » June 26th, 2019, 7:55 pm

posted by dark ricardo on Jan 22, 2019:

bennydiamond said:






Oh boy, tons of assumptions and guessing coming up.

The first thing to know is that every Xbox BIOS have 2 "executables" packed together. The actual Xbox Kernel based on Windows 2000 source of course but also a small bootloader, called 2bl.

The job of the 2bl is to answer a couple of security challenges to (try to) prevent tampering of the boot process and then to unpack the Xbox Kernel (essentially a stripped .cab archive), verify it's integrity and jump to it. From that point, the Xbox kernel takes on and it's at that point that you'll see the flubber animation. That's verified info.

The rest is mostly speculative (mostly by me and my understanding of the process).

The magic of the tsop recovery BIOSes all lies in the 2bl. The 2bl embedded in the tsop_recovery BIOS contains some instructions to toggle a signal line on the LPC modchip (A15 pad) which in turn will ground the A15 address line of the Xbox onboard TSOP. After doing that, it tell the modchip to release D0 control and soft-reset the console in order to allow booting from TSOP.

At that point, the 2bl on the TSOP just try to do it's job like normal but will ultimately fail as grounding the A15 line will corrupt the packed Xbox kernel. It corrupts it because if the MCPX is not able to toggle correctly the A15 address signal of the TSOP, it will not actually receive the correct data when A15 is expected to be at "1" or 3.3V.

My assumption is that grounding A15 specifically results in failing to unpack the kernel at a critical point in the process where the MCPX decides to branch to another state than generating a FRAG(normal behavior when trying to load a corrupt kernel). During implementation of this feature on my modchip, I experimented grounding other address lines on the TSOP and found that neighboring address signals could also be used successfully (A15 to A18 if I remember correctly). Anything other than that would not make it work and would result in a FRAG.

Continuing on this, another assumption is that after a couple (unsuccessful) retries unpacking the kernel on the TSOP, the MCPX is programmed to switch to LPC bus temporarily without reseting the system thus keeping the 2bl active in memory. With the normal 2bl in memory and LPC bus being active, the 2bl fetches the packed (hacked) kernel from the modchip and does its job with it. After a while, the MCPX switch back to TSOP access.

You're now in a state where you loaded a hacked kernel but MCPX still points to TSOP, containing a corrupt/stock packed kernel. From then on, you need to either launch Evolution-X dashboard or XBlast OS in order to release modchip's hold on A15 signal (done on launching either program).

At that point, you now have full access to flash the TSOP, providing the write enable points are soldered of course.

In order to make this work, the part of the TSOP containing the 2bl must be valid. The rest can be corrupted.
Second, the Xbox kernel embedded in the tsop_recovery BIOS must be packed as such as the 2bl contained on the TSOP will be able to unpack it. It needs to be encrypted using the same key contained in the 2bl and packed archive must be at most the same size as the stock kernel (because size of the packed image is contained in the 2bl itself and thus cannot be changed on the fly).

Since Evox M8 X2 5xxx and some later BIOSes radically changed how the Xbox kernel is packed (because they use a custom 2bl, I don't know why...), you cannot use the current tsop_recovery images to repair a corrupt TSOP that contain either of those. My theory is you could make it work if you'd manually pack a tsop_recovery BIOS containing the magic 2bl and a packed kernel that was packed using evox's 2bl "standard". So far, I have not been able to make this work. I have not dissassembled this evox 2bl to see how it ticks but there is something fishy going in there when it comes to unpacking the kernel.

My guess is this TSOP recovery process takes advantage of a manufacturing loophole set in place in the MCPX to easily flash the Xbox TSOP through the LPC port while on the asembly line, or during QA testing. There is probably a way to send a signal to the MCPX in order to fully control that loophole but I guess nobody ever found it.
It's quite common practice in electronics manufacturing to automate flash programming while in production. Coupled with the fact that in this case, this process must remain hidden away from the public, finding how to trigger it is always a challenge or takes a really long time to figure out. Just look at the Pandora Battery exploit on PSP or the PS3 jailbreak dongles in the early days of PS3 hacking. Both were likely purposedly put in place in order to facilitate programming in production or service them in repair centers.





I wonder will it be possible to create a solution to repair all the xboxs bricked tsop, such as creating a programmer that connects to directly into the LPC (something like the jr programmer on xbox 360 rgh) and thus repair or flash the tsop?
it would be possible to create programmer with arduino to flash or repair tsop?
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

1.0-1.5 TSOP recover BIOS: tsop_m7.bin

Post by Archive » June 26th, 2019, 7:55 pm

posted by Bad_Ad84 on Jan 22, 2019:

You can pull the tsop out and reflash it. Pretty sure the eprom method works on a tsop in any state too.

Regarding just programming from the lpc port - as above the method to make this happen is unknown currently.
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

1.0-1.5 TSOP recover BIOS: tsop_m7.bin

Post by Archive » June 26th, 2019, 7:55 pm

posted by bennydiamond on Jan 22, 2019:

Bad_Ad84 said:






Pretty sure the eprom method works on a tsop in any state too.

Yep, the 29-wire mod with a switch that toggle between the DIP flash chip and the TSOP's "CE" pin will enable you to recover a TSOP regardless of the content of it.

Did it many times when trying to test TSOP recovery feature of XBlast!
 

User avatar
Archive
Posts: 891479
Joined: June 25th, 2019, 11:00 am

1.0-1.5 TSOP recover BIOS: tsop_m7.bin

Post by Archive » June 26th, 2019, 7:55 pm

posted by jimmsta on Feb 14, 2019:

More likely than not, the reason why Evox used their own 2bl is because the keys that sign the 2bl are unknown. You can compile a patched kernel, but re-packing it is the problem, as the normal 2bl's keys aren't available to re-sign the kernel image. There's also likely a better way to handle the compression of the kernel, which can only be implemented in the 2bl. Microsoft used LZ compression, taken from the CAB format. Evox likely used something with a little higher compression ratio, which would allow them to add larger patches to the kernel (I don't know if they actually did so or not).
 

Locked