Reverse Engineering a Cheap NES Phone Case: Firmware, Hardware, and Custom Code Analysis

Poking Technology

Introduction to the NES Phone Case [0:00]

The video begins with the presenter introducing a novel phone case that doubles as a functional NES (Nintendo Entertainment System) console. The device, purchased from AliExpress for a low price (5 Swiss francs), is noted for its ubiquity and "cheap and nasty" nature.

• Comparison with "Sup" Handheld [0:18]

  • The phone case is likely based on a "NES-on-a-chip" (NoC) device, similar to other cheap handhelds like the "Sup" console, which became common after Nintendo's patents expired.
  • These NoC devices offer basic NES compatibility but often have "miserable controls" and varying game compatibility.

• Initial Experience with the Phone Case [1:41]

  • The phone case's firmware package and main menu are distinct from the typical "Sup" console.
  • It features fewer games, around 30-something, presented with a colorful title screen, which is an unusual feature for a stock NES, suggesting customized hardware or firmware.
  • The games, which are described as "totally legal licensed ROMs" (sarcastically), run adequately, though the exact speed and sound quality are not definitively confirmed by the presenter.

    

Disassembly and Internal Components [3:23]

The presenter proceeds to disassemble the phone case to examine its internal workings.

• Opening the Case [3:30]

  • The case is found to be glued together, but with weak adhesive, allowing for easy opening.

• Component Identification [3:51]

  • Loudspeaker: A standard speaker component.
  • USB Connector: Provides power only, with only red and black wires, indicating no data functionality.
  • Battery: Equipped with a battery protection circuit, a positive finding for safety.
  • PCB and Screen: The main circuit board and display. The screen is plastic-welded in place.
  • "324 Ultra" Marking: A model name or identifier found on the PCB.

Examination of the Printed Circuit Board (PCB) [5:30]

The PCB is removed and inspected more closely, revealing the core logic of the device.

• Epoxy Blob and Flash Memory [5:52]

  • The central epoxy blob is identified as containing the "intelligence of the device," likely a microcontroller or an all-in-one "NES-on-a-chip" solution.
  • A visible 8-pin chip is identified as an SPI flash chip (Winbond 25Q16), which is presumed to store all the software and game ROMs.

    

  • Other components include a smaller 8-pin chip (possibly a power controller) and unpopulated USB socket pads, indicating a common PCB design used across different products.

• Button Mechanism [6:30]

  • Buttons operate by pushing down on conductive pads, shorting circuits on the PCB.

ROM Dumping and Initial Analysis [7:24]

The presenter attempts to extract the firmware from the SPI flash chip.

• On-board Dumping Attempt (Failure) [7:34]

  • An initial attempt to dump the chip using a clip on the board fails due to interference from the powered microcontroller. The programmer reports an incorrect chip ID.

    

• Off-board Dumping (Success) [8:45]

  • The flash chip is desoldered and placed onto a carrier board, allowing for a clean read. The programmer correctly identifies the chip (Winbond 25Q16) and successfully extracts the 2MB ROM image.

    

• Basic ROM Analysis [9:35]

  • Encryption Check: The ROM image is confirmed to be unencrypted after running string searches, revealing plain text strings like the Greek alphabet.
  • Machine Code Detection: Running CPU rec to detect 6502 machine code yields minimal results, which is unexpected for an NES system. This suggests that code reads might be encrypted on-the-fly, while data reads are not, or the system uses an unrecognized architecture.
  • NES Boot Vectors: Expected NES reset vectors are not found at the typical memory locations.

    

Signal Analysis and Debugging [12:00]

To understand the system's runtime behavior, the presenter connects a logic analyzer to the PCB.

• Initial Logic Analyzer Setup Challenges [12:00]

  • Wiring the logic analyzer to the board causes glitches and boot failures, attributed to long wires introducing capacitance at the detected 90 MHz SPI clock speed, which is beyond the comfort zone for hobbyist tools.
  • The speaker notes that the speaker sound became "nasty scratchy" and the device would glitch out, suggesting signal integrity issues.

• Hardware Modifications and New Issues [13:51]

  • A ZIF (Zero Insertion Force) socket is soldered to the board for the flash chip, requiring hot glue for stability. This makes reassembly impossible but improves signal integrity for the flash chip.
  • Further issues arise with power, as the power supply cannot provide the necessary inrush current, causing the device to boot loop. This is solved with a large capacitor.
  • During these attempts, the screen is accidentally broken.

• Successful Test Jig and QSPI Protocol [20:41]

  • A fully functional test jig with external buttons is assembled.

    

    

  • The working system allows for capturing SPI signals. A deeper look with the oscilloscope reveals the clock signal for the SPI flash can reach 90 MHz in bursts.
  • Analysis of the Winbond datasheet confirms the use of a Quad SPI (QSPI) mode (command E7) for continuous read operations, transferring 4 bits per clock cycle for faster data retrieval.

    

  • The logic analyzer successfully decodes reads from the flash chip, matching the dumped ROM data.

    

• Unreliable Logic Analyzer Capture [24:30]

  • Despite using a high-end Saleae Logic Pro 16, the logic analyzer itself interferes with the 90 MHz signals, causing the device to crash and leading to corrupted data captures. The captures are deemed unusable for understanding program execution flow.

    

Deeper ROM Analysis and Chip Identification [33:28]

With unreliable signal captures, the focus shifts back to static analysis of the dumped ROM and further research.

• Identifying Game ROMs [37:12]

  • Within the 2MB flash dump, ROMs for "Super Mario" (0.5MB) and "Super Contra" (1MB) are found.
  • Other areas contain structured information and blocks of actual 6502 machine code that CPU rec initially missed.

    

• Vendor and Chip Identification [44:51]

  • A string "Cube Technology Company" is found in the ROM. Cube Technology is known for bootleg NES devices.

    

  • Through pattern analysis and a MAME database search using the ROM's SHA1 hash, the device is identified as a "36P case" based on the VT369 "NES-on-a-chip" solution, one of the most advanced NES clones.
  • The VT369 chip features hardware multiplication, fast CPU, and 8-bit per pixel graphics, explaining the colorful menu seen earlier.

    

• Internal ROM and EEPROM Discovery [49:27]

  • The VT369 has a 4KB internal ROM for initialization, which executes before accessing the external SPI flash. This explains the initial slow boot sequence observed in the logic analyzer.
  • The Nesdev Wiki (Mapper 427 for VT369) describes a possible "i-squared C based protection chip" and a 24C04 EEPROM connected to GPIO ports (4148 or 4150).
  • The menu code, running on the VT369, reads values from this EEPROM for PPU control and other settings, suggesting a copy protection mechanism or hardware configuration storage.

Dumping Internal ROM and EEPROM [51:30]

Since the internal ROM and EEPROM are inaccessible, creative methods are needed.

• Dumping Internal ROM via Backlight Morse Code [51:30]

  • The presenter devises a method to dump the internal ROM by writing a custom program to the flash chip.
  • This program reads the internal ROM byte by byte and outputs the data by blinking the screen's backlight in Morse code (later simplified to a short/long pulse scheme).
  • A phone camera is used to record the blinking, and an FFMPEG script converts the video to grayscale pixels, which are then decoded by a Python script.
  • This method successfully extracts the 4KB internal ROM image.

    

    

• Dumping the EEPROM [1:12:35]

  • The internal ROM is found to contain code that reads an external EEPROM.
  • A custom program is written to read all 256 bytes of the EEPROM (believed to be 512 bytes based on Wiki, but only 256 bytes could be read by addressing).
  • The EEPROM dump shows mostly blank values with some modified bytes, which are then matched against the menu's initialization code in Ghidra.

    

  • The values from the EEPROM are used to configure NES PPU registers and other settings. This is considered an unusual approach as these are typically hardwired, potentially serving as a copy protection or hardware variant detection scheme.

    

Conclusion and Future Work [1:41:53]

The project concludes with all major ROM components dumped, but further emulation proves challenging.

• Emulation Challenges [1:35:00]

  • Attempts to create a combined ROM image for MAME, including the dumped flash ROM, internal ROM, and EEPROM data, fail to boot the system successfully.
  • MAME's support for the VT369 (Mapper 427) is noted as "poor" and requires significant development work, which the presenter opts not to undertake at this time.

• Project Outcome [1:41:53]

  • All dumped ROM images (main flash, internal, and EEPROM) are planned for upload to relevant forums and archives for community use.
  • The presenter expresses interest in retrofitting a working NES phone case (a newly acquired replacement) into a more usable handheld console with better controls, as the original rubber keys are "terrible."
  • The quality of the pre-loaded games on these devices is praised for being "legitimate ripped off pirate games" that generally work well, unlike older cartridges with many duplicates.