1) I doubt is is encrypted as not much is (I am struggling to think of examples on the DS) but what it might be is compressed but more on that in a moment.
How people find text.... various methods. Most of the time file names, extensions, directory names, size and elimination (if it is not sound- usually a file with sdat as the extension, graphics- many extensions but still quite obvious or level data- harder but still sometimes obvious) give up text data.
You do however have more programming oriented methods ranging from conceptual but easier and not sure fire to messing around with game code and a sure result.
Before going on I assume you understand the idea of text encoding but the one paragraph summary is computers only understand binary signals which get stacked for form hexadecimal. To this end computers use codes to convert hex to letters (think back to your childhood and the code a=01, b=02, c=03......) and there are hundreds of methods and prior to the DS they were usually custom for each game or occasionally company. The most common methods seen on the DS are ASCII, unicode, EUC-jp and for Japanese games at least shiftJIS but again it can be custom. You have to text your viewer to decode using one of these methods and you tell it how to by giving it a so called table file.
Assuming you have not lucked out and got a bunch of text in shiftJIS or some other known/common format you get to do some stuff.
The lines between finding where the text is housed and how it is encoded get a bit blurred but it is all good stuff to know. Japanese poses a minor problem as some of the methods revolve around languages and computer implementations of them.
Methods include
Corruption- you quite literally corrupt parts of the rom and run it. When you encounter dodgy text you have just found where the text is housed. Once you have this I like to put either runs of a single character in there or counting upwards so when I next play it and see something like "one day I aaaaaaaaaaaa" or "one day I abcdefg" I can line it up against what I did and start figuring out more.
Mathematical analysis- space is probably the most common character, vowels have to appear in just about every word... Guess parts of the code and the rest tends to fall into place.
Relative searching (typically not available for Japanese as it has not set order unlike the Roman alphabet even in the kana and games do tend not to include every kanji there ever was and there is definitely no defined order there)- in the a=01, b=02... code mentioned back a bit each letter is encoded one after the other give or take a jump for capitals so you can take a line of text from the game (longer is often better) and run it through a relative search tool (I like monkey moore although crystaltile2 has some abilities here) at which point it will find all things that match the pattern in the rom and often with it find out a good chunk of the encoding. You can live a bit more dangerously and assume that the word "the" or some other common phrase will appear and do a search for that.
Fonts can be useful here- sometimes they will contain encodings but other times you can try to line things up against a font- even if it is in random order in the game it will often match the order in the font.
Save editing and name entry- kind of based on a encryption attack/property called known cipher text or chosen cipher text. Here you create a bunch of saves with different names for your character and often the method by which it is encoded will be the same as the game proper at which point you can guess or at worst start filling out the table and with it lay it against the rom to see if you find anything. Bonus here is if you have an entry screen you can put whatever characters you like in memory and watching it change when you do often has similar results with regards to opening things up.
Memory influenced searching- find the text in memory and you can give searching the rom a go but that is not ideal if you are facing compression. You can also try poking values here around but often by the time you find it in memory it will already be displayed on the screen so changing it is not going to do much.
Proper ASM hacking- you find the text in memory (not so useful) and trace it back to the game itself- it will have had to have a command to put it in memory, you find where that command originated and again and again until you are staring at a location in the rom (and so a file)
There are more methods covered in far more depth in various romhacking guides but now you have an overview you can hopefully start looking around and refine you methods.
As for compression game text is not exactly conservative when it comes to using space so files get compressed for storage which troubles many of the methods here. Fortunately most compression is based on known concepts and predefined methods so you can use something like
http://code.google.com/p/dsdecmp/ and cut through most of it. I should also mention text can and often is found in the binaries (arm9.bin and arm7.bin although less so for the arm7) and overlays if they exist/are not 0kb in size.
To answer the following question of how do I make the space for the extra length you need to read up on pointers but the short version is as far as most hacking is concerned they are like the contents page of a book- chapter (or paragraph) ? starts at point X in the rom. There are tweaks and some roms do not use them at all but that is covered in guides to pointers. If for some reason the game does not include the Roman character set you need to go hunting for the font. In DS games this is usually a simple image or a custom format known as NFTR
http://gbatemp.net/t105060-nftr-editor
2) I can not speak for every rom hacker but I usually walk into such things with my standard rom hacking tools
A hex editor (or nine)-
http://www.romhacking.net/?category=13&...itle=&desc= ,
http://filetrip.net/f23649-CrystalTile2-2010-09-06.html , hex workshop, xvi32, HxD, xways/winhex and more are available. Most rom hackers will have a bunch at their disposal.
A method to pull roms apart (if the roms can be pulled apart which all known DS roms can be)-
http://filetrip.net/f23649-CrystalTile2-2010-09-06.html again although you also have the likes of nitro explorer
http://treeki.shacknet.nu/ , ndsts
http://www.no-intro.org/tools.htm some tools in the line below and ndstool (frontends in dslazy and dsbuff).
A higher level tool- I mentioned crystaltile2 several times already but recently we have seen a couple of nice newer ones like tinke, lowlines console tool and
http://gbatemp.net/t299444-mkds-course-modifier
A tile editor- agains crystaltile2 but I also like
http://home.arcor.de/minako.aino/TilEd2002/ . It needs to support GBA 4bpp and GBA 8bpp (some older ones skimp on the second format).
A list of known formats and concepts- see most rom hacking guides for lists but
http://www.romhacking.net/?category=&P...itle=&desc= is a start.
I have loads of little tools in addition to this but those are the ones I walk around with.
Specifically when dealing with Japanese I like to have a nice Japanese text editor to hand
http://www.njstar.com/cms/njstar-japanese-word-processor is nice but I also like having
http://www.physics.ucla.edu/~grosenth/jwpce.html around. One of the "little tools" I like for this is
http://www.romhacking.net/utilities/504/
3) If you mean part of the games logic and not just specific text remember the "proper ASM hacking" part- pretty much that but for what you want rather than text (there is a reason hackers capable of playing in ASM are held in high regard even among other rom hackers). You might get lucky and find something like
http://www.pipian.com/ierukana/hacking/ds_evos.html (indeed it will probably even boil down to modding something as simple as that) but to get there will probably see someone having to put in the spadework to get there.
