GBATemp ROM hacking documentation project (new 2016 edition out)

FAST6191 · Dec 6, 2019

Edit December 2019.
Reuploaded to GBAtemp's new download section.
https://gbatemp.net/download/gba-and-ds-rom-hacking-guide.33419/

mirror
http://trastindustries.com/randomfiles/romhacking2016_copy_1.pdf

I am aiming to sit down and get some more done and updated in the near future but for now it will remain the 2016 version.

Edit January 2016.
A new PDF, mainly to head off the possible demise of google code and fix a few links. Not many changes but I have tweaked some of the formatting and general tidied things up a bit more.
http://filetrip.net/nds-downloads/u...-rom-hacking-guide-2016-preview-1-f33419.html
Contents below, numbers may be slightly off as they come from a slightly revised edition but titles are all the same.

Edit August 2014. A new PDF that has been edited a bit and has the new domain for GBAtek/no$gba is available. It is pretty similar to the 2012 version in terms of what it has inside it, it is slightly more edited and has working links to gbatek in it.
http://filetrip.net/nds-downloads/u...-rom-hacking-guide-2014-preview-1-f32908.html

Contents
I
II
1
Introduction
12
ROM hacking concepts
15
Basics
1.1
1.2
1.3
1.4
15
Hexadecimal
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Representation 1.1.2 BCD (Binary coded decimal) 1.1.3 Big and little endian . . . . . . . . . . . . . . . . . . . . . 19
1.1.4 Signed values, oating point and xed point . . . . . . . . 19
Hex operations
. . . . . . . . . . . . . . . . . . . . . . . .
15
1.1.1
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
18
24
1.2.1 Shift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.2 Rotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.3 Flip . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.4 Boolean logic . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2.5 Hex Mathematics.
. . . . . . . . . . . . . . . . . . . . . .
Patching and patch making
. . . . . . . . . . . . . . . . . . . . .
27
28
File systems and operations . . . . . . . . . . . . . . . . . . . . . 30
1.4.1 Non lesystem devices . . . . . . . . . . . . . . . . . . . . 30
1.4.2 GBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.4.3 DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.4.4 3DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4.5 GC (gamecube) . . . . . . . . . . . . . . . . . . . . . . . . 32
1.4.6 Wii 32
1.4.7 Xbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.4.8 Xbox 360 33
1.4.9 PS1 and PS2
1.4.10 PS3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . 34
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4.11 PSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4.12 Saturn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4.13 Dreamcast . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
1.4.14 Amiga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.4.15 PC and related hardware. . . . . . . . . . . . . . . . . . . 36
1.5 Finding the object of your interest. . . . . . . . . . . . . . . . . . 36
1.6 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.7 Tools of the trade continued . . . . . . . . . . . . . . . . . . . . . 39
1.7.1 Hex editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.7.2 Tile editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
1.7.3 Spreadsheet and command line . . . . . . . . . . . . . . . 55
1.7.4 Compression 57
1.7.5 Music . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.7.6 ASM/Assembly . . . . . . . . . . . . . . . . . . . . . . . . 59
1.8
. . . . . . . . . . . . . . . . . . . . . . . . .
Basic le format concepts
. . . . . . . . . . . . . . . . . . . . . .
5
632
Graphics
2.1
Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.0.2 Haloing
2.0.3 Bit depth
2.3
2.4
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Palettes and colours
2.1.1
2.2
65
2.0.1
66
66
67
. . . . . . . . . . . . . . . . . . . . . . . . . 67
GBA colours (15 bit) . . . . . . . . . . . . . . . . . . . . . 67
Tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.2.1 1Bpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.2.2 4 Bpp 68
2.2.3 8Bpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.2.4 GBA3 Xbpp . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.2.5 GBA2 4BPP . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.2.6 Bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.2.7 Known formats . . . . . . . . . . . . . . . . . . . . . . . . 73
2.2.8 Crystaltile2 export and import. . . . . . . . . . . . . . . . 73
2.2.9 Avoiding gradients, AA, lossy compression, noise and such
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
things. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Layout, timing, OAM and special eects . . . . . . . . . . . . . . 78
2.3.1 Introduction to the OAM and BG modes. . . . . . . . . . 78
2.3.2 Timing 2.3.3 GBA and DS OAM (sprites) . . . . . . . . . . . . . . . . 79
2.3.4 GBA and DS BG modes . . . . . . . . . . . . . . . . . . . 82
2.3.5 Basic animation . . . . . . . . . . . . . . . . . . . . . . . 86
2.3.6 Window feature . . . . . . . . . . . . . . . . . . . . . . . . 91
2.3.7 Special features (ipping, ane transformation, alpha and
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
such) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.3.8 Basic DS layout formats and mapping . . . . . . . . . . . 93
2.3.9 Video memory handling and alignment . . . . . . . . . . . 96
3d
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
2.4.1 Basic 3d (bones, coordinates, keyframes) . . . . . . . . . .
98
2.4.2 Viewpoints
2.4.3 Textures and material colours . . . . . . . . . . . . . . . . 100
2.4.4 Models
2.4.5 Lighting/shadows
2.4.6 3d smoke and fog . . . . . . . . . . . . . . . . . . . . . . . 103
2.4.7 Animations . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.4.8 DS 3D hardware
2.4.9 The shift of the 3D to DS 2d
. . . . . . . . . . . . . . . . . . . . . . . . . . 100
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
. . . . . . . . . . . . . . . . . . . . . . 102
. . . . . . . . . . . . . . . . . . . . . . . 105
. . . . . . . . . . . . . . . . 107
2.4.10 NSBMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
2.4.11 Non NSBMD . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.5
3
Notes and further reading . . . . . . . . . . . . . . . . . . . . . . 118
Text
3.1
119
Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.1.1 Relative searching
3.1.2 Corruption and alteration . . . . . . . . . . . . . . . . . . 127
. . . . . . . . . . . . . . . . . . . . . . 121
3.1.3 Memory viewing and corruption
3.1.4 Frequency analysis . . . . . . . . . . . . . . . . . . . . . . 131
3.1.5 Language analysis
3.1.6 Pointer and encoding/hex analysis
. . . . . . . . . . . . . . 130
. . . . . . . . . . . . . . . . . . . . . . 133
6
. . . . . . . . . . . . . 1343.1.7 Assembly tracing . . . . . . . . . . . . . . . . . . . . . . . 134
3.1.8 Font viewing
3.1.9 Language comparing . . . . . . . . . . . . . . . . . . . . . 135
. . . . . . . . . . . . . . . . . . . . . . . . . 134
3.1.10 Table creation tools
3.2
3.3
3.2.1 Special cases and non pointer concepts . . . . . . . . . . . 139
3.2.2 Example reverse engineering of pointers
Markup, control codes and placeholders
3.3.1
3.4
3.5
Worked example
3.4.1 NFTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.4.2 Common hacks . . . . . . . . . . . . . . . . . . . . . . . . 156
Scripting and layout
. . . . . . . . . . . . . . . . . . . . . . . . . 160
Layout and limits . . . . . . . . . . . . . . . . . . . . . . . 168
Text extraction and insertion
Text extraction . . . . . . . . . . . . . . . . . . . . . . . . 170
3.6.2 Text insertion . . . . . . . . . . . . . . . . . . . . . . . . . 172
Language detection in DS games
3.8 Translation hacking
. . . . . . . . . . . . . . . . . . 174
. . . . . . . . . . . . . . . . . . . . . . . . . 174
3.8.1 The types of Japanese characters and how they work -
3.8.2 Japanese glyphs/characters and observations on the lan-
On language
3.8.4 Right to left languages and translation.
. . . . . . . . . . . . . . . . . . . . . . . . . 180
. . . . . . . . . . 180
Japanese text editors and translation tools . . . . . . . . . . . . . 181
3.9.1 General Japanese capable text editors
3.9.2 ROM hacking tools . . . . . . . . . . . . . . . . . . . . . . 182
3.9.3 CAT tools . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Sound
. . . . . . . . . . . 181
184
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
4.1.1 SDAT (NDS) . . . . . . . . . . . . . . . . . . . . . . . . . 188
4.1.2 Others . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
4.1.3 Tracker formats . . . . . . . . . . . . . . . . . . . . . . . . 197
4.1.4 General rule of thumb for custom audio formats
4.1.5 Common DS SDAT audio hacks (undubbing, injection,
tweaks and relinking)
4.1.6
4.2
4.3
GBA audio
Video
. . . . . 197
. . . . . . . . . . . . . . . . . . . . 197
. . . . . . . . . . . . . . . . . . . . . . . . . . 216
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
4.2.1 General video theory . . . . . . . . . . . . . . . . . . . . . 221
4.2.2 Mods/VX/act imagine by Mobiclip.
4.2.3 RAD/Bink
4.2.4 Criware
. . . . . . . . . . . . 222
. . . . . . . . . . . . . . . . . . . . . . . . . . 222
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Cut scenes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Game logic
5.1
. 176
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
3.8.3
Multimedia
4.1
5
. . . . . . . . . . . . . . . . . . . . 169
3.6.1
guage
4
. . . . . . . . . . . . . . . . . . . . . . . 144
3.7
3.9
. . . . . . . . . . 140
. . . . . . . . . . . . . . 144
Fonts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.5.1
3.6
. . . . . . . . . . . . . . . . . . . . . 135
Pointers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Levels and Stats
224
. . . . . . . . . . . . . . . . . . . . . . . . . . . 224
5.1.1 Example tools
5.1.2 Level editing techniques . . . . . . . . . . . . . . . . . . . 227
. . . . . . . . . . . . . . . . . . . . . . . . 226
5.1.3 Stats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
75.1.4
5.2
5.3
5.4
RPG randomiser . . . . . . . . . . . . . . . . . . . . . . . 238
Compression . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
5.2.1 Lossy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
5.2.2 Lossless
5.2.3 Basic theory of the actual implementations
5.2.4 Compression at hexadecimal level . . . . . . . . . . . . . . 246
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Cheating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
5.3.1 General cheat making
5.3.2 GBA cheat making . . . . . . . . . . . . . . . . . . . . . . 251
5.3.3 DS cheat making . . . . . . . . . . . . . . . . . . . . . . . 253
5.3.4 Basic making of a cheat
5.3.5 Cheat prevention methods and frustrations
5.3.6 Instruction editing cheating . . . . . . . . . . . . . . . . . 264
. . . . . . . . . . . . . . . . . . . . 249
. . . . . . . . . . . . . . . . . . . 256
Functions and procedural programming. Also return ori-
ented programming/ROP
5.6
. . . . . . . . 260
Programming concepts . . . . . . . . . . . . . . . . . . . . . . . . 267
5.4.1
5.5
. . . . . . . . 240
. . . . . . . . . . . . . . . . . . 267
5.4.2 IF ELSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
5.4.3 Recursion . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
5.4.4 Iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
5.4.5 Loops
5.4.6 Turing complete
5.4.7 Fundamentals of Assembly
Assembly
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
. . . . . . . . . . . . . . . . . . . . . . . 269
. . . . . . . . . . . . . . . . . 270
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
5.5.1 ARM
5.5.2 GBA Assembly specics . . . . . . . . . . . . . . . . . . . 275
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
5.5.3 DS Assembly specics
5.5.4 The GBA and DS compared
5.5.5 On controls . . . . . . . . . . . . . . . . . . . . . . . . . . 285
5.5.6 Hooking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
5.5.7 GBA cart as extra memory for DS hacks . . . . . . . . . . 287
. . . . . . . . . . . . . . . . . . . . 279
. . . . . . . . . . . . . . . . 284
Non specic assembly discussion. . . . . . . . . . . . . . . . . . . 287
5.6.1 Language mod example
5.6.2 Non code in ASM
. . . . . . . . . . . . . . . . . . . 287
5.6.3 Destructive vs non destructive assembly editing . . . . . . 291
5.6.4 Polymorphic and dynamic code . . . . . . . . . . . . . . . 292
5.6.5 Slowdown and speedup
5.6.6 Cryptography (encryption, checksums and signatures)
5.6.7 Multiplayer and the failure of Nintendo's online DS security.301
5.6.8 Save editing . . . . . . . . . . . . . . . . . . . . . . . . . . 301
5.6.9 Interpreted languages
. . . . . . . . . . . . . . . . . . . . . . 290
. . . . . . . . . . . . . . . . . . . 294
. . 295
. . . . . . . . . . . . . . . . . . . . 303
5.6.10 Game AI, game logic and game theory . . . . . . . . . . . 303
5.7
5.8
III
6
Flash cart and emulator theory . . . . . . . . . . . . . . . . . . . 307
5.7.1 GBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
5.7.2 DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
ROM hacking protection . . . . . . . . . . . . . . . . . . . . . . 313
Examples, oddities and techniques.
Crystaltile2 general usage guide
8
315
3157
GBA tracing
7.0.1
8
DS tracing
8.1
9
320
Worked examples . . . . . . . . . . . . . . . . . . . . . . . 321
321
Cart read command
. . . . . . . . . . . . . . . . . . . . . . . . . 322
8.1.1 Basic lookup and methods for it
8.1.2 Header reverse engineering/generated values . . . . . . . . 322
. . . . . . . . . . . . . . 322
Reverse engineering various ROM images
9.1
322
Large archive on top of lesystem . . . . . . . . . . . . . . . . . . 323
9.1.1 Tony Hawk
9.1.2 Star Wars - The Force Unleashed . . . . . . . . . . . . . . 323
. . . . . . . . . . . . . . . . . . . . . . . . . . 323
9.1.3 El Tigre Make my mule
. . . . . . . . . . . . . . . . . . . 323
9.2 Compression
9.3 First Person Game . . . . . . . . . . . . . . . . . . . . . . . . . . 324
9.4 Platformer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
9.5 Fighting games . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
9.6 Role playing games . . . . . . . . . . . . . . . . . . . . . . . . . . 324
9.7 Racing games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
9.8
9.9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
Puzzle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
9.8.1 Mahjong game
9.8.2 Tetris . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
. . . . . . . . . . . . . . . . . . . . . . . . 326
Other genres . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
10 Developer leftovers 326
11 Workarounds 327
12 Moving to a new system 327
13 Developer tricks aka thinking like a game developer 328
13.0.1 Level and mechanism design . . . . . . . . . . . . . . . . . 328
13.0.2 Sprite and palette reuses . . . . . . . . . . . . . . . . . . . 329
13.0.3 Pre rendering . . . . . . . . . . . . . . . . . . . . . . . . . 330
13.0.4 Speed blur and fog . . . . . . . . . . . . . . . . . . . . . . 330
13.0.5 Loading covers
. . . . . . . . . . . . . . . . . . . . . . . . 330
13.0.6 Optimisation of loading
. . . . . . . . . . . . . . . . . . . 330
13.0.7 3d imagery in general . . . . . . . . . . . . . . . . . . . . 331
13.0.8 Procedural generation . . . . . . . . . . . . . . . . . . . . 332
13.0.9 Noise on images and sound.
. . . . . . . . . . . . . . . . 332
13.0.10 Using the limits of the system/working to them . . . . . . 332
13.0.11 Network coding . . . . . . . . . . . . . . . . . . . . . . . . 333
14 Game design and media
333
15 Python, batch les and programming for ROM hacking
15.1 radare2 reverse engineering tools
15.2 Programming languages
15.3 Python
334
. . . . . . . . . . . . . . . . . . 334
. . . . . . . . . . . . . . . . . . . . . . . 334
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
916 PC program hacking
335
16.1 Debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
16.2 Decompilation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
17 Version control and project management.
17.1 Project and team management
17.2 Version control
338
. . . . . . . . . . . . . . . . . . . 338
. . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
18 Interesting links and further reading.
340
18.1 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
18.2 Further reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341
IV File formats (specications, methods and known
formats).
342
19 General things about the DS 342
20 Generic DS nitro SDK format 342
21 General le reverse engineering 342
21.1 Headers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
21.2 File sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
21.3 Multiple versions of the game . . . . . . . . . . . . . . . . . . . . 343
21.4 File names and extensions . . . . . . . . . . . . . . . . . . . . . . 343
21.5 Tile viewers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
21.6 Pointers and such . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
22 Sound
344
22.1 SDAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
22.2 SSEQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
22.3 STRM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
22.4 SWAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
22.5 SWAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
22.6 BANK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
22.7 Other formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
23 Graphics
347
23.1 NCER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
23.2 NANR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
23.3 NCGR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
23.4 NSCR
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
23.5 NMCR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
23.6 NFTR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
23.7 NSBMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
23.8 NSBTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
23.9 NSBCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
24 Packing format
350
24.1 NARC, ARC and CARC . . . . . . . . . . . . . . . . . . . . . . . 350
1025 Text
350
25.1 BMG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
V
Glossary, index and such
26 Glossary
352
352
Click to expand...

Feel free to discuss it or make suggestions/corrections in this thread.

Intro:
This is a holder page for GBAtemp/FAST6191's ROM hacking documentation. It is mainly focused on the GBA and DS though other consoles are looked at and most of what is said applies to all consoles or can be easily adapted.
It has taken many forms over the years with the most advanced one at present being the one linked above this intro. The following thread still has good info but it is considered completely eclipsed by the PDF versions linked above.

For those who are concerned about license issues share links, excerpts, copy and paste things to other sites/forums/newsgroups as this is mainly about getting some information out there, link back if you want but it is not required to do so. Basically feel free to include this document in whole or in part, original or altered in any format (odt, doc, html, PDF, chm....). If you want to contact me so I can try to remember to tell you if something gets updated then by all means go ahead.

The rest of the post covers more detailed stuff but the average DS ROM hacking toolkit consists of five things

A hex editor - able to view and edit any file although it is often pointless to try massive edits using one.
http://gbatemp.net/topic/326873-rom-hacking-hex-editors-mid-2012-discussion/ has some discussion and links
http://sourceforge.net/projects/hexplorer/ is the best general purpose editor with featured desirable to use in ROM hacking you can get for free (you will need to configure it quite a bit as the stock/initial setup leaves a bit to be desired) although do read the link as it contains more information. Most hackers will have several aimed at various tasks though.

A tile editor- http://filetrip.net/f23649-CrystalTile2-2010-09-06.html has one of the best, if not the best, general purpose tile editors for the GBA and DS. Crystaltile2 is also a self contained ROM hacking toolkit with loads of nice features (usage later in the guide).

A spreadsheet with hex capabilities. Always nice to have some data in a form that can be easily read, fiddled with and manipulated.
http://www.libreoffice.org/download/ if you need one.

Something to pull apart DS roms Crystaltile2, ndstool, ndsts, nitroexplorer, tinke and more. Covered later in this post

Something to handle compression It is commonly used, needs to be decompressed to do any real work with and easily worked around on the DS at least. http://gbatemp.net/topic/313278-nintendo-dsgba-compressors/ and http://code.google.com/p/dsdecmp/ are the leading two DS rom compression tools (GBA support is there as well but Crystaltile2 probably does better there).

There are other little tools like http://gbatemp.net/t105060-nftr-editor (editor for a common font format) and http://www.romhacking.net/utilities/504/ (a tool to convert text into various common formats of hex string) and http://www.propl.nl/random/NSBTXExtractor.zip (a tool to extract textures from the standard 3d model format, straight up viewers are also available in the likes of nsbmdtool and tinke but not as useful as that and tend not to work that well for viewing purposes).

Contents linkfest (not yet complete)

This post
Introduction
How to pull apart your roms
links, links and more links

First steps in hacking

graphics hacking
Multimedia hacking (also SDAT some words on general sound hacking too)
text hacking
core and file format hacking

Other topics

Guide to crystaltile2
Cheats, Assembly, AP and you
Rom ripping and enhancements (backup of very old thread)
Compression
Coding for rom hacking
Advanced techniques not necessarily covered elsewhere
Known file formats and niceties.

Introduction

Back when this project/document was started the GBA was only just starting to be hacked properly, the DS was limited to a very small group of people for anything beyond rudimentary file system hacks, the GC was split across several sites and the Wii was still known as the revolution (and naturally did not figure into these documents).
Today as this paragraph is written [2012 edit]probably could stand to be rewritten again but it is being left[/2012 edit] the GBA release scene is long dead and has several very high profile projects released and in progress, the DS still has many releases (although a successor is nearly upon us and also has some very high profile projects with tens of people in the teams, the GC release scene is long dead but the hacking scene has solidified (and is helped by the success of the wii) and the wii (which can run GC code) still has releases and not only has the file system decrypted but methods by which to run custom code other than homebrew built from the ground up.
On all those consoles simple graphical tools (or even game specific tools/info) do not really exist at this time for all but a handful of games on all the consoles; these games usually include pokemon, fire emblem, advance wars, mario platform games, mario kart, smash brothers and many other first party Nintendo or otherwise popular games games. Given the nature of ROM hacking this is not likely to change or ever cover more than the basics although a lot can be done with a few tools and a little bit of knowledge, this is especially true of sound hacking which was long considered one of the hardest areas of ROM hacking.
The rather technical nature of ROM hacking coupled with the tendency towards high level coding being taught elsewhere as well as the somewhat legally and ethically dubious nature of it makes people wanting to take up this fascinating subject can face a steep learning curve.
This guide aims to help people come in “cold” (you know little of computers but have a desire to learn) as well as “retrain” (you can already code but this hacking thing is something relatively new) and although it is not explicitly aimed at such people it should hopefully be of some use for those already versed in ROM hacking to use as a reference manual. This relatively broad range of targets means some areas will repeat things, other times things which have not be detailed extensively yet will be referred to. To some extent this is unavoidable but the guide should allow you to skip backwards and forwards.
The original reasons for writing this was that if you visit any sites with a focus on ROM hacking you will generally get told to learn to hack nes/SNES/Megadrive (Genesis to those in the US)/Master System ROMs and then move on to “harder” systems like the GBA/DS/GC and Wii. Should you ask specifically how to hack GBA/DS/GC/Wii you will be told to look at the general/NES/SNES documents to learn as it applies to “harder”/newer systems.
Doing such things would not be following a bad line of logic but a guide geared exactly towards what you want can help and the later consoles also avoid some of the annoyances with earlier consoles; memory/space limits are less harsh if they exist at all, the hardware has relatively few quirks and there is quite a bit of conformity between titles.
License stuff:

Thankyous. Rather than place them at the tail end of the document the people directly responsible are featured here.
Thanks from FAST6191 to:
People at gbatemp.net and sosuke.com, original hosts of this and extremely active discussion boards on GBA, DS, GC and Wii hacking.
Romhacking.net the people there have helped more than they probably know with this.
Deufeufeu, rom hacker, spec writer and sounding board for a lot this.
Martin Korth, author of no$gba and the awesome technical document on the GBA and DS (there would not be this document without it).
All team members of the original and forked Jump Ultimate Stars translation project.
Cracker, author of DSATM and countless other cheat tools, guides and codes for all manner of systems as well as discussion on this.
Slade, cheats guides, cheats and discussion.
Anyone I have ever had a discussion with on ROM hacking.
All regulars of #gbatemp.net on irc2.gbatemp.net::5190 and all regulars of #ezflash on irchighway.
Any and all authors of tools/guides/posts that have been linked.

So first what is ROM hacking.
It is the name given to the action of changing a rom (or despite the misnomer iso) in some way that is useful to someone else. This can include translation, improvement (better font, better handling of text, more balanced stats), restoration (sound, themes and working around censorship mainly) and a myriad of other things.

What can be done? Absolutely anything. The trouble comes in the difficulty in pulling it off, there are no hard and fast rules as to what is more difficult but generally changing text and graphics is easier than changing a racing game into an RPG.

What do I need to know/have done to become one? This one is a bit harder, I personally have never been officially taught anything about computers at any level much beyond "if you happen to be typing all in capitals press the caps lock key".
Generally I find people who have a great interest in figuring out how things work and being in possession of a bit of patience make for good ROM hackers.
Some advocate experience and while it is useful I believe the following analogy concerning normal human language serves a good example:
How many people might you have met who have been speaking/writing a language for 50 years yet what they speak/write is awful with regard to what the language actually is? Experience is not all powerful.
Likewise how many of you have met foreigners speaking your language who probably possess a greater knowledge of the the implementations of irregular verbs and are far more able to communicate (even if it is their own language) what a pronoun is than you might be able to, yet due to them only knowing 70 odd words they might as well not have bothered? Technical knowledge is not all powerful.
On the subject of language English is probably the most commonly used language for this sort of thing (technical discussion) so it is probably best to become acquainted with it.

Some thoughts though, I personally study how computers work from the ground up and how the specific platform I am hacking a game for works and go from there. Others find it better to know what you want and then go a step higher in the abstraction which works quite well too.
Modern consoles (the GBA, DS, GC and Wii all count here) however do not tend to use assembly coding (just quickly assembly is the type of coding that revolves around changing the hardware manually, it is only different to altering the raw data the game uses by abstracting it to a more human readable form) as much owing to it be far more complex than it may need to be for not a lot of/any real gain. To this end the console makers should provide extensive software development kits to developers and this means games often share features (and more importantly formats) and this can be abused by ROM hackers.
However the mere fact ROM hacking exists should say that someone can do something better (or in a manner perceived to be better) than someone else. This means that purely relying on SDK based hacking can fall flat on occasions developers decide to change or write additions (or even badly implement) the SDK, the format was not correctly reverse engineered (if you pulled apart a format and later another game uses a feature the original sample file did not use is a good example of a pitfall of this method) or attempt to obscure their code (normally against cheaters but this does have a knockon effect for ROM hacking).

The main thing about rom hacking though is data representation, storage thereof, limits of the representation/storage and how a game does this. The nice thing about the DS and newer consoles is that they usually use a file system that is known which provides a great jumping off point- file names, extensions, sizes and more often lead you right to the format's doorstep.

How to pull apart your Roms

The following paragraphs detail how to pull roms apart into the files that make them up, generally it is not very useful if you can not flank it with other hacking skills but in many cases simply being able to look at the things that make it up is enough to inspire people to sit through the dry stuff you need to know to be a hacker.
The following will not cover much of the common formats used by the consoles, how to deal with roms that pack things inside archives (a common occurrence) or indeed even mention much about simply swapping/renaming files (a brutally simple but often a very effective hacking method) as that comes later.

GBA
This is only mentioned in passing. Some tools have been made (looking mainly at golden sun and pokemon) for various file types and locations but generally the rom is packed all in one file.
There is however a fairly advanced method called tracing that can find what you need relatively quickly and easily once you know how
http://www.romhacking.net/docs/361/

Nintendo DS extraction tools
The DS uses the nitro rom file system, several tools exist for extracting things from it.
Most hackers then scan the files contained using several methods including by not limited to checking names, checking extensions, checking locations, checking sizes, using techniques like relative searching and many more within so as to hit upon their chosen piece of data to hack.

Owing to the very same niceties that come with a file system tracing does still exist on the DS but it is a comparatively advanced technique and few do it for the DS. You have to follow the DS read protocols and figure out what it directed at what (it is abstracted at several levels too which is nice for rom hackers when it comes to putting things back together) http://nocash.emubase.de/gbatek.htm#dscartridgeprotocol has more on the read protocol.

There are several other tools available but the ones above should be able to sort the file system for most people. Some more considerations are required when it comes to releasing "production grade" patches but that will be covered later.

Many of the early DS hackers figured out some of the basics by pulling apart roms and attempting to shrink them, it was from here that they figured out common formats and ultimately branched out into more general DS hacking. Today with multi gigabyte DS cards and roms rarely being more than 256 megabytes nobody really rips roms but if you wanted to look back over some of the basics they are still available Rom ripping and enhancements (backup of very old thread)

Ndstool- this is the standard go to tool of most DS hackers. It does however have limitations like not being able to rebuild certain games without them crashing.
http://filetrip.net/nds-downloads/utilities/download-nintendo-ds-rom-tool-ndstool-1501-f29352.html

It is a command line only program but there are frontends (both require .net) in two programs called DSLazy and DSBuff. Many hackers have their own batch files/scripts to unpack games.

NDSTS
A nice little graphical program that details lots of information about the DS ROM you feed it. The main limitation is that it only allows files of the same size to be replaced in the rom. It keeps things clean so it means it can be used for example hacks and small hacks that you do not want to change the entire rom for and as such roms edited with this will not crash like they can do for ndstool.
It is available http://www.no-intro.org/tools.htm

Crystaltile2
An all in one hacking tool for the DS that will feature extensively in this guide and romhacking in general (a guide to the program is available Guide to crystaltile2 ). Naturally it features DS file system support.
It is developed sporadically by various Chinese developers but the current version should always appear on filetrip below
http://filetrip.net/f23649-CrystalTile2-2010-09-06.html

Tinke
Another all in one program like crystaltile2 above but with more focus on formats, sound and 3d. Also frequently works where NDStool falls short.
gbatemp thread

Nitro explorer
Aimed at replacing ndstool and being able to work with games NDStool can not.It does what it sets out to do.
filetrip download

Gamecube
Disc based media tend to be file system based and the Gamecube is no exception.
Gamecube games comes as a .gcm files (often renamed to .iso). It is not signed for the GC or the Wii, files are region locked but a there are tools and most chips (GC or wii) should bypass this.
Support for multiple games per disc is done at iso level with several tools able to do it. Size limit is 1.4 gigabytes (miniDVD) for gamecube and DVD size (4.35 gigabytes) for Wii games if making a multiple game disc.
Gctool:
http://filetrip.net/f818-GC-Tool-1-20-beta.html
GCMtool is good for unix like operating systems (X86 and ppc versions exist):
http://filetrip.net/f606-GCMUtility-0-5.html
http://www.sadistech.com/gcmtool/tutorial.php
http://filetrip.net/wii-downloads/tools-utilities/latest-gamecube-iso-tool-f28774.html

There are many other tools for nearly every common OS if these do not suit your needs.

Wii
Comes as a .iso file. Actual data is signed (junk/padding is not hence the exception for “scrubbing” the iso), the decryption key is known and various bugs (see trucha bug in encryption above) allow for data to pass signing checks.
Size limit is DVD9 at 8.7 gigabytes (DVD5 at 4.35 gigabytes is the usual standard). Unknown how far this can be pushed for the USB loaders.
Most hacks allow for region free, USB loading and more.

The main tool for all this is a program called wii scrubber

http://filetrip.net/f4399-Wiiscrubber-Kit-...oader-1-40.html

Also useful Wiimms ISO Tools
http://wit.wiimm.de/

For the wad files (virtual console, wiiware and the like)
Libwiisharp example programs
http://libwiisharp.googlecode.com/files/libWiiSharp 0.21.rar
Older tools like wwPacker can also work but might have issues. It might need to be combined with a u8 compression tool like u8mii (u8tool is now considered somewhat deprecated).

A largely outdated collection of links
I would not be surprised is most of these are dead or otherwise out of date in some manner.

A nice list of various things is also available in http://gbatemp.net/t73394-gbatemp-rom-hack...t&p=1221059 for now at least.
A pokemon hacksite:
new: pokemon editing tools for DS roms by D-Trogh http://gbatemp.net/index.php?showtopic=94499&hl=

http://wah.studiopokemon.com/herramientas/herramientas.php One of the main questions asked is how do I hack pokemon (and to be fair it has a nice engine to start with). This site has tools, info and discussion.
As does this site: http://www.pkmncommunity.com/
and this site:
http://pokeguide.filb.de/programs.php
and this site:
http://www.pipian.com/ierukana/index.html
That will be all on pokemon for now.

Gavins guide to x86 assembly: while the x86 is nowhere to be seen in this it provides a great intro to assembly in general.
contents page
GBATek specifications:
http://nocash.emubase.de/gbatek.htm The document for all things GBA and DS hardware based.
Lowline's format specifications
http://llref.emutalk.net/docs/
older version with more on SDAT
http://www.romhacking.net/documents/469/
Compression:
http://www.ics.uci.edu/~dan/pubs/DataCompression.html Compression is an important part of rom hacking and one frequently assumed to be too hard to deal with for all but the best hackers. This is wrong and that site is a bit academic but combined with some of the other links can get it done.
Wave file format:
http://www.sonicspot.com/guide/wavefiles.html Not quite related to the DS (it does do IMA-adpcm) but a nice intro to specifications for files which if you plan on doing work with the wii, GC and DS you will use very often.

Some gamecube and by extension wii links:
http://wiki.xentax.com/index.php?title=Just_Cause_ARC (the main site also deals with lots of file formats)
http://hitmen.c02.at/files/yagcd/yagcd/index.html
http://www.emutalk.net/showthread.php?t=26919
http://forum.xentax.com/viewtopic.php?t=2105
http://www.hitmen-console.org/
kiwi.DS site:
http://kiwi.ds.googlepages.com/sdat.html SDAT (DS sound) specifications.
http://kiwi.ds.googlepages.com/nsbmd.html (DS 3d (mainly nintendo game) format) See GBATek for more low level stuff for other games.
Romhacking.net Tracing with VBA-SDl-h:
http://www.romhacking.net/docs/361/ Sometimes you need to find where something is stored in a GBA rom, this document explains how to do it with an emulator. Likewise the main site and forum deals with some very interesting topics. VBA-sdl-h thread there: http://www.romhacking.net/forum/index.php/topic,4521.0.html
Patersoft:
http://www.patatersoft.info/ a nice guide to DS programming and a bit more gentle introduction the DS hardware than GBATek.
A site with some GBA rom formats:
http://www.datacrystal.org/wiki/Category:G...y_Advance_games
enhacklopedia:
http://cheats.gbatemp.net/hack/index.html favours cheating over hacking but most definitely worth a read.
My thread on DS rom rips and enhancements:
http://ezflash.sosuke.com/viewtopic.php?t=457 Basic file system stuff really but it is what got me into DS hacking.

GBA sound:
There is a somewhat common GBA sound format usually known as Sappy although tools and techniques are slightly less developed than the DS and it is not quite as common.
Atrius did a lot of work for it with Golden Sun ( http://gbatemp.net/t109517-golden-sun-tla-...ta-ripping-tool ) and http://gbatemp.net/t230202-gba-sappy-sound...ion-by-bregalad has some more.
There is a tool called sappy (you will want the newest version, one of the 2006 versions and the original)
http://filetrip.net/gba-downloads/tools-utilities/download-sappy-2006-mod-171-f30549.html
An older tool called sap tapper works for some games http://caitsith2.com/gsf/ripping.html
Also http://code.google.com/p/loveemu/downloads/list has some stuff.
Otherwise it is hardware from the ground up unfortunately, http://belogic.com/gba/ is a pretty good companion to GBAtek for sound purposes.

Liranuna's page: http://liranuna.drunkencoders.com/nds-2d-tuts/lesson-1 more DS development.
Crystaltile2: a nice hacking tool. Cory1492 made a translation and it is available on this thread:
http://gbatemp.net/index.php?showtopic=131468
Old links
http://gbatemp.net/index.php?showtopic=60675 Main site (Chinese) http://www.angeleden.net/crystaltile.htm

Compression basics on the GBA (shared with the DS and the concepts used are common across all lossless compression)
http://members.iinet.net.au/~freeaxs/gbaco...ion%20Functions
GBAcrusher is a good bios compatible compression app and is available from the link above.
Recently several great tools for the DS compression have been released http://gbatemp.net/topic/313278-nintendo-dsgba-compressors/ and http://code.google.com/p/dsdecmp/ are the main two.
http://gbatemp.net/t274472-codec-lzss-ds-released has some discussion on the subject.

kenghot's site: In Thai for the most part but kenghot is a fantastic rom hacker and it also has some game specific stuff:
http://www.kenghot.com/
acclms board, a ton of useless info and fairly reknowned for infighting and other nonsense but there are occasionally some really great/informative posts:
http://acmlm.no-ip.org/board/forum.php?id=19
Treeki's site, has a NSMB editor and a rom packer that supposedly works better than ndstool (I have yet to test it though and my carts tend to work fine with ndstool)
http://treeki.googlepages.com/

GBA trainers: http://gba.dellicious.de/trainer.php?s=n&o=asc&d=
GBA cheats:
http://ezflash.sosuke.com/viewtopic.php?f=3&t=686
GBA trainer beginnings:
http://gbatemp.net/index.php?showtopic=39979&hl=
GABSharky guide:
http://home.versatel.nl/derks202/smj/files...ing%20Guide.zip
original thread (Dutch language) http://gathering.tweakers.net/forum/list_messages/942567/26

Do a forum search for crackers trainer guides too. They are available along with a whole host of tools that are sometimes hard to find from http://min.midco.net/cracker/

matthewd997 · Jan 28, 2008

wow nice guide!

FAST6191 · Jan 28, 2008

First steps in hacking

In addition to/alongside the concepts in the introduction section (improvement, restoration, translation and what have you) there are 4 main areas in DS hacking:

graphics: for years games have relied on graphics to display different worlds.

text: I will limit this strictly to the game generated representation of a language rather than a developer created picture of some text housed the rom (although that does exist too and is often one of the more annoying parts of any translation).

multimedia: This is audio and video.

core hacking: how the game works. Attacking takes atk stat multiplies it by a random number and takes it from enemy health, sticking 014f in a certain memory block means a certain sprite will appear..... Also included here is how the game stores data you might use in other sections.

There is no one hardest area: stats can be simple XML files and text can be compressed and encoded with the actual binary code that is run on the processor(s) leaving you to account for it when editing it.

2 questions now arise that in a somewhat more philosophical sense encompass all of rom hacking: "what does a string of 1 and 0's mean?" (if you know what it means you know how it works and you then know how to change it) and "I know what I want to play with so how do I find it?" (possible to include in the first question perhaps but in rom hacking the idea of reducing complexity of something is fundamental).
Some of these have been hinted at already but this is what these documents aim to try and train you in the mindset and hopefully enough knowledge to solve those questions.

Graphics: there are three components:
2d tiles
2d bitmaps
3d graphics.

multimedia: three main concepts hackers get to deal with
audio
video
ingame cutscenes.

text: 3 sections that are important to text hacking
tables
pointers
fonts

core: much like the others this will be split into three components
the binary
extraneous files
file system.

-------------------------------------------------------------------

The following section is likely broken, however the relevant posts should be in order as it goes down in this thread

Graphics:

2d tiles
Think paint by numbers but with pixels.
http://gbatemp.net/t73394-gbatemp-rom-hack...st&p=970547
The position on the screen is determined both by something in the core hacking world and as far as the hardware is concerned by the OAM:
http://nocash.emubase.de/gbatek.htm#dsvideoobjs

2d bitmaps
For various reasons 2d tiles are not suited for a given application so each pixel is given a colour by the numbers it is made of.

3d graphics.
The DS has 3d hardware and it would take someone very foolhardy not to use it and try to do it all in software. Not all files use the NSBMD format but they all work with the 3d hardware:
http://nocash.emubase.de/gbatek.htm#ds3dvideo
In short it creates a mathematical model of a situation (based on 3d coordinates often with different origins) and then generates the according 2d image while the usual scaling, rotation and translation movement methods occur.

Multimedia

Audio:
Sound appears in waves for those that recall science lessons. The most basic form of storing sound is to sample the waveform at intervals and play back the amplitude of the wave at the intervals they were taken from. Do this well enough and you replicate the sound as far as people can detect (this is usually considered to be around 2 times the highest frequency someone can hear or around 44KHz for "transparent" quality. The DS tends to muddle around from around 11KHz (about telephone quality) to around 48000 Hz ("DVD" quality) and come in three main formats:
instrument:
a cymbal hit, a piano sequence.....
"midi"
an arrangement of instruments
full blown wave format.
whole songs or voice samples.

44000 samples a second each with 16 bits as you can imagine takes a lot of space up in very short order but rather nicely most sounds do not alternate that much so you can then assume one millisecond is the same as the next (it gets far more complex than that of course) which means you can drop the size of the file. Now not being a waveform however you have to make it into one which takes CPU time and other resources.
Most DS roms use the SDAT format
http://gbatemp.net/index.php?showtopic=82825
http://gbatemp.net/index.php?showtopic=84009

Video:
Much like audio with sounds if you play enough pictures quickly enough (17 frames per second is about the limit with 20 being comfortable and 30 being pretty good) you create the illusion of movement.
Not much happens from frame to frame and not much changes between one pixel and the neighbour to it so you can call them similar and save space (again it gets far far more complex with everything from psychology, electrical engineering, physics to fields of maths many have never heard of being involved). Again this incurs the need for more CPU and resources to decode.
Although intellectual pursuits are likely what brings rom hackers to the table reverse engineering all but the most basic of video formats is a monumental task.
The two most common hacks are
file system: make one video play by tricking the game into loading it by altering the file sytem or pointers that the game uses. Usually done with an eye towards saving/making space but making videos play at a given time is OK too.

and the lucky occasions where you have a known format like rad tools/BINK:
http://www.radgametools.com/bnkdown.htm (very common in home consoles, the PC market and has a presence in the DS world)

Of course it ultimately boils down to the graphics subsystem so people have done things like subtitle videos or overlay an image by hooking into things there.

Ingame cutscene:
the controls tend to fall dead and the sprites on the screen or the 3d images get moved normally according to a list somewhere. If you can find this list hacking it is then far easier and it saves on space used- a sequence of numbers for a 5 minute cutscene like this is not likely be any more than a 30 second video clip.

text

tables
Many years ago you may have made a "code" along the lines of 01=a, 02=b, 03=c and so on. Nothing has changed now computers are there other than hexadecimal is used and normally more than just 2 digits are used (26 characters in the current roman alphabet used by the English language x 2 for 2 cases, 10 numbers, some punctuation and a few other terms and it starts adding up. Account for French, Spanish, Slavic, Asian, Greek, ancient greek and you end up with thousands of characters.
table is the term given to the list of numbers and their definitions.
See example hack below for a start or read any hacking guide or site as these are the fundamentals of hacking.

pointers
You know a sentence ends becuase of the fullstop, a computer however does not so it can either parse the text or more commonly use and index/contents file/section known as a pointer table.
These are explained in some detail here page search "pointers"
http://gbatemp.net/index.php?showtopic=73394

fonts
binary code is just electrical signals and try as hard as you might but you will probably not be able to interpret them in any meaningful way. This means a number then calls a representation to be displayed on the screen as a glyph, character, rune or whatever your language of choice chooses to call the pictorial representation of the spoken word.
The font is often just a 2d tile or two for a character but it can be more complex than that (see deufeufeu's JUS project: http://deufeufeu.free.fr/wiki/index.php?ti...rmat_.28font.29

The DS has a common format called NFTR of which there are many tools but http://gbatemp.net/t105060-nftr-editor? is a nice one and crystaltile2 also works (not to mention has nice things like OCR and font conversion).

Do note some more modern roms change this format slightly (a nice example of the perils of relying on SDK level hacking) so you may need a conversion tool.

Core hacking

The binary: if you have made it this far you will have heard of computer languages. Simply put computers blindly follow strings of 1's and 0's (give or take some aspects of security) but trying to get the hardware turned on to display, configured and display an image of a box is a hard task and machines can be different so people abstract this and then write compilers and/or runtime environments for the code.
The most fundamental computer language is called assembler/assembly and is simply a more human readable form of binary (granted there are some niceties for some assembly environments regarding memory locations).

There have been emulators that take advantage of certain languages being used- on one level you have things like SCUMMVM http://www.scummvm.org/ which revolves around a very high level language used by many older PC games (although the project has since branched out into other areas) and starting with the N64 there was a technique known as dynamic recompilation that took a function and tried to reimplement it for the host system in real time (and it worked quite well for some things but again people can do whatever they like and so it failed for other titles). So called uncompilers or decompilers do exist depending on the language although for the languages used by consoles (typically a version of C or C++) are not very advanced and certainly nothing special for the consoles covered here exists.
That is not to say you should not look- puzzle quest on the DS uses a form of Lua (a high level interpreted language) and there are many examples of similar things on consoles (the 360 has several games use .net/XNA which allows for a lot of decompilation).
Getting back on topic you may well have to deal with compression (fortunately in the binary at least it is often a common/known type that many tools can deal with ( http://gbatemp.net/t274472-codec-lzss-ds-released has some discussion on the subject) and bundled data (game developers often include text in the binary for whatever reason) but a disassembly tool is what you want (an overview of DS assembly http://nocash.emubase.de/gbatek.htm#cpuoverview (scroll up a bit for a link to the instruction sets)). Several exist and they exist in emulators too (nice for real time things).
DS hackers note that the DS also uses overlays (usually available right at the start of execution if needs be and only for the ARM9) to extend code so you will also want to figure out where they land (for memory purposes) and consider them alongside the more traditional binaries.

extraneous files: you can include stats for your monsters/players/weapons/whatever in the binary or you can do it in files/sections distinct to it. In actuality a large chunk of rom hacking comes down to this but a lot of those sections are common enough across games and even systems.
With the exception of pokemon http://www.pipian.com/ierukana/hacking/ds_evos.html you are pretty much on your own for all games- text, graphics and multimedia are common requirements and have formats at varying levels of popularity but the rest is up to the game developer for fairly obvious reasons (although earlier games in a series or for related versions (think how pokemon usually appears with two very similar games) or different regions can and very often do share code- it might not be exact (see sequels tending to want to improve) but it is certainly a jumping off point).

file system: you can lump all your code, images, multimedia and text into one file and systems up to and including the GBA did this very successfully.
However as time goes on you will likely want to make an index of files and be able to call upon said index to get files. Most disc based systems do this and so does the DS and files can have their own filesystem as well. Common ones include (N)arc/CARC, SDAT, NCER, NANR, NCLR, NTFP, NTFT, NTFS and NSBMD
http://www.romhacking.net/?category=&P...itle=&desc=
http://kiwi.ds.googlepages.com/nsbmd.html
(bonus points are that many of those formats above will share common traits between them- most will start with a few ASCII characters followed by a size and then some info on what comes next).

FAST6191 · Feb 3, 2008

This post will cover Graphics. Right now only 4bpp paletted is covered and a note on 3d as well as a post with some random info. 8bpp is but a minor tweak on this and in a tile editor* it is all simple enough.

*several exist, these are the bread and butter of those that engage in graphics hacking

2d Graphics
And here is the actual binary implementation of 4 bit per pixel (4bpp) paletted GBA/DS format (it works to see for the wii and gamecube as well but some of the ordering needs to be changed). 8bpp works in the same manner but 8 bits are used to address a palette (more colours available). It was taken from a discussion I had with hankchill so please ignore some of the sections that make little sense out of context.
Remember the GBA/DS is big endian, basically this means you need to flip the palette: ff7f becomes 7fff etc. Discard the first byte as it is seethrough as well.
Read the remaining 15 bytes and place them in the order they come out.
The palette's numbers merely reflect the intensity of the colour so it may get interesting trying to replicate it on a PC (using the default the computer default RGB but switching the numbers from the GBA/DS BGR usually works very well to the point where it is differences in screen rather than your code)
Here is some code for a tile editor (linux one) that could help if you become especially unstuck:
http://sourceforge.net/projects/gbafromscratch
VBA has GBA to windows paint palette options as well.
There are also a few RGB to BGR libs available for GBA/DS dev purposes which should not be that hard to repurpose either.

read 16 bytes of the bitmap and call it a tile, repeat in rows of 4 tiles until all 512 bytes are used.
4bpp is 4 bits per pixel so every byte is 2 pixels and each tile has 32 i.e. 8x8 pixels.
The arrangement is known to the DS/GBA so these bytes merely define what colours are used, this is where it gets a bit tricky though as the nibbles will need flipping. For this example the hex editor used does not have the capability to flip nibbles so no simple pictures (as and when you get into the real world chances are your editor will lack such a function as well). Either way each nibble points to the colour at that place in the palette. (in the example below F points to the 15th colour which is white and you can see it repeated)
Here is a picture of the super robot taisen icon with the palette in hex form as follows (first line is 8 colours):
0000 0000 0000 0421 2D04 2128 0174 39CD
01D9 4E73 023F 62F6 675A 739C 7FFF

Each line of hex corresponds to 8 pixels and the three orange pixels on the top left tile were added in so you can try and get your bearings.

Is there a way that I can change the sprites
This may be better served with a thread to itself but I have not played any new game bar the final fantasy CC title as I am doing the whole finish what I have got which given the sorts of games I like is taking a while.

Back on topic you have two options as I see it:
hard sprite change where you literally find and replace the sprites in question.
Find the sprite (and most likely palette for it) and replace them with the ones you want. Finding and decoding are fairly basic rom hacking skills but compression and figuring out encoding can be a pain (and pokemon games are notorious for making this sort of thing complex).

Change loaded offset:
There are likely to be 2 main points at which the sprites are able to be messed with.

In ram via OAM hacking: Most useful if you have a sprite already in a game and loaded for a scene. It bypasses any compression/encoding issues. Bad news is that is squarely in ASM hacking country but it can be implemented with a lowly cheat (and cracker's new DSATM tool if you were so inclined).
http://nocash.emubase.de/gbatek.htm#dsmemorymaps
You might find the sprite at 06400000 hex but what you actually care about is the OAM at 07000000 hex which controls what is on screen and where.

In RAM proper:
Similar to the hard sprite change stuff above but in some regards a bit less crude.
You can get the game to grab a sprite from the rom (if necessary) and overwrite one that is already there (if you were especially flash you could even get a cheat to add it to the rom: it would likely be about 10 codes for a single sprite mind you).

You can mess with where it grabs the sprite from in the rom in the first place (or more likely where the sprite is loaded from the file within it if the file does not have its own file system like those found in a NARC file or something). Granted you can probably alter the file system more easily but I am just tossing out ideas.

The stuff that ends up in the VRAM can sometimes be decompressed/copied into the main memory before it is needed as files are often bigger than the available VRAM and too much cart access gets in the way of things.

Again you are ASM hacking and while cheats are possible it may end up a bit harder than you might hope.

In file: the bastard child of ASM hacking and the replace method.
If you liked you might be able to couple this with the above method by adding a new set of sprites (be they new or just copied from elsewhere) wherever you can put it and getting the game to point to those instead (by editing the file system) or if they are all in one file (fairly likely) then you can edit that as it too will likely have its own file system: this would be like the GBA hacks where people would leave the original text and just point to the previously blank space at the end of the rom or stuff like the Tetris/Castlevania sound hacks I and few other did where they would change the pointers to a song (or none at all) for cosmetic or speed purposes.

This sort of thing is actually the one time I do not like the DS file system compared to the GBA and the like as it makes simple replace/get different files more complex (granted it affords you near limitless space as compensation which is nice).

------------------------------------------------------------
DS 3d basics
GBAtek is pretty good for the 3d internals and well worth a read if you plan on doing any serious work (the DS 3d is fairly simple so you can usually see how things match up or use a bit of brute force to aid you in that area).
http://nocash.emubase.de/gbatek.htm#ds3dvideo
This is only the 3d hardware mind but I have not encountered anything using a software renderer and the 2d hardware like the GBA does (admittedly 3d is not my primary focus but common sense says use what you have got).

kiwi.DS also found time to reverse engineer NSBMD files, this is the nitroSDK format for 3d like SDAT is to sound but nowhere near as common (mainly first party or captive devs).
http://kiwi.ds.googlepages.com/nsbmd.html
http://tahaxan.arcnor.com/index.php?option...amp;topic=34.45
http://tahaxan.arcnor.com/index.php?option...amp;topic=39.15

Ages back there was a metroid viewer and some pokemon hackers also did some work (it should be under the pokemon section further up)

Bear in mind 3d is fairly big and usually fairly compressible (bios compatible LZ mainly) so it is not likely to be simple hack.

------------------------------------------------------------

Short version- it is must like any other rom hack in that you figure out how the image is stored and then how to convert it to a more common format or edit it in place.

Slightly longer version
That is not that useful though so in more depth.
Graphics are not as demanding as some things but if you are not careful they can take up a lot of space and resources very quickly. To this end most developers keep things fairly close to the hardware which allows you to decode them quite easily as the hardware is known.
http://nocash.emubase.de/gbatek.htm#dsvideo
http://www.coranac.com/tonc/text/video.htm
http://www.cs.rit.edu/~tjh8300/CowBite/Cow...ware%20Overview

The hardware takes a little while to learn but as far as you are concerned for a first stab at graphics hacking on the GBA and on the DS there is a 4 bit per pixel mode, an 8 bit per pixel mode and not that is used often a bitmap mode as well.
The main tool of the graphics editing trade then is a tile editor, much like hex editors many exist with differing abilities and fans.
Crystaltile2 detailed below has a great one
I like http://home.arcor.de/minako.aino/TilEd2002/ myself
Tile molestor is a very popular one
Have a poke around http://www.romhacking.net/?category=&P...=&desc=tile and you can start to see. Do note GBA 8BPP is not that common (it was not that common on the GBA but the DS uses it all the time).

What happens in hardware- short version

The graphics can be split into two broad types called backgrounds (BG) and objects (OBJ- often simply referred to as sprites). Said sprites are usually considered to be blocks and while they are frequently 4 to some power square blocks they can in theory be almost any size. Fonts are especially keen on using odd sizes (fonts also count as images, the DS has a common font format in NFTR http://gbatemp.net/t105060-nftr-editor however)
Backgrounds are usually big images that well serve as backgrounds, text is usually part of it.

Aside from bitmap mode the images are essentially paint by colour images and the thing that holds all the colours is called a "palette". Games frequently change palettes as a simple way to add some variety- this does however mean some edits can have unintended effects.
Most palettes are stored in the rom somewhere (be it in the binary, the image file you are editing or another file entirely but some palettes are generated or modified at runtime (Mr Driller rainbow blocks providing a great example).

Most images slot together like a tile puzzle fairly easily but some images have hugely custom layout options and animation routines (hands moving, facial expressions, attack poses/stances and what have you). Phoenix wright being a good example.

3d images
3d images assuming you are not dealing with a 2d painting type 3d image do exist for the DS as well- it has 3d capable hardware. Many games (most notable new super mario brothers) use the 3d hardware to create or augment their 2d visuals so it is worth knowing.
These use their own format in hardware and on the actual DS several common methods exist. One nice thing about 3d however is that with it being mathematical rather than pixel based you can do things to it to change it quite easily once you know how.
The big DS 3d format is NSMBD but it is not the only one

http://www.romhacking.net/forum/index.php/topic,8407.html is good.
http://kiwi.ds.googlepages.com/nsbmd.html is a bit outdated and incomplete but it is nice to see.
Not so many tools here, the first link has one nsbmd viewer is another

Annoying things
At this point compression should be mentioned. The DS has many options but the big three in images are

packing- mainly for fonts but this takes a simple 2 colour image and packs it down into 1 bit per pixel (many editors will actually support this)
LZ compression- by far the most common. The DS BIOS actually has a decompression function but there are variations on it (the big three being called type 10, type 11 and type 40). Type 10 is the BIOS one and type 11 appeared a couple of years back in roms but type 40 is new.

Several tools can handle it including dsdecmp http://code.google.com/p/dsdecmp/downloads...DSDecmp_v3b.zip
codec LZSS
http://gbatemp.net/t274472-codec-lzss-ds-released
crystaltile2 (mentioned below)
Some GBA tools http://www.romhacking.net/?category=&P...itle=&desc= A few even include tile viewers of a sort but do not expect great compression abilities.
GBAcrusher
http://members.iinet.net.au/~freeaxs/gbacomp/

On top of this the image files for DS and other systems that have a filesystem (most modern systems- the GBA was probably the last holdout) can use archive type formats to hold lots of small files in one big file. NARC is a common DS one.

SDK level editing
This still is perhaps not as useful as it could be so SDK level editing.
The DS SDK (called nitroSDK for most purposes) have lots of formats for developers to use for all things. In graphics they often make their own formats but it is worth knowing about the SDK ones.
http://llref.emutalk.net/nds_formats.htm#NCLR
http://llref.emutalk.net/docs/
(sites appear to be down right now but when it they are up they are a great source of info) You can get the first one on http://d.hatena.ne.jp/loveemu/20091002/nds_formats
A more basic approach http://gbatemp.net/index.php?showtopic=45360
http://www.romhacking.net/forum/index.php/topic,8407.html is worth a read.

Being common formats several tools can open them.
To start with there are susie plugins (a plugin format with a fair bit of support)
http://gbatemp.net/index.php?showtopic=162863
crystaltile2 has extensive support
http://gbatemp.net/t73394-gbatemp-rom-hack...t&p=1221059 (scroll down a bit, this link might change in the coming weeks though so just search the topic if it does) http://filetrip.net/f23649-CrystalTile2-2010-09-06.html
http://www.romhacking.net/forum/index.php/topic,8407.html is worth a read and has a tool.

There are also minor asides for game specific stuff and guides (mainly for things like pokemon) to use existing tools.
Something worth a look at
http://gbatemp.net/index.php?showtopic=608...t=0&start=0
http://jumpstars.wikispaces.com/File+Formats
It is not an SDK format but it is worth knowing and details the thought process quite well.

It is very ill advised to only learn how to pull apart things as found in the SDK- developers can and will change things and that will leave you in the lurch if you only know how to open known formats.

http://gbatemp.net/t272687-gtd-graphics-can-anyone-help

Flam9 · Mar 5, 2008

This topic got no love.
FAST, as always, great posts. Hopefully someone other than myself takes the time to read your beautiful explanations :/

altorn · Apr 20, 2008

Cool, i'll look into this. Thanks for the guide!

(although this could use some polishing up because just looking at the paragraphs make me dizzy.)

Upperleft · Apr 20, 2008

Neat!
i'm gonna read this ASAP
great guide

Chotaz · Apr 29, 2008

Wow Fast6191, nice guide. I'm gonna try some stuff outta this

just a question, dunno if you played the latest Mystery Dungeon game, but even if they aren't in the team, 'the Hero and his partner' are always the one that walk around the places, you only get to se the other pokemons inside the dungeons, is there a way taht I can change those sprites?

FAST6191 · Apr 29, 2008

Multimedia holder.

SDAT/sound replacement: originally done to shrink roms (goldeneye has an especially small file) but these days is done mainly for undubbing games.
The simple undub merely takes the Japanese sound files and replaces the ones from the Euro or US release and it works most of the time. Other times there are extra or fewer sounds or it is done in a different order (the DS can use name of a file or ordinal (numbers) to call a sound) leading either to odd sounds being played or to crashing. Here you have to alter the files to match with techniques detailed in the next paragraph.

SDAT tweaking: various people have tweaked tetris to play different songs. I did it to play the classic tetris theme ( http://gbatemp.net/index.php?showtopic=36870 ) all the time and mufunyo removed the BG music entirely ( http://gbatemp.net/index.php?showtopic=69603 ).
Other times this can be done to reduce loading times/increase stability. Various people did it but it was kenghot who put out the patch you will most likely see for the Castlevania portrait of ruin.

Full blown sound replacement: the first people to do this were messing around with electroplankton as it uses plain windows compatible wave files which brings me onto the next thing.
What sound files are.

The most common format is the SDAT format. Some games are shifting to other formats and a lot of the time these games are quite notable.
Others use common formats (electroplankton) and not so common but common in games world (the world ends with you had a topic the other day http://gbatemp.net/index.php?showtopic=86998 ).
One or two use tweaks on a "common" format meaning you will likely have to make new tools/alter existing ones to do it (lower bitrate/only mono audio/lower sample frequency/lower bit depth.....) but this is fairly rare and most tools allow for this even if they were not intended to be used for it).

SDAT format stuff is fairly easy to work with.
Specs here
http://loveemu.yh.land.to/page/NDS/SDAT.html
http://kiwi.ds.googlepages.com/sdat.html
Tahaxan forums have a early stage repacker but I find a hex editor and a spreadsheet nicer to work with.

For the BG music tweaking the file system is normally tweaked to read a different file (or none at all, normally by "reading" outside the actual file).

Next is simple replacement/swapping. I mentioned the repacker and it is easy enough to swap from rom to rom but the formats used within SDAT are not quite common PC formats which makes converting to the format a bit harder. The formats are detailed properly in the links I gave you above and kiwi.ds also made midi2sseq:
http://kiwi.ds.googlepages.com/midi2sseq.exe

http://llref.emutalk.net/nds_formats.htm#SDAT is also worth a look if you fancy editing the sound at really low levels (adding looping, changing what is played and beyond).
http://jul.rustedlogic.net/thread.php?id=7518 is worth a look.

You have simple sounds: drum hits, a gun shot in soundbite format (normally some form of PCM/IMA-ADPCM)
You have midi type files (not actual midi but close enough for conversion to and from) with their instruments in distinct sections.
Lastly you have full blown tracks (Tony Hawks games are the most common here). PCM or IMA-ADPCM (also detailed above) are the most common.

Video

Actimagine do a video codec used by a lot of DS games known as mobiclip but word is they lock it down hard even at the SDK level (phone homes/lockdown timeouts in addition to whatever nintendo have) and nobody has done much there.
The mobile phone mobiclip and the DS one are two different things and while they might share a measure of compatibility at some level (both aimed at portable devices) it is sadly not that easy.

The people behind ADX and AHX (CRI Middleware) do a codec used in some DS games- they even have a nice list http://www.cri-mw.com/product/adoption/platform/ds.html . Not sure about playback options at this point in time.

Lastly the PC favourite RAD / Bink have some stuff on the DS although not much and I have still yet to try it http://www.radgametools.com/bnkdown.htm

After this it is mainly in game cutscenes using the OAM and sprites, backgrounds (all things that emulators and maybe a bit of fiddling with cheats can lose) and whatever else the hardware affords. There are some minor animation formats available in the nitroSDK that some developers use (and later versions of crystaltile2 support) but that is rare.

Nobody is going to pull apart a video codec- my usual example is to say have a look at something like MPEG1 ( http://www.cmlab.csie.ntu.edu.tw/cml/dsp/t...g/coding/mpeg1/ ) and now consider most modern stuff is going to be more complex and thanks to the existence of software patents less than intuitive.

Nothing stopping you from slicing up games (either repointing an end of game sequence as the title or injecting something that has a nice intro with something from another game) and using an emulator for playback purposes though (screencapture type recording).
Do note that many videos on the DS store their sound separately* but sound ripping is easy enough.

*a useful bit of info if your emulator, flashcard or PC is struggling to do the lot at once and you can simply blank the music.

Sprite based animation. Not strictly a cutscene but get a copy of Miles Edgeworth Ace Attorney Investigations, open it in the developers version of desmume and point your memory viewer at 07000000 hex. You can see the rapid change of numbers that is involved in on screen animation.

FAST6191 · Jun 11, 2008

Text holder

The main thing about rom hacking though is data representation and storage thereof and how a game does this. The following a drastically simplified example with the main part to appear later.
A simple example can probably arise from your childhood. Back then you may have made a code along the lines of a=1, b=2 c=3 and so forth.
Text in games, assuming people do not use is as graphics (see below), is done in the exact same manner. The most common encoding is arguably ASCII (acronym of American standard code for information interchange and is used in a fair few games), companies define their own according to their needs however (ASCII above is an 8 bit (technically 7-bit) encoding which affords 256 characters: nowhere near enough for sufficient Japanese characters which can number in the thousands for a given bit of text).

likewise pictures, these tend to be a paint by numbers approach using one of two methods
bitmap
green,red
red,green
In actuality there would be numbers used here but serves to illustrate the example.

palette
This is closer to the paint by numbers approach. Here a number is given which corresponds to a position in another area or the rom/memory. This allows quick swaps of numbers and so colours and can be smaller than rattling off exactly what colour you need (the GBA screen allows for for 32768 distinct colours which requires 16 bits to describe the lot: each pixel for a bitmap can be 16 bits).

The thing about representing data is I can say asaghfjsgfjh and none of you may know what it means. I now tell you that it is actually my encoded version of today I went to the shop to buy some milk.

Now data packing:
Open up a rom in a hex editor and you will see some hex with little idea of what does what: some is executable code, some is junk/padding, some is the pictures you see, the sound......
In much the same way the internet can be viewed. Should I say something is on the internet the first thing people do is either ask for a link or head to a search engine. Likewise when reading a reference book you read the contents or index to (hopefully) find what you need.
In some cases this is easy: the DS uses a well known, well understood file storage format meaning you can quickly break apart roms (most use extra formats on top of this but that is a different matter).
The GBA on the other hand is normally just one lump of code and sometimes the only way to find what does what is to stick it in an emulator, find where it appears in the game and note what memory section it is in, reset and find what part of the cartridge it was read from (this process is called tracing and is detailed very nicely here: <a href="http://www.romhacking.net/docs/361/" target="_blank">http://www.romhacking.net/docs/361/</a> )

In nearly all cases (even to some extent for the GBA above) the rom or file within appears much like a book with a contents/index section and the main bulk able to be split up using that index/contents section. A good deal of rom hacking involves restoring these formats to working order after you have come and done your hack: adding in 5 pages to a book will make all subsequent pages if you use the contents/index 5 pages out. Change the index and you are good to go.

<b>Start of tech section:</b> I will add some more from my document and other sources later but here is
pointers for text:
Assuming your text is not graphical (a good chunk of puzzle games have a very small amount of text so they often eschew sorting out a text decoding system and in place drawing a picture with some text burned into it) and the very rare cases of "end to end" and "set limit" text (they will be summarised them at the end) what you want to read about is pointers.

In short they are like a contents to a book as trying to get the computer to calculate the end of a work is a pain and a waste of resources if you can just do it at compile time (trying to predict things at compile time is a whole section of computing to itself but as text is for the most part static you can sideline that).

If you run over the length without changing the pointers to match the worst that will happen is you will crash and at best your text will spill over into other areas.

They come in three main forms:
Standard: you will get a list of hexadecimal numbers (if you do not know what hexadecimal is have a read of chapter 3 on the following website
<a href="http://webster.cs.ucr.edu/AoA/Windows/HTML/AoATOC.html" target="_blank">http://webster.cs.ucr.edu/AoA/Windows/HTML/AoATOC.html</a> )
These numbers count from the start of the file to the text. My example today in rune factory 2 ( <a href="http://gbatemp.net/index.php?showtopic=70192&st=41" target="_blank">http://gbatemp.net/index.php?showtopic=70192&st=41</a> ) is a good example and it deals with the endianness problem .

Offset:
The numbers in the standard form above usually come at the start of the file and are called a header. These work in the exact same way as standard but count from the start of the text (or occasional some other point).

Relative:
A hybrid of offset and standard types and in some ways the easiest on the system (although not on your head). Basically they count on from their place in the file, for example if the pointer is at address 5c in the file and reads 10 you add the two numbers together to get where the pointer actually points to.

The exceptions and a few problems
GBA: This is perhaps outside the scope of the question but the GBA cart is in the memory so pointers will usually start with a 08 for roms 16 megabytes and under and 09 for some roms 32 megabytes in size (GBA memory mapping gets a bit more complex with mirrors and some text being loaded/decompressed into the memory proper). DS roms tend to be little files which is nice and keeps things simple.

End to end: I know a sentence is finished when you put a fullstop: some games (mainly nes and snes era) do the same with a 00 or something.

Fixed length:
Ever wondered why certain final fantasy titles have names of spells that look horrible when translated? Basically the devs decided 12 (or some other number of) characters would do for names (and it does in Japanese) but when it comes to the west things get a bit more difficult. Rather than redo it the localisation team just scrunched the names up. If you encounter this it is usually wise to continue at the next section i.e. for 4 characters ACBD|EFGH|HI__|JK__

Endianness:
You know the number 7000000000 is bigger than 6999999999 despite most of the numbers in the one starting with 7 are smaller than the one with 6 at the start. This is called big endian and the GBA/DS read numbers the other way i.e. 0745 would actually be read 4507. Simple enough really once you know the trick. The link for hexadecimal should sort you out for this as well.

Sector based:
Not so important for text but as pointers are used in packing formats (see ARC for wii: <a href="http://gbatemp.net/index.php?showtopic=72013&st=0" target="_blank">http://gbatemp.net/index.php?showtopic=72013&st=0</a> ). Here a sector is defined as opposed to being the start of a sentence/paragraph in most text. In short a sector of say 256 bytes is defined, now instead of saying go 1024 bytes in the application takes a 4 and multiplies it by 256 to get there. 4 is a much smaller number and can be represented far more easily allowing for a larger space to be occupied. There is a problem with wasted space but compression or simply the fact a disc can hold a large amount of data with large tracts unused renders this point somewhat moot.

Use in/as compression.
Perhaps not as useful for the GBA, DS, GC and Wii where space is plentiful but worth learning/considering.

Spells in some RPGs have a naming scheme referring to how powerful they are.
E.g.
firebolt
great firebolt
mega great firebolt

Nasty I know but it is just an example. Imagine if you will that the end of the text has a 00 or some other end of section character.
Now instead of having firebolt00great firebolt00mega great firebolt00 with the pointers going to each one you can point to the start of the word you want (i.e. for the basic firebolt spell you would just point towards the end of the text where firebolt starts and so forth) leaving you with just "mega great firebolt00" for your text section.

section on basic text hacking here for archival.

Stuff like Sim City uses plain text files but if you look back I would suggest starting out with New Super Mario Brothers.
The text is unicode which any hex editor or text editor worth anything these days supports (if not you can just ignore the 00's between characters and use ASCII which every editor I have every used supports) and the pointers were simple enough to work with (I forget exactly what they were but they were nothing spectacular).

Some simple info examples on NSMB:
<a href="http://gbatemp.net/index.php?showtopic=32910&hl=" target="_blank">http://gbatemp.net/index.php?showtopic=32910&hl=</a>
<a href="http://gbatemp.net/index.php?showtopic=33129&hl=" target="_blank">http://gbatemp.net/index.php?showtopic=33129&hl=</a>

A more general explanation:
Getting the text:
GBA roms are all one big file so you can do a search for 08XXXXXX (X is a wildcard) and should you find a section with a lot of them in you have something of interest (it could be music, graphics, video or something but text is a distinct possibility). 09 is used for sections in roms above the 16 megabytes line. Sidenote here would be that there are also other mappings of the cart in the memory with 08 and 09 being the ones with the shortest delay/most urgent. See gbatek memory mappings for more on this.

Memory tracing: not quite proper tracing and used more for palettes. The text probably finds a way into the ram at some point, you find the text in the ram and search back through the rom for it.
Similar to this shiftJIS detailed below often starts with an 8 or a 9, so it is worth a look if you have a Japanese game, unicode for most roman characters will look like 00XX so a search for 00 is not a bad idea.
Tracing proper: you log all reads of the cart in an emulator (VBA-SDL and vbasdl-h for the gba and developers no$gba for the DS are the two most commonly used emulators for this but you can kludge stuff together in other ways).
Disassembly: related to tracing but going through the games binary by hand can either give the location of the text or the text itself as it is in there with the rest of the code.

DS specific: files have a nice name or extension within a file system. Often carries across from Japanese games as well.

Corruption: mess up a sequence of code and see what happens in the game. Not very precise but it can narrow things very quickly. Try and be intelligent if you use this and in the case of the DS do not spend 6 hours corrupting the sound file and run it through a tile editor first to make sure it is not a section of graphics you are working on.

Scanning: I mentioned tile editors above and they are quite good at giving a representation of a file at a glance (far more so than hex numbers). You can add in some statistical analysis as well (detailed below when encoding is talked about).

First step after getting the text to begin with:
Find the encoding.
The three most common encodings for computers as far as rom hacking is concerned these days (go back in history and it will not be so important) is ASCII:
<a href="http://www.neurophys.wisc.edu/comp/docs/ascii/" target="_blank">http://www.neurophys.wisc.edu/comp/docs/ascii/</a>
Notice there it is only the last 7 bits used, when the uppermost bit is used it gets a bit more complicated (there are 128 more characters available and different companies, countries, consortiums, programmers and so on have made their own versions).

Unicode:
Unicode is an odd one, it is 16 bit unlike ASCII which means it is easy enough to accomodate near enough every character recognised by mankind but after the initial "ASCII" section
<a href="http://unicode.org/charts/" target="_blank">http://unicode.org/charts/</a>
There are also several implementations of each character set and any and all could have been used).
A nice intro/overview is available at <a href="http://www.joelonsoftware.com/articles/Unicode.html" target="_blank">http://www.joelonsoftware.com/articles/Unicode.html</a>

ShiftJIS when dealing with Japanese. It is not the most obvious of encodings (if you look at ASCII 3? is a number (33 being 3, 35 being 5.....) and capitals are 2? lower than the lower case (41= A, 61=a) and it is all relative: 41=A,42=B,43=C) but it works well enough:
<a href="http://www.rikai.com/library/kanjitables/kanji_codes.sjis.shtml" target="_blank">http://www.rikai.com/library/kanjitables/k...odes.sjis.shtml</a>

Of course not all use them which means you may have to find them, here it can get very interesting. A note here Capcom have their own table they use in some of their games which is readable in a plain ASCII editor as the lower case characters are read as ASCII upper chase characters.

Earlier I mentioned relative sets of characters (41=A, 42=B) and you can abuse this by doing a relative search for a number sequence (simple example is CAB which would have a pattern like x,x-2,x-1). This will spit out a list of results but it gives you something to work with. Longer inputs are better but can be tripped up be increased "problems" as detailed in the ---- encompassed section.
Other things involve repeated sections or words (some games I have worked on have had a quirky charcter who repeats lines or has a phrase (kupo from final fantasy titles being a good example). Note however that capitals and lower case characters are not likely to be relative and I have seen the two characters encoded one after the other (AaBbCc.....).

Brute force:
Find the text by disassembly or corruption (corruption is simply changing a section and seeing what happens ingame) and then try characters (best to make it fairly methodical) and get it that way. Downside is that it can take a while, upside is that it is fairly foolproof.

Statistics: so far I would hazard a guess that the space key was my commonly typed charcter of all the ones available so a breakdown of the characters used would give out some good ideas as to what the space is encoded as which then provides a base for you to guess the space character.
You can expand such a concept into plain linguistics as well:
I saw it in a film (Zodiac I think it was) but it is a good example, a serial killer sent coded notes to newspapers with no key. The key was decoded by the fact that the word kill (and so the repeated l character and then the k and i) was bound to be in there somewhere. The most simple example would be for the word français (French language word for french), you would likely see fran?ais in an editor which you could than guess whatever the ? is is supposed to represent a ç.
Hackers hangman/crosswords can also be played once you have the space and some idea of what is what.

Disassembly: the only surefire way but it requires knowledge of assembly for the console you are working with.

Font viewing: The font is usually encoded as it appears in the table (order wise) so it can help narrow things. External encodings (outside the binary) are quite rare so I would not count upon them but there is a format known as NFTR which is used in some roms <a href="http://gbatemp.net/t105060-nftr-editor" target="_blank">http://gbatemp.net/t105060-nftr-editor</a>?
Some have even attempted to use optical character recognition on such things (pretty tricky with some Japanese font styles/typefaces.

Ram/savegame related
In encryption a rather powerful set of attacks known as known plaintext, partial known plaintext or chosen plaintext are available in some situations that allow you to infer things about the encryption or key by knowing or choosing what you feed into it.
By watching the memory as you change characters (or if you are lucky highlight a new character) on a name entry screen (or something to that effect) or analysing the resulting save file you can potentially figure out a lot of things. After this it is somewhat similar to the end stage of a corruption attack- picking and choosing what you stick in the ram.

----------------------------------------------------------

Problems:
Japanese is not relative when it comes to kanji (stroke order, first to appear in the game/script and many more things can be used (sometimes developers will use even an encoding from another game) as well as the fact there are many kanji and not all will be used in a game). The problem is not limited to Japanese either.
16 bit, most relative searches are for 8 bit characters. You can use a wildcard to get around this though. It has been heard of for a 12 bit character map and a 24 bit character map being used as well but thankfully that is very very rare.

MTE/DTE, multi tile and dual tile encoding. Strictly DTE is multi tile encoding but dual tile encoding is the most common.
Here a word or some characters are encoded as a single or more characters
Sidenote if you edit the font you can have a rather nice halfway hack to give the illusion of variable width fonts (Japanese characters are all approximately the same width while ijl looks odd if spaced as much as say a w (try it in a codebox).
A cousin of this is the halfwidth characters for Japanese, I mentioned that Japanese characters are the same size for the most part but they are also fairly wide which means two characters each forming half of the character are used to make a whole one.
Another cousin of this is the variable, often you get the chance to name characters or there is a variable amount of gold in your bank/wallet and this needs calling upon. This can come in anything from programming/xml style "[main char]" arrangements to just another "character" in the table ("you need 4F gold to stay the night").

Not all text sections use the same table, this can mean anything from a different extended set of ASCII to a whole different table. This is mainly limited to having different tables for the menu, ingame sections, cutscenes but multiple tables for a section of speech has been heard of on several occasions.

Compression: long the bane of the romhacker but text is large, cumbersome and a good candidate for compression. The GBA/DS bios has decompression functions with arguably the most common being one of the LZ implementations but a game is not limited to those.

---------------------------------------------

You take the info on what the characters are and put it in a so called table file, there are a few different sorts and this what you use will depend on what you are doing and/or like to use.
Very few commercial editors and general purpose editors support tables (and even fewer support stuff like DTE/MTE and variables) but there are a whole bunch of hacking editors available at romhacking.net
<a href="http://www.romhacking.net/?category=13&Platform=&game=&author=&os=&level=&perpage=30&page=utilities&utilsearch=Go&title=&desc=" target="_blank">http://www.romhacking.net/?category=13&amp...itle=&desc=</a>

From here you deal with pointers and reinsertion issues. Pointers are detailed in the rom hacking sticky (they are simply a list of locations at which lines and/or paragraphs/sections begin/end and insertion issues are mainly things like only 70 characters per line/3 lines per paragraph.

Fonts are simply the graphical representations of characters and for the most part are simple. nftr is a common DS format and a good example of a halfway house between the simple row of tiles approach and the more complex generated set of tiles, deufeufeu did a bunch of work on the latter type:
<a href="http://deufeufeu.free.fr/wiki/index.php?title=Main_Page" target="_blank">http://deufeufeu.free.fr/wiki/index.php?title=Main_Page</a> and crystatile2 as well as <a href="http://gbatemp.net/t105060-nftr-editor" target="_blank">http://gbatemp.net/t105060-nftr-editor</a>? supports nftr if you are looking around.

FAST6191 · Jun 20, 2008

Core hacking holder

---------------------------------------------------------------------------

Example hacking route adapted from a PM discussion about translating a rom:
The game was a harvest moon title on the DS. Use of first person is not usually done in technical documents I agree but it should hopefully not distract from the message.

First stage is find the text encoding and dump the script ready to be translated. The most common type of encoding for Japanese games on the DS is shiftJIS, a rather horrible abortion of a standard as far as things go but it works. The rune factory series uses it so there is a good chance Harvest moon will also use it. Hopefully it will not be compressed.
ShiftJIS:
http://www.rikai.com/library/kanjitables/k...odes.sjis.shtml
Simple Japanese text editor:
http://www.tanos.co.uk/jlpt/jwpce/

Before you get to all that though you will have to pull the rom apart, DS roms are much like CDs in that unlike the other systems files are distinct from each other making rom hacking easier once you have figured out what they do and makes it easier to get at them but harder than other systems until you do find out what is what.
A topic covering the basics of it:
http://ezflash.sosuke.com/viewtopic.php?t=457

The script will likely be in several files and if you are lucky they will have names (English based) to indicate what they do: something like NPC_name for the names of the non player characters is not uncommon (and if the harvest moon and rune factory games are anything to go by then you should be OK here as well).

You now have a choice: if you want to recruit someone I would make a demo showing you can do something, rather basic but here is my pulling apart rune factory 2:
http://gbatemp.net/index.php?showtopic=70192&st=41
I also did some stuff for the recent 3d gundam game and in an old (pre trucha) thread for the wii that could be a decent demo if you want more.

Putting it back together: text files have an index (search for "pointers" on rom hacking guides). Once you have this you will probably want to alter the pointers to make the text read more easily (or even to work at all: if the game has something outside boundaries it may crash). This stage takes a while.

In short there will probably be the following stages:

pulling the rom apart (takes a minute at most once you have everything set up_

finding the text (could be very quick or it could take days or more)

decoding the text (if you have an emulator it should be fairly quick)

reworking the text: If you hand your translators a nasty looking script they will probably not like you much). If it is something common like shiftJIS I suggest leaving it as what you got it in unless you really really have to change it.

translating (this one is very much how you and/or your team work: my personal preference for translations from Japanese is not to assume your readers are Japanophiles but assume they are at least knowledgeable (unlike most official translations).)

reinserting the text: encoding it is not bad, but redoing the pointers may be. I suggest a spreadsheet unless you want to code your own app.
ShiftJIS is nice as it has ASCII built in (although the extra Spanish characters may prove a problem). The font on the other hand can cause problems and I suggest leaving it until you have got the translation "playable" unless you have a good coder on the team as it can get messy.

reworking the text: you may have to trim lines/sentences to make it appear on screen better or fix bugs.

If you get a team the usual team rules should apply:
everyone should be able to do everyone elses job, maybe not as well as the person but it should be able to be done.
everybody has tasks/jobs.
in this case everybody should know the basic Japanese text: what are the kana (and the subsets), kanji and romaji and what are they for (you could probably leave out stuff like kana in place of kanji when medical terms are needed).

What did you want to know, we have extraction software and fairly complete specs. NARC can sometimes come called arc files as well.

Narctool is the usual extractor tool (you can use a hex editor too if you like though)
http://www.pipian.com/stuffforchat/narctool-0.1-p.zip (for the "nameless files)
http://members.cox.net/dexter0/DSTools/narctool.shtml (for the directories)
There were a few newer versions but I will have to dig them up (it is about 1 in the morning right now and my eyes are doing the unable to focus bit).
Crystaltile2 also has the ability.
As does this http://gbatemp.net/index.php?showtopic=83049

Earlier versions had problems with directories and "nameless" files (there are names and ordinals)
Sidenote carc files are compressed narc with the compression being BIOS compatible LZ compression (support is in the app and with any of the many GBA tools that do the same job).

Specs (accounts for "new" features). The format is fairly obvious if you are used to hacking DS roms anyhow and the source for narctool is readily available (crystaltile2 also has source if you are willing to go digging).
http://www.pipian.com/ierukana/hacking/ds_narc.html
http://tahaxan.arcnor.com/index.php?option...9&Itemid=36

In other news I am still working on the redone version of the guide (it got sidelined while I help some people out and finished the EZ5 review), a no pictures version will probably appear at first and then I will see to sorting out pictures.

Edit: Going to be abused for now as a link dump/tools of the trade post

Tools of the trade

Hacking involves manipulating files which means it should go without saying (although it will be said) that taking frequent backups of your work is a wise idea.
Computers break and discs/sticks get lost so it is also an idea to get a free email account/file host and send yourself some attachments.

There are many tools of trade although they usually fall into the two main categories of game specific and general purpose.
This section will contain minimal information on usage (although a fairly in depth description will be present on what they are used for) which is to be detailed in the respective sections.
Some of the more specialist tools are left for the respective sections as well.

Game specific tools can be anything from a pointer table calculator to some of the tools aimed at pokemon games that are almost up there with the game creation tools. The former sort are usually created by a hacker/hacking team working on the game and released to save others some time should they decide to take up hacking the game.
The likes of pokemon* hacking tools are aimed at those who do not want to hack the game yet have ideas for new stories/maps and so forth, while they are quite powerful they tend to lack the ability to fine tune things/operate outside the scope of the tool and you will not really learn anything worthwhile about hacking when using them.
That is not to say they are all bad as some truly impressive works have been made using them, just remember using one of the tools (exclusively) will not/does not make you a hacker and as most hacking forums are intended for discussion other than how to use such tools meaning your questions will at best be redirected to somewhere that does deal with them and at worst ignored.
There are several tools for dealing with file formats but owing to the ubiquitous nature of the formats and that fact they do not do much by themselves they are included in the next section.

*pokemon games are usually very hard to hack owing the developers making them fairly hard to hack so you may wish to pick another game to learn with.

Regardless of what tools you use it is strongly suggested you familiarise yourself extremely well with the tool you are using.

Game specific.
Owing to the amount of effort it takes to make high level (“easy” to use) graphical tools as seen in the case of pokemon and the power possessed by modern scripting languages (like python, autoit and even bash/dos with a few helping tools) the former do not tend to appear much these days while the latter are usually distributed in script form.

Still some tools exist:

Golden Sun.
http://gbatemp.net/index.php?showtopic=229225&hl=
http://sourceforge.net/projects/gstoolkit
http://z9.invisionfree.com/Golden_Sun_Hacking/
Pokemon (almost all versions have some tools)
http://www.romhacking.net/?category=&P...itle=&desc=
http://gbatemp.net/index.php?showtopic=94499&hl=
http://gbatemp.net/index.php?showtopic=99737&hl=
Romhacking.net collection of applications:
http://www.romhacking.net/?category=&P...itle=&desc=

Some guides/sites to make things simple using more general purpose tools exist too:
Advance Wars.
http://forums.warsworldnews.com/viewforum.php?f=11
Sonic Advance
http://www.romhacking.net/docs/335/
Metroid Zero mission
http://www.romhacking.net/docs/184/
Final fantasy 4 (GBA)
http://www.romhacking.net/forum/index.php/topic,4449.0.html

Should you look around some of the various translation/hacking projects there is usually some good information available about games and occasionally even tools to help edit.

General purpose.
The two main tools of any hacker are the hex editor and the tile editor but there are many others that can make life easier.
A spreadsheet is useful, open office ( http://www.openoffice.org/ ) provides a spreadsheet program (calc) that also functions well with hexadecimal so it is worth a look.
Those involved in translation hacking will usually find a Japanese text editor a useful tool
JWPCE is a freeware tool used by many in the hacking community.
http://www.tanos.co.uk/jlpt/jwpce/
NJstar is http://www.njstar.com/cms/njstar-japanese-word-processor is also worth having.

Development of new programs is split across many languages but C,C++, C# and scripting languages (python, autoit, visual basic....) are the most common. They key aspect as you might imagine in manipulation of files with a nod to file conversion (images to/from PNG/some other lossless format, text to/from a common encoding, music to/from a common format) so it is advised you pick a language that deals with it (or at least is able to interface with tools able to do it). 3D files and the programs that deal with them will often use existing libraries/programming methods (mainly directX and opengl). A language that can readily make a GUI is also a good idea idea.

Before the more specific tools are mentioned several general purpose tools have risen to prominence in recent years so they will be mentioned first
File format specific.
There exists simple decompression tools for given formats (sometimes game specific) to general tools for a given format to full blown kits (the two most common for the GBA/DS being lowlines console tool and crystaltile2).
Lowline's console tool
http://www.romhacking.net/forum/index.php/topic,8407.html

Crystaltile2, originally Chinese language but there are now translations and the application is fairly simple to use.
http://gbatemp.net/t232718-crystaltile2-2010-06-12
SDAT files, NARC files, NFTR files and several other formats (graphical in nature) are supported. A basic usage guide is available at the end of this document.

There was another tool called tahaxan but it has since vanished (and was surpassed by other tools).

Sometimes they are distributed as application specific addons (tahaxan has xml modules) or hex workshop formats while others are distributed as scripts (python is popular here although dos/bash script also exist simple programs like file trimmers and readers), sometimes as simple command line programs (NARC files have a widely forked program) called narctool.
Alternative specifications are available at the end of this document.
Warning reverse engineering specifications is an ongoing work and different/bad implementations (or even the use of options not used in the originally reverse engineered files) can make existing tools not work. Notably in the case of pokemon the subdirectories of the NARC files are not named which causes early versions of narctool not to work.

GBA files are binary only have been covered in game specific tools above. More general tools to aid decompression and other things are available from the links above too.

DS.
NFTRedit (font files used in a lot of DS games)
http://gbatemp.net/index.php?showtopic=105...t=0&start=0
Includes specification.
Alternative specification (Chinese language)
http://www.ndsbbs.com/read.php?tid=146954

NARCtool. Narc is a common file format used to store other files, also comes in compressed format called carc and occasionally seen with the extension arc.
http://members.cox.net/dexter0/DSTools/narctool.shtml
narctool 0.1p (for pokemon roms with no folder/file name)
http://www.pipian.com/stuffforchat/narctool-0.1-p.zip (file format here http://www.pipian.com/ierukana/hacking/ds_narc.html ).

SDAT
tool for ripping: NDS sound extractor(originally from http://nintendon.s6.xrea.com/ ), source included in download:
http://www.4shared.com/file/68276816/80922...sndext_v04.html
VGMtrans
http://hcs64.com/mboard/forum.php?showthread=17715
http://www.4shared.com/file/76520093/5a299676/VGMTrans.html

swav to swar
http://gbatemp.net/t243430-swav-to-swar-converter

SDAT spec:
http://gbatemp.net/t253947-nintendo-sdat-specifications
http://kiwi.ds.googlepages.com/sdat.html
See also the source code for the various tools linked.

Various other formats have been seen on the DS for sound including windows compatible wave files, ADX/AHX ( http://hcs64.com/vgm_ripping.html do a page search for adx) and PCM audio (should be able to import it into anything that accepts a raw wave file- audacity http://audacity.sourceforge.net/ being a good program).

Start of NBSMD:
http://kiwi.ds.googlepages.com/nsbmd.html
Some nice discussion on the subject of file formats
http://www.romhacking.net/forum/index.php/topic,8407.html

Jump Ultimate stars:
http://gbatemp.net/index.php?showtopic=60809
http://deufeufeu.free.fr/wiki/index.php?ti..._Ultimate_stars

Gamecube. Multiple formats are available.
http://forum.xentax.com/viewtopic.php?t=2105
http://wiki.xentax.com/index.php?title=Just_Cause_ARC
http://hitmen.c02.at/files/yagcd/yagcd/chap14.html#sec14
http://www.amnoid.de/gc/
http://www.emutalk.net/forumdisplay.php?s=...mp;daysprune=-1
http://www.hcs64.com/in_cube.html (a winamp plugin for multiple formats including some GC (and even some wii) formats. Source is available).

Hex editors
Anything can be done with a hex editor as any aspect of the files in question can be manipulated but for a lot of things it gets quite difficult to do so a hex editor is usually used during the reverse engineering of file formats, for small tweaks to things and the manipulation of files (copy and paste, insert blank section, file corruption.....).
Being a valuable tool in almost all aspects of computing there are many hex editors, some of the things done in rom hacking are not so common though so editors geared towards rom hacking (but generally lacking in some of the general purpose functions) are available. Most hackers have a collection of editors used for different purposes for this reason.
Hex Workshop
http://www.hexworkshop.com/
A very powerful payware editor although it lacks rom hacking specific features. Most hex editor screenshots in this guide are from it.

Xvi32:
http://www.chmaas.handshake.de/delphi/free...xvi32/xvi32.htm
Simple, effective freeware editor. Again lacks rom hacking specific features.

Winhex
http://www.x-ways.net/winhex/index-m.html
Freeware (a more featured paid version exists), lacks rom hacking specific features but comparable to Hex Workshop.

HxD:
http://mh-nexus.de/en/hxd/
Freeware hex editor, Simple but effective. Lacks rom hacking specific features.

Notepad++.
http://notepad-plus.sourceforge.net/uk/site.htm
Programming oriented text editor, contains a basic hex editor.

Free hex editor neo
http://www.hhdsoftware.com/Products/compar...ditor-free.html
General purpose editor (multiple versions including free). Lacks rom hacking features.

Crystaltile2
http://gbatemp.net/t232718-crystaltile2-2010-06-12
Features a hex editor amongst other things. Rom hacking oriented features like relative search, decompression, custom character sets (table support).

Romhacking.net list of hex editors. Contains links to a whole host of hacking specific emulators.
http://www.romhacking.net/?category=13&amp...itle=&desc=

Some more general purpose hex editors with linux support
http://wxhexeditor.sourceforge.net/
http://heraia.tuxfamily.org/
http://www.softcircuits.com/cygnus/

Note a lot of the rom hacking oriented hex editors lack support for the bitwise operations and other things a lot of the originally listed editors have. The main draw is table support and other features useful for text hacking.

To cover a few
Translhextion
http://www.romhacking.net/utils/219/
Table support is the main draw along with relative search capabilities.

Windhex32
http://www.romhacking.net/utils/291/
Lots of rom hacking oriented features.

Most hackers have several editors in their toolkit. Usually a powerful general purpose editor and a hacking related editor.

Rom corruption.
The ease by which you can test code out (via emulation/flash cart) and the fact you can easily backtrack on a computer means you can indulge in a bit of “what does this button do?”. Rom corruption is where you alter a section and then test the game out to see what was broken/if the bit you want to edit is broken. Hex editors have the ability to do this but dedicated programs also exist. A sidenote, colours are limited to only 15bits (3 primary colours at 5 bits each or 0 through to E in hexadecimal)) for the GBA and DS so be careful.
http://www.romhacking.net/?category=1&...itle=&desc=

Hex editors feature the likes of bit shifting, bit inversion, logic operations and much more which can be used for corruption with the bonus of them being easily reversible.

Graphics editing
Tile editor.
There are few text based games these days so you will need to edit images at some point, a full discussion on what images are made of is present later. A tile editor makes for easier editing environment than a hex editor so it is vital bit of kit. Quickly scanning over a whole file with a tile editor is also possible and can reveal things that may not be as evident to a quick scan with a hex editor.
GBA
Note there is 4bpp (bits per pixel) and 8bpp tile formats, Some tools only include 4bpp which is OK as not that much 8bpp work is done by the GBA courtesy of CPU and space limitations. For newer systems is it fairly essential.
tiled2002
http://home.arcor.de/minako.aino/TilEd2002/
Crystaltile2
http://gbatemp.net/index.php?showtopic=81767&hl=
NDS
tiled2002 also works for DS owing to the same (as far as this is concerned) graphics hardware. The DS makes extensive use of 8bpp graphics so it really is a must for a tile editor.

Crystaltile2
http://gbatemp.net/t232718-crystaltile2-2010-06-12

GC/Wii. Use variations on the GBA/NDS and a lot of 3d work so tile editors are not as useful.
http://hitmen.c02.at/files/yagcd/yagcd/chap17.html#sec17

Unknown formats can often require reverse engineering.
Feidian is the tool of choice here
http://feidian.sourceforge.net/

Text hacking
jwpce and njstar are good tools for Japanese text editing.
http://www.tanos.co.uk/jlpt/jwpce/
http://www.njstar.com/cms/njstar-japanese-word-processor
romjuice is good for dumping text and converting it into a more workable format (converting binary flags to whatever is necessary). Simpler tools exist but often fall flat on more complex projects.
http://www.romhacking.net/utils/234/
Hex editors have replace functions though and knowing 0d0a is the usual method for “start a new line” is good to know.

A very nice tool to have during text editing is a relative search tool (indeed it can help you pull apart the text of a rom without so much as having seen it run in some form if you use simple language tricks- there will probably be vowels in every word, a characters name will probably appear, words like the, and, it and other sentence construction type words are bound to appear....).
http://www.romhacking.net/utils/513/
It can also spit out table files which you can add to your hacking type hex editor (including crystaltile2) to display unusual formats.

Assembly tools.
There are three main tools here.
Strictly speaking assembler is the human readable form of machines language, assembly is the action of turning assembly code into machine code, an assembler is the program used for the process of assembly..
Disassembling is the action of turning machine code into assembly code, a disassembler is the program used for disassembly.
Compiling is the action of turning high level code (like C or java) into assembly (or more commonly machine code).
Decompiling is the turning of machine code (or assembler) into a high level language. It is very rarely done by a machine unless the language allows for it (java and scripting languages like autoit are common targets) owing to it being incredibly difficult (most companies rely on this fact to prevent hacking by anyone who can code), as an aside dynamic recompilation is the technique used in several emulators where instructions are turned directly from code for one system into code for another as opposed to running a mockup of the hardware and running the code through that (conventional emulation). In much the same way decompilation exists for common operating systems, compilers and languages like C# that rely on a system of libraries used by all users of a language to do common task.
A decompiler is then a program that decompiles code. Some decompilers act as a halfway house between disassembly and true decompilation and will decompile things that the decompiler can recognise (as complexity increases people turn to premade libraries to do things, decompilers can be made to spot these) and leave the rest as raw hexadecimal or assembly. None exist for any of the systems covered by this guide though (the closest available is the NEF format crystaltile2 and no$gba support that allows for some basic comments to appear in the disassembly).

In practice assembler and assembly are synonyms along with ASM (to do that will require an ASM hack, I programmed it in ASM). Searching for disassembly will tend to find you guides on how to pull apart a console* meaning disassembler is is good search term.

*going back to the sanitised names part for hacking related terms from the introduction. Disassembly of the console is generally considered part of hacking/modding and will be taken down by the more overzealous anti-piracy types, console repair on the other hand uses exactly the same methods.
Similarly machine repair will not involve assembly language so adding (program) disassembly specific terms like opcode to the search with disassembly will tend to narrow the results to things that you might want.
Tile (or some other) format editors are also somewhat afflicted by the same problem, tile or graphics viewers on the other hand will usually have some good info/source code that can be twisted to editing purposes (or be straight up editors as well). Not to mention that viewers can usually render something in a far more useful manner for the non hackers on a team than most tile editors.

Assemblers: turns assembly code (text based) to machine code (binary/hexadecimal based). Normally you will only author a small extension to a binary with the assembler, (for example to change a game from displaying each character 8 pixels apart to checking the width and placing each character so there only 2 pixels between each edge of the visible character).
ARM:
http://common-lisp.net/project/armish/
http://labmaster.bios.net.nz/pyga/
http://www.romhacking.net/utils/343/ (ARM7 only)

See also LIARDS by the same author if you plan on doing DS homebrew using assembly:
http://common-lisp.net/project/liards/

For the gc and wii powerpc processors (as well as the GBA and DS processors) the homebrew developers kit known as devkitpro is suggested.
http://www.devkitpro.org/

Disassemblers:
The tools turn machine code (binary/hexadecimal based) to assembly code (text based). Note this is not an exact science so freshly disassembled code may well not be able to simply assemble. There exists a free disassembler for all the consoles but a bit of paid software called ida (interactive disassembler) is commonly used and is geared towards reverse engineering.
There are two main types of disassembler: raw disassemblers and format specific. The former blindly disassembles files while the latter is geared towards a known file type (like exe, elf or DOL in the case of the GC/Wii) or more simply disassembles at a given location (the GBA binary starts after the header with the actual code also being referenced after the I/O routines) or automatically attempts to switch to ARM to THUMB code for the likes of the GBA and DS (there are two instruction sets).

Links to basic assembly code/instruction/opcode lists included as well.

GBA
Emulators feature the option. Nearly all versions of VBA include a basic disassembler.

Crystaltile2
http://gbatemp.net/index.php?showtopic=81767&hl=

gbadsm (java and DOS versions available)
http://www.postbox.javamaster.co.uk/downloads.html

Assembly code.
http://nocash.emubase.de/gbatek.htm#cpuoverview
http://consolehacking.org/wiki/Main_Page

NDS
ndsdis2 (parses the header: you can feed it a raw rom)
http://hp.vector.co.jp/authors/VA018359/nds/ndshack.html
Some emulators have the option, the most advanced is no$gba paid version (freeware version lacks the debug features of the paid version although some extra programs/techniques can be used to allow cheat making), desmume has good abilities in this area.
IDA plugin:
http://www.openrce.org/downloads/details/56/NDSLDR

Assembly code:
http://nocash.emubase.de/gbatek.htm#cpuoverview
http://consolehacking.org/wiki/Main_Page

Gamecube
vdappc (windows, mac and linux versions and alterations to those).
IDA modules and more
http://hitmen.c02.at/html/gc_tools.html

Opcodes and the like
http://hitmen.c02.at/html/gc_docs.html

Wii:
Some gamecube tools work (the “broadway” processor is upwards compatible with the gamecubes) but most is done with IDA. Work is ongoing.
http://wiibrew.org/wiki/Broadway/Registers
http://wiibrew.org/wiki/Wii_Hardware

http://www.backerstreet.com/rec/rec.htm#Features
Aimed at general powerpc processors but worth a look.
IDA plugin:
http://www.openrce.org/downloads/details/1...der_Plugin_v0.1
http://github.com/Megazig/WiiTools

Tracing tools:
Invaluable on the GBA, less so for newer systems. These log when an area of memory is read and what command was doing it. This means if you determine some text is in a given memory section (usually by corruption) you can run the emulator again and wait until the text gets written there and trace it back to where it came from (which hopefully is a location in the rom, if not a few extra steps are necessary). This is also a fairly simple (but very powerful) assembly level technique. Simpler versions of these methods are used to make cheats and these can be turned to hacking purposes.
File systems make tracing incredibly difficult to do (all consoles lack a virtual file system at this time), the best technique is usually to try a search within the rom/file in question with data pulled from the memory, with information being compressed and dynamically generated this obviously falls far short of true tracing.
GBA. Usually this is done with a specially made emulator, the most common here being vba-sdl-h but the functionality has been added to other versions of VBA.
http://labmaster.bios.net.nz/vba-sdl-h/

Emulators.
Emulation is invaluable in software (and to some extent hardware) creation and debugging (read rom hacking) as it allows quick checks on changes and the ability to change things in real time. More importantly a lot of emulators feature save states (also known as instant saves, real time saves, snapshots and several other similar names) which can mean a quick way of getting to the required places.
Little in the way of hardware level debugging exists so it will not be covered.

GBA.
The GBA has several emulators although for hacking the list tends to then shrink to PC only emulators.
VBA-sdl-h
http://labmaster.bios.net.nz/vba-sdl-h/

“vanilla” VBA, Not as full featured.
http://vba.ngemu.com/
See also VBAlink (allows emulation of the link cable)
http://vbalink.wz.cz/
And VBA-m (a combination of all of the forks of VBA, work is ongoing)
http://vba-m.ngemu.com/

no$gba. The debugging sections cost money (fairly cheap for hobby users) but it is generally regarded as one of the best tools for the job. The author has been absent for a long time though.
http://nocash.emubase.de/gba.htm

DS:
While emulation may not be at a “fully playable” level the emulators are certainly good for hacking (being slightly slow/juddery in graphics does not matter if you can eventually see what you need).
There are many emulators for the GBA with most featuring some level of debugging.
no$gba
http://nocash.emubase.de/gba.htm
Desmume (limited hacking features)
http://desmume.org/
iDeaS
http://www.ideasemu.org/

The GC and Wii have a few emulators, the most advanced probably being http://www.dolphin-emu.com/news.php

Strictly speaking file/font viewers are also types of emulation but this will be covered in the relevant sections.

Patching tools.

Unlike the other tools this section will have a discussion as it is applicable to all areas and types of hacking.
Developers tend to frown upon distribution of rom/iso images and doing so is not also that nice on bandwidth for the end user. Patches however can be made that only contain the changed data and so people are free to distribute them (technically it can fall under the derived work aspect of copyright law but it is a relatively unexplored area, for more see the discussion on rom hacking and the law at the end of this document).

The are many ways of making patches however. Methods of making patches and tools aimed at end users (the “complexity” of some patching methods are often a source of frustration for new users unfamiliar with patches) will be detailed.

IPS
Very common on the earlier systems but there is a 16 megabyte* file size limit (there is a hack to allow the patch to start at an offset but it is not widely supported).
The coupled with the fact it is a “dumb” patcher in that it sees changes in the original file and makes a patch accordingly. This is not a problem for systems up to and including the GBA (assuming it is 16 megabytes or under in size) where shifting bytes would mean a large amount of work but newer systems where files can be shifted (which happens often) and also signed/encrypted (looking mainly at the wii) mean a change is seen and consequently encoded.
*actually it is 16 megabytes – the bytes to represent EOF (end of file). Most patchers will also support changes within the first 16 megabytes which led to the use of IPS for some trainers and simple patches.
However it is widely used and supported so it is still worth mentioning.
Patch making.
IPSXP
http://home.arcor.de/minako.aino/ipsXP/

Patch applying
GBATA:
http://www.no-intro.org/tools.htm
http://ezflash.sosuke.com/viewtopic.php?f=...047&start=0

BSDiff
Used by many of the trainers released by “scene” groups and on several other occasions.
Patching and application
http://sites.inka.de/tesla/f_others.html#bsdiff
See also
http://ezflash.sosuke.com/viewtopic.php?f=...047&start=0

Xdelta
The main rival to BSDiff. Can achieve similar levels of usability to BSDiff.
http://evanjones.ca/software/xdelta-win32.html (older but still widely used port)
http://code.google.com/p/xdelta/ (google code pages)
Patch applying can be done with:
http://ezflash.sosuke.com/viewtopic.php?f=...047&start=0

PPF
Playstation patching format. Originally designed for use with the original playstation there were several often mutually incompatible implementations. Today it is mainly used by some hackers of wii isos.
http://www.romhacking.net/?category=2&...e=&desc=ppf

UPS
Designed as a replacement for IPS and to unite the different formats it has not achieved a large foothold yet.
http://www.romhacking.net/utils/519/

Workaround and custom/patching implementation.
Courtesy of wii isos being signed and no signing key (the existence of the verifcation key and certain bugs are what is used, more under file systems) most patches will patch the decrypted file and get the user to rebuild the ISO thus avoiding the problem with lots of changed bytes. Several patching methods mentioned above are used and it is the main reason for the inclusion of PPF in this document.

Some patches for DS roms use a similar technique although as the file system is not signed the whole process can be done by one program (or more commonly batch file). Here the DS rom is pulled apart and the individual files patched before the rom is rebuilt. This makes smaller patches than even the “smart” patching methods of xdelta and BSDiff as well as allowing different grades of patch to be applied (for example in the case of multiple cheats or for sound hacking where different amounts of change are called for the users of the patch).
Deconstruction of the file system type methods also make it slightly easier to implement multiple hacks from different groups if done correctly.
A few others release patching “programs” based on their own or an existing method.

More patching methods and alternatives to the tools above
http://www.romhacking.net/?category=2&...itle=&desc=

An aside on stacking patches
You will have to understand how things work with the DS (as well as GC and wii) and how patching mechanisms work.
All known commercial DS roms use the nitrorom file system and all use their own file types underneath that. These file types are what makes DS rom hacking easier and harder at the same time (easier as you do not have to worry about space and harder as tracing (a method by which you can determine what does what with extreme accuracy) is nearly impossible.

Patching mechanisms also vary, some of the more modern ones like deufeufeu's patching system and the earlier hacks with batch files and rom ripping rely on the fact the DS file system exists.

Others like IPS, bsdiff and xdelta work simply by having an address (or three) and replacing the information at the address with the data they hold. It gets far more complex in that IPS has a limit of 16 megs unless you use the hack (which hardly anything supports) to change the starting address giving you a window, it is also a dumb patcher in that if you change the position of something position in a file it sees a "change" rather than a shift. Xdelta and bsdiff do not have the size limit and for the most part shifts do not affect them either which is why they are used for the DS.
Another problem comes with the newer patching types that implement hashing into a patch (it will check to make sure the file you are putting is good and the file coming out is also good), you can usually tell it to ignore the hashing though although it may take going to the command line to do it.

However many hacks work on the internal file system of the files within the DS rom:
small patches like the basic sound hacks (tetris, pokemon, Castlevania POR), cracker's early trainers and some the scene trainers only change files within the rom and so should not need to rebuild it or change the location of anything.
If the hack is simple (as in the case of the simple sound hacks) the the length of the file will not change and if the hacker knows what they are doing they will reinsert the file with something like ndsts instead of rebuilding the entire rom. Note you can usually pad smaller files out to match sizes and then insert using this method.
This is not always the case though and some choose the rebuild the rom (which has another set of problems as various rom/flashcart combination do not get along with ndstool which DSLazy and DSbuff use to manipulate the file systems of DS roms), mario kart is the classic example and 99% of the time when the basic undub procedure fails (basic procedure is grab sound files from Japanese rom, replace sound file from US/Eu release with Japanese one and rebuild) it is because of this problem.

If it is a basic patch using something like ndsts or ndshv such as the sound hacks you can usually stack as many of these as you please. Note that just because you can does not mean you should: trainers and sound hacks could well use the same things and interfere with each other (for example changing a sound file to play 1 song and then changing it to play another in another patch will mean you “lose” the effects of the first patch).

There is also another method whereby you extend the size of the rom beyond what it normally is (trimming roms just gets rid of junk space and you can reclaim this junk for your hack). For the most part this sidesteps the problems with ndstool based operations (at the cost of wasted space) and allows you to change file sizes without rebuilding the rom. Aside from some internal testing and that of a few others nobody has yet done this to an actual rom hack released to the "general public" on the DS but it has been seen a few times for internal files, on the GBA there was a problem with earlier scene intros that did just this which meant roms could not be trimmed (a 32 megabyte card could well cost over $100 back when: roms were up to 32 megabytes, average was 8 to 16).

Translation patches and bigger changes may well change the file sizes (pointers are simple and space is near enough unlimited so people tend not to have space constraints like in the older systems) and so the file system will be rebuilt.

Knowing this you can bypass some of the problems or work around it. If for example you want to apply a trainer to a rom and a translation patch apply the trainer first as it should not touch the rest of the rom and it will likely be a dumb patch of some form and when the translation rebuilds the rom you can get the best of both worlds.
On the other hand you can reverse engineer the rom hack and find which files are changed before reassembling a hack of your own.

Adding into this is the patching used by GBA slot cards when running DS roms, often they expect clean roms and so you have to be very careful when patching them usually this patching is done last though and hackers will know this. It also has the effect of changing positions for some things which can make the dumb patching methods (IPS and the like) fail.

704jaffer · Jul 13, 2008

Holy crap, what an awesome collection of info. I'd been meaning to take a look at some "tech docs" on rom hacking, think I found the one I'll be using.

Sp33der · Jul 31, 2008

Hey FAST great topic, but could you tell me some more about .narc files?

FAST6191 · Aug 1, 2008

How to use Crystaltile2

Crystaltile2 is a fantastic general purpose rom hacking application with many features useful to ROM hackers. As such it is almost like an IDE and as such it is quite complex so the following aims to serve as a guide to the basics.

You can grab it http://filetrip.net/file.php?id=23649

Introduction
I know of no guides and while it is a very nice application it is still a very low level application however you slice it so a true guide would read more like a general hacking guide than how to use crystaltile2.
It is a Chinese application but there are translations, the English one was made by cory1492 and myself (apparently) but between high level technical language, a bit of machine translation at points and the volume of text that often repeats parts of it are a bit crude.
A note before we start- the basic application is easy enough on your machine but start playing even with some of the basic search methods and you will soon eat memory faster than any memory leak you have ever seen. The more advanced search/scanning methosds will be a true test of your machine.

I will not be covering emulator integration in much detail because frankly I do not know enough about it to say much other than it exists and as of the later versions it has rather nice support for things like nef files (about as close as we come to decompiling- think of it as ASM with awesome premade comments) and you select your emulator (while it is running/in memory from the file DS emulator options, No$gba is the main one). From there it can snatch the odd thing like a palette or some memory from it which can be useful for basic editing if your palette is dynamic, compressed or otherwise hard to get at in the rom.
I have however been looking to do this sort of thing since I first discovered the application so here we go:

General usage/theory
There are 5 main features of the application and several niceties associated with the whole application.

tile viewer, hex editor, disassembler, tile editor and text editor which are represented by the 5 icons on the right hand side of the icon list or the view pulldown menu. The pulldown menus do change depending on what one of these modes you have selected, they are however usually context relevant (no graphics in the text editor for instance) and the general tools menu should be there throughout (though that too changes). As such good practice is to have the editor relevant to what you want open when doing things of that nature.
Each mode is perhaps not as good as a more specific application (the disassembler is not going to worry IDA any time soon for instance) and indeed the same applies to some of the other options but for breaking into a new ROM I know of no better tools and while there are better options for the specifics most are perfectly functional and can get most things done.
Where it really shines is when you use the DS file system support and some of the extra features which I will cover in a few paragraphs.

DS file system support. First you need to click on the DS looking icon also on the right hand side.

This will open a sub window showing the DS file system. The pulldown menus have some good options that I encourage you to scan through.
Generally speaking though there are three things you want to be looking at on this page

The icons on the left of the files- these give clues as to what they are and rather nicely if they are compressed.
The file name for obvious reasons.
the sub file categorisation on the right hand side.
The number, address and size data is useful for hacking but here you are probably looking at a more specific hack if you are looking at this. On the other hand if you have opened the entire rom or a subfile in a hex editor it can be useful for tracking it down.

Basics here are a double click sets the start address of the file you just clicked on in the tile viewer, disassembler and hex editor.
Right click provides more options, most importantly is the sub file sort (f2 is also a shortcut) and compression support but extract and import are great too.
Format support in crystaltile2 is the second big strength after DS file system support. Many many file types are supported including most of the big SDK formats like SDAT, NARC and the graphics NCER, NCLR and so on.
SDAT, .bin (assuming it is something like utility.bin) and NARC will open new windows much like the one you were just working on although in the case of SDAT there is some somewhat broken playback options.
Right click on the graphics will allow you to do one of three things (more on graphics here: http://tahaxan.arcnor.com/index.php?option...=36http://pix.gbatemp.net/32303/gundam2.JPG

Compression support is another strength, for the longest time crystaltile2 had some of the best compression support in general rom hacking tools (indeed some of the new LZ flags were supported long before anything else). It works in much the same way as import and export files does but it can use compression algorithms at the same time.
More general compression options are available under the tools menu including a general compression app and rather nicely a compression search that rivals anything else I have seen.

After this you have a NFTR editor (a relatively common font type in DS roms) which includes font conversion abilities (as in you grab a PC font and it will spit out a NFTR font)
Multimedia editor- more aimed at animation than sound. Would probably get a call from Nintendo's legal types were it not in China.
Below that is a rather crude OCR app that in my version at least seems to have escaped translation but it is the only one I have ever met in rom hacking. I use them day in day out in video and images but for rom hacking...... wow.

Onto the main tools side of things. You have a tile viewer, hex editor, disassembler, tile editor and text editor.

Tile viewer
Assuming you have not wound DS formats into it the tile editor is a fairly full featured one. It is not as pretty as some others (indeed I still keep a copy of TilEd 2002 around for really crude work) but it has great features like nonstandard tile size (7x13- not a problem).
First thing to note is the keyboard shortcuts which do nice things like change starting offset which is nice for dodging headers and whatever else. Everything else is self explanatory aside from perhaps tile form(at) which allows you to chose between all the various image modes (and there are a lot) that crystaltile2 supports. Most useful are GBA 4bpp, GBA 8bpp (the modes used by the GBA and DS, note that most GBA stuff is 4bpp while 8bpp is very common in the DS) and nds1bpp (useful for a certain type of packing used sometimes in fonts) but play with it all.

If you higlight a selection of tiles you can export it to a more common format (word to wise, stick with lossless if you plan on dragging it back into the app), 1:1 is a "regular expression" style exporter.

Hex editor
A hex editor, rather basic but for the table support and inbuilt support for shiftJIS (back when it was one of the very few that did making it a very valuable tool)
Use of tables is chosen in the box on the left (same place as the tile editor before it) and more general codepages can be chosen by clicking on the section above the text decoding (probably saying Western European (Windows) at first).
In the box the options other than table support is choice of known codepages
choice of sort options (1 byte, 2 bytes or 4 bytes)
colour character- not as useful as it might be in other areas as it can be a bit hard to read at pace unlike tiles but to each their own.

Data to palette and palette to data do as they say on the tin and grab the hex and stick it in the palette and vice versa. A nice shortcut for some but probably not all that useful as most games I have ever tangled with tend to opt for the RAM to do things to the palette or in the case of the DS have it wrapped in some format.

Disassembler
Rather basic crude disassembly supporting ARM9 and ARM7 including THUMB for each. You force change between these modes in the same way you changed premade code tables (clicking where it says ARM? .
You can get base address at the top of the "effective address" list.
You can an offset (goto address) too in the box on the left

Assembly is a topic for coverage elsewhere but you have effective address, hex code for the instruction and the mnemonic and registers/addresses* it deals with.

*this is one of the things NEF files can sort for you- if a given address is a given thing the NEF file will make it change to an even more readable format.

Tile editor
Unless you have an image made up from DS format options it will just have the tile you have selected in tile viewer.
Fairly basic, you snatch colours from the palette by clicking on the button and choosing it,
left is char, right is BG.

usual warning about palette based graphics- a change of one thing can have effects on another if things are reused which they often are and likewise they are palette not bitmaps so changing a colour in the palette may not necessarily translate to the real game.
Much like the other palettes and the hardware itself you have 16 available (0 through F).

Script editor
Originally a standalone app from the same author, most useful is probably the table support and the script search (it is an upgraded version of the search strings option (namely table support) you may have seen in various hex editors), under the tools menu it is called Ambassador search.

If you already know text editing the rest is fairly obvious. Exit code= line end/new line sort of thing (0D0A in windows .txt for instance, 0000 in bmg files (a somewhat uncommon DS SDK text format))

Geared towards the GBA mainly but can be pushed towards the DS side of things.

In the translation I have in front of me "censorship" allows you to narrow down the broad/"crude"* search but it will require some tweaking/defining what you want.

*the methods/algorithms behind these techniques are anything but crude but the results they produce are far from "magic application" grade.

Annoyingly the relative search (I personally use monkey moore for such things: http://www.romhacking.net/utils/513/ ) is back on the hex editor menu under the search or the tools pulldown menus for the version I have in front of me. It is a fine relative search with many options including 4 byte search which is insane (I have only ever heard of 4 byte fonts- 4294967296 possible characters, 16 bit is 65536 which is more than enough for pretty much every character in every commonly used language).

There loads of other little featured buried around the program (compression search is quite nice) so do poke around the menus and test things out. Be warned some of the more exotic features will crash the program and use lots in the way of resources.

Lockon Stratos · Dec 31, 2008

Hi, you think you can send the links for the main programs needed to hack any NDS game and. Sorry I'm not much of a reader and I can't be bothered to dig through your giant tutorial for the links.

Lockon Stratos · Dec 31, 2008

Hi, you think you can send the links for the main programs needed to hack any NDS game and. Sorry I'm not much of a reader and I can't be bothered to dig through your giant tutorial for the links.

You think you can put some examples up for every time you introduce a new style of encoding?

Wow I've read quite a lot of it and I'm beginning to learn quite alot I just want to also learn what programs/ apps. I need for hacking. >.>

dice · Jan 1, 2009

refrain from triple posting please, that's what the edit button's for

Lockon Stratos · Jan 1, 2009

Quoted from dice:

refrain from triple posting please, that's what the edit button's for
Click to expand...

Okay

psycoblaster · Jan 2, 2009

Quoted from Ameer10:

Hi, you think you can send the links for the main programs needed to hack any NDS game and. Sorry I'm not much of a reader and I can't be bothered to dig through your giant tutorial for the links.

You think you can put some examples up for every time you introduce a new style of encoding?

Wow I've read quite a lot of it and I'm beginning to learn quite alot I just want to also learn what programs/ apps. I need for hacking. >.>
Click to expand...

Main programs to hack any NDS game? I can't say about "any" but crystaltile2 is the only multipurpose program I can think of that is used for NDS games.

And encoding?
Basically, about encoding, take a look at several code pages such as Shift-JIS, Unicode, and others.
http://www.rikai.com/library/kanjitables/k...odes.sjis.shtml
http://www.rikai.com/library/kanjitables/k...s.unicode.shtml

Most Japanese games use Shift-JIS, including Tales of Innocence, Tales of the Tempest, ASH, and more.
Other games use UTF-16BE, such as Ragnarok DS.
Some games use font based encodings, such as Etrian Odyssey 2 and TWEWY.
Other games use their own encodings, which I can't find an example for right now.
The best way to determine the encoding the game uses is by looking into a font file.
Many NDS ROMs uses NFTR font files, which are font files with all necessary information, bitmap fonts files which has no information in them but instead only has the "pictures" of the font.
If you manage to find the font, look at how it is arranged.

This is S-JIS.

This is Unicode.

Lockon Stratos · Jan 2, 2009

Thanks pscyoblaster you've been of great help to me I'll try on my own for a while until I get stuck. lol

Useful Searches

OP FAST6191 Techromancer Reporter Level 28

matthewd997 GBAtemp Regular Member Level 1

OP FAST6191 Techromancer Reporter Level 28

OP FAST6191 Techromancer Reporter Level 28

Flam9 GBAtemp Regular Member Level 2

altorn GBAtemp Maniac Member Level 8

Upperleft Namcoholic Member Level 2

Chotaz I'm back! :D Member Level 2

OP FAST6191 Techromancer Reporter Level 28

OP FAST6191 Techromancer Reporter Level 28

OP FAST6191 Techromancer Reporter Level 28

704jaffer GBAtemp Regular Member Level 1

Sp33der GBAtemp Fan Member Level 1

OP FAST6191 Techromancer Reporter Level 28

Lockon Stratos GBAtemp Regular Member Level 2

Lockon Stratos GBAtemp Regular Member Level 2

dice pansy-ass ex-staff member Former Staff Level 6

Lockon Stratos GBAtemp Regular Member Level 2

psycoblaster Divine Member Level 2

Lockon Stratos GBAtemp Regular Member Level 2

Hide similar threads Similar threads with keywords - documentation, GBATemp, hacking

Not a bug Personal Blogs on GBATEMP result in hacking attempts

Share this thread:

OP FAST6191 Techromancer
Reporter
Level 28

matthewd997 GBAtemp Regular
Member
Level 1

OP FAST6191 Techromancer
Reporter
Level 28

OP FAST6191 Techromancer
Reporter
Level 28

Flam9 GBAtemp Regular
Member
Level 2

altorn GBAtemp Maniac
Member
Level 8

Upperleft Namcoholic
Member
Level 2

Chotaz I'm back! :D
Member
Level 2

OP FAST6191 Techromancer
Reporter
Level 28

OP FAST6191 Techromancer
Reporter
Level 28

OP FAST6191 Techromancer
Reporter
Level 28

704jaffer GBAtemp Regular
Member
Level 1

Sp33der GBAtemp Fan
Member
Level 1

OP FAST6191 Techromancer
Reporter
Level 28

Lockon Stratos GBAtemp Regular
Member
Level 2

Lockon Stratos GBAtemp Regular
Member
Level 2

dice pansy-ass ex-staff member
Former Staff
Level 6

Lockon Stratos GBAtemp Regular
Member
Level 2

psycoblaster Divine
Member
Level 2

Lockon Stratos GBAtemp Regular
Member
Level 2