View on GitHub

Hikvision Intercom RE

Deep-dive into a Hikvision intercom system.

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.

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.

Your visitors’ faces are being sent to China

The alarm_2000 module inside hicore uploads face-recognition captures and access-control events to Hikvision cloud via S3-style bucket POSTs. The source paths are right there in the binary strings:

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

The SQLite schema stored on-device tells the rest of the story:

CREATE TABLE face_param (
    inter_orbital_distance, max_distance, eco_mode_enable,
    enable_mask, pass_contral, ir_1vn_masktonormal_sim ...);

Four hardcoded cloud endpoints — including www.hikvision.com/RaCM/trackExt/ver10 — are called without any user-visible opt-in or disclosure.

The root password hasn’t changed since 28 December 2012

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

Day 15595 in Unix epoch-days is 2012-12-28. 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.

Read the Full Report →