cam-mitm/SECURITY_PAPER.md

Security Analysis of Cloud-Connected IoT Cameras: A Case Study on the UBIA/UBox Ecosystem

Setec Labs Research By: sssnake Date: March 2026

---

Abstract

This paper presents a security analysis of a consumer-grade cloud-connected IP camera sold under multiple brand names (Javiscam, Funstorm, and others) that relies on the UBIA Technologies "UBox" platform and ThroughTek Kalay P2P SDK. Through passive network analysis, API reverse engineering, and mobile application decompilation, we identified ten distinct vulnerabilities ranging from plaintext credential exposure in API responses to disabled SSL certificate validation. The camera's cloud-first architecture — with zero inbound network services — creates a false sense of security while introducing systemic risks through its vendor cloud dependency. All testing was performed on equipment owned by the researcher using custom tooling developed for this analysis.

---

1. Introduction

The global IP camera market has seen explosive growth, with millions of low-cost WiFi cameras entering homes and businesses. Many of these devices are manufactured by a small number of Chinese ODMs and sold under dozens of brand names through Amazon, AliExpress, and similar marketplaces. Despite different branding, they often share identical hardware, firmware, and cloud infrastructure.

This presents a compounding risk: a vulnerability in one "brand" affects every device built on the same platform. This paper examines one such platform — UBIA Technologies' UBox ecosystem — and documents the security posture of a camera sold as a "Javiscam" (also marketed under the "Funstorm" brand) that uses ThroughTek's Kalay P2P SDK for cloud connectivity.

1.1 Scope

This research was conducted on a single camera owned by the researcher:

Property	Value
Vendor Marketing Name	Javiscam
Alternate Brand	Funstorm
Model Number	2604
Product ID	1619
Firmware Version	2604.0.29.8
MAC Address OUI	14:92:F9 (TP-Link chipset)
Mobile Application	UBox (cn.ubia.ubox) v1.1.360
Cloud Platform	UBIA Technologies (ubianet.com)
P2P SDK	ThroughTek Kalay IOTC/AVAPI
IOTC Device UID	J7HYJJFFFXRDKBYGPVRA

1.2 Methodology

The analysis was performed in four phases:

1. Passive Network Analysis — ARP spoofing to capture all camera traffic, identifying cloud endpoints, protocols, and communication patterns
2. Application Reverse Engineering — Decompilation of the Android UBox APK using jadx to extract API endpoints, authentication flows, and protocol definitions
3. API Security Testing — Direct interaction with the UBIA cloud API, enumeration of endpoints, and analysis of data leakage
4. Automated Fuzzing — Custom tooling for endpoint discovery, parameter mutation, and authentication bypass testing, integrated with AI-assisted analysis via REST API

1.3 Tools

All primary tooling was developed specifically for this research and is released as the "SetecSuite Camera MITM Framework":

• ARP/DNS Spoofing — Python raw socket implementation for MITM positioning
• Protocol Capture — Multi-protocol listener (HTTP, HTTPS, UDP, raw packets)
• API Client — Authenticated UBox cloud API interaction
• API Fuzzer — Endpoint discovery, parameter mutation, auth bypass testing
• Packet Injector — Raw frame crafting for UDP, ARP, DNS
• REST API — External integration interface enabling AI-assisted automated analysis

Third-party tools used: nmap (initial discovery), jadx (APK decompilation), tcpdump (packet capture validation).

---

2. Architecture Analysis

2.1 Network Architecture

The camera employs a cloud-first architecture with zero inbound services. All 65,535 TCP and UDP ports were found to be filtered — the device accepts no incoming connections from the local network.

All communication is outbound, initiated by the camera:

Protocol	Port	Destination	Purpose
UDP	10240	Tencent Cloud (43.x.x.x)	P2P master/relay service
UDP	123	AWS EU, Alibaba	NTP time synchronization
TCP	443	portal.ubianet.com	API/portal communication
TCP	443	*.aliyuncs.com	Alibaba OSS (firmware, photos)
TCP	443	*.amazonaws.com	AWS (accelerator)
TCP	20003	UBIA push servers	Push notification service
TCP	80	Various CDNs	Connectivity checks

2.2 Connectivity Checks

The camera performs HTTP connectivity checks against:

• www.microsoft.com
• www.amazon.com
• www.apple.com
• www.qq.com

The inclusion of www.qq.com (Tencent/QQ) confirms the firmware's Chinese origin. These checks use plaintext HTTP (port 80), not HTTPS.

2.3 P2P Communication

The camera uses ThroughTek's Kalay P2P platform for all video streaming and device control. The app and camera both connect to P2P master servers (m7.ubianet.com, m8.ubianet.com) which broker a direct P2P tunnel or provide relay services through Tencent Cloud infrastructure.

The P2P protocol uses UDP port 10240 with 72-byte outbound packets and 180-byte inbound packets. The IOTC UID format (J7HYJJFFFXRDKBYGPVRA) serves as the device's unique identifier on the P2P network.

2.4 Cloud Infrastructure

The following infrastructure was identified through DNS analysis and APK decompilation:

API Servers:

• portal.ubianet.com — Primary API (global)
• api.us.ubianet.com — US region
• api.cn.ubianet.com — China region
• pay.ubianet.com — Payment processing
• wx.ubianet.com — WeChat integration

Object Storage:

• ubiaota.oss-cn-shenzhen.aliyuncs.com — Firmware OTA (Alibaba OSS, Shenzhen)
• uboxphoto-us.oss-us-west-1.aliyuncs.com — User photos (Alibaba OSS, US West)
• ubiaota-us-1312441409.cos.na-siliconvalley.myqcloud.com — Tencent COS backup
• ubiaota-cn-1312441409.cos.ap-guangzhou.myqcloud.com — Tencent COS China

P2P Master Servers:

• m7.ubianet.com
• m8.ubianet.com

SIM Management:

• 118.178.150.203:9001
• api.iot400.com

---

3. Vulnerability Findings

V1: Plaintext Device Credentials in API Response

Severity: CRITICAL CVSS 3.1: 9.1 (Critical)

Endpoint: POST https://portal.ubianet.com/api/user/device_list

The device list API response includes the camera's authentication credentials in plaintext:

{
  "cam_user": "admin",
  "cam_pwd": "yyc1G::HPEv7om3O",
  "device_uid": "J7HYJJFFFXRDKBYGPVRA"
}

These credentials are used for IOTC P2P authentication. Any attacker who can intercept or access this API response — through a compromised account, session hijacking, or MITM — obtains full device control credentials.

Impact: Complete device takeover including live video/audio access, file download, configuration changes, and firmware manipulation.

Recommendation: Never include device credentials in API responses. Use session-based tokens with limited scope and expiration.

---

V2: API Key Leakage in Login Response

Severity: HIGH CVSS 3.1: 7.5 (High)

Endpoint: POST https://portal.ubianet.com/api/v3/login

The login response includes internal cloud service credentials:

{
  "app_config": {
    "android_private_config": {
      "ucon": {
        "GoogleAPIKey": "AIzaSyD_oOWY67gLDTUdezW9UTlTfwTidR9itXA",
        "AMapAPIKey": "5c32ed9e0ebea43b41496713e259a895"
      }
    }
  }
}

Additionally, the user's avatar URL contains a pre-signed Alibaba OSS URL with embedded access credentials:

uboxphoto-us.oss-us-west-1.aliyuncs.com/...?x-oss-credential=LTAI5tGDU3y7P6YtDzmb1dDL...

Impact: Exposed API keys enable unauthorized use of mapping and cloud services. The OSS access key ID (LTAI5tGDU3y7P6YtDzmb1dDL) could be used to enumerate or access cloud storage if combined with other vulnerabilities.

Recommendation: Serve API keys only to authenticated clients via secure channels. Use short-lived pre-signed URLs without exposing access key IDs.

---

V3: Weak Password Hashing (HMAC-SHA1 with Empty Key)

Severity: MEDIUM CVSS 3.1: 6.5 (Medium)

Source: LoginViewModel.java:276

loginJsonBean.setPassword(
  new HttpClient().get_replace_str(
    new String(Base64.encode(hmac_sha1.getHmacSHA1(str2, "")))
  )
);

User passwords are hashed using HMAC-SHA1 with an empty string as the key, then Base64 encoded with character substitutions (+ -> -, / -> _, = -> ,). HMAC-SHA1 with an empty key is functionally equivalent to unsalted SHA1 hashing.

Impact: User passwords can be reversed via rainbow tables or brute force. No per-user salt means identical passwords produce identical hashes across all accounts.

Recommendation: Use bcrypt, scrypt, or Argon2 with per-user salts and appropriate work factors.

---

V4: SSL Certificate Validation Disabled

Severity: HIGH CVSS 3.1: 7.4 (High)

Source: NewApiHttpClient.java:1053

MySSLSocketFactory mySSLSocketFactory = new MySSLSocketFactory(keyStore);
mySSLSocketFactory.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

The mobile application accepts any SSL certificate without validation. This enables trivial MITM attacks against all API communications, including the login flow (exposing credentials) and device list (exposing device access tokens).

Impact: An attacker on the same network can intercept all cloud API traffic, steal authentication tokens, and obtain device credentials (V1) by presenting a self-signed certificate.

Recommendation: Implement proper certificate validation. Consider certificate pinning for critical API endpoints.

---

V5: ThroughTek Kalay P2P SDK (Known Vulnerabilities)

Severity: CRITICAL CVSS 3.1: 9.6 (Critical)

The camera uses ThroughTek's Kalay IOTC/AVAPI SDK for P2P communication. This SDK has multiple disclosed critical vulnerabilities:

CVE	Description	CVSS
CVE-2021-28372	Improper access control, remote camera/audio access	9.6
CVE-2023-6321	OS command injection (root access)	9.8
CVE-2023-6322	Stack-based buffer overflow	7.2
CVE-2023-6323	Insufficient verification (AuthKey leak)	4.3
CVE-2023-6324	Insufficient entropy in DTLS setup	5.9

CVE-2023-6323 and CVE-2023-6324 can be chained with CVE-2023-6321 to achieve remote root access from the local network (Bitdefender Labs, 2024).

The SDK version in use was not definitively determined during this analysis. ThroughTek patched affected SDK versions by April 2024, but the firmware version analyzed (2604.0.29.8) shows no evidence of recent SDK updates.

Impact: Depending on SDK version, an attacker could remotely access camera feeds, audio, and execute arbitrary commands as root.

Recommendation: Update to the latest patched ThroughTek SDK. Implement SDK version checking in firmware update flows.

---

V6: Firmware Updates via HTTP

Severity: HIGH CVSS 3.1: 8.1 (High)

Network captures show the camera initiating HTTP (not HTTPS) connections to CDN endpoints (Akamai, Tencent Cloud) on port 80. The firmware update mechanism sends the download URL to the camera via IOTC command 4631:

// AdvancedSettings.java
UpdateReq.setFile_url(resultBase.getData().getResult().getHost().getFilename().getBytes());

If the firmware URL uses HTTP, the download is unencrypted and subject to MITM replacement.

Impact: An attacker in a MITM position can intercept firmware download requests and serve malicious firmware, achieving persistent device compromise.

Recommendation: Use HTTPS exclusively for firmware downloads. Implement cryptographic signature verification of firmware images before flashing.

---

V7: IOTC Command Set Enables Full Device Control

Severity: HIGH CVSS 3.1: 8.0 (High)

Decompilation of the UBox APK revealed the complete IOTC command set (defined in AVIOCTRLDEFs.java). With valid credentials (obtainable via V1), an attacker can:

Command ID	Function
768/769	Start/stop live audio
816/817	Get device info
896/897	Format SD card
4631/4632	Push firmware update
4864/4865	List files
4866/4867	Download files
4868/4869	Upload files
4874/4875	Delete files
8482/8483	Capture picture remotely
241/242	Set device UID

Command 241 (IOTYPE_UBIA_SET_UID_REQ) is particularly dangerous — it allows changing the device's P2P identifier, potentially hijacking it from the legitimate owner.

Impact: Full device takeover, data exfiltration, evidence destruction (SD card format), and device identity theft.

Recommendation: Implement command-level access control. Critical commands (firmware update, UID change, format) should require additional authentication or user confirmation via a separate channel.

---

V8: Cloud Infrastructure Enumeration

Severity: INFORMATIONAL CVSS 3.1: N/A

The complete cloud infrastructure is discoverable through APK decompilation and DNS analysis. The firmware OTA bucket (ubiaota.oss-cn-shenzhen.aliyuncs.com) was confirmed to exist and contain firmware files, though access is restricted to signed URLs.

This level of infrastructure visibility, combined with the leaked OSS access key ID (V2), could facilitate further attacks against the cloud backend.

---

V9: No Local Network Services

Severity: INFORMATIONAL (Architectural Observation)

The camera exposes zero inbound ports. While this prevents traditional network-based attacks (port scanning, brute force), it creates complete dependency on the vendor's cloud infrastructure. If the cloud service is compromised, discontinued, or suffers an outage, the device becomes non-functional and there is no local fallback.

This also means the device owner has no local control mechanism — all interaction must route through vendor servers in China, raising privacy concerns for users outside that jurisdiction.

---

V10: Multi-Brand Obfuscation

Severity: INFORMATIONAL

The same hardware/firmware/cloud platform is sold under multiple brand names:

• Javiscam
• Funstorm
• (likely others sharing UBIA/UBox platform with product IDs in the 1600+ range)

The TP-Link MAC OUI (14:92:F9) further obscures the actual manufacturer. Users cannot easily determine that their "Javiscam" and a neighbor's "Funstorm" share identical firmware, cloud infrastructure, and vulnerability surface.

---

V11: Improper Use of HTTP Status Codes for Authentication

Severity: MEDIUM CVSS 3.1: 5.3 (Medium)

All Endpoints

The API returns HTTP 200 for all requests regardless of authentication status. Authentication failures are communicated only through the JSON response body ({"code": 10004, "msg": "token不能为空"}). The API never returns HTTP 401 or 403.

This was discovered during automated fuzzing: every endpoint returned HTTP 200 with any token, no token, invalid tokens, and SQL injection payloads in the token field. Manual verification confirmed that the application-level code field correctly rejects unauthenticated requests (code 10004), but the HTTP transport layer provides no indication of failure.

Impact:

• Standard security tooling (WAFs, API gateways, SIEM, monitoring dashboards) that relies on HTTP status codes will not detect or alert on authentication failures
• Rate limiting rules based on 401/403 response codes will never trigger
• API monitoring cannot distinguish between successful and failed auth attempts from HTTP logs alone
• Automated scanners and vulnerability tools may report false positives (as observed during this assessment)

Recommendation: Return HTTP 401 for authentication failures and HTTP 403 for authorization failures, in addition to the application-level error codes. This provides defense-in-depth and enables standard security infrastructure to function correctly.

---

V12: Unauthenticated Firmware Version Check

Severity: MEDIUM CVSS 3.1: 5.3 (Medium)

Endpoint: POST https://portal.ubianet.com/api/user/check_version

Automated fuzzing with application-level response code verification confirmed that user/check_version returns {"code": 0, "msg": "success"} without any authentication token. This was the only user-scoped endpoint (out of 27 discovered) that returned a successful application-level response without credentials.

While the endpoint returned empty data in our tests (the correct internal parameters were not determined), the lack of authentication means an attacker could potentially:

• Enumerate device firmware versions if the correct parameter format is discovered
• Obtain firmware download URLs for specific device models
• Determine which devices are running outdated/vulnerable firmware

Additionally, several PTZ snapshot endpoints (user/del_ptz_snap, user/confirm_ptz_snap, user/put_ptz_snap) returned code: 0 with authenticated requests using empty parameters — suggesting these operations may execute without requiring valid target parameters.

Recommendation: Enforce authentication on all endpoints consistently. Validate that required parameters are present before processing requests.

---

V13: Endpoint Enumeration via Consistent Error Responses

Severity: LOW CVSS 3.1: 3.7 (Low)

Automated endpoint fuzzing revealed that the API returns distinguishable responses for existing vs. non-existing endpoints: existing endpoints return HTTP 200 with application-specific error codes (e.g., {"code": 10001, "msg": "invalid params"}), while non-existing endpoints return HTTP 404. This allows an attacker to enumerate all valid API endpoints without documentation.

27 active endpoints were confirmed through this method, including undocumented ones not referenced in the mobile application's current version.

Recommendation: Return consistent error responses for both invalid endpoints and valid endpoints with bad parameters. Consider rate limiting API requests to slow enumeration.

---

4. Attack Scenarios

4.1 Local Network Attacker

1. Attacker joins the same WiFi network as the camera
2. ARP spoof to MITM the camera's traffic
3. DNS spoof portal.ubianet.com to attacker's server
4. Due to disabled SSL validation (V4), the camera connects to the fake server
5. Attacker captures IOTC credentials from the handshake
6. Using those credentials, attacker connects to camera via P2P for live video/audio

4.2 Cloud API Attacker

1. Attacker compromises a UBox user account (weak password hashing, V3)
2. Calls user/device_list to obtain camera credentials in plaintext (V1)
3. Connects to camera via ThroughTek P2P using leaked cam_user/cam_pwd
4. Full device access: live video, audio, file access, firmware push

4.3 Firmware Supply Chain Attack

1. Attacker performs MITM on camera's network
2. Camera checks for firmware update via HTTP (V6)
3. Attacker intercepts the firmware URL and serves malicious firmware
4. Camera flashes the malicious firmware (no signature verification)
5. Attacker achieves persistent root access

---

5. Disclosure

This research was conducted on hardware owned by the researcher for educational purposes. No unauthorized access to third-party devices or accounts was performed.

Findings are being documented for coordinated disclosure to:

• UBIA Technologies Co. (vendor)
• ThroughTek Co., Ltd. (P2P SDK vendor)
• CISA (for CVE coordination if applicable)

---

6. Conclusion

The UBIA/UBox camera ecosystem demonstrates a pattern common across low-cost IoT devices: a polished user experience masking fundamental security failures. The cloud-first architecture with no inbound ports creates an illusion of security, while the cloud API freely distributes device credentials in plaintext. Disabled SSL validation makes MITM attacks trivial. The use of a P2P SDK with known critical vulnerabilities compounds the risk.

The multi-brand sales strategy means these vulnerabilities affect an unknown — but likely large — number of devices across brands that consumers cannot easily correlate.

The most impactful finding is V1: the cloud API returns camera admin credentials (cam_user/cam_pwd) in every device list response. This single design decision means that any cloud-side breach, account compromise, or API interception immediately yields full access credentials for every camera on the account.

For consumers: these cameras should not be used in any context where privacy is critical. Network isolation (dedicated VLAN with no internet access) would mitigate cloud-based attacks but render the camera non-functional due to its cloud dependency.

For manufacturers: the recommendations in each vulnerability section should be implemented. The highest priority items are removing credentials from API responses (V1), enabling SSL certificate validation (V4), and updating the ThroughTek SDK to the latest patched version (V5).

---

7. References

1. Bitdefender Labs. "Notes on ThroughTek Kalay Vulnerabilities and Their Impact on the IoT Ecosystem." May 2024.
2. CISA. "ThroughTek Kalay P2P SDK." Advisory ICSA-21-229-01. August 2021.
3. Unit 42, Palo Alto Networks. "CVE-2021-28372: How a Vulnerability in Third-Party Technology Is Leaving Many IP Cameras Vulnerable." 2021.
4. Nozomi Networks. "New IoT Security Risk: ThroughTek P2P Supply Chain Vulnerability." 2021.
5. ThroughTek. "About ThroughTek's Kalay Platform Security Mechanism." 2024.
6. OWASP. "IoT Security Verification Standard." 2024.

---

Appendix A: Network Capture Summary

Source	Destination	Protocol	Port	Description
Camera	Tencent Cloud (6 IPs)	UDP	10240	P2P relay
Camera	AWS Frankfurt	UDP	123	NTP
Camera	Alibaba Cloud	UDP	123	NTP
Camera	Akamai CDN	TCP	80	Connectivity check
Camera	Tencent Cloud	TCP	80	Connectivity check
Camera	Router (DNS)	UDP	53	DNS queries
Camera	10.0.0.27	ARP	-	Phone (ubox app)
Camera	10.0.0.243	ARP	-	WireGuard host

Appendix B: IOTC Command Reference (Partial)

Extracted from AVIOCTRLDEFs.java:

ID	Name	Direction
241	SET_UID_REQ	App -> Camera
768	AUDIOSTART	App -> Camera
769	AUDIOSTOP	App -> Camera
816	DEVINFO_REQ	App -> Camera
896	FORMATEXTSTORAGE_REQ	App -> Camera
4629	FIRMWARE_UPDATE_CHECK_REQ	App -> Camera
4631	FIRMWARE_UPDATE_REQ	App -> Camera
4864	FILE_LIST_REQ	App -> Camera
4866	FILE_DOWNLOAD_REQ	App -> Camera
4868	FILE_UPLOAD_REQ	App -> Camera
4874	FILE_DELETE_REQ	App -> Camera
8482	CAPTURE_PICTURE_REQ	App -> Camera

Appendix C: API Endpoint Map

Discovered via APK decompilation:

Endpoint	Auth	Method	Purpose
/api/v3/login	No	POST	Authentication
/api/user/device_list	Yes	POST	List devices + creds
/api/v2/user/device_list	Yes	POST	Device list v2
/api/user/families	Yes	POST	Account groups
/api/user/cloud_list	Yes	POST	Cloud recordings
/api/user/event_calendar	Yes	POST	Event history
/api/user/get_cloud_video_url	Yes	POST	Video URLs
/api/user/qry/device/device_services	Yes	POST	Service status
/api/user/qry/device/check_version/v3	Yes	POST	Firmware check
/api/user/check_version	Yes	POST	Version check (legacy)
/api/temp_token	No	POST	Temporary token
/api/reset_pwd	Yes	POST	Password reset
/api/send_code	No	POST	Verification code

---

This document is the intellectual property of Setec Labs. Distribution is authorized for the purpose of improving IoT security through responsible disclosure and education.