-
Notifications
You must be signed in to change notification settings - Fork 0
Finding your first cheat
The whole loop, end to end: hunt an address in a running game with default.3gx, prove it's
the right one, then turn it into a real cheat in your own plugin.
No prior knowledge assumed. If you can install a file on an SD card, you can do this.
What you need: a 3DS with Luma3DS and the plugin loader enabled, a game with a number you can see on screen, and — for part 3 only — devkitARM to build.
Copy default.3gx to the root of the plugins folder:
sd:/luma/plugins/default.3gx
Not in a game folder. That is the whole install: it now loads into every title that doesn't have a plugin of its own.
Start with a number the game shows you and that you can change on demand. Coins, rupees, lives, ammo, a lap timer. Health is fine if you can reliably take damage.
Avoid, for your first attempt: anything that changes constantly on its own (a running clock), anything with decimals, and anything you can only change once.
Launch the game, press SELECT, open Cheat Search. The bottom screen is the form, the top screen is the results.
Set the form (tap a field, or use the buttons in the footer):
| Field | Set it to | Why |
|---|---|---|
| Memory Region | All Memory |
Narrow it later only if a scan is slow. |
| Search Type | Known Value |
You can see the number. |
| Value Type | 4 Bytes (32-bit) |
Start here; see the note below. |
| Scan Type | Equal To |
|
| Value | the number on screen |
Press R (or tap Search). You will get thousands of results. That is expected and not a problem — you are about to throw almost all of them away.
This is the part people miss. You do not stare at the list. You go back into the game.
- Press SELECT to return to the game. Your results are kept.
- Change the value. Spend a coin, take a hit, fire a shot.
- Press SELECT again — it drops you straight back into Cheat Search, exactly where you left off. You don't navigate back to it.
- Set Value to the new number, keep
Equal To, press R.
That jump-back is deliberate, and it is what makes this loop bearable. The flip side: as long as a tool is the last thing you were in, SELECT keeps taking you there instead of to the menu. To leave the tool for good, press B — that returns you to the menu, and SELECT goes back to meaning "the menu" again.
Each round cuts the list hard. Repeat until you have a handful of addresses — often three or four rounds is enough.
If you don't want to type the number each time, use the scan types instead: change the value in
game, then scan Increased, Decreased or Changed. Y cycles the scan type. This
is also how you search for something with no visible number (see Unknown Search below).
Pressed the wrong thing? L undoes the last scan.
Move the cursor to a result and press A. Type a new value and confirm — the keypad takes touch input, and the DEC/HEX button switches base.
Look at the game. If the number on screen changed to what you typed, that address is the one. If nothing happened, try the next result.
That test matters: several addresses often hold the same number, and only one of them is the one the game actually reads.
About Value Type.
4 Bytesfinds most things. If a value refuses to show up, it may be stored narrower — try2 Bytes, then1 Byte. A counter that caps at 255 is a strong hint it's a single byte; one that caps at 99 or 999 is probably 2 bytes. X cycles the width, but you must Reset before changing it — the width is fixed once a search starts.
Unknown Search. No number on screen — a hidden timer, a stamina bar with no digits? Set Search Type to
Unknown Searchand press Search to take a snapshot. Then change the thing in game and scanIncreased/Decreased/Changed. Same loop, no typing.
Note the address from the results list. That hex number is what you came for.
Two tools help you look around it:
- Hex Editor — press Y for from-search to jump straight to the address you found. Neighbouring values are often related: max health next to current health, a bag size next to its contents.
-
RAM Dumper — Y also pulls the search address in. Dump a block around it to a
.binand study it on your PC.
Before you build anything, understand the shape of what you have.
Addresses are region-specific. An address found on the EUR release will not be the same on USA or JPN. Note which region you used. This is the single most common reason a "working" cheat does nothing for someone else.
Some addresses move, some don't. Reboot the game and check your address again with the Hex Editor:
- Still correct → it's a fixed address. A direct write works. Easiest case, and where you should start.
- Now wrong → the value lives inside a structure the game allocates fresh each time. You need a base pointer plus offset: find the pointer that leads to it and read that first. That's a harder hunt — leave it for later.
Test what happens when you write it. Some values are read once and cached; others are validated and reset; a few will crash the game if they go out of range. Poke a few different values from Cheat Search before committing to a cheat.
Now switch to the template. Clone the repo — everything below happens inside
Sources/plugin/, and you
never need to open the engine.
Each step names its file. There are only four:
| Step | File |
|---|---|
| 1 · your game's folder | identity.inc.c |
| 2 · the cheat's id | cheat_ids.inc.c |
| 3 · the write · 5 · toggle or not · 6 · cleanup | cheats.inc.c |
| 4 · the menu row | menu_tables.inc.c |
In Sources/plugin/identity.inc.c:
#define PLUGIN_DIR "/luma/plugins/0004000000033500/" // your game's Title IDRosalina's Process list shows the Title ID of the running game.
In Sources/plugin/cheat_ids.inc.c, in the enum next to the CH_EX_* examples:
CH_MAX_COINS,The rest is Sources/plugin/cheats.inc.c. For a value you want pinned continuously, add it to
ApplyCheats() — that runs every frame while the menu is closed:
if (cheatState[CH_MAX_COINS])
W32(0x0ABCDEF0, 999); // the address you foundUse W8 / W16 / W32 to match the width you searched with. Writing wider than the game
stores will clobber whatever sits next door.
For a one-time effect ("give me the item"), use OneShot() instead — it fires once when you
press A on the row:
case CH_MAX_COINS:
W32(0x0ABCDEF0, 999);
return 1;For a base+offset value:
u32 base = R32(0x0BASE_PTR);
if (base) W32(base + 0x40, 999); // ALWAYS null-check the baseIn Sources/plugin/menu_tables.inc.c, inside whichever folder should hold it:
IT_CHEAT("Max coins", CH_MAX_COINS, "Pins your coin count at 999."),The description is what the info box shows on X.
IsToggleCheat() — same file, just below ApplyCheats() — decides whether the row draws a
checkbox or a plain action box. Continuous cheats go in the list; one-shots do not.
case CH_MAX_COINS:
return 1;Remove the CH_EX_* entries (in cheat_ids.inc.c) and their menu rows (in
menu_tables.inc.c) once yours works. EXAMPLE_ENABLED can stay at 0 forever — it only ever
guarded the placeholder addresses, and your cheat doesn't go through it.
makeBuild from a path with no spaces — the devkitPro toolchain breaks on them — and use the devkitPro msys2 shell, not git-bash. Then:
sd:/luma/plugins/<TitleID>/YourPlugin.3gx
One .3gx per folder. Bump PLUGIN_VER_PATCH in identity.inc.c every build and check the
version on screen — that is your proof the file on the card is the one you just compiled, and
not a stale copy the SD card write silently skipped.
The plugin doesn't load at all. Plugin loader off in Rosalina, or the Title ID folder is
wrong, or two .3gx files are in the same folder.
The menu opens but the cheat does nothing. Nine times out of ten the address is right but
the write is wrong: check the width (W8/W16/W32), and check IsToggleCheat — if the row
shows a plain box instead of a checkbox, the engine treats it as a one-shot and ApplyCheats
never runs it.
It worked, then stopped after a reboot. The address moves. See Part 2 — you need a base pointer.
It works for you and not for someone else. Different region. Addresses are per-region.
The game hangs or crashes. Before debugging the plugin, delete the .3gx and try to
reproduce it. A plugin runs inside the game's process, which makes it the obvious suspect even
when it is innocent — that test costs thirty seconds and settles it.
The top screen freezes on the plugin when you leave it — bottom screen returns to the game,
audio keeps playing, but the top stays stuck on the last menu frame, and reopening just draws
another menu over it. That is a fixed engine bug: the overlay flipped the LCD's
buffer-select register and never handed it back. Update to v1.1.4 or later, which also fixes
three other engine bugs from the same sweep — button waits that could hang the console with the
game paused, a translation file long enough to overflow a stack buffer, and a footer that drew
{D-Pad} as literal text.
If you are building on an older fork of this engine, all four are still in your code. Quickest
check for this one: a lone write to LCD_TOP + LCD_SELECT inside Present() with nothing
restoring it. Easiest way to reproduce: star a tool as a quick-menu favourite and launch it from
there — if your favourites are all cheats you will never hit it, which is why it can sit unnoticed
for a long time.
CORRECOES-MOTOR.md in the
repo has all four, each with the patch and a way to confirm it applies to your fork before you
touch anything.
- The README has the full engine reference: every hardware address, the rendering model, the pause mechanism, and the complete "make it yours" checklist.
- Section 3 of the README covers save-diffing — mapping packed bitfields (which songs you know, which collectibles are taken) by diffing progressive save files. That is how you find things Cheat Search struggles with.
- Credit people whose address maps or research you build on. There is an About screen and a guide Credits page waiting for exactly that.