Skip to content

SubGhz: add Cardin S508 rolling-code decoder (decode-only)#1004

Open
half2me wants to merge 1 commit into
DarkFlippers:devfrom
half2me:subghz-cardin-s508
Open

SubGhz: add Cardin S508 rolling-code decoder (decode-only)#1004
half2me wants to merge 1 commit into
DarkFlippers:devfrom
half2me:subghz-cardin-s508

Conversation

@half2me

@half2me half2me commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

What

Adds a decode-only Sub-GHz protocol for the Cardin S508 868 MHz rolling-code remote (S500-series, FCC ID TXQ508; the 2-channel S504 uses the same protocol). It recognizes the remote in Read mode and displays the on-air codeword. It's the 868 MHz sibling of the 433.92 MHz Cardin S449 (KeeLoq) from #908 — a different protocol on a different band.

Protocol (reverse-engineered)

  • 868.35 MHz, 2-FSK (~12 kHz dev), read with the FM12K preset.
  • Manchester / biphase, half-bit ≈ 100 µs. On a real capture the 2-FSK slicer is duty-cycle biased (high half-bits read longer than low), so classification uses per-level timing bands.
  • Codeword = 140 bits: a 12-bit fixed sync 110011110100 + a 128-bit fully-rolling payload. Every payload bit changes between presses; there is no cleartext serial, button, or counter — those live inside the encrypted block. Cardin documents this family as "128-bit cryptography", consistent with a 128-bit AES ciphertext, which is stored and shown as an opaque hex blob.

Decode/display only — by design

The rolling payload is encrypted and the key resides in the receiver, so valid future codes cannot be generated. Emulation is impossible and is intentionally not implemented: no encoder, no "Add Manually", no TX path (the encoder vtable is an all-NULL stub). This is purely an RX/identification contribution — it cannot open a gate.

Implementation notes

  • Modeled on the repo's existing Manchester FSK decoders; reuses the shared manchester_advance helper. Decode-only structure follows ido.
  • The helper decodes this remote's convention complemented, so the decoder locks on either the sync or its complement and normalizes to the canonical form (codeword always begins 110011110100).
  • 128-bit payload stored across data/data_2, serialized with the kinggates_stylo_4k extra-field pattern.

Testing

  • Hardware-verified: flashed to a Flipper; both an on-device subghz decode_raw replay and a live read of a real remote detect the protocol and show a 140-bit codeword with the constant sync and a per-press-changing 128-bit Key.
  • Regression test added (RAW .sub replay) under applications/debug/unit_tests/.
  • Coverage caveat: validated against one physical remote; no public bit-level spec exists, so the model is derived from clean captures.

Add a decode-only Sub-GHz protocol for the Cardin S508 868 MHz rolling-code
remote (S500-series, FCC ID TXQ508; the 2-channel S504 uses the same
protocol) — the 868 MHz sibling of the 433.92 MHz Cardin S449 (issue DarkFlippers#908).

868.35 MHz, 2-FSK (FM12K preset), Manchester, half-bit ~100us. Codeword is
140 bits: a 12-bit fixed sync (110011110100) + a 128-bit fully-rolling
AES-128 payload with no cleartext serial/button/counter. The decoder locks
the sync (accepting either polarity, since the firmware's manchester_advance
decodes this convention complemented, and normalising to the canonical form)
and reports the 128-bit payload as an opaque hex blob.

Decode + display only: the payload is AES-128 encrypted and the key lives in
the receiver, so valid codes cannot be generated. No encoder, "Add Manually",
or TX path is implemented (the encoder vtable is an all-NULL stub).

Verified on hardware (decode_raw + live read of a real remote) and with a
unit-test capture replay.
@half2me
half2me requested a review from xMasterX as a code owner June 10, 2026 09:59
@mishamyte mishamyte added the area/subghz Related to the subghz subsystem label Jul 3, 2026
@mishamyte mishamyte added this to the Backlog milestone Jul 7, 2026
@mishamyte

Copy link
Copy Markdown
Member

So without encoder we can't accept it. So putting in the backlog

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/subghz Related to the subghz subsystem

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants