The ARM7 swap was designed for when your flash cart had not updated its save handling routines for the newer games yet. It has no bearing on this which is a badly programmed game causing troubles. The crashing can be quite random, though you can usually find something which will force it.
The only patch I have ever seen floating around the internet was the sound muting/nerfing patch (several variations on the theme actually) which might work but is not ideal by any means. Most other flash carts added the fix mentioned to their loaders, though some took a while.
Making that into a patch. I did cover some of the things.
All those values are memory locations, you might just be able to get them in as cheats on your flash cart if you wanted ( http://doc.kodewerx.org/hacking_nds.html
For a proper patch though.
The DS cartridge is not visible in memory like the GBA and 16 bit and old era consoles. For commercial games it copies the ARM9 binary to RAM, the ARM7 one to RAM and occasionally loads other binaries into sections of memory (a process known as overlays).
The main memory, where most of the binary work is done and where they will be loaded, is located at 02000000 in the memory bus ( http://problemkaputt.de/gbatek.htm#dsmemorymaps
The binary will not necessarily be loaded into the start of that section though, however where it is loaded to is known to the ROM which is why I mentioned header programs like ndsts ( http://www.no-intro.org/tools.htm
With that you can find where the binary is loaded into memory.
From where if you know where it is located and what the patches change at those locations it is simple maths (or if you were really bored/your hex editor does not allow setting virtual addresses I guess you could append the binary to a blank file to make it appear in the "same" location) to figure out where to put the changes that the source code below notes.
Things that might trip you up.
1) I mentioned compression before. For whatever reason sometimes the DS binaries are compressed in the ROM and decompressed to work. They tend to use a known type of compression called BLZ, though many refer to it as DS binary compression. Cue's compression tools can handle this. I should also say Crystaltile2's DS ROM filesystem window has spotty detection of compression at times and it will say things which are not compressed are actually compressed, though at the same time its extract and decompression functions (right click in the filesystem window) will spit out the same file either way.
2) I am not sure offhand what endianness the payload parts of that are. Easy enough to test both ways though, and even if it was not then the disassembled code would likely not make any sense if you got it wrong.
As far as making a patch then IPS might work in this instance (it is an in place patch of a section likely to be less than 16 megabytes into the ROM) but it will be one of the few in the DS where it does. You would be better off making an xdelta patch or one of the other good formats.