I bought a generic Chinese IP camera off a marketplace listing — the kind that costs less than dinner. Plugged it in, watched what it does, then started taking it apart. Three weeks later I had extracted hardcoded admin secrets, forged authenticated requests against the vendor's operator API, mapped the entire cloud backend, identified eight leaked Google & Alibaba API keys, confirmed three CVEs apply to the device, and put together this report.

The vendor is UBIA Technologies — legal name Shenzhen Qingshi Internet Technology Co., Ltd. (深圳市青视互联科技有限公司), founded 2014, based in Bao'an District, Shenzhen. They claim to have shipped over three million low-power cameras. The hardware is the same Ingenic T31 reference design sold under at least nine brand names — UBox, UCon, YBox, Javiscam, Funstorm, i-Cam+, Soliom+, icamplus, Jarvis-, xega — all the same firmware, all the same backend, all the same problems.

UBIA didn't respond when CISA tried to contact them about the existing CVE-2025-12636. They probably won't respond to this either. I'm publishing under a 90-day responsible-disclosure window from April 2026 with sensitive specifics redacted; CISA coordinators and UBIA security contacts can request the unredacted artifact pack at the email below.

This report covers 20 distinct findings, 3 applicable CVEs, the full toolchain we built, and the failed paths we tried so other researchers don't have to repeat them. Everything below is from research on a device I own. No production user data was touched. PII has been redacted from all example payloads. The source code for every tool is published at repo.seteclabs.io/SetecLabs/cam-mitm.

Methodology: passive observation first, MITM on a controlled LAN, decompilation of the official Android app, native binary analysis of the bundled libUBICAPIs.so series, original PoC verifiers built from scratch (no public exploit code reused), and direct reproduction against my own camera. No port scans were run against the vendor's infrastructure. No credentials beyond my own account were used. No production accounts were touched.

Brand           Javiscam (one of nine OEM rebrands of the same hardware)
Model           2604  (Product ID 1619)
SoC             Ingenic T31 (Junzheng) — per UBIA marketing
Android App     cn.ubia.ubox v1.1.360 (Pro: com.ubianet.uboxpro)
Vendor          UBIA Technologies Co. / Shenzhen Qingshi Internet Technology Co.
Founded         2014  (Bao'an District, Shenzhen, Guangdong)
Firmware        2604.1.2.69 (current shipping)
P2P Stack       ThroughTek Kalay (rebranded internally as "UBIC")
MAC OUI         14:92:F9 (TP-Link reference design)
IOTC UID        20-char alphanumeric (Kalay format, REDACTED)
Cloud Portal    portal.ubianet.com (US, CN, EU regions)
OAM Portal      oam.ubianet.com (operator/admin tier)
Photo Storage   Alibaba OSS + AWS S3 (ubiasnap-{eu,as} multi-region)
OTA Storage     Tencent COS (ubiaota-us-1312441409, ubiaota-cn-1312441409)
Tencent APPID   1312441409
Push Service    TCP/20003
P2P Relay       UDP/10240 (Tencent + Alibaba clouds)
Master Servers  portal.{us,cn}.ubianet.com  + ThroughTek Kalay masters

Architecture is the standard Shenzhen IPC playbook: small ARM SoC, no inbound services, all comms outbound through a P2P relay run by ThroughTek's master servers and the vendor's portal. The camera never opens a port to the LAN. It just dials home, registers its UID against a Kalay master, and waits for the legitimate client app to connect through the relay. Local control requires the per-device IOTC credentials, which the cloud API leaks (V01).

The vendor's own marketing page (ubia.com.cn/intro/1.html) confirms the SoC family: UBIA describes themselves as having "launched a Junzheng T31 low-power doorbell / battery camera" with over three million units shipped. Junzheng is the Chinese name for Ingenic. T31 is the standard battery-IPC reference SoC, fully supported by the open-source OpenIPC project.

Standard ISC research methodology, no unusual tradecraft:

1. 01
   Passive observation. Plug the camera into a controlled LAN. Capture all traffic with tcpdump. Identify the cloud endpoints, DNS lookups, P2P registration packets, and connectivity-check destinations the device hits without prompting. Output: a list of every IP and hostname the camera ever talks to.
2. 02
   Active MITM on the LAN. Build a small Python framework (later setec_suite/cam-mitm) that does ARP spoofing, DNS interception with our own answers, HTTP/HTTPS interception with auto-generated certs, raw packet sniffing per IP, and protocol fingerprinting from the first 6 bytes of every payload. Use it to capture the camera's API requests in cleartext and analyze them.
3. 03
   App decompilation. Pull the official UBox Android app from APKPure (cn.ubia.ubox v1.1.360). Extract resources with jadx. Statically grep for: API endpoint strings, hardcoded credentials, cryptographic constants, OAuth/OAM signing schemes, hardcoded IPs and hostnames, third-party SDK identifiers. Cross-reference any interesting findings against the live MITM captures.
4. 04
   Native binary analysis. The app's TUTK/Kalay stack is in libUBICAPIs.so (and ...23.so, ...29.so for ABI variants). Pull strings, list exported symbols with nm -D, locate the crypto init/encode/decode functions, disassemble those with arm-linux-gnueabi-objdump, and look for static keys, master server hostnames, and runtime-derived auth schemes.
5. 05
   Authenticated API enumeration. Log into the cloud portal with my own account using our reproduced auth scheme. Hit every endpoint we harvested from the decompiled app (146 of them) with empty bodies first; flag any that return real data, an error code with a meaningful message, or a documented schema. Then mutate parameters on the interesting ones.
6. 06
   Forged operator-API requests. The decompiled app contains an OamHttpClient class with a hardcoded HMAC secret used to sign requests against UBIA's operator/admin tier (oam.ubianet.com). Reproduce the signing scheme. Forge requests against the OAM endpoints we know exist. Confirm acceptance.
7. 07
   CVE verification. Build original non-destructive verifiers for the CVEs we believe apply (CVE-2025-12636 cred leak, CVE-2021-28372 Kalay UID hijack, CVE-2023-6322/6323/6324 Kalay LAN parser chain). Each verifier probes the necessary preconditions on the live camera and reports VULN / NOT_VULN / UNKNOWN with evidence. No exploit payloads were sent. No overflow attempts. No spoofed master-server registrations.
8. 08
   Documentation. Every finding gets a numbered V-record with severity, source location, vector summary, evidence, and remediation guidance. Sensitive specifics (actual leaked secret values, the alternate hardcoded password, the live API keys) are redacted from this public report and held back for the vendor.

What I did not do: scan the vendor's infrastructure with port scanners, test against accounts other than my own, perform any operation that would interfere with other users' devices, send overflow / fuzz payloads to the live camera, or use any public exploit code. Every PoC in this report is original.

Twenty distinct issues. Severity is mine, calibrated to "what an attacker can actually do" rather than CVSS theatre. Sensitive technical specifics are redacted on this public page; the unredacted artifact pack is available to CISA coordinators and UBIA security contacts on request.

Every tool used in this engagement is original. None of the off-the-shelf IoT pentest frameworks knew anything about this device. The whole stack is published as repo.seteclabs.io/SetecLabs/cam-mitm and is reusable as a template for any TUTK Kalay-based camera (or any IP camera with cloud + P2P architecture).

setec_suite/cam-mitm

Camera MITM & pentesting framework. PyQt6 GUI on top of a curses TUI on top of a service controller. Real-time intercept, fuzz, inject, attack-chain runner.

• gui.py — PyQt6 dashboard, nine tabs (Dashboard, Live Log, Intruders, Cloud API, Fuzzer, Inject, CVEs, Config, Help). Wraps the same Controller as the curses TUI so both UIs work.
• mitm.py — curses TUI + Controller class with per-service start/stop and iptables management.
• services/arp_spoof.py — ARP poisoning with auto-cleanup on exit.
• services/dns_spoof.py — Selective DNS hijack for cloud hostnames.
• services/http_server.py — HTTP/HTTPS interception with peek-before-wrap (so non-TLS traffic on :443 doesn't get lost when we wrap_socket too aggressively).
• services/udp_listener.py — UDP P2P / push capture on configurable ports.
• services/sniffer.py — Raw packet sniffer with conntrack-based original-destination lookup and per-packet protocol fingerprinting.
• services/intruder_watch.py — Detects ARP-spoof attempts against the camera, unknown LAN peers contacting the camera, and outbound destinations not on the known cloud whitelist.
• api/ubox_client.py — UBox cloud client. Login, devices, firmware check, families, raw POST. Plus the OAM HMAC signing client that forges admin requests with the V14-leaked secret.
• api/fuzzer.py — API endpoint discovery (146 known + ~600-entry wordlist), parameter mutation, auth-bypass tests.
• api/firmware_fetch.py — Multi-version check_version caller, walks the response for any URL, downloads any firmware-shaped object found.
• api/ota_bucket_probe.py — Anonymous HEAD enumeration of UBIA's Tencent COS firmware buckets across 320 path templates.
• api/cve_checks.py — Original PoC verifiers for CVE-2025-12636, CVE-2021-28372, CVE-2023-6322/3/4 + markdown report generator. Non-destructive — every verifier reports VULN/NOT_VULN/UNKNOWN with evidence and never sends an exploit payload.
• api/server.py — Local REST API on :9090 for external tool integration / AI-assisted automation.
• inject/packet.py — UDP/ARP/DNS packet injection.
• utils/log.py — Shared logging with 1 GiB log rotation.
• utils/proto.py — Payload-to-protocol fingerprinting from the first 6 bytes (TLS, HTTP, RTSP, IOTC, STUN, DNS, NTP, MQTT, SSDP, etc.).
• regen_cert.sh — Regenerates the MITM SSL cert with full SAN list (*.ubianet.com, *.aliyuncs.com, *.myqcloud.com, target IP).

Live screenshots from the engagement. All sensitive specifics (account email, JWTs, tokens, API keys) are blacked out where they appeared.

The one thing this engagement could not extract was the actual firmware binary. Three reasons.

1. 01
   The cloud refuses to push it. Multiple check_version/v3 calls with progressively older fake versions (down to 2604.0.0.1) all return {"data":{"result":{}},"msg":"success"}. The cloud accepts the request shape — we verified against com/apiv3/bean/AdvancedSettings.java:827-857 byte-for-byte — but has no OTA campaign active for this model. The vendor either retired the model or pinned it to its current shipped version permanently.
2. 02
   The OTA bucket name leaked but listing is locked. We extracted ubiaota-us-1312441409.cos.na-siliconvalley.myqcloud.com from app/getconfig. We confirmed individual files can be public-read (a demo MP4 at dev_add_doc/1159_video/... is anonymous-readable). But anonymous bucket listing returns AccessDenied, and 320 guessed paths for our product ID returned zero hits. Without the real filename pattern, blind enumeration is hopeless.
3. 03
   The TUTK auth key isn't in the app. We dumped every native library in the APK. libUBICAPIs.so has the symbols (p4p_crypto_init, p4p_device_auth, p4p_client_send_masterhello) but no static auth key. p4p_crypto_init allocates buffers and the key is supplied at runtime by a caller. The TUTK key is therefore either runtime-derived from the cloud login response, or compiled into the device-side firmware (not the app).

The path forward is one of: (a) MITM the camera's own boot-time firmware check on a live network and capture the URL the cloud serves to the device itself; (b) Frida-hook the running app and dump p4p_crypto_init's arguments at runtime; (c) physical UART access to the camera, drop into U-Boot, dump NAND, extract the device-side libraries — the standard OpenIPC T31 flow now that we've identified the SoC (V19).

Phase 2 — Hardware Teardown (planned)

The next phase of this engagement, scheduled for the disclosure-window period, is a full physical teardown and hardware-side analysis:

• Open the case — non-destructive disassembly, document every screw and clip for reassembly
• Identify the SoC by chip marking on the QFN package (~10×10mm). UBIA's own marketing says Ingenic T31 (V19); we confirm with the eyeball
• Map the PCB — identify UART TX/RX/GND test points (often labeled, often four pads in a row near the SoC), SPI flash chip, NAND chip, status LEDs, and any debug headers
• Hook a USB-UART adapter at standard 115200 8N1 and capture the U-Boot boot log + Linux dmesg. The boot log alone almost always reveals: kernel version, rootfs layout, MTD partition map, secondary boot args, and any failsafe modes
• Drop into U-Boot by hitting Enter during the 1-second boot countdown. From U-Boot we can md arbitrary memory, nand dump the entire flash, and load custom kernels via TFTP
• Dump NAND — either via U-Boot's nand dump command, or by physically lifting the SPI flash with a clip programmer (CH341A or similar). Image is then mounted with jefferson / ubidump / binwalk to extract the rootfs
• Extract the device-side libIOTCAPIs.so — this is the missing piece from the app-side analysis (V16). The device-side library is where the runtime TUTK auth key actually lives, and where any encryption key derivation happens. With the rootfs in hand, this is a 60-second find + strings job
• Identify any custom firmware obfuscation — UBIA may apply XOR, AES, or simple bit-rotation to firmware images on the OTA path. Whatever scheme they use is hardcoded in the device-side bootloader and trivially recovered with rootfs access
• Build OpenIPC for the confirmed T31 variant and flash a known-good bootable image. This gives us a permanent root shell on the device for ongoing research, and lets us replay traffic against UBIA's cloud as the camera
• Document everything — PCB photos, pinout diagrams, U-Boot environment, partition layout, and the firmware extraction recipe. Shipped as a Phase 2 addendum to this report so other researchers don't have to repeat the same work

Once Phase 2 is complete, the remaining gaps in this report — specifically, the runtime TUTK auth key (V16) and the actual filename string the cloud uses for OTA paths (V12) — should both be filled in. Phase 2 will be published as camhak.seteclabs.io/phase2 when complete, or merged into this report if the disclosure window has not yet closed.

One CVE on this device is already public: CVE-2025-12636 went out via CISA in October 2025. The advisory specifically notes that UBIA did not respond to coordination attempts. Our independent verification reproduces the exact issue against current shipping firmware.

The other findings (V11–V20) are new. We are sitting on the most sensitive specifics — the actual leaked secret values, the alternate hardcoded password, and any working OAM endpoint paths discovered after publication — and will not publish those until either:

• UBIA acknowledges the report and ships fixes for V11–V20, OR
• 90 days pass with no response, matching standard responsible-disclosure practice.

If you are at UBIA and want to talk before the clock runs out, the contact is below. If you are a CISA coordinator who handled the original ICSA-25-310-02 disclosure and want the unredacted technical pack, same address.

For the unredacted artifact pack, coordinated disclosure inquiries, or follow-up questions on methodology:

sssnake [at] seteclabs.io

PGP key: seteclabs.io/sssnake.asc

Source code: repo.seteclabs.io/SetecLabs/cam-mitm

This report: camhak.seteclabs.io

— SsSnake  //  Lord of the Abyss