[PC] Tokyo Xanadu eX+ ".bra/PDA" Archive Container Format

var prgmr == true;
var i = int;
for (i = 0; i < prgmr.knwldge; i++) {
prgrmr + i";
}
Post Reply
sewer56lol
Posts: 2
Joined: Sat Jun 17, 2017 12:19 pm

[PC] Tokyo Xanadu eX+ ".bra/PDA" Archive Container Format

Post by sewer56lol » Sun Dec 10, 2017 10:44 am

Just a quickie for anyone interested, as I'm still to play the game for the first time so I've no intentions of going any further than this (although I did already check all of the test levels, unfortunately Aksys did not localize them :/).

I got my hands on the game yesterday morning, a bit late to the party (as I've forgot about the release till I was reminded) and after a few hours of poking around (and criticizing the bad format), I've got the game data extracted without a hitch or any particular issues.

Here's a quick breakdown of the badly defined archive format used for Tokyo Xanadu eX+, it's not perfect but you probably also could write a packer with this:

Code: Select all

// File Header Section (0x10)
string headerTag; // Constant: PDA (Null Terminated)
uint32 compressionType; // Presumed to be this. Value is constant 2
uint32 fileEntryOffset; // Offset relative to start of file to the end of compressed file data after the header.
uint32 fileCount; // File count
    
// Raw Data Section (Variable Length), Files consist of a 0x10 header & raw compressed data.
uint32 uncompressedSize; // Size expected after decompression.
uint32 compressedSize; // Size of compressed data after this header.
byte[8] unknown; // Sometimes 0, not a pointer/offset.
byte[x] compressedData; // Raw compressed data. Compression type is deflate. (Might be deflate64, I didn't verify, works under both).

// File entry section (immediately succeeding compressed data), variable length, repeated fileCount times.. 
time_t archiveTime; // C Time format. Appears to be the time the file was last packed/modified in the archive. Archive appears to be one of type that is built from scratch but files are simply updated and pushed in, potential for lots of unused goodies.
uint32 unknown; // The purpose is unknown.
uint32 compressedSize; // Same as in the file entry, except including 0x10 header.
uint32 uncompressedSize; // Same as in file entry, size post decompression.
uint16 fileNameLength; // Length of file name, including junk terminators.
uint16 fileFlags; // ? Seem to be flags, cannot tell as of yet, proper investigation was not made.
uint32 fileOffset; // Offset to the Raw Data Section for this file, relative to start of file.
string fileName; // Name of the file, lesser or equal to the fileNameLength field.
byte[1-3] shitPadding; // Literally what the name implies and the awful part of this format. Rather than null terminating strings and having the length correctly explicitly defined, the format pads the end of the file name with random junk data (which changes every time file name length changes) until the combined length of both the name and the junk is integer divisible by 4.
I wrote a quick parser and extractor which will let you get a hold of the game data for the people's game digging and wiki fetishes. File layout and engine internals are a slightly newer version/iteration of Cold Steel II's.

Notably some filenames for old and marked as unused files are also badly defined and would not extract to storage (I've seen 3 instances of this), the exporter sanitizes all file name outputs such that these files could also be extracted.

Usage:

Code: Select all

dotnet Xanadu-BRA-Decompress.dll <BRA Archive> -t
You may remove the "-t" argument which trims extension length but because of the badly defined file naming with random padding, your result may not be that of what you might expect (bad extensions).

Source: https://github.com/sewer56lol/Xanadu-BRA-Decompress
Download (Binary):
Xanadu-BRA-Decompress.7z
(5.64 KiB) Downloaded 18 times

The application is a .NET Core 2.0 program, you might require the runtime: https://www.microsoft.com/net/download/windows
Last edited by sewer56lol on Sun Dec 10, 2017 11:35 am, edited 3 times in total.

sewer56lol
Posts: 2
Joined: Sat Jun 17, 2017 12:19 pm

Re: [PC] Tokyo Xanadu eX+ ".bra/PDA" Archive Container Format

Post by sewer56lol » Sun Dec 10, 2017 11:20 am

Not to clutter OP, here's some extra stuff.

I did try to port the Xanadu models to CSI PC as part of my model swap shenanigans, however it seems that the model formats are not binary compatible, even after changing a field I've identified as the Phyre version. It's possible that Xanadu either uses Phyre model features unavailable in Cold Steel or that the .DAE/Collada specification was since updated.

There isn't really anything open source to work with the .Phyre container for models and I'm lazy to reverse the format from scratch myself (in CS1/CS2 I could get perfect model swaps without having to touch the model files, much).

As expected with usual Falcom stuff from my own experience, there is someone already out there who has the knowledge and/or has either the tools or source to work with the formats (and probably doesn't want to share), thus reverse engineering the model formats from scratch would be a waste of time for the short term gain of my occasional "meme-ing".

Other formats are compatible though and with a bit of fun, I've no problems with making monstrosities such as this: Image

I've also made a listing of each of the archive information, hopefully this should prove useful to someone.
It's pretty awesome to see files date back to 2014 after Cold Steel II's launch.
The format is: Name, Date, Compressed Size (including Header), Uncompressed Size.

(I've compressed it as the text files are too powerful for pastebin and attachments wouldn't allow me to post text files)
Attachments
ArchiveDetails.7z
(93.56 KiB) Downloaded 11 times

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest