# Introduction

After being stalled by a faulty RX pin on the UART interface in a prior hardware-level analysis, I turned to the network layer. This latter effort is focused on capturing and decoding the packets of data sent to and from the camera to determine the underlying tech stack and possible entry points.

---

# Methodology

Since the hardware interface proved to be not so reliable, I resorted to a wireless traffic analysis. The camera will act as a local Access Point (AP), and it can be hardwired to the device and a smartphone app. I took advantage of this network of ad-hoc that I was at the center of communication channel.

I then hooked my workstation to the hot spot that the camera was transmitting and began to capture using Wireshark. In order to have a comprehensive dataset, I conducted a 10-minute Functional Walkthrough, which elicited certain actions:

PTZ Commands: Pan and Tilt requests are sent to find movement related opcodes. Media Requests: Sent to find high bandwidth data transfer. Keep-Alives: Measuring the heartbeat between the camera and client.

Since the hot spot of the camera is a closed network, which is not externally routed, I saved the session in the form of a pcap file. The migration to a machine with full internet access enabled me to cross-reference the found IP addresses with known cloud providers and look up the proprietary OUI (Organizationally Unique Identifiers) of the MAC addresses.

---

# Findings

1. The packets of the video feed share the same hex header that (from the research I've done) is of unknown file type, indicating that the Video feed is encrypted. The absence of JPEG magic bytes (FF D8 FF), MPEG-TS markers (47 47), or H.264 NAL units (00 00 00 01) further confirms the video stream is encrypted, not compressed or raw.

2. Traffic flows through WireGuard VPN tunnel.

3. The encryption algorithm/protocol seems to be proprietary since it is running using an unusual port (34593).

4. The camera checks for internet access by sending requests to msftconnect.com. This is a standard captive portal detection mechanism, but on an IoT device it also serves as a heartbeat to confirm internet availability. The device likely fails to function or degrades gracefully if this check fails.

5. Bidirectional communication is taking place. After a few video feed packets sent to my machine, a smaller request is sent back from my machine to the camera. Because of encryption, I can't tell for sure what it is but a safe assumption would be that that request is ACK.

6. There are DNS requests going to "us-c-master-rksera4488ffwtalxew9.iotcplatform.com". This might happen in order to save footage to the cloud for remote access for the user, however, this might be a manufacturer backdoor. The structure of the endpoint suggests the following; us-c = US region, master = master server.

7. All traffic remains within the local 10.68.68.0/24 network during normal operation. Video transmission (port 34593) is bidirectional and local-only. While this prevents external threats, internal threats are unaffected by this.

---

# Limitations

1. Lack of transparency: Manufacturer does not document the encryption algorithm, key derivation method, or what metadata is transmitted through the WireGuard tunnel.
2. Cannot decrypt WireGuard VPN traffic — Encrypted tunnel to manufacturer's server obscures what metadata is being transmitted. Requires VPN private key to decrypt.
3. RX remains unavailable: console is set to null so inputs I provide are ignored.
4. Encryption algorithm unknown — Video stream encryption method (AES, proprietary, etc.) cannot be determined without firmware analysis or app reverse engineering.

---

# Threat Model

An attacker who gains access to the manufacturer's iotcplatform.com infrastructure might:

1. View live video feeds from any camera
2. Issue pan/tilt commands remotely
3. Extract usage patterns and timestamps
4. Potentially extract encryption keys for offline video decryption
5. Pivot to other cameras on the same infrastructure

The mandatory WireGuard tunnel means the manufacturer has inherent access to all these capabilities.

---

# Next Steps

The device is essentially a black box between a failed RX line that doesn't allow shell access, and a forced VPN tunnel obscuring the network logic.

Next Steps: To proceed, I will have to quit gazing at the lines (UART/Network) and begin gazing at the brain. The second step will be a SPI Flash Dump - literally removing or clipping into the BIOS chip to recover the firmware binary to reverse engineer offline.

Another step I am contemplating is reverse engineering the app itself, maybe is exposes hardcoded credentials or keys. Perhaps I could find the decryption algorithm and use that to decrypt packets.

---

## Disclaimer

This is an educational analysis by a cybersecurity student. I am investigating the security design of this device to know IoT design patterns and security practices.

This analysis is not meant to be an imputation of misconduct upon the producer, nor is it an official vulnerability report.

The results are my observations and insights into artifacts of network traffic. I am simply thinking out loud and recording my process and logic.

Some conclusions can be hypothetical, pending full information, and I am open to modifications or other interpretations.

This report is meant to be educative and to better my understanding of hardware security analysis, network reconnaissance, and reverse engineering techniques.

Date: April 2026
Device: $10 Budget IoT Camera (Ingenic XBurst T23)
Analyst: Awaab Kheiri (Cybersecurity Student, APU)