Research: 3DS BSCAR Format

[Pingus!]

The BSCAR format has been partially documented, and extraction of BCWAV's has been easily achievable. Despite these successes however, name preservation is destroyed in the process. In attempt to recover this, I've been looking into analyzing the missing bits of the archive to figure out the missing portions. The base research I took from here, but there are some inaccuracies in the written information. I've discovered little things along the way about this format:

- It's separated into partitions (Generally MAIN HEADER, STRG, INFO, + MAIN FILE (Which has "sub-file" partitions, which probably contain all the files of each type of format. Such as one for bcwavs, and one for another format etc.)

Main Header:

Spoiler

0x0 - long "CSAR" (Magic Word)
0x4 - short Endian Identifier 0xFFFE = Little Endian 0xFEFF = Big Endian
0x6 - short CSAR Header Size
0x8 - long Version ID
0xC - long Archive Size
0x10 - long Partition Count
0x14 - long partition header length
0x18 - long STRG Partition Offset
0x1C - long STRG Partition Length
0x20 - long unknown constant (?)
0x24 - long INFO Partition Offset
0x28 - long INFO Partition Length
0x2C - long unknown constant (?)
0x30 - long Main FILE Partition Offset
0x34 - long Main FILE Partition Length
0x38 - longlong Reserved Space(?)

STRG:

Spoiler

0x40 - long "STRG" Partition String identifier
0x44 - long STRG Partition Size
0x48 - long unknown
0x4C - long unknown
0x50 - long unknown
0x54 - long unknown
0x58- long # Of Files Referenced (Applies to inside + outside of archive)

Table #1:
- Each entry is 0xC in length

Structured as follows:
- long: entry start identifier
- long: file name relative offset (add 0x58 to that value to get the absolute pointer! Uncertain if this is the actual constant value across all archives, but it seems to be for whatever reason)
- long: file name length

Table #2:
Raw file names (Length corresponds to values in table 1)

Table #3: Unidentified. No clue what it does yet. It looks like it's used to link something to another something.

INFO:

Spoiler

- long "INFO" identifier
- long INFO size
- long Constant
- long INFO Header Size
-long constant
-11 unknown longs
- long Constant(?)
- 2 unknown longs
-First table Start(?)


There may be more to this header, but I'm uncertain where the first table data starts.

There looks to be Three tables. I don't know where the first one ends and the second one starts, but it seems to be this:
- The first one may be pointers to the STRG entries. Some values land me on the entry start value, so I think that's what it is.
UPDATE: There seems to be a noticeable pattern within the first table I think. Looks like a constant 0x00002200 followed by a value and 0x000022000 repeated again. I don't know how many times this appears, but it could be for all the files referenced(?) or maybe just the files referenced externally?

- The second one points to the data that immediately follows the raw file names. No clue what that does yet.
- The third one (the most interesting to me) is a list of all externally referenced files. I don't know what the data values between the names mean yet, but will get there after I handle the first two tables.

- Have not started researching the Main FILE partition as of yet.

Future developments and discoveries into this format I will post about below. If anyone has any interesting information to contribute, all help is welcomed. I've attached a few sample ones that I've looked at. If anyone could find a big endian BCSAR, that would be even more useful!


  BCSAR's.zip (Size: 670.43 KB / Downloads: 249)

---

Clarified INFO partition format in regards to header length:

MWORD long
Size long
constant long
header size long
constant long

[Pingus!]

Recently uncovered the location of the BCWAV's offsets and sizes within the archive. This is more information that would be useful for later on. The huge missing link is the ability to link the actual names to the data (which is the main issue everyone is facing). But, uncovering this info cancels out one possible place for this information to be hiding. The CWAR holds all the data relative to the Main File Partition (Kind of like it's dictionary). Here's it's structure:

Code:

CSAR "CWAR" Archive

offset      length              info
0x0           0x4           "CWAR" MWORD
0x4           0x2           Endianess Identifier (0xFFFE = Little, 0xFEFF = Big)
0x6           0x4           Header Size
0xA           0x2           Version ID
0xC           0x4            Archive Size
0x10         0x4            Partition Count (INFO + FILE)
0x14         0x4            Weird Constant
0x18         0x4            Info Partition Pointer**
0x1C         0x4            Info Partition Size
0x24         0x4            Main File Partition Pointer**
0x28         0x4            Main File Partition Size
0x2C         0xC            Reserved space for other partitions(?)

** These values pertain to the CWAR when it's separate outside of the main CSAR archive, to get these real values, add the current value to the CWAR's actual offset
in the CSAR archive!!!
----------------------------------------------------------------------
Info Paritition:
**Offsets pertain to that of the partition
offset     length          info
0x0          0x4         "INFO" MWORD
0x4          0x4          INFO Partition Size
0x8          0xC          File Count (of CWAR)

Splits off into a table, per each entry:
long - entry start
long - relative offset of the file in the CWAR
long - size of the file in the CWAR

--end table
Concatenated Files Follow

The way to find the actual offsets of the BCWAV's is easy. All of the relative offsets given are padded by a certain number (we'll call it x).
We first need to jump to the main file partition location, read the h8 bytes. After that, theres a DString of h18 following that which leads us to the first bcwav. We can save that position and then subtract that from the given offset to find the relative difference. So:

1. Find relative difference:
First actual offset - (given offset + Actual Offset of the beginning of the CWAR) = x!

2. Calculate the actual file offsets:
add the relative offset (given in the table ) + x = y
Seek from the beginning of the CWAR y Bytes. To get to the new position.

I'm uncertain if the structure of the CWAR is old news or not, but if it isn't, tahdah! Now that the analysis of that is done, I plan on looking into the "CWSD" portion of the archive, in order to clarify that the linkage isn't hidden in there. Until then!
~Pingu!