Skip to content
HN On Hacker News ↗

16GB iPod Nano 3G Upgrade

▲ 167 points • 32 comments • by Ivoah • 2w ago • HN discussion ↗

Pangram verdict · v3.3

We believe that this text is a mix of AI and human-written content.

11 %

AI likelihood · overall

Mixed
89% human-written 11% AI-generated
SEGMENTS · HUMAN 1 of 2
SEGMENTS · AI 1 of 2
WORD COUNT 930
PEAK AI % 98% · §2
Analyzed
Sep 26
backend: pangram/v3.3
Segments scanned
2 windows
avg 465 words each
Distribution
89 / 11%
human / AI fraction
Verdict
Mixed
Pangram v3.3

Article text · 930 words · 2 segments analyzed

Human AI-generated
§1 Human · 1%

Watch the first video I first had this project idea in April of 2020 at the beginning of the pandemic. I didn't really know how long it would be (the project or the pandemic) and I was curious why nobody had tried this before (the project, not the pandemic). At this point, I had no soldering experience, no reverse engineering experience, and while I'd been working with software at some level since I was five years old, to this point I had very little hardware experience outside of working with Arduinos at a very "Adafruit" maker level. I didn't realize how big of a challenge this would be, mainly because I was learning everything from scratch. But now that it's done, I can confidently say that it was worth it. It took longer than it should have, but give me a break. An Introduction To The Problem You've probably seen some videos on YouTube of people upgrading the storage in their iPod Classics, pushing it to 1TB, 2TB, and 4TB (whereupon it fails, since it runs out of RAM to handle that many songs). While I wouldn't call the hard drive in the large iPods "user serviceable", it certainly is compared to the NAND chips found in iPod Nanos, Shuffles, and everything else Apple makes now (with the exception of AirTags, I guess). I naively thought that swapping out the NAND chip in a Nano would be easy and it would simply Just Work™. I chose the iPod Nano 3rd Generation for two reasons. First, it's the newest revision of the Nano that has a NAND chip with legs (which was less out-of-my-league than BGA soldering but still out-of-my-league). Second, it's the Nano closest to my heart because it's the one I had growing up. I loved that thing. People loved their iPods - proven by the popularity of some Australian drummer and snake owner's YouTube channel about iPods that isn't actually about iPods because there is only so much content you can make about iPods. Taking apart any Nano is hell. It's possibly impossible to do it without destroying it. But, if you manage to get into the 3rd Generation Nano (which I will be referring to as the 'n3g' from here on out), you immediately see the NAND chip. The iPod's guts revealed for not the first time Desoldering it is easy enough with low speed hot air. Soldering it is less easy. The first few iPods were done by my good friend Wesley in his garage. Literally just in his garage "This is it," I foolishly thought as I held the camera waiting to see that blessed 16GB in the "About" section of the iPod UI. But no. What we got instead was the dreaded Red X. The Red X Standing in Wesley's garage, I thought this meant "this chip is unformatted, where's my operating system?" which made sense to me. I tried recovering the iPod and found that iTunes couldn't even see it. Wesley has experience in embedded electronics, and explained that usually there's some sort of table of acceptable NAND in the firmware and, if the chip isn't found in that table, it just stops. I went back home determined to figure out what was going on and mod my way into getting this thing to work. How hard could it be? I just have to find the table and patch it out with the details of the NAND chip, right? My first discovery confirmed Wesley was right. I found a similar table in Rockbox's n2g port: 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}, {0x15C1DAEC, 2048, 1936, 0x40, 6, 2, 1, 2, 1}, {0x1510DCEC, 4096, 3872, 0x40, 6, 2, 1, 2, 1}, {0x95C1DCEC, 4096, 3872, 0x40, 6, 2, 1, 2, 1}, ...and a lot more... }; This table had to come from somewhere, obviously, so I needed to find where the n3g's version was in its firmware. It turns out an almost identical table shows up in several places across the n3g firmware. After doing some research and talking to some people in the Rockbox IRC channels, I inherited some half-done reverse engineering work from some developers who, years prior, were trying to port Rockbox to the n3g. This included the Rockbox bootloader and led to my very first success in getting code to run on the iPod. I knew code execution would be the first real hurdle, and the fact that someone had already done this was a huge step in the right direction. The first time I got the Rockbox Bootloader running on 7/13/2020 (I was very excited) The Rockbox bootloader uses the Pwnage 2.0 exploit to run code. You can read more about it here and here, but it's basically a stack-overflow exploit targeting a bug in the ASN.1/DER certificate parsing logic of early Apple S5L8xxx BootROMs.

§2 AI · 98%

Because the entire certificate chain parsing context (der::chain::parse_ctx) is allocated on the stack, and the saved link register (LR) sits at a known offset just past the end of that structure, an attacker can craft a malicious last certificate whose oversized signatureValue overflows the buffer by 344-345 bytes, overwriting the saved LR with an attacker-controlled address. The attacker can place arbitrary executable shellcode there, and the overwritten return address simply redirects execution to that payload, achieving full unsigned code execution at the BootROM level.