I do not know why we are replying to a 2010 vintage thread but I will roll with it and provide nothing resembling a solution but a method to get there (we are in the DS rom hacking section after all).
For what it is worth as far as I am aware the Japanese version was cancelled and tweaking the game to display the Japanese script like this is the only way to do it for this game- it is not a simple option we can select somewhere but an actual hidden thing only unlocked by AR codes (consider it a developer leftover similar to the stuff we were discussing later in
http://gbatemp.net/topic/320192-japanese-programming-madness/ ). This possibly also makes it different to making a more general patching tool for other games that trigger from firmware (I have to analyse the codes) and especially if there is a workaround.
The quick and dirty way is to use DSATM to patch in the codes to the rom.
After this I would look at the cheats and see how they work
From the GBAtemp XML database
Code:
[Advance Wars: Days of Ruin (U)]
Language Mod Codes
1
Japanese
22168F8C 00000000
English
22168F8C 00000001
French
22168F8C 00000002
German
22168F8C 00000003
Italian
22168F8C 00000004
Spanish
22168F8C 00000005
http://doc.kodewerx.org/hacking_nds.html#arcodetypes
Type 0x02
8-bit
2XXXXXXX 000000YY Writes byte YY to [XXXXXXX+offset].
02000000h Main Memory (4MB) according to gbatek (linked in a moment-
http://nocash.emubase.de/gbatek.htm )
2168F8C is then the location. Curiously or perhaps not the codes line up with the firmware/cart header order of names (see gbatek-
http://www.romhacking.net/documents/542/ ).
Rom info thanks to NDSTS
ARM9 source (ROM) 0x00004000
ARM9 execute address 0x02000800
ARM9 copy to address 0x02000000
ARM9 binary size 0x00132438
ARM7 source (ROM) 0x00283800
ARM7 execute address 0x02380000
ARM7 copy to address 0x02380000
ARM7 binary size 0x00026DB8
ARM9 overlay source (ROM) 0x00136600
ARM9 overlay size 0x00000180
ARM7 overlay source (ROM) 0x00000000
ARM7 overlay size 0x00000000
Alas ARM9 copy to address 0x02000000 + 0x00132438 (the size of the binary) gives 2132438 which is smaller than 2168F8C (and similarly for the ARM7 but I did not expect it to be there) and according to crystaltile2 the lowest overlay is found at 02169020 (which is very close indeed and probably chosen for that reason but still not there) so this cheat is not a binary patch cheat and you can not just patch a part of the ARM9 binary or an overlay based entirely upon the cheat. With all the above if I had to guess I would say that is the location the dump of the relevant DS firmware settings was held.
Now the quick and dirty way (my usual preferred way as I am lazy) is to recreate the cheat idea (and what DSATM will most likely be doing) and patch something to constantly write it (I do not actually know if it needs to be constantly written or just there at boot/for a while) probably by hooking into the ARM7 or something (
http://crackerscrap.com/ see documentation).
The not quite proper but still better than constant write method is to find the read function and force it to return a 0 or whatever you want it to be- this would be done by looking for the (hopefully it is just one) function to read it and forcing it to return your value of choice. There are probably slightly more elegant ways and maybe you can exploit part of the underlying function (in your case it might already assume it is zero aka Japanese and just have the function grab and carry from there but if you NOP it it will think it was always 0 or something- such are the options when playing ASM hacker) but that you will have to see once you see the function. There might be further implications in that you have to force the bit there (realistically it should have just let you use Japanese- forcing it to another language almost certainly took extra code to do) but cross that bridge when you come to it (or not if it will be a pain).
The proper doing the job properly method is to find the thing that triggers the initial read function and stop it from doing a read at all and just using whatever you would have forced it to use.
The crazy man way is to physically repoint everything but that is just silly, for many language set requests like this though we see the related method of deconstruct the rom and swap all the files out manually or relink them but this has troubles for some games if they change the font or text handling (Japanese to Roman character or other small glyph set languages being especially prone to it- see 16 bit to 8 bit text conversion hacks). The crazy man's genius cousin's method comes when the number here probably informs which pointer table to use for text and just jump straight to that but at this point in time you are just optimising the hack/game and probably only by about 20 instructions at best and probably about as many clock cycles when it comes down to it (most of which are probably already wasted displaying the company logos).
I imagine it is a fairly similar method for any game that reads the firmware settings to choose a language.