Hikvision Intercom RE

Introduction

Commercial video intercom systems are found at the entrance of most buildings. Older analog systems are steadily being replaced by TCP/IP-connected units that offer video calling, face recognition, and cloud management at consumer prices. The Hikvision DS-KV6113-WPE1(C) is one such device — widely deployed in residential and commercial buildings across Europe and Asia.

DS-KV6113-WPE1(C) front view

This research analyses the firmware extracted directly from the device’s flash chip via chip-off read, covering static binary analysis, automated CVE correlation, cryptographic material extraction, and privacy-relevant behavior discovery.

PCB Analysis

The device uses two PCBs joined via a mezzanine connector. The primary board carries the HK-2019-A16B TRXM7500 SoC (Hikvision custom, Hi3516CV300 core) and the MX25L25645G 256Mbit SPI NOR flash IC — the sole persistent storage for the entire firmware. The secondary board handles PoE, voltage regulation, and external connectors.

The flash IC sits exposed on the PCB surface with no epoxy potting, making chip-off extraction straightforward.

Back shield with EMI shielding can removed

Mezzanine connector joining the two PCBs

Back shield — EMI shielding can removed

Firmware Analysis

Extraction

The MX25L25645G was de-soldered and read with a flash programmer, yielding a 32 MB binary image. binwalk3 identified four regions:

Offset	Type	Contents
`0x00000`	Raw	U-Boot bootloader
`0x60438`	JFFS2	`dev.bin` device config
`0xA02E0`	JFFS2	Backup config, shared TLS key pair
`0x1E0000`	CramFS	Main system, kernel, ramdisk, shared TLS key pair

The U-Boot region reveals a UART debug console on ttyS0 at 115200 baud — physical access to the PCB test points would give an unauthenticated root shell.

What’s inside the CramFS

Beyond the Linux 3.18.20 kernel and ramdisk, notable files include:

start.sh — encrypted boot script, decrypted at runtime by digicapkeyArm.ko (a ring-0 Hikvision proprietary kernel module)
serverkey.pem / servercert.pem — the shared RSA private key; also present in the backup JFFS2
hicore — the main application binary (~several MB, stripped); source of nearly all critical findings
11 device-tree blobs for different hardware variants

Ramdisk

/
├── bin/
│   ├── psh          ← backdoor shell (4 hardcoded RSA public keys)
│   └── busybox, hik debug tools
├── etc/
│   ├── dropbear/    ← shared SSH host keys (identical on all units)
│   ├── shadow       ← unsalted SHA-256 root hash, unchanged since 2012
│   └── profile      ← calls psh on every interactive login
└── sbin/ usr/

Automated Analysis — EMBA

The full image was processed by EMBA, covering CVE correlation, binary hardening audit, CWE static analysis, Ghidra/semgrep decompilation, credential scanning, and kernel exploit matching.

19Total Findings

4Critical

9High

6Medium

4,000CVEs Identified

105Public Exploits

CRITICAL 9.8 F-01 — Hardcoded TLS private key shared across all units
CRITICAL 9.8 F-11 — Severely outdated software stack: 4,000 CVEs, 47 Critical, 105 public exploits
CRITICAL 9.8 F-17 — CVE-2021-36260: unauthenticated command injection via ISAPI endpoint (Metasploit available)
CRITICAL 9.1 F-18 — sipServer SQL injection via unauthenticated SIP REGISTER (no prepared statements)
HIGH 8.8 F-12 — Kernel privilege escalation: Dirty COW + overlayfs, confirmed Metasploit modules
HIGH 8.1 F-03 — Unsalted SHA-256 root hash, unchanged since 2012-09-12, shared across all units
HIGH 8.1 F-13 — Binary hardening failures: 93% lack RELRO, 84% lack stack canaries, NX absent on hicore
HIGH 8.1 F-14 — 300 unsafe strcpy, 41 system() calls, 2,659 format string issues in hicore alone
HIGH 8.1 F-19 — ISAPI serial bus passthrough: authenticated HTTP-to-RS232/RS485 bridge, no additional access control
HIGH 7.5 F-04 — Cloud telemetry & phone-home endpoints hardcoded in hicore
HIGH 7.2 F-02 — psh backdoor shell with 4 hardcoded RSA keys; Debug mode accessible to key holder only
HIGH 7.1 F-15 — 395 instances of weak file permissions
HIGH 7.1 F-16 — da_info hidden command surface: resetPasswd/resetParam accessible via direct invocation
MEDIUM 6.5 F-07 — Preset SSH host keys identical across all units
MEDIUM 6.4 F-06 — Encrypted boot script; 3DES key extracted from digicapkeyArm.ko .rodata
MEDIUM 5.9 F-08 — Telnet can be enabled via config; no encryption
MEDIUM 5.3 F-09 — Hardcoded internal Hikvision IP addresses in production binary
MEDIUM 5.3 F-10 — Hardcoded Chinese DNS servers (114.114.114.114 / 223.5.5.5)
MEDIUM 4.5 F-05 — Hik-Connect enrollment routes identity-linked event images to Hikvision cloud (opt-in)

Standout Discoveries

Hikvision built a backdoor into every device

/bin/psh is installed as the interactive shell for every authenticated session — SSH, Telnet, UART — via /etc/profile. It’s not a shell. It presents a numeric challenge and waits for a response computed from four hardcoded 1024-bit RSA public keys embedded in the binary:

[PSWD][0042]:_

Supply the correct answer (computable offline from the embedded keys) and the binary responds:

You know

Root access granted. On any unit. Ever shipped. The string RSA_new faild — note the typo — confirms the key-loading code is homegrown. This is not a bug that crept in; it is an intentional Hikvision service-access mechanism.

Every device on the planet shares the same TLS private key

serverkey.pem and servercert.pem are baked into the firmware in plaintext — and appear in two separate partitions, so reflashing one doesn’t fix it:

Subject:   C=CN, ST=ZJ, L=HZ, O=HIKVISION, OU=HZ, CN=hikvision.com
Issued:    2019-12-17
Expires:   2037-12-31  (18-year validity)
Key:       RSA 2048-bit, self-signed
Serial:    8a:b4:23:17:c6:2a:20:f1

Every DS-KV6113-WPE1(C) presents this same certificate. Anyone who has downloaded the firmware — which is publicly available — holds the private key for your device’s TLS session.

Hik-Connect uploads identity-linked images when the building manager opts in

The alarm_2000 module inside hicore can upload face-recognition event captures to Hikvision’s cloud via S3-style presigned URL POSTs. Static disassembly of event_upload_proc confirms the upload path is gated by an ezviz_enable flag (default 0) in the on-device SQLite database — it is only set to 1 when a building manager actively enrolls the device in Hik-Connect.

What is uploaded when enabled: a JPEG frame at the moment of a face-match event (pic_info.picPoolIdx) linked to the enrolled person’s employee number (pic_info.employeeNo). Biometric templates themselves are not uploaded; faceDataUrl and infraredFaceDataUrl are local ISAPI endpoints.

Four hardcoded cloud telemetry endpoints — including www.hikvision.com/RaCM/trackExt/ver10 — are compiled directly into hicore and appear to be called independently of the Hik-Connect enrollment state. Whether those specific calls are triggered in practice requires live traffic capture to confirm.

The source paths embedded in the binary:

accessControl/authorityManagement/authInfoUpload.c
accessControl/eventCtrl/event_upload.c

The root password hasn’t changed since 28 December 2012

root:8c9a60a87ff34a9e6c70a986aa4a9e14b237fcd4126f77107298c8afd86248d3:15595:0:99999:7:::

Day 15595 in Unix epoch-days is 2012-09-12. The hash is unsalted SHA-256 — the same value on every unit ever manufactured. John the Ripper couldn’t crack it in an hour, but that’s now irrelevant: the hash is public, and GPU-accelerated cracking against a custom wordlist can run indefinitely.

The GECOS field — normally a human-readable name — is a 64-character hex string that appears to be a device identifier, suggesting the password was set programmatically and never intended to be changed by users.

QA test infrastructure shipped in production firmware

Buried in the hicore binary, alongside the cloud endpoints, is this URL:

http://10.19.132.120:6120/pic?=d61if98e*b8ai034-59562b--49a411810d50fi0b6*=ids1*=idp1*

10.19.132.120 is an internal Hikvision RFC-1918 address. The obfuscated parameter string looks like a test-harness artifact. It was never stripped before the release build. A second internal address, 10.192.74.191, also appears with no documentation of its purpose.

CVE-2021-36260 is probably exploitable on this device

Hikvision confirmed in 2021 that a broad range of their products — including video intercom units — contained an unauthenticated command injection vulnerability in the HTTP server. The attack requires a single unauthenticated PUT request:

PUT /ISAPI/System/configurationData HTTP/1.1
Host: <device-ip>

<?xml version="1.0" encoding="UTF-8"?>
<language>$(id>/tmp/pwned)</language>

Static analysis of this firmware confirms:

The endpoint /ISAPI/System/configurationData is present in hicore’s ISAPI dispatch table
hicore imports system(), popen(), execve(), fork(), and vfork()
The version string V2.1.5 is compiled into the binary — within the affected range (before V2.2.0)
A Metasploit module for this CVE is publicly available

A successful exploit yields a root shell over the network with no credentials.

Combined exploit chain: CVE-2021-36260 RCE → unprivileged shell → Dirty COW (CVE-2016-5195) → root. Every step has a public exploit or Metasploit module.

SIP REGISTER message can inject SQL into the device database

sipServer manages a SQLite database of registered SIP clients — intercoms, indoor monitors, and room units. It builds every SQL query by substituting SIP header fields directly into format strings, then executing them raw:

// From sipServer strings — no prepared statements anywhere
sprintf(sql, "WHERE user_name = '%s';", sip_from_header);
sqlite3_exec(db, sql, ...);

No sqlite3_prepare_v2, sqlite3_bind_text, or any other parameterisation function exists in the binary’s import table. Any device on the same LAN can send a crafted SIP REGISTER with a SQL-injection payload in the From: header — no authentication required — and read or modify the credential database:

REGISTER sip:device SIP/2.0
From: <sip:' OR '1'='1@attacker>

The reg_user table contains login_password, reg_password, device serial numbers, and MAC addresses for every registered unit.

Read the Full Report →