Project Details

Hardware Specs

First let's take a look at the motherboard. There's the Samsung S5L8702 SoC (ARM926EJ-S Processor), 256Mb/32MB mobile DDR SDRAM, 8Mb/1MB Utility NOR Flash, the WM1870 Wolfson DAC, the D1671B Power Manager and finally the MLC Nand Flash.

In my unit it's a Toshiba TH58NVG5D1DTG20 and after a quick search I found a naming scheme diagram. It's a 3.3V, 32Gbit/4GB and 8-bit wide MLC NAND, so pretty standard.

From a hardware perspective the upgrade is quite feasible.

Rockbox NAND Table

But it can't be that easy right? No.. Of course not, well maybe. Sadly there is no rockbox and/or ipodlinux port for the third gen.
Weird because we already have code execution and a port for the same SoC (Classic 6G Port).

After some digging in the rockbox source code I found a NAND driver for the second gen iPod Nano. It's based on the same SoC family (S5L8701), so we have an idea how they implemented it.
There's a list of DeviceIDs, Blocks, Identifiers e.t.c. It determines the size of the NAND and the partition that will be allocated.

iPod Partition Scheme

The iPod has two partitions.
A hidden system partition where the bootloader and the Realtime Operating System is stored and a Fat32/HFS partition for storing media.
What if a similar method is used in the original firmware? Since there's no Rockbox port we'd need to decrypt the raw firmware image and hack it.

Hardware Hacking

But back to the hardware part. I decided to desolder the NAND and solder a TSOP-48 breakout board to test various NAND ICs and maybe tap into it.
And here is the process of me soldering 0.15mm enamelt magnet wire to an 0.5mm pitch TSOP footprint. Keep in mind to leave the magnet wire as short as possible to avoid interference.
A time consuming process but at the end it looks very cool.
     Now to the NAND IC selection. I actually have access to the Micron Confidential Datasheets (Makes it much easier). First we don't know if we have a software limitation in the stock firmware then we have to understand the ONFI (Open NAND Flash Interface) TSOP pinout.
It's an 8-bit wide multiplexed bus with additional Chip Enable and Ready/Busy signals. The amount of Chip Enable and Ready/Busy signals determine the maximum addressable capacity.
     The 3rd gen Nano has four CE and R/B signals, as does the ipod nano 2g and 1st gen. The chips come stacked, dual config, single config and in the case of the Ipod Nano 1g it comes with a daughter board, this is most likely due to chip availability to Apple at the time of manufacture. in dual stacked configs 2 of the rb and ce legs are cut and the ce and rb re routed on different legs. Some of the hynix chips come with 4ce and 4rb. The a maximum addressable capacity of 512Gbit/64GB  (only NAND Flash with one or two or 4 CE signals will work).

Firmware

If you extract the .IPSW firmware image you have the following files: OSOS.fw, aupd.fw and rsrc.fw. The OSOS file has a 512 Byte Header, 1536 Bytes of Zeros and the encrypted payload. There are 8 markers (offsets) that are enabled by default. When disabled (and the key retrieved) you can decrypt the payload with the RC4 decrypton method. But this only works on aupd.fw. OSOS.fw needs a 2nd key. It's in the SoC's internal Flash (AES CBC 128). There is an overflow exploit that let's you dump the SoC's flash and the NOR utility flash.

Progress (Updated 05.05.2021)

Tucker made a video detailing his progress on interacting with new NAND chips from the iPod's EFI Firmware. A summary of his findings are below:

Despite being able to read the new NAND's ID and finding a new entry in the allowable NAND table, the FMI (Flash Media Interface?) refuses to read or write to the NAND. Early on in NAND initialization, there's a function that tries to format the chip by writing data structures and attempts to verify them by reading them back. Yet the verification step is failing because the read function always seems to return a buffer full of FFs. It is possible that this is from the NAND itself (in which case we are able to read but not write), or it is a fail state from the FMISS layer (in which case we can currently do nothing with the chip). The FMISS is this mysterious spooky layer that communicates with the chip async from the code and fires an interrupt when done. We don't know what goes on in the FMISS layer. It runs this state machine bytecode that we don't fully understand. Tucker started reverse engineering the FMI's state machine's bytecode, but progress is slow and is mostly guesswork, so there is still very little confidence in understanding what's actually being performed at this level.

Error correction is likely handled in the FMISS layer itself (either in hardware or the bytecode execution), but we would expect the write functions to return an error if it fails. All read/write functions return success. So the fact that the read methods are returning all FFs doesn't seem to bother this layer which may indicate that the contents are indeed actually coming from the NAND itself. Signal level debugging is required to ascertain if this is actually true or not.

Tucker is using the Rockbox bootloader written by the community to apply a patch to the original EFI firmware to modify the behavior of the NAND driver. He is changing ARM instructions so that he can return any value and see it in the diagnostic NANDLba field. This is how he knows he can read the NAND ID and how he could tell the buffer was just FFs and other arbitrary debug data bubbled up from various places in the EFI.