Hardware Security Assessment: $10 IoT Camera Firmware Analysis
Part 3 of the IoT camera research series. In this part, I extracted the firmware directly from the camera's flash chip. I used a CH341A programmer with an SOIC-8 clip, so I did not need to desolder the chip. Analysis of the firmware revealed an active RTSP video stream, enabled by default. I also found hardcoded credentials stored without encryption. The same password worked across multiple services on the device. I modified the firmware and reflashed it to the camera. I changed the startup sound as proof of persistent code execution. The device accepted the modified firmware without any warning. This confirms the device has no secure boot and no firmware signature check.

# TL;DR
I got the appropriate tools to dump the camera's firmware directly from the camera's flash chip. I managed to get it off, and now I have a complete "copy" of the device's firmware to analyze.
When examining the firmware, a number of important features were discovered. Firstly, unlike what I thought, RTSP was not disabled, it is active and available. Stream credentials were found in a configuration file in the firmware image.
The string "Jooan" was found during the firmware analysis, and further investigation has found that it is a version of a camera model that was rebranded as Jooan A2R-U and is manufactured by China. This I verified by comparing Jooan's product lineup and finding an eBay listing for the A2R-U that had the same hardware as the unit had.
I also found other hardcoded secrets in the firmware - in addition to the RTSP credentials.
Lastly, I was able to modify the firmware image and reflash it on the device. As an example of such code execution, I changed the sound the camera plays during startup, a proof of persistent arbitrary code execution on the camera.
# Firmware Extraction
With UART access unavailable (RX pin disabled), direct flash extraction was the only viable path to obtain the firmware. The process required identifying the flash chip, establishing a physical connection via an in-circuit clip, and dumping the contents using a CH341A programmer.
The camera's PCB was inspected to locate the SPI flash chip. Based on the package type and pinout, the chip was identified as a GB2528 ZB25Q64DSIG P4H862 — a 64 Mbit (8 MB) Serial NOR Flash.

## Connection Setup
The CH341A USB programmer was used with an SOIC-8 in-circuit clip, allowing chip-off extraction without desoldering. Neoprogrammer was selected for compatibility with the CH341A hardware.
The clip's pinout was verified against the programmer software's chip-specific diagram to ensure correct orientation (pin 1 alignment) before applying power.

The closest flash chip available in the software is ZB25Q64, selecting it in the programmer software tells me how to connect the clip to programmer.

## Dumping Firmware
A full read of the flash contents was performed. The resulting binary image (8,388,608 bytes) was saved and verified against a second read to ensure data integrity (hashes matched).

## Filesystem Extraction
Initial analysis with binwalk revealed a U-Boot bootloader and a SquashFS filesystem. The following command was used to extract the filesystem for further analysis:
binwalk -e dump.binThe command ran successfully and I now have access to the file system.


# Identifying Jooan Evidence
## "Jooan" String Present
While conducting analysis on the filesystem, it was found that the string "Jooan" is present many times across the firmware, in configurations, binary locations, and UI strings. This indicates that this string may be related to a manufacturer or an OEM.
## Software Corroboration
Both devices make use of the Cam720 mobile and desktop application during setup and for streaming purposes. The shared software environment reinforces the hardware connection further in that the mobile application is linked to the device through its QR code or UID.
## Manufacturer Identification
Jooan is a Chinese company that specializes in producing consumer IP cameras and surveillance devices (Shenzhen Jooan Technology Co., Ltd.). Use of branding of the manufacturer in the firmware pointed to the possibility that the device was made either by Jooan or based on their OEM design.
## Model Correlation
Matching Jooan products by cross-reference revealed the A2R-U as the hardware equivalent. Visual inspection proved that the device under investigation is a rebranded version of this device with an identical enclosure design, lens arrangement, and PCB layout.
With that I can find public information like the exact URL for RTSP, default credentials etc.
# RTSP Evidence
## Initial Hypothesis
Past network recon did not show an RTSP service running, which prompted the hypothesis that the stream is disabled by default and needs to be enabled through firmware changes. This was proven wrong through the analysis of the extracted file system.
## Configuration File Evidence
Examination of the camera's configuration files revealed an RTSP server configuration block, confirming the service was not only present but enabled by default.

## Default Credential Testing
The iSpyConnect database documents default credentials and stream paths for Jooan devices. For the A2R-U platform, the documented defaults are: plain rtsp://admin:admin@192.168.1.20/live/ch00_0

Network analysis from earlier reconnaissance identified the camera's IP address.
The default path is
rtsp://admin:admin@192.168.1.20/live/ch00_0## Credential Analysis
Test results showed that the password "admin" was not correct. The configuration file verified the username to be "admin," but the password had a different hash format. Analysis through the hash identifier did not yield any results for common hash types such as MD5, SHA-1, SHA-256, NTLM, etc.
## Password Recovery
Adjacent to the RTSP configuration block the password of another service (most likely ONVIF or web management) in plaintext was found. The password worked for RTSP authentication, providing access to the stream.

The on-screen timestamp shown in the RTSP stream is inaccurate. The camera's internal clock is misconfigured and does not reflect the actual capture time.
## Security Implications
The RTSP service is accessible without user configuration, protected only by a password that is:
- Not documented to the end user
- Reused across multiple services (RTSP, ONVIF, web UI)
- Recoverable from unencrypted firmware storage
# Firmware Patch
## Objective
Provide evidence of continued code execution through the modification of the camera's startup audio by replacing the OEM startup audio with custom audio. This will act as the proof-of-concept of the ability to modify and reflash the firmware without triggering the security mechanisms of the device.
## Audio File Identification
Analysis of the extracted filesystem identified the audio files responsible for startup sounds.
## Size Constraint Analysis
At first, the new audio had been designed to be the same size, byte by byte, as the original file in order to prevent corruption or failure of the file system or booting. But analysis of the firmware binary showed that there seems to be some sort of padding between sections, almost like it was made for this situation.
## Patch Construction
A custom audio file was prepared and renamed to match the OEM filename exactly, ensuring the bootloader would locate and play it without modification to the startup scripts.
The modified files were repackaged into a complete firmware image.
## Flashing & Verification
The new firmware was flashed to the flash chip through the use of the same CH341A programmer and Neoprogrammer software as before.
Device booting with modified audio — arbitrary code execution confirmed
## Security Implications
This modification demonstrates:
An attacker with just some time of physical access to a target system can install firmware that will allow for covert monitoring, credentials dumping, or pivoting attacks, and the only noticeable thing about such attack would be an altered startup tune (or its complete absence).
# Impact & Disclosure
## Security Impact
Vulnerabilities found in the research can pose serious threats to users of these devices as well as network security. The results can be considered CVE-worthy and require proper coordination with the vendor.
## Attack Scenarios
Local Network Attack:
An attacker who has access to the same LAN segment will be able to:
- Detect the existence of the camera through ARP scan or mDNS broadcast
- Gain authentication to RTSP based on information acquired from firmware analysis or extraction through physical means
- View live video and audio feeds without the knowledge of the user
- Pivot to other network components through the camera
Supply Chain / Pre-Compromise:
- The firmware has credentials that are valid to all devices in this type
- Lack of per-device uniqueness in cryptographic keys
- If the firmware is compromised, all devices are compromised
Physical Access Attack:
- Flash extraction gives full firmware, which contains all secrets
- Reflash with modified firmware creates an undetectable backdoor for persistent surveillance (modification of the boot sound proves code execution capability)
- The attack can survive a factory reset and firmware updates
## Affected Products
Note: Jooan operates as an OEM/ODM; additional rebranded variants may exist under different market names.
## Recommended Mitigations
For End-Users:
- Segment Camera from its own VLAN/Guest Network
- Restrict access to Cam720’s cloud services if running locally only is tolerable
- Physically protect device, treat as untrusted if attacker has access to device previously
For Vendor (Jooan):
- Create unique credentials for each device at its first boot time
- Use encrypted credential storage in the firmware (using TPM or secure enclave)
- Isolate credentials depending on service used (RTSP, ONVIF, Web UI)
- Support Secure Boot to prevent unauthorized firmware updates
- Provide security contact and vulnerability disclosure process
## CVE Justification
These findings meet CVE assignment criteria:
# Conclusion
An investigation into the Jooan A2R-U repackaged camera shows security flaws that are prevalent in cheap IoT devices: undocumented RTSP service, reversible hardcoded authentication and lack of firmware protection. The fact that the firmware could be extracted, modified and reflashed proves that these flaws are not just information exposure vulnerabilities, but can also lead to persistent and stealthy compromises. These vulnerabilities are under consideration for CVE ID. Manufacturers and customers of such devices should assume complete compromise in case of physical access.
A Note on CVE Submission
I have not decided yet if I will submit this for a formal CVE ID. The findings meet the basic criteria for one, but I want to think through vendor disclosure first rather than publish and file at the same time. If I do pursue it, I will update this post with the CVE ID and disclosure timeline

