# Lab 004 — K1 FW 3.0.2 Quick Connect mechanism and closure

- Date: 2026-07-20
- Device scope: one owner-controlled LixelKity K1
- Firmware scope: exact `3.0.2`
- Host: owner-controlled Apple-silicon Mac
- Safety: offline firmware analysis followed by one explicit BLE/AP/host-association cycle
- Secret policy: no AP credential value or digest appears in this report, Git, argv,
  logs, manifests or fixtures

## Official artifact

The full K1 `3.0.2` archive was downloaded from the XGRIDS international
[K1 support page](https://www.xgrids.com/intl/support/download?page=K1). The
local private artifact was `1,252,252,754` bytes with SHA-256
`e5830feae54d586cdeda2824495d08598920dc9cf4541059d01f0efeb858a750`.
It remains under the ignored `sessions/firmware-analysis/` tree with mode
`0600`.

The archive contains a Rockchip `RKFW`/`RKAF` image. The reviewed partitions
were extracted read-only as sparse ext4 images:

- `rootfs.img`: 4,294,967,296 bytes, SHA-256
  `b6e565fa1dd37d539a34b6fe92457bba6e793ab8db0ca216e1fe73a6602b975e`;
- `apps.img`: 230,801,408 bytes, SHA-256
  `c4acb8d60b2e84d56487e5a110b41806fb2f4aa2f4b3cf6f1bc4d8b704b7e59a`.

No firmware was uploaded to the device and no filesystem was mounted
read-write.

## Recovered mechanism

The application partition contains
`/system/scripts/wifi_ap/wifi_ap.sh`. The script deletes prior Wi-Fi profiles,
creates NetworkManager connection `WIFI_AP`, configures WPA2/RSN/CCMP, assigns
`192.168.56.1/24`, installs one firmware-constant PSK and raises the AP.

The stripped AArch64 `lixel_nman` service invokes that script for AP mode. Its
reviewed control flow constructs the SSID as `XGR-` plus six device-identity
characters; if the expected ten-character identity is unavailable it falls
back to the final three MAC bytes formatted as six hexadecimal characters. The
owner-controlled scanner's observed BLE name and AP SSID match this rule.

Therefore, for exact K1 firmware `3.0.2`:

- the AP credential is not supplied by the AP-enable BLE frame;
- it is not recovered from an iPhone or synchronized Wi-Fi history;
- it is not per-device material;
- it is an exact-firmware credential profile defined by the scanner itself.

This does not authorize extrapolation to another K1 firmware or XGRIDS model.

The owner workflow is consistent with this separation. LixelGo required an
application account, but the operator performed no explicit scanner-to-account
pairing, ownership confirmation or per-device credential enrollment. The
available evidence therefore supports treating login as application access and
the AP credential as local firmware behavior. It does not prove that one
account is authorized for every XGRIDS device, and no such broader claim is
made.

## Provider implementation

Mission Core now identifies the source as
`xgrids.lixelkity-k1.quick-connect.fw-3.0.2.official-firmware.v1`.
The offline importer:

1. requires the exact reviewed archive SHA-256;
2. streams the nested Rockchip image without extracting the 4.57-GB container;
3. scans only the bounded apps-partition range;
4. requires exactly one syntactically valid NetworkManager PSK declaration;
5. writes the short-lived value to the host credential store through stdin;
6. zeroizes the mutable Python buffer and emits only redacted provider metadata.

On macOS the firmware-scoped material lives in Keychain. Before any device
write, the CoreWLAN helper materializes the selected SSID's opaque device
profile entirely inside Keychain. The browser/API receives neither the source
material nor a password. A missing source fails before AP activation.

This is a working laboratory provider, not a portable product bootstrap. A new
host needs the provider material installed before Quick Connect. Windows and
Linux would additionally need their own secure-store and Wi-Fi adapters.

## Physical acceptance

After the firmware-scoped provider was installed, one six-second BLE scan found
exactly one expected K1 candidate. Mission Core then performed:

1. one reviewed 100-byte AP-enable write;
2. one bounded wait for the canonical byte-51 AP-ready transition;
3. one exact-SSID CoreWLAN association using the Keychain-only profile.

The operation succeeded and admitted the reviewed K1 AP address
`192.168.56.1`. No credential was entered or displayed. The operator then
manually disconnected the Mac from the scanner AP to preserve the external
chat connection; that later host action does not invalidate the completed
association acceptance.

## Result and closure decision

The device-side mechanism and the prepared-host transport are physically
accepted: Mission Core can enable the K1 AP, observe canonical readiness,
associate one configured Mac and continue into the normal local control path.
The result does **not** establish a self-contained, transferable plugin. The
successful Mac had first received the firmware-scoped material through a
separate administrative import; copying the current application to a clean Mac
would fail closed with `credential-source-unavailable` before the BLE write.

On 2026-07-20 the owner rejected all remaining bootstrap variants for the
product path:

- downloading the 1.25-GB firmware archive during first connection;
- extracting or enrolling the value manually from an iPhone;
- embedding or deriving an unversioned password in application source;
- presenting the machine-local Keychain setup as cross-host automation.

Quick Connect remains in the interface and its current Mac Keychain/provider
state is retained. No evidence, credential material or private firmware files
were deleted. Development of credential acquisition is closed without claiming
that the password can be read from BLE: the reviewed BLE exchange contains AP
activation and status, but no observed credential response. The preferred and
accepted product topology is now Bridge/direct-LAN, where Mission Core sends
operator-selected LAN credentials to K1 through the already reviewed 99-byte
provisioning frame.
