Why are ".sgarc.cmp" files (found in Mii Maker) to this day unable to be recompiled?

[1vb]

To this day, we can decompile .sgarc.cmp files easily, but it's impossible to modify or repackage the extracted/decompiled files. Tools like QuickBMS or Switch Toolbox allows us to decompile, but it still hasn't been possible for those tools to package it into a usable format.

 

[FAST6191]

Code it yourself or go manual (bonus if you have scripts like that as they will usually have defined the format for you so you know what to change* and what format it takes) tends to be the answer here. Manual might be tedious but so very far from impossible.

*most archive/packing formats you will not want to change the names in (if any exist) so mostly either then if it is one or two files repoint the old files to the end (if they are larger, if they are smaller maybe pad them out and go back to the original size and location) and maybe do any size values for the archive, or if it is a more substantial alteration then there is usually a way to either identify end of files or make it so there is (insert a unique string not seen in any other file in the archive between each file as you repack it, dump the locations and the rest is maths a spreadsheet can do).

Bonus for coding it yourself is there are likely many tools for broadly similar formats already out there you can twist, and I can see it being in the range of those fun AI programs these days as well.

 

[1vb]

Are there any guides or something that you think could help me along the way? I've never touched compression and stuff related, but I would love to be able to figure and do it myself, and the .bms script from QuickBMS does not give enough information on that front

 

[FAST6191]

Any compression in these sorts of things is usually on the sub file basis (saves having to decompress the whole file when you only want part of it). Don't know what it will be offhand, or if the good old u8tool is still in play but it sounds like that is not the issue.


Anyway never really played with quickbms so not familiar with its approaches.
Looking at (do a page search for mii maker rather than extensions)
http://aluigi.altervista.org/quickbms.htm

# Mii Maker (Wii U)
# script for QuickBMS http://quickbms.aluigi.org

endian big
get SIZE long
savepos OFFSET
get ZSIZE asize
math ZSIZE - OFFSET
clog MEMORY_FILE OFFSET ZSIZE SIZE

idstring MEMORY_FILE "SA01"
get FILES long MEMORY_FILE
get BASE_OFF long MEMORY_FILE
for i = 0 < FILES
    get OFFSET[i] long MEMORY_FILE
    math OFFSET[i] + BASE_OFF
next i
for i = 0 < FILES
    get SIZE[i] long MEMORY_FILE
next i
for i = 0 < FILES
    getdstring NAME 0x80 MEMORY_FILE
    log NAME OFFSET[i] SIZE[i] MEMORY_FILE
next i

That looks like a fairly encompassing setup that defines things (all those terms are general computing terms or fairly obvious as to their intent from a programmer perspective) even before I grab http://aluigi.altervista.org/papers/quickbms.txt and start decoding it. Though even before that some of the debug features might be useful in explaining the steps it is taking when it unpacks the file.
It does also mention a repack option. Have you tried that in this?

Back on topic section 4 and http://wiki.xentax.com/index.php/BMS appear to cover the language.

endian big is a way of specifying big endian be used, which makes sense as it is a gamecube/powerpc derivative where such number setups are used. For you it will mostly mean numbers in a basic hex editor view will be flipped around compared to how you might want to read them.
get means grab the data, long means a 32 bit value (short aka INT and long and double being usually associated with C family languages as a means of denoting length of data) and SIZE in this case is a variable name that the script author used (probably to hold the size of the whole file).
http://wiki.xentax.com/index.php/BMS#Get
As nothing else is specified then it looks like the first 32 bits of this format are used to indicate the size of the file, a fairly common thing in game file hacking.

savepos is short for save position. In this case it stores it in a variable name called OFFSET.
http://wiki.xentax.com/index.php/BMS#SavePos

get is used again, in this case uses the special asize option to get the length of the file being examined and store it in a variable called ZSIZE

Math sees it do some maths. http://wiki.xentax.com/index.php/BMS#Math
In this case takes the ZSIZE (which at this point is the length of the file) and takes the value OFFSET from it

CLog is a special version of the log command used for compressed files it seems.
http://wiki.xentax.com/index.php/BMS#CLog and normal log as it is a tweak on that http://wiki.xentax.com/index.php/BMS#Log
MEMORY_FILE is a special type of temporary file that the program keeps in memory.
Be careful interpreting this using the link as the variable names picked by the script writer are slightly confusing if you are not paying attention. ZSIZE remember is the length of the file, size is the file size the archive itself indicates it is which is not necessarily the same thing.

http://wiki.xentax.com/index.php/BMS#IDString
Looks for SA0 in the MEMORY_FILE it stored previously, mostly to make sure you are doing it to a format it knows rather some random file and it possibly getting numbers it has no clue about. By no means foolproof but hey.

Now it actually gets to doing something interesting.

Get was already covered, in this case
it grabs a long (32 bits) from the memory file and stores that in a variable called FILES (presumably number of files within the particular archive)
another long gets grabbed and called BASE_OFF (presumably base offset, offset being a term used to in a way start counting from this particular location)

FOR is a type of loop, loops in programming are ways of doing repetitive tasks
https://www.tutorialspoint.com/cprogramming/c_loops.htm if you want an overview, though any programming language tutorial will cover this if that one is not doing it for you. http://wiki.xentax.com/index.php/BMS#For..Next having the particulars of this.
In this case without checking beyond right now I imagine it is going to grab each file in turn until it runs out of files to grab, and will know it is done by adding one (or subtracting one) from the total file count it has done and comparing it to the file count it has from the original file itself, and increasing the offset such that the pointers to the file are set grab the appropriate sub file from the archive. Or if you prefer in more human language it will get a list of pointers, and go through one by one grabbing the files where they say to grab until it reaches the end which it will know as it will keep a track of how many files it has grabbed and compare to how many files the archive says it has.

Math returns to add the value it grabs to BASE_OFF, this presumably meaning the location values start counting at the end of the header and setup section. If thinking like a game developer this is mostly useful these days so you can add files to the archive quite quickly without having to recalculate everything, historically it would have had more uses when limited jumps were more of a thing but this is not the NES or gameboy. I normally see this in text files rather than archives but sounds like someone has already done it so I am not going to argue.
It similarly grabs a size of the file, note that size of the file might not be next file location - current file location as it can be easier to pad things out to land on specific locations (called alignment, byte aligned, word aligned, double word aligned, 32bit aligned... being the sorts of things you might hear in such discussions).

Next presumably bumps the counter up it is using to see when it runs out of files in this case, or indeed the sub aspect of the whole file name, size and location it is presently dealing with.

http://wiki.xentax.com/index.php/BMS#GetDString
Grabs 0x80 worth of text data from the memory file and calls that the name of the file contained within, and does it however many times. Odd to see fixed length names of files but again someone has already looked into it so not going to question things here, and there is no mystery data that might indicate otherwise.

Finally the big finish http://wiki.xentax.com/index.php/BMS#Log , or at least will finish after it runs this however many times to grab all the files.
Has the file name it is using, the location of the sub file within the archive and the length of it and is going to grab it for us.

So anyway doing another of those more human language things looks like file starts with a file size, has an magic stamp as it is generally known (small bit of text or binary data that indicates the file type, usually considered more reliable than file names, extensions and such as those are easily changed/lost depending upon what the dev did or if they are doing something strange), an indicator of the number of files the archive has and a start for the files themselves (as opposed to all this setup).
After that you have a run of locations, a run of sizes, a run of names (fixed length which is nice of them*) and then get to the data itself.

*though when if dealing with another format that is not fixed length that mostly just means you either have another set of pointers and lengths dealing with said things just for the name aspect or said names have escape values/ending values between them, say 00 is never going to be in the name so fine to have that mark the end of/start of, between them which you search for instead

Alternatively http://wiki.xentax.com/index.php/CMP_SA01 which was found via http://wiki.xentax.com/index.php/GRAFs/M (mii maker, do a page search for ti) might be it as well.