The reason I’ve never previously discussed the Xbox save signing procedure in public is concern that by doing so would negatively impact Xbox Live.  Now that the original Xbox and it’s games are unable to access the Xbox Live service the following information is relatively harmless.

A brief history

The original Xbox used digital signatures to validate not only executables it was loading but save data, with this it was impossible to change or tamper with a save without updating the file’s digital signature using the correct key.  This key was generated using data contained within the default.xbe and a key used by the Xbox Operating System.  The save data was then run through a SHA1 HMAC routine and the 20 byte result appended to the save data to confirm integrity. This result, or digest, was usually found at the beginning or the end of a file although it can potentially be located anywhere in the file if the developer was feeling adventurous.

Obtaining the XBE key

Each Xbox game has a default.xbe file, this is the executable that is loaded whenever you start a game. It contains various information including the title ID, age rating, game region and the all important signature key.  Don’t get confused, this is not the key used to sign the saves but is an essential piece in the process.
The first step is to obtain the key directly from the XBE. This is stored in a certificate area of the file, the address of which is located in the XBE header. Before we can retrieve the key we need to define the structure of the XBE Header and the Certificate data we will be retrieving:

// XBE sections
unit xbestruct;
 
interface
 
type
ByteArray = array[0..15] of byte;
 
type
TxbeHeader = record
	m_magic : cardinal;                    // magic number [should be "XBEH"]
	m_digsig : array[0..255] of char;      // digital signature
	m_base: cardinal;                      // base address
	m_sizeof_headers : cardinal;           // size of headers
	m_sizeof_image : cardinal;             // size of image
	m_sizeof_image_header : cardinal;      // size of image header
	m_timedate : cardinal;                 // timedate stamp
	m_certificate_addr : cardinal;         // certificate address
	m_sections : cardinal;                 // number of sections
	m_section_headers_addr : cardinal;     // section headers address
	m_init_flags : cardinal;
	m_entry : cardinal;                         // entry point address
	m_tls_addr : cardinal;                       // thread local storage directory address
	m_pe_stack_commit  : cardinal;                // size of stack commit
	m_pe_heap_reserve : cardinal;               // size of heap reserve
	m_pe_heap_commit  : cardinal;                 // size of heap commit
	m_pe_base_addr : cardinal;                   // original base address
	m_pe_sizeof_image : cardinal;               // size of original image
	m_pe_checksum : cardinal;                // original checksum
	m_pe_timedate : cardinal;                   // original timedate stamp
	m_debug_pathname_addr  : cardinal;            // debug pathname address
	m_debug_filename_addr : cardinal;           // debug filename address
	m_debug_unicode_filename_addr : cardinal;   // debug unicode filename address
	m_kernel_image_thunk_addr : cardinal;        // kernel image thunk address
	m_nonkernel_import_dir_addr : cardinal;      // non kernel import directory address
	m_library_versions : cardinal;               // number of library versions
	m_library_versions_addr : cardinal;          // library versions address
	m_kernel_library_version_addr : cardinal;    // kernel library version address
	m_xapi_library_version_addr : cardinal;      // xapi library version address
	m_logo_bitmap_addr : cardinal;               // logo bitmap address
	m_logo_bitmap_size : cardinal;               // logo bitmap size
end;
 
pTXbeHeader = ^TXbeHeader;
 
type
TxbeCertificate  = record
	m_size : cardinal;                          // size of certificate
	m_timedate : cardinal;                     // timedate stamp
	m_titleid : cardinal;                       // title id
	m_title_name : array[0..63] of widechar;                // title name (unicode)
	m_alt_title_id : byteArray;            // alternate title ids
	m_allowed_media  : cardinal;                 // allowed media types
	m_game_region  : cardinal;               // game region
	m_game_ratings  : cardinal;                  // game ratings
	m_disk_number : cardinal;                   // disk number
	m_version : cardinal;                       // version
	m_lan_key : byteArray;                 // lan key
	m_sig_key : byteArray;                  // signature key
	m_title_alt_sig_key : array[0..15, 0..15] of byte;     // alternate signature keys
end;
 
pTxbeCertificate = ^ TxbeCertificate;
 
implementation
 
end.

The TxbeHeader record contains a lot of data but the two most important sections are m_certificate_addr, and m_base.  These two values give us the address of the certificate.

The following code retrieves the key from an XBE file:

var
    MS : TMemoryStream;
    xbeHeader : pTxbeHeader;
    xbeCert : pTxbeCertificate;
begin
 
    MS := TmemoryStream.Create;
    MS.LoadFromFile(FileName);
    new(xbeHeader);
    new(xbeCert);
    //Read in header and certificate
    MS.Read(xbeHeader^, sizeof(xbeHeader^));
    MS.Position := xbeHeader^.m_certificate_addr - xbeHeader^.m_base;
    MS.Read(xbeCert^, sizeof(xbeCert^));

We can now access the sig_key directly

xbeCert^.m_sig_key

Generating the signing key

The key we retrieved from the XBE is not used to directly sign save data, instead it is used in a SHA1 HMAC with the Xbox key to produce the actual key we need. Thankfully we don’t need to determine the Xbox key every time we need to sign or verify a save as it is a constant.

The following is a textual representation of this key, to use it you must first convert it to a 16 byte array:

5C0733AE0401F7E8BA7993FDCD2F1FE0

Once you have this key in a byte array simply run both the XBE key and the Xbox key through a SHA1 HMAC (referring to the documentation for your SHA1 HMAC function as to whether you need to pass data or memory addresses to the function). The output should be a 160bit digest truncated to 16 bytes (the last 4 bytes are not required and should not be used or present).

var
    digest : T160BitDigest;
begin
    digest := CalcHMAC_SHA1(addr(xboxKey), 16, xbeCert^.m_sig_key, 16);

Determining the data to process

As noted before the digital signature is usually found before or after the actual save data.  It is entirely possible to store this signature at any location in the file and treat this location as all 0′s during the HMAC process.  Since we cannot rely on all developers using the same location for the signature we must determine the location ourselves.

The fastest and easiest way to do this is to start a new game and make a save at the earliest opportunity.  If the game saves any options you change this is ideal, otherwise start playing and save as soon as you can.  Copy this save to you PC and label is SAVE A.

Load the game again and create another save with as small a difference as you can but ensuring something is different.  As before, if the game saves option changes you should change only a single item and re-save. Copy this save to your PC and label it SAVE B.

Open both saves in a hex editor and visually compare the two, with little differences between them you should easily spot the 20 byte digital signature either at the start or the end of the file.  You can use an automatic file comparison if your editor supports it but in my experience I can find the sig faster by eye.  The signature in both files should be wildly different with the actual save data very consistent, aside from the minor differences you saved earlier.

Once you have found the sig location you should exclude this from the HMAC routines.  If the sig is at the end of the file you should HMAC all data up to the last 20 bytes, if it is at the beginning then all data after the first 20 bytes should be processed.  If the signature is located at another location in the file then you will need to experiment as to what data to HMAC.  A common trick when generating checksum’s is to treat the area containing the result of the checksum as all 0′s during the processing stage and write the result back to this location once complete.  Please note, it is rare to see this, most saves store their signature at the beginning or end of the file.

Generating the signature

Now you have the correct key and the data to process you can generate or check signatures for that particular games save files.  Similar to how the key was generated, the actual signature generation is a SHA1 HMAC of the save data (excluding the existing signature) with the key.

In the following example the save signature is located at the end of the file and the data is copied to a different memory stream for processing. The previously generated key is stored in a 16 byte array named sigKey

mem := TMemoryStream.Create;
mem2 := TMemoryStream.Create;
mem.LoadFromFile(FileName);
mem.Position := 0;
mem2.CopyFrom(mem, mem.Size - 20);
digest := CalcHMAC_SHA1(addr(sigKey), 16, mem2.memory^, mem2.size);

Before making any changes to a save you should confirm that the signature you generate matches that already present on an unaltered save.

It’s worth bearing in mind that a lot of saves contain a checksum as well as a digital signature.  The most common being a CRC32 or a simple addition of bytes, you must recalculate this before the digital signature should you make any changes to the file.

Conclusion

The process of creating a digital signature for Xbox saves is fairly simple and can be summarized as

• SHA1 HMAC “XBE key” using “Xbox key”
• Truncate resulting 160 bit digest to 16 bytes to create the “signature key”
• SHA1 HMAC Save data using ”signature key”
• Compare resulting 160 bit digest to existing signature or write back to save file.

If you use the information above to create anything or produce a unique save, drop me a line in the comments, sometimes the most interesting time in a games life is long after it was released..

Criterion Games have taken the Burnout World and turned it into a free roaming sandbox game but since this is a driving game don’t expect any GTA style escapades. This new style in itself isn’t too bad but some seriously bad design choices have been implemented:

No retstarts.

Criterion boasted that this wouldn’t matter as there will always be other events near by. But it does matter Criterion. When doing a Burning Route, having to drive for 5 mins to get back to the start just because you crashed once is not fun. When you are trying to do the last few activities in the game to complete your licence, driving back for 5 minutes back to the race you just failed is not fun. Even Rockstar realised that the GTA series needed a quick way to get back to a mission you failed and introduced taxi cabs as restarts. Games are meant to be fun remember Criterion?

1 crash and you’re out!

During many of the later Burning Routes and races, once single crash is all it takes to be left so far behind that there is no point in continuing. This is not fun Criterion. I’ll give it another shot when I fail but when you punish me needlessly I start thinking about trading your game in for something fun.

You’ve just crashed, lets see that in slow mo and waste 5 seconds!

Like the boring relative who comes round to show you 500 holiday photo’s, Criterion decided that since they had spent so much time on the crumple/crash physics (instead of making the game fun it would seem) that they would show you it at every opportunity. You wish for an option to turn this off after 30 minutes of first play and what makes it worse, you can actually lose races due to this ‘feature’.

I need a navigator!

Practically any race is 10% driving, 90% pausing to look at the map! Let us set waypoints so we know when a turn is coming up and plan our own routes. This is not a fun way to race! If you try to use the mini-map you will end up crashing into any number of cars and walls and don’t forget, more than 1 crash and you may as well forget the later races. Turns come up so fast that most of the time you will not see them until you’re way past them and the turn indicator is useless and distracting when planning your own route.

Don’t look at a curb!

The game seems so desperate to show me it’s crash engine that on several occasions it has crashed me when I was nowhere near a curb, wall or car. I sat there in disbelief as my car crumpled on the edge of a tiny railing that I wasn’t near and wouldn’t expect to damage my car in the first place.

What do you mean you want to see the road ahead?

In what can only be thought of as some kind of punishment, the default camera angle is far too low to the ground. This may mean you get a better feeling of speed but it also means that the road ahead is often a mystery until you end up face first into a wall, car or speck of dirt that causes you to crash. heaven forbid you think to activate your Burnout along the road of random death. You can raise the camera angle but only by holding up on the right analog stick, without some sellotape this is an impossible task when racing! The only other view available is a first person one and the less said about that the better.

Now Burnout Paradise is fun at times, but there’s just too much wrong with it at a basic level. This is the sort of game that appeals to car fanatics, Burnout Brand Slaves and submissives who love being punished. A patch is forthcoming by the sounds of it, lets hope Criterion address some of the major problems with this game and give us the Paradise that it so wants to be.

As for me, I’ll keep plodding along with it, for all the stress it causes and poor design there’s a fun game in there fighting to get out. Online can be a lot of fun and there’s a definite feeling of satisfaction when you beat a friends time on a road. This is probably Burnout’s saving grace but it relegates what should have been a first class game to a nice, but sometimes uncomfortable, second class.

Yes, I know it sounds like a good idea, the two bases next to each other so you can kill the other team grab their flag and score within minutes. However, if you move your Elephant to the other side of the map and the other team kill you, then you start spawning on the far side of the map, a long way away from the action and your flag! All you do is allow the other team to get you flag very quickly and end the match in record time.

By all means move the Elephants next to each other, but bring the other team’s Elephant to your base

On an unrelated note, my Memor32 was delivered today. I’ll be putting it through it’s paces over the next few days and a comprehensive review will be posted over at PS2 Save Tools

The console manufacturers want you to upgrade. The games publishers want you to upgrade. The third party software/hardware developers want you to upgrade. Your old games console is obsolete and you should be playing the latest and greatest on something that costs the about the same as 100 visits to the cinema or a feast fit for a king.

As time passes the old file formats get abandoned, superseded with newer formats for new software and machines.

I would like to see software developers and hardware producers open up these archaic file formats to the public. They’re not going to loose any money from it and it may even rekindle some interest in their particular device or software.
Many file formats are already cracked, but having the offical specifcations and internal structures would allow utility makers to polish their code, finish features and more.

Playstation 2 saves

Playstation 2 saves come in many different formats, most have been cracked by talented individuals such as Vector who created PS2 Save Builder. However some formats, notably .max and the newer Xploder save format, remain barely documented and to this day, people still cannot support these formats in their tools.

Releasing these specifications to the general public would allow those utility makers to support that format natively, instead they ultimately recommend alternative formats, which are now fully documented, such as the once barely known .psu save format. uLaunchELF has recently added .psu support to it’s feature list which has resulted in an upsurge of .psu format saves being used and new utilities to be released

Is it too early to release the file specifications for formats such as .max to the public? Probably. Would it affect sales? At this late stage it’s hard to tell.

One thing I do know is that my choice of products to purchase, and to recommend to others, is heavily influenced by the file format used, specifically if it is open or unencrypted. If it is encrypted or purposely protected in such a way as to stop people sharing, or creating utilities, I will look around for other products and recommend others do the same

Should legacy formats still be secret? I don’t think so and would like to see more developers giving the information to the communities built around their product rather than gathering digital dust on some developers long forgotten hard drive.