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

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/

 

[FAST6191]

Yeah I am not sure what happened there, lyx is usually pretty reliable in making pdfs that are worth having. I would never really have searched it either as I have the base document here and otherwise know where most things in it are/have the contents page.

Anyway that version copies and searches so there is that for now. I am probably going to return to it soon and fiddle with some stuff, maybe even finally finish the bit on GBA audio, so I will update things on the main page/download then.

 

[takeya yuki]

Yeah I am not sure what happened there, lyx is usually pretty reliable in making pdfs that are worth having. I would never really have searched it either as I have the base document here and otherwise know where most things in it are/have the contents page.

Anyway that version copies and searches so there is that for now. I am probably going to return to it soon and fiddle with some stuff, maybe even finally finish the bit on GBA audio, so I will update things on the main page/download then.

Sir, can you teach me how to add more space for text edit on nds and PSP game. Because I have this problem when I try translate some game with limited font problem with no space....

 

[FAST6191]

Assuming you don't face scripting or memory issues (both things on many platforms, the latter especially on the systems like the DS and PSP which do not have things able to be mapped to memory) then it is usually pointers you want to play with. I am not sure of the specific forms PSP pointers take (I have seen a few, they are fairly obvious and nothing too strange there) but DS ones I cover a few examples of in the docs. In the case of the DS you might also have to alter file size indicators or section size indicators (seen both in text files and in countless other files on the DS) but it is still going to be pointers and size values much like the pointers for the text itself.
The short version is pointers are lists of numbers, usually early in the file, which say how long or where each line/section/whatever is within the file.You make one longer and the pointers after it are out by however much longer you made it so you need to change that pointer and all of them after it, same again for the next line and the next line and the next line... so most redo pointers once they have finished editing. If you are lucky each section will end or start with something you can search for, copy the search results and then manipulate numbers with a spreadsheet or program or something before putting it back in.
There are other things some games use but it is not very common and hopefully you do not face it here.

Fonts can come into it, especially if you are doing a 16 bit to 8 bit conversion, but for the most part are separate concepts.

 

[takeya yuki]

Assuming you don't face scripting or memory issues (both things on many platforms, the latter especially on the systems like the DS and PSP which do not have things able to be mapped to memory) then it is usually pointers you want to play with. I am not sure of the specific forms PSP pointers take (I have seen a few, they are fairly obvious and nothing too strange there) but DS ones I cover a few examples of in the docs. In the case of the DS you might also have to alter file size indicators or section size indicators (seen both in text files and in countless other files on the DS) but it is still going to be pointers and size values much like the pointers for the text itself.
The short version is pointers are lists of numbers, usually early in the file, which say how long or where each line/section/whatever is within the file.You make one longer and the pointers after it are out by however much longer you made it so you need to change that pointer and all of them after it, same again for the next line and the next line and the next line... so most redo pointers once they have finished editing. If you are lucky each section will end or start with something you can search for, copy the search results and then manipulate numbers with a spreadsheet or program or something before putting it back in.
There are other things some games use but it is not very common and hopefully you do not face it here.

Fonts can come into it, especially if you are doing a 16 bit to 8 bit conversion, but for the most part are separate concepts.

Sorry sir I still lost at here because
I don't know what pointer is???
Can you show the pic of pointer. It's easy explanation for me to understand sir

 

[FAST6191]

It is all in the guide in far more detail than I can reasonably do here.

Equally they can take many forms, a picture of one might well have no real bearing on another type unless you already understand the concept.

Generally though they are long lists of numbers somewhere in the ROM or in the file or in a similarly named file, if they are in the file it is usually at the start of the file before the text/pictures/sound/whatever starts. They are a thing which tells you (points if you will) to the location within the ROM/file/memory that houses the piece of data you need. They are what the game uses so when you make things longer or shorter it then when it tries to load from the location the pointers say it gets something else and you get garbled text, crashing and such.
The pointers can take several forms, the big three main ones being standard (the pointers point directly to the location in the file), offset (they start counting somewhere else than the start of the file) or relative (you take the position of the pointer and add the value of the data the pointer location holds to the location of the pointer and get where you are going, this is annoying but does make some things slightly quicker).

I usually describe pointers like being the contents page of a book, if you imagine inserting 10 extra pages somewhere in the middle then everything else will be shifted by 10 pages, take out 4 pages a bit later after that and then some things are 10 pages out, some are 6 pages out and you have to redo everything. Back in games you are probably not going to be changing just two lines but all of them.

There are other options, including scripting based text systems (I have an example from the wizard of oz game in the docs) and fixed length systems (common in older games in menus), but you are probably not going to be facing them.

 

[takeya yuki]

O

It is all in the guide in far more detail than I can reasonably do here.

Equally they can take many forms, a picture of one might well have no real bearing on another type unless you already understand the concept.

Generally though they are long lists of numbers somewhere in the ROM or in the file or in a similarly named file, if they are in the file it is usually at the start of the file before the text/pictures/sound/whatever starts. They are a thing which tells you (points if you will) to the location within the ROM/file/memory that houses the piece of data you need. They are what the game uses so when you make things longer or shorter it then when it tries to load from the location the pointers say it gets something else and you get garbled text, crashing and such.
The pointers can take several forms, the big three main ones being standard (the pointers point directly to the location in the file), offset (they start counting somewhere else than the start of the file) or relative (you take the position of the pointer and add the value of the data the pointer location holds to the location of the pointer and get where you are going, this is annoying but does make some things slightly quicker).

I usually describe pointers like being the contents page of a book, if you imagine inserting 10 extra pages somewhere in the middle then everything else will be shifted by 10 pages, take out 4 pages a bit later after that and then some things are 10 pages out, some are 6 pages out and you have to redo everything. Back in games you are probably not going to be changing just two lines but all of them.

There are other options, including scripting based text systems (I have an example from the wizard of oz game in the docs) and fixed length systems (common in older games in menus), but you are probably not going to be facing them.

OK I got it and thanks sir

 

[YugamiSekai]

Sorry to bump, but can this help with reverse engineering file formats on current systems and games too?

 

[FAST6191]

It is not aimed at it, and a lot of the examples are specific and kind of tailored to what is on the GBA and DS, but I doubt it will hurt. It does not cover some of the things seen in the latest and greatest formats (I barely touch floating point for instance, and going from there I do even less with some of the crazy 3d maths that some modern formats are based around), however throughout all of it I hoped to show that understanding the concepts underpinning it all (learning that the pointers for a file are 2 bytes per entry is one thing, learning what pointers are and why you need to know them is another and what I aimed to cover more) is what you want. Equally I have wandered into new systems I have no idea about prior to wandering in ( http://gbatemp.net/threads/a-little-bit-of-3ds-rom-hacking.333348/ being one such example), in such cases what I learned from the GBA and DS helped, and combined with some hardware documentation for that system I was able to make some headway.
I don't know if I have something else I can link that will be more general, most of the time I would go in for programming and hardware so I don't know what else is really out there. That said I did a quick search using "guide to reversing formats" as the term and it brought back some good stuff.

 

[TeamAwesomeness21]

um,so,how do i translate yes precure 5 from japanese to english?

 

[Camilius]

Very helpful, thank you, it's a pity that some link has died out. Maybe this will take a while to master, hope that my brain won't be overloaded

 

[FAST6191]

Very helpful, thank you, it's a pity that some link has died out. Maybe this will take a while to master, hope that my brain won't be overloaded

I will likely be going through it again at some point soon.

That said most of the links should be on https://gbatemp.net/download/ these days as all the public files made their way over to there again, and should also be on romhacking.net most of the time as well if you search for the name.

 

[Xylorapis]

Hello, sorry to bother you. I've recently heard about you and your hacking skills, etc... And I was wondering if you could help me.
I'm trying to figure out how to create a code, on pokémon, to make critical hits in battle. Could you help me ? (please) ^^
Thanks.

 

[FAST6191]

There are plenty of dedicated pokemon forums, including on the DS, and I would be surprised if they have not done such a thing.
https://www.pokecommunity.com/
https://projectpokemon.org/home/forums/forum/68-rom/
Those are probably the biggest two but there are loads of others.

As a general concept for a normal game you have two main approaches.
1) You learn the battle routine to the point where you can force a critical
2) You bump the luck stat or whatever the game uses to determine/influence such a thing as high as possible and hope that is enough (sometimes it won't be every hit, or things might still miss, but will generally be enough).

I assume you are familiar with general cheat making but https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial if you need something. It is for the GBA but cheat making works the same on just about everything (search for something, change it, search for what changed, change it, search for what changed, maybe don't do anything for a few seconds/leave the value you care about alone and then search for what did not change, change it, search...).

2) Is likely this, albeit possibly harder to do if you can't change luck as easily as you can say HP, mana (or pp in the case of pokemon), ammo, potions in inventory...
I will note that many games will put all the stats and variables it cares about in a row or near enough. That means you might get somewhere by searching for something you can change and then looking immediately before or after that.
Anyway think of all the ways you can influence luck (items, moves, moves the enemy has that decrease yours, if said effects wear off after a few turns...) and search accordingly. By all means use other cheats to make this easier -- inventory cheat for infinite items, if they hold a berry then infinite berries, give them infinite HP and PP, give your enemy infinite HP if that is going to bother them...
In battle is probably better but out of battle might also work or tell you something, even if it would likely make an illegal pokemon, oh and by all means make one of those (though maybe keep it off any saves you don't want to be banned on) if you think that will help you in this.

1) is a bit harder and will require some understanding of the game (while you probably won't have to get to https://www.dragonflycave.com/mechanics/gen-i-capturing level it will be getting some of the way there).
If you found luck you can try searching for anything that references that. Otherwise in most cases I would find the enemy HP. Any changes to this are normally the result of you doing damage (and in most games the few instances of healing are so few and far between that you can usually skip them). The game will then have to do a calculation based on whatever factors it uses (ATK, their Def, weaknesses maybe...) which will hopefully include a determination of a critical hit somewhere in the mix. You then get to figure out what you need to force this to always be critical.
This can be easier said than done if you are new to things as you will be playing with a debugger and assembly, which for many is the final boss of the ROM hacking world. Don't be put off though as you are not going to have to learn all the opcodes, their timings, all the hardware quirks and everything else that emulator authors and the crazy end of ROM hacking find themselves discussing.
https://www.romhacking.net/documents/361/ is for the GBA and for a command line tool (today I would usually point people at the graphical no$gba debug version -- http://problemkaputt.de/gba.htm ) but if you can follow along with the ideas in the document you can do stuff here. Assembly debuggers will usually operate around so called breakpoints and have a bunch of stuff you can look at the state of various pieces of memory with, anything more is a bonus really. Breakpoints (and watch or log points) usually have fairly obvious names that will cause the emulator to stop and say this thing wrote to this bit of memory (BPW), read from this bit of memory (BPR), executed this instruction and so on and so on and so on. They will usually then detail the last few instructions that happened before that so you step back up and repeat until you find what you want. If you can compare these between a critical and normal then great as you might have more info, if not then a combination of elimination and observation will usually see you figure out what most do.
The final change will depend what the instruction is or does. You might find a simple "was critical hit" value, or you might have to change it such that the instruction doing the luck check or whatever always returns a critical hit (the critical check might be a complicated calculation based on stats, enemy stats, a "random" value it got from somewhere and it will eventually spit out a number and do a yes/no compare, you just force this compare to always be critical and basically skip the results of all that).

Find the thing that finally subtracts from HP (so set a break on write to the HP value) and go backwards from there.


If you want to do this in one of the older pokemon games (and maybe now we have seen a few leaks there might be something there) then you can look at the disassemblies made for them and they will likely have figured this all out already (battle mechanics being of at least a tiny bit of marginal importance to people interested in pokemon, and the making of simulators for it). Find the parts dealing with battle and there will be the core loop of that.
Such things are not usually available to most people hacking games other than pokemon so best to know how to do things.

 

[Xylorapis]

Thank you very much for your response and for your time. I hadn't approached this problem at all the way you did. I had gone on the principle of equal to / not equal to but my research was interminable ^^. I didn't have to think at all about your idea of starting from the cause to find the effect. And don't worry, I know quite a bit about the basics of assembler and how breakpoints work, etc...
I'll try your idea as soon as I can.
Oh and I had another question, (excuse me but I'm very curious ^^). When you modify a function in assembler like the HP. For example, if I change the function that removes HP, so SUB R0, R1, R0 to NOP. I won't lose any more HP but my opponent will too (which is totally logical, the creators of a video game don't make create hundreds of functions with the same utility). Do you know how to fix this? ^^

 

[FAST6191]

Did not expect that to go for HP here, though as mentioned it is not out of the realms of reason either (code reuse and all that).

Simplest way would probably be to tack an instruction on that sets the HP to full every turn much like the cheat engines will do (or DSATM if you would rather not go manual). Main downside with that is something could still possibly one shot you -- I will probably have to make a more modern example but I usually used goldeneye, basic infinite health cheat worked fine with basic bullets but catch a rocket to the face and as the damage = full calculation happened before the next vblank or whatever when the health got topped back up you might still die, the in game cheat however did whatever it did and did not suffer such problems.

Other than that you can add some IF ELSE/compare stuff to see if is your pokemon that is being bothered or the enemy.

 

[Xylorapis]

Did not expect that to go for HP here, though as mentioned it is not out of the realms of reason either (code reuse and all that).

Simplest way would probably be to tack an instruction on that sets the HP to full every turn much like the cheat engines will do (or DSATM if you would rather not go manual). Main downside with that is something could still possibly one shot you -- I will probably have to make a more modern example but I usually used goldeneye, basic infinite health cheat worked fine with basic bullets but catch a rocket to the face and as the damage = full calculation happened before the next vblank or whatever when the health got topped back up you might still die, the in game cheat however did whatever it did and did not suffer such problems.

Other than that you can add some IF ELSE/compare stuff to see if is your pokemon that is being bothered or the enemy.

Mhmm okay, i see, so your solution would be to use a branch and do :

if(!is_my_pokemon)
{
    hp -= damage;
}

But I don't know how to create this condition is_my_pokemon, how do I know if it's my pokemon? ^^`(and I tried the technique of losing hps but so far I can't find much ^^')

 

[FAST6191]

There will usually be some tell somewhere, or you can set a flag during player's move and unset it (though splashback and counter damage might trouble something).
Here I would probably look at the eventual destination of the HP as I imagine your 6 pokemon are going to be in a different location/range to the opponent's and the destination will be stuffed in one of the registers ahead of time or soon generated. Might have to fiddle with a mask/some Boolean fun to do the simple compare at the end but nothing drastic there.

 

[Xylorapis]

There will usually be some tell somewhere, or you can set a flag during player's move and unset it (though splashback and counter damage might trouble something).
Here I would probably look at the eventual destination of the HP as I imagine your 6 pokemon are going to be in a different location/range to the opponent's and the destination will be stuffed in one of the registers ahead of time or soon generated. Might have to fiddle with a mask/some Boolean fun to do the simple compare at the end but nothing drastic there.

Mm-hmm. Sounds a little complicated x)
I'll try to figure that out later. You'll have some links/documentations like above to guide me on this task, manipulate the flags, learn how to do more advanced cheat, etc... it will help me a lot thanks ^^

 

[FAST6191]

If you have the concept of loops in general and the idea of comparisons on lock this is nothing extra. You will probably not even run up against timing issues or quirks of the hardware when it comes to data formats. Most of that is also find specs for system http://problemkaputt.de/gbatek.htm and maybe a programming overview http://www.coranac.com/tonc/text/asm.htm ... and go from there, maybe learn a few basics that you are likely to be able to use in most instances ( http://adshomebrewersdiary.blogspot.com/2012/02/unequivocal-answer.html ) to do basic manipulations and you are good.

I should also have noted the tell does not have to be at all related to what you care about, just has to be there at the same time. That also applies when finding other things -- if I wanted to say find a hit animation or audio clip I might note that HP is going to go down and work backwards from there (or forwards from selecting attack) as somewhere in the long line of triggered events will be the animations or audio sting.

Flags in this sense is the programming one rather than anything the CPU might have. Find an area of memory you can use (if you happen to have a free register on the CPU then even better) and set it high, set it low after all is done/at a suitable point.

Advanced cheats tend to mean you step up from basic infinite whatever that you have 1000 of and can decrement by 1 until you narrow down the list. This can mean you encounter anti cheat (mirrors, encryption, rotating locations, obfuscation, false mirrors and so on) or decide to do fun things like moon jump (usually done in games with double jump where you set the "has double jumped" flag to not done, or if the game has gravity/jump stat then set it ridiculous if the baseline is low), walk through walls (same idea really if there is an item to disable collisions, basic level editing might also be possible and in game level editors are also fun things to play with), no enemies (usually find a potion/equip/cutscene that disables them and replicate that as a cheat), play as boss/NPC/whatever (if the game has a selection screen or maybe a sequence with a different character start going outside what the standard menu options provide but first learn what they are and where they are), rare items (inventory is usually either a list of possibilities and how many they have though the possibilities are all in the game so it is basically a long list, or a value and how many they have. Find a common as dirt item's location and then you either fiddle with values to find out -- 1 might be rusty iron dagger, 2 might be steel sword, 3 is maybe mithril or whatever fancy sword 4 might be rare end game sword, or if location 0 is iron dagger, 1 is steel sword, 2....) and then start implementing minor tweaks to the binary (the DS loads the ARM9 binary into memory so a cheat can manipulate that, earlier systems have various takes on the game genie which can subvert ROM reads rather than messing with RAM).
At this point you are more learning how games work ( https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true ) and how you might twiddle some RAM (most games operate within RAM) or an instruction somewhere along the line to do something fun and not immediately apparent.

http://bsfree.org/hack/ (the main enhacklopedia link I normally have is down right now but that is one of the mirrors).

Elimination is also a fun one. Sadly nothing really like it for the GBA or DS right now unless you manually note things (a possibility/viable option for a lot of things) but the NES with FCEUX and a few other systems have elimination logging. Here you will let the game run and do everything but what you want to look at (say jump in this example), you say after this what is new and jump and as it will presumably have seen timers, the button check routine, music, idle animations, graphical updates, menu and all the rest before then it will say hold on this was a new thing called and you look at that.

Think about what savestates actually do as well. Normally we tell people to be careful using them in hacking as you might not know when something is loaded (edit a font and the game might keep it there from seconds after boot until the end of the game, you load a savestate and your font changes probably won't be reflected, ditto for text and graphics), though cheats can be more fun here and what I use to hunt down flags or things that are either on or off or maybe make things quicker (far quicker to load a savestate than reset the game, finish a battle or the like, and probably a whole lot fewer changes to memory as well).
More generally this also feeds into controlling your circumstances in the game -- random pokemon battle is random, trainer battle is still a battle but probably a lot less random, also reliable to cause where it might take a while going back and forth in the grass normally. I mentioned elimination above, while you can find a place where enemies wander in if you don't have to and can hide in the corner where none spawn (or kill them all before searching) then might want to do that.
Regular saves can also be things to look at -- if the game has to save my pokemon between boots but the company is too cheap to buy in a chip to make a full memory dump then it will be something written to it, and might well be in the same pattern as memory.

I already mentioned using cheats to find cheats -- if you need 30 minutes in a battle to search where they are normally over in seconds then give things infinite health, make your characters do no damage, prevent other things. If you need to get to the end of the game (and don't want to grind or level jump) then invincibility and stats... If you need to buy 100 potions but money is tight then first make infinite money. Obvious when you think about it but not everybody will go there right away. Equally not everybody wants infinite stuff but a reviewer, faq writer or similar might want something more complete to look at and if you can give them one of everything, or set monsters such that they have seen them (smea/smealum on the 3ds when he had the only hacked one did some here to reveal the legendaries that were otherwise unknown at the time).

Basically most of it is a protracted game of either "If I was the coder how would I have done this? Let's test it out" or "this will cause a change in this so if I work backwards or step on from there I will find what I want, find that first thing and then nose to grindstone", and in both cases attempting to dodge things that might make that harder (you already met reused code, most probably meet it first when they try to stop a timer and find all sorts of fallout*). Working in assembly compared to C or even higher level can be tedious, and sometimes it takes a little while for "actually you can do real work in this" to click ( https://stuff.pypt.lt/ggt80x86a/asm1.htm is for X86 but has some nice chapters where they build to practical results) and possibly a bit longer still until you can skim things and dismiss what is basic number fiddling** and what might be what you want. For instance here if we are still looking for critical hit then that is basically a coin flip/randomness test which looks rather different to a simple summation/multiplication/maths exercise if final damage is base damage + attack, not to mention if you know what some of the variables are (or have an idea -- set the luck stat to 1 and then to 255 and then to something else you might know... anything that follows those pattern of changes is presumably the luck part of the equation).
Not every game will have every style of cheat available (or at least not without a lot of hacking) so a lot of it is also what can be done with what the basic game provides me.
Or maybe in general people want games to be harder, to be easier, to be more random, to be less random (or even very specific), to be quicker, to be slower, to enjoy a core loop for a longer period than the devs provided, maybe to eliminate an annoying factor. Your job as fancy cheat maker is then to figure out what the dev provided, the engine can be twisted to do or that you can possibly crowbar in there (maybe a nice shift to give a 2x,4x or whatever exp/gold bonus in a battle, assuming the game itself does not have something like that for a job well done (think no damage taken) and you can just trip a flag) to effect such a thing, or close enough (there might still be one shot attacks, or I might daydream and forget to refill my health but for 99% of purposes press combo to refill health is invincibility and a partial solution is better than no solution for most).
You can help this by learning some of how to code but games are often fairly simple affairs at their heart so if you made it to about the point most people quit learning coding but have a general overview of tables/arrays, data formats and how a program might flow then you can do most of cheating quite happily and pick the rest up along the way. Sometimes people will be in a hurry to find things which can frustrate them -- I will rarely start out with decreasing on increasing value searches as much as "has something changed searches", and almost never specific values other than maybe one or two attempts just to see if it is going to be that, which is basically I can always do another round of searching but if I have to start over from scratch then that is no fun at all.

*this is one reason people might go for activator or fill up cheats rather than simple hold this value as this. Can also have bonuses if you mainly want say invincibility (or at least a health refill) to get past a section rather where simple infinite health is boring. The other being a hold might break the game if the same area is used in an unusual part of the game (and booting up is often an unusual part of the game).

**the ARM9 does not have a full 32bit immediate, though some assemblers might cheat and give you it as a pseudo instruction. To that end if you wanted to fill a register with all 1s then actually you would use movn 0 (move negate or basically invert what the immediate is) but for something a bit more exotic you would first do say 16 bits, then shift it all along, then add the next 16 bits to the result of the shift (which remember is a multiplication) and bam. At the same time a dev might have known that so might have given the normal game max value at something lower (it is never going to go higher than what they set after all) and thus you have some overhead for say text speed, jump height or something similar.

 

[PrayashLand]

Is there a program that can actually unpack LZ77 or L77 filetypes? I decompressed an L77 file but I didn't actually get it's contents. I looked at the file in crystaltile and the hex string specifies that there's 19 images in there but I can't seem to find a way to actually access them