Release v0.1.9: enforce Photos API boundary and finalize Server migration

2026-10-17 01:39:23 +08:00
parent 46a0429d5e
commit b87bf6f77e
35 changed files with 724 additions and 155 deletions
@@ -0,0 +1,84 @@
+# 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.