Skip to content

Develop > Master#788

Merged
max246 merged 21 commits intomasterfrom
develop
Feb 15, 2026
Merged

Develop > Master#788
max246 merged 21 commits intomasterfrom
develop

Conversation

@max246
Copy link
Copy Markdown
Collaborator

@max246 max246 commented Feb 15, 2026

Release 3.7.1

lenoxys and others added 21 commits February 9, 2026 13:38
Newer eufy devices (e.g. E340 doorbell) use elliptic-curve cryptography
instead of RSA for P2P session key exchange. The cloud cipher API already
returns an ecc_private_key field for these devices, but the local Cipher
interface did not expose it.

Add the optional ecc_private_key property so downstream code can detect
whether a device uses ECC and act accordingly.
Some eufy devices negotiate the P2P session key using ECDH (prime256v1)
rather than RSA. This adds a dedicated decryption function that handles
the three envelope formats observed in the wild:

  - Raw shared-secret derivation (short key payloads)
  - Full ECIES envelope (public key + IV + ciphertext + HMAC)
  - Graceful fallback for unexpected formats

The function uses the ECC private key returned by the cipher API to
compute the shared secret and derive a 16-byte AES session key.
Devices that use ECC keys send encrypted payloads that RSA cannot
decrypt. Instead of failing outright, the session now attempts RSA
first and, on failure, transparently falls back to ECDH when an ECC
private key is available. If both methods fail, encryption degrades
gracefully to Level 1 so the connection is not lost.

Additionally, guard AES-ECB decryption against non-block-aligned data.
Some command responses (e.g. 36-byte status replies) carry a non-zero
signCode but are not actually encrypted. Attempting to decrypt them
caused crashes; the guard skips decryption when the payload length is
not a multiple of 16 bytes.
The E340 (T8214) is a standalone device where the station serial number
matches the device serial number — making it an integrated device. Add
it to the serial-number-based detection list so that P2P connection
routing and protocol-version decisions handle it correctly, just like
other self-contained cameras and doorbells.
The E340 doorbell uses the same livestream command format as the Outdoor
Pan & Tilt Camera (CMD_DOORBELL_SET_PAYLOAD) — a JSON payload containing
accountId, encryptkey, streamtype, and related fields. Without this, the
generic branch would send CMD_START_REALTIME_MEDIA which the E340 does
not understand.

Route the E340 through the existing Outdoor PT Camera livestream path
rather than duplicating the logic, since the payload format is identical.
Same ECDH+livestream pattern as the E340 doorbell: the T8425 uses
ECDH key exchange and needs the CMD_DOORBELL_SET_PAYLOAD path to
produce video data.  Also adds T8425 to isIntegratedDeviceBySn (was
the only floodlight model missing from the list).
Fix ECDH livestream for E340 doorbell and T8425 floodlight
Parameter Parser accept object
@max246 max246 requested a review from martijnpoppen February 15, 2026 15:41
@max246 max246 merged commit 45aa7f2 into master Feb 15, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants