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/    ← preset SSH host keys (sshd off by default)
│   ├── 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

2Critical

5High

15Medium

2Low

4,000CVEs Version-Matched

2Findings Demonstrated

How to read these severities. This is a static-analysis project. With two exceptions (F-06, demonstrated; F-20, a reproducible crash under emulation), none of these findings has been exploited end-to-end against a working device. They establish that vulnerable code, keys, and endpoints exist in the firmware image — not that they are remotely reachable on a deployed unit. The CVSS scores are worst-case-if-confirmed and should be read as upper bounds on hypotheses. The full report marks the evidence class and test status of each finding, and live testing on a second, newer unit has already refuted one of them (F-22).

CRITICAL 9.8 F-17 — CVE-2021-36260 ISAPI command injection — published NVD score; applicability inferred from a version string and never tested, likely inapplicable to current firmware
CRITICAL 9.1 F-18 — sipServer SQL injection via SIP REGISTER — sprintf pattern traced statically, no payload ever sent
HIGH 7.8 F-12 — Kernel privesc: Dirty COW version-match (upstream CVE score) — untested, requires a shell not yet obtained
HIGH 7.8 F-20 — Unauthenticated CPIU IPC bus in daemon_fsp_app — reproducible SIGSEGV under QEMU, no execution control shown
HIGH 7.4 F-01 — Hardcoded TLS private key in firmware (device never observed serving it; cross-unit sharing unverified)
HIGH 7.4 F-23 — Cloud-keyed secretkey ISAPI maintenance bypass — no valid token obtained
HIGH — F-11 — Outdated software stack: 4,000 version-matched CVEs (un-triaged aggregate; no single CVSS applies)
MEDIUM 6.8 F-02 — psh backdoor shell, 4 hardcoded RSA public keys; unlock needs the vendor's private key. CVSS understates this — see report
MEDIUM 6.8 F-22 — U-Boot verify=n on the older unit — refuted on the newer unit (OTP-locked, signatures verify)
MEDIUM 6.5 F-19 — ISAPI serial bus passthrough — requires admin credentials; documented integrator feature
MEDIUM 6.5 F-25 — No CSRF protection on the web interface
MEDIUM 6.4 F-03 — Unsalted SHA-256 root hash, unchanged since 2012-09-12 (uncracked; no login service on by default)
MEDIUM 5.9 F-24 — Hardcoded tokens and predictable fallback encryption key in hicore
MEDIUM 5.5 F-16 — da_info hidden command surface: resetPasswd/resetParam via direct invocation
MEDIUM 5.3 F-04 — Cloud telemetry & phone-home endpoints hardcoded in hicore (no traffic capture performed)
MEDIUM 4.8 F-07 — Preset SSH host keys in image (sshd off by default; cross-unit sharing unverified)
MEDIUM 4.7 F-21 — BSP encryption layer uses AES-128-ECB with a device-bound decryption oracle
MEDIUM 4.6 F-06 — Encrypted boot script; 3DES key extracted from digicapkeyArm.ko (demonstrated)
MEDIUM 4.4 F-15 — 395 instances of weak file permissions (un-triaged scan result)
MEDIUM 4.3 F-05 — Hik-Connect enrollment routes identity-linked event images to Hikvision cloud (opt-in)
MEDIUM — F-13 — Binary hardening gaps: 93% lack RELRO, 84% lack canaries (missing mitigations, not exploitable bugs — no CVSS)
MEDIUM — F-14 — 300 strcpy, 41 system(), 2,659 format-string sites in hicore (un-triaged pattern counts — no CVSS)
LOW 3.3 F-08 — Dormant Dropbear SSH daemon, enableable via a legacy-named enable_telnet flag (no Telnet server exists in the image)
LOW 3.7 F-10 — Hardcoded Chinese DNS servers (114.114.114.114 / 223.5.5.5)
INFO F-09 — Hardcoded internal Hikvision IP addresses in production binary (no attacker-usable path)

Rescored in the current revision — every score was re-derived from first principles against CVSS v3.1. Nineteen findings moved, one upward. The full rationale for each is in Section 5 of the report.

Standout Discoveries

Hikvision built a backdoor into every device

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

[PSWD][0042]:_

Supply the correct answer and the binary responds:

You know

To be clear about who can do that: the binary embeds the public keys only. Computing a valid response requires the corresponding private keys, which are not in the firmware and are presumably held by Hikvision. This is not an open door for anyone who downloads the image — offline cryptanalysis of the four keys (pairwise GCD, exponent and primality checks, 2M rounds of Fermat factorization) found no weakness, and repeated attempts to escape psh over UART on a live unit all failed.

What it is: a permanent, vendor-controlled root-access mechanism present on every unit shipping this firmware, surviving firmware updates, with no owner-facing way to disable or audit it. The string RSA_new faild — note the typo — indicates homegrown key-loading code. This is not a bug that crept in; it is an intentional service-access design.

A TLS private key sits in plaintext in the firmware

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   (self-signed, RSA 2048-bit)
Expires:   2037   (18-year validity)
Serial:    [redacted]
Key:       [redacted — private key withheld]

Confirmed against live hardware. A running door station was observed serving a certificate identical to the one extracted from a different physical unit’s firmware image, and the matching private key is present in plaintext in that image. The two units run different firmware versions, different kernels, and different SoC vendors — so the key is shared across units, firmware revisions, and hardware generations, not merely within one production batch.

Consequences: HTTPS to this device provides no confidentiality against anyone holding the (publicly downloadable) firmware; certificate pinning is worthless; and the exposure cannot be fixed by an update that ships another shared key.

Key material, fingerprints, and serials are deliberately omitted from this page. The finding is reported; the means to exploit it are not. See Disclosure posture at the foot of this page.

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:[redacted — unsalted SHA-256 digest]:15595:0:99999:7:::

Day 15595 in Unix epoch-days is 2012-09-12. The hash is unsalted SHA-256, so every unit shipping this firmware carries the same value. John the Ripper did not crack it within an hour, and no remote login service is enabled by default — so this is a latent exposure rather than a live one. The digest itself is withheld here.

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.

Disclosure posture

This page describes what was found. It deliberately omits how to exploit it.

The full technical report — proof-of-concept commands, key material, hashes, certificate fingerprints, memory offsets, and the raw firmware image — is not published and is retained privately by the researcher. Findings here are summarised at a level intended to inform owners and operators of the risk, without handing a working toolkit to anyone who wants to attack a door station they do not own.

Specifically withheld:

The RSA private key, its certificate serial and fingerprints
The root password digest
Login-challenge parameters and captured authentication material
The raw 32 MB flash image and extracted filesystems
Exploitation scripts and packet captures

Testing scope. All work was performed on hardware owned outright by the researcher, on an isolated network, with no third-party device accessed at any point and no service disrupted. No vulnerability described here has been used against any system belonging to anyone else.

Contact. Vendors, CERTs, or researchers wanting the technical detail — including Hikvision — are welcome to get in touch through this repository’s issue tracker to arrange coordinated disclosure. Corrections are equally welcome; several findings on this page have already been revised or refuted by subsequent testing, and that process continues.