Eufy HomeBase Encryption Weakness

Posted in Vulnerability disclosure by Jesper - 12 October 2026
  1. Home
    2. »
  2. Vulnerability disclosure
    3. » Eufy HomeBase Encryption Weakness

Eufy HomeBase .zxvideo Encryption Weakness

Foreword: This report is written by Claude, cause i was tired. This trick is known and used by others, im just making it all known, to make everyone aware. I own a Eufy Homebase S380, Eufy Indoor Cam C220 and a Eufy Indoor Cam S350, which has been tested and all videos and screenshots got decrypted. I dont do this to cause harm, im doing this to inform. Please don't hate me, pretty please!

1. Summary

Recordings stored locally by a Eufy HomeBase (.zxvideo files and their sidecar thumbnails and metadata) are protected by a stream cipher that reuses the same keystream for every file. The keystream is a fixed 4096-byte sequence XORed over the data and repeating every 4096 bytes; it is identical for every recording, identical across both cameras paired to the base, and does not change over time. Because recordings and their sidecar files contain large amounts of predictable content (JPEG thumbnail headers, JSON metadata, frame headers, H.264 and AAC structures), the keystream can be reconstructed from the files alone. An attacker who obtains the storage medium can then decrypt all stored video, audio, thumbnails and metadata.

No AES key, device credentials, account, or cloud access is required. Recovery used only commodity tools and a few minutes of computation, and was reproduced against two different firmware versions — the newer firmware changed the key but did not remove the weakness.

2. Affected products and scope

The finding concerns recordings written to the HomeBase local storage drive in the .zxvideo format, with per-recording sidecar files snapshort.jpg (thumbnail), recover.dat (JSON metadata) and raw_pic.dat.

Tested on the researcher's own equipment. The decrypted recover.dat identifies the device as:

Field Value
station_sn (HomeBase) T8030T2324450C69
device_sn (camera) T8W11… (prefix)
device_type 10008
Newer firmware tested 3.8.5.2 (build 09-02 03:28), subsystem 1.4.0.8

Both cameras paired to the base (Camera00, Camera01) share a single keystream. Two firmware versions were tested; each used one fixed keystream across all of its recordings. Anker/Eufy should confirm the full list of HomeBase and camera models that use this storage format, as the weakness is in the storage scheme rather than in any one camera.

3. Severity and classification

Impact: confidentiality. Full disclosure of all stored interior video and audio, thumbnails, and metadata (timestamps, device identifiers, storage paths).

Attacker model: read access to the HomeBase storage medium. No credentials, no account, no cloud access, no special hardware, and no interaction with a live device are required. The attack is fully offline.

Root weakness (CWE):

  • CWE-323: Reusing a Nonce / Key Pair in Encryption (keystream / two-time-pad reuse) — primary.
  • CWE-1204: Generation of Weak Initialization Vector (IV) — related, if the scheme is a counter mode with a fixed starting counter.
  • CWE-311 / CWE-312 effectively apply to the result: the data is not meaningfully protected at rest.

Severity rationale: a common, realistic event (loss of the physical drive) leads to complete compromise of highly sensitive data (continuous footage of a private home interior), with low attacker effort. This warrants a high confidentiality-impact rating.

4. Background: the .zxvideo format

A .zxvideo file is a sequence of length-prefixed frames. Each frame begins with a header starting with the ASCII magic XZYH (58 5A 59 48), followed by a type/command field, a 24-bit frame length, a timestamp, and type-specific fields. Two frame types are interleaved:

  • Video (type 0x14): H.264. The payload begins with Annex-B NAL start codes (00 00 00 01); keyframes carry SPS/PPS/IDR NAL units.
  • Audio (type 0x15): AAC-LC, 16 kHz, mono, carried as ADTS frames (sync word FF F?).

Each recording folder also contains:

  • snapshort.jpg — a JPEG thumbnail of the scene (standard JFIF/EXIF structure, same quantization/Huffman tables across captures).
  • recover.dat — JSON metadata with fixed field names and a SQL-like structure (start/end time, device and station serials, storage paths, mic_status, frame count, and more).
  • raw_pic.dat — a small JSON record.

All of these files are encrypted with the same keystream as the video, which is central to the weakness below.

5. Root cause

The on-disk protection behaves as a fixed keystream XOR. Three properties were observed directly:

  1. The keystream repeats every 4096 bytes. Within a single file, byte positions that are 4096 apart are encrypted with the same keystream byte. (Confirmed because identical plaintext 4096 bytes apart yields identical ciphertext, and because frame headers at offsets a multiple of 4096 apart decrypt consistently with one 4096-byte key.)
  2. The same keystream is reused for every file — across all recordings, across both cameras, and across many months. Independent files begin with identical ciphertext where their plaintext is identical (e.g. the leading XZYH frame header), and the recovered key decrypts every file.
  3. It never rotates. One key covered an entire firmware generation's recordings.

Reusing one keystream across many messages is the classic two-time-pad / key-nonce-reuse failure. Whether the underlying primitive is AES in a stream mode (e.g. CTR) with a fixed key and a fixed starting counter, or a precomputed static keystream, the observable result is the same: the cipher provides essentially no confidentiality once any plaintext is known or guessable. There is also no integrity protection (no authentication tag), so data is malleable.

The practical consequence is that the attacker never needs the AES key. Recovering the 4096-byte keystream is equivalent to recovering the key, and the keystream leaks directly wherever plaintext is predictable.

6. Why recovery is possible

For a keystream byte at position p, keystream[p] = ciphertext[p] XOR plaintext[p]. Wherever the plaintext is known or guessable, that keystream byte is revealed. The .zxvideo format and its sidecar files contain predictable plaintext at a great many positions:

  • JPEG thumbnails (snapshort.jpg): fixed SOI/JFIF/APP0 headers, and standard quantization and Huffman tables shared across captures.
  • Metadata (recover.dat): a JSON document with constant field names and a fixed, SQL-like structure.
  • Frame headers: the constant XZYH magic plus fixed header fields on every frame.
  • H.264 payloads: Annex-B NAL start codes 00 00 00 01 at predictable offsets within each video frame.
  • Audio payloads: ADTS sync headers (FF F1/FF F9, profile, sample-rate and channel bits) at the start of every audio frame.

Because the keystream repeats every 4096 bytes and is shared by every file, each of these known-plaintext positions — gathered from thousands of frames and files, landing at many different offsets — pins down keystream bytes. Collectively they cover all 4096 positions. No brute force of the AES key is involved; the keystream is simply read off the data.

7. Recovery method

The keystream was reconstructed column by column (one column per position 0–4095) using a majority vote over known-plaintext observations, described here at the level of mechanism:

  1. Bootstrap a handful of low positions from the most reliable known plaintext — the leading frame header and the thumbnail JFIF header (which also fixes the frame length field).
  2. Chain through frames. Once a frame's length field is known, the next frame's header position is known; its fixed header bytes and the H.264/ADTS markers just after it reveal more keystream bytes.
  3. Vote across many files. Because every file shares the keystream and frames land at varied offsets, observations from thousands of frames accumulate at every position; the correct value wins by overwhelming margin.
  4. Verify. The recovered keystream was validated by decoding thumbnails to clean images and decoding the video and audio streams with zero decoder errors.

Only standard, widely available software was used, and the computation took on the order of a minute per firmware generation on an ordinary PC. A critical detail: only header bytes that are genuinely constant must be trusted — fields that merely look constant (counters, flags, length-dependent bytes) differ between firmware versions and must be verified empirically, or they corrupt the result.

This report intentionally omits a packaged tool; the mechanism above is sufficient for the vendor to reproduce and assess the issue.

8. Proof of finding

All results were produced offline from a copy of the storage drive; the original device and drive were never modified.

Older firmware (full run):

Result Value
Recordings present 16,115
Fully recovered 16,112 (3 had no usable keyframe/audio stream)
Total footage \~171 hours
Output Playable MP4 (H.264 1920×1088 + AAC), plus every thumbnail and all metadata
Decoder errors on verification 0

Thumbnails decoded to clean images, confirming the key is exact. Metadata (recover.dat) decrypted to readable JSON including timestamps, device/station serials, storage paths and mic_status.

Newer firmware (sample verification): the keystream was recovered and verified on samples — thumbnails decoded to clean images, and audio and full MP4 output decoded with zero errors.

9. The newer firmware does not fix it

The newer firmware was tested specifically to check whether the issue had been addressed. It had not. The structure is identical — a single fixed 4096-byte keystream, shared across all recordings and both cameras, recovered by the same method in under a minute.

The only differences observed were cosmetic:

Aspect Older firmware Newer firmware
Keystream One fixed key A different fixed key (same structure)
Audio ADTS tag FF F9 (MPEG-2 AAC) FF F1 (MPEG-4 AAC)
Video resolution 1920×1088 2304×1296

Because the key changed between firmware versions, the key is likely derived from or reset with the firmware rather than bound to a device-unique secret. Either way, a firmware update does not protect recordings already on a drive, and does not protect recordings written after the update — both remain recoverable from drive access alone.

10. Impact and threat model

The protection fails against anyone who gains access to the storage medium. Realistic ways that happens:

  • Theft or burglary of the HomeBase or its drive.
  • Resale or second-hand sale of the base or drive.
  • RMA, repair or warranty return, where the drive passes through third parties.
  • Disposal or e-waste, where discarded drives are routinely harvested.
  • Seizure, lawful or unlawful.

In any of these cases the holder can reconstruct the complete set of stored recordings: continuous video and audio of a private home interior, with per-recording timestamps, plus device and station serial numbers and storage paths from the metadata. This directly undermines the core promise of local, on-device storage — that keeping footage off the cloud keeps it private. In practice, the footage is no better protected than if it were stored in the clear, from the moment the drive leaves the owner's control.

11. Remediation recommendations

  1. Never reuse a keystream. Use authenticated encryption (e.g. AES-GCM or ChaCha20-Poly1305) with a unique, non-repeating nonce per file — and never restart the counter within a file. This single change removes the two-time-pad weakness.
  2. Add integrity. The AEAD tag detects tampering and truncation; the current scheme has no integrity protection.
  3. Bind keys to a device-unique secret in secure hardware (e.g. a TPM/secure element), not derivable from firmware, so that extracting a drive does not yield the key and a firmware image does not reveal it.
  4. Rotate keys and avoid a single long-lived key across a whole firmware generation.
  5. Consider full-disk or per-file encryption tied to a user-controlled secret, so a drive removed from the base is unreadable.
  6. Provide a migration path. Offer a way to re-encrypt or securely erase existing drives, and warn users that drives written by affected firmware remain readable until migrated or destroyed.
  7. Document secure disposal for affected devices in the interim (physical destruction or cryptographic erase).

12. Disclosure notes

  • All testing was performed by the researcher on their own HomeBase, their own cameras, and their own recordings, using a copy of their own drive. No third-party devices, accounts, or data were accessed.
  • No cloud service was contacted and no live device was attacked; the work was entirely offline.
Related posts
  • No related post found
Vulnerability disclosure