Animal Crossing: amiibo Festival (Wii U) — patch to remove Katrina

Animal Crossing: amiibo Festival is a Wii U game where, every so often, a random special character shows up to do something unique — K.K. Slider plays a concert, Redd sets up an art sale, Pascal shows up on the beach. One of these random visitors is Katrina, a fortune-telling panther common to the series, and for reasons that are entirely a matter of personal taste, Luke wanted her gone. Permanently. Every other random visitor could stay; just not her.

There's no in-game setting for this. So the only way to do it was to open up the compiled game code itself, figure out how the game decides "who shows up today," and surgically remove just her from that decision — without touching anything else, and without breaking the game.

That turned into a much deeper rabbit hole than expected: multiple wrong guesses that looked right until tested, a couple of real bugs in my own patches, live-hardware testing over dozens of in-game days, and eventually a small binary patch that does exactly one thing: it makes the game treat Katrina's specific "slot" in its daily lottery as permanently empty.

The result is two small files — a patch and its exact undo — that anyone with a legally-dumped copy of the game can apply to bring about the same result, plus a full write-up of how it was found, for anyone curious about what that process actually looks like on a Nintendo console from the inside.

The game and the toolchain

Animal Crossing: amiibo Festival (Wii U, title ID 00050000101C6400, US region) ships as a set of Cafe OS executables: a main bbq.rpx and several .rpl library modules, one of which — board.rpl — handles the party-board game logic. Both are ELF-derivative files in Nintendo's "RPL" format: mostly-ordinary ELF, except individual sections can be independently zlib-compressed, and there are a handful of Cafe-specific section types (SHT_RPL_EXPORTS, SHT_RPL_IMPORTS, SHT_RPL_CRCS) for cross-module linking between the main executable and its .rpl libraries.

None of the existing tooling I found did quite what I needed, so I ended up writing a small Python toolkit from scratch: an RPL/ELF parser that handles the zlib sections and the export/import tables, a parser for Nintendo's proprietary "PAC" archive format used for the game's asset bundles (shared with Mario Party 10, as it turns out — both are ND Cube titles), an MSBT localized-text parser, and a Capstone-based PowerPC disassembler with relocation-aware call-graph tracing (cross-module calls show up in the raw file as placeholder addresses that only resolve correctly once you follow the ELF relocation table).

First guess: VisitorId 31 (wrong)

The compiled binary still had its debug symbol table intact — a huge convenience, since it meant real, demangled C++ function and class names instead of a sea of anonymous addresses. Searching for anything related to "Katrina" led to bd::TodaysHappeningEvent::canAllowVisitorToCome(int), a function that reads a per-character enable flag out of a small table. A message-file search turned up bbq_SPNpc_name031 → "Katrina", a special-NPC name list where the numeric suffix in each symbol was literally the character's ID. 31 looked like the answer.

It wasn't. Patching canAllowVisitorToCome to reject id 31 changed nothing — she kept showing up. Rebuilding and testing this patch also surfaced a real bug in the RPL format's compression handling: the Cafe loader reads *exactly* section_size - 4 compressed bytes and feeds them to inflate() directly — it does not stop at the natural end of the deflate stream the way most zlib wrappers do. My first repack attempt zero-padded the leftover space after recompressing (to avoid moving every subsequent section in the file), which caused the loader to choke on the trailing garbage and refuse to boot the title at all ("executable is damaged" in Cemu). The fix was to shrink the section header's declared size to match the new, smaller compressed length instead of padding — a good reminder that "it decompresses fine in Python" and "the actual game loader is happy with it" are not automatically the same thing.

Second guess: TodaysHappeningEvent id 101 (also wrong)

With the loader bug fixed, the patch now *loaded* — but Katrina still appeared. Time to reconsider the actual ID. The canAllowVisitorToCome signature takes a TodaysHappeningEvent value, a different enum from VisitorId. Digging through the binary's own debug label tables (an internal getTdEventLabel(int) → "td_all_NNN" lookup, seemingly meant for developer logging) turned up td_all_101, and the corresponding localized text file for that ID — td_all_101.msbt — contained the string "Katrina space." Convincing evidence. Rebuilt the patch for id 101.

Still wrong. She still showed up.

Finding the real mechanism

At this point it was clear canAllowVisitorToCome simply wasn't the actual decision point — cross-referencing its callers confirmed it's a real, legitimately-used cross-module function (board.rpl imports and calls it exactly once), but only as one of several downstream validity checks (alongside weather and time-of-day conditions) on a value that had already been decided somewhere else.

Tracing backward through board.rpl eventually surfaced the real mechanism: once per board-game session, the game runs a weighted random lottery over a 120-slot candidate table to decide "today's happening." Each 36-byte record holds an enable flag, a lottery weight, a valid month-range, and some weekday-type flags. The winning slot's raw index (0–119) is the TodaysHappeningEvent value used everywhere else in the game — no translation step. The debug label naming (td_all_101) and the actual runtime index turned out to be two different numbering schemes entirely; directly reading the binary's static id→string lookup array and searching for which index pointed at the Katrina string revealed the real value: the td_all_1NN numbers map to real indices via a flat -20 offset (td_all_100 = index 80, td_all_101 = index 81, and so on) — not something documented anywhere, just something that fell out of reading the compiled table directly.

Testing it — the empirical part

Static analysis got the mechanism and a candidate index (81), but the only way to be sure was to test it on real hardware, and that meant building several disposable test patches:

• A patch that disabled all 120 slots at once, as a sanity check that this table really was the mechanism. Played a full session: every calendar-fixed holiday and the deterministic weekly NPC still appeared normally, while every random event — Katrina included — never did. Confirmed the mechanism.
• A binary search across ranges of the 120 slots (quarters, then eighths), each requiring a real multi-day play session to get a signal, narrowing candidate 81 down from "somewhere in 120" to "confirmed."
• A "keep only this one slot active, disable all 119 others" test, run against slot 81 for a full one-hour session: Katrina appeared 5 times, nothing else random did. A second version of this same test, applied to Redd's and Phineas's candidate slots (found the same way — searching their names in the game's own text files) came up empty even after fixing a real bug in the test patch itself (the first version only bypassed the enable-flag check, not the month/weekday checks further down the same code path, which could mask a real hit if the real-world calendar didn't line up) — suggesting those two specific events have some additional gating condition never fully traced. Katrina's slot had no such issue.
• Finally, the actual intended patch — disable *only* slot 81, leave the other 119 fully intact — survived a complete real game session with Katrina never appearing and every other random event continuing to work normally (if anything, slightly more often, consistent with her removed weight being redistributed across the remaining candidates in the lottery).

Every patch, at every stage, was built via a small "code cave" technique: replace one instruction at the check site with a branch to newly-appended code at the end of the (now slightly larger) compiled section, run the real logic there, then branch back — letting a couple of extra instructions' worth of new logic get inserted without disturbing anything else in the file. Every hand-encoded branch offset was double-checked by disassembling the result and confirming it landed exactly where intended — I made the same kind of off-by-a-few-bytes mistake more than once by trusting mental arithmetic instead of a disassembler round-trip, which is a good general lesson for anyone doing this kind of binary patching by hand.

The deliverable

The final patch is a single 4-byte instruction replacement at one specific address in board.rpl's compiled code, expressed as a standard IPS patch (plus an exact reverse/undo patch), along with the hashes needed to confirm it's being applied to a matching, unmodified file before use.

What's still unresolved

The function that actually *populates* that 120-slot table at runtime was never found, despite a fair amount of searching — it's likely filled in via a generic "load resource into buffer" routine rather than anything with an obviously-searchable, hardcoded address. And there's currently no reliably working tool for live memory inspection on Wii U's current Aroma homebrew environment (several options were tried; one didn't connect, one doesn't compile against the current plugin library version, one turned out to be an unrelated tool entirely) — which would have made some of the binary-search testing above considerably faster if it had worked.

Final note

If you're looking to do something similar with a game you own: this whole process amounted to combining static analysis of the compiled code with patient, repeated empirical testing on real hardware, and being willing to throw out a confident-looking guess the moment it failed a real test.