Home
//
projects
//
hardware-security-assessment-10-iot-camera-firmware-analysis
ProjectSeptember 15, 2026

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.

FirmwareAnalysisJooan

IoT Part 3 Thumbnail

# 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.

IoT Part 3 Flash Chip

## 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.

CH341A in-cricuit flash connected

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.

Pasted image 20260911003022

## 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).

Pasted image 20260911131743

## 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:

code
 binwalk -e dump.bin

The command ran successfully and I now have access to the file system. Pasted image 20260911003401

Pasted image 20260911003439

# 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.

Unit in handA2R-U unit
WhatsApp Image 2026-04-12 at 18.58.26IoT Part 3 Real Jooan Camera

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.

Pasted image 20260911132423

## 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

Pasted image 20260911132512

Network analysis from earlier reconnaissance identified the camera's IP address.

The default path is

code
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.

Iot Part 3 RTSP worked

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:

  1. Not documented to the end user
  2. Reused across multiple services (RTSP, ONVIF, web UI)
  3. 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.

StepActionOutcome
1Disconnect power, connect SOIC-8 clipPhysical link created
2Erase flash chipProcess completed successfully
3Write the patched patched.binSuccessful verification against original
4Turn on the deviceCustom start-up tone heard

Device booting with modified audio — arbitrary code execution confirmed

## Security Implications

This modification demonstrates:

FindingImpact
Lack of Secure Boot/Firmware Signature ValidationArbitrary code execution is allowed across reboots
No filesystem integrity validationAltered binaries execute without any warnings
Flash memory chip is accessible without disassemblyPhysical attack involves SOIC-8 clip only

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.

FindingSeverity
Hardcoded, undocumented RTSP credentialsHigh
Password reuse across multiple services (RTSP, ONVIF, Web UI)Medium-High
Unencrypted credential storage in firmwareMedium
Firmware modification enabling persistent code executionCritical

## 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

ProductStatusNotes
Unbranded A2R-U variant (this research)Confirmed vulnerableFirmware dump analyzed
Jooan A2R-ULikely vulnerableSame hardware/firmware base
Other Jooan models using Cam720 platformPotentially vulnerableShared codebase suspected

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:

CriterionAssessment
Independent of other issuesYes — each vulnerability is exploitable standalone
Recognized security impactYes — unauthorized surveillance, credential exposure, persistent compromise
Affects shipping productYes — consumer devices actively sold and deployed
Not intended behaviorYes — undocumented backdoor credentials contradict stated security model

# 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