# KoKonna local-control investigation

Reviewed 2026-10-06. No frame writes, network changes, or firmware changes.

## Sources and limits

- Official FAQ: https://kokonna.art/pages/faq explicitly describes Bluetooth
  upload and switching. This is a product-level claim, not verified B101 behavior.
- Public OpenAPI: https://kokonna.art/pages/openapi documents cloud HTTPS calls.
- Existing official Android nightly 1.6.5 APK from the prior download:
  SHA256 `8f611bf74bbda70e7e7a5d087e4065dc6000849dcd2f12538d5ff5017c91e1c0`.
  Static inspection of its packaged app-service.js; no vendor code is copied here.
- Searches found community API clients, but no verified B101 firmware source or
  documented bring-your-own-server configuration. Absence from search is not
  proof that firmware source or another configuration path does not exist.

## Observed client behavior

The account client uses `https://robot.galaxyguide.cn/api/rpc`. Its Bluetooth
upload flow calls `appFrame.uploadImage` with base64 and `synced: true`, receives
an image ID, downloads the resulting image from the vendor server, and sends
the bytes to the frame over BLE. Therefore this observed flow still exposes
the original image to the vendor cloud.

BLE service UUID: `4fafc201-1fb5-459e-8fcc-c5c9c331914b`.
Characteristic UUID: `beb5483e-36e1-4688-b7f5-ea07361b26a7`.

Observed JSON commands include `get_info`, `refresh_image`, and `set_image`.
Image transfer uses start metadata (ID, rotation, type, size, chunk count),
numbered binary chunks, sync acknowledgements/missing-chunk information, and
an end command. The client chooses `y4` for firmware starting with B103 and
`jpg` otherwise. That makes local JPEG transmission a plausible B101 research
path, not a proven implementation: cloud-independent IDs, processing, firmware
acceptance, pairing and completion semantics still require validation.

The observed `set_config` payload contains `slideType`, `slideMinute`, and
`nickname`; `set_wifi` contains SSID and password. No server-host setter was
found in these paths or common host-setting symbol searches.

## Host replacement assessment

Changing Frame Flow's API base URL changes where Frame Flow sends requests,
not where the frame connects. Replacing the frame's cloud server requires its
device-side protocol and a supported address-setting mechanism or firmware
change. DNS redirection alone may fail HTTPS certificate validation and still
requires a compatible server implementation. TLS/pinning and actual device
polling transport have not been established from this APK.

Next read-only step: inspect BLE `get_info` and installed firmware compatibility.
Any subsequent local image write needs a separate controlled test. No BLE driver
is enabled by this investigation.

## Wi-Fi-only follow-up

The user excluded Bluetooth and additional gateways. The target is NAS-to-frame
Wi-Fi control with the original hardware.

GitHub's public repository search for `kokonna` returned three repositories:
`patrickchen914/kokonna`, `nixihz/kokonna-skill`, and
`zhengweiran66-eng/kokonna-product.html`. These provide a Home Assistant cloud
integration, an OpenAPI CLI, and a product page, respectively; no verified B101
device firmware or Wi-Fi local-server implementation was identified.

Static APK checks found no hard-coded private IPv4 target, WebSocket URL,
custom image-URL setter, or common server-host setter symbols in app-service.js.
This does not exclude hidden firmware features or native-library code paths.
`app.getFirmwares` is called with `robotId`. Upgrade submission passes a firmware
name, locale and distributor ID through `app.setUpgradeFirmware`; the inspected
UI does not supply a user-selected firmware download URL. Neither method was
called during this investigation. Existing account RPC allowlists remain intact.

Candidate paths, none yet verified:

1. A device-local HTTP/TCP service: requires a confirmed frame LAN address and
   bounded service inspection while the frame is awake.
2. A firmware-supported custom server or image URL: requires configuration or
   firmware evidence, not simply replacing the application's API host.
3. A NAS implementation of the device's cloud protocol: requires the actual
   polling/download protocol and address/TLS behavior. Passive observation at
   the existing gateway may provide evidence; a normal NAS on a switched LAN
   cannot assume it sees another device's outbound packets.

No DNS redirection, router interception, certificate replacement, firmware
upgrade, reset, or automatic display change was performed.