Hacking Homebrew ROM Hack wappy dog file system. i need help decoding it!

[Epicwappy20]

i extracted the filedata.bin with tinkedsi and this is what happened, please help!

 

[FAST6191]

Another accessory for the DS that sailed completely by me? I am really not doing well with these things despite trying to. Will have to see how it works (we have seen infrared, bluetooth, network, wire albeit for homebrew/flash carts/cheat devices, GBA slot and more used).

Anyway interesting. Don't see too many of these all in one data file type games but there are still some.

Extracted the data folder and had a look. Two files, one of which is SDAT (common audio format, and usually main thing left out of this archive file type games along with download play stuff).
Had a look in a hex editor. Very close to the start I see RTFN which reversed is NFTR or the popular font format. This usually means everything before it is some flavour of data about the archive.

In this case being so small a section for nearly 9 megs of file (no overlays that I saw, 500K ARM9, sound noted as being outside it) I am not expecting names/extensions (you will have to figure that out from context -- if indeed it is NFTR then congrats, hopefully all the files have magic stamps).
This would appear to be born out when I shrink the hex window down. Also it might not start with RTFN and in fact the "11848C" a bit earlier might well be an indicator of compression (the 11 in this case is a type of LZ seen a bit later in the DS lifetime, and the 848c matches the size value shortly after RTFN -- fonts don't always compress the best so the size of compression matching the size of file makes some sense).
Anyway after shrinking the window I am seeing 4 byte runs that when flipped (see big endian vs little endian if you are not familiar) then are counting upwards which is usually a sign of pointers of some form.

02A0 to start with is odd. It is almost at the end of the section (or might even be the end of the section plus a bit to account for this value aka size of pointer section) but I have also seen this sort of thing be a file count. Lacking other examples in the game (don't know if this appeared in other regions and looking at the text later in the file I am seeing English, Spanish, French and German at least) I would have to go further.

Flicking around I see SCRN at 160B4. Before it I am seeing 0000 and some stuff that is not especially fitting with the text before it so I don't know. Hopefully the 00 is some kind of separator rather than padding.

I see a BMD0 (curiously no 10 or 11 or 40 to indicate compression which is very rare -- 3d files take up a lot of space and usually compress very well) which is a start of the NSBMD 3d model format, said things immediately followed by what what looks like valid data for said 3d model format (lot of things mentioning the name eclair).
21BD34 is the address there, curiously as well just before that is BC27 0000 which is the same as the size value inside the NSBMD file. Would not be the first archive file to have a size value located at the start of the file.
Adding those two together gets me 21E4F0 and going there does appear to be the end of the file and start of yet another NSBMD, or in this case the 0C280000 which matches nicely with the internal size value of the NSBMD there.

8C2C4C (though for the sake of making things easier for this 008C 2C4C) would be the end of the file; not usually in such pointers but if any go outside that limit it tends to mean something else is happening.
008C 8411 then being the last value in the table before RTFN (8411 also being larger than 2C4C) but immediately before that is stuff in the 0022???? range. There could be a giant file at the end though.

What I would do when it is not 1:45 in the morning is grab all the "pointers" from the start of the file, flip them, put them in a spreadsheet, subtract the following from the one before to get a size difference and then see if you see some of the size values mentioned above or something close to it (maybe 4 bytes more or some multiple of 4 bytes out each time). Kind of neat archive format and not one I have seen in this configuration.

Shorter version no fear what I suspect it might be.
Single archive file housing several dozen files.
Start value might be either a file count (doubtful for the lack of pointers) or a size of pointer section as it does end near the start of the first file.
After this a list of possible pointers to files contained within. Whether offset, relative or standard I am not sure at this point.
Each file sadly does not have a name but before the start of each file is what could be a file size (flipped of course) in some form of padding or lookup. Whether you have to change this if you change file sizes as part of your hack I don't know at this point (sometimes this sort of thing is vital data, other times it is just fluff the developers left in).

No indication of any kind of shifted data (did see that for touch detective which has a similar all files in one archive), data encoded in upper bits of pointers (see subdirectories in NARC files, and compression indicators in several other things) or anything like that.

If you need a tool to slice up files after you played with your spreadsheet then rather than make something custom, or try to decode the internal formats of one of the general tools then instead we have long pointed people at https://web.archive.org/web/20170218180937/http://min.midco.net/cracker/filecutter.zip
Between the spreadsheet, a text editor and that you can make a batch file that will slice given sections of data out of a bigger file.
Sadly my primitive hex editor I have installed on this machine does not do flipping but hopefully the following gives you an idea of what I was looking at/considering

 

[Epicwappy20]

tried reversing RTFN in a hexeditor and nothing happened

 

[FAST6191]

tried reversing RTFN in a hexeditor and nothing happened

Why? It was merely a note of the magic stamp (short section of code, usually ASCII text but not always, that files start with that indicate their format) is that of the NFTR font format and thus presumably the end of whatever header/pointer/size/name/extension data was in that archive format.
https://wiki.xentax.com/index.php/Nintendo_DS_Font_NFTR

All that reversing the RTFN part might achieve is any tools that look for files within files (not seen one for NFTR but common enough for general graphics and audio) might not pick it up where they would have before. It is not going to make whatever tool you were using to pull apart the base ROM suddenly aware of a completely custom archive format.

You then get to reverse engineer the file system. Two main approaches

1) You play with the pointers/size values and try to match that to sections within the file
2) You identify files within the archive, preferably successive files, and try to match those back to the pointers or whatever you have. I already mentioned there being several NSBMD 3d model (and texture) formats, which is nice as most common DS formats ( https://www.romhacking.net/documents/[469]nds_formats.htm ) have a size value in them.

In this case you have the added bonus that this particular archive format also looks to have size values included before the files/between the files (quite rare actually, mostly only see that in scripting engines and very rarely in text). To that end you might be able to find a file, note its location, grab the size indicator before it and then add that onto the length of size value and current location to get the next file, repeating until the end. Compare this list of sizes and locations to the start/end/potential further location data within the file and... if you just want to extract things to look at then you are done but if you want to edit things and increase sizes (pad it out if it is smaller) then you have a very good idea of what to look for and what changes might have been done.