================= 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. 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 :doc:`/partition-map` (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. 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. 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``). Extracted logos --------------- Three 8-bpp (256-color palette) BMPs — palettized, e-ink/grayscale-friendly but retaining the Boox brand orange: .. list-table:: :header-rows: 1 * - 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 :doc:`/boot/keys`, :doc:`/soc/pmic`); ``logo1`` is the brand splash. All three render on the color e-ink panel via the MDP framebuffer handed forward through ABL. 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, :doc:`/boot/secure-boot`) 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 :doc:`/boot/keys`. ``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. Artifacts ========= - ``../artifacts/splash/xbl_logo{1,2,3}.bmp`` (carved) and ``.png`` (converted) — the boot/charging logos. 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: :doc:`/partition-map` (blank-partition list), :doc:`/boot/boot-image`, :doc:`/boot/keys`, :doc:`/soc/pmic`.