How do I open this file?

[DMCA_Kupa]

I encountered strange files once I unpacked the contents of the .nds file from the original Fossil Fighters. None of these files have an extension of any type and I have absolutely no idea what they are or how to open them. Does anyone know what any of these files are and how to open them?

Here is some information about the biggest file I found.

File Name: arc
Size: 5,633KB
Location: [ROOT FILE]/data/model/fieldmap/

Some Hexidecimal Data of arc
   

Other files in the same directory
   

[Resistiv]

Hiya DMCA_Kupa!

I've run into this problem a few times before, so let me try to break it down and help you out a bit:

The file named "arc" is a sort of archive that holds all of the data for the "fieldmap" section of the game.
All other files in that folder are marker/pointer files, and they individually point to a section of the "arc" file where specific data is stored.
However, I haven't been able to figure out what is what in terms of where the files point in "arc".
That being said, I have been able to find a pattern in the pointer files, that being that only three bits change across the files, at offset 30, 38, and 40.
Even included at the very bottom of "arc" is some hex that reads out to "tow.n03_cut", which resembles the name of the file "town03_cut".
In the end, I haven't been able to find a clear way of extracting individual files or clear data out of the "arc", but hopefully this acts as some sort of push in the right direction, alongside a quick bump to keep this fresh.

Hope this helps, cheers!

[DMCA_Kupa]

Hiya DMCA_Kupa!

I've run into this problem a few times before, so let me try to break it down and help you out a bit:

The file named "arc" is a sort of archive that holds all of the data for the "fieldmap" section of the game.
All other files in that folder are marker/pointer files, and they individually point to a section of the "arc" file where specific data is stored.
However, I haven't been able to figure out what is what in terms of where the files point in "arc".
That being said, I have been able to find a pattern in the pointer files, that being that only three bits change across the files, at offset 30, 38, and 40.
Even included at the very bottom of "arc" is some hex that reads out to "tow.n03_cut", which resembles the name of the file "town03_cut".
In the end, I haven't been able to find a clear way of extracting individual files or clear data out of the "arc", but hopefully this acts as some sort of push in the right direction, alongside a quick bump to keep this fresh.

Hope this helps, cheers!

I guess somebody will have to make an entirely new unpacking tool just to open this type of archive then. I see why I can never find any assets from the first Fossil Fighters game now.

[Raccoon Sam]

I guess somebody will have to make an entirely new unpacking tool just to open this type of archive then

I guess I could try
Think you could upload the ARC?

[Resistiv]

Think you could upload the ARC?

Here you are:
root_model_fieldmap.zip

[Raccoon Sam]

the arc file is a MAR archive. It contains many many MCM files.
MCM files are also apparently archives. They contain some files too.
Both, the unpacked MAR and subsequent unpacked MCMs are here, along with my (shitty) code
https://www.dropbox.com/s/dtjs3bhhbqvts6...f.zip?dl=0

[DMCA_Kupa]

the arc file is a MAR archive. It contains many many MCM files.
MCM files are also apparently archives. They contain some files too.
Both, the unpacked MAR and subsequent unpacked MCMs are here, along with my (shitty) code
https://www.dropbox.com/s/dtjs3bhhbqvts6...f.zip?dl=0

Of course now the question is how to open the .bin files located inside the MCM's.

[Resistiv]

First off, thanks Raccoon Sam for the script!~
Also, I believe some of the files are straight textures or sprites based on what they read in a hex editor, see below for an example. Others seem to be scenes and whatnot, but other than that it looks like we'll have to manually decipher most of it due to a lack of headers or an obvious constant structure.

[Raccoon Sam]

Very good, CorruptTurret!

lack of headers

Well, the raw files have twelve(?) unknown bytes in the header and I kinda just skipped over them. Maybe they could be flags for compression or values for LZ window size or something?

Anyway nice observations and a great example of team work!!

[DMCA_Kupa]

Who knew that fossil fighters would have such unusual storage methods.
In data/model/battle I discovered they legitimately decided to just use spreadsheet files to store some of the animation data.
   

[DMCA_Kupa]

You can sort of tell what a file is based on its size.
From what I can see it always fills the more important looking files to 8KB.
Files that are smaller than 8KB are usually structured more like metadata and pointer files.
It is possible that the ARC file may just be an archive of pointer files and basic rendering data because most of it looks unusual.

Another thing that leads me to believe that arc is one big pointer file is how uniform every file size is, obviously the size of models and images would probably vary greatly
but every file I see is 8 KB except for a few but even those are usually 2KB files. I haven't found any evidence that any of these are files, instead they seem like they are
just libraries of data related to the field. Although it might also be possible that each MCM just has one file, but fragmented. Each .dat might be a fragment containing 8KB of the original file and the smaller file is the unequal fragment left over. If that were true the problem would be figuring out how to put the file back together in the right order. I have noticed that in each folder all the .dat files have the exact same structure as each other, so fragmentation is very plausible.

[Resistiv]

Whoops, sorry! I probably should have included that info with the screenshot: it was arc_000106D0.MCM, specifically at the offset of 14D60. Interestingly enough, this MCM seems to have a lot of human-readable strings after the header, making me believe that this MCM may have been a texture/sprite container unlike some of the other observable MCMs.
I also remember finding an unpacked .bin file that was plain human-readable code of some sort, but I can't remember what file... (not related to that MCM though)

[DMCA_Kupa]

If only we had the bit of source code that reads this data or a copy of the tool that was used to compile this archive, then it would be so much easier to decode.
I don't really know a whole lot about emulators but I thought maybe there might be an nds emulator capable of dumping the currently loaded/mounted assets from the ram into a separate file once the game extracts them. If not an emulator might be able to at least help identify some of the ways that these files are read and what they do.
Not sure if any debugging type emulators like this exist, but I think one might be useful here if they do.

---

After looking around it seems like No$GBA does not directly include debugging tools, but there are debugging tools available for it.
I have no idea if these tools are relevant at all, but they definitely exist.

[DMCA_Kupa]

Ok so this is my theory on why this type of file might have been used.

I assume that early in development they had some sort of directory tree with all of the assets to make development easier, and whenever they wanted to load these assets they would use file paths as reference. The framework of the fossil fighters game engine ended up not getting built properly to utilize a standard compressed asset archive and instead relied on plain files. When it came time to build the final game it was too big to fit on a nds flash cart because they had not been utilizing a compressed archive. In an attempt to fit the game onto the flash cart they threw all the file binaries into a archive and compressed them as much as they possibly could. I think the reason there is so many pointers and file paths inside is because on boot up the game reassembles arc files back into the original structure including folders and file names and then mounts the reassembled folder. Arc is a very unique type of archive because it appears to be a heavily-compressed archive of an entire directory, rather than your standard form of compressed archive. The reason why this file structure does not reappear in champions or frontier is because it is only there in the first place due to lazy game structure mistakes that were likely learned from after the first game.

[DMCA_Kupa]

I think i have these .fff files figured out.
We have been looking for headers all this time but I just realized that these files use footers instead.
At the bottom of each file is an index of what is inside the file, I realized this when looking through arc_000BD2DC_unpacked.fff (which im now fairly sure literally contains the raw code for the file parser, there is a massive block of code which looks like its related to file structures) there was a script somewhere in there that mentioned an endpoint, so I went to check and sure enough these fff files have an index at the very bottom and probably some file type information too.

---

The thing that is interesting to me is the [ IS-NITRO-DEBUGGER ] line at the top of the text block.
I searched it up and it seems like IS NITRO is a nds debugging emulator, Its definitely not there from the person who dumped the rom because the version is 2006.6.7 making it two years older than the Japanese release of fossil fighters in 2008, the US release was made in 2009 so if we go by US release date then it would be 3 years older.
This looks like it might either be a log file that they didn't remove, or proof that this game has a compatibility library for is nitro built in.
I'm seeing paths to .vtx files and .mdl so its possible whatever this tool is has access to dump the actual raw files in a windows-readable format