ROM Hack How to view DS Demo's filesystem?

[Hiccup]

The way they have been dumped seems to have made their file system unreadable by Nitro Explorer (latest version 2b) and similar software (like NSMBe).

 

[loco365]

First of all, that link is illegal.

Second of all, they're just encrypted, if memory serves. Decrypt them with eNDryptS.

 

[Hiccup]

From the page:
"Legal disclaimer: I am putting these online in good faith that Nintendo and the respective copyright holders wish them to be distributed, as they are only demos, and are not (and have never been) sold anywhere."

Thanks for the answer.

 

[Hiccup]

It said that it got decrypted, but it still cannot be viewed in Nitro explorer or similar.

 

[Hiccup]

These demos have all their files inside arm9.bin and/or overlays (not in the filesystem). How can I extract and re-insert files properly?

 

[FAST6191]

Just arm9 or overlays as well? I have seen games include everything and end up with hundreds or even thousands of overlays before but all in the ARM9 (save for sound I assume) is new.

Back on topic..... with a hex editor usually. If they are packed into/included in the ARM9 it is probably not going to be with a proto filesystem or anything like that and will tend to be referred to directly by memory addresses (which you will also have to fix/change* if you make the file bigger, you also then get to juggle memory and possibly find some free space in the memory to hold things**). If they are known formats or conform to the normal DS standards (magic stamp plus file length) then you usually have a nice start of file indicator and a length of them which helps immensely, they tend not to be doubly compressed either (only binary compression across the whole binary as it usually is) but it might happen in the case of something that has to get to the VRAM instead.

*dynamic/calculated pointers are also a possibility here so you may have to run/observe the game to make sure this does not happen.

**I occasionally fish nice long wifi error messages in several languages out of binaries, this can provide a nice bit of space for you to reclaim.

In short it is actually closer to classic ROM hacking really (everything is known to the game at fixed locations and probably memory mapped too, you have to figure out the pointers to them or hope you do not make the files bigger) but with the twist that expanding the "ROM" is a nightmare most of the time when the "ROM" is a DS binary. Trying to find free memory at runtime on the DS.... well there is at least a tool to help you http://gbatemp.net/threads/unofficial-desmume-build-unused-memory-finder-tool.349332/ or if you prefer a slightly more manual methods then DSATM has an option to patch the ROM to change all unused memory to DEADBEEF ( http://filetrip.net/nds-downloads/utilities/download-dsatm-434-434-f27609.html and that is the last version with the functionality, later versions dropped it).

If you really want I have been toying with the idea for years but never put it into practice really. If you can get a GBA slot device then you gain up to 32 megs of very fast memory mapped memory, possibly even writable if you work at it. Somewhat larger than the DS' 4 megs.

 

[Hiccup]

Well.. there may be stuff in the overlays as well.

I'm not interested in creating new files, just replacing similarly sized files with each other and extracting files.

I'm not quite sure how to find the start and beginning of files.
I know the final game uses various unknown file formats. The only known one used in the proto and final is SDAT.

 

[Hiccup]

These demos have all their files inside arm9.bin and/or overlays (not in the filesystem). How can I extract and re-insert files properly?

 

[rastsan]

not all demos listed have what you are saying.
dump the memory and take a look. those pointers - point to some things you might need. ie raw data. Use the pointers with file cutter and dump what you need. use fast6191's guide to look these terms up if lost. (or the file cutter thread)...

 

[Hiccup]

Where can you get file cutter, and how can you differentiate the pointers from the rest of the hex in the memory?

 

[FAST6191]

http://crackerscrap.com/index.php and click on projects, it is towards the bottom though a page search will bring it up as well.

If there are no magic stamps or something equally nice (no pointer table in memory or something) then you get to debug the game to figure it out. This is an awful lot of work to go for to play with demos, if you want to rip things (though I am not sure what there is as far as demo specific stuff goes) there are easier methods using emulators and tile viewers, sound recorders and whatever else. Equally you could approach it instead like a normal tracing session when you are after something specific rather than trying to decode an entire game (as part of it you may find you can decode it but who knows at this point, it might even very between the demos), seen as it is all in normal memory as well you even dodge the more annoying aspect of DS tracing where you have to watch functions or ROM read commands to see where in the ROM is being read.

Possibly bonus as you say you have SDAT. This is always nice to see in games as it tends not to be compressed (no point compressing wave files and it also makes handling it far more tricky). This means you might be able to find the SDAT, find whatever points at it in memory and then get lucky as it is also next to the rest of the stuff to handle file locations (I did exactly that to help decode El Tigre Make My Mule and Touch Detective.

Short version is you find yourself playing at one of the deeper ends of the hacking swimming pool, if there is an easy method (and there could be) it will first involve blazing a trail and that is unlikely to be easy in this case.