feudalnate / Original-Xbox-Gamesave-Resigners

Miscellaneous gamesave re-signers for the Original Xbox
The Unlicense
19 stars 2 forks source link

Halo: CE Profile and Gametype XSaveSig resign information #4

Closed mmillar-bolis closed 2 years ago

mmillar-bolis commented 2 years ago

Hey there! I hope this is an appropriate way to submit information for your XSaveSig documentation.

Through some guess & check, I was able to figure out Halo: CE's file geometry for profile and gamesave data files.

[4D530004]
ID=4D530004
Title=Halo (Gametype)
SigKey=1F71DE93D52AADB19446D7494F731158
AuthKey=5770E155A1C75FA9830B141896544428
DataFile=blam.lst
DataOffset=0
DataLen=104
SigOffset=104

[4D530004_2]
ID=4D530004
Title=Halo (Profile)
SigKey=1F71DE93D52AADB19446D7494F731158
AuthKey=5770E155A1C75FA9830B141896544428
DataFile=blam.sav
DataOffset=0
DataLen=48
SigOffset=48

I have not been able to figure out the values for a campaign save (savegame.bin) as of yet. They're quite large but are invariably 3584K. Still, I hope the above information is helpful in some way.

feudalnate commented 2 years ago

Hey, any avenue someone wants go to get in contact is fine with me and thanks for the contribution. I'll test these out when I get the chance (as well as the Halo 2 section you provided) and I'll also have a look at the savegame.bin file to see what I can figure out

Can I ask which region(s) the XBE files were marked as (internally) that you grabbed the Halo 1/Halo 2 signature keys from?

Sometimes XBE files for a game released in different regions will have differing signature keys - I will have to have a look at those files as well to check if they all share the same signatures key if you haven't already done so (when I add a game to the list of XSavSig sections I'll generally check each XBE for a game in all the regions it was released - for completeness sake and so I don't need to circle back around to a game again)

Thanks again for contributing, you and anyone else is free to contribute to the list of resign.ini sections for XSavSig or request a section/signing tool and I'll do what I can to accommodate

mmillar-bolis commented 2 years ago

Ah, excellent point! I was definitely not thinking about regions when I submitted this. My reference was the initial retail release of the USA version of Halo: CE (and same with Halo 2). I definitely appreciate how meticulous you are, so to provide some reference data for you to check against, here's the additional .xbe info for the eight versions of Halo: CE that I could get my hands on:

Key Description
Title Halo
Release 1.00
XMID MS00402A (USA)
Region 1
TitleID 4D530004
SigKey 1F71DE93D52AADB19446D7494F731158
Key Description
Title Halo
Release 1.01 (GotY)
XMID MS00408A (USA)
Region 1
TitleID 4D530004
SigKey 1F71DE93D52AADB19446D7494F731158
Key Description
Title Halo
Release 1.02 (Greatest Hits)
XMID MS00409A (USA)
Region 1
TitleID 4D530004
SigKey 1F71DE93D52AADB19446D7494F731158
Key Description
Title Halo
Release 1.00
XMID MS00406J (Japan)
Region 2
TitleID 4D530004
SigKey 1F71DE93D52AADB19446D7494F731158
Key Description
Title Halo
Release 1.00
XMID MS00403E (Europe, Eng)
Region 4
TitleID 4D530004
SigKey 1F71DE93D52AADB19446D7494F731158
Key Description
Title Halo
Release 1.00
XMID MS00404E (Europe, Fr, De)
Region 4
TitleID 4D530004
SigKey 1F71DE93D52AADB19446D7494F731158
Key Description
Title Halo
Release 1.00
XMID MS00405E (Europe, Es, It)
Region 4
TitleID 4D530004
SigKey 1F71DE93D52AADB19446D7494F731158
Key Description
Title Halo
Release 1.00
XMID MS08701J (Asia, Zh-tw)
Region 2
TitleID 4D530057
SigKey FEFE53BC72E2E07444D1D318ACE06DAC

I'm still new at this, but at first glance, it seems as though developers only changed the SigKey when the TitleID was changed, but I can't be too sure about that. Nonetheless, I went ahead and tested each of these releases and it appears that the profile and gametype geometry is consistent across all versions. However, it would appear that the Taiwanese localization used a different TitleID and SigKey, so here's some additional XSaveSig information for that release:

[4D530057]
ID=4D530057
Title=Halo (Taiwan) (Gametype)
SigKey=FEFE53BC72E2E07444D1D318ACE06DAC
AuthKey=087F980482788FE539573697D7387BC2
DataFile=blam.lst
DataOffset=0
DataLen=104
SigOffset=104

[4D530057_2]
ID=4D530057
Title=Halo (Taiwan) (Profile)
SigKey=FEFE53BC72E2E07444D1D318ACE06DAC
AuthKey=087F980482788FE539573697D7387BC2
DataFile=blam.sav
DataOffset=0
DataLen=48
SigOffset=48

I'm still in the process of collecting data for Halo 2, but will add the information to that issue as soon as it's ready. :)

EDIT: I thought that I would add that I went ahead and also had a look at Halo beta builds 1749 (2001-08-15) and 2247 (2001-09-26). Here's some quick reference info for those:

Key Description
Title Halo
Release Build 1749
XMID N/A (DEBUG)
Region 7
TitleID 00000000
SigKey 54455354544553545445535454455354
Key Description
Title Halo
Release Build 2247
XMID N/A (DEBUG)
Region 7
TitleID 4D530004
SigKey 54455354544553545445535454455354

At least when it comes to debug builds, the TitleID could be just about anything, so forget about that hunch I had above, haha. The interesting thing about Build 1749 is that the save data structures appear to be the same as later builds, but at the offsets where the signatures should be, the data is only 4 bytes long. This does seem to still be important as modifying the data outright still causes a signature mismatch error in the debug log and the save data is automatically deleted by the game runtime. So I'm not sure yet what's going on there. The other funny observation about this build is that it doesn't seem to write savegame.bin yet.

By the time Build 2247 came around, signatures seemed to be the standard 20 bytes. As such, here's the relevant XSaveSig information:

[4D530004_3]
ID=4D530004
Title=Halo Beta 2247 (Gametype)
SigKey=54455354544553545445535454455354
AuthKey=0EAF8368D32192FCDA09CD69D5356DD2
DataFile=blam.lst
DataOffset=0
DataLen=104
SigOffset=104

[4D530004_4]
ID=4D530004
Title=Halo Beta 2247 (Profile)
SigKey=54455354544553545445535454455354
AuthKey=0EAF8368D32192FCDA09CD69D5356DD2
DataFile=blam.sav
DataOffset=0
DataLen=48
SigOffset=48
feudalnate commented 2 years ago

Looking over my own save data for Halo 1/2 and doing some quick checks, the XSavSig sections you wrote out seem like exactly what I would write as well so I've went ahead and added them to the collection page

I didn't include the alpha/beta build sections though because as you observed (and what I've observed also), it's not typical for debug builds of games to utilize the signature API for save data - my best guess for the 4 bytes you mentioned is that it's a placeholder 32-bit CRC they tacked on for quick integrity checking before switching it out in the retail build

You're first assumption about the TitleID/Title Signature Key being linked was actually correct, I mentioned region specifically in my initial reply because it's simpler to explain and a game being released in different regions is generally when a TitleID may get changed since a game being released in a different may have a different publisher, whether it be a subsidiary of the main publisher or otherwise. Seems in the case of Halo CE it was a completely different build of the game which makes sense considering the region you noted (likely a highly censored build of the game)

The 3 main uses for a TitleID for the original Xbox are:

  1. A catalog ID for Microsoft to track games released by specific publishers, a TitleID holds the abbreviation of the publisher name and the game release number. For example 4D530004 is MS-4, which is Microsoft game release number 4 (2 ASCII characters + 16-bit number)
  2. How folders get mapped to the running title on the Xbox. Using 4D530004 as an example, when you boot the game the kernel will map E:\UDATA\4D530004 to U:\ and E:\TDATA\4D530004 to T:\ which restricts a title to accessing it's specified area on the hard drive only (U:\ being user data (saves, profiles, etc.) and T:\ being title data (DLC/updates)) and any data in this area will be "signed" using the specific Title Signature Key assigned to the TitleID of the running title (if the developer chooses to use the signature API)
  3. Like I mentioned right above, a TitleID is used a sort of access restriction for areas of the hard drive but a .xbe file can also store up to 16 AlternateTitleIDs and AlternateTitleSignatureKeys, which can allow the running title to access other titles data on the hard drive (all of this TitleID/TitleSignatureKey stuff is to comply with certification)

The key you noted for the alpha/beta builds of Halo 1/2 is actually the placeholder/dummy key that get written to the XBE header for debug builds of .xbe files 5445535454455354544553545445535454455354544553545445535454455354 which if you were to open a debug .xbe file you can see it's actually TESTTESTTESTTESTTESTTESTTESTTEST in ASCII text - which is why I mentioned above that it's not typical for debug Xbox executables to utilize the signature API like a retail game might

I went on a bit there but I figured I'd explain some things in case you were interested in knowing. I appreciate you submitting all this and I also appreciate that you took the time to format it all neatly to make it easy to look over at a glace. For the savegame.bin for Halo 1, I believe from 0x4000 to EOF is encrypted (the absence of zeros is normally a give away and it has no sort of header to indicate compression but that could be possibility as well) and the fact that the file is exactly on a 0x4000 byte alignment makes me think the file gets loaded directly into memory since 0x4000 is the alignment of memory pages for the original Xbox, which makes my assumption of encryption even more plausible (since as a developer you would want to protect data you intend to load directly to the game like that). I will make a note to look into that specific file again but it's something I'll have to put on the backburner for a bit

mmillar-bolis commented 2 years ago

This is excellent! I'm definitely thankful for the explanation. I noticed the four byte repetition, but didn't think to check the text. I just assumed it's placeholder status had to do with the potential state of the XDK in the middle of 2001, but I have also never really scrutinized a debug executable before.

I knew about TitleID to user data mappings, but again never thought to translate the IDs to text. Also, thanks for cluing me in on the purpose of the AlternateTitleIDs and their keys. This makes so much sense!

As for the savegame.bin, I think you are exactly right. I was messing around with build 1749 again last night while learning some of the debugging interface for Blam. What this build seems to do is take core dumps of the map state (which I had to load manually to resume a game). Based on your observation, it stands to reason that they simply continued to use this mechanism for the bulk of their save file.

Also, it's no problem to me if you don't include the alpha/beta information. I was more trying to do my due diligence. Plus, markdown keeps much of my personal notes organized. Otherwise things just get too out of hand, lol!

I saw that you have updated XSaveSig.md. Would you like me to close out these issues?

feudalnate commented 2 years ago

It makes sense that state would get dumped and loaded from disk considering how accurate the Halo games checkpoints can be with things like exact number of alive/dead enemies, where weapons are on the map and how much ammo they have, etc. - a bit strange (and unsafe) to just simply dump raw memory though (if that's actually the case (but wouldn't be the first time I've seen this on original Xbox games))

I didn't mean to ignore your comment here I didn't get any notification for this, I do have email notifications set up so I'm not sure what happened sorry about that. I did make note to check out the save data again and grabbed a handful of various saves off the internet to add to my own for researching

I guess I'll close this for now and if I figure out anything interesting with the saves I'll come back and reopen this to get some information to you and you're free to do the same (I think you can reopen your own issue? I'm not very familiar with GitHub stuff tbh) or directly email me if you'd like. I appreciate the time you took to organize all your info, thanks again