Patching Beta Live Games

So technically, this should be possible, according to conversations a few years old. Am I correct in thinking I should be looking at the Entry Point, and the Kernel Image Thunk Address?

The XBE don't seem to open in any programs, which was to be expected since they are a bit unusual. Although there is a possibility there was an error copying from my disk, which wouldnt surprise me entirely. (Edit: Did get it to load in a program, which is good)

Anyone care to get me started?

 

Someone once took a look at the XBE for ReVolt I had put up here a while ago. He took a crack at it starting with a hex editor and looked for hooks that didn't exist in ReVolt but apparently did in halo 2.

Beyond that I'm useless.

 

Yeah Im just kind of stabbing in the dark here, its tough. My brief and probably incorrect understanding is that I should start at these two points.

Edit : Looking at the source code to a Debug / Retail xbe patcher, I seem to be in the right spot anyway.

Edit 2 : The other issue is going to be not knowing the Beta Key to be able to sign it. So who wants to help me figure out how to get that key?

 

The difference between debug, retail and chihiro games is mainly that the debug games use different XOR keys.

static const uint32_t XOR_EP_DEBUG = 0x94859D4B; /*!< Entry Point (Debug) */
static const uint32_t XOR_EP_RETAIL = 0xA8FC57AB; /*!< Entry Point (Retail) */
static const uint32_t XOR_KT_DEBUG = 0xEFB1F152; /*!< Kernel Thunk (Debug) */
static const uint32_t XOR_KT_RETAIL = 0x5B6D40B6; /*!< Kernel Thunk (Retail) */

These are the keys for the normal xbox. The chihiro keys are also floating around and from what I remember they are different for the firmwares and games.

So to convert a debug application to retail you must first XOR the kernel thunk table address from the header with XOR_KT_DEBUG, then XOR it again with XOR_KT_RETAIL. The same applies to the entry point address using the other keys.

Furthermore the retail versions of games are signed using a private key only known by microsoft (and to my knowledge a few other people who may or may not know about it because the private keys were leaked (accidentally) in another leak).

I'm not sure what exactly you are trying to accomplish here though.
The COMPLEX kernels will do the XOR'ing on their own.
Signing / running the games on a retail xbox (without mods) is probably impossible unless the private key and signing procedure is found.

If the beta games used a different XOR key you'd probably want to check the kernel (which must have came with it) to find the key.

 

Beta Live Games are indeed different, and will not run on any modified BIOS in their current state. As you said, both addresses need to be XOR'd, where we don't currently have the key to do so, but with my talks with another member, there is also another problem to explore as there is code that makes a retail console FRAG (Really, its an orange and green/red flashing, I cant remember, so not a real frag heh).

 

If you could provide me with an XBE or two I could have a look.
I was also able to patch away SCSI disc checking in retail games.
I believe I'm rather experienced with this stuff by now.

 

Here is a link to the demo that was included on a disk:
http://ptoponline.com/NFLFever2003.rar

It is from a PAL Beta Live game. Link will be good for a max of a week, probably less.

 

0x46437DCD (kernel thunk table could be 0x12000) should be kernel thunk table XOR (looks wrong (lots of low level file IO) but couldn't find anything better yet)
0xE682F45B (entry point is probably 0x2ED137) should be entry point XOR (very sure about this one)

I did not try to verify my findings yet by patching / running it. However, if you do you should also patch it to run on all media if your xbox kernel doesn't do that (COMPLEX will do). Also, it's possible that it encrypts data using the XePublicKey. That is probably different than on retail builds. You can probably find it by scanning the live beta kernel (or really just any file you can find for a REAL bruteforce attack):
Set a 32 bit word pointer to offset, then XOR offset[1] ^ offset[2] and compare the result to the entry point XOR key I posted above.
Once you found the correct address go back 128 bytes and that should be the beginning of the XePublicKey data.

 

I believe it has some other protection on it that prevents it from running on normal debug or retail (modded) consoles, as it causes them to flash orange (and red, I think). The bios for the kit, I was told, is closer to a retail kit than it is a debug kit, but I don't know. Someone else is also taking a look, they think that a beta live bios of some sort was shared privately, but I don't plan on opening mine up so.

 

Well.. if the XOR keys are wrong the xbox will try to access invalid memory in the xbe loader which could possibly result in the flashing led..
I just doublechecked the XOR keys I gave you and I'll write a tiny patcher tomorrow.

From what I saw, there is nothing special about the XBE.
The only problem, as I mentioned before, could be differences in the encryption keys for the xbox crypto library. However, that's a kernel related thing which can not be patched properly in the XBE.

 

My goal really is for it to run on debug or modded retail units. It's just weird since even an invalid XBE format would usually just reboot the Xbox. But Id appreciate a patcher, and then I could test it out and see what happens.

 

NOTE: Doesn't work yet!?

// Name: XBL Beta to Retail patcher
// Usage: ./this <in> <out>
// Author: Jannik Vogel

#include <stdio.h>
#include <stdint.h>

int main(int argc, char* argv[]) {

// Load input buffer

size_t length;
uint8_t* buffer;
{
FILE* f = fopen(argv[1],"rb");
fseek(f,0,SEEK_END);
length = ftell(f);
fseek(f,0,SEEK_SET);
buffer = malloc(length);
fread(buffer,1,length,f);
fclose(f);
}

// Make the keyed stuff addressable

uint32_t* ep = &buffer[0x128];
uint32_t* kt = &buffer[0x158];

// Un-xor entry and kernel thunk

*ep ^= 0xE682F45B;
*kt ^= 0x46437DCD;

// Print the actual values

printf("Entry point at 0x%08X, kernel thunk at 0x%08X\n",*ep,*kt);

// Re-xor entry and kernel thunk

*ep ^= 0xA8FC57AB;
*kt ^= 0x5B6D40B6;

//TODO: Patch the media type?

// Write to output file

{
FILE* f = fopen(argv[2],"wb");
fwrite(buffer,1,length,f);
fclose(f);
}


// Completed everything successfully

return 0;

}

I tested this by loading the new files in some XBE tools and all values I checked were as expected. I also ran it in my emulator and it got stuck in the XDK CRT which is normal (because my emulator sucks). I then tested it on one of my actual xboxes but it did not work. However, I couldn't get the original to flash my led either. Both just seem to hang.
I had similar problems with Virtua Cop (Chihiro) before though on this particular xbox.
It might just be my kernel screwing up the media type patch.
So if you could test this for me that would be appreciated.

 

Ill double check that the XBE flashes things when I can. It should, since it was the same format as the actual disk, but who knows. I've tried some normal patching programs, but they didn't do the job either.

 

Old thread, but I like this. So I ask, did a solution came alive?

 

Nothing :\

 

They must be all different if Re-Volt was patched/cracked successfully. :/

 

Revolt wasn't patched. It was built from the source code which leaked using assets from the retail beta live disk I believe

 

Oh so it was re-compiled XBE? Interesting.

 

The whole game was compiled, not just the XBE The only thing used from any disk were the assets, since they weren't included in the source package.

 

Interesting, these type of things need to be documented more often.