ROM Hack Tutorial  Updated

GBATemp ROM hacking documentation project (new 2016 edition out)

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/
 
Last edited by FAST6191,
  • Like
Reactions: Vanessa__, Aen9ine, _StelioKontos_ and 26 others
Click to expand...
luke_c

luke_c

Big Boss
Member
Level 6
Joined
Jun 16, 2008
Messages
3,587
Trophies
0
Age
29
Location
Land of England
Website
gbatemp.net
XP
915
Country
Great guide FAST, helped me a bunch
biggrin.gif
just wondering, is it absolute neccesary to learn C#/C++ for this, i'm already filled up to my head in coursework ._.
 
psycoblaster

psycoblaster

Divine
Member
Level 2
Joined
Jan 26, 2008
Messages
2,131
Trophies
0
Age
33
Location
Seoul.. (in Korea)
Website
Visit site
XP
211
Country
cool casey10 said:
Great guide FAST, helped me a bunch
biggrin.gif
just wondering, is it absolute neccesary to learn C#/C++ for this, i'm already filled up to my head in coursework ._.
Click to expand...
The reason why programming helps is because it helps you do repetitive work, and it just makes the whole task easier.
Manually increasing the file size, editing pointers, rewriting control codes etc can be a pain. With programming, you can make this whole work easier by making it as simple as editing a text file.
 
Sp33der

Sp33der

Well-Known Member
Member
Level 1
Joined
May 31, 2008
Messages
435
Trophies
0
XP
78
Country
Netherlands
psycoblaster said:
cool casey10 said:
Great guide FAST, helped me a bunch
biggrin.gif
just wondering, is it absolute neccesary to learn C#/C++ for this, i'm already filled up to my head in coursework ._.
The reason why programming helps is because it helps you do repetitive work, and it just makes the whole task easier.
Manually increasing the file size, editing pointers, rewriting control codes etc can be a pain. With programming, you can make this whole work easier by making it as simple as editing a text file.


So...when you didn't know C#,what did you use as replacements?

Care to tell me more about this line of code:

QUOTE
Click to expand...
List textDump = new List();
Click to expand...

Not really good with C# syntax, so what's textDump?
 
psycoblaster

psycoblaster

Divine
Member
Level 2
Joined
Jan 26, 2008
Messages
2,131
Trophies
0
Age
33
Location
Seoul.. (in Korea)
Website
Visit site
XP
211
Country
before I knew C#, I made Darth make programs for me ;D
jk
well I had to do everything in a hex editor, manually writing down every new pointer for each line.
Why not just spend that time learning how to make a program that calculates everything for you?
List textDump = new List();
In C# library, there is a Generic List class. http://msdn.microsoft.com/en-us/library/6sh2ey19.aspx
For more info about the < > (Generic programming), look at http://en.wikipedia.org/wiki/Generic_programming
After a variable type, a name is given to it.
So basically, what this line of code do is creates a new List which can only contain strings (So no need to cast objects), and the name of this List is textDump.
new List();
This part of code means you will create it as a new List of strings with no parameters.

I'll tell you though, that the easiest way of learning how to program is to just learn the basics, and then look at source codes of different programs.
(That's how I learned)
I started out with JAVA, just learning the basics. Then I took a look at Darth's codes, and just learned from there. (The internet is also a good reference when you are looking for specific classes that can do what you need)
 
FAST6191

FAST6191

Techromancer
OP
Editorial Team
Level 33
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,321
Country
United Kingdom
My thoughts.
As mentioned much of hacking once you get past the reverse engineering is long winded and tedious if you go it by hand. Fortunately computers are designed for long winded repetitive tasks (actually they are good at little else which many people and coders seem to forget).

Fortunately we have file types which means they are at some level predictable. This however is where things get interesting. Rom hacking has changed somewhat with the rise of DS hacking; snes era hackers would work in small, fairly quiet and very tight teams where DS teams are often 10 people or more and will be fairly open and people will often come and go as they are needed.
Also seen as we are now dealing with file types on what amounts to fairly complex files (snes, GBA and the like would have code fairly similar to the hardware: see GBA pointers generally being 08XXXXXX) which are often game specific and with teams including people of less technical skill things also changed things also change.

If you look at hacking documents aimed at the likes of the snes they will often focus around getting premade tools (table files, text extraction tools, tile editors and so on) to work with games whereas on the DS can afford to or needs to do things differently. This also marks a shift in ideas as now rather than a simple tool you can tweak to a rom you need to make your own (even if you have a tool configuring it will likely be analogous to programming something yourself).

This is where programming comes in:
For a lot of my internal hacks or stuff I play around with myself I will tend to use a hex editor and a spreadsheet: you can set the width of columns and the amount of bytes they contain in a hex editor* (making a crude form of matrix) and then import these into a spreadsheet.
Alongside this various hex editors (I am still using hex workshop for day to day stuff) feature nice search abilities which means you can search for offsets or given strings that give things away (text will often end a line with something and you can grab these and add one to get the pointer location for example).
Spreadsheets feature some serious hex manipulation tools (open office includes them as standard, MS office you may need to install the "analysis toolpack" although I have not used some of the newest versions at length so I am not sure about them) which can be good to work out file formats: it is fairly easy to take the previous cell from the current one or do fun things like that which is great for reverse engineering.

*it might involve pasting into a text file first and you may also wish to know that 0d0a is the main method to start a new line in windows using ASCII (linux and mac tend to use either 0a or 0d although they will accept the windows method, windows standard notepad and wordpad will tend to ignore a single 0a or 0d which is why some files you download will not display properly in them).

As well as reverse engineering you can also do shifts quite easily and if you do a search again you can often get a list of new pointers. From here it is just a matter of pasting back into your file of choice.

However as I mentioned your team may not be so comfortable with this (the simple example is things like flags in the text to make it bold or something) and if you are doing something like narc files (bad example as there are many tools for this but I am sure you can see what I am aiming for) or doing something with the binary then it gets either tedious or complex meaning you probably have to make a program.
Now comes the debate as various languages have their strengths and weaknesses, generally from a hacking perspective what you want is
Binary manipulation: few hacks can get away with "standard" formats so this is a must.

"random" external file manipulation of any type: some languages are designed for a given format or even a given file (sql type languages spring to mind)

Graphical interface: if you are making a tool you may need to make it so people can manipulate things, of course if you are just making a tool to recalculate pointers you could make it command line quite easily.

The most common from a hacking perspective are
internal formats: things like hex workshop have the ability to define file types, most notable use would be Keshire's work on the Jump Ultimate Stars sprites.

plain C: An old language but a very good one, all the criteria are fulfilled.
C++: A tweak on plain C and was taught more often in the late 1990's and early 2000's which means most hackers you will meet who were around then will know it.
C#: A tweak on C type languages by Microsoft although nowadays it is an iso standard and with things like mono other operating systems can use it at some level too. While the above languages share many similarities things are easier to port and/or remake between C# type programs and as there is a framework a lot of the work has already been done for you. Considered by most to be a successor to visual basic (an older language from MS that some older tools are written in, not held in high regard these days).

All forms of C are similar enough that you can reasonably transition between them all (certainly a C programmer could, as C++ and C# feature more it can be harder to "go backwards"), resource issues aside (a well written c program can invariably beat C++ and c# in size, memory usage and probably speed; hence why it is used for most DS programs), I counsel against landing yourself with something like borland /turbo C++ (it might be easier in the beginning but it will cause headaches later).
Personally I am useless at any form of C coding (I know the basics but I never took it that far), I plan on rectifying this problem as C is the most commonly used language for computer coding (especially on the consoles) which is very useful to know when reverse engineering (many emulators (ab)use this fact).

python: deufeufeu did a lot of work with this and for quick and dirty scripts you can not really beat it. It fulfils all the criteria I mentioned above very well. Other languages that share a similar mindset like LISP, perl, lua and scheme are also worth a mention.

autoIT: not so good at binary manipulation (it works but the tools available are "ground up" only: you will have to shift, add and and perform logical operations to get it where you need it to be) but does make a nice frontend quicker than any other language I have ever used (good for a series of command line tools).

java: not so common in hacking circles for some reason as it does do what it needs to.

assembly: very little work on the PC side of things is done in assembly although with the rise of video and audio hacking this looks set to change a bit. Any assembly will probably be "inline assembly" (assembly code that sits inside a program and gets assembled when the rest gets compiled).
 
Sp33der

Sp33der

Well-Known Member
Member
Level 1
Joined
May 31, 2008
Messages
435
Trophies
0
XP
78
Country
Netherlands
Never heard of autoIT hahaha, soms like some varient of BASIC.

Now my main programming language is Python, now looking at psychoblaster's sample I'm guessing you open the file, reads it and put it in a list?

And should I just stick with Python or use C#, since most hackers I've seen actually use that language, and I guess I could learn faster looking at samples which are mostly made of C#.
 
Lockon Stratos

Lockon Stratos

Well-Known Member
Member
Level 2
Joined
Apr 1, 2008
Messages
262
Trophies
0
Age
27
Location
Sylvarant - Tales of Symphonia
Website
Visit site
XP
220
Country
I tried learning the basics of C# but then I can't find the tutorials and I've sort of learnt about some parts of C# but I don't understand how when you type in strings or any piece of C# code, how it would make something actually appear on the screen like making it work properly. That's one of my main problems.

PS - FAST can you make that download link another format aswell?
 
T

tom9927

Active Member
Newcomer
Level 1
Joined
May 21, 2009
Messages
35
Trophies
0
XP
17
Country
thamks guys alot of the links u linked me too help alot hmm interesting this is gona take some time to learn still reading alot of it

eidt so far im reading

http://www.romhacking.net/start/

alot of usefull stuff and sould be me homewotk for today D ill continue and hopefully when iv learned alot ill start a project up

projects i hope to do are

3535_Super_Robot_Taisen_K_JPN_NDS-XPA full english

reason is i have alot of free time on my hands so im going to learn and hopefully with my free time hack this rom to make it fully english




UPDATE ok guys iv been reading Hexadecimal(The Basics of Bases) i was learning thiat college so i know a little so thats no problem onto Hex Lesson

thansk to everyone who made the guides
yaypsp.gif


ill keep you guys updated stay tuned
yaypsp.gif








urgent help needed

i was reading hex editor and he says

I also suggest grabbing a copy of Castlevania , because it’s my favorite game and the one I use for this document

which castlvaniagame is he on about nes snes gba ds?
 
Ian10234

Ian10234

Active Member
Newcomer
Level 2
Joined
May 27, 2009
Messages
41
Trophies
0
Age
29
Location
In front of you
XP
166
Country
United States
I wasn't sure where to ask this so ill just ask it here. I unpacked a rom but i want to watch the cutscenes (and possibly edit them) Im pretty sure i found them but how do I open them? They're MODS files.
 
Nugg2396

Nugg2396

Well-Known Member
Member
Level 1
Joined
Jun 9, 2009
Messages
239
Trophies
0
XP
48
Country
Malaysia
Great job on the thread
smile.gif


and to Ian10234, My name is Ian, and my birthday is on October (10) 23rd!! Lol
 
T

TempusC

Well-Known Member
Member
Level 1
Joined
Nov 22, 2006
Messages
229
Trophies
0
Website
www.FatalFrame4.net
XP
91
Country
Canada
I use python. It’s easy to learn since the console lets you experiment quickly. It’s easy to use since it isn’t such a syntax stickler.

The struct module allows for easy unpacking and packing of files.

The string.encode/decode functions and the unicode module allow for conversion between SJIS and unicode (or *shudder* ascii).

It’s easy to test and to modify since it runs from scripts, so you can try each step out as you code them.

It works with tkinter, wxWidgets, and PyQt, which are easy to use cross platform interface builders (also available for C/C++).

It’s completely cross platform - as a Mac dev, I appreciate not having to run a VM or gimp the code for it to work on Windows.
 
FAST6191

FAST6191

Techromancer
OP
Editorial Team
Level 33
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,321
Country
United Kingdom
I made it for another thread and I am too lazy right now to reword it to a more general post but here is a quick how to on crystaltile2, I will see if I can work it into an earlier post as well.

<b>Introduction</b>
I know of no guides and while it is a very nice app 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 with some of the even basic search methods and you will soon eat memory faster than any memory leak you have ever seen. The more advanced ones 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 app so here we go:

<b>General usage/theory</b>
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 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 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). Good practice is to have the editor relevant to what you want open when doing things of that nature.
Each one is perhaps not as good as a more specific app 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 sub apps most are perfectly functional.
Where it really comes into play 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: <a href="http://tahaxan.arcnor.com/index.php?option=com_content&view=section&id=7&Itemid=36&lang=en" target="_blank">http://tahaxan.arcnor.com/index.php?option...=36&lang=en</a> )
This is load the data, order the data (tiles can be in an order in the rom) and apply a palette.
This leads to stuff like <a href="http://pix.gbatemp.net/32303/gundam2.JPG" target="_blank">http://pix.gbatemp.net/32303/gundam2.JPG</a>

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.

<b>Tile viewer</b>
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.


<b>Hex editor</b>
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.

<b>Disassembler</b>
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.

<b>Tile editor</b>
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).

<b>Script editor</b>
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: <a href="http://www.romhacking.net/utils/513/" target="_blank">http://www.romhacking.net/utils/513/</a> ) 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).
 
jjjewel

jjjewel

Well-Known Member
Member
Level 4
Joined
Dec 17, 2009
Messages
1,010
Trophies
0
XP
522
Country
United States
FAST6191 said:
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)

...

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.
Click to expand...

FAST6191, I'm just getting curious about NEF you mentioned in your article. Do you have any links that give more information about it? (I searched and only got Nikon Electronic Files and I don't think that's something related to rom hacking.
happy.gif
)

I totally have no idea about ASM hacking but that's something I think I should start to learn at some point.
 
FAST6191

FAST6191

Techromancer
OP
Editorial Team
Level 33
Joined
Nov 21, 2005
Messages
36,798
Trophies
3
XP
28,321
Country
United Kingdom
I do not have a great deal of info on them or even that much experience with it but I will give it a go:

NEF is a file format apparently used by Nintendo but supported in the developers version of no$gba (a far more interesting prospect for hackers) and later in the line of things crystaltile2, in practice is acts like an external comments system ("the commands at a given address do X" sort of thing) mixed with a debug info (breakpoints and whatnot).

The reason this sort of thing is interesting is because when you first disassemble a rom (the DS is quite nice as you have the filesystem- older consoles are not so lucky) you get several thousand lines of barely comprehensible instructions ( http://gbatemp.net/index.php?showtopic=39979&hl= is worth a scan through as it has a bit of info/provides a good example) and indeed owing to developers leaving/reading the game text/pictures/levels and the like from/in the binary and the fact the ARM processors in the DS having two differing instruction sets (ARM and THUMB: http://nocash.emubase.de/gbatek.htm#cpuoverview ) it may indeed be entirely useless (your basic disassembler is a very very crude tool- it is on a par with the ASCII readout of your hex editor in that any good it shows is luck, use of standards or you manually guiding/prodding it to show as such). Anything that cuts this down and makes it more manageable is welcomed, using the NEF files you can essentially comment "out" the things like setting the stack pointer, changing CPU modes and ultimately leave you looking at the juicy stuff like what instructions deal with your chosen interest for hacking or more broadly what deals with what. Similarly it can kind of cut down on the memory/register management side of things that most of ASM is concerned with and most high level languages seek to do away with)- I am loathe to use the word decompiler but they are in the same circles.

Hopefully I am allowed to paste it here but here is the relevant section from the no$gba debug help (note the passage on SRL- you normally see that format in roms as the file sent over wireless for download play):

QUOTE said:
If debug info (.SYM or .ELF files) has been loaded, labels will be displayed in disassembled code. And input boxes will recognize labels (eg. for Ctrl+G). TAB in code window toggles symbolic display on and off. Moving the code windows cursor onto a line with a symbol displays the value that hides behind the symbol in the upper left corner of the screen (DOS) or in the status bar (Windows).
Also, if source-level debug info is present, no$gba allows the user to view his/her source code in 'stacked' view mode, ie. disassembled opcodes shown below of each source line, this would be important for HLL programs.

.ELF Files (GBA)
Elf files are binaries, generated by many ARM assemblers and compilers (eg. Nintendo Tools, GNU tools). The files are containing the program (binary executable), and optionally also a symbol table & further debug information (usually in Dwarf2 format, and if present, typically containing source-level debug info).
Current no$gba version supports loading the binary (game), and the symbol table (similar content as .SYM files, but without additional code+data info), and the source-level debug information.

There seem to be different interpretations of how to store a binary inside of ELF files - as far as I know no$gba is compatible with all of these 'standards'.

.NEF/.SRL Files (NDS)
Nintendo's DS devkit outputs ROM-image and debug-info to separate files:

cart.SRL rom-image (without any debug info, same as normal .NDS files)
cart.NEF the NDS9 debug-info in ELF format (but without program code/data)
cart.NLF contains a path to another .NEF file with NDS7 debug-info

No$gba v2.2e supports NDS9 debug info, the NDS7 file isn't supported yet.

.SYM Files
When not using ELF files, symbolic Information may be stored in file .SYM in the same directory than .GBA. The A22i assembler produces ready-for-use SYM files. When using another assembler, you may convert any debug information into .SYM format.

.SYM Symbolic Information File Format:

;no$gba symbolic information table example
08000000 .arm
080000C0 start
08000124 mainloop
080001EC .thumb
080001EC init_video
08000210 .arm
08000210 irq_handler
08000228 jumplist
08000228 .dbl:0010
08000414 text_array
08000414 .asc:0017
0800042B .asc:000F
0800043A .asc:0012
06000000 vram_base
;...

All symbols have to be declared as EIGHT-character string nnnnnnnn (hexadecimal memory address, not case sensitive), followed by at least one space or TAB and then followed by the symbol name (the name may contain any characters except spaces and control codes, names are case-sensitive).

.SYM Additional Code and Data Information
Aside from labels, the file may also contain information about 16bit or 32bt program code areas, and about data zones. This info is stored in the same format as normal labels, but by using the following reserved "labels":

.arm ;following code is in 32bit/ARM format
.thumb ;following code is in 16bit/THUMB format
.byt:NNNN ;next NNNN bytes are 8bit data (dcb lines)
.wrd:NNNN ;next NNNN bytes are 16bit data (dcw lines)
.dbl:NNNN ;next NNNN bytes are 32bit data (dcd lines)
.asc:NNNN ;next NNNN bytes are ascii data (quoted dcb lines)
.pool ;dummy label (indicates that following is literal pool)

The entries may be mixed with normal label definitions, NNNN is a hexadecimal value, it is always counted in BYTES (even when defining 16/32 bit data fields).

There is no need to sort the entries in any way. Empty lines are allowed. Lines starting with ";" are ignored as comments. Lines are terminated by LF or CRLF or EOF or filesize. The file is terminated by EOF or filesize.
Click to expand...


I would argue it is not that relevant to the hacker new to ASM, you would probably be better served reading up on the likes of http://crackerscrap.com/index.php?p=docs http://gbatemp.net/index.php?showtopic=444...t=0&start=0 and http://www.romhacking.net/?category=&P...itle=&desc= (pretty much all of the documents there but the ones on VFW, compression and VBA-SDL are the big three)

desmume (now a proper dev version exists) is also good enough for some ASM work (it plays well with later roms too unlike no$gba).
 
Krobelus

Krobelus

Well-Known Member
Member
Level 2
Joined
Apr 9, 2009
Messages
164
Trophies
0
Age
33
Location
Vancouver
XP
192
Country
Canada
I have a question; I used thenewpoketext to create the tmp folder of Pokemon Platinum. Then after I closed thenewpoketext.

Now that I've finished using ppre I want to compile the tmp folder, but thenewpoketext wont compile it.

How could I compile my tmp_Pokemon Platinum folder?

Thanks
 
L

loco365

Well-Known Member
Member
Level 12
Joined
Sep 1, 2010
Messages
5,457
Trophies
0
XP
2,927
I dunno about reviving stickies here... But what is the catch on looping in a ds sseq? I have been trying to crack that for a while and haven't gotten too far.
 

Site & Scene News

Go to forum More news

Popular threads in this forum

Testing the new EZ-Flash Parallel

Hardware Review  EZ Flash Parallel Warning - Power Strobe When DS Shut

Best DS flash Cart?

ROM Hack  Mario Kart DS - Custom Tracks Grand Prix NITRO (CTGP NITRO) v1.1.0 Release

Do Nintendo DS Games Go To Sleep If Not Used For Years?

Metroid Prime Pinball slowdown and audio stutter on EZ-FLASH Parallel

EZ-Flash Parallel Question (Sav files and where to put them)

Emulation  What are the emulation capability of a DSi? (2024)

General chit-chat
Help Users
  • No one is chatting at the moment.
    Xdqwerty @ Xdqwerty: