X360 Backwards Compatibility, '*Technical* speculation' :p ;) Options

[PedrosPad]

Hmmm. Always one to enjoy shooting down my own theories...

This text file, discovered on the "Experience XBOX 360" Kiosk disk, is thought to be a list of the contents of the Flash memory. It appears to show that the patch files are applied to the files in the Flash memory, and not dynamically applied on load (check out the file lengths of the *.xex and their *.xexp1 counterparts). Not necessarily conclusive proof, as we don’t know the origin/history of the text file (DevKits may work differently for example), but certainly not 'theory supportive' . - oh well.

This may not necessarily kill the dynamic merging of the *.xexp files idea completely, as it's currently my only theory to explain by the \Partition 2\Compatibility\xbox.xex, and xefu.xex files are unchanged by their *.xexp files shipped in the BC update. (We know these HDD-based files are still used for BC, as when Angerwound deleted them, BC broke!)

CODE

Xenon target system 65.52.238.80 (65.52.238.80)

Drive FLASH is an Unknown Volume

Directory of flash:\

               0 File(s)             0 bytes
09/06/2005  03:30p             397,312 bootanim.xex
09/06/2005  04:02p             401,408 bootanim.xexp1
09/06/2005  03:30p              81,920 connectx.xex
09/06/2005  04:02p              81,920 connectx.xexp1
09/06/2005  03:30p              40,960 createprofile.xex
09/06/2005  04:02p              32,768 createprofile.xexp1
09/06/2005  03:30p           2,596,864 dash.xex
09/06/2005  04:02p           2,318,336 dash.xexp1
09/06/2005  03:30p                 256 dashboard.xbx
09/06/2005  03:30p              20,480 deviceselector.xex
09/06/2005  04:02p              16,384 deviceselector.xexp1
09/06/2005  03:30p              69,632 feedback.xex
09/06/2005  04:02p              45,056 feedback.xexp1
09/06/2005  03:30p             110,592 friends.xex
09/06/2005  04:02p              90,112 friends.xexp1
09/06/2005  03:30p              77,824 gamerprofile.xex
09/06/2005  04:02p              57,344 gamerprofile.xexp1
09/06/2005  03:30p             126,976 hud.xex
09/06/2005  04:02p             110,592 hud.xexp1
09/06/2005  03:30p              77,824 huduiskin.xex
09/06/2005  04:02p              77,824 huduiskin.xexp1
09/06/2005  03:30p             143,360 marketplace.xex
09/06/2005  04:02p              98,304 marketplace.xexp1
09/06/2005  03:30p              36,864 mfgbootlauncher.xex
09/06/2005  03:30p              36,864 minimediaplayer.xex
09/06/2005  04:02p              32,768 minimediaplayer.xexp1
01/01/1601  00:00a               1,536 MobileB.dat
01/01/1601  00:00a                 512 MobileC.dat
01/01/1601  00:00a                 592 MobileH.dat
01/01/1601  00:00a                 529 MobileJ.dat
09/06/2005  03:30p             409,600 processdump.xex
09/06/2005  04:02p             409,600 processdump.xexp1
09/06/2005  03:30p              28,672 quickchat.xex
09/06/2005  04:02p              24,576 quickchat.xexp1
09/06/2005  03:30p                  29 recint.ini
09/06/2005  03:30p             257,636 recovery.ttf
09/06/2005  03:30p           1,233,340 rrbkgnd.bmp
09/06/2005  03:30p             921,656 saferec.bmp
09/06/2005  03:30p              49,152 signin.xex
09/06/2005  04:02p              36,864 signin.xexp1
09/06/2005  04:02p             322,768 sysupdate.xexp1
09/01/2005  05:13p              16,384 testxex.xex
09/06/2005  03:30p              20,480 updater.xex
09/06/2005  04:02p              20,480 updater.xexp1
09/06/2005  03:30p             114,688 vk.xex
09/06/2005  04:02p             110,592 vk.xexp1
09/06/2005  03:30p              86,016 voicemail.xex
09/06/2005  04:02p              86,016 voicemail.xexp1
09/06/2005  03:30p           1,236,992 xam.xex
09/06/2005  04:02p           1,216,512 xam.xexp1
09/06/2005  03:30p              36,864 xapi.xex
09/06/2005  04:02p              36,864 xapi.xexp1
09/06/2005  03:30p              36,864 xapid.xex
09/06/2005  03:30p             102,400 xbdm.xex
09/06/2005  04:02p              98,304 xbdm.xexp1
09/06/2005  03:30p             405,504 xbupdate.xex
09/06/2005  04:02p             303,104 xbupdate.xexp1
09/06/2005  03:30p           1,159,168 xenonclatin.xtt
09/06/2005  03:30p           1,736,704 xenonjklatin.xtt
09/06/2005  03:30p             589,824 ximedic.xex
09/06/2005  04:02p             589,824 ximedic.xexp1
09/06/2005  03:30p           9,183,232 xlaunch.fdf
09/06/2005  03:31p              92,672 xlaunch.strings
09/06/2005  03:31p           1,318,912 xshell.xex
09/06/2005  04:02p           1,318,912 xshell.xexp1
               0 dir(s)              0 bytes free

This post has been edited by PedrosPad: Mar 22 2006, 12:46 PM

[PedrosPad]

Ok, I restored the Virgin X360 HDD image, and then installed the Dec 05 BC update from DVD-R. I then diffed the Virgin & updated HDD images. The only differences in the 20GB HDD images are additional directory entries for the two new folders ( \$systemupdate\ & \$titleupdate\), entries for the 2 files they contain, and the file contents themselves. Nuffin else. I had 4 partitions on the Virgin HDD, and same four on the updated HDD.

But when I try to play BC title Fable with the Virgin HDD, I'm requested to install BC updates. My best guess is that it's the contents of the \$titleupdate folder it's looking for. Are you XBL guys who play BC titles sure you don't have an \$titleupdate folder?

I revisited this test last night.

My X360 is now running D/K:2.0.2241.0 (nothing I can do to revert that ), but I did restore the X360 HDD to the Virgin HDD state. Tried to boot Fable - failed! (as expected and as above).

I then used Xplorer360 to inject just the \$titleupdate folder from the Dec 05 BC update (which contains a single PIRS archive of xbox.xexp, xefu.xexp, and xexfu2.xex) onto the X360 HDD. Booted Fable, and it worked fine.

I then experimented with removing and renaming others xex files thought to be part of the BC functionality and witnessing the effects. I found that altering any of the files broke BC support. So, in conclusion, on my PAL X360 D/K:2.0.2241.0 configuration, the following HDD-based files are mandatory for BC functionality (this list is not exhaustive, these are just the ones I tampered with):

CODE

\Device\Harddisk0\Partition2\Compatibility\xbox.XEX
\Device\Harddisk0\Partition2\Compatibility\xefu.XEX
\Device\Harddisk0\Partition3\$titleupdate\fffe07d2\tu********* - The Dec05 PIRS archive containing xbox.xexp, xefu.xexp, and xexfu2.xex)

It’s a curiosity that Angerwound doesn’t have the $titleupdate folder on his X360, and can play BC titles successfully.

As DaBiscuit suggested

I'd guess the next step in the process is to discover if there are any other differences between an XBL-updated HDD and a manually-updated HDD.

IIRC I believe Angerwound only got his X360 recently, and would have plugged into XBL ASAP and got the latest updates. These means that his first update would have taken his D/K from D:2.0.1888.0 directly to either D/K:2.0.2255.0 (the XBL update from January 30, 2006), or even directly to D/K:2.0.2258.0 (the XBL update from March 2, 2006).

Maybe M$ have changed the location and/or operation of the BC functionality in these later OS updates? (maybe it’s been moved into the Flash?), or, BC updates installed via XBL live somewhere else on the X360 HDD?

Angerwound did inform me that he has see both su* and tu* PIRS archives in his X360 HDD’s Cache partition/folder. I’d be interested to know if this is the new home of the active BC PIRS archive, but surprised if it were, given that the nature of cached data is transitory. This could be tested by first seeking and locating a tu* PIRS archive that contains the xbox.xexp, xefu.xexp, and xexfu2.xex files (note that other title update 'tu*' PIRS archives have been seen that contain updates to other software, e.g. COD2 updates), delete the BC one, and see if BC still works.

This post has been edited by PedrosPad: Mar 26 2006, 04:14 AM

[PedrosPad]

I'd guess the next step in the process is to discover if there are any other differences between an XBL-updated HDD and a manually-updated HDD. This whole thing doesn't make sense otherwise.

I'm going to revert my HDD back to its virgin state, and take it over to my brothers on the weekend. He's a keen XBL player, so his X360 will already be at the latest OS. I'll let XBL update my HDD to get BC working, bring it back, and diff it to the image of the Virgin HDD. We'll see what that reveals.

This’ll be the first time I've attempted to move the HDD between X360 units. I’ve read mixed messages on whether this works or not. Obviously at retail, the add-on HDDs have no knowledge of what X360 unit they’ll get attached to. But unsure whether they get ‘bound’ to a specific X360 unit on 1st usage? Guess I’ll find that out categorically also.

This post has been edited by PedrosPad: Mar 24 2006, 10:21 AM

[Angerwound]

Angerwound did inform me that he has see both su* and tu* PIRS archives in his X360 HDD’s Cache partition/folder. I’d be interested to know if this is the new home of the active BC PIRS archive, but surprised if it were, given that the nature of cached data is transitory. This could be tested by first seeking and locating a tu* PIRS archive that contains the xbox.xexp, xefu.xexp, and xexfu2.xex files (note that other title update 'tu*' PIRS archives have been seen that contain updates to other software, e.g. COD2 updates), delete the BC one, and see if BC still works.

I've removed the su* tu* files from my cache partition and used BC without problems. I in fact removed the entire contents of the cache partition with no adverse effects toward how BC works.

As you mentioned above, I did directly upgrade to the latest kernel/dash version via one xbox live update.

[PedrosPad]

I've removed the su* tu* files from my cache partition and used BC without problems. I in fact removed the entire contents of the cache partition with no adverse effects toward how BC works.

As you mentioned above, I did directly upgrade to the latest kernel/dash version via one xbox live update.

None of the files identified as being involved with BC are particularly lengthy. I wonder if they've simply moved them in the Flash on the latest OS?

Am I right is thinking there's an 'initialise disk' command in the X360 dashboard (under memory management? )? If so, it'd be interesting to see what it erases (which partitions, etc.), and what it leaves. This could provide a cleaner 'baseline' HDD image, making any deviation from baseline easier to spot.

Angerwound, I wonder if initialising the disk will finally cripple your unshakeable BC support?

This post has been edited by PedrosPad: Mar 24 2006, 02:52 PM

[PedrosPad]

I'm going to revert my HDD back to its virgin state, and take it over to my brothers on the weekend. He's a keen XBL player, so his X360 will already be at the latest OS. I'll let XBL update my HDD to get BC working, bring it back, and diff it to the image of the Virgin HDD. We'll see what that reveals.

This’ll be the first time I've attempted to move the HDD between X360 units. I’ve read mixed messages on whether this works or not. Obviously at retail, the add-on HDDs have no knowledge of what X360 unit they’ll get attached to. But unsure whether they get ‘bound’ to a specific X360 unit on 1st usage? Guess I’ll find that out categorically also.

Success . Moving the X360 HDD between consoles caused no issues. It simply works just like moving a MemPak between units would. My HDD-based profiles showed up on my bro's X360 unit. I've read that any premium XBL content reverts to 'trial' mode, but I didn't have any of that.

As I suspected/hoped, my bro's X360 was already at the latest OS level (D/K:2.0.2258.0), but even so it still wanted to download an update in order to play the BC title Fable.

Examining the X360 HDD after accepting the BC update revealed approximately 6 new files in the \Partition3\Cache folder - all but one of these were short (only 2k) files with the word "PROD" in bytes 4-8, the last one was a PIRS archive with contents identical to the Dec05 BC update $titleupdate one, except for header being “LIVE” & its certificate. These files must only be transitory.

The only other file altered was my profile file (a CON flavor PIRS archive). It grew by about 8k by the addition of another *.GPD file (bringing the total to 3 *.GPD files). *.GPD files begin with the signature bytes XDBF (Xbox DataBase File ).

From this evidence, I have to conclude that with D/K:2.0.2258.0 the updates to BC are no longer persisted to the HDD .

This post has been edited by PedrosPad: Mar 26 2006, 05:12 AM

[StrictPuppet]

IIRC it is the nature of Flash memory that it can only be reflashed a finite number of times. Erasing it all and updating it for each update to the Operating System could head toward that limit (how frequent are Windows updates? - lol ).

Often the actual changes to the files are minimal. By using dynamically loaded 'patch files', M$ is able to leave the entire base 2.0.1888.0 OS in the Flash untouched, and only needs to burn these small patch files into subsequent Flash memory areas. Preserving the rewrite limit for when it might be needed.

An analogy could be a multi-session CD-R. You might ‘replace’ a file previously burnt to the media in a later session. Obviously the disk space the actual file occupied can’t be revisited/reused, but the updated directory written in the later session, further down the disk, ensures that the latest version of the file is predominant.

Of course, you can rewrite Flash memory, but why do so (and thereby reduce its lifespan) if you don’t need to?

I got to thinking about this....and the number of program/erase cycles are a little higher than perhaps you may have expected.

The article that AnandTech wrote about the 360 shows an image of the flash on the motherboard
http://www.anandtech.com/systems/showdoc.aspx?i=2611&p=3

It uses a 128meg Hynix flash ram HY27US08281A

The datasheet can be found on Hynix's website---> http://www.hynix.com/datasheet/eng/flash/d...Y27US08281A.jsp

DATA INTEGRITY
- 100,000 Program/Erase cycles
- 10 years Data Retention

Even for MS, this should be able to handle enough updates

[BlueCELL]

I like your research and your theories that you mentioned in the first couple of posts makes sense of the libraries and then having a db file to block/enable specific games. Great Job so Far!

Success . Moving the X360 HDD between consoles caused no issues. It simply works just like moving a MemPak between units would. My HDD-based profiles showed up on my bro's X360 unit. I've read that any premium XBL content reverts to 'trial' mode, but I didn't have any of that.

As I suspected/hoped, my bro's X360 was already at the latest OS level (D/K:2.0.2258.0), but even so it still wanted to download an update in order to play the BC title Fable.

Examining the X360 HDD after accepting the BC update revealed approximately 6 new files in the \Partition3\Cache folder - all but one of these were short (only 2k) files with the word "PROD" in bytes 4-8, the last one was a PIRS archive with contents identical to the Dec05 BC update $titleupdate one, except for header being “LIVE” & its certificate.

The only other file altered was my profile file (a CON flavor PIRS archive). It grew by about 8k by the addition of another *.GPD file (bringing the total to 3 *.GPD files). *.GPD files begin with the signature bytes XDBF (Xbox DataBase File ).

From this evidence, I have to conclude that with D/K:2.0.2258.0 the BC files are no longer stored on the HDD.

Are you saying that techincially you dont need a HDD to play XBOX1 games on the 360? Could it be that they require the HDD for the cache data? Which I sort of doubt because the Xbox360 has 512mb RAM, which should be plenty for the game (64 MB ram in XBOX1 + Emulating software + Cache (for some games)).

Can you send me the XDBF file you have? I want to take a closer look at it.

BlueCELL

[StuMan1337]

Success . Moving the X360 HDD between consoles caused no issues. It simply works just like moving a MemPak between units would. My HDD-based profiles showed up on my bro's X360 unit. I've read that any premium XBL content reverts to 'trial' mode, but I didn't have any of that.

As I suspected/hoped, my bro's X360 was already at the latest OS level (D/K:2.0.2258.0), but even so it still wanted to download an update in order to play the BC title Fable.

Examining the X360 HDD after accepting the BC update revealed approximately 6 new files in the \Partition3\Cache folder - all but one of these were short (only 2k) files with the word "PROD" in bytes 4-8, the last one was a PIRS archive with contents identical to the Dec05 BC update $titleupdate one, except for header being “LIVE” & its certificate.

The only other file altered was my profile file (a CON flavor PIRS archive). It grew by about 8k by the addition of another *.GPD file (bringing the total to 3 *.GPD files). *.GPD files begin with the signature bytes XDBF (Xbox DataBase File ).

From this evidence, I have to conclude that with D/K:2.0.2258.0 the BC files are no longer stored on the HDD.

So, now that you have the virgin HD + the updates obtained by plugging your HD into your brother's xbox, can you play XBox1 games on your 360?

[PedrosPad]

None of the files identified as being involved with BC are particularly lengthy. I wonder if they've simply moved them in the Flash on the latest OS?

Am I right is thinking there's an 'initialise disk' command in the X360 dashboard (under memory management? )? If so, it'd be interesting to see what it erases (which partitions, etc.), and what it leaves. This could provide a cleaner 'baseline' HDD image, making any deviation from baseline easier to spot.

Are you saying that techincially you dont need a HDD to play XBOX1 games on the 360? Could it be that they require the HDD for the cache data?

Sorry, the top line of mine quoted above wasn't very clear . Angerwound said here that certainly the BC files xbox.xex & xefu.xex are still executed from the X360 HDD, even on his D/K:2.0.2258.0 configuration! So the question returns to simply "how are the updates to BC implemented/stored on OSes >D/K:2.0.2241.0 that don't use the \Partition3\$titleupdate folder?"

I've no immediate plans to update my X360 OS further (I didn’t really want it updated at all ), so I'm personally unable to investigate this further.

I did restore my X360 HDD back to Virgin HDD state, and test out the X360 Dashboard's 'Memory Format' command on the HDD. All this command appears to have done is clear out the \Partition3, leaving the partition with only an empty \Cache folder, and a "\name.txt" file (which simply contains the text "Hard Disk"). The other partitions (including \Partition2\Compatibility - which contains xbox.exe & xefu.xex) were not effected.

It'd be interesting to know if BC titles still work on a D/K:2.0.2258.0 configured X360 with a 'formatted HDD'. Angerwound?

This post has been edited by PedrosPad: Mar 26 2006, 05:57 AM

[PedrosPad]

I got to thinking about this....and the number of program/erase cycles are a little higher than perhaps you may have expected.

Yeah , I kind'a had my doubts on its plausibility even while writing that. I'm a long time & heavyweight Flash KeyDrive user and have never experienced any rewrite issues. I was just coming up with theories to help in the description of the observations. Heck, got’a start somewhere.

This post has been edited by PedrosPad: Mar 26 2006, 05:31 AM

[PedrosPad]

So, now that you have the virgin HD + the updates obtained by plugging your HD into your brother's xbox, can you play XBox1 games on your 360?

My working theory is that the updates to the BC were stored in the Flash firmware on my bro's X360 D/K:2.0.2258.0 unit, so I'd expected BC to fail now that the HDD is now back in my D/K:2.0.2241.0 unit. But then there was that persisted update to my profile file .....I'll try it out.

[Angerwound]

With our current theory; we have discovered that only xbox.xex and xefu.xex being used on the harddrive for backward compatibility titles. I'm not sure why they didn't make these flash native files and execute them from there. Adding a bit more security? Of course, the hard drive IS needed for BC to function. The /partition0/xbox* folders (legacy xbox cache partitions), and the st.db for previous music collections.

Thinking a bit more on the legacy cache partitions. Most games required most if not all of 1 or 2 partitions. How is it possible that BC is possible with a memory unit? Is it possible? The memory unit wouldn't be near big enough.

Pedro: I will run your tests before I head to bed tonight. Will post results soon.

This post has been edited by Angerwound: Mar 26 2006, 07:17 AM

[BlueCELL]

With our current theory; we have discovered that only xbox.xex and xefu.xex being used on the harddrive for backward compatibility titles. I'm not sure why they didn't make these flash native files and execute them from there. Adding a bit more security? Of course, the hard drive IS needed for BC to function. The /partition0/xbox* folders (legacy xbox cache partitions), and the st.db for previous music collections.

Thinking a bit more on the legacy cache partitions. Most games required most if not all of 1 or 2 partitions. How is it possible that BC is possible with a memory unit? Is it possible? The memory unit wouldn't be near big enough.

Pedro: I will run your tests before I head to bed tonight. Will post results soon.

How big are those xbox.xex and xefu.xex files? Also would you know how big the cache partitions on XBOX1 are? (to lazy to look but wasnt it like ~700mb?)

[PedrosPad]

How is it possible that BC is possible with a memory unit? Is it possible? The memory unit wouldn't be near big enough.

Nope. X360 BC needs the HDD - to act as the XBOX1 HDD.