Capcom Arcade Stadium 1 and 2

[shawngmc]

While I've added placeholders, CAS 1 and 2 aren't yet implemented. Investigation notes go here.

Analysis

KPKA

These appear to be KPKA archives, and it is reasonably certain that the extraction is correct, as most files have a 3-4 character allcaps header indicating file type.

Example KPKA (1556708)

• 1556708_0_1957557.dat - One of the ROM packages
• 1556708_1_331.dat - has '.psb' at the beginning, but does not appear to be a valid M2 MArchive/PSB Archive
• 1556708_2_1976307.dat - One of the ROM packages
• 1556708_3_150.dat - Small MAME file describing ROM name?
• 1556708_4_138.dat - Small file of null bytes
• 1556708_5_667.dat - SCN file - Scene description?
• 1556708_6_3828.dat - Moderate MMAC file listing ROM file names and possible keys?
• 1556708_7_26.dat - Very small MMAC file

PSB

In the example above, 1556708_1_331.dat appears to have ".psb" at the beginning; however, this doesn't match what we know about the PSB filetype.

• If this was an uncompressed PSB file, we would expect the first three bytes to be "PSB"
• If this were a compressed PSB file, we would expect the first three bytes to be a compression type indicator, like "mdf"
• We have no current indication M2 (which makes the m2engage emulator and MArchive file format) worked on CAS
• MArchiveBatchTool can't seem to do anything with the file.
• The file is far shorter than most PSB files. As such, this is likely a coincidence or other dead end.

[TheNametag]

The depot version says it is supported, but when I attempt to use cas1_old I get an error message that the metadata.json is not found. Nor do I see it in the source files.

[RealRelativeEase]

The depot version says it is supported, but when I attempt to use cas1_old I get an error message that the metadata.json is not found. Nor do I see it in the source files.

I didn't get any of the DLC games, but gextoolbox extracted a folder titled 1943u.zip from the depot, and it plays fine in an emulator.

[xperia64]

I did some digging into the new format, and the protection on these files is semi-simple. There are two steps, and while neither are great, ironically it's the second one that significantly weakens the first.

Each zip file has been mangled into its own container of sorts; semi-randomly padded with 0xFF and a few seemingly control bytes that seem to either replace/further compress the data in some way (e.g. some repeating bytes may be missing when compared to the older or console releases); every 16 byte chunk of the file is then XOR'd with a fixed value that is unique per file.

While working with these files, I extracted them using QuickBMS which provides nicer file extensions at the moment.

I have not determined how the keys are supposed to be derived, but currently they can be derived directly from at least most files I've looked at:

1. Locate a large .dat file that corresponds to a mame zip
2. Look for repeating or mostly repeating 16-byte sequences in the .dat file in a hex editor 2.1. Larger titles appear to have these sequences at or near the top of the file 2.2. The sequence will always be 16-byte aligned 2.3. Some sequences may be trickier to figure out than others; consider 00000002.dat from Savage Bees (Exed Exes); here, the key can be derived from offset 0x2240; note the partially repeated data before and after the key
3. Take the 16-byte sequence you found, and XOR each byte with 0xFF
4. For each byte in the file, XOR that byte with the key indexed to the current index % 16
5. Save the modified data, you should notice some plaintext filenames and pkzip structures with some junk data

Descrambling the extra junk data is where I'm currently stuck. Junk data will frequently begin or end with a non-0xFF byte which presumably tells the descrambler what to do, and I'm not sure what that is.