Storage

The Zune HD keeps everything on internal managed NAND: the bootloader, the OS image, user content, and the DRM store. The 32 GB model pairs two Toshiba NAND packages with a Phison PS8006 controller, and the 16 GB model uses Hynix NAND.¹ That controller presents the NAND to the SoC as a single eMMC device and handles wear levelling, ECC, and the flash translation layer, so the OS sees plain logical-block storage with no raw NAND exposed. The eMMC interface reports as revision 1.2, eMMC 4.2. This page covers the partition topology, the mount points, the driver stack, and what the hardware does and does not expose. Topology and mount contents were read from a live 4.5 device. Anything not confirmed on the device is marked.

Partitions

CE's storage manager sees the eMMC as one store, DSK1: (store name eMMCFlashDisk), holding three partitions. Read live:

Partition	Filesystem	Volume	Size	Mount
Part00	zbinfs	ZBINFS	128 MiB	\Windows\
Part01	zexfat	Flash	128 MiB	\Flash\
Part02	zexfat	Flash2	30,440 MiB	\Flash2\

The store reports 15,716,608 sectors of 2048 bytes, 29.977 GiB. The three partitions sum to that total within about 80 KB, so there is no unlisted partition inside the addressable area. A separate 1 MiB RAMDisk store also appears in the storage manager. It is volatile scratch space, not part of the eMMC.

zbinfs is the read-only Zune binary filesystem that backs the OS image. zexfat is the read-write Zune exFAT variant used for the two data partitions. The filesystem driver is chosen per partition from a field in the partition record, not from the MBR type byte.

What each partition holds

• \Windows\ is the OS image from Part00, read-only and presented as a RAM-backed shadow that resets on reboot. This is the \Windows\ view described in the platform overview.
• \Flash\ is small and persistent. On a live device it holds zconfig.dat, zver.dat, and FWUpdate_LastError.dat: device configuration, a version stamp, and the last firmware-update error.
• \Flash2\ is the large user-data partition. It holds the device certificate (devcert.dat), the DRM store (drmstore.dat), the media database (zunedb.dat, with a .BAK), and the Content, Browser, and DNCache directories. On a modded device it also carries \Flash2\automation\, where the platform stages its boot files.

On-disk layout

Sector 0 of DSK1: is a DOS-style master boot record with one populated entry: an extended partition (type 0x05) that spans the user area from LBA 16. The three partitions the storage manager returns are logical partitions chained as extended boot records inside it. That is why the device exposes three partitions from an MBR that lists only one. The logical entries carry type bytes 0x21 for the zbinfs OS partition and 0x07 for the two zexfat data partitions.

The storage manager reports 2048-byte sectors, which is the block driver's logical sector size. The eMMC underneath uses 512-byte native blocks, the standard eMMC block size, and the driver folds four of them into each logical sector.

The driver stack

Storage is reached through a standard CE 6 block-storage stack, with a Tegra-specific bottom driver and a small Zune-custom partition and filesystem layer:

Layer	Module	Role
Block driver	libnvemmc.dll	The DSK*: stream driver over the NVIDIA SDMMC DDK.
Partition	zpartstream.dll, mspart.dll	Zune partition-stream layer over the MS-partition (MBR) driver.
Filesystem	zbinfs.dll, zexfat.dll	Read-only OS image and read-write data filesystems.
Dispatch	fsdmgr.dll, filesys.dll	CE filesystem-driver manager and kernel filesys.
Application API	coredll.dll storage-manager exports	FindFirstStore, OpenStore, FindFirstPartition, and the file APIs.

The CE-standard sdmemory.dll and sdbus.dll are not loaded, matching the absence of a removable-card path. Inside libnvemmc, DSK_Read is a stub. All input and output, sector reads included, goes through DSK_IOControl.

The rest of the eMMC

An eMMC can carry dedicated boot and RPMB partitions alongside the user area, physically separate from it and reached by switching the controller's PARTITION_ACCESS. This device has none of them. Its EXT_CSD, read with CMD8 SEND_EXT_CSD, settles it directly: BOOT_SIZE_MULT, RPMB_SIZE_MULT, and every GP_SIZE_MULT read 0, and a zero size multiplier means the region is not provisioned. EXT_CSD_REV reads 2, which the JEDEC table maps to revision 1.2 (eMMC 4.2), a part older than the boot-partition feature (eMMC 4.3) and the RPMB and general-purpose features (4.4), consistent with all three being absent. The 30 GiB user area is the entire addressable eMMC. Reading EXT_CSD on this controller takes some work, covered in Storage internals.

CE does not map the whole user area. The card's EXT_CSD SEC_COUNT is 63,307,776 native 512-byte sectors, 30.19 GiB, while CE's store is 62,866,432 native sectors, 29.977 GiB. The 441,344-sector difference, 215.5 MiB, is a reserved region at the front of the card. A DSK1: read of logical sector 0 reaches the eMMC as a CMD18 for native block 441,344, so the driver maps the store 441,344 blocks in, and 441,344 plus the store size equals SEC_COUNT exactly. Native blocks 0 through 441,343 sit ahead of everything CE exposes.

That region holds the device's boot and recovery firmware, read by hooking the SDMMC driver and remapping a DSK1: read down into it (described in Storage internals). A 2 KiB signed header, a PKCS#7 signedData catalog that names the device model Pavo and carries a 2011 signing date, is repeated 24 times across the first 3 MiB, one copy every 128 KiB. A Tegra boot configuration table (the block carries BCT tags) and a 651.5 KiB encrypted bootloader follow near 3 MiB, with a second copy of the bootloader near 6 MiB. The bootloader matches the firmware package's ZBoot stage: unpacked, ZBoot.bin is the same size, and it is the only encrypted payload in the region. Two identical copies of a 12 MiB Windows CE image sit near 9 MiB and 77 MiB. This is a v4.5 boot and recovery image, not byte-identical to either the firmware package's NK.bin or Recovery.bin but matching them module for module save six modules and the pointer relocation a different ROM layout requires. It carries the Tegra WOOKIE board-support strings, the NVIDIA bootloader (NvBl), and the CE kernel (kernel.dll, kitl.dll, coredll.dll). A 30 MiB Windows CE image with networking (RNDIS, RAS) begins near 144 MiB. About 55 MiB of the 215 MiB is content; the space between components is erased or zero. The component identities and the module comparison are in Storage internals.

The DRM device-binding keys live in the \Flash2\ files: the public device certificate in devcert.dat, and the private key material in drmstore.dat. The wmdrm.dll module that handles them imports only coredll and reads no Tegra fuse [static]. The SoC's OTP fuses hold the separate secure-boot keys, a distinct key hierarchy from the content DRM. The bootloader is encrypted, and reading the fuse block back, the rows that hold its key material return all-ones, the read-locked state; the key is burned but not software-readable, so the bootloader cannot be decrypted off the device.

Reading raw sectors

The read and write IOCTLs this firmware uses are not the values CE's public headers suggest. The read code is 0x75C08 (CTL_CODE(7, 0x702, BUFFERED, FILE_READ_ACCESS)), recovered from fsdmgr's disk-read helper. The write code is 0x79C0C. The historical IOCTL_DISK_READ value 0x75400 is not in the driver's dispatch table at all.

A raw read opens DSK1: with CreateFile and calls DeviceIoControl with the read code and an SG_REQ structure: a 20-byte header (start sector, sector count, scatter-gather count, status) followed by one 8-byte descriptor per buffer. The topology on this page was enumerated through the storage manager's own FindFirstStore, OpenStore, and FindFirstPartition walk, filling a 240-byte STOREINFO and a 296-byte PARTINFO per call. On this build OpenStore takes a single argument and returns the handle directly, not the two-argument form some CE references show.

The storage manager rejects these calls when they come from the kernel-call context and requires a normal user-mode thread. Lyra reaches them through its runtime rather than the kernel trampoline, which the Lyra runtime reference covers.

The exact IOCTL dispatch tables, the STOREINFO and PARTINFO byte layouts, the storage-manager export addresses, and the SoC register map are collected in Storage internals.

---

1. Microsoft Zune HD teardown, iFixit. ↩