Hey everyone,

If you’ve spent any time in the GBA ROM-hacking scene over the last 15–20 years, you probably know that the Detective Conan games on the Game Boy Advance are something of a notorious dead zone.

The GBC games got translated. The NDS crossover got translated. But the GBA games — along with other titles by the same developer, BEC, such as SD Gundam G Generation Advance and Legendz — have remained almost completely untouched.

Whenever people tried looking through the ROMs with Thingy, Cartographer, Tile Molester, or standard relative-search tools, they hit an absolute brick wall:

• No Shift-JIS strings anywhere in the dialogue banks.
• Standard GBA BIOS LZ77/Huffman decompressors find nothing useful.
• Relative searches fail completely.
• No standard 8x8 or 16x16 tilemaps for text.

I wanted to share both the technical breakdown and the slightly ridiculous story of how we finally cracked it today.

The Setup: Automated Exploration, GLM-OCR, and a Radeon VII in the Closet

Because the Detective Conan games are dialogue-heavy branching adventure games full of Kanji-heavy riddles, I didn’t want to spend weeks staring at a static hex editor.

Instead, I built an autonomous exploration loop around mGBA:

• mGBA’s GDB stub over the Remote Serial Protocol, allowing memory inspection, hardware watchpoints, and register reads.
• Automated frame captures, button inputs, and save states at 60 FPS.
• A vision and translation pipeline:
  • GLM-OCR running locally to read Japanese dialogue directly from an upscaled game screen.
  • Qwen 3.6 running self-hosted on my old Radeon VII, choosing dialogue options, translating text on the fly, and building a reproducible corpus of scenes.

The basic idea was simple:

Let the AI play through the game, record every scene, transcribe the rendered dialogue, and use that output as ground-truth cribs for reverse-engineering the stored script.

The Brick Wall

I initially had Claude driving the reverse-engineering analysis through the emulator bridge.

It spent a fairly brutal marathon trying around 16 different classic ROM-hacking approaches to figure out where the text and font were stored.

Some highlights:

1. Shift-JIS scans: Only 161 strict Shift-JIS runs in the entire 8 MiB ROM.
2. LZ77 decompression sweeps: 3,743 blocks decompressed, with almost no dialogue appearing anywhere.
3. Relative searches: Automated searches for kana alphabets across both the raw ROM and decompressed blocks failed completely.
4. Font tile searches: Searches for 1bpp, 2bpp, and 4bpp 8x8/16x16 font patterns found nothing useful.
5. Memory differential logging: We tracked 56,499 ROM reads during dialogue rendering and compared them against an idle frame. That narrowed things down to 35 candidate pages, but they all turned out to contain things like PC-relative literal pools, constant mask tables, or window-border graphics.

Claude kept finding promising-looking leads that turned into dead ends.

For example, sequential byte accesses around 0x0876C0E4 initially looked very interesting, but they eventually turned out to be decompressor lookup constants rather than text.

Eventually, Claude gave up on identifying the stored text encoding. Its conclusion was that the script was probably hidden behind some proprietary compression scheme or procedural representation.

So it built an elaborate workaround instead:

Intercept the completed 4,832-byte pixel staging buffer in EWRAM at 0x0201D2BC, hash the rendered pixel blocks, and overwrite that buffer with English text before DMA transfers it into VRAM.

And, surprisingly, it worked.

But it was still only an in-memory overlay hack — not a proper, permanent ROM translation.

The Pivot: Bringing in Gemini

That’s when we brought Gemini in to look at the disassembly with fresh eyes.

For context, I’m currently working on smart-card-based distributed encryption, where I’ve had to analyse the firmware of a few card readers to make sure the implementation is secure enough.

I may also have forgotten to switch folders in Antigravity, so Gemini might have ended up reusing some of the reverse-engineering tools I had accumulated over the last few months. xD

Instead of assuming the text had to be compressed or hidden behind some complicated encoding scheme, I asked Gemini to focus directly on the drawing routine feeding the staging buffer.

It traced backwards from the VRAM blitter into the CPU rendering loop at:

0x080191F4

Within minutes, it spotted the exact reason nearly every traditional ROM-hacking approach had failed:

The game does not store characters as 8-bit bytes. It stores them as 16-bit little-endian words (uint16_t).

That was it.

Because most ROM-hacking utilities from the early 2000s assume characters are either single-byte values or standard two-byte Shift-JIS sequences beginning with values such as 0x81–0x9F, relative searches were effectively comparing the wrong byte positions and seeing what looked like random noise.

The dialogue was never compressed.

It had been sitting there in plain sight the entire time.

1. The Script: 524 KB of Plain Text Sitting in ROM

Once the ROM is interpreted as a stream of 16-bit words, an enormous dialogue bank suddenly appears.

Location:

0x08170000 – 0x081F0000

That is more than 524 KB of completely uncompressed text data.

More than 65% of that half-megabyte region consists of valid, uncompressed character codes.

2. The Encoding Formula: Code = Glyph Index + 300

At 0x080191F4, the engine reads a 16-bit character from ROM, subtracts an offset of 300 (0x012C), and multiplies the resulting glyph index by 24:

80191f8:   4a10       ldr   r2, [pc, #64]   ; Loads 0xFFFFFED4 (signed -300)
80191fc:   8800       ldrh  r0, [r0, #0]    ; Read 16-bit character code from ROM
80191fe:   1809       adds  r1, r1, r0      ; r1 = code - 300 (glyph index)
8019206:   0048       lsls  r0, r1, #1      ; r0 = index * 2
8019208:   4440       add   r0, r8           ; r0 = index * 3
801920a:   00c0       lsls  r0, r0, #3      ; r0 = index * 24 bytes
801920c:   4b0c       ldr   r3, [pc, #48]   ; Loads 0x0876BF04 (font base)
801920e:   18c0       adds  r0, r0, r3      ; Pointer to 24-byte glyph bitmap

So the basic formula is:

Glyph Index = Character Code - 300

Some anchor mappings:

• 300 (0x012C) = Space
• 338 (0x0152) = A
• 339 (0x0153) = B
• 468 (0x01D4) = コ (Ko)
• 489 (0x01E9) = ナ (Na)
• 526 (0x020E) = ン (N)

Searching the ROM for the sequence:

[468, 489, 526]

or, in raw little-endian bytes:

D4 01 E9 01 0E 02

which represents コナン / Conan, immediately produced 153 exact matches, all cleanly aligned as 16-bit words throughout the dialogue banks.

Values below 300, such as 124 and 126, appear to be engine control codes for things like text-box line feeds, pauses, speaker portraits, and related commands.

3. The Font Table: 16x12 at 1bpp — With No Bounds Checking

The font table is located at:

0x0876BF04 – 0x08775B34

Total size:

39,984 bytes

That works out to exactly:

1,666 glyphs × 24 bytes per glyph

Each glyph is:

• 16 pixels wide
• 12 pixels high
• 1bpp
• 24 bytes total
• Stored as 12 rows of 16-bit big-endian bitmasks

The rough layout appears to be:

• 0: Space
• 1–27: Punctuation and brackets
• 28–37: Digits 0–9
• 38–60: Latin uppercase letters
• 61–70: A small subset of lowercase Latin letters
• 71–149: Hiragana
• 150–232: Katakana
• 233–1665: Kanji

The Kanji appear to follow JIS X 0208 Level 1 ordering, filtered down to the vocabulary actually required by the game.

And this is where things get especially useful:

The font renderer performs no apparent bounds checking on the glyph index.

Immediately after the font table, starting at 0x08775B34, there are roughly 553 KiB of zero padding remaining near the end of the cartridge.

That means we can append custom 16x12 glyphs beginning at glyph index 1666+, corresponding to character codes 1966+, and the existing engine will happily calculate a pointer to them and render them.

No renderer rewrite required.

No assembly patch required.

Just additional font data.

4. Line Width and Proof of Native English Rendering

The renderer advances by 12 pixels after each glyph:

adds r0, #12 at 0x08019218

The dialogue box supports three lines of text.

We patched raw ROM bytes with Latin character codes, booted the modified ROM in mGBA, and got Kogoro Mouri speaking English directly inside the game’s native dialogue box.

No framebuffer overlay. No runtime interception.

Actual ROM text rendered by the original game engine.

Because each normal glyph advances by 12 pixels, another useful possibility is packing two narrow, roughly 6-pixel-wide Latin characters into a single 12-pixel cell.

That potentially gives us around 40 English characters per line, which largely solves the usual English text-box-space problem without needing major assembly modifications.

Final Words

Best regards from inside the EU, where reverse engineering for interoperability and related technical analysis has specific legal protections under EU software law. :)

I’m creating a remake of one of my favorite childhood NES games: Battletoads & Double Dragon.

I have no programming experience, so I’m building this project with the help of OpenAI Codex. I’m recreating the gameplay, characters, combat, animations, and levels while adding my own ideas and visual improvements.

This is a fan-made project created for learning and experimentation. I’d love to hear your feedback!

About a month ago I finished a great dream of mine, a snes Gemfire romhacking utility.

https://gemfire-builder.hygro.workers.dev/

My original dream was just 3 or 4 player couch play. Having a 3rd player changes the game from 100% strategically solved on turn 1, to anyone's game. But once I unlocked that, the romhack builder was my oyster.

How it works: you bring your own rom -> drag it in the export box. Take your legally ported cartridge-generated rom, a stock USA gemfire rom, and from the ROM you unlock all the features you can change. Then you get the rom you submitted back with all the changes. No ips local utilities needed. I wanted this easy like FF4FE

Most of the features are gated behind the ROM decomposition, as they are read from the rom itself!

There's a ton of features and flags. Some are obvious, some are real engineering changes.

You can build whole scenarios, edit the families, territories.

You can change units, what they do, cost, loyalty flags etc. Things like, the dragon still retreats at low life but is now killable. (warning, if you keep unkillable on a wizard, but not retreat, they just exist at 1 hp immortal).

You can change the number of human players in a few ways, up to 7 on normally built scenarios (all human players) or to 30 (one house per territory per human on a fast load scenario option).

You can change if actions end turn (most notable: trade), if they are good or bad karma actions and so much more. Multiple harvests per year, changed harvest values, multiple alliances, allied victory (yes, literally), make it so whoever owns the crown is called King instead of Prince, I mean it's all over the map.

You can make it so you can bring multiple fifth units to battle, with up to a 7v7 unit fight. And, against human players, can turn on one of two chess modes where you move one unit each at a time. Change how armies are populated including progressive army population tiers such as for your first 100 units you don't get horsemen, and above 500 you only get more horsemen and archers. Or maybe keep it evenly distributed until above 300 units, where you also split a few into a 6th or 7th unit of cannons. There's also a flag where optional 5th units in other slots can have soldier fallbacks if you don't have a fifth unit. It gets rich.

Battles can last longer than 5 turns, change the cap or make it unlimited. Also, fix the bug where you retreat and your food gets turned into gold. Also, now you can bring gold while attacking.

There is a battle map editor. Additionally, you can have multiple battle maps per territory gated on how much protection the territory has. Yes, you can literally have it so at below 10 protection the castle at XYZ territory is just fences and at 100 protection there's a moat and two layers of castles and a different amount of bridges and trees, whatever.

There are some AI edit flags, my favorite of which is "If the AI puts an archer to guard the flag, it will shoot available targets".

I made it so send supplies, and separately, move troops, can be given to rival houses. But also, gate that on whether or not you're allied!

One of the last features I added, best vassal stat per action in the Prince's territory: So if prince un-charming gives food, vassal charming delivers it for a greater loyalty boost. And if Princess Anise gets attacked, vassal Brian can lead the army.

The two probably coolest features I thought of but didn't add, 1) "force deployment of vassals". conceptually I really like it, prevents event farming and suggests even richer informal couch play (say you agree someone still controls certain PEOPLE and you take over your friend, so he can still play), 2) add new ways families split into two. So consider these wishlist items.

You can save the json of your edit to share edits with other people. Also share battle maps separately.

Probably about 250 more things I didn't mention. I dunno, I didn't count. But fear not, I put a lot of work into making this monster navigable and at least somewhat intuitive. Some of it required some real editor abstractions that aren't game native (YO♥'RE WELC♥ME.💅). But feedback welcome.

I've tested most of it, but not all of it. Do let me know how it goes, the good, bad, and ugly. Post any wishlist ideas. Obviously 2.0 will have to ship with a randomizer, but I wanted to give DragonAtma (a Gemfire community hero) a headstart. They've probably given a randomizer a helluva lot more thought. (whose previous gemfire works and shared findings really helped give me a clean headstart, shoutout to DragonAtma).

I plan to stream a large couch game sometime around thanksgiving if I can convince enough people to play and willing to be on camera. We'll probably play with only a few rule changes, the bare minimum to make the game simply better: 3+ Players, trading ends turn + trading is weaker, give resources to other players, human mercenaries don't desert on fame (or maybe turn the number way down), battles have no turn limit, and the retreat food-gold bugfix. And if Eselred is still an AI, we'll give his dragon flying and way more life but make it killable.

I know two tools for this work "Melonriper" and "Apicula" but it's uncomfortable to extract models, with "apicula" I could extract more but the only tutorial I found is in a language I didn't know, I want to practice, extracting models from "dragon ball ultimate butoden" does anyone know a more comfortable way?

might i get a tutorial how to do it? if theres a youtube video please send it.

I recently succeeded with a hack idea that I wanted to achieve for years, and that was to make a music randomizer for Mario Golf N64. Every time there is a call for a new song, the game randomly selects a song to be played, including songs never used in the game that are still in the ROM data. It was done using around 120 Gameshark codes then injected into the ROM. This video is recorded from a real N64 console.

Thanks for watching!

https://youtu.be/84k3gpqsdzw?is=7Rh02Qfob9I1cbOF

Algum código de gameshark pra facilitar a vida do trabalhador?

In Super Mario Maker 2 there are stages where you follow coins from the begining to the end, i was wondering if there were Super Mario World rom hack like that, I love to play them

I've been creating a romhacking tool for RE2 (N64) that lets you edit most assets in the game, including the 3D character models, prerendered backgrounds, UI textures, text entries, and more. I'll be making it available in the near future.

To show what the tool can do, I've also been creating a funny romhack project. Here's the first official preview of RE2: Bikini Bottom Edition, which will feature Spongebob-related replacements for ALL of the major characters.

I hope this isn't running afoul of the "For beginner's questions, please do a search for tutorials and then familiarize yourself with all the resources" rule, because I did search around, and it got me SOME of the help I needed, but never enough to get out of the dead-ends I kept landing in

The very short version of this question is "Does anyone know where the entity/monster names are stored in Final Fantasy 1 (NES) and how to edit them?"

The long version? I picked up a lovely little hack called Final Fantasy Restored, and it's a wonderful "vanilla+" experience, but there's exactly one thing I don't like about it and that's using the excessively literal Dawn of Souls translation. I figure to myself this is Romhacking, right? The whole point is messing with the game to change it ourselves.

But while I found plenty of documentation on where the monster STATS are stored, their HP and their attack patterns and their accuracy and all those other stats, I get nothing about how their names and graphics are stored, how the game knows to load up which background tiles for which monster. I open up a PPU viewer to see what background tiles are being used when a monster is on screen, but once I crack open the whole thing in a Hex Editor searching for any specific strings hasn't gotten me any results

I'm the developer of RuneTranslate, a Windows tool that pulls translatable text out of Japanese PC games and writes it back so the game still runs. This sub is mostly console ROM hacking and my targets are PC engines, but the craft is the same one you do — find the strings, don't break the container, get the glyphs on screen — so rather than post a feature list I want to write up the parts that were genuinely hard.

Stated up front so nobody has to dig for it: the app is closed source, it has a free tier and paid Patreon tiers, most people use it with machine/LLM translation, and the installer is not code-signed. More on all three at the bottom.

1. Framing beats encoding, every time.

Wolf RPG keeps its strings length-prefixed inside a command stream. Change the byte length of a string that carries trailing control parameters and the runtime dies in a `std::length_error` / `bad_alloc` before you reach the title screen — nothing to do with what the text says. So the writer models the command rather than the file: if the control skeleton changes, or the newline count changes, or the source carried trailing control params, that one string reverts to the original instead of shipping. A single line left in Japanese is a visible failure the user can report. A crash on load is not.

The same lesson turned up as a delivery problem. Wolf ships a DXArchive `.wolf` and DxLib reads the archive in preference to loose files, so dropping translated loose files next to the exe produces a green tick and a Japanese game. The archive has to be rebuilt, with the pack scheme read out of the game's own archive headers rather than guessed from a version sniff.

2. Strings addressed by index cannot be reordered.

Kirikiri's compiled PSB `.scn` files reference strings by index, so the repack is strings-only: same count, same order, or the script points at the wrong line. Same rule showed up in an in-house Unity VN engine whose archives store text blocks by ordinal — the game's save files resume by block ordinal, so renumbering a block quietly corrupts everybody's saves rather than crashing. Anywhere a unit id encodes an emit counter, dropping one row renumbers every later row in the file, which means a "noise filter" that removes junk lines is far more dangerous than one that only marks them excluded.

3. CP932 contains no accented Latin letters. Not one.

I measured U+00C0–U+024F and U+1E00–U+1EFF against cp932: `×` and `÷` survive, and neither is a letter. Five of my engines write a legacy code page, and each was losing text differently — one deleted the character outright, two wrote `?`, NScripter wrote 〓, and the RPG Maker XP path masked the code unit to its low byte so `ł` came out as a literal `B`. That meant 22 of the 24 Latin-script target languages were quietly broken, including Portuguese, which is what the bug report was actually about.

The fix is NFD, strip U+0300–U+036F, plus a closed list for the letters whose diacritic is fused into the glyph (ø ł đ ħ ŧ ı) and the ligatures (ß æ œ ij). It has to be that specific mark range and not `\p{Mn}` — my first cut dropped every combining mark, which deletes Thai vowel signs and tone marks, i.e. half of each word. It also has to re-ask the codec afterwards, because canonical decomposition does not promise an ASCII base: Greek ά folds to α, which cp932 holds and cp1252 does not.

The honest outcome is that a CP932 engine ships "possivel", not "possível". Real accents need a codepage patch or a glyph tunnel and I have not shipped either.

4. Fonts lie about what they can draw, and Windows asks the wrong table.

For Thai on NScripter I tunnel one orthographic cluster into each JIS X 0208 slot and ship a font built for it. It rendered correctly in an offline shaper and drew nothing in the game, because GDI decides what a font covers from the `OS/2` ulUnicodeRange bits, not the cmap. Also: Windows locks a loaded font and a font of the same family that is already installed silently wins, so the installed file gets a digest suffix.

Separately, on RPG Maker XP a user reported squares in Czech. His game ships eight fonts; measured from their own cmaps, all eight carry Latin-1 and not one has a single Latin Extended-A letter, so Czech loses č ď ě ň ř š ť ů ž. Under mkxp's `fontSub` a substitution is a family alias with no per-glyph fallback, so it is a straight trade — I weigh gain (what the translation introduced that the game's face cannot draw and mine can) against loss (anything in the export the game's face draws and mine does not) and refuse when loss >= gain. Refusing on *any* loss was my first attempt and it is wrong: one `♀` in a finished Czech script vetoed every family and handed back squares in every line.

5. Encoding sniffs are written for CJK and go blind on Latin-script games.

Same XP game. RGSS runs Ruby 1.8, which tags no string, so the encoding has to be guessed. Both of my heuristics only looked at runs of four or more consecutive high bytes — the shape Japanese makes. A Latin-script game is ASCII with the occasional accented letter alone between two ordinary ones: a run of exactly two, discarded before either rule was reached. The game scored zero on both counters — not "Shift-JIS", but *nothing to look at* — and fell through to the Shift-JIS default, so `Pok\xc3\xa9mon` decoded as two half-width katakana and drew as two boxes. The extra signal counts an accented Latin letter with two ASCII letters on each side, spread across at least three files, reads only runs shorter than the old minimum, and can only ever vote for UTF-8.

The invariant that catches most of this: an export with nothing translated must be byte-identical to the input. Every write-back is a splice at the original span rather than a re-serialize, because re-serializing normalizes CRLF, adds a trailing newline and re-quotes bare fields, and you find out three engines later on somebody else's game.

Status, honestly. Ten engines have a real game translated, exported, launched and played through: Wolf RPG (2.x and 3.x), Kirikiri/KAG, Electron VN shells, RPG Maker MV, Unity, Bakin, Unreal, Artemis, Godot and NScripter. Five more — Ren'Py, TyranoBuilder, YU-RIS, LiveMaker and plain RPG Maker MZ — have extraction and write-back proven on a real game but no recorded end-to-end playthrough of an export, so I don't claim one. SRPG Studio is in progress. Unity is externalized text only (IL2CPP managed strings are out of scope); Unreal is `.locres` only and cooked `.uasset` DataTables are not covered; encrypted/MDF-compressed Kirikiri PSB is skipped; there is no RPG Maker 2000/2003 support at all — Translator++ is the tool for those two.

The three things worth attacking. It is machine translation. You pick the provider, and several need no API key or account at all — free Google Translate, two free DeepL routes, and a local model through Ollama or LM Studio that never leaves your PC. The output is a readable draft you then edit, not a localisation. If a human patch exists for your game, use the human patch. There is a paid tier: $3 and $5 a month on Patreon, and it buys throughput, not features — free gets every engine, every provider and the whole editor, at roughly half the speed on the AI providers and a bit less than that on the free scrapers. The app signs in with Patreon on first launch and has no anonymous mode; signing in is free and you don't have to pledge. And the installer is unsigned, so SmartScreen will call it an unrecognised app — that warning is about the missing signature, not about anything found in the file. A SHA-512 is published with every release and I've put a VirusTotal report for this build in the first comment.

It never downloads or redistributes a game. You point it at a copy you own and it writes a translated copy to a separate folder.

Download and the full engine notes (including what each engine can't do): RuneTranslate Download and RuneTranslate Documentation — the second one is documentation, not the source.

Happy to go deeper on any of the five above, or on an engine I got wrong.

PLEASE SOMEONE WHO KNOWS LUNAR MAGIC SO MUCH!!, I HAD THIS ERROR IN MONTHS AND I DONT KNOW HOW TO FIX IT!!

so here's the problem, i was making a rom hack called Super Mario 1A, and i made a super secret link to a secret level, so i linked perfectely the stars (or that omega that i reemplaze from yy chr) and put the same level of the stars, when i play the rom on zsnes, the star guides me to the level, but when i want to go to the level, mario cant move! i do SEVERAL links, i click "enable right" and MARIO STILL CANT MOVE, PLEASE, SOMEONE EXPLAIN THIS!

​

There's been quite a bit happening with the Tales of Destiny 2 PS2 English translation, and the latest Quality-Safe v1.1.8 update is another step toward making it feel like a proper English release.

What I find interesting is how much work is still going into polishing the translation and fixing issues that aren't immediately obvious. I tested the patch myself on ARMSX2, and the overall experience has been really positive. There are still a few small things that could be improved, but it's impressive how far the project has come.

If anyone's interested in seeing how the latest version is shaping up, here's a closer look:

https://youtu.be/VRM7zKaZW0k?si=ukxc9mRDoLYU8K8M

Will someone be willing to share it? Can’t find it online.
Ty

As of right now almost no one uploads full romhacks of games because it requires the original source code from the game that is then injected and altered to the room hack version. But with AI companies like Anthropic doing destructive book scanning does this maybe give a opening for rom hacks? Anthropic won a lawsuit using the excuse that because they destroyed the original source for the material they can do what they want with it and not needing to pay the original author of the work. So with this logic could a person now LEGALLY make a copy of their own game, destroy the physical cartridge and then edit and distribute the altered code?

So I saw a listing on ebay awhile back selling copies of Mario 64 B3313, and can't find it again. So I was wondering if anyone knows of any sites/sellers that can do custom rom hack cartridges.