Ben 10 Alien Force Vilgax Attacks PSP psp_ben10.bin archive extraction help

[TITAN]

Hello,

I am analysing the PSP build of Ben 10 Alien Force Vilgax Attacks. All game data on PSP is packed into one large file called 'psp_ben10.bin' and I need help figuring out the archive structure so I can extract the contents. This is specifically for the PSP version. I am aware that other versions (like PS2/Wii/X360) of this game use a different, open filesystem, but the PSP version uses this single archive

What is known
-The file name is 'psp_ben10.bin'
-File size: 1,125,622 KB
-Signature: 'ARCV' found at file start, no offset
-A header of 12 bytes is read at the start, based on observed file reads
-After the header there appears to be a table of entries where each entry is 12 bytes, suggesting a structure like offset, size, flags (this is a hypothesis consistent with the 12 byte reads and allocation behavior)
-The game reads chunks directly from the .bin at runtime, using standard PSP IO and cached reads
I prepared a sample file containing the first 1 MiB of the archive for testing

Known resource paths found in the binary (examples)
global/scripts/psp.ddf
global/scripts/struspsp.txt
global/scripts/strsppsp.txt
global/scripts/strfrpsp.txt
global/scripts/char_psp.ddf
global/scripts/gld_psp.ds
l_anur/snd_psp/swpanr0.fsb
l_bell/snd_psp/swperth.fsb
l_ence/snd_psp/swpenc0.fsb
l_terr/snd_psp/swpterr0.fsb
global/snd_psp/swpbchil.fsb
global/snd_psp/swpbstrm.fsb
and there are some other ones, it's also strange that I couldn't find other paths, although there are clearly more files there

Attachments
I will attach a 1 MiB sample cut from the start of the archive and a screenshot of the first bytes in a hex editor.

Request
If anyone has seen an ARCV container layout before or can confirm the header/table layout and entry field meanings, please share examples or a small parser snippet. If you need a different sample range from the file I can extract and upload specific offsets on request.

Thanks in advance for any pointers or pointers to similar formats

psp_ben10 filecutter.rar

[DKDave]

1 hour ago, TITAN said:

Hello,

I am analysing the PSP build of Ben 10 Alien Force Vilgax Attacks. All game data on PSP is packed into one large file called 'psp_ben10.bin' and I need help figuring out the archive structure so I can extract the contents. This is specifically for the PSP version. I am aware that other versions (like PS2/Wii/X360) of this game use a different, open filesystem, but the PSP version uses this single archive

What is known
-The file name is 'psp_ben10.bin'
-File size: 1,125,622 KB
-Signature: 'ARCV' found at file start, no offset
-A header of 12 bytes is read at the start, based on observed file reads
-After the header there appears to be a table of entries where each entry is 12 bytes, suggesting a structure like offset, size, flags (this is a hypothesis consistent with the 12 byte reads and allocation behavior)
-The game reads chunks directly from the .bin at runtime, using standard PSP IO and cached reads
I prepared a sample file containing the first 1 MiB of the archive for testing

Known resource paths found in the binary (examples)
global/scripts/psp.ddf
global/scripts/struspsp.txt
global/scripts/strsppsp.txt
global/scripts/strfrpsp.txt
global/scripts/char_psp.ddf
global/scripts/gld_psp.ds
l_anur/snd_psp/swpanr0.fsb
l_bell/snd_psp/swperth.fsb
l_ence/snd_psp/swpenc0.fsb
l_terr/snd_psp/swpterr0.fsb
global/snd_psp/swpbchil.fsb
global/snd_psp/swpbstrm.fsb
and there are some other ones, it's also strange that I couldn't find other paths, although there are clearly more files there

Attachments
I will attach a 1 MiB sample cut from the start of the archive and a screenshot of the first bytes in a hex editor.

Request
If anyone has seen an ARCV container layout before or can confirm the header/table layout and entry field meanings, please share examples or a small parser snippet. If you need a different sample range from the file I can extract and upload specific offsets on request.

Thanks in advance for any pointers or pointers to similar formats

psp_ben10 filecutter.rar 838.69 kB · 1 download

The initial table at the start is offsets and sizes, as you've guessed.  The attached initial QuickBMS script should extract all of the raw files for further analysis.  There are no filenames other than what might be in some of the files.  However, there are also many compressed files in the extracted "CARC" archives, which I haven't done anything about in my script.  The .fsb files are audio banks and can be played directly with Foobar/vgmstream.

 

 

 

 

b10.zip

[TITAN]

1 hour ago, DKDave said:

The initial table at the start is offsets and sizes, as you've guessed.  The attached initial QuickBMS script should extract all of the raw files for further analysis.  There are no filenames other than what might be in some of the files.  However, there are also many compressed files in the extracted "CARC" archives, which I haven't done anything about in my script.  The .fsb files are audio banks and can be played directly with Foobar/vgmstream.

 

 

 

 

b10.zip 467 B · 1 download

First of all, thank you so much for the QuickBMS script! It worked perfectly and extracted all 721 files from the full archive, which matches the count I found in the executable.

Now I'm analyzing the extracted `.carc` files and found the relevant functions in Ghidra. Here's what I discovered about the CARC format:

CARC Structure (from Ghidra analysis):
-Header: 16 bytes starting with signature `0x43524143` ("CARC")
-File Table: `file_count` entries, each 24 bytes (`0x18` bytes) 
-Total header size: `file_count * 0x18 + 0x10`

The code shows this exact calculation:
```c
if (DAT_0047c8ec == 0x43524143) { // Check "CARC" signature
    uVar6 = DAT_0047c8f4 * 0x18 + 0x10; // Calculate table size
    // ... allocates and reads the table
}
```

Additional findings:
-Inside CARC files, I can see references to `spav` format and what looks like compressed data (strings like "zSi6" appear)
-Some CARC files seem to contain what might be VAPS-related data
-I also found VAPS signature checks in the code (`0x76617073`)

Interesting context: VAPS archives are known from other Vicious Engine games (like Ben 10 Ultimate Alien: Cosmic Destruction), where they use LZF compression and have different formats between X360 and PS2/PSP versions. Here's a link to the documentation: https://web.archive.org/web/20230515024617/https://wiki.xentax.com/index.php/Vicious_Engine_Archive
rather, it doesn't differ much from cosmic destruction

Attachments:
I'm attaching examples of each file type extracted by your script:
-2 `.carc` files
-2 `.spav` files 
-2 RIFF files (no extension)
there are two types of files of the same format, if you need more I can send

Next steps:
I'll continue analyzing the CARC table structure and the SPAV format. If anyone has insights into these formats or recognizes the "zSi6" compression pattern, I'd appreciate any pointers (and yes, this pattern is not in every carc file).

Thanks again for the help, the script was a huge breakthrough!

extracted files.rar

[DKDave]

I've had a look at the CARC files.  All of the files in the CARC archives seem to be compressed - they all start with SSZL, which seems to be LZSS0 compression.

Note: It seems like there are only a small number of files, but split into multiple compressed parts that need to be joined together.

 

The CARC main header is 0x10 bytes:

0x00 - "CARC"

0x04 - Total number of files

0x08 - Total number of parts (each file seems to be made up of multiple compressed parts) - this count includes the total of files and part entries

0x0c - Total size of this CARC archive

 

The main file entries start at offset 0x10, which includes an offset and count to the start of the part entries for that file:

0x00 - ?

0x04 - Entry type (2 for files, 1 for parts ?)

0x08 - Offset to start of part entries for this file

0x0c - Total number of part entries

0x10 - ?

0x14 - Total decompressed size

 

Then each part entry seems to be :

0x00 - ?

0x04 - Entry type ?

0x08 - Relative offset to start of this part

0x0c - Compressed size

0x10 - ?

0x14 - Decompressed part size

 

Then the "SSZL" data has a header of 0x10 bytes, with compressed/decompressed size, and then the compressed data.

 

 

 

 

 

 

[TITAN]

I really want to sincerely thank you for taking the time to examine the CARC files and provide such a detailed breakdown. Your insights are incredibly helpful and gave me a much clearer understanding of the archive structure. I truly appreciate the effort you put into analyzing it!  
I've been testing the SSZL decompression following your notes on the specific CARC file I examined, but it seems that standard LZSS0 approaches don't fully work.
Here's what I observed in that file (37KB):  
0x00: "SSZL" signature (I cut off all the bytes that were before it)
0x04: 8 unknown bytes (00 00 00 00 25 22 00 00)
0x0C: 0x00002225 (likely decompressed size = 8741 bytes)
0x10: 0x00004000 (likely compressed size = 16384 bytes)
0x14+: Compressed data starting with FF 73 70 61 76...  

I tried multiple LZSS0 extraction methods, but the results are always partial, about 99% coverage, and the output seems slightly corrupted.  
I'm wondering if this could be a custom LZSS variant specific to Vicious Engine, or if there's something subtle in the header that I'm missing. Based on the initial bytes, the data appears SPAV related.  
Again, thank you so much for your help. Your explanation really helps me understand how these archives are structured. Any guidance or hints on this last piece would be hugely appreciated, but I completely understand if it's complex to explain

Update: I also found the SSZL decompression functions in Ghidra:
- Functions check for signature 0x53535A4C ("SSZL") and 0x4C5A5353 ("LZSS")
- Header structure in code:
0x00: signature
0x04: unknown field (possibly flags)
0x08: compressed size
0x0C: decompressed size
- The code handles endianness conversion for SSZL format
- Calls internal decompression function FUN_00085d10

This confirms the 0x10-byte header before compressed data.

Update 2: After analyzing the decompression function FUN_00085d10 in Ghidra, I can confirm it's LZSS with: 
- 0x1000 (4096) byte sliding window 
- Standard bit-flag controlled decoding 
- History buffer implementation  

The algorithm appears to be standard LZSS but might use custom parameters that differ from typical lzss0/lzss1 implementations. Any further guidance would be appreciated!

Edited Monday at 10:17 AM by TITAN
I'm adding info to avoid spamming.

[TITAN]

Thank you again for all your help with the CARC analysis. I've continued my research and made several key discoveries:  
1. The extensionless files are indeed the game's scripts and resources (.ddf, .ds, .txt etc formats, RIFF+WAVE audio, FEV1/FMOD sound banks, and some files without visible signature remain unknown)
2. All textual files are encrypted with the signature "1badbabe" - consistent across Papaya Studio's Vicious Engine games
3. Some unencrypted files like sndbnk.ddf reveal the expected structure in plain text
4. While I found the encryption functions in Ghidra, the algorithm involves complex bit operations and 10-round processing that proved too difficult to reverse
5. The CARC/SPAV archives likely contain game assets, but my primary interest was the scripts  
Your assistance was invaluable for understanding the archive structure. While the encryption prevents practical modding, the analysis provided complete understanding of the PSP version's data structure. Thank you.