This blog post is published for research and learning purposes only. It describes hardware analysis and firmware extraction techniques on a device we purchased and tested in a controlled lab environment. It is not an invitation to access, attack, or interfere with systems you do not own or do not have explicit written authorisation to test. Always follow applicable laws and responsible disclosure practices. CyberKartel is not responsible for misuse of the information in this article.
Device Overview
The target was a no-name 1080p WiFi IP camera purchased from a local electronics market for ₹500 (roughly $6 USD). It is the kind of device that ships in white-box packaging with no manufacturer branding, no documentation, and a single QR code on the bottom that links to a mobile app on the Play Store. The app handles "cloud" provisioning - scan the code, enter your WiFi password, and the camera is online. There is no web setup wizard, no firmware update mechanism exposed to the user, and no way to change credentials from within the app beyond setting a basic viewing password.
Inside, the device runs a Linux-based firmware on a Hisilicon HI3518E SoC - a chipset that powers a significant portion of budget IP cameras on the market today. The camera connects to a cloud relay service for remote viewing, meaning it maintains an outbound connection to a third-party server at all times. The mobile app communicates through this relay rather than connecting to the camera directly on the local network. This architecture is standard for the price segment, and as we'll show, it introduces a set of security failures that are equally standard.
We contacted the manufacturer 90 days before publishing this writeup. We received no response. All identifying identifiers - MAC addresses, serial numbers, cloud relay hostnames, and specific firmware build strings - have been redacted or genericised. This post is published for educational purposes and to demonstrate the systemic security failures common in budget IoT hardware.
Reconnaissance - Opening the Device
The camera's enclosure was held together by four Phillips-head screws hidden under rubber feet. After removing them, the shell popped open with a plastic spudger - no glue, no ultrasonic welds, no tamper-evident seals. Inside, a single PCB was secured by three more screws to the front casing. The board was cleanly laid out and labelled, which immediately made our job easier.
The PCB featured the Hisilicon HI3518E SoC under a small metal heatsink, a separate WiFi module (a common RTL8188-based board), IR LED array for night vision, a fixed-focus lens assembly, and a small electret microphone. But the most interesting feature was a set of four unpopulated through-hole solder pads sitting immediately adjacent to the SoC, silkscreen-labelled with barely legible markings. These are the hallmark of a UART debug interface - and on budget hardware, they are almost never disabled in firmware.
Identifying the UART Pins
A standard UART interface exposes four pins: VCC (power), GND (ground), TX (transmit), and RX (receive). We used a multimeter to identify each pad on the board. The process is straightforward and requires no specialised equipment:
- GND: Continuity check between each pad and a known ground point (the USB port shield or large copper fill). One pad showed zero resistance - that's ground.
- VCC: Powered the device on and measured voltage on each remaining pad. One read a steady 3.3V - that's VCC. We did not connect anything to this pin.
- TX: The transmit pin fluctuates between 0V and 3.3V during boot as the SoC sends boot messages over serial. We observed rapid voltage swings on one pad during the first few seconds of power-on.
- RX: The remaining pin. It sat at a steady 3.3V (idle high) and did not fluctuate. This is the receive pin - data goes in here, not out.
USB-to-UART adapter (CH340-based, ₹150 from the same electronics market), female-to-female jumper wires, a basic digital multimeter, a soldering iron (to attach header pins to the unpopulated pads), and minicom running on a Linux laptop. Total equipment cost: under ₹500. No oscilloscope, no logic analyser, no specialised hardware.
Gaining Serial Console Access
With the pins identified, we soldered a 4-pin male header to the unpopulated pads and connected the USB-to-UART adapter. The wiring is simple: the camera's TX connects to the adapter's RX, the camera's RX connects to the adapter's TX, and GND connects to GND. We left VCC disconnected - the camera is powered by its own supply, and backfeeding power through the UART adapter can damage both devices.
With the adapter plugged into the Linux laptop, we opened a serial terminal at 115200 baud - the default baud rate for Hisilicon-based devices. We then power-cycled the camera and watched the boot log stream across the terminal:
The device dropped us straight into a root shell. No login prompt. No password. No authentication of any kind. The boot console was configured with console=ttyAMA0 and the inittab spawned a shell on the serial port with getty bypassed entirely. We had full root access to the device's Linux filesystem in under 60 seconds - and we hadn't even needed to interrupt U-Boot.
What We Found Inside
With root shell access, we began systematically examining the filesystem. What follows are the four most significant findings, in order of severity.
Finding 1 - Hardcoded Admin Credentials
The /etc/passwd file contains plaintext passwords. There is no /etc/shadow file - the system doesn't use shadow passwords at all. The admin account has the password admin, and the guest account has the password guest. These same credentials are used across the web interface (port 80), the RTSP stream (port 554), and the Telnet service (port 23). The root account password absocute99 appears to be a build-time default that is identical across every unit of this model.
Finding 2 - Private SSL Key Exposed
The SSL private key (server.key) is stored in the firmware image with world-readable permissions (644). Worse, the same key is hardcoded across all units of this camera model - we verified this by extracting the key from three additional devices purchased from different batches and comparing the modulus hashes. This means anyone who downloads the firmware (or reads this post) can extract the private key and perform a man-in-the-middle attack against any camera of this model, decrypting its HTTPS traffic and intercepting credentials transmitted during the cloud relay handshake.
Finding 3 - Cloud Relay Credentials in Plaintext
The cloud relay configuration is stored in a plaintext JSON file readable by any user on the device. The device_secret is a hardcoded authentication token used to register the camera with the relay server - it does not appear to be unique per device, suggesting it may be a shared fleet-wide secret. The encryption field is set to none, meaning video streams relayed through the cloud server are transmitted without any transport-layer encryption. An attacker who compromises the relay server (or any device on the same network) can intercept and view live camera feeds in plaintext.
Finding 4 - Telnet Running on Port 23
Telnet is an obsolete, unencrypted protocol that transmits credentials and session data in plaintext. The telnetd daemon is running on port 23 and listening on all interfaces (0.0.0.0), meaning it is accessible from the local network. Combined with the hardcoded credentials found in Finding 1 (admin:admin), anyone on the same WiFi network as the camera can gain a root shell over Telnet in seconds - no physical access required. There is no reason for Telnet to exist on a production firmware image; it is a debug service that was never removed before shipping.
Impact Assessment
The vulnerabilities above chain together to create a full compromise path - from physical access to remote root, from credential theft to mass surveillance. The following cards summarise each finding by severity:
Remediation Recommendations
None of these vulnerabilities require novel research or expensive engineering to fix. They are the result of shipping debug configurations to production and cutting corners on credential management. The following recommendations apply to this specific device, but also to the broader category of budget IoT cameras:
- Network segmentation: Deploy IoT cameras on an isolated VLAN with no internet access unless explicitly required. Firewall rules should restrict lateral movement between camera subnets and corporate/home networks.
- Change default credentials: If the device allows it, change the admin password immediately during setup. If it doesn't allow credential changes (as in this case), the device should not be deployed in any environment that handles sensitive activity.
- Disable cloud relay: If local network viewing is sufficient, disable the cloud relay feature entirely. If remote access is required, route traffic through a VPN rather than a third-party relay server with no transport encryption.
- Physical security: Treat the device as inherently compromisable upon physical contact. Deploy cameras in tamper-evident enclosures and monitor for unauthorised access to physical locations where cameras are mounted.
- Consider replacement: For devices where the vendor has not responded to disclosure and no firmware update is available, the only reliable remediation is replacement with hardware from a manufacturer that provides timely security updates and disables debug interfaces in production firmware.
Responsible Disclosure Timeline
| Date | Action |
|---|---|
| Mar 15, 2026 | Vulnerabilities discovered during a routine IoT security assessment of budget surveillance hardware. |
| Mar 17, 2026 | Vendor contacted via support email with a full technical report, proof-of-concept steps, and remediation guidance. |
| Mar 30, 2026 | Follow-up email sent. No response received from the manufacturer. |
| Apr 15, 2026 | 90-day responsible disclosure deadline reached. No patch, no acknowledgement, no response. |
| May 1, 2026 | Public disclosure published with all identifying identifiers redacted for educational purposes. |
As of publication, the vendor has not responded to any of our communications. No firmware update has been released. The vulnerabilities described above remain open in firmware version 2.1.x and earlier. If you are deploying budget IP cameras in your environment, assume they have similar issues unless independently verified.
Conclusion
A ₹500 IP camera with an exposed UART port, hardcoded credentials, a shared SSL private key, and an open Telnet daemon is not an anomaly - it is the norm for budget IoT hardware. The economics of this market segment reward cutting corners: manufacturers compete on price, not security, and the result is devices that ship with debug interfaces enabled, default passwords in plaintext, and encryption that exists in name only.
The fixes are not complicated. Remove debug interfaces from production firmware. Generate unique SSL keys per device at provisioning time. Force a credential change on first boot. Disable unused services. None of these require significant engineering effort - they require a vendor that treats security as a release requirement rather than an afterthought. Until that changes, the burden falls on the deployer to understand what they're putting on their network.
If you are deploying IoT devices - cameras, sensors, access controllers, industrial controllers - and want to know what's actually inside them, we can run the same analysis against your hardware. We find what others miss. Get in touch.