# Reviewed K1 Wi-Fi provisioning profile

Profile ID: `xgrids-k1-fw3-wifi-v1`

Status: reviewed for one controlled write against the owner-controlled K1. This
profile is not a generic XGRIDS protocol claim and must not be used for fuzzing.

## Evidence and target

- Observed device firmware: 3.0.2.
- Live metadata-only GATT discovery exposes service `7f00`, read/write
  characteristic `7f01`, and read characteristic `7f02`.
- Static analysis of the official Android application's production path maps
  its service field to `7f00`, discovered write field to `7f01`, and status/read
  field to `7f02`.
- The application sends operator-supplied router credentials; it does not derive
  them from the K1 and it does not require the password of the K1's own AP.

The 99-byte `7f01` profile is used when K1 joins an external network (Bridge or
controller hotspot). It is not the Quick Connect bootstrap. A live Mission Core
negative run on 2026-07-19 proved that host association alone cannot work while
the reviewed K1 remains in station mode: `7f02` still reported the existing LAN.

Re-review of the owner-supplied LixelGO QuickLink branch then recovered the
missing first step. After a real BLE connection, LixelGO sends one fixed
100-byte frame to the same `7f01` characteristic: bytes `0..98` are zero and
byte `99` is `0x01`. Its callback is the AP-launch result; only then does the
application passes that device record's `WiFiAP_SSID` and `WiFiAP_Password` to
the operating-system connector. Later analysis of the official K1 `3.0.2`
firmware recovered the upstream source: `lixel_nman` invokes the bundled
NetworkManager AP script, which assigns a firmware-constant WPA2 credential.
The persisted app fields are per-device records, but the reviewed firmware
material is not per-device. The reviewed app requests write-without-response.
Mission Core follows the live characteristic properties on macOS, where this K1
advertises write-with-response, and never retries either transport or command
automatically.

The browser/API carries no AP password. An optional laboratory importer authenticates the
exact official `3.0.2` archive, resolves the reviewed material without printing
it and installs one firmware-scoped credential source in the OS secure store.
Mission Core then binds a device-scoped host profile ID to the selected
BLE-advertised SSID. Before any device write, the macOS helper materializes that
profile entirely inside Keychain from the firmware-scoped source. The actual
secret never reaches the browser, API, argv, logs, manifests or evidence. The
bounded Python importer holds it only in a short-lived mutable buffer, sends it
through helper stdin and zeroizes the buffer.

Full UUIDs:

- service: `00007f00-0000-1000-8000-00805f9b34fb`;
- write: `00007f01-0000-1000-8000-00805f9b34fb`;
- status/read: `00007f02-0000-1000-8000-00805f9b34fb`.

## Request frame

The application writes exactly 99 bytes:

| Offset | Length | Meaning |
| --- | ---: | --- |
| 0 | 1 | SSID UTF-8 byte length, 1 through 32 |
| 1 | 32 | SSID UTF-8 bytes followed by zero padding |
| 33 | 1 | password UTF-8 byte length, 1 through 64 |
| 34 | 64 | password UTF-8 bytes followed by zero padding |
| 98 | 1 | zero |

There is no checksum, nonce, token, certificate, signature, or separate commit
command in this production call path. The implementation must never print,
persist, or accept the password as a command-line argument.

## Quick Connect AP-enable frame

The separately reviewed Quick Connect device action writes exactly 100 bytes:

| Offset | Length | Meaning |
| --- | ---: | --- |
| 0 | 99 | zero |
| 99 | 1 | enable device AP (`0x01`) |

It contains no SSID, password, device identifier or user input. The reviewed
client maps response byte 51 of `7f02` to its AP-ready flag. Mission Core
therefore requires all three observations before host association: mode
`WIFI_AP`, address `192.168.56.1`, and non-zero byte 51. A failed or ambiguous
attempt is not automatically repeated.

The first controlled AP attempt was physically accepted: one write-with-response
completed, `7f02` changed to `WIFI_AP / 192.168.56.1`, and a later exact
CoreWLAN scan found the SSID matching the selected BLE device. The Mac remained
on its previous LAN only because the former host adapter looked up an invalid
global profile. That profile inference and its APK importer were withdrawn.

A later physical attempt established another boundary: `7f02` can continue to
report `WIFI_AP / 192.168.56.1` with byte 51 zero after the exact SSID is no
longer beaconing. Mode and address alone are therefore not an idempotency or
readiness signal. Like the reviewed LixelGO action, each new explicit Mission
Core Quick Connect intent emits one AP-enable frame even when the baseline mode
already says `WIFI_AP`, then polls for the byte-51 ready flag for at most 15
seconds. It never retries the device write automatically.

Static review of the original client also established a lifecycle requirement:
LixelGO keeps the same BLE manager connected after AP-ready and invokes native
Wi-Fi association from that live session. Mission Core now retains the same
`BleakClient` while CoreWLAN performs bounded exact-SSID discovery and one
association. The discovery window may contain multiple read-only scans; it does
not repeat the BLE write or Wi-Fi association.

The next physical attempt exposed a CoreBluetooth lifecycle boundary before any
write: K1 appeared in the explicit six-second BLE scan, but a second lookup by
its macOS UUID failed moments later. The UUID is a transport-local selector, not
a durable rediscovery contract. The runtime now retains the live `BLEDevice`
handle from the operator's scan and connects that exact selected handle in the
following network action. A fallback lookup remains only for non-UI callers
that did not perform discovery first.

The 2026-07-20 prepared-host acceptance installed the exact firmware provider,
found one expected K1 candidate, emitted one AP-enable write, observed AP-ready
and completed one CoreWLAN association without an iPhone or manual credential.
Mission Core admitted `192.168.56.1`; the operator disconnected afterward only
to restore the external chat route. Full redacted evidence and artifact hashes
are recorded in `docs/lab/004_K1_FW302_AP_CREDENTIAL_PROVIDER_20260720.redacted.md`.
This proves the mechanism on that Mac, not automatic credential acquisition by
a copied application on a clean host.

The Android application unequivocally requests a write without response and
negotiates MTU 120, making the 99-byte frame one ATT command. A live read-only
CoreBluetooth check reports MTU 256 and a maximum write-without-response size of
253, so the same frame also fits one command on this Mac.

CoreBluetooth metadata advertises `write`, not `write-without-response`, despite
the official application forcing the latter. The macOS tool exposes that
discrepancy: `auto` follows advertised properties, while the explicit
`without_response` mode mirrors the application only after checking the live
maximum is at least 99. The first controlled experiment uses that explicit
mode. It never fragments or retries the payload automatically.

## Expected transition and evidence of acceptance

A completed GATT write only proves transport completion. It does not prove that
the K1 joined Wi-Fi or began beaconing. The application polls `7f02`; the
observed response frame contains a fixed-width mode slot, an address slot, a
status byte at offset 50 and the AP-ready flag at offset 51. The stale AP
baseline reports `WIFI_AP / 192.168.56.1 / byte51=0`; the physically observed
ready transition reports the same mode/address with `byte51=1`.

For Bridge/Direct Connect, acceptance requires at least one of:

1. `7f02` reports a non-AP IPv4 address;
2. the same address appears as a new router/ARP client after the write;
3. a statically evidenced K1 application endpoint is reached at that confirmed
   address.

Do not infer success from a write callback alone.

The Bridge/Direct Connect address is a DHCP lease, not configuration and not
device identity. Mission Core re-reads `7f02` without writing before every new
LAN control session, implicit-host acquisition and factory-calibration read.
If the value changes, it rotates `device_session_id`; it never retargets an
active acquisition. A correlated MQTT `DeviceInfo` response supplies the live
model/firmware/serial identity barrier.

The 2026-07-20 reboot/power-cycle check observed the startup race directly:
one read returned the earlier `.54` lease while that exact address had no ARP or
application endpoint; a later read returned `.52`, where exact probes found
MQTT 1883 and RTSP 8554. No subnet scan, route change, network-profile change or
VPN action was used. This is why no owner-LAN IPv4 value is a product constant
and why a BLE lease observation alone is not reported as live DeviceInfo.

For Quick Connect, host association is not admitted until the canonical
byte-51 ready flag is observed. CoreWLAN then searches only for the exact
device-profile SSID for at most 15 seconds and performs at most one association.

## Safety, recovery and stop conditions

- Perform one write per explicitly named attempt. Never retry automatically.
- For Bridge/Direct Connect, use credentials for the operator-selected network.
- For Quick Connect, the exact `3.0.2` provider must already exist in the OS
  secure store. Missing or mismatched firmware material fails before the AP
  write. Never extrapolate this provider to another firmware or model.
- The macOS adapter materializes a device-scoped Keychain item from the exact
  firmware source, then performs one association. Standard Wi-Fi Keychain and
  native prompt paths remain compatibility fallbacks, not the reviewed
  zero-touch path. It never asks the browser for a password.
- Do not alter Deco settings, scan the subnet, or guess any credential.
- If the status does not change, do not retry automatically.
- If the supplied credentials are wrong, reconnect over BLE and overwrite them
  with corrected credentials using the same reviewed profile.
- A single normal power cycle is allowed as a recovery check. It is not claimed
  to erase stored credentials. Factory reset and firmware actions are prohibited.
- Stop on repeated disconnects, an unexpected GATT layout, overheating, an
  activation prompt, or any device fault indication.

The exact factory-return command is not known. That limitation is accepted for
the first write because BLE remains the documented configuration transport and
the operator controls the intended LAN credentials.

## Live transport attempts

Attempt 01 mirrored the Android application: one 99-byte write without response,
with a live CoreBluetooth maximum of 253 bytes. For 60 seconds afterward, `7f02`
remained at the AP baseline and the existing LAN neighbor table did not change.
There was no automatic retry.

Attempt 02 was separately reviewed because `7f01` explicitly advertises ordinary
write-with-response to CoreBluetooth. The identical 99-byte payload was sent
once using that advertised transport. This tested the transport mismatch only;
it did not change credential values or application framing.

Attempt 02 succeeded immediately. `7f02` reported the operator-selected LAN,
status code 1 and a non-AP private IPv4 address. The existing neighbor table then
confirmed the same new address on the Mac's Wi-Fi interface. No third
provisioning write was made.

Offline analysis of the owned application and a targeted check against only that
confirmed address identified plain MQTT on TCP 1883 as the production
application endpoint. Port 8008 belongs to a separate QuickLink/AP WebSocket
branch and was correctly refused in the bridge/LAN topology. The successful
MQTT result is documented in `05_K1_MQTT_STREAM_PROFILE.md`.
