[GH-ISSUE #5709] [Feature] Nintendo 3DS static analysis through Ghidra and a reusable verification workflow #3459

New issue

Open

opened 2026-10-31 00:40:42 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:40:42 +00:00

Owner

Originally created by @thepoppfish on GitHub (Oct 20, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/5709

Before submitting

I searched the open and closed issues and pull requests for a related proposal.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This request does not include credentials, private samples, or sensitive target data.

Area

Native analysis or decompilation

Current limitation

Corrected submission: An earlier copy, #5704, was accidentally submitted through a different connected account. This is the request from my intended account. Could the repository owner please delete the earlier copy and use this issue going forward?

I'm developing an AI-assisted native Windows companion/port for the European Nintendo 3DS release of Tomodachi Life, using my own copy. I'd like to contribute reusable analysis and verification work to REA instead of maintaining all of the tooling separately.

This is a documentation-based support request, not a reproduced REA bug: I have not tested a REA integration on this target. The raw-binary guide documents a generic ARMv7 profile and excludes raw ARM from the native Windows Ghidra boundary. A verified 3DS workflow would need to establish ARM11/ARMv6K, ARM/Thumb interworking, floating-point conventions and the actual executable layout.

The initial analyst task would be to inspect a selected function, its instructions, callers and data references from an already-extracted 3DS executable plus explicit layout metadata, preserving the distinction between file offsets and loaded addresses.

Use cases

Our separate project currently has:

A C++ native Windows companion with a Mii/original-voice proof and tray show/hide, pause/resume and mute controls.
Recovered and individually checked components for resource loading, resident state/ownership, animation/rendering and audio. The integrated resident interaction and full game remain unfinished.
A Python-driven toolkit called Native Bench: reusable build manifests, case data and adapters; pinned inputs and build identities; incremental builds; and structured result recording.
Differential checks keeping original/reference execution separate from native implementation, comparing state, return values and relevant floating-point effects within declared fixture domains.
Bounded diagnostic output and storage, preserved failure results, and explicit handling of unsupported operations, timeouts and incomplete cleanup.

These are separate project capabilities, not proof of REA/3DS support or a complete general-purpose recompiler. No private comparison results or captured reference state are attached.

Desired outcome and success criteria

A focused static-analysis path through the existing CLI/MCP workflows:

Accept an explicit 3DS executable/layout profile, or integrate a suitable existing loader, with correct mapped sections and ARM/Thumb context.
Return function/instruction/reference results with source identity, file-to-memory mappings and explicit unsupported or unverified cases.
Verify the path with newly written, distributable homebrew/synthetic fixtures of known layout, including mixed ARM/Thumb code and selected floating-point controls.
Check actual Ghidra CLI/MCP behavior, unchanged input bytes, bounded output, cancellation and owned-process cleanup on a clearly named host platform.

A supported Linux/WSL analysis path would be useful if native Windows support needs a separate follow-up. This is not a request for an automatic whole-game port.

Expected interaction with targets

Read existing files or captured data, Launch or attach to a process, Write or change files/configuration

Target and scope details (optional)

The proposed first step reads caller-supplied files, launches Ghidra for static analysis, and writes isolated analysis output. It does not run the game or attach to it. Emulator/debugger reference execution, if useful later, would need a separate scope discussion.

ROMs, extracted game files, firmware, keys, assets, saves, captured memory, disassembly, title-specific recovered code and private evidence would stay out of public contributions. No decryption or protection-bypass capability is requested.

Verification available so far

I can suggest a sample or manual check

Verification details (optional)

We have a separate working component-verification toolkit and privately recorded project results. No REA/3DS runtime reproduction, public 3DS fixture suite or performance comparison has been completed. The acceptance checks above are proposed, and any speed benefit is unmeasured.

Alternatives considered

Continue using our separate Native Bench workflow, or investigate an existing Ghidra CTR loader. The existing loader and its maintenance fork are relevant starting points to evaluate instead of duplicating their format work; REA/Ghidra compatibility still needs testing.

Possible direction

Subject to maintainer direction, we could prepare focused contributions from the generic parts of our workflow: sanitized build/result contracts, reusable verification adapters, failure/resource-boundary handling, reproducible homebrew fixtures and documentation. Any code would first be separated from title-specific material and reviewed for third-party dependencies and licensing.

Would this fit REA's direction? Would you prefer an extension of existing Ghidra admission/layout profiles or integration with a CTR loader, and which host platform and smallest first contribution would be most useful?

References

REA raw-binary support
Ghidra CTR loader
Raikaru maintenance fork
Earlier copy submitted through the wrong connected account: #5704

Originally created by @thepoppfish on GitHub (Oct 20, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/5709 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area Native analysis or decompilation ### Current limitation **Corrected submission:** An earlier copy, #5704, was accidentally submitted through a different connected account. This is the request from my intended account. Could the repository owner please delete the earlier copy and use this issue going forward? I'm developing an AI-assisted native Windows companion/port for the European Nintendo 3DS release of Tomodachi Life, using my own copy. I'd like to contribute reusable analysis and verification work to REA instead of maintaining all of the tooling separately. This is a documentation-based support request, not a reproduced REA bug: I have not tested a REA integration on this target. The [raw-binary guide](https://github.com/morluto/rea/blob/main/docs/raw-binary.md) documents a generic ARMv7 profile and excludes raw ARM from the native Windows Ghidra boundary. A verified 3DS workflow would need to establish ARM11/ARMv6K, ARM/Thumb interworking, floating-point conventions and the actual executable layout. The initial analyst task would be to inspect a selected function, its instructions, callers and data references from an already-extracted 3DS executable plus explicit layout metadata, preserving the distinction between file offsets and loaded addresses. ### Use cases Our separate project currently has: - A C++ native Windows companion with a Mii/original-voice proof and tray show/hide, pause/resume and mute controls. - Recovered and individually checked components for resource loading, resident state/ownership, animation/rendering and audio. The integrated resident interaction and full game remain unfinished. - A Python-driven toolkit called Native Bench: reusable build manifests, case data and adapters; pinned inputs and build identities; incremental builds; and structured result recording. - Differential checks keeping original/reference execution separate from native implementation, comparing state, return values and relevant floating-point effects within declared fixture domains. - Bounded diagnostic output and storage, preserved failure results, and explicit handling of unsupported operations, timeouts and incomplete cleanup. These are separate project capabilities, not proof of REA/3DS support or a complete general-purpose recompiler. No private comparison results or captured reference state are attached. ### Desired outcome and success criteria A focused static-analysis path through the existing CLI/MCP workflows: 1. Accept an explicit 3DS executable/layout profile, or integrate a suitable existing loader, with correct mapped sections and ARM/Thumb context. 2. Return function/instruction/reference results with source identity, file-to-memory mappings and explicit unsupported or unverified cases. 3. Verify the path with newly written, distributable homebrew/synthetic fixtures of known layout, including mixed ARM/Thumb code and selected floating-point controls. 4. Check actual Ghidra CLI/MCP behavior, unchanged input bytes, bounded output, cancellation and owned-process cleanup on a clearly named host platform. A supported Linux/WSL analysis path would be useful if native Windows support needs a separate follow-up. This is not a request for an automatic whole-game port. ### Expected interaction with targets Read existing files or captured data, Launch or attach to a process, Write or change files/configuration ### Target and scope details (optional) The proposed first step reads caller-supplied files, launches Ghidra for static analysis, and writes isolated analysis output. It does not run the game or attach to it. Emulator/debugger reference execution, if useful later, would need a separate scope discussion. ROMs, extracted game files, firmware, keys, assets, saves, captured memory, disassembly, title-specific recovered code and private evidence would stay out of public contributions. No decryption or protection-bypass capability is requested. ### Verification available so far I can suggest a sample or manual check ### Verification details (optional) We have a separate working component-verification toolkit and privately recorded project results. No REA/3DS runtime reproduction, public 3DS fixture suite or performance comparison has been completed. The acceptance checks above are proposed, and any speed benefit is unmeasured. ### Alternatives considered Continue using our separate Native Bench workflow, or investigate an existing Ghidra CTR loader. The existing loader and its maintenance fork are relevant starting points to evaluate instead of duplicating their format work; REA/Ghidra compatibility still needs testing. ### Possible direction Subject to maintainer direction, we could prepare focused contributions from the generic parts of our workflow: sanitized build/result contracts, reusable verification adapters, failure/resource-boundary handling, reproducible homebrew fixtures and documentation. Any code would first be separated from title-specific material and reviewed for third-party dependencies and licensing. Would this fit REA's direction? Would you prefer an extension of existing Ghidra admission/layout profiles or integration with a CTR loader, and which host platform and smallest first contribution would be most useful? ### References - [REA raw-binary support](https://github.com/morluto/rea/blob/main/docs/raw-binary.md) - [Ghidra CTR loader](https://github.com/Martmists-GH/ghidra-ctr-loader) - [Raikaru maintenance fork](https://github.com/Raikaru/ghidra-ctr-loader) - Earlier copy submitted through the wrong connected account: #5704

bsakaguchi added the

triage

enhancement

labels

2026-10-31 00:40:42 +00:00

bsakaguchi referenced this issue

2026-10-31 00:44:58 +00:00

[GH-ISSUE #6484] [Bug] stop counting changed PyInstaller member types as unchanged #3890

bsakaguchi referenced this issue

2026-10-31 01:09:11 +00:00

[PR #3463] [CLOSED] test(artifact): cover multiple inspection inventory substeps #5754