85 lines
4.5 KiB
Markdown
85 lines
4.5 KiB
Markdown
|
# 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.
|