10.2. Splash partition¶

The splash partition (lun4/splash.bin, 32.6 MB, 8356 × 4 KB sectors) is entirely 0x00 in this dump — empty by design. The boot and charging imagery does not live in any flash partition; it is embedded in XBL (xbl_a.bin), because XBL disables splash-partition loading as a security measure.

10.2.1. Blank partition¶

Every one of splash.bin’s 8356 blocks is zero, verified three ways:

4 KB non-zero-block scan: 0 / 8356 non-zero.
cmp against an all-zero blob of identical size: identical.
SHA256 = efd199079045…443d7a6e equals the SHA256 of a same-size zero blob and equals the value recorded in ../_READONLY/SHA256SUMS. The dump is faithful; the partition is empty.

There is nothing to decode or extract from splash.bin — no header, no image, no format.

The “Blank (all-0x00) partitions” list in Partition map and checksums (keystore, catefv, cdt, fsc, storsec, dip, toolsfv, catecontentfv) also includes splash. splash is grouped separately only because its all-zero hash is unique to its size (32.6 MB) and therefore not clustered with the shared 512 KB / 1 MB zero-hash groups.

10.2.2. Why it is blank: XBL disables splash-partition loading¶

XBL (xbl_a.bin) treats loading an image from the splash partition as an attack surface and turns it off:

## NOTE: Enabling splash partition is a security risk ##
EnableSecurityHoleForSplashPartition = 0x0

With that flag 0, XBL never reads or paints from the splash partition, so the OEM leaves it empty. The likely motive (general security reasoning about the vendor’s intent, not a documented OEM statement) is that a populated splash partition is generally a pre-auth image-parser attack surface, and disabling it avoids parsing untrusted image data before authentication — that inference is consistent with XBL’s own “security risk” comment and the EnableSecurityHoleForSplashPartition flag name above, but those two labels are as far as the OEM’s own documented reasoning goes; the specific attack-surface mechanism above is this analysis’s inference from them, not spelled out further anywhere in this dump.

10.2.3. Where the boot logo comes from: embedded in XBL¶

XBL references its logos as internal files, not the partition:

logo1.bmp   logo2.bmp
MDPSystem: Display_Utils_GetContinuousSplashInfo failed.
/reserved-memory/splash_region

The images are stored inside the XBL DXE firmware volume and painted via the MDP continuous splash path into the splash_region reserved memory, which ABL then preserves and hands to the kernel (ABL strings: Backup the boot logo blt buffer, Splash memory region before/after updating, Could not get splash memory region node).

10.2.3.1. Extracted logos¶

Three 8-bpp (256-color palette) BMPs — palettized, e-ink/grayscale-friendly but retaining the Boox brand orange:

File	Dimensions	Content
`../artifacts/splash/xbl_logo1.{bmp,png}`	120×473 (portrait)	BOOX wordmark (rotated 90° for panel orientation), with an orange accent on the “X” — the boot splash.
`../artifacts/splash/xbl_logo2.{bmp,png}`	480×520	Charger + battery + charging bolt (“connect charger” graphic).
`../artifacts/splash/xbl_logo3.{bmp,png}`	446×300	Battery + charging bolt + power symbol (low-battery / charging indicator).

logo2/logo3 are the charging-screen graphics used by the XBL/charger UI (QcomChargerApp, see Physical keys: power, volume, and the boot-mode dispatcher, PMIC reset timers, charging and reachability); logo1 is the brand splash. All three render on the color e-ink panel via the MDP framebuffer handed forward through ABL.

10.2.4. A second boot-UI asset volume: `imagefv_a`¶

imagefv_a.bin (LUN4, 2 MB partition, 0x80000/512 KB payload) is a separate signed firmware volume from XBL’s own embedded logos above — its own MBN/ELF32 envelope (test-key cert chain, Secure boot and image signing) wrapping a single data segment (entry 0, i.e. data, not code). The payload is a UEFI Firmware Volume in its own right: it carries the _FVH header with the standard EDK2 FFS2 GUID (8c8ce578-8a3d-4f1c-9935-896185c32dd3) and FvLength 0x80000. It holds one FIRMWARE_VOLUME_IMAGE FFS whose single LZMA-GUIDed section decompresses (720 KB) to a nested FV of 9 ``FREEFORM`` files, each a Windows BMP — a second, distinct boot-UI symbol set from the xbl_logo{1,2,3} graphics above. By their VERSION strings: Battery_symbol_Soc10, …_NoBattery, …_Nocharger, …_LowBattery, …_LowBatteryCharging, …_DebugBoot, …_DebugStay, and Sens_thermal_symbol / Sens_thermal_err_symbol — the battery / charger / thermal glyphs XBL draws in charger-mode and low-battery/thermal states. The DebugBoot/DebugStay glyphs pair with the boot-mode entry in Physical keys: power, volume, and the boot-mode dispatcher. imagefv carries no executable DXE — it is a signed image-asset volume only. The partition is 2 MB; the rest is pad.

Both volumes feed the same charger-mode UI, from separately signed sources.

10.2.5. Artifacts¶

../artifacts/splash/xbl_logo{1,2,3}.bmp (carved) and .png (converted) — the boot/charging logos.

10.2.6. Provenance¶

Source:: ../_READONLY/lun4/splash.bin (READ-ONLY); xbl_a.bin; decompressed XBL DXE FV (/tmp/boox_xbl/dxe_fv.bin). Extracted logos in ../artifacts/splash/.
Method:: Zero-scan of splash.bin (per-4 KB block + cmp + SHA) confirmed blank; searched xbl_a.bin for splash/logo strings (found the disable flag and logoN.bmp names); scanned the decompressed XBL DXE FV for BMP headers (magic BM, reserved==0, DIB∈{40}, sane W×H×bpp), carved 3, sips to PNG.
Cross-refs:: Partition map and checksums (blank-partition list), Boot image: kernel, DTB, ramdisk, config, Physical keys: power, volume, and the boot-mode dispatcher, PMIC reset timers, charging and reachability.