ThomasWii said:
I wonder if it would be able to convert .DAT to .nds (yes) then decompile the nds, play with the code, compile to nds then to to DAT? That might work.
There's a commercial disassembler available - IDA Pro - that's about US$500.
Steps, roughly, would probably be something like:
1 - Decrypt using Yasu's tools
2 - Point something like dsbuff or some other unpacking tool at it to unpack it
3 - Run a disassembler over it (after having paid half a grand)
4 - Work magic, with insight acquired into ARM Assembler code though much careful research and practice
5 - Re-pack
6 - Re-encrypt using Yasu's tools
The steps I have trouble with are the ones that require money and special skills and knowledge - 3 and 4. Everything else you can do with free stuff and no special knowledge.
I suspect that if it was easy to get the loader out of the R4 code (as Yasu managed to do with the DSTT loader for YSMenu) that someone would have already done so. Not that anyone seems to have had much luck at using the DSTT loader separately yet anyway...
It might be easier for someone to do something like the following:
1 - Build a loader that will work on the R4 (easy enough - FlashCard OS, DSOrganise, DSBrowser and DS-DOS and the like can probably all be DLDI-patched for the R4 and encrypted to start up)
2 - Devise a way to dynamically patch the R4 menu so that the default file is changed from "default.nds" in the root directory to whichever file you wish to start, and start that patched R4 menu - which, in turn, will load its default program. This would be done in place of the standard loader used by the menu system chosen as the basis for this.
Ugly and cumbersome, and it would be relatively slow on loading (patch operation, load patched R4 menu, run "default file" patched in) but it could provide a means to load whatever you wanted through whatever menu system you wanted... a hacked DSOrganise, a moonshell-based menu, whatever.
It's a pity FAT doesn't support links - if it did, it'd be dead easy to do something like:
1 - See if default.nds exists - if it does, remove it
2 - When a file is selected for starting, link it to \default.nds and link its .sav to \default.sav and run _DS_MENU.NDS (a decrypted _DS_MENU.DAT) which will load the default
Something approximating that could be achieved by:
1 - Checking to see if a previous move/load operation has been performed (maybe in a file called something like lastloaded.inf), and moving default.nds and default.sav back to their previous names and locations - this is necessary so they'll show up in the menu in the correct location and as their correct name, and to ensure that previously used software and its save files are preserved.
2 - When something is selected for starting, moving the desired .nds and its corresponding .sav to \default.nds and \default.sav (and maybe creating a .sav file if one doesn't already exist)
3 - Starting _DS_MENU.nds (a decrypted _DS_MENU.DAT) which will load default.nds
It'd be as slow as the move operation plus the entire R4 menu/autostart operation, and would rely on the moves happening correctly, but it would work without having to make any changes to the official firmware. It's an a approach that theoretically should be able to be applied to many other cards too, provided you have a copy of the official menu that can be run as a .nds and the menu that boots first ignores \default.nds