default.xex

[Vampire]

As you may know, to update the Xbox-emulator on your Xbox 360, you can download a file from http://www.xbox.com/en-US/games/backwardscompatibility.htm and burn it on a CD or DVD.

The file is called default.xex and is inside the http://assets.xbox.com/en-us/backwardcompatibility/default.zip ZIP-archive.

The xex-file looks similar to a xbe-file (and "xex" looks like a reversed "exe").

There are some interesting strings inside the file:
XEX2
UPDATES
MEDIA
\Device\CdRom0\default.xex
installupdate.exe
XRTLLIB
XAPILIB
LIBCMT
XBOXKRNL
D3D9
XUIRUN
XUIRNDR
XAUD
XGRAPHC
xam.xex
xboxkrnl.exe

And there seems to be a digital signature of 256-bytes locatet from offset 0x00000110 to 0x00000210.

The part from offset 0x00002000 to 0x0025B800 seems to be encrypted.

[Arakon]

what's interesting is that the game support for almost 200 games is in a 2.5MB file.. that definitely speaks against the theory that the "emulator" just uses recompiled xbox 1 xbes.
it would also point at the emulator not being too game specific.. i.e. eventually creating a somewhat universal data file or adding support for games yourself would be possible.

[QuiescentWonder]

I seem to know everything in the wrong fields for this kind of thing. Is the XEX a self-extracting archive of some sort that includes all those files? Does it just include patches for those files or are they entire files?

I'm so curious but I don't seem to know enough to be helpful. Want I really want to do is learn. I mean, I could have found all those strings, but the digital signature and what is encrypted are beyond me.

[oskie]

And there seems to be a digital signature of 256-bytes locatet from offset 0x00000110 to 0x00000210.

The part from offset 0x00002000 to 0x0025B800 seems to be encrypted.

I don't know too much about the original xbox's XBE file format (yet), so I'm just guessing here. What makes you think there's a digital signature at 0x110? It seems likely though. What doesn't seem all that likely to me is that there would be encrypted data at 0x2000. I don't think there would be much point in encrypting data in the xex file. Perhaps it's just compressed data. I believe it is - the unzipped default.xex is 2473984 bytes and the zipped archive is 2467196. This leads me to believe that the default.xex contains much compressed data already.

Also I don't think this default.xex contains the complete emulator - after all it's just an update (according to the link). So perhaps the data at 0x700 to 0x2000 is some kind of directory index?

Oskar

[twobombs]

Encrypted data compresses bad, especially with a long keylength
So being able not to compress a lot indicates the presence of encrypted data.
A decompiler should also display garbage (as it's encrypted)

[th0mas]

(as it's encrypted)

Compressed data also compresses badly.  There is no proof yet that it is encrypted, so don't rule anything out without proof.

[twobombs]

it would be infinitely stupid when m$ would release X360 code into the wild without encryption as this code will most definately have copyrights and will contain certain secrets and/or exploitable hooks inside the code. I also don't see a header for compression (even though a compression header is not 100% nessesary, I know ) The old xbox xbe's were also encrypted, m$ *must* encrypt their code....  a large chunk of the security system of the xbox1 was build around this.

[th0mas]

it would be infinitely stupid when m$ would release X360 code into the wild without encryption as this code will most definately have copyrights and will contain certain secrets and/or exploitable hooks inside the code.

Uhm.. not really.  The .xex file contains a cryptographically signed hash of the remainder of the file.  So.. there aren't any exploitable hooks since we can't change the code.

I also don't see a header for compression (even though a compression header is not 100% nessesary, I know )

Doesn't mean it's not compressed (just like you said).

The old xbox xbe's were also encrypted, m$ *must* encrypt their code....  a large chunk of the security system of the xbox1 was build around this.

Wrong, wrong, wrong.  Go read up on xbe file format.  The XBE's are cryptographically signed, but not encrypted.  If you don't clearly know the difference then don't continue posting.  I'm sure XEX files also contain an authenticated hash of the remainder of the file.  It served it's purpose well.

I'm not saying that they aren't encrypted.  They very well may be.  What I'm saying is that there is no proof that they are, and that much of your evidence is purely fiction.

[twobombs]

  twobombs slowly awakes from his hybernation sleep whilst hammered upon by th0mas

Update from frontpage:
The emulator for first generation games can be updated via an official Microsoft download burned to CD by the user, though the CDs' content will be encrypted and signed with public key cryptography. source: http://www.free60.org/wiki/Main_Page

[tjfontaine]

has anyone setup tcpdump to grab the default.xex live downloads to update backward compat?

[th0mas]

These aren't the emulator updates per se, but they're similiar.. xbox live marketplace packages.

http://forums.xbox-scene.com/index.php?showtopic=462911

[tjfontaine]

ya, I updated that thread with the info that free60 has found so far.

but with regards to this topic it would be dually interesting if we could get our hands on the .xex that live distributes for backward compatability updates to check for differences in the files (that presumably) do the same thing just come and run from different places.

for that matter just being able to see the differences between two very similar .xex's would help in understanding the file format.

[th0mas]

There appears to be a table starting at 0x28c.  Each entry is 24 bytes.  This is the table (bytes in big-endian.. I'm assuming?)

Code:

0x00000103 0xf256f5aa 0xd97dfd82 0xbd1d26b0 0x5ecf87a3 0x6d650e27
0x00000101 0x0a6c8b1d 0x567870ce 0x25078769 0xf10aa4b9 0x54b89976
0x00000101 0xea1170d3 0x6b32ac9c 0x11591006 0x39a32c3e 0xdcbf77a3
0x00000101 0x7ff5cb75 0xe8b3a685 0x449f6889 0xcba5385a 0x1ddac291
0x00000101 0x95ce15ae 0x21d35d3f 0x71ed8d03 0x20e8ccbc 0xcf0fb5c9
0x00000101 0x9a2f1af7 0xa78b00f1 0x955bf2be 0x28303cfe 0x8c507f8f
0x00000101 0x21a5fcd9 0x35edca13 0x2656535a 0x43076c8b 0xb3f4fe31
0x00000101 0x71e83f13 0x03019316 0x5fc197bb 0xfaa27a9b 0xefd22d7d
0x00000101 0xbc3ab871 0x77c558b5 0x7009c1f9 0x57bac276 0x9509108a
0x00000101 0x102f796f 0x762689ea 0x40391bce 0x5868f10a 0x247e0f4b
0x00000041 0x0e6f641e 0x81296366 0xb8f1ac9f 0x7e09b90f 0x55cd9785
0x00000072 0xa7a922ba 0x4ea80eb8 0x524ff2ee 0xe92f0a3b 0xe5c98fc1
0x00000053 0x536bbcfa 0x94154421 0x715cee67 0x328e057b 0xe95c6912
0x00000103 0x0a09bc35 0x149c99fe 0xe2ebb76e 0xe01037e0 0x79d07251
0x00000103 0xf16969e6 0x924e1d7f 0xab0b80bf 0x63c44f16 0xdbc42c42
0x00000103 0x0c5e59b2 0xe6581b30 0x6c4134a3 0xb84a8596 0x749841d6
0x00000103 0x271188fc 0xcc9f67b5 0x4b61660e 0x3ff7c875 0x6411a81f
0x00000103 0x73bbf21b 0x28eaf000 0x8cbf941c 0x2328f0f8 0xbde44435
0x00000103 0x5b06f4bf 0x25cec689 0x2d707709 0xad03490e 0x5673b6f0
0x00000103 0x4119d436 0xcbbd25a6 0xd958a335 0x2012e714 0xef94dc66
0x00000103 0x7c2901fe 0xe55f6474 0xb94c1edf 0xc994dd88 0x499d966d
0x00000103 0xd09e1809 0xce8f0f6a 0xbb8261ff 0x62348d16 0x219bb3bf
0x00000103 0x93616614 0x5b929b49 0xbe590501 0x44ec6873 0x42605b6e
0x00000103 0x18e229c7 0x111a1c07 0x5c715f1e 0x9d6ef2f7 0xd4551ac8
0x00000103 0xc955fba2 0x96961d08 0x97af6159 0xf181d101 0x50659fa3
0x00000103 0x2c69bcba 0x528d87e5 0x192272cf 0x6b506584 0x459216ad
0x00000103 0x29b2540e 0xaea87e9d 0xc97cf264 0xc86c91cc 0x96eb1ecd
0x00000103 0xf0a5ba4e 0xefb538b5 0xe2a98b76 0xe124bdce 0x27f051e5
0x00000103 0x2f1d6597 0xaa4fec34 0x6383f135 0x9c550dd2 0xad0d11f7
0x00000103 0x36b4a8b6 0x311df430 0xf2190b4c 0x4adb9640 0xa48ae0a3
0x00000103 0x82f8213b 0x50b86f63 0x747eb7b4 0x6599b15e 0xc4fc5d3a
0x00000103 0xf2775751 0xe3253615 0x8073372b 0x804275fc 0x86bf92ad
0x00000103 0xa7220986 0xa2271478 0x3645cd24 0xdcf44fc8 0x4a3f5f09
0x00000103 0xb895cd6e 0xde7915d9 0xa87fdb39 0x4b49cba0 0xe8dfe1b9
0x00000103 0x72d996b8 0x16ce5e76 0x8f1f90ba 0xa81500e6 0xb62bb039
0x00000103 0x6d09d496 0x4333f641 0x9d091548 0x0ceb752d 0xfd72a31f
0x00000103 0x7f692b0a 0xd7c5e878 0xfc3969d6 0xbc90283f 0xe811df33
0x00000103 0xb985838d 0xd356e6f5 0x25872339 0xea27653c 0x92752d49
0x00000103 0x1829f079 0xd46deccb 0xfb965b64 0x694b6882 0x6792021b
0x00000103 0x503c9151 0xf9848e4c 0x65b4b5e9 0xccd5cf46 0x8d3a37c4
0x00000103 0xa654cf6d 0x2096c97a 0x1e86ba99 0xdc04f9b4 0xace07929
0x00000103 0x62bb0de5 0xabebeb52 0x1bf96ade 0xfb2fd74b 0xe26a3f34
0x00000103 0xcbe3b4ec 0x7f342e0a 0x231ba1b0 0x105c7e99 0xa8cc29da
0x00000103 0x15192982 0xee654322 0xd1d7305f 0xb94c5426 0xc4015fa3
0x00000103 0x2601f280 0xe00ab13a 0x7e9e820c 0x052855cd 0x9a19f640
0x00000103 0x64e48969 0xfb273aec 0xcfcc76ef 0x4cabf79d 0xcaebb975
0x00000103 0xfd584164 0x75872cac 0x8742e9ea 0x0793cfe3 0x8c7814a3

I used the following to extract it:
dumptable.c:

Code:

#include <stdio.h>
#include <string.h>

#define TABLE_START 0x28c
#define NUM_ENTRIES 47

struct table {
   unsigned int unknown[6];
};

unsigned int ByteSwap (unsigned int nInt)
{
   union u {unsigned int vi; unsigned char c[sizeof(unsigned int)];};
   union v {unsigned int ni; unsigned char d[sizeof(unsigned int)];};
   union u un;
   union v vn;
   un.vi = nInt;
   vn.d[0]=un.c[3];
   vn.d[1]=un.c[2];
   vn.d[2]=un.c[1];
   vn.d[3]=un.c[0];
   return (vn.ni);
}

void printTable(struct table *t)
{
   int i;
   for (i = 0; i < 6; i++) {
      int j = ByteSwap(t->unknown[i]);
      printf("0x%08x ", j);
   }
   printf("\n");
}

int main(int argc, char **argv)
{
FILE *fp = fopen(argv[1], "rb");
struct table tmp;
fseek(fp, TABLE_START, SEEK_SET);
int i;
for (i = 0; i < NUM_ENTRIES; i++) {
     fread(&tmp, sizeof(struct table), 1, fp);
   printTable(&tmp);
}
}

[tjfontaine]

Interesting, perhaps that will jive with the new info I just posted about the xex being more similar to an archive file format, see http://www.free60.org/wiki/BackwardsCompatability

[th0mas]

perhaps the later 20 bytes in each table entry is an SHA-1hash?

[norder]

I noticed that there are 5 (out of total 47) 0xA3 in the last byte of each entry. should i be surprised for this fact? 

it's sound like you go to a class of 50 people, and found FIVE of them have the SAME BIRTHDAY, wow!

[Dark_Neo]

While it is interesting that there is indeed a repeating 24 byte pattern, it doesn't look like a table to me. Tables would have some sort of index, I can't see any evidence of that. Most of the entries start 0x00000103 or 0x03010000 (depending on which endian you want to read it as) some of them are 0x00000101 with a couple random numbers. Don't get me wrong, it's a good find and should be looked into, but I don't think we're looking at a table unless th0mas is right about the last 20 bytes being a hash, and maybe the first four are the type of hash applied?

[th0mas]

All I have are random conjecture, no actual proof or anything.  That being said, the data is open to interpretation.  Like all the other data in the file, they have a meaning.  I'm just guessing .  I'd assume that if the data WAS the output from a hash, that maybe each entry corresponds to a file that is in the compressed archive?  Something like filetype/filehash?  No real clue here..

I don't know enough about standard archive file formats so I don't really know what are the usual data structures found in the files.

[Dark_Neo]

Actually let me just rephrase what I said, I don't think it's a lookup table, for finding the files, or describing them. However you could very well be right that it's a list of file types/hashes. Do we know how many games this emulator patch is supposed to support?

[th0mas]

Your guess is as good as mine

Here's more details on the file format.  Note that, since I'm only looking at one instance of the format, and any all of these offsets could be coincidence.  It will only be by comparing a large number of these filetypes that we can actually derive information.

Note that it does appear that the data is stored in big-endian format.  I think it'd be too much of a coincidence for that to not be the case.

0x08 - points to beginning offset of (compressed or encrypted) data (in this case, 0x2000)
0x10 - points to start of "certificate"? - 2 words before what was previously considered the signature of the file.
0x14 - number of entries that immediately follow.  Each entry consists of two uint_32's.  The first could potentially identify what the entry means? In either case, the second uint is often a pointer to a specific peice of data contained in the header of the file, and I'll use the first uint to identify each entry.  Pretty much all of this is conjecture and unknown .

0x000002ff - points to a section of data at 0x70c that has the strings $UPDATES and
             MEDIA.. possibly referenced directories?

0x000003ff - points to section starting at 0x730, judging by surrounding entries
             to be 36 bytes long

0x000080ff - points to section at 0x754, and is 0x20 bytes in length (judging by next entry)
             
0x00010001 - doesn't point to an offset in the file. (0x00400000)

0x00010100 - doesn't point to an offset in the file (0x920127f8)

0x00010201 - "" "" (0x92000000)

0x000103ff - points to 0x1b74, ?? contains strings- "xam.xex xboxkrnl.exe",
followed by.. well, something.

0x00018002 - points to 0x0774, which is 8 bytes long (judging by next entry)

0x000183ff - points to 0x077c, string "installupdate.exe"

0x000200ff - points to 0x0794, a list of libraries?

0x00020104 - points to 0x0828, some data. 16 bytes until next table entry

0x00020200 - 0x00010000.

0x00040006 - points to 0x0838, 16 bytes.  very similiar to the entry at 0x0828

0x00040404 - 0x0850 - block of nulls until 0x1b74.