Reverse Engineering and Gaming: The Technical Journey of Running Doom on a 20-Year-Old Office Phone

In an era of increasingly sophisticated computing devices, there exists a certain charm in repurposing older hardware for unexpected tasks. One such fascinating project involves running the classic Doom game on a 20-year-old Snom 360 office phone—a device originally designed for VoIP communications. This technical endeavor represents not just a nostalgic trip down memory lane but a remarkable exercise in reverse engineering, hardware hacking, and software porting.

The Genesis: From VoIP Phone to Gaming Platform

The journey began with a simple premise: what to do with outdated office hardware. The Snom 360, released in 2005, was a business-grade VoIP phone with a screen and keyboard—features that immediately sparked an alternative use case in the mind of the hacker. The original plan to set up an Asterisk PBX was quickly abandoned in favor of a more ambitious goal: could Doom, the iconic first-person shooter from id Software, be made to run on this specialized hardware?

The web interface of the Snom 360 during firmware update

Firmware Analysis: Understanding the Target Platform

The first step was understanding what exactly was running on the device. After upgrading to the latest available firmware (V08), the author began by examining the HTTP headers returned by the phone's web interface, revealing a custom "snom embedded" HTTP server. A deeper dive into the firmware image using binwalk showed a JFFS2 filesystem—a format designed for flash memory devices.

The extracted filesystem revealed a Linux-based system running kernel 2.4.31 on a MIPS processor, specifically designed for INCA-IP chips by Infineon Technologies. This was promising news, as it meant the platform wasn't completely alien but rather a somewhat dated Linux system that could potentially be modified.

Snom's website offering GPL downloads for older firmware versions

The Breakthrough: Accessing GPL Source Code

A critical moment in the project came when the author discovered that Snom provides GPL-licensed components for their devices. While the exact version (v7) wasn't identical to the installed firmware (v8), it was close enough to provide valuable insights into the system architecture. The download included:

• Root filesystem
• Kernel sources
• BusyBox source code
• U-Boot bootloader
• Cross-compilation toolchain
• UPX executable packer

This treasure trove of source code would prove invaluable for understanding the hardware interfaces and building custom firmware.

Hardware Hacking: Gaining Physical Access

With source code in hand, the next challenge was gaining access to the underlying hardware. The author opened the phone and identified test points on both the top and bottom PCBs. After some trial and error with a Serial-to-USB adapter, they successfully established a connection to the U-Boot bootloader.

Top PCB with test points (GND, TxD, RxD)

This physical access enabled the creation of a custom firmware image. Using the provided toolchain, the author built a modified rootfs with enhanced BusyBox capabilities and flashed it to the device via TFTP. The result was shell access to the phone, opening up possibilities for further experimentation.

Reverse Engineering: Decoding Hardware Interfaces

With shell access secured, the author embarked on the complex task of reverse engineering the hardware interfaces for the display, LEDs, and keyboard. This involved analyzing the firmware binaries in Ghidra, identifying system calls, and cross-referencing with the kernel source code.

Display Interface

The display proved to be a custom LED matrix controlled through a special device file (/dev/inca-port). Communication occurred via ioctl commands with specific parameters for controlling the display. The author discovered that the display consisted of 8 rows with 132 columns each, but each row actually represented 8 vertical pixels, resulting in a resolution of 132×64 pixels.

Bottom PCB with additional test points

LED Control

The phone contained 16 controllable LEDs, including the backlight. Through careful analysis, the author mapped each LED to its corresponding index in the control register, with the backlight being LED index 0.

Keyboard Interface

The keyboard interface required reading individual bits from the device, with each key press generating a specific code. The author created a complete mapping of all physical keys to their corresponding codes, distinguishing between key presses and releases through the most significant bit.

Single line of pixels at the bottom of the display

Porting Doom: Adapting to Limited Resources

With the hardware interfaces understood, the author turned to the actual task of porting Doom. They chose doomgeneric, a fork of fbDOOM designed for easy portability to new platforms. The port required implementing several platform-specific functions:

1. DG_Init: Initialize the platform and activate the backlight
2. DG_SleepMs: Implement millisecond sleep using usleep
3. DG_GetTicksMs: Track time using gettimeofday
4. DG_GetKey: Map keyboard events to Doom's key codes
5. DG_DrawFrame: Convert and render the game frame to the display

The most challenging aspect was adapting Doom's rendering to the phone's limited display. The solution involved:

• Rendering at 640×400 resolution
• Downscaling to 132×64 by averaging pixel groups
• Converting RGB to grayscale
• Applying a contrast threshold
• Packing 8 vertical pixels into a single byte

Overcoming Technical Hurdles

The project wasn't without its challenges. One significant issue was endianness—the cross-compiler wasn't setting the internal __BYTE_ORDER__ macro correctly, causing problems with the WAD file loading. The author implemented a simple workaround by adding explicit byte-swapping functions.

Another limitation was the lack of sound support. While the hardware likely had audio capabilities, implementing sound would have required additional reverse engineering and was deemed more complex than the visual aspects.

Final Product and Implications

The completed Doom port, while functional, had noticeable limitations: visual artifacts, no sound, and largely unreadable text. Yet, it represented a significant achievement in hardware hacking and demonstrated the potential for repurposing specialized devices.

This project highlights several important technical concepts:

• The value of open-source firmware components in hardware hacking
• The importance of physical access for low-level system modification
• The challenges of adapting software to highly constrained hardware environments
• The creative problem-solving required when working with undocumented interfaces

For those interested in similar projects, the author has indicated plans to release the custom driver, display control tool, and doomgeneric patch once the code is properly cleaned up. The project serves as both a technical guide and inspiration for others looking to breathe new life into obsolete hardware.

The Snom 360 Doom port stands as a testament to the enduring appeal of hardware hacking and the creative possibilities that emerge when we look beyond the intended purpose of our devices.