For the record I am seeing a lot of NCER, NANR, NCLR, NCBR... the usual graphics and graphics helper formats and the usual suspects as far as 3d goes.
Still there are lots of .xbb files in it in a folder tree called rom\pics\char\*
Various sizes exist though there does seem to be a logic at work.
Took a look. Kind of similar to a lot of archive formats I have worked with over the course of things. If the file names within them are anything to go by then it is also full of NCER, NANR, NCLR, NCBR... type things.
The file appears to start XBB then 01 in the hex (or 58424201 all in hex) for every thing I saw (I pulled a selection of various sizes for everything). After that is another number which appears to be a hex count of the number of files contained.
After this there seems to be 00 padding until 20 hex.
Buttlerfly shadow has two files which is nice so I will have a look at that first.
Usual 32 bit byte flip
Unless I miss my guess it is
File location (100h in this case, for files larger this first value appears to be aligned to the nearest 100h, this normally means 200h or 100h though with the occasional 300h for the really big files)
File length (0228h, backed up by the internal NCLR length parameter and seen in other formats that are not so uniform in length)
File name location (the file names do appear to be variable length and end to end with only a 00 between them).
No there is 32 bits of something I can not determine the use of, it is usually all random and full up (no 0000???? ???????? or anything). It is not memory locations (things that do not exist appear), it is not locations within the ROM (too variable between names), names are obviously next so it is not some reference to that.
Between the end and the names are the same random values as ended the other files, though here they are in a different order for archives with more than two parts separated by 32 bits. Said other 32 bits are numbers which seem to correspond with the file order (if the random value is followed by a 04 then the random value will be the same as the random value for the file 04, do note like a good programming language things start counting from 00).
Following this is the file names. Again they are however long they are (you were already told the location) and between each there is a 00, I guess it is location and simple string read that is stopped by a 00 for this (
a typical C affair).
I am seeing compression in some of the files, usual type 10 LZ by the looks of things. This is easy enough to deal with and in my samples the things I saw with it tended to have _LZ in the names.
The random stuff has me stumped right now, I should compare it between files more but I did not see any matches from a quick scan. You have all the other data about the files so it is not some obfuscated stuff. It only bothers me because I like to figure things out, it might not trouble you though. Best policy is to leave it alone and match it back up as and when you rebuild the files. If the game crashes and you have changed the length of the files you know it is that. I do not think they would be so crazy as to do something like a checksum (or at least not actually use it in game). However this is Marvelous Entertainment we are dealing with so who knows, likewise if they are using an archive format from another platform (entirely possible when it comes to the DS) that is a thing and it is about the only reasonable thing left for me to guess (the matching file number - random value thing also being a good fit for that theory). I tried a few guesses for checksum values but guessing checksum variables (if it is even a standard method at all) is almost like trying to guess a password. The trick will be to see if there are any identical files and if their random values match, there is a good bet for this as palettes might well be the same.
The random stuff aside I agree it is a simple format. No calculations really even needed to decode or rebuild it which is great really.
.
