4.5 KiB
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:
- A device-local HTTP/TCP service: requires a confirmed frame LAN address and bounded service inspection while the frame is awake.
- A firmware-supported custom server or image URL: requires configuration or firmware evidence, not simply replacing the application's API host.
- 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.