Mass-Storage Import and Backup

The mass-storage personality (Product ID 0x41E2) carries two host-facing data flows: a one-way bulk import of credentials into the device, and an encrypted backup export off the device. This page documents the import file format down to the byte, the host-side import procedure, the device-side import flow, and the shape of the backup export file.

Import overview

When the user selects import on the device, it mounts a small FAT volume over USB mass storage. The host writes an import file onto that volume; the device parses the file as a fixed array of credential records and stages them. The user then chooses a merge policy and commits.

Import is one-way and unattended at the record level: there is no read-back and no per-record confirmation. The user drives the whole operation from the device (selecting the mode, watching progress, resolving conflicts if interactive).

Note

Import is the right tool for loading a whole vault at once (up to the 500-entry store limit). To read credentials back, or to add them one at a time, use the USB-Slave Serial Protocol interface instead.

The FAT volume

While in import mode the device presents a FAT volume with:

• a volume label of SECLAVE (host tooling can detect the device by matching a FAT volume whose label ends with SECLAVE); and

• a single marker file named ``SCIMPORT.STE`` in the root directory.

The presence of SCIMPORT.STE on a SECLAVE volume is how a host recognizes a device that is ready to receive an import.

Note

The device reconstructs import records from the raw data blocks written to the volume; it keys off the record cookie (below), not off a filename. A host may therefore either overwrite SCIMPORT.STE or create its own file (historically seclave.imp) - both work, because the device intercepts the written data blocks regardless of which file they belong to. Filesystem metadata that the host OS writes automatically (for example macOS volume housekeeping files) is ignored, because those blocks do not carry a valid record cookie.

Import file format

The import file is a fixed array of exactly 500 records. Each record occupies 256 bytes: a 224-byte record structure followed by 32 bytes of zero padding. The total file size is therefore 500 * 256 = 128000 bytes.

Records that carry real entries come first; every remaining slot up to 500 must be present as an empty record (distinguished by its cookie). The device counts records until it has seen 500, so the array must be fully populated.

Record structure (224 bytes)

All multi-byte integers are little-endian. All string fields are fixed-width, Latin-1 (ISO-8859-1) encoded, and zero-padded on the right; they are not NUL-terminated when they fill the field exactly.

Offset	Size	Field	Notes
0	4	cookie	Record type marker. See the cookie table below.
4	16	label	Primary key. Must be non-empty and pass the label character set.
20	1	status	Write 0. Ignored on import; the device marks the stored entry valid.
21	8	group	Folder/category. May be empty.
29	50	username	Free-form.
79	50	password	Free-form.
129	83	optional	Free-form. Holds the domain for a web-password entry.
212	10	reserved (MAC)	Write zero. Not used for import.
222	2	reserved (offset)	Write zero. Not used for import.

Bytes 224-255 (the remaining 32 bytes of the 256-byte slot) are zero padding.

Important

The import file is plaintext - there is no checksum, MAC, or encryption to compute. The two reserved trailing fields (offsets 212 and 222) exist for internal record bookkeeping and must be written as zero; a client does not compute them. The device validates only the label of each record (it must be non-empty and use the allowed character set); group and the remaining fields are stored as written.

Cookie values

The 4-byte cookie at offset 0 identifies the record type. A client uses two of them:

Cookie	Bytes	Meaning
Import record	08 F3 24 00	This slot carries a credential to import.
Empty record	08 F3 25 00	Unused slot; fills the array out to 500 records.

Any slot whose cookie is neither of these is skipped and does not count toward the 500-record total; write empty records (not arbitrary zero bytes) for the unused tail.

Field limits and truncation

The field widths in the record are the hard maximums (label 16, group 8, username 50, password 50, optional 83). A host writer should truncate or reject over-long inputs before packing them, since the fixed-width slots cannot hold more. Enforce these limits and warn the user rather than silently losing data.

The label character set is the same as elsewhere on the device: ASCII letters, digits, _, -, ., and the fixed Latin-1 accent set (æ Æ å Å ä Ä ö Ö ø Ø ü Ü ß). A record with an invalid or empty label aborts the whole import (see the failure cases below). Labels are unique across the store; a host writer should de-duplicate labels (case-insensitively) before export.

Worked record example

A single import record for label gmail, group web, username alice, password s3cret, empty optional (offsets shown in decimal; .. denotes a run of zero padding to the field width):

off 0    08 F3 24 00                          cookie = import record
off 4    67 6d 61 69 6c 00 00 00 ..           label    "gmail"  (16 bytes, zero-padded)
off 20   00                                   status = 0
off 21   77 65 62 00 00 00 00 00              group    "web"    (8 bytes)
off 29   61 6c 69 63 65 00 ..                 username "alice"  (50 bytes)
off 79   73 33 63 72 65 74 00 ..              password "s3cret" (50 bytes)
off 129  00 ..                                optional ""       (83 bytes)
off 212  00 00 00 00 00 00 00 00 00 00        reserved (MAC)    (10 bytes, zero)
off 222  00 00                                reserved (offset) (2 bytes, zero)
off 224  00 .. (32 bytes)                     slot padding to 256 bytes

Host-side import procedure

A host importer performs the following steps:

1. Ask the user to put the device into import mode and choose the merge mode on the device.

2. Locate the device. Enumerate mass-storage volumes and find a FAT volume whose label ends with SECLAVE and whose root directory contains SCIMPORT.STE.

3. Validate the entries. Enforce the field maximums, the label character set, and label uniqueness (case-insensitive). Reject or truncate as appropriate, and warn the user about anything that had to be changed.

4. Write the import file. Pack each entry into a 256-byte record with the import cookie 08 F3 24 00; then fill every remaining slot up to 500 with an empty record (cookie 08 F3 25 00). Write the bytes to the volume (overwriting SCIMPORT.STE or creating a new file such as seclave.imp), using Latin-1 encoding for all string fields.

5. Flush and let the device finish. The device shows import progress and, when done, asks the user to eject and confirm.

A password-manager plugin implementing exactly this procedure is shipped as the first-party KeePass integration; it discovers the volume by the SECLAVE label plus SCIMPORT.STE, writes seclave.imp in Latin-1, packs the record exactly as above, and pads the array to 500 records.

Device-side import flow and merge modes

Before the transfer, the user chooses a merge mode on the device. This governs how a record whose label already exists in the store is resolved when the staged import is committed:

Mode	Behavior on a label that already exists
Interactive	The device prompts per conflict and lets the user keep either the existing (device) entry or the imported one.
Merge	The existing (device) entry is kept; the imported record is discarded.
Overwrite	The imported record replaces the existing entry.

After the mode is chosen, the device reads the whole 500-record array, stages valid records, then commits them under the selected mode. Progress is shown on the device; when the transfer completes it asks the user to eject the volume from the host OS and confirm.

The merge-mode menu shown when the user starts an import on the device.

After the mode is chosen the device presents the FAT volume and waits for the host to write the import file. This is the state a host importer should tell the user to put the device in before it looks for the SECLAVE volume.

Import failure cases

The import aborts (and stages nothing) if:

• a record’s label is empty or contains an invalid character - the device reports an invalid-label failure; or

• the number of staged entries exceeds the 500-entry store capacity - the device reports a no-space failure.

A host importer should pre-validate to avoid these, since the device abandons the entire import rather than skipping the offending record.

Backup export

The mass-storage personality also exposes the device’s encrypted backup as a file named ``SECLAVE.BKP`` on the presented FAT volume. When the user selects backup export on the device, the volume presents SECLAVE.BKP with a size of 256 * 501 = 128256 bytes (500 record slots plus one trailing header, at 256 bytes each). A host reads the file off the volume and stores it.

The device while presenting the backup volume. SECLAVE.BKP is readable on the host until the user presses the joystick to leave the mode.

Note

SECLAVE.BKP is an opaque encrypted archive. Its internal record format is not part of any public interface, and a client must not attempt to parse or modify it. A backup is restored only on a Seclave device (through the device’s restore flow, which reads the archive back from the mass-storage volume) using the backup key that protects it. The same archive content is also available record-by-record over the serial protocol via GET_BACKUP; see USB-Slave Serial Protocol.

For a host tool, treat the backup as write-through bytes: copy SECLAVE.BKP to storage on export, and copy it back to the device’s restore volume on restore. Do not interpret its contents.