ROM Hack Extracting file (.sdat) from arm9.bin

[Hiccup]

A few games (e.g. ds download demos) contain their files in arm9.bin. How would you go about extracting these. I have found the string 'SDAT' in a hex editor, but I don't know how to go from there.

 

[FAST6191]

I often still find the demos have the sdat files as a separate file. Equally I would not read too much into finding a string of SDAT in a arm9.bin -- though it is certainly possible you do also see general strings that are also magic stamps of known file types in such things.

Anyway if it is a proper SDAT file then there will be a nice filesize value (it will be SDAT, 0100feff in the hex section and then the file size). It is how I tend to find things if a dev buries a SDAT in an archive file. Changing the file size within the ROM is trickier if you are increasing the size (less or the same and you just insert a file the same size as the old one).

 

[Hiccup]

I just really want to extract files from ARM9.bin.

I can find the start of SDAT files (I think), but finding the end seems to be a bit harder.

 

[FAST6191]

If you have the uncompressed arm9.bin then the size of the SDAT file is right there in plain text (well endianness aside), if you have the size and you have the start then it should be trivial to rip it from the file.

 

[Hiccup]

It seems to be uncompressed (as EFE throws an error when trying to decompress it). I've found the text 'SDAT'.
This is what comes after:

 

[FAST6191]

Looks like a SDAT file to me (SYMB a few lines after that is the symbol block and the usual thing to come after SDAT), should not have any compression either judging by the amount of 00000 in that.
https://sites.google.com/site/kiwids/sdat.html?attredirects=0

The Header appears at offset 0 in the SDAT file. All offsets in this structure are absolute offsets.

typedef struct tagSDATHeader
{
	struct tagNdsStdFile {
		s8  type[4];   // 'SDAT'
		u32 magic;	// 0x0100feff
		u32 nFileSize;

From that picture it is e0780700 or read properly/accounting for endianness it is 0007 78e0 hex long, or just shy of 500 kilobytes which is pretty reasonable for a download play game (it kind of has to fit in 4 megs after all).

You can slice it out with a hex editor (I do not recognise that one but such things are features of various free editors), a file trimmer or whatever you like really.

 

[Hiccup]

Sorry for my ignorance; how would I use the hex editor to count and select 0007 78e0 (bits/bytes?) after the SDAT header? I'm using the limited version of 'Hex Editor Neo'.

 

[FAST6191]

Can't say I have really used hex editor neo
https://gbatemp.net/threads/rom-hacking-hex-editors-mid-2012-discussion.326873/ has my list of hex editors I suggested for ROM hacking uses and I have not really added or taken anything away since then, the freeware suggestions in that will probably be better than trying to get by with a nerfed version (I have never seen a demo version of a hex editor that I can suggest for day to day use).

The count is from where SDAT starts rather than after the header. Many things do count from the end of the header but in this case it is the size of the whole file.

Good hex editors will tend to have the option to select a block of a given size, at which point you just copy that and paste it into a new file. For a lesser editor I would probably go to the start of the SDAT file, select everything before it and delete it, go to the end of the SDAT file (which should just be the size of the file if you have deleted everything before it) and delete everything after. Save this as a new file and read with your chosen SDAT reader.

 

[Hiccup]

I've sent you a PM with a video showing you what I've tried.

 

[FAST6191]

Frankly most SDAT readers will not care about the extra stuff at the end.
I saw the video, for the most part it just looked like HxD being fussy about the inputs (I probably should not have left the space in the middle there, some will even want you to put a 0x in front of it to make sure it is hex but the editor looks like it gives you a choice) and you did pretty much what I would have done.

It might be that the sdat from the game is a slightly cut down one compared to normal (might be missing some blocks to make space or something), if that is the case and you do not want to write your own reader you may have to pull the files from it and then inject them into a working format. This is potentially quite tedious but still nothing major.

I am surprised VGMtoolbox did not play ball, what about vgmtrans https://gbatemp.net/threads/newest-vgmtrans.123463/

 

[Hiccup]

VGMtrans will play it, thanks!

I'll try to inject it into another sdat (replacing a range from 0-0007 78e0), but I can't find one big enough. Can you think of a game with a large sdat?

 

[FAST6191]

If VGMtrans will play it then injection is less useful. Equally it might not be as much a large SDAT as what is within yours -- 500 kilobytes is nothing for a SDAT file, especially if it has the STRM stuff in it, but if the one you just ripped has many tracks or many banks, complex arrangements and fiddles with things accordingly then you might instead be looking instead for a SDAT that features enough of those to be useful. There are tools to rebuild a SDAT from scratch but I do not especially rate them.

Tinke is probably the best tool for injecting things into SDAT these days, though crystaltile2 can be persuaded to work sometimes and I must confess I have not tried the new and improved vgmtrans for this sort of thing.