Full Report
Before the internet, the Super Nintendo (SNES) had an online gaming community via the XBAND Video Game Modem. The goal of the author was to create complete emulation support for XBAND. XBAND networks was designed to send controller inputs between connected clients with the network and the mode. The XBAND OS would patch the ROM of the game to add its own instructions to inject controller inputs. The engineers who built the implants for the games had to reverse engineer the games in order to write custom patches, which is pretty neat. To accurately emulate this, the most important thing is getting it to boot. This required setting up the memory mappings correctly. Additionally, the Rockwell Modem, used to send the wireless packets, was communicated with via MMIO. So, to accurately emulate this, the read and write had to be properly implemented. From reading specifications and old school docs, they were able to get this working in a few months. The protocol used for the XBAND network was the Apple Data Streaming Protocol (ADSP). This was used because it provided basic sessions between two hosts. The XBAND would consume these packets via the modem, which would de-frame and push the information to the XBAND OS for consumption. To test out this functionality, the author created a way to injection arbitrary ADSP packets into the network layer. The XBAND network has two types of calls: ServerTalk and GameTalk. ServerTalk was the server to client communication while the GameTalk was for client to client communication. The XBAND OS used the message dispatch pattern in order to execute OS function calls for ServerTalk packets. Each one of the message id corresponded to a piece of functionality. While reverse engineering the dispatch codes, the author found one called msExecuteCode. What does this function do? It runs arbitrary code specified by the modem! To test this, the author used the packet injection feature and hit the corresponding location in the code on the game. From there, the author wrote a short snippet of self-contained assembler that would reset the state of important registers and change the color of the screen to green. The author even got this to run on real hardware by setting up the modem and the SNES game locally. From there, the author found a few other bugs. One allowed for a re-write of a char 244 OOB. Additionally, they found an unbounded write to SRAM for X-mail messages. Overall, this was an awesome post on emulation, games in the 80s and hacking. Thanks for writing this!
Analysis Summary
# Research: Exploring the XBAND Video Game Modem and Executing Arbitrary Code Over a Phone Line in 2022
## Metadata
- **Authors:** fresh-eggs (Independent Researcher)
- **Institution:** N/A
- **Publication:** fresh-eggs.github.io
- **Date:** 2022
## Abstract
This research explores the legacy architecture of the XBAND Video Game Modem for the Super Nintendo (SNES). The author develops a custom emulation environment to facilitate security analysis and successfully identifies a remote code execution (RCE) primitive built into the XBAND OS. By repurposing the Apple Data Streaming Protocol (ADSP), the researcher demonstrates the ability to inject arbitrary code into retail hardware via a simulated 1990s telephone network.
## Research Objective
The primary objective was to investigate the security posture of the XBAND modem and its proprietary operating system. This involved creating a functional debugging and emulation environment for XBAND on the SNES to achieve arbitrarily code execution on 30-year-old retail hardware through the modem interface.
## Methodology
### Approach
1. **Emulation Development:** Porting existing partial XBAND support to the `bsnes-plus` emulator to create a robust debugging environment.
2. **Reverse Engineering:** Analyzing the XBAND OS’s memory mapping, I/O handling for the Rockwell modem, and the implementation of the Apple Data Streaming Protocol (ADSP).
3. **Protocol Analysis:** Investigating "ServerTalk" and "GameTalk" message dispatchers.
4. **Hardware Verification:** Validating findings on physical hardware using an Analog Telephone Adapter (ATA) and a private XBAND server.
### Dataset/Environment
- **Hardware:** Retail SNES, XBAND Modem, Cisco ATA (Analog Telephone Adapter).
- **Software:** XBAND OS (Retail ROM), Asterisk (Software PBX), modified Roofgarden XBAND server.
### Tools & Technologies
- `bsnes-plus` (Source-level debugging/Emulation)
- 65816 Assembly (SNES CPU architecture)
- C++ (Emulator modifications)
- Asterisk/Softmodem (Telephony simulation)
## Key Findings
### Primary Results
1. **Intentional RCE Primitive:** The discovery of the `msExecuteCode` ServerTalk message. This function is a "feature" of the XBAND OS that allows the server to send and execute arbitrary code on the client's SNES.
2. **Lack of Authentication:** The XBAND OS lacks modern signature verification or authentication for ServerTalk packets, allowing any entity acting as the server to gain full control of the console.
3. **Memory Safety Issues:** Identification of an out-of-bounds (OOB) write in the `_PutByte` function and unbounded writes to SRAM via X-mail messages.
### Supporting Evidence
- Successful execution of a custom 65816 assembly payload (changing the screen color to green) on both the emulator and physical retail hardware via a simulated phone call.
### Novel Contributions
- The first complete implementation of XBAND modem hardware emulation (Rockwell RC2324DP MMIO) in a modern SNES emulator.
- Development of a packet injection framework for the ADSP protocol on SNES.
## Technical Details
The XBAND OS utilizes a message dispatch pattern for server-to-client communication. When the modem receives an ADSP packet, the OS identifies the message ID and routes it to a corresponding function. The `msExecuteCode` (Message ID 0x3D) routine specifically reads a payload directly from the modem buffer and jumps the CPU program counter to that memory location. To demonstrate this, the researcher bypassed the modem layer by injecting packets directly into the emulator's memory and later via a local telephony loopback.
## Practical Implications
### For Security Practitioners
- This research highlights the longevity of "backdoors" or diagnostic features. What was an efficient patching mechanism in 1994 becomes an RCE vulnerability in 2022.
### For Defenders
- Demonstrates that legacy systems often lack the concept of "untrusted input," treating data from a peripheral (like a modem) as implicitly safe.
### For Researchers
- Provides a blueprint for retro-gaming security research: Emulation -> Debugging -> Protocol Analysis -> Hardware Verification.
## Limitations
- Exploitation requires a man-in-the-middle (MITM) position on the phone line or control over the XBAND server.
- The 65816 architecture lacks modern protections like NX (No-Execute) or ASLR, making code execution trivial once a primitive is found.
## Comparison to Prior Work
While the Retrocomputing network had revived the server-side architecture, this research is the first to analyze the XBAND OS from a vulnerability research (VR) perspective and complete the hardware emulation necessary for deep security analysis.
## Real-world Applications
- **Gaming Preservation:** Accurate emulation of the XBAND hardware allows for the preservation of online-only gaming history.
- **Hardware Hacking:** Techniques for interfacing 90s modems with modern VoIP/SIP systems (Asterisk).
## Future Work
- Further exploration of persisting payloads within the XBAND SRAM database via X-mail.
- Analysis of the "Patch" files used by XBAND to modify game logic in real-time.
## References
- XBAND Retrocomputing Network: `xband.retrocomputing.network`
- `bsnes-plus` GitHub: `github[.]com/devinacker/bsnes-plus`
- FullSnes (SNES Documentation): `problemkaputt[.]de/fullsnes.htm`