[h2]GBAtemp thoughts and links 10th February 2012[/h2]
4 things every good DS flash cart owner should know about rom hacking.
Welcome back to the GBAtemp thoughts and links series- for that are just joining us (we have been on a bit of a hiatus) this series will be used to share news, links and articles that might not warrant a full portal post as well as trial runs for new series and one off articles. This edition we aim to cover very quickly four rom hacking techniques we feel should be known to anyone that wishes to claim they know how to rock a DS flash cart.
It should also be mentioned it is quite easy to find yourself well into full on rom hacking territory but the corollary of that is with a bit of learning you can find yourself doing proper rom hacking (pull apart a new format/game previously untouched and you then become the expert on said new game/format for a while at least) and if you are good at translating ideas across disciplines then when you approach a new platform much of what you might know from here applies. For an example here is the GBAtemp thread from when the first public wii filesystem decryption/parsing tool became available- it would be about a month before we could run any of this code (and then only by remaking the iso and burning it to disc) but it only took hours for things to start being decoded.
A knowledge of what hexadecimal is will help in the long run but most of this can be done as long as you know hexadecimal is a number system used in computing as it scales up from binary (1 and 0) far more easily than decimal numbers (it is why the limits on items you can carry, stats you can have, health you can have and more is often 255, 511 or some “multiple” of it) and that any half decent calculator (or indeed a piece of junk like windows calculator in scientific mode) can convert between decimal and hex. Equally although some of these methods do not take much thought power once you know the underlying methods they can still take a long time to explain so for the initial post the rough concept will be explained and more advanced stuff linked up as necessary.
[h2]1)Rom patching.[/h2]
Most of you reading would be probably borderline offended if we assumed downloading a text document in a zip file, extracting it, editing it, zipping it up and uploading it again was an ability you lacked (if it is do go and learn how as the coming decades will be somewhat easier if you can pull it off) and patching roms is actually easier than that not to mention as the flow of new releases for the DS has all but ceased it is left to the increasingly large number of hacks and translations to fill the gap. Patches have various formats with various strengths but in general there are five main types seen on the DS. It has been noticed many are somewhat loathe to use the command line in general (if you recall the bracketed text a line or two up then add in command line for a similar sentiment) so if a base program is command line we will try to link a windows GUI without any serious dependencies on .NET, visual basic or worse.
IPS- very old and has serious issues on the DS (it does not do well when you move sections about the file and it has low size limits in most implementations) but the odd hack might use it and is the dominant type among most earlier cartridge based home consoles so definitely worth knowing about. GBA roms (and other things with a bit of fiddling are taken care of quite well) with GBATA but Lunar IPS works quite well otherwise.
UPS- made as a successor to IPS it has seen a few uses and is increasingly popular among GBA hacks. Tsukuyomi UPS is a fairly nice patcher but check that site for others if you wish.
xdelta- IPS had long began to show its age by the time DS hacking started to produce patches and xdelta was around to fill the hole, it has seen a few versions but backwards compatibility has been maintained quite well and if not older versions are not that hard to source.
Delta patcher and xdelta UI are nice GUI driven tools where here is the xdelta googlecode site.
bsdiff- originally saw use in scene trainers (a few do exist) and outside hacking it is often considered xdelta's foremost competitor but among rom hackers it usually makes little difference and can simply be that is what the hacker had on their machine when it came to make a patch.
bsdiff project homepage, various GUI programs exist as well.
Custom- these usually come in an easy to use exe or custom patch format for use with another tool. Generally they are based around the DS filesystem mentioned elsewhere in this article (some “cheat” and combine a file system manipulation program with more conventional patching) and can achieve very small patch sizes and/or custom patching (change the text but not the audio by selecting an option) as a result (the others mentioned are very much rooted in the general file patching world). The only real trouble with some of these is applying them on non windows systems (the other four are well documented and often started life as unix projects of some form so with a bit of thought can be applied on just about every platform out there).
Also ran- PPF which was made for the original playstation and has enjoyed some success on the wii (which unlike the DS pretty much requires custom patching methods or the end user to handle the wii filesystem) but not much use has been seen on the DS.
On top of this you can also download one of the many all in one patching programs (naturally most will not feature the custom formats) that will usually handle IPS, xdelta and Bsdiff. The only real downside to these GUI programs is sometimes they will lack the ability to make patches as well as their format specific brethren. romhacking.net's patching tools list has several things that might be of interest as well.
On the subject of patch making it is usually a minor tweak on applying a patch in the first place so read the help sections of the patcher you want to use (unless you can argue otherwise we suggest xdelta or bsdiff). Be wary though if you are going to say undub a rom or modify an existing hack that it can be frowned upon to release a patch containing work from someone else (one of the main reasons you do not see many undub patches around) and if patching a patch you might want to consider building your patch against the initial hacked rom (apply the original patch and then making your patch turn the hack into what your final rom image looks like).
[h2]2) File system manipulation.[/h2]
All known DS roms use the nitro file system aka nitroFS aka the DS file system. Some roms stack things on top of this (the first Phoenix Wright and Tony Hawk games being prime examples) and use archive formats (the format known as narc/carc being the official one but many other formats exist and most formats have a measure of it if you want to be a pedant) but at the heart of it lies the DS filesystem and most roms can have something done with this.
The initial uses for this was to reduce the size of roms (most people were still dealing with GBA era devices where a size of 256 megabytes was top notch and 32 megabytes was average)- you could slice the later levels from a game, still play the first set and swap to the later ones to play the rest (it also follows that in some cases renaming a file for another can lead to things being done in the “wrong” order,- a bit of minor rom hacking (Electroplankton uses straight up wave files such as those that can be made with most audio editors) and swapping out the audio with a smaller roms. Somewhere along the line undubbing appeared on the DS where what usually happens is the Japanese sound files are sent into the North American or EU release of a game to allow Japanese audio with English (or such) text.
The usual process of undubbing amounts to finding the file with the extension .sdat in the Japanese rom (more often than not sound_data.sdat), finding the equivalent in the NA/EU rom (if you have to rename it then do so), swapping the files out and rebuilding the NA/EU rom. The vast majority of DS games use SDAT but there are others although same logic often applies there (find Japanese sound and use it replace the NA/EU release's sound).
This basic technique works in the vast majority of cases and where it fails it is usually down to the rebuilding stage not working (ndstool and by extension dslazy and dsbuff have long been demonstrated to butcher roms so instead we have nitro explorer) but occasionally the localisation process can introduce some large changes to the rom necessitating a bit more thought/proper hacking.
Tools of the trade
ndstool (originally a part of devkitarm it was built for homebrew but works on many roms as well). Today is it mainly a legacy tool but when combined with a batch file containing the full extraction command it is one of the quickest and easiest ways to explode a rom into the files that make it up and it still works well enough for putting a rom back together.
DSBuff (a .NET frontend to ndstool and a few other programs)
Nitroexplorer made to work where ndstool fell short.
ndsts which unlike the other programs before it can only replace it with files of the same size (nothing stopping you padding a file out a bit) so if you edit with this and make the rom crash or error out it is purely your editing that caused it.
Many GUI driven tools (discussed later) also feature abilities here.
Crystaltile2
MKDS course modifier (not just for Mario Kart any more)
Tinke
[h2]3) Basic cheat making and concepts.[/h2]
Now the cheat making contingent of GBAtemp and elsewhere do some amazing things at a very high level and in the process often exploiting cheat devices and engines beyond far what their designers probably envisaged (things like patching the actual game code in ram as opposed to values that will be being discussed here) which leads to many raising an eyebrow but the basic ideas of cheat making we hold should be known to all and knowing how cheats work will allow you to tweak existing ones to your advantage.
First for the purposes of this post knowing how to add cheats to the database your cart uses (for most carts/loaders means R4CCE for which we have a nice guide on the forums) will fall under basic flash cart management rather than hacking.
Cheats in this meaning of the term rely on the idea that games will allocate a small (hopefully static) location in the memory to hold the value for lives, ammo, money, health and more. The basic cheat making concept is to get an emulator or device capable of viewing the memory and then attempting to change the value noting every change in the memory- theoretically if you repeat this enough times and eliminate anything that did not change between scans you will be left with enough values to conduct a bit of trial and error upon (hold the value static/constantly rewrite it with a value) and see if you have your cheat- in practice cheats are usually variations on constantly writing a value, check and then write a value and check a point to see where the value is found and then use it to direct the former two. Usually in such searches you can search for specific values, higher than/lower than values, values that just went up or just went down, just note things that changed allowing the search to be refined as you go. We do wish to note that the value displayed on a screen and the value in the memory need not be the same thing.
DSTWO/ISMM owners can make basic cheats as well as more advanced ones if they have the patience with their cards (a nice youtube video is available on the subject) but others will require the likes of Datel's Trainer Toolkit if continuing to use hardware or on the software front desmume (do note there are considerably newer SVN builds if you do a quick search and the developer version might be a better place to look) has some nice abilities and is presently about the only DS emulator to continue work on newer titles.
Cheat engine/device developers can reasonably assume this arrangement so they make cheat engines that decode small lines of numbers to tell the cheat engine where to attack, what sort of attack and what the attack payload, if any is necessary, should be. Some guides are available on the cheats forum linked above and a reasonably complete listing of code types can be found on enhacklopedia (DS version and GBA version available among many others).
Most cheat makers will assume you want infinite/maximum lives or silly speedup in the case of experience multipliers where you may simply seek to rebalance the game a bit (making it easier, harder or gearing up for a certain “run”) so knowing that you can hopefully edit a cheat to change it to be closer to what you want to do.
Game developers occasionally dislike cheats being applied to their game and may lay traps for the amateur cheat makers (ranging from simple mirrors of the required value to things that are easier to work around when you have low level programming experience) and additionally the memory that will eventually see the health value or something may well be used earlier when the game is booting up or in a different mode so you might have to cater for this (if your cheat device allows cheats to be activated at any time then that is good) and often this is where it gets trickier and you will probably want to consult a more in depth cheat making guide. When you do want to get a bit more advanced you might consider Cracker's DS hooking tutorial.
Additionally cheats by their very definition get games to do things they were not designed for so you may find the cheat maker made decisions for a reason to dodge an issue with the game code (the reasons can be technical or gameplay related (think the JRPG cliché of the fight you have to lose to continue the story)).
Do note that tweaking existing cheats and releasing them as the fruits of your own hard graft is considered exceptionally bad form so state where you got your intial cheats if you do decide to rerelease them.
[h2]4) Tool driven file editing.[/h2]
Engineers (software and otherwise) really dislike having to design new things and as time goes on it becomes increasingly unproductive to design new things all the time which is a phenomenon that very much applies to software (we have long since left the point where it is possible to know everything from the ground up) so to make things easier Nintendo and other companies will design formats to do basic things (hold files, hold images, hold music/sound effects, hold video, hold text and more) that various game developers use (across many titles and companies no less) that rom hackers then see, pull apart, document and either build tools to view and manipulate or provide sufficient documentation that anyone with basic tools can modify.
As the line above implied there are two main schools of thought on this this subject 1) Nice GUI tools that can be applied by anybody with a mouse and 2) information that can be applied by anybody with a bit of knowledge but not being limited by GUI options quite a bit more can be achieved (or continue to be achieved when the formats change/reveal a hitherto unknown feature/limit). 2) probably falls just outside the “everybody should know” thing but many of the tricks can be done by someone with next to no knowledge of what is going on so they are being covered alongside this.
The four main hacks here are sound editing, graphics editing, game editing (possibly related to cheats above but level editing is also possible) and text editing.
Sound editing usually takes the form of what are technically called repointing hacks where you get a game to play a different song (or no song) to the original rom. Ripping and conversion tools for sound injection can be found but most of DS sound hacking still revolves around a person and their hex editor.
A quick guide to repointing style hacks can be found this thread
SSEQ injection is covered fairly well here (SSEQ is the "midi"/tracker style sound component of the SDAT format and the main source of music you will hear in DS games).
This thread covers some of the ideas behind looping the SSEQ audio. It is arguably doable with just a hex editor and knowledge of SSEQ commands but easy enough to follow along and is a fairly nice primer for editing some of the other commands available for the SSEQ format.
The various audio formats of the DS thread was already linked up but covers some of the basics of the more exotic formats seen on the DS.
Graphics and other editing
GuardianSoul's "The Ultimate Nintendo DS ROM Hacking Guide!" features usage guides to crystaltile2 that alongside a tightly integrated hex editor and tile viewer/editor all with DS filesystem support does also sport the ability to decode and subsequently do things to many DS formats.
Jewel's site has another guide to CT2.
Although now featuring abilities of a general editor MKDS course modifier does have serious abilities when it comes being able to modify the game it is named for.
Romhacking.net has several tools geared towards specific games and the pokemon series is noted for the abundance of game specific tools (as well as being somewhat above average in terms of difficulty when it comes to pulling apart the formats within it).
Leaving things you do just clicking on buttons in a program comes simple format hacking- here you can read off where a value should be in a file (or the location of the data that tells you where it is) and edit it accordingly
Romhacking.net's library of DS related game formats
Lowline's format page (Author of the console tool program and a great example of the kind of concepts you often encounter in DS formats).
You might be forgiven for thinking there is a gap between being able to hex edit something and having a program to do it for you (and a lot of rom hacking is very tedious when it comes down to actually doing stuff) which you would need to be able to program for which is not actually true with various people attempting to make programs and formats to define other formats by (hex editors like hex workshop support formats and general hacking tools like tahaxan and the console tool have tried to add support for user defined formats over the years) and you have tools like ROMulan which heads towards general programming in terms of complexity but stops short of needing to actually know how to program. Equally many rom hackers will abuse spreadsheets (modern ones have fairly decent hexadecimal support and have long had great abilities when it comes to doing repeated basic manipulation of the numbers contained) and search results of their hex editor to do a lot of their grunt work.
If you want you can also learn to apply simple compression tools ( dsdecmp and CUE's compression tools are two of the best for the GBA and DS) to handle compression as most times compression once it is known to be present (by the way compression is also quite easy to detect a lot of the time) amounts to a single extra stage for each file going into or out of a rom (you decompress it when pulling it from a rom and recompress it before it goes back in). The most common type of compression in GBA, DS and often further afield is LZ compression and most modern tools handle the known/common types of LZ along with the less common compression formats/types (huffman and RLE/run length encoding mainly).
[h2]Closing thoughts[/h2]
One of the marks of a good hacker is the ability to combine methods together to pull something off- for example if you are resorting to ripping the sound via an audio out somewhere you can change the level design or files themselves to play the ending theme in the first level (or somewhere where it is quiet) rather than play the whole game through. Equally you could make a cheat to allow you to speed through a game to get to a place where you need to perform your hacks. If you want further clarification on any of the points raised feel free to ask it in the discussion below or if you think it warrants it then make a thread.
4 things every good DS flash cart owner should know about rom hacking.
Welcome back to the GBAtemp thoughts and links series- for that are just joining us (we have been on a bit of a hiatus) this series will be used to share news, links and articles that might not warrant a full portal post as well as trial runs for new series and one off articles. This edition we aim to cover very quickly four rom hacking techniques we feel should be known to anyone that wishes to claim they know how to rock a DS flash cart.
It should also be mentioned it is quite easy to find yourself well into full on rom hacking territory but the corollary of that is with a bit of learning you can find yourself doing proper rom hacking (pull apart a new format/game previously untouched and you then become the expert on said new game/format for a while at least) and if you are good at translating ideas across disciplines then when you approach a new platform much of what you might know from here applies. For an example here is the GBAtemp thread from when the first public wii filesystem decryption/parsing tool became available- it would be about a month before we could run any of this code (and then only by remaking the iso and burning it to disc) but it only took hours for things to start being decoded.
A knowledge of what hexadecimal is will help in the long run but most of this can be done as long as you know hexadecimal is a number system used in computing as it scales up from binary (1 and 0) far more easily than decimal numbers (it is why the limits on items you can carry, stats you can have, health you can have and more is often 255, 511 or some “multiple” of it) and that any half decent calculator (or indeed a piece of junk like windows calculator in scientific mode) can convert between decimal and hex. Equally although some of these methods do not take much thought power once you know the underlying methods they can still take a long time to explain so for the initial post the rough concept will be explained and more advanced stuff linked up as necessary.
[h2]1)Rom patching.[/h2]
Most of you reading would be probably borderline offended if we assumed downloading a text document in a zip file, extracting it, editing it, zipping it up and uploading it again was an ability you lacked (if it is do go and learn how as the coming decades will be somewhat easier if you can pull it off) and patching roms is actually easier than that not to mention as the flow of new releases for the DS has all but ceased it is left to the increasingly large number of hacks and translations to fill the gap. Patches have various formats with various strengths but in general there are five main types seen on the DS. It has been noticed many are somewhat loathe to use the command line in general (if you recall the bracketed text a line or two up then add in command line for a similar sentiment) so if a base program is command line we will try to link a windows GUI without any serious dependencies on .NET, visual basic or worse.
IPS- very old and has serious issues on the DS (it does not do well when you move sections about the file and it has low size limits in most implementations) but the odd hack might use it and is the dominant type among most earlier cartridge based home consoles so definitely worth knowing about. GBA roms (and other things with a bit of fiddling are taken care of quite well) with GBATA but Lunar IPS works quite well otherwise.
UPS- made as a successor to IPS it has seen a few uses and is increasingly popular among GBA hacks. Tsukuyomi UPS is a fairly nice patcher but check that site for others if you wish.
xdelta- IPS had long began to show its age by the time DS hacking started to produce patches and xdelta was around to fill the hole, it has seen a few versions but backwards compatibility has been maintained quite well and if not older versions are not that hard to source.
Delta patcher and xdelta UI are nice GUI driven tools where here is the xdelta googlecode site.
bsdiff- originally saw use in scene trainers (a few do exist) and outside hacking it is often considered xdelta's foremost competitor but among rom hackers it usually makes little difference and can simply be that is what the hacker had on their machine when it came to make a patch.
bsdiff project homepage, various GUI programs exist as well.
Custom- these usually come in an easy to use exe or custom patch format for use with another tool. Generally they are based around the DS filesystem mentioned elsewhere in this article (some “cheat” and combine a file system manipulation program with more conventional patching) and can achieve very small patch sizes and/or custom patching (change the text but not the audio by selecting an option) as a result (the others mentioned are very much rooted in the general file patching world). The only real trouble with some of these is applying them on non windows systems (the other four are well documented and often started life as unix projects of some form so with a bit of thought can be applied on just about every platform out there).
Also ran- PPF which was made for the original playstation and has enjoyed some success on the wii (which unlike the DS pretty much requires custom patching methods or the end user to handle the wii filesystem) but not much use has been seen on the DS.
On top of this you can also download one of the many all in one patching programs (naturally most will not feature the custom formats) that will usually handle IPS, xdelta and Bsdiff. The only real downside to these GUI programs is sometimes they will lack the ability to make patches as well as their format specific brethren. romhacking.net's patching tools list has several things that might be of interest as well.
On the subject of patch making it is usually a minor tweak on applying a patch in the first place so read the help sections of the patcher you want to use (unless you can argue otherwise we suggest xdelta or bsdiff). Be wary though if you are going to say undub a rom or modify an existing hack that it can be frowned upon to release a patch containing work from someone else (one of the main reasons you do not see many undub patches around) and if patching a patch you might want to consider building your patch against the initial hacked rom (apply the original patch and then making your patch turn the hack into what your final rom image looks like).
[h2]2) File system manipulation.[/h2]
All known DS roms use the nitro file system aka nitroFS aka the DS file system. Some roms stack things on top of this (the first Phoenix Wright and Tony Hawk games being prime examples) and use archive formats (the format known as narc/carc being the official one but many other formats exist and most formats have a measure of it if you want to be a pedant) but at the heart of it lies the DS filesystem and most roms can have something done with this.
The initial uses for this was to reduce the size of roms (most people were still dealing with GBA era devices where a size of 256 megabytes was top notch and 32 megabytes was average)- you could slice the later levels from a game, still play the first set and swap to the later ones to play the rest (it also follows that in some cases renaming a file for another can lead to things being done in the “wrong” order,- a bit of minor rom hacking (Electroplankton uses straight up wave files such as those that can be made with most audio editors) and swapping out the audio with a smaller roms. Somewhere along the line undubbing appeared on the DS where what usually happens is the Japanese sound files are sent into the North American or EU release of a game to allow Japanese audio with English (or such) text.
The usual process of undubbing amounts to finding the file with the extension .sdat in the Japanese rom (more often than not sound_data.sdat), finding the equivalent in the NA/EU rom (if you have to rename it then do so), swapping the files out and rebuilding the NA/EU rom. The vast majority of DS games use SDAT but there are others although same logic often applies there (find Japanese sound and use it replace the NA/EU release's sound).
This basic technique works in the vast majority of cases and where it fails it is usually down to the rebuilding stage not working (ndstool and by extension dslazy and dsbuff have long been demonstrated to butcher roms so instead we have nitro explorer) but occasionally the localisation process can introduce some large changes to the rom necessitating a bit more thought/proper hacking.
Tools of the trade
ndstool (originally a part of devkitarm it was built for homebrew but works on many roms as well). Today is it mainly a legacy tool but when combined with a batch file containing the full extraction command it is one of the quickest and easiest ways to explode a rom into the files that make it up and it still works well enough for putting a rom back together.
DSBuff (a .NET frontend to ndstool and a few other programs)
Nitroexplorer made to work where ndstool fell short.
ndsts which unlike the other programs before it can only replace it with files of the same size (nothing stopping you padding a file out a bit) so if you edit with this and make the rom crash or error out it is purely your editing that caused it.
Many GUI driven tools (discussed later) also feature abilities here.
Crystaltile2
MKDS course modifier (not just for Mario Kart any more)
Tinke
[h2]3) Basic cheat making and concepts.[/h2]
Now the cheat making contingent of GBAtemp and elsewhere do some amazing things at a very high level and in the process often exploiting cheat devices and engines beyond far what their designers probably envisaged (things like patching the actual game code in ram as opposed to values that will be being discussed here) which leads to many raising an eyebrow but the basic ideas of cheat making we hold should be known to all and knowing how cheats work will allow you to tweak existing ones to your advantage.
First for the purposes of this post knowing how to add cheats to the database your cart uses (for most carts/loaders means R4CCE for which we have a nice guide on the forums) will fall under basic flash cart management rather than hacking.
Cheats in this meaning of the term rely on the idea that games will allocate a small (hopefully static) location in the memory to hold the value for lives, ammo, money, health and more. The basic cheat making concept is to get an emulator or device capable of viewing the memory and then attempting to change the value noting every change in the memory- theoretically if you repeat this enough times and eliminate anything that did not change between scans you will be left with enough values to conduct a bit of trial and error upon (hold the value static/constantly rewrite it with a value) and see if you have your cheat- in practice cheats are usually variations on constantly writing a value, check and then write a value and check a point to see where the value is found and then use it to direct the former two. Usually in such searches you can search for specific values, higher than/lower than values, values that just went up or just went down, just note things that changed allowing the search to be refined as you go. We do wish to note that the value displayed on a screen and the value in the memory need not be the same thing.
DSTWO/ISMM owners can make basic cheats as well as more advanced ones if they have the patience with their cards (a nice youtube video is available on the subject) but others will require the likes of Datel's Trainer Toolkit if continuing to use hardware or on the software front desmume (do note there are considerably newer SVN builds if you do a quick search and the developer version might be a better place to look) has some nice abilities and is presently about the only DS emulator to continue work on newer titles.
Cheat engine/device developers can reasonably assume this arrangement so they make cheat engines that decode small lines of numbers to tell the cheat engine where to attack, what sort of attack and what the attack payload, if any is necessary, should be. Some guides are available on the cheats forum linked above and a reasonably complete listing of code types can be found on enhacklopedia (DS version and GBA version available among many others).
Most cheat makers will assume you want infinite/maximum lives or silly speedup in the case of experience multipliers where you may simply seek to rebalance the game a bit (making it easier, harder or gearing up for a certain “run”) so knowing that you can hopefully edit a cheat to change it to be closer to what you want to do.
Game developers occasionally dislike cheats being applied to their game and may lay traps for the amateur cheat makers (ranging from simple mirrors of the required value to things that are easier to work around when you have low level programming experience) and additionally the memory that will eventually see the health value or something may well be used earlier when the game is booting up or in a different mode so you might have to cater for this (if your cheat device allows cheats to be activated at any time then that is good) and often this is where it gets trickier and you will probably want to consult a more in depth cheat making guide. When you do want to get a bit more advanced you might consider Cracker's DS hooking tutorial.
Additionally cheats by their very definition get games to do things they were not designed for so you may find the cheat maker made decisions for a reason to dodge an issue with the game code (the reasons can be technical or gameplay related (think the JRPG cliché of the fight you have to lose to continue the story)).
Do note that tweaking existing cheats and releasing them as the fruits of your own hard graft is considered exceptionally bad form so state where you got your intial cheats if you do decide to rerelease them.
[h2]4) Tool driven file editing.[/h2]
Engineers (software and otherwise) really dislike having to design new things and as time goes on it becomes increasingly unproductive to design new things all the time which is a phenomenon that very much applies to software (we have long since left the point where it is possible to know everything from the ground up) so to make things easier Nintendo and other companies will design formats to do basic things (hold files, hold images, hold music/sound effects, hold video, hold text and more) that various game developers use (across many titles and companies no less) that rom hackers then see, pull apart, document and either build tools to view and manipulate or provide sufficient documentation that anyone with basic tools can modify.
As the line above implied there are two main schools of thought on this this subject 1) Nice GUI tools that can be applied by anybody with a mouse and 2) information that can be applied by anybody with a bit of knowledge but not being limited by GUI options quite a bit more can be achieved (or continue to be achieved when the formats change/reveal a hitherto unknown feature/limit). 2) probably falls just outside the “everybody should know” thing but many of the tricks can be done by someone with next to no knowledge of what is going on so they are being covered alongside this.
The four main hacks here are sound editing, graphics editing, game editing (possibly related to cheats above but level editing is also possible) and text editing.
Sound editing usually takes the form of what are technically called repointing hacks where you get a game to play a different song (or no song) to the original rom. Ripping and conversion tools for sound injection can be found but most of DS sound hacking still revolves around a person and their hex editor.
A quick guide to repointing style hacks can be found this thread
SSEQ injection is covered fairly well here (SSEQ is the "midi"/tracker style sound component of the SDAT format and the main source of music you will hear in DS games).
This thread covers some of the ideas behind looping the SSEQ audio. It is arguably doable with just a hex editor and knowledge of SSEQ commands but easy enough to follow along and is a fairly nice primer for editing some of the other commands available for the SSEQ format.
The various audio formats of the DS thread was already linked up but covers some of the basics of the more exotic formats seen on the DS.
Graphics and other editing
GuardianSoul's "The Ultimate Nintendo DS ROM Hacking Guide!" features usage guides to crystaltile2 that alongside a tightly integrated hex editor and tile viewer/editor all with DS filesystem support does also sport the ability to decode and subsequently do things to many DS formats.
Jewel's site has another guide to CT2.
Although now featuring abilities of a general editor MKDS course modifier does have serious abilities when it comes being able to modify the game it is named for.
Romhacking.net has several tools geared towards specific games and the pokemon series is noted for the abundance of game specific tools (as well as being somewhat above average in terms of difficulty when it comes to pulling apart the formats within it).
Leaving things you do just clicking on buttons in a program comes simple format hacking- here you can read off where a value should be in a file (or the location of the data that tells you where it is) and edit it accordingly
Romhacking.net's library of DS related game formats
Lowline's format page (Author of the console tool program and a great example of the kind of concepts you often encounter in DS formats).
You might be forgiven for thinking there is a gap between being able to hex edit something and having a program to do it for you (and a lot of rom hacking is very tedious when it comes down to actually doing stuff) which you would need to be able to program for which is not actually true with various people attempting to make programs and formats to define other formats by (hex editors like hex workshop support formats and general hacking tools like tahaxan and the console tool have tried to add support for user defined formats over the years) and you have tools like ROMulan which heads towards general programming in terms of complexity but stops short of needing to actually know how to program. Equally many rom hackers will abuse spreadsheets (modern ones have fairly decent hexadecimal support and have long had great abilities when it comes to doing repeated basic manipulation of the numbers contained) and search results of their hex editor to do a lot of their grunt work.
If you want you can also learn to apply simple compression tools ( dsdecmp and CUE's compression tools are two of the best for the GBA and DS) to handle compression as most times compression once it is known to be present (by the way compression is also quite easy to detect a lot of the time) amounts to a single extra stage for each file going into or out of a rom (you decompress it when pulling it from a rom and recompress it before it goes back in). The most common type of compression in GBA, DS and often further afield is LZ compression and most modern tools handle the known/common types of LZ along with the less common compression formats/types (huffman and RLE/run length encoding mainly).
[h2]Closing thoughts[/h2]
One of the marks of a good hacker is the ability to combine methods together to pull something off- for example if you are resorting to ripping the sound via an audio out somewhere you can change the level design or files themselves to play the ending theme in the first level (or somewhere where it is quiet) rather than play the whole game through. Equally you could make a cheat to allow you to speed through a game to get to a place where you need to perform your hacks. If you want further clarification on any of the points raised feel free to ask it in the discussion below or if you think it warrants it then make a thread.
