# 1. Introduction ## 1.1 Disclaimer et objectifs This article follows a talk I gave at the Forum International de la Cybersécurité (FIC). After my presentation, a large number of people asked me to publish a detailed article on the subject. That’s one of the reasons I created this blog: to share my research and findings in a way that’s accessible to everyone.

In this article I will present several vulnerabilities that affected many security cameras; notably cases of 0-click code execution, whether via the network or… through the air (yes, really — without sending anything at all). Vulnerabilities still active Despite my follow-ups and the discovery that several “white-branded” cameras come from the same manufacturer, these vulnerabilities remain active. This article is by no means an exploitation tutorial. I disclaim all responsibility for malicious use or any damage caused.

This analysis is divided into two parts to make it easier to read and to keep a clear approach: - **First part**: this article, which focuses on the preliminaries. It presents the macroscopic operation of the cameras, the associated mobile application, the network flows and the observable entry points. The goal is to provide a concise general framework. - **Second part** : dedicated to an in-depth technical analysis of the firmware, with a focus on reverse engineering, extraction and identification of exploitation chains.

These two articles do not claim to cover every aspect of the analysis. Some notions may remain partial or require further clarification. That’s why additional complementary content, notably *[Pentest IoT 101](/blog/pentest-iot-101)* series, is available to deepen certain concepts and techniques. Pentest IoT 101 Discover how to ... This first article **is not a prerequisite for reading the second**, but it provides essential context to better understand the technical analysis that will follow. ## 1.2 Contexte Let’s be honest: today, who doesn’t have at least one connected object at home? Between the smartwatch, the voice assistant or the little surveillance camera, these gadgets have settled into our homes almost without us noticing.

One day I needed a Wi-Fi connected surveillance camera. No way I was going to spend €300 on a “pro” solution, so I opted for an “all-in” camera — like the ones you find in stores or homes. I bought two; when configuring them I discovered you had to pay a subscription to access the images remotely. True to my habits, I wanted to take a look “under the hood” to redirect the streams elsewhere… and that’s where I made some rather surprising discoveries. ## 1.3 Presentation of the targets As mentioned above, I bought two cameras. One on eBay for a handful of euros (€30) and the other at a very, very well-known discount hypermarket in Europe (not naming it — Action) for €60. The two cameras behave quite similarly and cover the same needs — and apparently… they are successful! Lots of people buy these things, so they must be good quality, right? ![LSC PTZ Camera](https://directus.cri.local/assets/4797d75e-2491-4177-a37d-2b475c337d1b) ![Yi IoT](https://directus.cri.local/assets/72b76d1d-e7d3-4efc-bceb-eb6fe68d4051) # 2. Understanding how an IoT camera works ## 2.1 General architecture Like most connected devices that handle images (cameras, baby monitors, intercoms, etc.), they typically run a small Linux distribution — for reasons of cost, productivity and development ease.

Imagine it as a slimmed-down Raspberry Pi: powerful enough to run drivers, manage sensors and transmit data, but without a GPU, with far less RAM and none of the components that are too power-hungry or expensive. In other words, these devices are limited for heavy computations and high-resolution processing. To go further If you want to learn more about the actual operation of an IoT device, I recommend [the following article](https://www.toradex.com/blog/using-cameras-in-embedded-linux-systems).It explains not only some key embedded principles, but also how to build one. ## 2.2 Key takeaways This is not the main topic of this article (there would be too many edge cases and details to cover) but to properly approach IoT pentesting, keep in mind that: - **It’s Linux**: same attack surfaces as a PC (kernel, network services, permissions, updates). - **It exposes interfaces** : Wi-Fi, Ethernet, Bluetooth, FTPS/SFTP, REST APIs, MQTT, open ports. In short, a small network server. - **The mobile phone is often present** : the mobile app serves as the UI, a network proxy and sometimes as an offloaded compute engine. This changes attack vectors (e.g. interception phone < - > device). Some manufacturers use the phone as a proxy to reduce costs or simplify architecture. We too often forget that our phones today contain more resources than ten Deep Impact space probes. # 3. Configuring an IoT camera ## 3.1 Access and setup Because we rarely have direct access to the camera or its configuration files, IoT device setup almost always happens via a mobile application. ![Example of configuration via Access Point](https://directus.cri.local/assets/253ae9eb-6f6f-4fa7-b70b-d03ddcdf907f) Here, both cameras use the same type of application and the same configuration flow. Concretely, these apps offer two main methods to configure a camera: - **Wi-Fi direct (mode AP)** : the camera becomes an access point (AP). The app connects to this temporary local network and directly sends the Wi-Fi credentials and configuration to the camera. - **QRCode** : the app generates a QR code which the camera scans. This QR code contains the necessary information (Wi-Fi credentials, pairing token, etc.) to connect the camera and link it to the account/app. # 4. Network analysis Once the camera is connected, it can be very interesting to listen to the network traffic — notably the traffic that occurs at boot. Why? Because that traffic fairly well describes the internal operation of the connected object.

One of the most common vulnerabilities in this kind of analysis concerns encryption of data in transit. Concretely, in the case of a MITM (Man-In-The-Middle) attack, an attacker could intercept and decrypt communications, thereby accessing sensitive information — for example login credentials, video streams or internal API requests. ![Example of MiTM attack scenario allowing an attacker to intercept an unencrypted firmware update and inject malicious code](https://directus.cri.local/assets/802f8b1c-7af5-48e5-9688-e77e1201ceed) Take the case of a firmware update: if the communication is not properly encrypted — or if the authenticity and integrity of the firmware are not verified — an attacker positioned between the device and the server can not only intercept the update, but also inject, modify or remove pieces of code in the downloaded image. Practically, that could allow them to insert a backdoor, modify the boot logic, or achieve remote code execution (RCE) as soon as the device applies the update. ## 4.1 Setting up the MITM The classic MITM method (or at least the one I prefer) often involves using ARP-spoofing. To understand what ARP-spoofing does, you must first grasp the role of ARP: the Address Resolution Protocol maps an IP address (layer 3) to a MAC address (layer 2). When a machine wants to send a packet to an IP on the same local network it asks “Who has this IP? Give me your MAC.” The reply is cached in the sender’s ARP table to speed future exchanges. ![Example of an ARP‑spoofing attack redirecting local traffic to the attacker, enabling packet inspection and modification](https://directus.cri.local/assets/77db09e8-3e4b-40c3-88df-233864dde6b6)

ARP-spoofing takes advantage of the fact that this table is considered trusted: an attacker sends fake ARP replies to associate their MAC with the gateway’s IP or another host’s IP. Result: packets destined for the gateway go through the attacker, who can read, modify or redirect them.

Once the attack is launched, you can start visualizing the network traffic with a packet analyzer (for example Wireshark). You can apply filters to display only packets from a given IP, a specific protocol, or a particular port — very handy for isolating relevant exchanges. Wireshark tips If it’s your first time with Wireshark or you want to level up, I strongly recommend consulting chapter 7 of the official documentation. It covers advanced filtering and analysis techniques that will save you a lot of time.

In our case, placing myself in a MITM position and inspecting the packets with Wireshark, I quickly noticed a large number of outbound HTTP requests. I emphasize that I had only connected the camera to the network: no cloud account creation, no explicit authorization to connect to the service. Despite that, the vast majority of requests targeted IP **47.254.183.205** (domain **plt-api-de.xiaoyi.com**). ![Example of outgoing data streams regularly transmitted by the camera to the cloud provider plt‑api‑de.xiaoyi.com](https://directus.cri.local/assets/751e553e-f0f6-462d-aba9-277b0e32d7d9) The domain **plt-api-de.xiaoyi.com** exposes an **Apache Tomcat 9.0.40** server (incidentally a version known to have several CVEs). After some enumeration tests, I found an endpoint that, when firmware versions are compatible and a new firmware image is available, allows downloading the latest firmware version. Having such an endpoint is interesting: it could have spared me from dumping the firmware manually (and therefore from having to buy an extra camera just to extract the image). Unfortunately for this analysis there was no new version available (checkout required): ![Server-side endpoint allowing retrieval of the published firmware image and triggering its download by devices](https://directus.cri.local/assets/3d9b572c-2a9a-456e-ad6b-915903f6014c) The camera also transmits sensitive information: I observed that it sends the SSID — and even the password — of the Wi-Fi network it is connected to. I am not an IoT product manufacturer, but what functional need does this really serve? What’s the point of transferring these credentials in cleartext to a third-party server? To those concerned, greetings. ![Cleartext transmission of the SSID and Wi‑Fi password to the cloud service](https://directus.cri.local/assets/6b7178e8-292f-46cf-8a5c-658e7ae304ef) Important clarification! I specify that no intrusive action was taken: no injection attempts, exploitation or compromise of the domain were performed. The purpose of this analysis is purely observational and educational. The service in question, while imperfect in terms of security (and possibly ethically questionable), is still used by many users — probably without their knowledge. Having received no authorization for penetration testing, I strictly limited myself to passive analysis, in accordance with best practices and professional ethics. # 5. Physical teardown and hardware analysis Here we want to access the camera’s system to retrieve the firmware or at least obtain a root shell. We have two main approaches: connect via UART (the easiest) and then, if authentication blocks us, force U-Boot to fail to return to its prompt and modify boot parameters. ## 5.1 Physical Teardown of the Camera The first step of the analysis is to disassemble the camera to access its circuit board. The two models examined have an almost identical internal architecture and share most of their components. Once opened, the two boards are displayed side by side: ![Camera motherboard (front side)](https://directus.cri.local/assets/8797479a-d534-49d1-a6c7-b08b01f548d5) ![Camera motherboard (back side)](https://directus.cri.local/assets/af02bc5a-81f7-48e5-a39e-4f3a4d4313f2) At the center of the device is the AK3918 SoC, an ARM processor that integrates the watchdog, memory management and several communication interfaces (UART, SPI, JTAG…). This component plays a central role as it aggregates the system’s computation and control functions. Beside it, the SV6256P Wi-Fi module provides wireless connectivity, while the FM25Q64 serial flash stores the firmware and operating system partitions. ![Functional diagram highlighting the central SoC, Wi‑Fi module, and flash memory used by both models](https://directus.cri.local/assets/895898ed-69fc-46d5-bf07-7746f94c1d12) These three elements form the core of the camera: the SoC handles processing and essential peripherals, the Wi-Fi module enables network communication and the SPI flash preserves the software data necessary for boot and operation. The analysis will focus mainly on the SoC and the flash memory, because they offer the most interesting entry points for hardware and software exploitation. # 6. Camera Exploitation ## 6.1 Gaining a Shell on the Camera ### 6.1.1 UART Connection Initial access is performed via the UART (Universal Asynchronous Receiver/Transmitter) interface, an asynchronous serial protocol widely used for debugging embedded systems. We covered this in detail in the Pentest IoT series, which I invite you to consult! IoT Pentesting 101 – Episode 1: Mastering UART Practical introduction to UART for IoT pentesting: identifying pins, methods (PCB inspection, multimeter, logic analyzer), secure wiring and configuration, and techniques for obtaining a console. On this board the UART pins are clearly marked, which makes the task easier. Simply connect TX, RX and GND to a USB–UART adapter, then open a terminal like minicom or screen. By trying different speeds, typically 115200 baud, you eventually see the system boot and the U-Boot bootloader appear. ![UART debug pins on the board provide direct console access for board analysis and debugging](https://directus.cri.local/assets/1beac5fc-3396-4470-9337-f6d79dd20a1d)

Once connections are in place, a serial terminal is opened with a tool such as minicom or screen. Then you need to determine the device’s baud rate — generally 115200 is a good starting point. A few tries are enough to obtain a readable output: the boot sequence displays, revealing the U-Boot bootloader sequence.

Explore my Tech Journey

Pentesting Insights • Fullstack Experiments • Tech Documentation & Beyond