I have also added file lists for other games to the zip (thanks RandomTBush @ xentax) plus added the missing files to the COTM1/COTM2 lists
(also just posted this on xentax)
Hello everyone, I managed to find out very little information about these games from the interwebs, so maybe someone will find this useful.
Here's a tool for decrypting/encrypting (if you can really call it encryption, it's not using AES or any other real encryption algorithm) datafiles from COTM1 and COTM2. Not all files encrypted, and I think some are compressed in addition to being encrypted. It's a very simple single file C program, should compile and work fine with gcc, clang, msvc, pretty much anything.
It may also work for some other Inti Creates games, but I haven't tried.
I have no idea where the game code reads or calculates the keys for the "encryption algorithm", but it seems there are four different possible keys used with the same decryption code, one per data type ("obj", "bft", "set" or "scroll").
The same keys seem to work for both COTM1 and COTM2 on all platforms.
Also, in the PC versions of both games, the filenames have been obfuscated changing each file's name to the MD5 hash of the actual filename. It is possible to recover the original filenames by logging them as the game accesses them (by eg. hacking the binary to report them via OutputDebugStringA), or using file listings from console versions which don't have obfuscated filenames. Note that for some filenames, you'll need to add a platform specific "Win/" directory prefix before hashing the filename (on Switch, these files would be in an actual "NX/" subdirectory inside the romfs, for some reason there is no equivalent subdirectory inside the PS4 version's package).
Using these methods, I have recovered original filenames for all but two of the files in the the DataHash directory on PC for COTM2. (I played through the game multiple times taking different routes, but the logger didn't catch anything which would match those two when MD5 hashed, unfortunately it's not really feasible to brute force the remaining ones, at least not with only a single albeit reasonably powerful GPU, the filenames could be up to 20-30 characters or even more, and may contain at least lowercase and capital letters, numbers, underscores and a single dot.)
For COTM1, I have recovered 261 of 296 filenames based on file listings from console versions. I'll need to play through it a few times with a logger patched one day...
Next up is going to be figuring out the actual map and background graphics formats. I want to write a program which can show the maps.
Btw. if you want to look at them, use the "set" key for map*.stb files and "scroll" key for map*.scb files. *.osb files use the "obj" key.
The zip includes the encdec.c program and MD5 filename hash lists for COTM1 and COTM2.
oh yeah, if you rename map00.stb to map01.stb (look at the hash lists), you'll get a debug map (in both games) when you start the game! nothing that interesting or useful there, though.
edit: fixed the argv enum I added just before upload...
edit2: figured out how the keys are calculated, but i'm too tired to update the zip
Code: Select all
#define WTFSTRING "90210"
#define BASEKEY 0xA1B34F58CAD705B2LL
uint64_t type2key (char *type)
{
uint64_t key;
int i, l;
char buf[12];
strcpy(buf,type);
strcat(buf,WTFSTRING);
l = strlen(buf);
key = BASEKEY;
for (i=0; i<l; i++)
{
key += buf[i];
key *= 141;
}
return key;
}
gives correct keys for inputs "obj", "bft", "set" or "scroll"
(also, the bft key seems to be for the font data files)
edit3: the compression seems to be just regular zlib compression with a 4-byte header (int32) telling how much space to reserve for decompressed output.
yes!
I still don't know what the huge 0-byte fills at the end of those scroll/font datafiles are for though (nor the actual header & stage tile layout format)
I have tested decoding & re-encoding the map01 files with it and the game still loads it fine.
Next up will be figuring out the actual map formats...