#[NDS] Kageyama Math Training
143 messages · Page 1 of 1 (latest)
These games are so painful to rip i swear. Let me take a real quick look at the files.
Ah,seems .mza file is bunch of NUE files without compression applied.
ah not NUE?
I've corrected it,thanks for correction.
Try cutting file from the big archive and open it in Tinke. If table is correct,it's all Nitro based with custom headers.
Now either that or it has custom compression built by some depressed random.
ok I think I have extracted a raw file
the length matches the one in the list
since it's 921 bytes long as per tinke says
but it's compressed
will dsdecmp do the work? 🤔
I guess finding out isn't painful.
Try QuickBMS compression scanner.
it has outputted a lot of different files in dmp format
Open them all in Tinke and start viewing one by one until you (hopefully) get the image.
none of them worked
i will try again because it froze at some point
ok it terminated successfully this time
the only interactable dmp-s are these
Bizzarre_Skip
Slz_03
fact5lz
hypatia_mariel
and nothing else
I will try again with a generic dat extension I guess
nope
nothing changed
I'd guess it's either custom engine or some very random LZ compression.
maybe they are not graphics
because here is what the file title is in the map
FN_A_01_01_LEFT_NSCR_NUE
nscr is a typical format for tilemaps, not assets
.....
I am stupid
there is this additional file I am sending rn
aaand I think I figured it out
the file order is weird as hell
We have tilemap-graphic-palette
all compressed
and tiled up
here is the raw graphic file
and the raw palette
please ping me if a decompression method is found
I have discovered something else
The mzc and mzh files contain readable code. mzc is localized and directly connected to the mza's offsets (c file), the mzh is shared for all versions (h file)
@smoky narwhal Any ideas? Sorry for the ping, but I am out of options.
No rush tho.
it is
a giant blob of compressed nue files
I have tried dsdecmp, quickbms compression scanner... nothing
i see
yeah i see
the mzc explicitly tells the addresses and sizes of the data inside the mza
there's some small files and big files inside
doesn't look too complex though
Yes, the files are simple stacked on top of each other, and with the mzc I can rip each one out with ease
The problem is they are all compressed in this nue format
yeah
differential analysis should be enough
i'm at work so i can't look at this in-depth, but the first thing i'd do is get some uncompressed data and compare it with the compressed data
see how they line up and work my way up from there
No
Play the game in an emulator and make a save state
Inside the save state, the game state is stored in its uncompressed form. RAM as it is, VRAM as it appears, etc.
Ok, do I send one here?
There is some uncompressed data in there at all times, by definition
Problem is finding the match. thankfully filenames are preserved, so things like FN_STAFFROLL2_BG_NAME_01_LEFT_NSCR_NUE are very likely tilemaps you'd find from the game ending, i.e. the Staff Roll
so a save state from the staff roll section is likely to contain an uncompressed representation of that particular file (or one of the others named like it)
comparing these is the key. At least that's the one-size-fits-all/platform agnostic solution i've always used,
thanks, gotta look into this later in the evening
in an ironic twist, i think Desmume save states are zlib compressed, so I need to decompress that too first
I can use melon if it helps
i'm not too caught up on DS emulation but I'm sure there are emulators that do raw save states too
but i don't know which ones. no$gba probably, at least no$psx has an option in the settings to choose save state format
but idk, like i said i'm at work so i can't focus on this 100%.
I'll get back to this
melon one
main menu after selecting save file
hmmm
I took it here
I could do a nogba one if it helps, but I can't change the language
and the graphics are language localized
I wish MelonDS had debug options,only thing it needs at the moment.
Ok I think I did it
Are the savestates in nogba known as snapshots, with SNA format?
Yes
But there should be a setting in there somewhere that determines compression level
which one
Unbelievable
It seems its not a setting after all, but a line you must add to the INI file.
https://www.save-editor.com/tools/wse_ds_save_converter_for_emulator_no_cash_gba_ini.html
I found this
NO$GBA.INI SAVE MODE CONVERTER is an online editing tool that changes the compression settings of NO$GBA save files. When converting to a save file format that can be used with other emulators, set it to RAW (uncompressed). by SAVE-EDITOR.com
Or this
https://www.ngemu.com/threads/hidden-config-options-for-no-gba-2-6a.137921/
SAV/SNA File Format == Compressed
None
Raw
Uncompressed
Ok there are a few options available which are not selectable from the gui (graphic interphase) menu. Since using the commandline is not an available option, because of the way the program was handled (stripped) when it was compressed (most likely). The simpliest way to enter these hidden...
do I have to switch it to raw -> compressed, or compressed -> raw?
I never went home yesterday sorry
Still haven't had a chance to look at it in detail
its k, I just want to get to the bottom of this no matter the time
I wonder if there is an option that doesn't involve reverse-engineering the entire rom
Because I don't have rn the time and effort required to put into that kind of project
We don't need to reverse engineer the entire ROM, no
Just differential analysis
Have you seen my video about the subject?
https://youtu.be/LASE8IiGB9Q
This time we're taking a deep dive back into 2018 and the methods we used to reverse engineer the GAM file format Whoopee Camp used to compress Tomba 1 data. We had no debugger but as it turns out, sometimes just eyeballing the compressed data and the decompressed data is enough to draw enough insight to figure out what the scheme is all about.
...
I do my best to explain the LZ compression differential analysis visually
The method works on many cases, LZ is just the most common one
Will look at the video this evening
Ok, that's actually insane
So practically, the savestate is supposed to contain the vram, which has the decompressed file
And from there, you figure out an algorithm, write it in python, and screw the compressed nue
I guess I will start comparing snapshot and mza
Yeah that's the gist of it
The problem here though is that we don't know what the uncompressed data is
We've got a bunch of files but what's what is the problem. The filenames give some hints sure but idk
Filenames like "nönnönnöö_ending" are extremely likely to be related to the ending.
Or stuff like "whatever_mainmenu" is likely to be stuff from the main menu, you know
The key is finding the compressed&raw "pairs"
I still haven't visited home
I wish I could just get back and have a good session with this at my computer but alas I'm stuck here, far from home, on my phone
Ok, I may not be able to look further and compare the data as of now, but in a few weeks I should have a little more free time and get on this properly. In any case, please send a ping if you discover something interesting.
I discovered a tool called GLintercept
Currently it doesn't work for my version of Desmume, but can it work?
I mean, even if the tiles are compressed like that
Oh well would you look at that, I tried another game and it worked!
It's like Dolphin Texture Dumper ahah
Holy smokes this tool is insane
I will test it with Math Training now
WAIT A
interesting
I can't rip everything with the layer method, but it surely does help to get backgrounds and buttons 🎉
Why didn't I think of this sooner
I can't find any samples, god damn
I don't know if I should close this or not.
at the end of the day, Desmume did the trick but it's pretty limited.
I will leave it here anyways tbh
Came back into this
Been a loong while but now I have better instruments