CMF Watch Pro 2 — BLE Protocol (reverse-engineered)

Unofficial. This document describes the Bluetooth Low Energy (BLE) protocol of the CMF Watch Pro 2 (CMF by Nothing), reconstructed by reverse engineering for an alternative companion app. It is not affiliated with or endorsed by Nothing/CMF. Use at your own risk.

All multi-byte integers in the frame header and opcodes are big-endian. Integers inside command payloads are little-endian unless stated otherwise (this mirrors the device firmware) — watch out for the exceptions (GOALS_SET, GPS_PUSH, bulk-transfer offset/length are big-endian).

Confidence markers

Every non-obvious claim below is tagged with how it was established:

• ✅ validated on-device — observed in a decrypted live capture or exercised against a real watch.
• 🔎 from firmware / APK RE — extracted by decompiling the firmware (1.0.0.73) or the official APK (3.5.7); consistent with the code but not runtime-tested.
• ⚠️ [uncertain] — inferred, not confirmed; may be wrong.

Test device for all captures: CMF Watch Pro 2-5485, fw 1.0.0.73, serial CI04102520008192, MCU Actions ATS3089C (Cortex-M4), screen 466×360.

1. GATT layout

The phone is the GATT client; the watch is the peripheral, advertising as CMF Watch Pro 2-XXXX (4 hex chars).

Enable notifications by writing 01 00 to each CCCD (00002902-…). The command channel (fff1/fff2) carries the framed protocol below. The shell channel (77d4…) carries plain AT-style text (e.g. AT GETSECRET; see §14). The data channel (02f0…) carries large binary blobs (watchface, firmware, AGPS), coordinated by control opcodes on the command channel.

✅ A whole real session ran on the single command channel — during a 160 s heavy-use capture there was no traffic on the data/firmware or shell channels except during an explicit OTA/watchface transfer.

2. Frame format (0xF5)

Every command-channel message is wrapped in one or more 11-byte-header frames:

+------+-----------+--------+-------------+-------------+--------+-------------------+
| 0xF5 | chunkLen  | cmd1   | chunkCount  | chunkIndex  | cmd2   | chunk bytes …     |
| 1 B  | 2 B (BE)  | 2 B BE | 2 B BE      | 2 B BE      | 2 B BE | chunkLen bytes    |
+------+-----------+--------+-------------+-------------+--------+-------------------+
        \__________________________ 11-byte header ____________________________/

• cmd1/cmd2 together form the opcode (see §6). 🔎 confirmed against the official app's frame builder (C6117b.m30831g).
• chunkCount = total chunks for this command; chunkIndex is 1-based.
• chunkLen = number of bytes of chunk in this frame.
• A single BLE write may be fragmented by the link MTU; the receiver buffers raw bytes and re-extracts complete frames. Large payloads are split into multiple chunks (same cmd1/cmd2, increasing chunkIndex) and reassembled in order.

Opcode convention (✅ confirmed on the wire)

• cmd1 = 0xFFFF: cmd2 in 0x80xx/0x90xx = phone→watch (request/set); 0x00xx/0xa0xx = watch→phone (reply). Pairs match by the low byte (0x9055↔0xa055, 0x8051↔0x0051).
• feature-specific cmd1: cmd2 suffix = 0x0001 SET, 0x0002 GET, 0x0003 .

Chunk body

For each chunk, the body is payloadPiece ‖ CRC32_LE(payloadPiece) (4-byte CRC, little-endian, zlib/IEEE). If the command is encrypted (see §3), the whole payloadPiece ‖ CRC is then AES-128-CBC/PKCS7 encrypted and that ciphertext becomes the frame chunk.

Plaintext quirk: for plaintext opcodes the watch counts the 4-byte CRC in chunkLen but does not transmit it. So when decoding a plaintext frame, the actual data length is chunkLen − 4. (Encrypted frames carry the CRC inside the ciphertext as normal.)

Chunk sizing (so encrypted chunks land on AES block boundaries), with maxWrite = mtu − 3:

• encrypted: floor((maxWrite − 11) / 16) * 16 − 4 − 1
• plaintext: maxWrite − 11 − 4 − 2

✅ All observed encrypted frame chunkLen values were multiples of 16 (block alignment holds).

3. Cryptographic primitives

• AES-128-CBC with PKCS7 padding and a fixed IV (from firmware CmfCharacteristic.AES_IV): 50 51 52 53 54 55 56 57 60 61 62 63 64 65 66 5A.
• CRC32 (zlib/IEEE), emitted as 4 little-endian bytes.
• SHA-256 over the concatenation of parts.

Key derivation:

authkey      = SHA256( rnd1 ‖ rnd2 ‖ secret )[0..16]      // persisted across sessions
sessionKey   = SHA256( nonce ‖ authkey )[0..16]           // per connection

• secret = 16-byte device secret (obtainable from the watch via the shell command AT GETSECRET → GETSECRET:<32-hex>,OK).
• rnd1 = 16 random bytes chosen by the phone; rnd2 = 16 random bytes from the watch.
• nonce = bytes from the watch's nonce reply.

After the key is set, all command-channel frames are AES-encrypted except the plaintext opcodes listed in §5.

✅ Both derivations validated: authkey recovered from a rooted phone's ntwatch.db matched the value derived from a captured rnd1/rnd2/secret; sessionKey reproduced from a captured nonce decrypts live frames.

4. Authentication / pairing handshake

Two entry paths share the same nonce/confirm tail.

4.1 First-time pairing (have the device secret)

phone → (shell)  AT GETSECRET
watch → (shell)  GETSECRET:<32hex>,OK
        phone: rnd1 = random16 ;  signed1 = SHA256(rnd1 ‖ secret)
phone → AUTH_PAIR_REQUEST  (plaintext)   payload = rnd1(16) ‖ signed1(32)        // 48 B
watch → AUTH_PAIR_REPLY    (plaintext)   payload = rnd2(16) ‖ signed2(32)        // 48 B
        phone verifies signed2 == SHA256(rnd2 ‖ secret)
        phone: authkey = SHA256(rnd1 ‖ rnd2 ‖ secret)[0..16]   → set crypto key = authkey
phone → AUTH_PHONE_NAME     (encrypted)  payload = 0xA5 ‖ model(UTF-8)           // e.g. "CMF Watch Pro 2"
watch → AUTH_WATCH_MAC      (encrypted)
phone → AUTH_NONCE_REQUEST  (encrypted)  payload = 0xA5
watch → AUTH_NONCE_REPLY    (encrypted)  payload = nonce
        phone: sessionKey = SHA256(nonce ‖ authkey)[0..16]     → set crypto key = sessionKey
phone → AUTHENTICATED_CONFIRM_REQUEST (encrypted) payload = 0xA5
watch → AUTHENTICATED_CONFIRM_REPLY   (encrypted)  → state = Initialized

On AUTH_FAILED (0xFFFF,0xA061) or signature mismatch, authentication fails.

4.2 Reconnect (authkey already known)

        set crypto key = authkey (persisted)
phone → AUTH_PHONE_NAME      (encrypted)  payload = 0xA5 ‖ model
watch → AUTH_WATCH_MAC       (encrypted)
phone → AUTH_NONCE_REQUEST   (encrypted)  payload = 0xA5
watch → AUTH_NONCE_REPLY     (encrypted)  payload = nonce
        sessionKey = SHA256(nonce ‖ authkey)[0..16]   → set crypto key = sessionKey
phone → AUTHENTICATED_CONFIRM_REQUEST (encrypted)  payload = 0xA5
watch → AUTHENTICATED_CONFIRM_REPLY   (encrypted)  → Initialized

✅ The reconnect order (no shell traffic) was observed intact on a real capture.

4.3 Post-auth init (phase 2)

⚠️→✅ TIME is mandatory before data queries. After Initialized, the watch will not answer BATTERY, SERIAL_NUMBER_GET, or the ACTIVITY_FETCH_* handshake until a TIME (FFFF 8004) has been sent in the session — without it, only an unsolicited FIRMWARE_VERSION_RET arrives and everything else times out. ✅ confirmed live (Pixel 8a): sending the three GETs with no TIME → only firmware replies; sending TIME first → battery and serial start replying.

Recommended phase-2 order: TIME → FIRMWARE_VERSION_GET → SERIAL_NUMBER_GET → BATTERY (0xA5) → config pushes → health sync (§8).

4.4 GET → SET echo pattern (✅)

There is no separate "read" opcode for most settings. Sending a *_GET (cmd2 = 0x0002, payload 0xA5) makes the watch reply with the SET opcode (cmd2 = 0x0001) carrying the current value. SET commands are acknowledged with cmd2 = 0x0003 and an empty body.

5. Plaintext vs encrypted

Frames are AES-encrypted once a key is set, except these opcodes, which are always plaintext:

• AUTH_PAIR_REQUEST (FFFF 8047), AUTH_PAIR_REPLY (FFFF 0048)
• DATA_CHUNK_WRITE_WATCHFACE (FFFF 9064), DATA_CHUNK_WRITE_FIRMWARE (FFFF 9042), DATA_CHUNK_WRITE_AGPS (FFFF 905F)

Frame headers (cmd1/cmd2) always travel in the clear, so the command sequence is visible in any capture even without the key — only encrypted payloads need sessionKey.

6. Opcode reference (cmd1, cmd2)

GET/SET/REQUEST = phone→watch; RET/REPLY/ACK/RESPONSE/DATA = watch→phone.

Session / device

Auth

Notifications / call / find

Music

Alarms / contacts / reminders

Config

Weather

Watch faces / dials

Health / sync

JS-only opcodes (FFFF 8051, FFFF 0051, FFFF 90A2, FFFF 90C5, FFFF A056, FFFF 908A/908B ChatGPT status/support) are handled in the app's Hermes bytecode, not the Java layer. Their headers appear in captures but payload semantics are ⚠️ [uncertain].

Bulk data transfer (data channel)

Watchface / firmware / AGPS use an init → chunk-request/chunk-write loop → finish-ack:

(all cmd1 = FFFF.) The watch drives the loop by emitting DATA_CHUNK_REQUEST_*(offset, length) (offset/length = u32 big-endian); the phone replies with DATA_CHUNK_WRITE_* carrying payload[offset..offset+length] on the data characteristic. See §11–§12 for details.

7. Time & timezone

TIME (FFFF 8004) payload = epochSeconds(i32, BE) ‖ utcOffsetMillis(i32, BE). Sent right after auth so the watch shows local time (and unblocks data queries — see §4.3).

⚠️ Health timestamps from the watch are UTC. The companion app must add the local UTC offset before deriving the local calendar day / time-of-day. (Bucketing health by raw UTC day rolls the day over at the wrong local time.)

TIME_FORMAT (005F 0001) payload = 1 byte: 00 = 24h, 01 = 12h.

8. Health sync

1. Phone sends ACTIVITY_FETCH_1; watch replies ACTIVITY_FETCH_ACK_1 (first byte 01 ⇒ ready).
2. Phone sends ACTIVITY_FETCH_2; the watch then pushes a burst of data frames: ACTIVITY_DATA, HEART_RATE_*, SPO2, STRESS, SLEEP_DATA, WORKOUT_SUMMARY[_V3].
3. Each is parsed into per-minute samples / sessions and aggregated by local day.

The sync is sequential (must follow TIME; the watch releases the streams after ACK_2), not a single burst. A heavy session pushes ~170–210 notification frames in ~160 s. ✅

8.1 Activity record — ACTIVITY_DATA (32 bytes each, LE) ✅

Calorie unit: activity calories are reported in cal (gram-calories). Divide the daily sum by 1000 to get kcal. (Workout-summary calories, by contrast, are already in kcal.)

8.2 HR / SpO₂ / Stress samples ✅

• Manual/auto HR, workout HR, SpO₂, stress = 8 bytes each: timestamp(i32 LE) ‖ value(i32 LE) (value = bpm / SpO₂ % / stress index).
• Resting HR (00DA 0001) is different — 5 bytes: timestamp(i32 LE) ‖ hr(u8). ✅ live example 5e dc 29 6a 4e → ts, hr = 78 bpm. Stress score ranges: 1–29 / 30–59 / 60–79 / 80–99.

8.3 Sleep — SLEEP_DATA (18-byte header + N × 8-byte records) ✅

One SLEEP_DATA = one sleep session; a night may contain several (micro-wakes split sessions).

Header:

Each 8-byte record: timestamp(u32) ‖ duration_s(u16) ‖ stage(u16). Stage codes: 1 = Deep, 2 = Core/light, 3 = REM, 4 = Awake. ✅ validated against a full night (two sessions, D/C/R/A totals reconcile).

8.4 Workout summary — WORKOUT_SUMMARY v1 (54 bytes) / _V3 (0160 0001)

v1: start(u32), end(u32), duration_s(u32), then type/calories/steps/distance/avg-HR and a GPS/extended block. ✅ v1 layout confirmed against firmware. WORKOUT_SUMMARY_V3 is a newer layout for the same data plus a ~40-byte extended block (exerciseLoad, aerobic/anaerobic, recoveryTime, VO₂max, cadence, PAI, best-run times…). The field set is known (from the app's Room DB) but the exact byte offsets inside that 40-byte block are ⚠️ [uncertain] — closing them needs one raw capture of a GPS workout.

9. Selected command payloads

Strings are UTF-8, byte-truncated to the field size (truncation may split a multi-byte char, matching the firmware's s.encode()[:max] behavior); short fields are zero-padded on the right.

• APP_NOTIFICATION (0065 0001) ✅: iconCode(1) ‖ 0x00 ‖ when(u32 BE) ‖ titleLen(1) ‖ title ‖ body. iconCode selects the app icon (WhatsApp=8, Telegram=12, Instagram=18, Gmail=27; unknown=0xFF). Title ≤ 20 bytes, body ≤ 128 bytes. Sent from a client → watch displayed it + ACK 0065 0003.
• BATTERY (005C 0001) ✅: reply = level(1) ‖ charging(1) (e.g. 3b 00 = 59 %, not charging).
• SERIAL_NUMBER_RET (00DE 0001) ✅: len(1) ‖ ASCII (e.g. 10 + "CI04102520008192").
• USER_INFO (0095 0001) ✅: height_cm(1) ‖ weight_kg(1) ‖ age(1) ‖ gender(1: 1=M) (e.g. = 172 cm / 73 kg / 31 / male).

10. Implementation notes & quirks

• No system clock in codecs: encoders take now/utc_offset as explicit parameters (deterministic, testable). The transport supplies the real time.
• TIME gates everything (§4.3) — send it first or the watch stays mute on data queries.
• Plaintext CRC counting (§2) is easy to get wrong — plaintext frames advertise but omit the CRC.
• Endianness: header + opcodes BE; payload integers LE; exceptions — GOALS_SET and GPS_PUSH are big-endian, and bulk-transfer offset/length are big-endian.
• MTU: chunk sizes are computed so encrypted chunks align to 16-byte AES blocks.
• authkey is persistable (store it after first pairing); sessionKey is per-connection and derived from the watch nonce on every reconnect.

11. Watch faces / dials — authoring

The watch supports (a) photo/custom dials (a background image + a firmware-drawn digital clock) and (b) structured dials (built-in / store faces: a background plus positioned sprite layers, hands, and text widgets). Both transfer over the data channel via the init → chunk loop in §6.

What actually works (✅ validated live): building a photo dial from any image and installing it; installing any of the 103 store dials offline; reskinning a structured dial (swap the background or any non-background sprite) and moving its layers; reordering / switching the active face; and building a structured dial from scratch — the 0x20 scene envelope is decoded and the builder is implemented (§11.7), proven offline to round-trip all 103 store dials byte-for-byte and to emit synthetic containers that pass the firmware's own validator. 🟡 the only unproven step is watching a from-scratch synthetic render on-device over 9075 (structural offline proof already covers what used to cause the 0a reject). There is no codec or transport barrier and no need for the vendor toolchain. The old "structured render is RES-pack-baked / impossible over BLE" and "cf=0x1f server-side codec" claims were wrong (an offset+bytes-per-pixel bug) — the firmware renders structured dials data-driven from the file you send.

11.1 Dial management — DIAL_COMMAND (9055 / a055) ✅

• type 0 = query the list. Reply a055 = result(u8) ‖ selectIndex(u8) ‖ total(u8) ‖ max(u8) ‖ N × dialId(u32 LE) ‖ ffffffff. Example: 01 05 06 07 … = active #5, 6 dials, max 7.
• type 1 = reorder / select active: resend the whole list with the target dial at index 0 (this is how the official app switches faces; there is no dedicated "set active" opcode).
• Delete a dial = resend the list without its id.
• CHANGE_DIAL (009F 0001) is inert on fw 1.0.0.73 (returns a constant, doesn't switch) — do not use it.

11.2 Transfer flow ✅

INIT1 8052 (payload A5) → 0052 [0]=01
INIT2  9063 (photo, APPEND)  |  9075 (structured, REPLACE)  → A063 / A075 [0]=01
[ watch → DATA_CHUNK_REQUEST A064 (offset, length; u32 BE, +progress u8)
  phone → DATA_CHUNK_WRITE   9064 (bytes[offset..offset+length], plaintext) ] × N
FINISH A065 → 9065 (payload A5)

Finish reply byte: 01 = activated & saved; 0a = stored but not activated / rejected. On Android each DATA_CHUNK_WRITE must go out as one BLE write per frame — concatenating and re-slicing by MTU desyncs the headers and the watch loops asking for offset 0.

• 9063 (photo) = APPEND. The dial list grows (6→7); watchfaceId = 0xFFFFFFFF (custom sentinel) so it is never rejected as a duplicate, and the watch auto-activates it.
• 9075 (structured) = REPLACE the old_id slot. old_id must already be in the list (otherwise 0a). To re-install an id already present, delete it first (9055 list-minus-id) then upload "fresh" — reusing an id in place gives 0a.

11.3 Photo / custom dial — ✅ fully validated end-to-end

Container (byte-verified round-trip; all fields little-endian):

0x00  magic     6c 8d c4 a5
0x04  count     12 00 00 00   (=18)  [constant, NOT an element count]
0x08  00 × 8
0x10  lenFull   u32 LE        (length of the whole FULL block: tag+len+payload)
0x14  FULL  tag 04 48 47 3a ‖ payloadLen(u32 LE) ‖ LZ4(RGB565-LE)   → 466×466  [raw 434312 B]
      THUMB tag 04 38 c4 21 ‖ payloadLen(u32 LE) ‖ LZ4(RGB565-LE)   → 270×270  [raw 145800 B]
EOF-4 magic     6c 8d c4 a5   [trailer = magic repeated]

Codec = standard LZ4 block over RGB565 little-endian, top-down (payloadLen counts from the first LZ4 byte). The official app uses LZ4-HC and strips the 21-byte LZ4-block header/footer; a plain literals-only LZ4 encoder also works — the watch accepts any valid LZ4, byte-identity is not required. Pixels outside the inscribed circle (center 233,233, radius 233) are set to 0x0000.

INIT_2 for 9063 — exact header (✅ this is the one that works):

01 ‖ size(u32 BE) ‖ FF FF FF FF ‖ 01 01 01 ‖ styleId(u16 BE) ‖ posX(u16 BE) ‖ posY(u16 BE) ‖
   color565(u16 BE) ‖ FF × 8

size = exact .bin length; FFFFFFFF = custom watchfaceId; styleId 0–4 selects the built-in digital-clock layout (it is always drawn — there is no "off"); posX/posY position it (known-good 56 / 77); color565 tints it (e.g. FFFF = white). ⚠️ The shorter A5 ‖ size ‖ watchfaceId form is rejected with finish 0a — use the full header above. (Reference impl: core-rust/engine.rs::build_wf_init2, mirroring C6135t.m31104u in the official app.)

Recipe: resize the image to 466×466 (and a 270×270 thumb), convert to RGB565-LE top-down, optionally zero the out-of-circle pixels, LZ4-compress each, assemble the container above, and upload via the 9063 pipeline with watchfaceId = 0xFFFFFFFF. (Reference codec: core-rust/watchface.rs, work/codec_dfa.py.)

11.4 Structured / store dial — container & codecs ✅

Header (identical across all 103 store dials; all fields little-endian):

0x00  perDialId  u32 LE     [per-dial id/hash; NOT a content checksum — 4 "Default" dials share one]
0x04  version    0x00000001 [constant]
0x08  name       char[]     [NUL-terminated, e.g. "SlopeTime", "Metaball"]
0x18  size_a     u32 LE     [= filesize − 36]   ✅ 100 % confirmed across 103 dials
0x1c  size_b     u32 LE     [data-section length, < size_a]
0x20  3× u32 LE  id/hash words [not a CRC]
0x2c  name       (repeated on larger dials)
~0x60 directory of layer records (61 xx 00 …) then the asset pool

There is no blocking checksum (CRC32/Adler32/byte-sum all fail to match) — repacking is not gated. Stub dials (~173 B, e.g. ids 273/274/277) are placeholders for faces baked into ROM: header + directory, no real assets.

Assets — each is dimsWord(u32 LE) ‖ len(u32 LE) ‖ LZ4(payload), where cf = dimsWord & 0x1f, w = (dimsWord >> 10) & 0x7FF, h = (dimsWord >> 21) & 0x7FF, and len counts from the first LZ4 byte (the 1f 00 01 00 you often see there is the first LZ4 token — do not skip it). Decompressed size = w·h·bpp:

✅ All 4151/4151 assets across the 103 dials decode exactly with a standard lz4.block decompressor at w·h·bpp. Transparency is the alpha byte (cf=5/24) or 0x0000 (cf=4 outside the circle) — there is no RLE and no "escape". Encode = re-raster → standard LZ4 → [dimsWord][len][LZ4].

INIT_2 for 9075 — AES-encrypted body:

kind(1) ‖ old_id(u32 LE) ‖ new_id(u32 LE) ‖ file_len(u32 LE)

kind = 0x02/0x03; old_id = current active dial (from 9055); file_len = real .bin size (= @0x18 + 36). Installing a store .bin as-is is the guaranteed path (Ring Data id 359 + 102 others confirmed). (Reference: core-rust/engine.rs::build_dial_replace_init.)

11.5 Structured directory grammar ✅ (decoded & implemented — REVISED 2026-07-02)

⚠️ Revision (2026-07-02): the flat 61 01 00 record schema below was systematically OFF-BY-ONE. The scene body is a clean TLV (§11.7); a drawable leaf body (tags 0x30/0x38 static, 0x70 pointer) is:

root@kitploit:~

01 xx 00 [X u16][Y u16] …attrs… 61 [count u16][base u32][count×id u16] [05 05 00 01 pivX pivY]

• attr 0x01 opens the body: X,Y = top-left on the 466² canvas (the s16 x,y of the SDK's sty_picture_t).
• the frame table 61 … closes the body (base = asset ptr; count 1 = image, 10/11 = digit atlas — the old "record type 0a/0b" was actually this count! — 7/13/2 = complication frame sheet).

Historic flat-record reading (superseded, kept for context):

• Static image (61 01 00): asset_ptr(u32) ‖ elemId(u16) ‖ 05 05 00 01 ‖ pivotX(u16) ‖ pivotY(u16) ‖ 3B ‖ 01 ‖ 1b 00 ‖ X(u16) ‖ Y(u16). Top-left on the 466² canvas = (X−pivotX, Y−pivotY).
• Pointer/hand — same image record, rotated at runtime. Rotation center = (X+pivotX, Y+pivotY) (≈ 233,233 on analog dials). The data source is a u8 at record offset +36, scale u16 at +38 (=60): 0x0a/0x70 = hour (h·30°+m·0.5°), 0x0e/0x71 = minute (), / = second (). ✅ confirmed by disassembling the getters (RTC fallback 10:10:30).

11.6 Authoring matrix

⚠️ Reskin/re-author pitfalls that cause a black screen or 0a: leaving the old asset len (the watch reads past the block → overrun → black); growing the file (rejected at install); reusing an id in place instead of a fresh install.

11.7 The 0x20 scene envelope — decoded & builder implemented ✅

A re-authored real dial renders because it preserves the file's scene envelope. A purely synthetic body of flat 61 … records is rejected — the firmware parser (WFManager_Parser, 0xdb35c) requires the body (from offset 0x24) to start with a 0x20 scene container. The full file is:

[0x00,0x24)  header:  perDialId@0 · version=1@4 · name[16]@8 · size_a@0x18 · size_b@0x1c · idWord0@0x20
[0x24, fa)   scene:   20 <u16 L0> ( 21 <u16 L1> ( 86 <len>=name , 30/70/80/81… drawables ) [ 22 … AOD ] )
[fa, EOF)    assets:  [dimsWord u32][len u32][payload = 1f 00 01 00 + LZ4] …
   size_a = filesize−36 · size_b = filesize−36−first_asset · 0x27+L0 == first_asset

The scene is a clean nested TLV — [tag u8][len u16 LE][body], container tags 0x20/0x21/0x22/0x68 recursing, leaf drawables 0x30 (static) / 0x70 (element/pointer) / 0x80 / 0x81 / 0x86 (name). (The flat 61 01 00 / 61 0a 00 records are patterns that live inside the drawable bodies; the old parser found them heuristically — and stitched adjacent bodies together, see the §11.5 revision. The drawable body layout is now fully decoded there.) Every child's offset+len must fit inside its parent's window; first body byte ≠ 0x20 → parser error −16; a child overrunning its window → −2; either makes the 9065 handler (0xeb50c) write finish .

Builder is implemented and offline-validated (core-rust/watchface_struct.rs: SceneNode / serialize / parse_scene / validate_container / build_container / build_container_raw; CLI cmfwatch-wfgen reframe):

• scene_roundtrip_identity — all 103 store dials: parse_scene→serialize reproduces the scene byte-for-byte (recomputed nested lens match) and validate_container passes on every one.
• build_reframe_identity / CLI reframe — reassembling the whole .bin from scratch reproduces the file byte-for-byte except 1 name-padding byte (@0x17; not a checksum).
• build_container_synthetic — composes a new dial (background + drawable nested in 20→21) that passes the firmware's exact invariant (build_container emits correct nested windows).
• validate_rejects_bad_containers — rejects a flat body (→ , the historic bug) and a child that overruns its window (→ ).

🟡 Still unproven (needs the watch, non-blocking): uploading a from-scratch synthetic over 9075 and watching it render — the offline structural proof already covers what caused the 0a reject.

11.8 Render-fidelity refinements (2026-07-02, dial 275 "SlopeTime")

Cross-referenced the wfweb render against the official store thumbnails (pixel oracle over all 103 dials) and closed four gaps:

• Drawable/pointer X/Y are i16 (signed). ✅ Anchors can be negative for elements that extend off-canvas — e.g. 275's red second hand sits at Y = 0xFFFC = −4 (a 30×281 sprite, source 0x12, rotated from center off the top edge). Reading X/Y as u16 (65532) made the guard drop it. Parse both as signed and allow a small negative range.
• Digital clock digits can be top-level 0x60 img_numbers (not only inside a 0x68 group), and the real data source is the u8 at record offset −5 — the forward 82-attr scan is systematically off-by-one here and grabs the next sibling's attr (in 275 the minute digit picked up the weekday 0x18). 275's "10:10" = hour 0x07@X≈306 + min 0x0b@X≈369 with the as an adjacent static between them, each an 11-glyph atlas (). ⚠️ When correcting X/Y from , the , or a re-export corrupts those bytes (breaks same-footprint → ).

Also: the official store thumbnails are rendered at 10:10 (classic marketing time), not 10:12 — matching the oracle time to 10:10 drops mean pixel-diff noticeably. wfweb's parser now round-trips all 103 dials byte-exact (the X/Y write-offset fix above cleared the last mismatches).

11.9 AOD-container skip + standalone img_number source (2026-07-03, dial "Gradient")

• Separate the 0x22 AOD container into its own view. ✅ The scene walker already skips 0x22, but the flat text/number scan walked the whole [0x30, firstAsset) — so it emitted the always-on (AOD) variant of each element as a normal layer. On "Gradient" the AOD gray date atlas (offset in 0x22) drew on top of the red normal one. Fix: tag every 0x22 record with layer.aod=true (with its own dedup set) and let renderAt(…, aod) show them only in AOD mode (normal mode hides aod layers; AOD mode hides normal ones; the background is swapped by setAod and always draws). Net oracle win in normal mode across the corpus (284: 31%→21%, +18 others) — the AOD variants were overdrawing many dials — and the editor's AOD toggle now shows the real always-on layout instead of the normal ones. The real AOD is a black screen (no dimmed scene): if the dial has no dedicated AOD background frame (dial.aod), the normal scene is hidden in AOD mode so it renders black + the 0x22 elements at their own colour. AOD parse via the scene walker too (it now recurses the container tagging drawables , instead of leaving them to the flat scan where their pivot didn't match → "unpositioned"); AOD hands rotate at the canvas centre (the sometimes carries an off-centre hand x/y the firmware ignores — e.g. Gradient's hour ). The editor also exposes this as an (§UI): each screen shows only its own layers and edits persist independently. Normal-mode render is byte-identical throughout; roundtrip stays byte-exact on all 103 dials.

11.10 img_number DIGIT COUNT — the 40 01 00 XX byte (✅ firmware-confirmed)

How many digits an img_number draws is a single byte in the field record — the data byte XX of the element's 40 01 00 XX attribute sub-record (the 0x40 sub-record that sits after the 61 [count][base][glyph-ids] frame table):

• low nibble XX & 0x0F = number of digit slots (0 ⇒ firmware default 7).
• bit 7 0x80 = zero-pad (show leading zeros, e.g. "09" vs "9").

Confirmed by disassembling the firmware (XIP image 0x10000000; render routine 0x100d8e60): NDIG = ldrb[40sub+3] & 0x0F (→7 if 0); the value is clamped value % 10^NDIG and exactly NDIG glyphs are drawn MS-first, leading zeros suppressed unless bit7. The u16 after the source (60 for date, 1000 for kcal) is NOT the count — it only feeds the thousands/millions separator-glyph insertion (cmp #1000/#1000000), which is why editing it did nothing. Source id doesn't cap either.

Corpus histogram over all 620 number fields matches: 2-digit fields (hour/min/sec/date/temp/HR) end 40 01 00 02/0x82; kcal …04; steps …05; single-digit clock splits 0x81. So the date field 40 01 00 82 = 2 digits, zero-padded — that's the entire reason a rebound Fahrenheit temperature (≥100) was truncated.

Fix / editor: wfweb parses digitCount/digitZeroPad (+digitCountOff) for number fields, exposes "Digits" + "Zero-pad" in the inspector, writes the byte in-place (same-footprint), and the preview clamps/pads to digitCount to mirror the firmware. So rebinding a field's source and setting its digit count works for any field (e.g. date→temperature °F → Digits 3). Normal-mode oracle unchanged (0 regressions, 3 tiny improvements); roundtrip byte-exact on all 103 dials. (The earlier "Digits width"/rectW hypothesis was wrong — width is layout only, not the count.)

12. Bulk transfer & OTA details

The transfer table is in §6. Additional confirmed points:

• AGPS/EPO ✅: the first written chunk begins with the ASCII header 000000010000…. The full init → [A05F ↔ 905F]×N → finish loop was observed on the wire (~892 chunks).
• Firmware OTA (9040–9042, finish 9041) 🔎: structure mapped; INIT2 payload = version bytes (e.g. 0b 00 00 39 = 11.0.0.57). Not field-tested (the app disables FW update here). Firmware images appear to be unsigned — integrity is CRC32 only (no asymmetric signature observed in RE).
• ⚠️ Because OTA and FACTORY_RESET (009A 0001) share the authenticated session, a single valid BLE auth is enough to wipe or (in principle) brick the watch. Handle with care.

13. Sensors

✅ Hardware exposed via BLE:

• Optical PPG — heart rate (manual/auto/workout/resting), SpO₂, and HRV-derived stress.
• 3-axis accelerometer — steps, distance, calories, sleep staging, wrist-raise, cadence.
• GNSS/GPS (AGPS-assisted) — workout track (WORKOUT_GPS) and location push (GPS_PUSH).

There is no barometer/altimeter, compass, gyroscope, or skin/body-temperature sensor. An internal NTC thermistor (board/battery temperature) exists but is readable only via the AT channel (AT GETNTCTEMP, §14) — the 0155 skin-temp history stream is empty on this SKU.

Data-widget hijacks (there is no real complication/data-binding API — see §11.5): the watch's existing text fields can be repurposed to show glanceable external data. Proven ✅: the weather city string (WEATHER_SET_1, e.g. "BRA 2x1 ARG" appeared on the widget) and the music track/artist fields; the contacts list (20 × name[32]+number[25]) works as a scrollable data panel. All are pushes, not persistent complications.

14. AT factory / shell channel (77d4ff01 / 77d4ff02)

A separate plain-text AT command channel, independent of the framed protocol. ✅ tested live:

• Read: AT GETSECRET (16-byte pairing secret), GETVERSION, GETSN, GETNAME, GETPID, GETBATLV (raw mV, e.g. 3853mv), GETGSENSOR (raw accel in g, X=… Y=… Z=…), GETNTCTEMP (°C, internal NTC).
• Write / actuate: AT SETMOTOR=1 (vibrate the motor), SETHR/SETHRV/SETSPO2=… (sensor test injection), SETLCDSWITCH/SETGPSSWITCH/SETKEYSWITCH.

Replies end in ,OK. SET* commands generally execute but may not echo ,OK over BLE — confirm case by case.

15. Firmware-gated / unavailable features (🔎 firmware RE)

Some features are present in the firmware but disabled by SKU/region and are not reachable from the phone/BLE — they need a firmware mod, which is out of scope here:

• ChatGPT voice — gate = ux2sys feature id 0x9e, seeded from NVRAM/EFUSE/region at boot; on this SKU support flag 908b = 00. Not influenceable by phone, account, or BLE (confirmed by experiment + RE). The app is only a relay; audio goes phone → Nothing cloud.
• Blood pressure — a complete subsystem exists in firmware, switched off by SKU/region.
• Alipay / NFC payment — full UI present, China-SKU only.
• Absent in hardware/firmware: ECG, SOS/emergency, generic NFC.

16. Complication getter table (🔎 firmware-internal reference)

Not needed to build a BLE client — included for completeness. The firmware's dial renderer binds each complication slot to a numeric getter id (142-entry dispatch table). Selected ids: 0x07 hour, 0x0a combined clock angle, 0x0b minute, 0x0f second, 0x18 day-of-week, 0x19 heart rate, 0x1b battery %, 0x24 temperature, 0x36 steps, 0x70/0x71/0x72 hour/minute/second hand angle, 0x25–0x27 goal %. Ring/arc complications index a pre-rendered frame sheet (e.g. 50 % = frame 50 of 100), not a per-pixel arc — the frames are baked into the .bin you send (§11.5), so no external RES pack is needed.

Quick-cards (home tiles) — QUICK_CARD (906D) ✅

The watch's home tiles. The phone only chooses which tiles show and in what order — tiles are rendered by the firmware (no content channel). First payload byte = sub-command: 00 = GET, 01 = SET; both use 0x906D (0x906C is listed but not used — querying it times out). Reply = A06D.

🛑 Sending a made-up assemblyId wipes the watch's screens (it accepts the list, can't match the ids, shows nothing). Only send ids you read back via GET; recover via the official app or a factory reset.

GET reply ✅: status(1) ‖ 00 ‖ N(1) ‖ N × group, group = tag=01 ‖ K(1) ‖ K×(assemblyId, sportId). Real frame: 01 00 04 01 02 5d00 6100 01 03 1900 2e00 2300 01 03 5c00 0400 5a02 01 03 4800 5100 5300 = 4 screens / 11 cards (5a02 = Sport card, sportId 2).

Slots: each screen has 4 slots. A card's type sets its size — circular/square = 1 slot, rectangle = 2 slots. Validation is pure slot arithmetic (Σ ≤ 4 per screen); no mutually-exclusive cards. sportId is 0 except on Sport cards (87–91). Ids 64 and 95 don't exist.

assemblyId catalog (each logical type = a contiguous range of 6 style variants _0.._5; 0 = empty slot):

Byte layouts above were reconstructed from the firmware (1.0.0.73), the official APK (3.5.7), and decrypted live captures against a real device. The reference implementation for this project lives in core-rust/src/{commands,frame,crypto,health,session}.rs (Rust) and the cmftool/ Python tools (pair.py, session.py, wf_codec.py, upload_custom.py, …).