Backing up the eMMC before touching anything

I promised myself one rule at the start of this project: before doing anything to the actual device that isn't trivially undoable, I would have complete, verified backups of everything involved — both the board's storage and the keys I generated in the last post. This post is about how that actually went, including a puzzle that cost me more time than I expected.

Backing up the eMMC, without needing a network

The board has a serial console port for normal use, and a separate port that turns into a plain USB storage device once you type one command at the bootloader prompt. That second part turned out to be the easy way to pull a full copy of the storage onto my laptop, without needing the device to have network access at all — just a USB cable and dd on the receiving end.

The main storage area (about 29 GB) came across in under fifteen minutes, piped straight through gzip to keep the resulting file small. I didn't just trust that the copy command finished without an error, though — I actually decompressed the whole thing again afterward to make sure it wasn't secretly truncated somewhere in the middle, and recorded a SHA-256 fingerprint of the final file, so that months from now I (or anyone else) can check "is this still exactly the same file" with one command instead of a guess.

The part that actually tripped me up: the two tiny boot partitions

Alongside the main storage, there are two very small (a few megabytes each) hardware partitions that hold the actual bootloader image and its environment variables. Backing up the big main storage area didn't touch these at all — they live somewhere else on the chip entirely, addressed differently.

My first attempt at reaching them gave me a result that looked plausible but was actually wrong: I got a partition back, but it was the wrong size — way too big for what should have been a few megabytes. Turned out I was using the wrong kind of address entirely. There are two completely different things you can mean by "partition 1" on this hardware:

• A GPT/MBR table entry — the normal kind of disk partition you'd think of.
• A hardware partition baked into the eMMC chip itself, at a lower level than any partition table.

I'd been asking for the first kind, when I actually needed the second kind. Once I used the right syntax for "give me hardware partition number one" instead of "give me table entry number one," the correct, tiny, exactly-the-right-size boot partition showed up immediately, and the second one right after it. Both took well under a second each to copy, compared to the fifteen minutes for the big one — they really are tiny.

It's a small, almost silly-sounding mixup in hindsight, but it's exactly the kind of thing where reading the actual debug output the board prints (which very plainly told me which of the two addressing schemes it was using each time) saved me from just guessing blindly. Worth remembering for next time I'm anywhere near this kind of low-level storage addressing.

All three pieces — the big storage area and both tiny boot partitions — ended up backed up and independently verified with their own fingerprints before I moved on.

Backing up the keys themselves

The keys from the last post needed a different kind of care. The private keys sit on disk with quite restrictive file permissions — only my own account can read them at all. A plain copy to another machine can easily lose that restriction, depending on the settings of whatever's receiving the copy. So instead of copying the folders directly, I packed everything into a single compressed archive first. That specific archive format actually stores each file's permission bits inside itself, so unpacking it anywhere reproduces the original, tightly locked-down permissions — regardless of the receiving machine's own default settings.

I moved that single archive to a completely separate machine, checked its fingerprint matched exactly, and then made a second, genuinely separate copy somewhere else entirely — not just "two places on the same two computers I already use every day," which wouldn't really be two independent backups at all.

I also wrote myself a note about how to properly restore this archive later, whenever that day comes — specifically, how to check afterward that the permissions actually came back correctly, and what to do if some other unpacking tool doesn't preserve them the way the right one does. Backups you've never practiced restoring aren't really backups yet, in my opinion, so I wanted that process written down clearly while it was still fresh.

With all of that done — board storage backed up in three pieces, keys backed up in two genuinely separate places, everything verified rather than assumed — I finally felt comfortable moving toward the parts of this project that actually build and sign something real. That's the next post.