16GB iPod Nano 3G Upgrade

By Tucker Osman | Published: 2026-09-05

---

🛠️ Project Origins

This endeavor began in April 2020, coinciding with the onset of the global pandemic. At the time, I was uncertain about the duration of either the lockdown or the project itself. I was driven by a simple curiosity: Why had no one attempted this specific upgrade yet?

At the project's inception, my technical profile was heavily skewed toward software (which I'd been tinkering with since age five), but I was a complete novice in other areas:

• Soldering: Zero experience.
• Reverse Engineering: Zero experience.
• Hardware: Limited to basic "Adafruit-style" Arduino projects.

I severely underestimated the magnitude of this challenge, primarily because I was essentially learning the entire discipline of hardware modification from the ground up. However, looking back, the struggle was unnecessary entirely worth it.

🔍 The Core Problem

Many enthusiasts have documented upgrading iPod Classics to massive capacities—1TB, 2TB, or even 4TB. However, the 4TB mods often crash because the system lacks sufficient RAM to index that many tracks.

There is a fundamental difference in how these devices store data:

I naively assumed that swapping the NAND chip in a Nano would Just Work be a plug-and-play affair. I chose the 3rd Generation Nano (hereafter referred to as the n3g) for two reasons:

1. It was the latest revision to use a NAND chip with "legs" (TSOP), which felt slightly more attainable than BGA soldering.
2. It was the specific model I owned and loved during my childhood.

"People really loved their iPods—as evidenced by that Australian drummer/snake owner on YouTube who makes iPod content that isn't actually about iPods, simply because there's a limit to how much one can say about a music player."

The guts of the n3g, revealing the NAND chip.

❌ The "Red X" Failure

Using low-speed hot air, desoldering the chip was straightforward. My friend Wesley helped me with the first few attempts in his garage. I remember the anticipation as I waited for the "About" menu to display a glorious 16GB.

Instead, I was greeted by a Red X.

"This is it," I thought, only to realize the device was bricked.

I initially assumed the chip was simply unformatted and lacked an OS. However, iTunes couldn't even detect the device. Wesley, who has a background in embedded electronics, explained the likely culprit: Firmware Whitelists. The firmware likely contains a table of approved NAND IDs; if the installed chip isn't on that list, the system halts.

💻 The Reverse Engineering Journey

I became determined to patch the firmware to accept the new NAND. I started by researching the Rockbox n2g port and found a similar data structure:

struct nand_device_info_type {
    uint32_t id;
    uint16_t blocks;
    uint16_t userblocks;
    uint16_t pagesperblock;
    uint8_t blocksizeexponent;
    uint8_t tunk1;
    uint8_t twp;
    uint8_t tunk2;
    uint8_t tunk3;
} __attribute__((packed));

static const struct nand_device_info_type nand_deviceinfotable[] = {
    {0x1580F1EC, 1024, 968, 0x40, 6, 2, 1, 2, 1},
    {0x1580DAEC, 2048, 1936, 0x40, 6, 2, 1, 2, 1},
    // ... and so on
};

After scouring the n3g firmware and consulting with developers on the Rockbox IRC, I acquired some legacy reverse-engineering work. This provided me with the Rockbox bootloader, marking my first successful execution of custom code on the device on 7/13/2020.

The Pwnage 2.0 Exploit

To achieve unsigned code execution, I utilized the Pwnage 2.0 exploit. This targets a stack-overflow vulnerability within the ASN.1/DER certificate parsing logic of early Apple S5L8xxx BootROMs.

The technical breakdown: The parsing context, $\text{der::chain::parse\_ctx}$, is allocated on the stack. The saved link register ($\text{LR}$) is located at a predictable offset immediately following this structure. By crafting a malicious certificate with an oversized $\text{signatureValue}$, an attacker can overflow the buffer by approximately: $\Delta \text{buffer} \approx 344\text{--}345 \text{ bytes}$

This overwrites the $\text{LR}$ with a pointer to arbitrary shellcode, redirecting the BootROM to execute the payload.

⚙️ Analyzing the Bootloader

I discovered that the first stage of the firmware is an EFI bootloader. I was surprised to find EFI (Extensible Firmware Interface) in a handheld device, as I associated it with Macs and Apple TVs. While this made static analysis more cumbersome, I eventually traced the codepath to the NAND driver's initialization routine.

The initialization process follows this sequence:

• Check IDs of the NAND banks.
• Initialize buffer memory.
• Initialize the Virtual Flash Layer (VFL).
• Initialize the Flash Translation Layer (FTL).
• Open both layers.

The process was failing at the very first step—the ID check—which confirmed my theory about the whitelist. I then began the process of swapping out the...