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

[sewer56lol]

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 1502 times

The application is a .NET Core 2.0 program, you might require the runtime: https://www.microsoft.com/net/download/windows

[sewer56lol]

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:

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)

[MVegeta]

The tool proved to be very helpful to me with the exception of not being able to extract the actual 3d models from the game (.dae.phyre files). However, you have my thanks and sincere appreciation for working on the .bra files extraction regardless and I'm hoping that one day, you'll further develop it.

[sewer56lol]

The tool proved to be very helpful to me with the exception of not being able to extract the actual 3d models from the game (.dae.phyre files). However, you have my thanks and sincere appreciation for working on the .bra files extraction regardless and I'm hoping that one day, you'll further develop it.

Apologies for taking this long to reply, I have quite long lost any motivation when it comes to anything Falcom, even if I didn't really do that much in the first place apart from reversing a few formats here and there and writing tools for those.

I did at one point look into .dae.phyre and its texture counterpart but with due time, lost the motivation to do so knowing that there wouldn't be much use for my reverse engineering efforts:

1. The Kiseki community doesn't seem very interested in mods from my own experience.

2. I didn't really have the motivation to look into the basics or commonly used components of the COLLADA .dae format such that I could fully distinguish what belongs to PhyreEngine and what is not.

3. There are people that do actual reverse engineering of Falcom stuff, some of them are members here but as you might know, this site is a bit inactive. Problem unfortunately lies in the fact that nobody documents their work and neither is there a place for anybody to really do so. I've found myself before working on various things which have already been done by someone else but have never told the world about it. Working, pointlessly on things that others have already done is rather demotivating.

There's also the fact that about half of my Kiseki reverse engineering stuff has merely been for meme purposes such as the posting of unusual images, etc. The other half was just some classic TCRF style research but I've lost the motivation for that.

Although for the format you speak of, someone else was willing to pick up the challenge a while ago, think January or February (I'm quite disconnected from the community).

Seek a person named uyjulian, he's pretty good with reversing file formats and has taken on this challenge himself, while I cannot give guarantees regarding how far he's come, I'm pretty certain that with his skills, model exports are (probably) already a thing by now. If they are a thing, feel free to give him this utility and/or a model dump of some Xanadu models, I'm sure that if he's motivated enough, he'll figure something out for you.

Sorry about that :/

Note: Reason I'm saying "Kiseki" is that the community for the two games is more-less one and the same.

As an addition, the underlying engine under this game is a tweaked up and altered version of the engine seen in Cold Steel II. There will be a few minor differences in the files of course such as PHYRE version but CSII's work could probably be pretty easily translated onto Xanadu.

[MVegeta]

I understand and thank you for taking the time to explain things in detail, I highly appreciate it.

It's quite alright though because since I first sent you a reply to this thread, I've discussed some things with some people who are interested in mods, I studied the format a little bit myself and finally, with the help of a friend at Xentax, we were able to successfully view and extract all of Tokyo Xanadu's models. From characters to entire maps, everything can be extracted now.

Despite what I just mentioned, I should thank you nonetheless. If it weren't for your threads and kind/detailed replies on this and other forums, I properly wouldn't even be interested in this.