People are really trying to help you but you are not making it easy joesteve1914. You seem to have locked onto two games that would require either tools to be made, half decent skills or strict instructions to be followed which have been generated by someone with said half decent skills, your tenacity is admirable in a way as many of those aspiring to be ROM hackers would have given up long ago but what you are doing is somewhat akin to asking circular questions and that can get quite frustrating for those trying to help. Suffice it to say most of those trying to help will not have been sitting there with all the info needed, tools necessary and whatever else to allow your work to happen but for some reason are not giving it to you, most of the people trying to help though will know exactly what has to be done but even when you know how to do it all it is a long and tedious process done for many games before and these two games are not interesting enough to overcome that.
From the top then
The idea of executables
The results of programming, especially when it comes to leisure activities likes games, are made all the nicer by being able to expand upon what the system/programming language affords and programmers and systems designers alike collude to make this a possibility. Initially these extras were included in the code itself, later files were not in the code itself but still fairly well wedged within it and later filesystems are used to contain the files which can be referenced at will and changed an awful lot without touching the underlying code. On top of that you can have a filesystem/archive within anything else.
There are benefits and drawbacks to each line of logic and all are used in modern programming. The DS is the first Nintendo handheld to use a proper filesystem in commercial games though, which is nice as nearly anybody can explode a DS ROM into the files that make it up, and for various reasons (the big one being the DS cart/ROM is not visible in memory like earlier systems). This makes the vast majority of DS games hackable by those that are far more at home in a text editor or image editor and also helps those that make programs for the former immensely- our advice seems to be find one of those and hack that for there are loads of nice to hack games worthy of being hacked/translated that are not even being looked at right now. Programmers like this too as it means you do not get bugged to build games or have to make things to build games for those working in your art department every time they want to test a slightly tweaked colour for something.
To that end the vast vast majority of DS games will use the filesystem to store almost all their files and may even have archive formats within that for various reasons, the most prominent of the archive formats is NARC (the one Nintendo made as part of their development kit) though DS ROM hackers frequently find themselves up against custom archive formats, but enough of that for the moment.
Recall that the DS cart it not visible in memory like earlier systems, this means you need to store code to be run on the processor in the actual memory of the DS and that would be where the ARM9.bin, the ARM7.bin and overlays (though by definition they come and go all the time) sit.
Just because you can use filesystems does not mean you have to (and there are some possible benefits to not doing this) and the arm9.bin, arm7.bin and overlays can store more than just instructions to be run on the processor. In "good" programming this would probably mean just numbers and tables for the game to reference to work with the instructions, however you are not limited to this and these arm9.bin files can contain all sorts of data and often do. This can go right up to fairly complex file formats like those made by Nintendo for use with their developers kits.
The problem comes in that when things are included in the binary they are visible in memory and will tend to be referenced by their memory location meaning if you make the file bigger you will send everything after it out of line and that is crashing time for games. If you make it smaller and do not pad it back out you will also see the game crash. This is why you can not "convert" it to NARC and expect to get anything useful out of it unless you are planning to do anything more than rip the assets.
Also most tools designed to decode Nintendo and other known formats will expect the formats to start as they normally do, if you feed it a binary and it sees a few hundred kilobytes of data beforehand it is probably not going to know what to do ("smart" programs have little need to exist on the DS unlike earlier systems so most are not programmed as such beyond detecting compression methods). If it is in the binary you can extricate the file with a hex editor (select it and copy and paste into a new file), a file trimmer or something else and feed it to it if you prefer, all this takes no programming skill to do at all if you know where your file is (which if it is a SDK format you do as it will start with a known string and then probably have the length of the file immediately afterwards). Again though when you put it back it had better be the same size or smaller (if it is smaller you need to add say enough 00's or something to the end of the file to make it back up to the size it was before) or the game will crash.
Should you have made the file bigger it depends upon what you are doing as to how you work around it. Typically this requires fairly high end programming skills for normal files like this and a lot of luck (memory is rather limited on the DS)- when editing things that have to go into memory along with a lot of other stuff (which means any time you edit the binary) you really want to keep the file the same size or make it smaller.
There are programming techniques that the original developer could have used to make this process easier (just because it is in memory does not mean it has to be directly referenced as such all the time) but this is an extra step for the programmer to have taken and likely will not have happened for an actual file. Related to this if the file type is a complex SDK one you might get lucky- by design most SDK files will have pointers in them telling you where various sections are and you could abuse this by making it think the file is way off in the distance and the game will then calculate the new location which is still off in the distance but is now elsewhere in memory*, however most of this is a fixed length even if the thing has a pointer so the programmer might have just said skip it and go to good stuff. There is a further complication known as relative/generated pointers which is kind of like the example for the "if you are lucky" thing that is in the line below but I will avoid that for the time being.
*say my file says the good data is at 0200h which is not a memory location the game would read the 200h and add it to the location of the file in the binary (probably something like 2000000 to get 2000200 in memory)- if that number in the header reads 0020FFFF it will instead look at 220FFFF in the memory which might have nothing in at all in the base ROM but your edited one might have that location house your edited files.
On ELF.
When first encountering programming some people wonder how the console knows to start up and what to do when it does and later how it runs programs. This is a fairly simple affair and depending upon what your computer operates like it may end up taking several steps. As not all computers run a single program and are done it gets to be useful to have a method of storing executable code. Enter the format known as ELF, where I said about "programming techniques above" this is not one of them per se but it effects a similar thing to a filesystem on occasion and you can dump things from it (this would be the objdump program). ELF has a long history in embedded device programming, which this is, and though its abilities are not strictly necessary as this is a simple single program system many developers and developer tools will kind of use it anyway. Whether this is the case here I am unsure as I have not really looked at the game yet, it would not be surprising but it is not that common. Equally just because ELF affords a measure of packing still does not mean it was used here, indeed the programmer inclined to include a file like that of an SDK format file on a system like the DS probably would not have done it like that.