How YSMenu Rewrites Nintendo DS Games at Launch

In this article I'll be tracing YSMenu's launch time binary rewriting pipeline from its interception of a retail Nintendo DS cartridge read routine through the resulting control flow transfer into a loader resident implementation absent from the game's original executable image.

1. Launch

YSMenu starts by reading the selected ROM header and resolving a compatibility record that describes relevant Nintendo SDK routines inside the staged ARM9 image, allowing stable interception points to be recovered even though commercial titles were independently linked against several SDK revisions and compiler configurations. When a cached offset is unavailable the loader scans characteristic instruction sequences and recovers equivalent hook metadata directly from executable code, after which either discovery route yields relocated ARM9 addresses + handler indices that select corresponding entries inside YSMenu's compact resident payload.

2. Installing the SDK interception

At 0x02328600, the installer walks cached record words and rejects sentinel encodings before materializing executable patches inside the relocated game image, because blindly treating an absent entry or reserved value as an offset would overwrite unrelated instructions and destabilize execution before the title reaches its own initialization path. At 0x0232863c, ldr r1,[r5,#0x18] retrieves record word 6 for the primary cartridge read hook, then 3 comparisons reject unavailable and reserved encodings before relocation arithmetic or an architecture specific writer can consume the candidate destination and overwrite executable code.

A surviving offset is combined with the appropriate ARM9 relocation base before hook_trampoline_address selects the resident destination required by that SDK routine, and the final writer emits an interworking stub directly over the original function entry without modifying any caller that already targets the established symbol boundary. Rewriting 1 callee is efficient because overlay loaders + resource managers and game engines already converge upon this SDK choke point, giving YSMenu broad interception coverage while keeping each mutation local enough for compatibility metadata to describe across thousands of independently built retail binaries:

3. Building an absolute interworking veneer

A direct branch can fail when displacement exceeds the instruction range or when source and destination execute under different processor states, so YSMenu generates an absolute veneer that loads a complete destination address before transferring control through bx with explicit ARM and Thumb interworking semantics. At 0x023272a4, the writer serializes each opcode byte and embeds the runtime pointer inside the patched ARM9 text region, while its register field is derived dynamically so 1 compact emitter can write several veneers without assuming a fixed scratch register or 1 instruction state.

The destination pointer carries bit 0 whenever execution must enter Thumb state because bx interprets that bit as interworking metadata, which lets the generated veneer cross architectural state safely while still carrying an unrestricted absolute address rather than a range limited displacement. For the principal card read hook the encoded target becomes 0x023fe001, which enters the resident trampoline through a cacheable RAM alias resolving to payload storage physically staged at 0x027fe000 because Nintendo DS main RAM exposes mirrored address windows during execution:

4. Preserving the game ABI

The resident payload begins with compact Thumb trampolines whose indices correspond to handlers selected earlier by the installer, and entry 0 preserves the caller's return address before invoking card_read_wrapper and restoring control through an explicit bx transfer that retains the required instruction state. Other entries support asynchronous reads + callbacks and specialized fixed-length transfers used across divergent Nintendo SDK generations, giving the patcher several ABI-compatible landing points without forcing each retail binary through 1 oversimplified signature or 1 brittle register convention alone:

The wrapper receives the same ROM offset + destination pointer and byte count that Nintendo's implementation would've accepted, enables the auxiliary cartridge bus before dispatching mapped_rom_read, and later restores hardware state without exposing the storage substitution to any upstream caller. This ABI continuity lets every compiled caller remain untouched because only the implementation beneath its linkage contract changes, while small ARM helpers preserve interrupt state and execute CP15 cache maintenance so DMA transfers + executable aliases remain coherent throughout the replacement transaction. Those details separate a production loader from a trivial redirect, since correct sector arithmetic remains useless when stale cache lines or disturbed interrupt state violate the timing and coherency assumptions surrounding an otherwise ordinary SDK cartridge request under sustained streaming workloads.

5. Translating ROM offsets into sectors

The resident runtime doesn't parse FAT because YSMenu prepares a compact extent map while the menu still owns filesystem context, pairing 16 logical boundaries with physical sector bases so fragmented file runs can be represented without carrying general filesystem machinery into scarce resident memory. mapped_rom_read preserves incoming registers before converting the requested byte offset into a logical sector through shifts aligned to 512 byte blocks, then walks the prepared extent table until it identifies the physical run containing that logical position during each request:

The mapper advances until the logical sector falls below an extent boundary before adding displacement to that extent's physical base, and a read crossing fragmented storage terminates the current transport run before restarting from the next physical extent without disturbing caller state. Unaligned requests use a scratch sector before copying selected bytes whereas aligned blocks stream words directly into the game's destination, preserving arbitrary SDK semantics without forcing the common aligned resource transfer through an unnecessary memory copy and its associated cache pressure. The transport layer consequently receives physical sectors rather than pathnames or FAT clusters, which keeps its latency sensitive hot path deterministic and compact while leaving all expensive filesystem traversal inside the menu phase where memory and execution time are less constrained.

6. Programming the DSTT controller

A new physical run begins with DSTT 0x54 and a sector argument serialized into the cartridge command buffer, while standard-capacity cards require the runtime to shift each sector left by 9 because their command protocol expects byte addressing rather than native sector indices. High capacity media accepts sector addressing directly and therefore avoids that multiplication, after which the routine polls operation 0x80 until hardware reports readiness before selecting payload data through operation 0x81 within the controller's command and response state machine during every block transaction:

At 0x04100010, CARD_DATA_RD supplies words under the configured ROMCTRL transfer mode, and YSMenu doesn't emulate this register because the flashcart changes the backing medium while Nintendo's native cartridge hardware continues performing the actual transport for each requested block transfer. Crossing an extent invokes the SD stop helper which sends command 12 through DSTT operation 0x51, then polls operation 0x50 and consumes its response through 0x52 so stale controller state cannot contaminate the next physical run or any later read.

7. Why DLDI isn't the answer

YSMenu also contains a recognizable DLDI driver with relocation metadata and generic block device entry points for homebrew software, whose binaries intentionally reserve a placeholder that launchers replace with flashcart-specific filesystem code before execution begins on supported hardware during initialization. Commercial games contain no such placeholder because their storage requests already target Nintendo's compiled cartridge SDK interface, so retail loading uses the patcher described above while DLDI remains a parallel integration path for cooperating homebrew applications inside the same launcher. Both paths eventually command DSTT hardware yet their discovery logic + calling conventions and mutation boundaries remain fundamentally different, which is why calling the retail mechanism DLDI obscures its defining property as binary linkage performed against an application that never requested linking.

8. The complete rewritten path

compiled SDK card read
    -> generated absolute interworking veneer
    -> cacheable RAM alias at 0x023fe001
    -> resident trampoline at 0x027fe000
    -> card_read_wrapper
    -> mapped_rom_read
    -> 16 entry extent map
    -> DSTT 0x54 / 0x80 / 0x81
    -> CARD_DATA_RD at 0x04100010
    -> bytes inside the original destination buffer

The complete chain is short because most loader complexity exists only to discover safe interception points across independently built games, and once execution enters the resident payload its responsibilities reduce to ABI preservation + extent translation and deterministic controller sequencing for every request. YSMenu doesn't rewrite every caller because 1 generated veneer changes the meaning of every read already converging upon Nintendo's SDK routine, producing something resembling dynamic linking where compatibility metadata supplies relocation knowledge and resident trampolines implement a device absent from the original binary. Its elegance comes from preserving every layer above that narrow boundary while replacing everything below with a purpose built microSD transport stack, leaving the game to consume redirected bytes through the exact interface and control flow its developers originally expected during ordinary resource loading.