Under the Hood: The OS and Filesystem

Before enabling developer mode and reaching for an SSH prompt, it pays to understand what you are connecting to. The reMarkable Paper Pro is not a locked-down appliance with a bespoke firmware blob; it is a regular Linux system with a normal userland, a single dominant application, and documents stored as plain files on disk. This section maps that terrain: the operating system, the silicon and storage it runs on, how a notebook is actually laid out in the filesystem, and why the whole platform remains open to modification despite the security hardening the Paper Pro introduced.

reMarkable OS: "Codex"

reMarkable OS is a custom, lightweight Linux distribution carrying the internal codename Codex. It is assembled with The Yocto Project, the same toolchain used to build embedded Linux distributions across many hardware architectures. The practical consequence is important: the result is a *regular* Linux distribution, so the device boots a standard kernel, runs systemd as init, and exposes an ordinary POSIX userland. Anything you know about administering a small Linux box largely transfers here.

The user-facing interface is drawn by a single proprietary, closed-source application named xochitl. It is a Qt application, and rather than talk to a display server or window manager, it renders directly to the framebuffer that drives the e-paper panel. It runs as a systemd service, which means it can be stopped and started like any daemon:

systemctl stop xochitl    # frees the framebuffer and pauses the UI
systemctl start xochitl   # relaunch the notebook interface

On an encrypted device xochitl also participates in device unlock. Because it holds the framebuffer, stopping it is the prerequisite for most third-party framebuffer apps and screen-sharing tools.

Figure 6.1: The reMarkable OS software stack, from aarch64 hardware up to the xochitl UI

Silicon, Storage, and Partitions

The Paper Pro is a 64-bit (aarch64) device, a generational shift from the 32-bit (armv7l) reMarkable 1 and 2. That change matters for anyone cross-compiling binaries: toolchains and prebuilt utilities must target aarch64, not the older 32-bit ARM.

Note that reMarkable has not published the exact SoC part number, and no detailed public teardown (iFixit or TechInsights) of the Paper Pro exists yet, so the precise silicon and flash vendor remain unconfirmed. For context, the smaller Paper Pro Move uses an NXP i.MX93, placing the Pro family on NXP's i.MX line.

The filesystem separates a writable home partition (/home) from a read-only root partition (/). User data and config flags live under /home and can be changed freely; to modify the OS or its applications you must remount root read-write, and the change reverts on reboot:

mount -o remount,rw /      # make the root filesystem writable (temporary)

The Document Bundle Format

Every notebook, PDF, EPUB, and folder lives under the xochitl data directory, each identified by a UUID and stored not as one file but as a *bundle* of sidecar files sharing that UUID as their base name:

/home/root/.local/share/remarkable/xochitl/
├── 9f8e...c2a1.metadata      # JSON: visibleName, type, parent, deleted, pinned
├── 9f8e...c2a1.content       # JSON: page order, tool/drawing settings
├── 9f8e...c2a1.pagedata      # template name per page (one per line)
├── 9f8e...c2a1.local         # 4-byte "{}" local-state marker
├── 9f8e...c2a1.pdf           # original imported document (if any)
├── 9f8e...c2a1/              # directory of per-page stroke files
│   ├── <page-uuid>.rm            # vector stroke data for one page
│   └── <page-uuid>-metadata.json # that page's layers/metadata
└── 9f8e...c2a1.thumbnails/   # ~280x374 JPEG previews for the library grid

The .metadata JSON records display name, item type (DocumentType for notebooks/PDFs, CollectionType for folders), the parent folder UUID, plus deleted and pinned state. The .content JSON is tolerant of missing fields. Since firmware 3.5, permanently deleted items get a .tombstone file instead of the old "deleted": true flag.

Figure 6.2: A single UUID document bundle fanning out into its sidecar files and per-page stroke directory

The .rm Vector Format

The per-page .rm files (formerly .lines) hold all vector detail of handwriting and drawings in a proprietary, reverse-engineered binary format. The current v6 format arrived with firmware 3.0 (late 2022); community parsers typically cover v3 through v6. v6 is structured as a SceneTree of typed Block structures (layers, lines, text, glyph ranges, scene info) and supports typed text with bold/italic formatting (FW 3.3+) and PDF highlight GlyphRange items (FW 3.6+).

Because the Paper Pro is a color device (E Ink Gallery 3), its content exercises the format's color fields more fully than any monochrome predecessor. Tooling worth knowing includes rmscene (read v6, Python), rmc (convert to/from v6), remarkable-lines (Rust parser), and a Kaitai Struct spec, rmv6.ksy.

Why the Platform Is Hackable

The platform stays open for a structural reason: it is ordinary Linux with documents in accessible files, so once you have root you can read, back up, transform, and script your data with standard tools. The Paper Pro does add hardening the older models lacked — secure boot (verifying bootloaders, kernel, and root filesystem) and full-disk/filesystem encryption at rest and in transit. Crucially, enabling developer mode disables most of secure boot to permit SSH and rootfs changes, but never disables disk encryption, and the pre-kernel boot chain remains protected so the device can always revert to a secure state. The trade-offs of that switch, and the SSH mechanics that follow, are the subject of the next section.