The VG Resource

Ripping Luigis Mansion 3DS remake has been successful so far, however we can't open the .gar files. The unpacker doesnt seem to be working. Is there anything we can do?

Can you send in a file for analysis?
Thanks in advance!

(10-15-2018, 08:50 AM)Resistiv Wrote: [ -> ]Can you send in a file for analysis?
Thanks in advance!

Thanks but we seem to have figured it out already. However the model file is still a mystery to us! If anyone wants to attempt it, heres Boolossus model file.


Edit: I believe I sent the file, I attached it to the post but if I didn't, my apologies haha

Yeah, you didn't attach the file lol, would you mind doing that?

(10-26-2018, 05:35 AM)Resistiv Wrote: [ -> ]Yeah, you didn't attach the file lol, would you mind doing that?

It says the type of file isnt allowed. It's a .cmb file. Hmmmm...
Not sure what to do here

Can you attach something like a Google Drive link to the file?

I also have the same question concerning Luigi's Mansion 3D, so here's two .gar files from the game. First is a prop and the other's likely a character.

key01.gar - DBREE
dog.gar - DBREE

I don't know what Doggo54321 may have tried, but I attempted to open some of these .gar files with xdanieldzd's latest version of N3DSCmbViewer to no avail.

(10-26-2018, 06:13 PM)Resistiv Wrote: [ -> ]Can you attach something like a Google Drive link to the file?

https://drive.google.com/file/d/1taWMD6q...sp=sharing
This should work?

Yes, that works Doggo!

Taking a look at the file in HxD, your CMD file seems very similar to that of the CMB files found in the GAR files provided by Centrixe, also meaning both don't properly open in N3DSCmbViewer. The reason they don't open is because they have an extra chunk of data before the denoted "mats" section (CmbViewer throws an error about not finding the "mats" chunk, and instead finds the "qtrs" tagged chunk). Attempting to get rid of the "qtrs" chunk doesn't help, and instead causes the program to throw more errors, and attempting to correct for them seems not to work either. So, it seems we'll need to reverse engineer the file to be able to interpret them. I would recommend looking at some of the files that work in CmbViewer and figure out their structure, then see if you can modify the CMB files to resemble their structure and open properly (however, that most likely won't work and we'll need to, instead, fully reverse-engineer the files).

Also, there are more files found within the GAR archives, most being files with a "csab" header and a few found in the "dog.gar" file being denoted by a "shpa" header (not sure if this is important but thought I would note it).

A quick detail on the structure of "csab" and "cmb " chunks:
All of these sections have the respective header and then a long representing the length of the file. However, it seems the length is to be read backwards (at least in HxD). An example header is as follows:
The data can be interpreted as this: "cmb ", then a backwards long representing the hex length of the file, in reference to this file being "A680". I couldn't really identify the relevance of the long "0F 00 00 00", but I'm no expert at reading these files.

Lastly, I was able to go through and and manually extract some files from the GAR files provided by Centrixe, however there were some sections ("shpa" chunks) I wasn't able to properly interpret and extract. You can find the files below.

dog.zip
key01.zip

Hope this helps, cheers!

(10-28-2018, 10:05 PM)Resistiv Wrote: [ -> ]Yes, that works Doggo!

Taking a look at the file in HxD, your CMD file seems very similar to that of the CMB files found in the GAR files provided by Centrixe, also meaning both don't properly open in N3DSCmbViewer. The reason they don't open is because they have an extra chunk of data before the denoted "mats" section (CmbViewer throws an error about not finding the "mats" chunk, and instead finds the "qtrs" tagged chunk). Attempting to get rid of the "qtrs" chunk doesn't help, and instead causes the program to throw more errors, and attempting to correct for them seems not to work either. So, it seems we'll need to reverse engineer the file to be able to interpret them. I would recommend looking at some of the files that work in CmbViewer and figure out their structure, then see if you can modify the CMB files to resemble their structure and open properly (however, that most likely won't work and we'll need to, instead, fully reverse-engineer the files).

Also, there are more files found within the GAR archives, most being files with a "csab" header and a few found in the "dog.gar" file being denoted by a "shpa" header (not sure if this is important but thought I would note it).

A quick detail on the structure of "csab" and "cmb " chunks:
All of these sections have the respective header and then a long representing the length of the file. However, it seems the length is to be read backwards (at least in HxD). An example header is as follows:

Code:

63 6D 62 20 80 A6 00 00 0F 00 00 00 00 00 00 00

The data can be interpreted as this: "cmb ", then a backwards long representing the hex length of the file, in reference to this file being "A680". I couldn't really identify the relevance of the long "0F 00 00 00", but I'm no expert at reading these files.

Lastly, I was able to go through and and manually extract some files from the GAR files provided by Centrixe, however there were some sections ("shpa" chunks) I wasn't able to properly interpret and extract. You can find the files below.

dog.zip
key01.zip

Hope this helps, cheers!

Sorry for such a late reply, but this helps a lot. Thank you!

I have a .gar file, It works with a modified version of N3DSCmbViewer but one of the folders in the .gar is called "C:" which causes the program to flip out and not allow me to mass extract the files and folders, any other way to open .gar and extract contents in few clicks instead of right clicking on every file in N3DSCmbViewer?

---

I tried another too called GAR-ZAR unpacker but it doesn't work... I wish I could just rename the folder in the .gar