Print

[Dark_Neo]

QUOTE(PedrosPad @ Jun 15 2006, 02:02 PM)

You probably want to start a new thread for this request.  But see my post here for my past thoughts on the idea.

I'm planning to start a new thread, but I'll be away next week so I didn't want to start a proper request yet.

Anyway back o/t:

CODE

0x000728-0x00072b (0x000004) ?ImageTimestamp      0x43278ab4   Wed Sep 14 02:28:04 2005
0x0006d0-0x0006d3 (0x000004) ?unknown             0x20075c00   2.0.1884.0
0x0006d4-0x0006d7 (0x000004) ?unknown             0x20075c00   2.0.1884.0
0x0006d8-0x0006db (0x000004) TitleId              0xfffe07d2   MS (internal)

Well I think we can safely say what those ?unknown values are
So what's the current hypothesis on how the backwards compatibility works? There's still the issue of what the Tdbx.db file is for. It makes sense for it to be involved in BC, but apparently it's not...it's too large to fit on the flash, so it's not redundant, so what on earth could it be? Even if it was critical to backwards compatability it still seems too large to be anything like libraries or anything else that could be required. I'm going to do some investigation into this file, see if removing it has any effect, or changing bytes in it.

[PedrosPad]

QUOTE(Dark_Neo @ Jun 15 2006, 03:28 PM)

There's still the issue of what the Tdbx.db file is for. It makes sense for it to be involved in BC, but apparently it's not...it's too large to fit on the flash, so it's not redundant, so what on earth could it be? Even if it was critical to backwards compatability it still seems too large to be anything like libraries or anything else that could be required. I'm going to do some investigation into this file, see if removing it has any effect, or changing bytes in it.

QUOTE(Angerwound @ Mar 20 2006, 02:40 PM)

My first test being the removal of the 'TDBX.db' file that was suspected to house Backward Compatibility information. Removing the file and executing a few legacy titles resulted in no problems. Each game booted and ran just fine. The two used were Halo 2 and Medal of Honor: Rising Sun.

[Dark_Neo]

Yeh I saw that, I meant if it has any effect at all, not just booting the games, since it must do something. Or maybe it's there for some future feature, I can't think what that could be though.

Here's the contents of my PIRS file in the $titleupdate\fffe07d2\ folder:


BTW any idea what the config.bin file is for in the compatability folder? it's mostly 0x00 bytes, with a bit of data in the middle...

[Dark_Neo]

Deleting the file doesn't cause a change is those version numbers, so I'm pretty sure updates must be written to the flash.

[PedrosPad]

QUOTE(ramzi22 @ Jul 7 2006, 03:06 AM)

Heres a TU file i found in \Partition 3\Cache\.  I have done all my updates through xbox live and i dont have any of the folders that start with $ on my hard drive.

If you do all your BC updates over XBL, the updates do indeed sit in your cache.  So the cache is a little more permanent than it's name implies.

QUOTE(Dark_Neo @ Jun 15 2006, 06:17 PM)

Deleting the file doesn't cause a change is those version numbers, so I'm pretty sure updates must be written to the flash.

My findings disagree.   If you delete the BC updates files from the cache, BC stops working and you're prompted to update BC.

[PedrosPad]

QUOTE(ramzi22 @ Jul 8 2006, 06:40 AM)

Has anyone looked into actually modifying the contents of a LIVE file?  I see extractors but no injects.

Injectors need to recalc the checksums/signatures.  Since the signing currently takes place within M$, there is no code to reverse engineer to determine the process/keys.

The exception to this are 'CON' dialect PIRS archives (used for themes, game saves, etc.).  These are generated within the console itself.  So everything needed to reverse engineer the process should be within reach.

[Dark_Neo]

QUOTE(PedrosPad @ Jul 7 2006, 11:31 AM)

My findings disagree.   If you delete the BC updates files from the cache, BC stops working and you're prompted to update BC.

Hmm, well then either one of two things is happening, either the version number is written to the flash, or another file on the hard drive, I'll do more investigation tonight.

[DR3AD]

QUOTE(Dark_Neo @ Jun 15 2006, 03:28 PM)

There's still the issue of what the Tdbx.db file is for. It makes sense for it to be involved in BC, but apparently it's not...it's too large to fit on the flash, so it's not redundant, so what on earth could it be? Even if it was critical to backwards compatability it still seems too large to be anything like libraries or anything else that could be required. I'm going to do some investigation into this file, see if removing it has any effect, or changing bytes in it.




QUOTE(Angerwound @ Mar 20 2006, 02:40 PM)

My first test being the removal of the 'TDBX.db' file that was suspected to house Backward Compatibility information. Removing the file and executing a few legacy titles resulted in no problems. Each game booted and ran just fine. The two used were Halo 2 and Medal of Honor: Rising Sun.
---------------------------------------------------------------------------------------------------------------------------

In regards to this I would belive the TDBX.db file to be a simple title database file for Backward Compatibilty. This is pure speculation at this point, but I believe the 2 games mentioned (HALO 2 and MOHA:RS) may have been working in BC at release.

 I am still not sure what the file would do but here is a though and my experience with a non BC game, and I will throw some more speculation about after I explain.

I recenlty purchased 2x non BC compatible games from Ebay (they were cheap and I am hoping eventually they will work, NFSU and BUFFY-original). I decided to put BUFFY into the XBOX360 anyway to see what would happen, even though I knew it wasnt on the compatible list.

Here is where it gets weird.

My eyes went wide with excitement when my XBOX360 decided to download updates. What I mean is this, at first it  says "game not supported", then it says "game may be supported with an update". I was already signed into live, and it said "updating please do not turn of console blah blah blah" . It actually DID SOMETHING, it looked like it was downloading a file, had the progress bar and took 2-3 mins to download an update . Here is the thing, whatever it downloaded did nothing, because the game still didnt work. The suprising thing was this was only a few days after I had gotten the Latest XBOX360 update via Live. Now somewhere else on these boards I read that the BC part wasnt complete on release. I havent recieved NFSU yet, but should be here any day now.

Now a few Possibilites-


WEIRD UPDATE
-The update was the rest of BC, this I will know as soon as NFSU gets here, because it shouldnt need to dl anything else (this game isnt supported)
-It wasnt an update, maybe the 360 phoned home to say "hey this guy tried buffy and it didnt work". Remeber alot of games work once another game is supported because of engine similarites etc. or it could be that they are keeping tabs of what XBOX1 games are TRYING TO BE PLAYED.

TDBX.db

- The TDBX.db file could be one of 2 things. a list of games or product id for games that you have tried in your box that arent supported yet, so that when you get another BC update that supports it,  it will say "hey buffy works now" which could explain why deleting it has no effect.

-It could be list of which games you have downloaded failed BC patches for.

just thoughts on this interesting subject, will see when i get NFSU and tell you results, in the meantime I gotta figure out how to image XBOX360HDD and everything so I can be of a bit more use than mere speculation.

BTW has anyone tried opening that file with a hex editor to see if it contains anything discernable?

I know it is probably useless for executing code, but non the less interesting, and good work guys