Forensic Video Recovery from Multi-Channel Analog DVR Systems: Channel Demultiplexing and Temporal Reconstruction from Interleaved DHAV Streams

Abstract

Analog digital video recorders (DVRs) are still extensively used in small-to-medium business and home security systems, but there are special problems when it comes to forensic recovery of video evidence in these systems that are not covered by tools or methodology. Compared to the IP-based network video recorders, analog DVRs packetize video frames of several coaxial-connected cameras into a single interleaved binary stream on disk, necessitating channel demultiplexing before single camera footage can be reassembled. In this paper, we discuss a multi-channel analog Dahua DVR system utilizing the DHAV frame format, with a focus on the forensic recovery approach. Three significant contributions are presented in the methodology: (1) a channel demultiplexing algorithm that separates interleaved frames with up to 32 cameras on the basis of embedded channel identifiers and temporal coherence analysis; (2) a frame sequence stitching mechanism to reassemble continuous video segments on the basis of non-contiguous disk fragments using adaptive frame number tolerance (±3 frames) and temporal validation (≤1 second difference); and (3) a native C implementation with Win32 GUI providing significant performance improvements over interpreted alternatives. The system was tested on 14 analog Dahua DVR hard drives of various models, with a 92.3% recovery rate (97.1% on hard drives with no hardware damage), 91.3% temporal accuracy, 97.5% channel separation accuracy and a 1.8% false positive rate. The methodology fills an important gap in the literature of surveillance forensics, where current studies have only concentrated on IP-based digital systems, and analog DVRs form an estimated 35–40% of operational surveillance systems across emerging markets. The channel demultiplexing capability, which is not found in any current commercial or academic tool, enables automated per-camera organization of interleaved streams, converting what was previously a manual multi-day process into an automated one.

1. Introduction

Closed-circuit television (CCTV) surveillance systems are now seen as ubiquitous elements of security infrastructure around the world, with the video surveillance market in the world estimated to be USD 73.75 billion in 2024, expected to grow to USD 147.66 billion by 2030 [1]. Video evidence recovered through forensic methods of these systems is an important capability for law enforcement agencies, court proceedings, and investigations of incidents. Nevertheless, the variety of surveillance system architectures, especially the basic difference between analog and digital (IP-based) systems, poses specific forensic issues that demand specialized recovering methodologies.

Over the past two decades, the surveillance sector has shifted substantially from analog to digital architectures. Modern IP-based network video recorders (NVRs) accept pre-digitized video streams from each camera over Ethernet and store the data from each camera in logically or physically independent locations on the storage medium. This architectural simplicity has made IP-based systems the primary target of forensic studies, and extensive methodologies have been developed for major manufacturers, including Hikvision [2] and Dahua [3]. Specialized forensic software such as Magnet DVR Examiner [4], VIP 2.0 [5], and DiskInternals DVR Recovery [6] has been designed to work with these digital architectures.

This industry-wide shift notwithstanding, analog DVR systems have continued to be widely used. According to industry surveys, as of 2025, about 35–40 percent of small-to-medium business surveillance installations and 25–30 percent of residential systems in emerging markets are still using analog equipment [7]. These systems are especially widespread in areas where technology adoption decisions are determined by cost sensitivity, encompassing Central Asia, southeast Asia, Latin America and portions of Eastern Europe. As the overall volume of IoT-linked devices is expected to surpass 29+ billion worldwide by 2030 [8], and with the incorporation of surveillance cameras in larger IoT systems, further complicating forensic acquisition, one can expect even more sophisticated systems to feature surveillance cameras, making forensic acquisition even more difficult. In Kazakhstan, analog surveillance systems still dominate retail, hospitality, and small office installations due to cheaper equipment costs and the wide coaxial cable network already in place.

Analog DVR systems have great forensic importance. Evidence recovery from older or budget surveillance installations where analog DVRs are used is often required in criminal investigations. When law enforcers confiscate the DVR equipment for crime scenes, retail theft, assault, traffic, and property crime, there are high chances of finding analog hardware, especially in economically limited settings. The fact that it is not possible to extract video evidence from such systems because of poor forensic equipment is a gap that is very critical in investigation processes.

1.1. Architectural Distinction: Analog vs. Digital DVR Storage

The major distinction between digital and analog DVR systems is the way video information from several cameras is stored in the storage medium. This difference is critical in understanding the forensic challenges that this study is discussing.

On IP-based NVR systems, each camera sends a separate, digitally encoded video stream (usually H.264 or H.265) on an Ethernet network. The streams are stored in logically separated areas or file formats on the NVR, which can be easily extracted on a per-camera basis during forensic recovery. Streams have their own frame numbering sequence, timestamps and codec parameters. Recovery tools are able to locate and recover individual camera streams with a minimum amount of cross-channel interference.

Analog DVR systems operate on a fundamentally different principle. Multiple cameras are connected to the DVR through coaxial cables (BNC connectors) that transmit analog video signals. The DVR digitizes these signals in parallel using internal hardware and stores them as digital frames in a single interleaved binary stream on the hard drive. Frames from the different cameras are multiplexed in a round-robin or priority fashion: Camera 1 frame, Camera 2 frame, Camera 3 frame, Camera 1 frame, and so on. This interleaving produces a composite data structure in which a single sequential read of the disk yields frames from all connected cameras intermingled.

Figure 1 shows the decision logic that the frame sequence stitching algorithm uses to decide how each incoming frame is placed in the existing video sequence or in the formation of a new output file.

Each frame of a validated DHAV input is tried in the algorithm as an exact sequential matching (Level 1) followed by a near-sequential matching with temporal validation (Level 2), then it constructs another sequence over the unmatched I-frames (Level 3). P-frames that do not have an I-frame immediately before them are dropped so that the video can be played.

This interleaved storage architecture creates three forensic challenges that are absent in IP-based systems:

1.

Channel demultiplexing: Recovered frames must be classified and separated by their source camera channel before meaningful video reconstruction can occur. Without proper demultiplexing, the recovered output contains an incomprehensible mixture of frames from different cameras, rendering the evidence unusable.

2.

Cross-channel frame sequence discontinuities: When reading the disk sequentially, consecutive frames from the same camera may be separated by hundreds or thousands of frames from other cameras, creating apparent gaps in frame numbering that must be distinguished from actual recording interruptions.

3.

Temporal interleaving complexity: Timestamps from different cameras may overlap or be closely spaced, requiring channel-aware temporal analysis rather than simple chronological sorting.

1.2. Research Gap and Motivation

The extensive survey of the literature on forensic issues has shown a sizable gap in terms of analog DVR recovery procedures. The Hikvision DVR file system was seminally analyzed by Han et al. [2], focused exclusively on IP-based recording architectures. Dragonas et al. [3,9] researched Hikvision and Dahua CCTV systems log records, but their study dealt with digital NVR platforms. Yang et al. [10] mentioned fundamental concepts of video recovery software in the context of Dahua and Hikvision but did not discuss the channel demultiplexing issue of analog systems. Ariffin et al. [11] introduced file carving methods to proprietary DVR formats without distinguishing between analog and digital storage devices.

Rzayeva et al. [12] presented an automated forensic recovery methodology for Hikvision and Dahua DVR/NVR systems, introducing adaptive temporal sequencing and dual-signature validation. Although that methodology showed good results on IP-based systems (91.8 % recovery rate, 96.7 % temporal accuracy with 27 test drives), it was developed to work in an architecture where each camera generates a distinct data stream and was not designed to accommodate the interleaving multi-channel storage that is typical of analog DVRs.

There are similar limitations with commercial forensic tools. Magnet DVR Examiner, VIP 2.0 and DiskInternals DVR Recovery are optimized to use IP-based file system layouts and support limited or no analog interleaved stream separation [4,5,6]. Practitioner reports that these tools tend to retrieve analog DVR data as a single unsorted stream, and a considerable amount of manual post-processing is necessary to isolate channels, which is a time-intensive task that is not feasible during time-sensitive investigations [13].

1.3. Research Contributions

This gap has been filled in this paper, which proposes a forensic recovery methodology that is specially created to work with multi-channel analog Dahua DVR systems. The major contributions are:

1.

Channel demultiplexing algorithm: An automated tool to separate interleaved DHAV frames of an arbitrary number of camera channels (maximum of 32) according to the channel identifiers embedded in them and generate per-camera video files stored in separate output directories (CAM_01, CAM_02, and so on).

2.

Frame sequence stitching with adaptive tolerance: A reconstruction system that uses a multi-level matching strategy to assemble continuous video blocks at the non-contiguous disk blocks: exact sequential match (frame $n-1$), near-sequential match (frame $n-2$ or frame $n-3$), with temporal coherence verification (less than one second difference between the frame timestamps) to avoid false joins between recording sessions.

3.

Dual-signature frame validation: An extension of standard DHAV header–footer validation (“DHAV”/“dhav” magic bytes) that additionally checks frame size consistency, timestamp plausibility, and frame-type playability (I-frame/P-frame) before accepting a frame as valid.

4.

Deleted file detection: This is a heuristic system that can be used to detect the existence of a deleted recording based on the video end timestamps versus the time of drive initiation and give investigators some evidence of destruction.

5.

High-performance native implementation: A C language-based application with a Win32 graphical user interface that offers the ability to access physical drive hardware directly through ATA Pass-Through commands for disk identification. Such a tool also performs integrated MD5 hash calculation for forensic integrity verification and allows the user to monitor the recovery process in real time.

The validity of the methodology was tested on 14 analog Dahua DVR hard drives with varying DVR models and recording settings and was qualitatively compared to the existing commercial forensic tools.

The rest of this paper is structured in the following way: Section 2 is a review of related work in the area of surveillance system forensics and file carving techniques; Section 3 contains the technical methodology, which includes system architecture, channel demultiplexing, and frame reconstruction algorithms; Section 4 presents the experimental results and comparative analysis; Section 5 discusses findings, limitations, and future directions; and Section 6 concludes this paper.

2. Related Work

2.1. Forensic Analysis of Proprietary Surveillance Systems

CCTV and DVR systems have emerged as a significant focus of forensic analysis because of the widespread use of surveillance infrastructure worldwide. The incompatibility of proprietary file systems among manufacturers, combined with the size and complexity of stored video data, requires specialized forensic methods for investigation [14].

The first systematic study of the Hikvision DVR file system was carried out by Han et al. [2], who reported its proprietary format featuring the Master Sector at offset 0x200 with the signature HIKVISION@HANGZHOU, a data block structure, and the HIKBTREE indexing system. This work laid the methodological foundation for further studies of proprietary surveillance formats. Building on this base, Dragonas et al. [9] re-examined the Hikvision file system to study previously unexplored log records. Their Hikvision Log Analyzer tool automated the carving and interpretation of these records, revealing that log entries (labeled with the “RATS” signature) contain user activities, system settings, power events, and security events. The same authors subsequently analyzed Dahua systems [3], showing that the DHFS4.1 file system logs information about hard drive formatting, camera recording status changes, and user authentication attempts—artifacts with strong attribution power.

Shin et al. [15] explored digital forensics for heterogeneous IoT incidents in smart-home settings, including Hikvision IP cameras, demonstrating that forensic acquisition becomes increasingly complex as surveillance cameras integrate into broader IoT ecosystems. Recent IoT forensics surveys [16,17] consistently identify proprietary surveillance storage as a key unresolved challenge for standardized forensic procedures.

Rzayeva et al. [12] introduced adaptive temporal sequencing, dual-signature validation, and automated manufacturer detection for Hikvision and Dahua DVR/NVR systems in our prior work, achieving a 91.8% recovery rate, 96.7% temporal accuracy, and 2.4% false positive rate on 27 surveillance hard drives. However, that approach was applied only to IP-based digital systems where each camera generates a distinct data stream and did not address the interleaved multi-channel storage architecture of analog DVRs.

Imanberdi et al. [18] analyzed AES-XTS data decryption with PBKDF2 key derivation for raw disk images of mobile phones. Although their work targets mobile devices rather than surveillance systems, the methodological emphasis on low-level binary parsing of proprietary storage is conceptually related to the present study.

2.2. File Carving and Video Recovery Techniques

File carving—extracting files from storage media without relying on file system metadata—is a foundational technique in surveillance forensics. Traditional carving tools such as Foremost and Scalpel [19] use header/footer signature matching to determine file boundaries, but they were designed for standard file formats and lack native support for proprietary surveillance frame formats.

The fragmentation problem arising in circular-buffer DVR storage has motivated more advanced carving techniques. Pal and Memon [20] introduced entropy-based statistical methods for fragment boundary detection, reporting that traditional header-only carving achieves only 60–70% success on fragmented video files. Garfinkel [21] introduced the carving of contiguous and fragmented files with fast object validation, establishing benchmarks for subsequent tools.

Deep learning has recently provided new approaches to file fragment classification. Haque and Tozal [22] proposed byte embeddings for fragment classification, and CNN-LSTM architectures have similarly improved fragment-type identification [23]. The broader survey by Dunsin et al. [24] identifies file carving and data recovery as promising but underexplored applications of AI in digital forensics. Oh et al. [25] addressed the complementary problem of metadata-independent recovery from damaged storage media, which is conceptually similar to the signature-based approach used here when proprietary file system metadata is unreadable.

Tobin et al. [26] demonstrated an experimental reverse-engineering approach for proprietary CCTV file systems on GANZ/AVTECH systems, but—like other methods in the literature—did not address analog multi-channel interleaving. Seckiner et al. [27] studied codec-specific artifacts and distortions in CCTV images, while Bruehs and Stout [28] proposed metrics for quantifying acquired recording quality on DVR systems.

Despite these advances, file carving for surveillance video remains limited because stock carving systems do not recognize DHAV or Hikvision frame signatures, requiring extensive custom configuration that is impractical for time-sensitive investigations.

2.3. The Analog DVR Forensic Gap

A critical observation emerging from the literature review is the near-complete absence of research addressing forensic recovery from analog DVR systems. The existing body of work—from Han et al.’s [2] Hikvision analysis through Dragonas et al.’s [3,9] log record investigations to our own prior methodology [12]—has focused exclusively on IP-based digital systems where each camera produces an independent data stream stored in separate disk regions.

Analog DVRs have an entirely different storage architecture: The DVR hardware digitizes several cameras in parallel on coaxial cables (BNC connectors) and then interleaves the frames of all cameras into a single binary stream. This presents a channel demultiplexing problem, which IP-based systems do not have, and which has not been discussed in any published forensic methodology as far as we know.

Yang et al. [10] outlined general concepts of video recovery of Dahua and Hikvision systems but failed to distinguish between analog and digital architectures. Ariffin et al. [11] suggested file carving methods in proprietary DVR formats, assuming that the DVR was a single-stream source with no multi-channel interleaving.

2.4. Commercial Tool Landscape

Commercial forensic tools provide the primary means of surveillance video recovery for practitioners. Magnet DVR Examiner (formerly developed by DME Forensics) supports direct file system acquisition from DVR hard drives and handles both native and proprietary formats [4]. VIP 2.0 by SalvationDATA provides broad manufacturer coverage with advanced features for professional investigators [5]. DiskInternals DVR Recovery offers automated manufacturer detection for Hikvision, Dahua, and other systems [6]. However, these tools are optimized for IP-based architectures and provide limited or no support for analog multi-channel stream separation. Practitioner forum discussions indicate that commercial tools typically recover analog DVR data as a single unsorted stream, requiring manual post-processing to separate camera channels [13].

The combination of high licensing costs (typically $3000–$8000 annually), closed-source algorithmic opacity, and limited analog DVR support motivates the development of transparent, academically validated methodologies specifically targeting analog surveillance systems—the objective of the present research.

3. Materials and Methods

3.1. System Architecture Overview

The proposed forensic recovery system utilizes a modular architecture that is capable of automatically detecting, extracting, demultiplexing channels, and reassembling video evidence on analog Dahua DVR hard drives. It is coded in C (~8000 lines of code) and runs on the Windows platform, with a Win32 graphical user interface. Figure 2 represents the system architecture.

The pipeline takes raw disk input and consists of five stages: signature-based manufacturer identification, DHAV frame parsing with dual-signature validation, channel demultiplexing into per-camera streams, frame sequence reassembly with adaptive tolerance, and forensically sound video output with MD5 integrity verification.

The architecture consists of five primary modules:

1.

Disk Access and Signature Detection Module: Gives direct access to physical drives or disk images, detects the manufacturer of the surveillance system by analyzing the signature and retrieves disk metadata through ATA Pass-Through commands.

2.

DHAV Frame Parser: Via two-signature matching (header DHAV and footer dhav) of the disk, locates the boundaries of DHAV frames and extracts frame metadata (channel identifier, frame number, timestamp, frame type, and checksum).

3.

Channel Demultiplexer: Classifies extracted frames by source camera channel and routes each frame to the appropriate per-channel output stream.

4.

Frame Sequence Stitcher: Maintains active sequences in each channel, reassembling continuous video segments with non-contiguous frames based on adaptive frame number tolerance with temporal validation.

5.

Output Module: Creates per-camera H.265 videos in channel directories, optionally converts to MP4 with FFmpeg, calculates MD5 checksums to ensure integrity, and creates recovery reports.

3.2. Disk Access and Manufacturer Detection

The system offers two modes of operation: one based on the analysis of raw disk image files (.img, .bin, .raw files) and one on the access to the physical storage devices. When accessing the physical disk, the system lists connected USB and SATA devices through the Windows SetupAPI, and opens them in read-only to maintain forensic integrity.

ATA Pass-Through commands (ATA IDENTIFY DEVICE, command register 0xEC) are used to retrieve the manufacturer model string (ATA words 27–46) and serial number (ATA words 10–19) directly out of the drive firmware, which are used to identify a disk. This implementation is hardware-level identification that works even with USB-to-SATA bridge controllers (e.g., JMicron chipsets) and gives the correct disk metadata independent of the interface adapter.

The manufacturer detection uses the signature-based analysis at constant offset in the disk image. The system accesses 1024-byte header blocks at offsets of 512, 1024 and 2048 bytes, seeking the signature of Dahua file systems, the DHFS4.1 signature. This multi-offset scheme allows differences in the partition layout of different versions of DVR firmwares. The detection algorithm has computational complexity of $O\left(1\right)$ signature matching, which allows signature matching with manufacturers being classified in real time.

3.3. DHAV Frame Format and Parsing

Analog Dahua DVR systems employ the DHAV frame format for video encapsulation, each frame of which includes a header metadata, encoded video payload and a validation footer. The frame structure is determined in the following way.

The frame header (24 bytes) consists of the “DHAV” magic signature (4 bytes at offset 0), frame type identifier (1 byte at offset 4, where 0xFD indicates an I-frame and 0xFC indicates a P-frame), frame subtype (1 byte at offset 5), channel number (1 byte at offset 6), subchannel identifier (1 byte at offset 7), frame number as a 32-bit little-endian unsigned integer (4 bytes at offset 8), total frame size as a 32-bit little-endian unsigned integer (4 bytes at offset 12), datetime stamp encoded in BCD format (4 bytes at offset 16), milliseconds as a 16-bit little-endian unsigned integer (2 bytes at offset 20), extended header flag (1 byte at offset 22), and checksum (1 byte at offset 23). Figure 3 illustrates the complete DHAV frame structure.

A frame is made up of a 24-byte header with the magic signature of DHAV, channel identification, frame number, timestamp and checksum, variable-length H.264/H.265 encoded video content and a validation footer with dhav magic bytes and confirmation of frame size.

The video data payload would then come after the header, which would consist of the H.264 or H.265 video data, which is encoded. The sum of the sizes of all payloads is computed as the frame size (based on the header) less 24 bytes of the overhead of the header. The frame is terminated with a footer with the dhav magic bytes (4 bytes), size field (4 Bytes) and integrity checking checksum.

Frame parsing algorithm reads the disk block-by-block (1 MB blocks) and searches the disk with the signature of the header of the DHAV. When a candidate header is found, the parser does multi-level validation:

1.

Header signature verification: Confirm the presence of “DHAV” (bytes 0x44, 0x48, 0x41, 0x56) at the current offset.

2.

Frame size plausibility: Verify that the declared frame size is within acceptable bounds ($100\le \mathrm{size}\le 10,485,760$ bytes) to reject corrupted headers.

3.

Footer signature verification: Read the expected footer position (current offset + frame size) and confirm the presence of “dhav” (bytes 0x64, 0x68, 0x61, 0x76), establishing dual-signature validation.

4.

Timestamp plausibility: Reject frames with year 2000 timestamps, which indicate corrupted or uninitialized metadata regions.

5.

Channel identifier validation: Verify that the channel number falls within the supported range (0–31 for up to 32 cameras).

Formally, a frame at disk offset o is considered valid if and only if all conditions are satisfied:

$$\mathrm{Valid}\left(o\right)=S_h\left(o\right)\wedge S_f\left(o\right)\wedge P_s\left(o\right)\wedge P_t\left(o\right)\wedge P_c\left(o\right)$$

(1)

where $S_h\left(o\right)$ denotes header signature match at offset o; $S_f\left(o\right)$ denotes footer signature match at offset $o+\mathrm{size}\left(o\right)$; $P_s\left(o\right)$ is the frame size plausibility check ($100\le \mathrm{size}\left(o\right)\le 10,485,760$); $P_t\left(o\right)$ is the timestamp plausibility check ($\mathrm{year}\left(o\right)\ne 2000$); and $P_c\left(o\right)$ is the channel identifier validity ($0\le \mathrm{chan}\left(o\right)\le 31$).

3.4. Channel Demultiplexing Algorithm

The channel demultiplexing module is the essence of the new contribution of such a methodology, as it deals with the special problem of separating interleaved multi-camera streams with analog DVR storage.

With the validated frames being read from the disk, each frame has an embedded channel identifier (byte offset 6 in the DHAV header) referring to the source camera. Each frame is demultiplexed by the demultiplexer with its channel number and sent to the per-channel processing pipeline. The system has a maximum of 32 concurrent channel pipelines, with a frame sequence tracking and output file management independent of each other.

The demultiplexing is done in a streaming mode so that the processing is performed in disk sequence and there is no need to scan the entire drive. In every valid frame at offset o having channel identifier c:

$$\mathrm{Route}\left(o\right)\to {\mathrm{Pipeline}}_c\mathrm{where}c=\mathrm{chan}\left(o\right),0\le c\le 31$$

(2)

The output is organized into channel-specific directories (CAM_01, CAM_02, …) within the main recovery folder, enabling investigators to immediately access footage from individual cameras without manual sorting. Figure 4 illustrates the demultiplexing process, where interleaved frames from the input stream are routed to per-camera output directories based on their embedded channel identifiers.

The analog DVR hard drive has single binary stream that has frames of all the cameras connected, but interleaved. The demultiplexer splits the frames according to their frame header channel identifier (byte offset 6 in the DHAV header) and sends each frame to separate per-camera output directories.

3.5. Frame Sequence Stitching

In each channel pipeline, the frames have to be put back together to form continuous video parts. Because of the overlapping of analog DVR storage, frames on disk of a single camera are spaced by frames of other channels. The frame sequence stitcher has a repertoire of running sequences and uses a multi-level matching policy to decide whether to add a new frame to an existing sequence or start a new one.

The stitching algorithm maintains a sequence pool $\mathcal{S}=\{s_1,s_2,\dots ,s_k\}$ where each sequence $s_i$ tracks the last frame number $n_i^{\mathrm{last}}$, the last timestamp $t_i^{\mathrm{last}}$, the associated output file descriptor, and a frame counter. For an incoming frame with frame number n and timestamp t, the stitching decision proceeds through three levels:

Level 1—Exact sequential match: The frame is appended to the current active sequence if $n=n_{\mathrm{active}}^{\mathrm{last}}+1$, indicating strict frame number continuity.

Level 2—Near-sequential match with temporal validation: If Level 1 fails, the algorithm searches the sequence pool for any sequence $s_i$ satisfying:

$$\exists s_i\in \mathcal{S}:n_i^{\mathrm{last}}\in \{n-1,n-2,n-3\}\wedge |t-t_i^{\mathrm{last}}|\le 1\mathrm{s}$$

(3)

The tolerance of ±3 frames is that there are occasional dropped frames when using the DVR, and the 1 s time limit ensures that there are no false joins between recording sessions that might overlap in the frame number ranges.

Level 3—New sequence creation: When no similar sequence is found and the current frame is an I-frame (type 0xFD), a new sequence is started. P-frames (type 0xFC) without an I-frame before them are dropped since they cannot be decoded independently by video players.

Sequences are subject to timeout-based cleanup:

$$\mathrm{Finalize}\left(s_i\right)\mathrm{if}{t}_{\mathrm{current}}-t_i^{\mathrm{last}}>300\mathrm{s}$$

(4)

The maximum number of concurrent active sequences is bounded at $M=128$ to limit memory consumption. When the pool reaches capacity, the oldest sequence is finalized to accommodate new entries.

Computational Complexity Analysis

Each newly parsed frame triggers a lookup over the active sequence pool to determine the best matching sequence according to Equation (3). The current implementation performs this lookup as a linear scan, yielding per-frame complexity $O\left(M\right)$, where M is the number of active sequences ($M\le 128$). Across the entire disk, the total stitching complexity is therefore:

$$T_{\mathrm{stitch}}(N,C)=O(N·M\left(C\right))$$

(5)

where N is the total number of validated DHAV frames on the disk and $M\left(C\right)$ is the average size of the active sequence pool, which grows with the number of recording channels C. Empirically, $M\left(C\right)\approx \alpha ·C$ with $\alpha \approx 1.5$–2 during steady-state recording, which explains the observed processing-speed degradation as the channel count increases from 4 to 16 (Section 4.5). Frame parsing and disk I/O contribute an additional $O\left(N\right)$ term that dominates only for small C.

This linear-scan bottleneck can be eliminated by indexing the sequence pool with a hash map keyed on $(\mathrm{channel}\_\mathrm{id},n_i^{\mathrm{last}})$, reducing per-frame lookup to amortized $O\left(1\right)$ and overall stitching to $O\left(N\right)$ independent of C. The current $O(N·M)$ implementation was retained because the memory and code-complexity overhead of hash-based indexing was not justified for $M\le 128$ in our test workloads, but this optimization is identified as a concrete avenue for future work targeting deployments with $C>16$ or extremely high frame densities.

3.6. Deleted File Detection Mechanism

The system uses a heuristic method to detect recordings that had been deleted before forensic acquisition. When a video file is recovered, the system will first compare the end timestamp of the video file with the time that the drive was initialized:   

$$\mathrm{Status}\left(v\right)=\left\{\begin{array}{cc}\mathtt{DELETE}\hfill & \mathrm{if}{t}_{\mathrm{end}}\left(v\right)+3\mathrm{s}<t_{\mathrm{init}}\hfill \\ \mathtt{ACTIVE}\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(6)

where $t_{\mathrm{end}}\left(v\right)$ is the last frame timestamp of video v, $t_{\mathrm{init}}$ is the drive initialization timestamp, and the 3 s tolerance accounts for clock drift. Files marked as DELETE provide investigators with evidence of potential data destruction.

3.7. Forensic Integrity and Output Generation

To ensure a forensically sound system, the system calculates MD5 cryptographic hash of all the recovered video files using RFC1321, and it is built into the recovery pipeline to be computed during file writing in an incremental manner.

The system produces an overall forensic report including: disk metadata (manufacturer, model, serial number through ATA identification), recovery log including per-file timestamps and disk offsets, per-channel statistics (number of files, total size, number of frames), MD5 hash values of all recovered files, indicators of deleted files, and processing time.

Video output files are named according to the following scheme: YYYY-MM-DD_HH-MM-SS_framenum.h265, and they maintain original time stamps. Optional conversion to MP4 is done by FFmpeg with the flag -c:v copy to avoid re-encoding artifacts.

3.8. Graphical User Interface

The system has a Win32-based graphical user interface (around 1800 lines of C code) with disk selection and disk enumeration with automatic USB/SATA support, disk image file selection using standard file dialog, real-time recovery progress, live log output and configurable output directory. Figure 5 shows the main window and an active recovery session.

3.9. Experimental Setup

The methodology was validated using 14 analog Dahua DVR hard drives obtained from operational surveillance installations.

Table 1. Analog Dahua DVR equipment used in experimental validation.

#	DVR Model	Ch.	HDD Size	HDD Model
1	DH-XVR1B04	4	500 GB	WD Purple WD05PURZ
2	DH-XVR1B04	4	1 TB	Seagate SkyHawk ST1000VX005
3	DH-XVR1B08	8	1 TB	WD Purple WD10PURZ
4	DH-XVR1B08H	8	2 TB	Seagate SkyHawk ST2000VX008
5	DH-XVR1B16	16	2 TB	WD Purple WD20PURZ a
6	DH-XVR1B16H	16	4 TB	Seagate SkyHawk ST4000VX007
7	DH-XVR4104HS-X	4	1 TB	WD Purple WD10PURZ
8	DH-XVR4108HS-X	8	2 TB	Toshiba S300 HDWT720
9	DH-XVR5108HS-X	8	2 TB	Seagate SkyHawk ST2000VX008
10	DH-XVR5116HS-X	16	4 TB	WD Purple WD40PURZ
11	DH-XVR5108H-X	8	2 TB	WD Purple WD20PURZ
12	DH-XVR5216AN-X	16	8 TB	Seagate SkyHawk ST4000VX007 × 2 b
13	DH-XVR4116HS-X	16	1 TB	Toshiba S300 HDWT710 c
14	DH-XVR7108HE-4KL-X	8	4 TB	WD Purple WD40PURZ

^a Bad sectors detected on HDD. ^b Non-standard firmware with partial DHFS metadata corruption. ^c Minor read errors reported.

details the DVR equipment models.

Figure 6 demonstrates the organized output produced by the channel demultiplexing module, showing per-camera directory separation with temporally ordered video files.

The experimental hardware consisted of a forensic workstation (Intel Core i7, 32 GB RAM, 1 TB NVMe SSD) running Windows 11 with the proposed tool compiled using GCC (MinGW-w64). Performance context is defined by comparing with published results of commercial tools tested in digital (IP-based) Dahua DVR systems in previous research studies [12].

The evaluation metrics are defined as follows:

$$\mathrm{Recovery}\mathrm{Rate}={\displaystyle \frac{\mathrm{Recovered}\mathrm{Videos}}{\mathrm{Total}\mathrm{Expected}\mathrm{Videos}}}\times 100\%$$

(7)

$$\mathrm{Temporal}\mathrm{Accuracy}={\displaystyle \frac{\mathrm{Correctly}\mathrm{Sequenced}\mathrm{Frames}}{\mathrm{Total}\mathrm{Recovered}\mathrm{Frames}}}\times 100\%$$

(8)

$$\mathrm{Channel}\mathrm{Separation}\mathrm{Accuracy}={\displaystyle \frac{\mathrm{Correctly}\mathrm{Assigned}\mathrm{Frames}}{\mathrm{Total}\mathrm{Demultiplexed}\mathrm{Frames}}}\times 100\%$$

(9)

$$\mathrm{False}\mathrm{Positive}\mathrm{Rate}={\displaystyle \frac{\mathrm{Invalid}\mathrm{Recovered}\mathrm{Files}}{\mathrm{Total}\mathrm{Recovered}\mathrm{Files}}}\times 100\%$$

(10)

$$\mathrm{Precision}={\displaystyle \frac{TP}{TP+FP}}\times 100\%,\mathrm{Recall}={\displaystyle \frac{TP}{TP+FN}}\times 100\%$$

(11)

$$\mathrm{F}1\mathrm{Score}=2\times {\displaystyle \frac{\mathrm{Precision}\times \mathrm{Recall}}{\mathrm{Precision}+\mathrm{Recall}}}$$

(12)

A new evaluation metric unique to analog DVR forensics, introduced as the Channel Separation Accuracy (Equation (9)), is a measure of how well the system correctly identifies the frames as belonging to their cameras of origin.

3.10. Automated Channel Separation Verification

To assess channel separation accuracy with reduced reliance on human inspection, we developed an automated verification script that evaluates three structural invariants on each recovered per-camera video file. The invariants exploit the fact that frames originating from a single physical camera must satisfy consistency constraints that cross-channel misassignments necessarily violate. Formally, for each recovered video file v assigned to channel c and containing frame set $F_v=\{f_1,f_2,\dots ,f_k\}$, the verifier evaluates:

1.

Channel identifier uniformity. Every frame $f_i\in F_v$ is re-parsed and its embedded DHAV channel identifier $\mathrm{chan}\left(f_i\right)$ is compared with the assigned output channel c:

$${\mathcal{V}}_{\mathrm{chan}}\left(v\right)=\underset{f_i\in F_v}{\bigwedge }\left[\mathrm{chan}\left(f_i\right)=c\right]$$

(13)

Any frame whose embedded channel ID does not match the output assignment is counted as a misclassification.

2.

Temporal monotonicity. Within $F_v$, frame timestamps must be non-decreasing up to the stitching tolerance:

$${\mathcal{V}}_{\mathrm{time}}\left(v\right)={\displaystyle \underset{i=1}{\overset{k-1}{\bigwedge }}}\left[t\left(f_{i+1}\right)-t\left(f_i\right)\ge -\tau \right],\tau =1\mathrm{s}$$

(14)

A backward jump exceeding $\tau$ indicates that frames from a different recording session—and frequently from a different physical camera—were stitched into the file.

3.

Codec-parameter consistency. The H.264/H.265 sequence parameter set (SPS) and picture parameter set (PPS) extracted from the first I-frame of $F_v$ must match those of every subsequent I-frame within the file. Resolution, profile, and level fields are compared exactly:

$${\mathcal{V}}_{\mathrm{codec}}\left(v\right)=\underset{f_i\in F_v^{\mathrm{I}}}{\bigwedge }\left[\mathrm{SPS}\left(f_i\right)=\mathrm{SPS}\left(f_1\right)\wedge \mathrm{PPS}\left(f_i\right)=\mathrm{PPS}\left(f_1\right)\right]$$

(15)

This is the strongest of the three invariants: in multi-camera installations, cameras are routinely configured with different resolutions or codec profiles, so an SPS/PPS mismatch within a single output file is a near-certain indicator of misclassification.

A recovered file passes automated verification if and only if all three invariants hold. Frames violating any invariant are flagged for review and counted in the denominator of Equation (9) as incorrectly assigned. The script processes recovered files at approximately 180 MB/s and completes verification of the full 34.5 TB recovery in under five hours.

It is worth noting that this automated procedure validates the internal consistency of channel assignments rather than their correctness against an externally established ground truth (camera-to-position mapping at the installation site). For the present evaluation, ground-truth camera positions were not available for the majority of drives, which were obtained from operational installations without preserved installation documentation. Internal-consistency verification has been used in prior forensic literature when external ground truth is unavailable and represents a methodologically defensible alternative; full ground-truth-based validation is identified as a target for future work where instrumented test installations can be deployed.

4. Results

The suggested methodology has been tested on all 14 analog Dahua DVR hard drives listed in Table 1 with a total storage of 34.5 TB and 11,812 anticipated video files in 4-channel, 8-channel and 16-channel setups.

4.1. Channel Demultiplexing Performance

Channel demultiplexing capability—the main innovative contribution of this methodology—was assessed using the automated three-invariant verification procedure described in Section 3.10, which evaluates channel identifier uniformity, temporal monotonicity, and codec-parameter consistency across all recovered per-camera files.

Table 2. Channel demultiplexing accuracy across 14 analog DVR drives.

Drive	Model	Cameras	Correctly Assigned	Accuracy (%)
1	DH-XVR1B04	4	289,800	99.52
2	DH-XVR1B04	4	622,700	99.08
3	DH-XVR1B08	8	1,241,300	98.36
4	DH-XVR1B08H	8	1,363,000	99.42
5	DH-XVR1B16	16	2,298,000	93.76
6	DH-XVR1B16H	16	4,541,000	99.19
7	DH-XVR4104HS-X	4	686,200	99.74
8	DH-XVR4108HS-X	8	1,411,000	98.53
9	DH-XVR5108HS-X	8	1,409,000	99.58
10	DH-XVR5116HS-X	16	4,591,000	98.27
11	DH-XVR5108H-X	8	1,435,000	99.58
12	DH-XVR5216AN-X	16	8,542,000	95.49
13	DH-XVR4116HS-X	16	1,052,000	97.23
14	DH-XVR7108HE-4KL-X	8	1,547,000	99.68
Overall			31,029,000	97.5

presents the per-drive channel separation accuracy as measured by the automated verifier.

The system produced a total channel separation accuracy of 97.5% with an individual drive range of 93.8% (Drive 5, which had bad sectors) to 99.7% (Drive 14). Some degree of correlation was also found between the number of channels and accuracy of separation: 4-channel systems had on average 99.4%, 8-channel systems had on average 99.1%, and 16-channel systems had on average 96.2%. Figure 7 visualizes the channel separation accuracy grouped by channel count, highlighting the gradual accuracy decrease as the channel count grows. This decreased accuracy in 16-channel systems can be explained by the additional complexity of interleaving and the greater likelihood of corrupting the frame headers in cases where additional channels are in the same disk region. The worst-case scenarios (93.8% for Drive 5, with bad sectors, and 95.5% for Drive 12, with metadata corruption) still remain above 93% accuracy despite these adverse conditions.

4.2. Recovery Performance Analysis

Table 3. Recovery performance across 14 analog Dahua DVR drives.

Drive	Model	Expected	Recovered	Recovery (%)	Temp. Acc. (%)
1	DH-XVR1B04	112	108	96.4	98.7
2	DH-XVR1B04	245	236	96.3	96.4
3	DH-XVR1B08	480	461	96.0	96.5
4	DH-XVR1B08H	510	498	97.6	98.8
5	DH-XVR1B16	920	748	81.3	75.4
6	DH-XVR1B16H	1680	1641	97.7	98.6
7	DH-XVR4104HS-X	260	255	98.1	98.8
8	DH-XVR4108HS-X	540	516	95.6	96.2
9	DH-XVR5108HS-X	530	521	98.3	98.8
10	DH-XVR5116HS-X	1720	1652	96.0	96.1
11	DH-XVR5108H-X	545	534	98.0	98.9
12	DH-XVR5216AN-X	3280	2789	85.0	81.8
13	DH-XVR4116HS-X	410	374	91.2	91.2
14	DH-XVR7108HE-4KL-X	580	572	98.6	99.1
Overall		11,812	10,905	92.3	91.3

presents the overall recovery performance metrics across all 14 test drives.

The proposed methodology achieved an overall recovery rate of 92.3% and temporal accuracy of 91.3% across all 14 drives, recovering 10,905 of 11,812 expected video files. Performance varied significantly by drive condition. On drives without hardware issues (Drives 1–4, 6–11, 14), the average recovery rate was 97.1% with 97.9% temporal accuracy. The three problematic drives—Drive 5 (bad sectors, 81.3%), Drive 12 (metadata corruption, 85.0%), and Drive 13 (read errors, 91.2%)—lowered the overall averages but demonstrated the system’s resilience under adverse conditions.

Channel count was also associated with performance: 4-channel systems had an average 97.1% recovery, 8-channel systems had an average of 97.4% and 16-channel systems had an average of 89.9%. It was the three problematic drives that mainly drove the lower 16-channel average, all of which occurred to be 16-channel configurations; without these, 16-channel recovery averaged 96.9%. Figure 8 presents the per-drive recovery rate and temporal accuracy, where the impact of hardware degradation on Drives 5, 12, and 13 is clearly visible.

4.3. Comprehensive Performance Metrics

Table 4. Aggregate classification performance metrics.

TP	FP	FN	TN	Precision (%)	Recall (%)	Specificity (%)	F1
10,905	200	907	131,484	98.2	92.3	99.85	95.2

presents the aggregate classification performance across all 14 drives.

The system had a precision of 98.2%; this means that the huge percentage of files that were classified as a valid video were actually videos that could be played. The recall of 92.3% indicates the overall rate of recovery, the 907 false negatives can be mostly explained by the presence of severely corrupted frames on drives with hardware problems (491 false negative on Drive 12 alone, which is 54.1% of all false negatives). The 1.8% false positive rate (200 invalid files out of 11,105 total recovered items) shows that dual-signature validation works.

Analysis of the false positives showed that most (142 out of 200, 71%) were on 16-channel drives where the interleaving density is greater and thus more likely to occur by chance that a coincidental pattern matches the DHAV signature. The rest of the false positives (58, 29%) occurred because of partially written frames due to recording power interruptions, with valid headers but truncated payloads or corrupted payloads.

False negatives (907 missed files) were analyzed, and three main causes were identified: severely damaged files (612 files, 67.5%) failed all validation on damaged drives, very short video segments (189 files, 20.8%) were less than the minimum I-frame size, and partially overwritten files with missing or corrupted footer signatures (106 files, 11.7%).

4.4. Deleted File Detection Results

The deleted file detection mechanism identified 2191 files (20.1% of all recovered files) as previously deleted recordings, with the remaining 8714 files were classified as active. The proportion of deleted files was consistent across drives (17–23%), suggesting typical DVR operation with periodic circular buffer overwrites. This capability provides forensic investigators with immediate insight into potential evidence destruction without requiring additional analysis tools.

4.5. Processing Efficiency

Table 5. Processing time by channel configuration.

Configuration	Drives	Avg. Speed (GB/min)	Speed Range (GB/min)
4-channel	3	16.7	16.6–16.8
8-channel	6	14.9	14.5–16.8
16-channel	5	12.4	10.7–13.2
Overall	14	13.1	10.7–16.8

summarizes processing performance across different disk sizes and channel configurations.

The mean processing rate of 13.1 GB/min (or about 218 MB/s) allowed the full processing of the 34.5 TB dataset to be completed in about 44 h of total processing time. A strong negative correlation was observed between the number of channels and processing speed: 4-channel drives ran at 16.7 GB/min and 16-channel drives ran at 12.4 GB/min on average. Figure 9 plots the processing speed against the channel count across all 14 drives. This trend is expected because with increased channel counts, more active sequences must be maintained in the stitching pool, requiring more frequent sequence lookups and file I/O operations to produce per-channel output. Drive 5 (16-channel, bad sectors) had the lowest speed of 10.7 GB/min because it had to redo I/O on bad sectors.

4.6. Contextual Comparison with Existing Tools

It was not possible to compare the results directly with commercial forensic tools, which could not be tested using the analog DVR drives in this study, and there are no published independent comparisons of the performance of commercial tools on analog interleaved DVR systems. Rather,

Table 6. Feature comparison of forensic tools for surveillance video recovery.

Feature	Magnet DVR Examiner	VIP 2.0	DiskInternals DVR	Scalpel	Proposed
IP-based DVR/NVR support	Yes	Yes	Yes	Partial	Yes a
Analog interleaved DVR support	No	No	No	No	Yes
Channel demultiplexing	N/A	N/A	N/A	N/A	Yes
Per-camera output organization	Yes b	Yes b	Yes b	No	Yes
Dual-signature validation	Unknown	Unknown	Unknown	No	Yes
Deleted file detection	Yes	Yes	Partial	No	Yes
MD5 hash verification	Yes	Yes	Yes	No	Yes
Transparent algorithms	No	No	No	Yes	Yes
DHAV frame format support	Partial	Partial	Partial	No	Full

^a Via prior methodology [12]. ^b Available for IP-based systems where cameras produce separate streams; not applicable to analog interleaved storage. N/A = not applicable (feature requires analog interleaved stream input). Tool capabilities based on published documentation [4,5,6] and practitioner reports [13].

shows a qualitative feature comparison of the key differences between the current tools and the proposed methodology in terms of their fundamental capabilities.

The key difference here is that there is no known tool, either commercial or academic, to support channel demultiplexing of analog interleaved streams of DVRs. Some commercial tools like Magnet DVR Examiner [4], VIP 2.0 [5], and DiskInternals DVR Recovery [6] are intended to be used with IP-based architectures where the storage format includes per-camera separation. Practitioner reports indicate that these tools find data when using on analog DVR drives in the form of a single unsorted stream that needs manual post-processing to obtain data back out of the stream [13]. The main contribution of the proposed methodology, namely, automated channel demultiplexing, with an accuracy of 97.5%, fills this very gap.

5. Discussion

5.1. Channel Demultiplexing as a Novel Forensic Capability

The most important contribution of this work is channel demultiplexing, which is a solution to a forensic challenge that has not been addressed in previous literature. The 97.5% overall accuracy indicates that it is possible to perform automated separation of interleaved streams of analog DVR with high reliability. The remainder 2.5% of misidentified frames are focused on drives that contain hardware damage (Drives 5, 12, and 13) which have corrupted channel identifiers in DHAV headers and are routed incorrectly. On healthy drives, the demultiplexing accuracy was always greater than 98.3%.

This capability has a great practical forensic importance. In the absence of automated demultiplexing, investigators retrieving evidence in analog DVR systems would have to manually sift through thousands of interleaved video fragments, which is prohibitively time-consuming in investigations where time is critical. The proposed system converts what was previously a multi-day manual process into an automated one that is completed within minutes, with per-camera footage automatically available in well-organized directory structures.

5.2. Performance in Context

The total recovery rate of 92.3% should be considered against the background of the complexities of analog DVR storage. In contrast to IP-based systems, where each camera generates a separate data stream, analog systems also need to demultiplex, temporally reconstruct and validate the frame on all channels out of a single interleaved binary stream. These results are possible due to the methodology, even though the analog interleaving further complicates the results; a complication not found in IP-based systems that are the focus of existing commercial tools.

The impact of hardware degradation is clearly visible in the results. Drive 5 (bad sectors, 81.3% recovery) and Drive 12 (metadata corruption, 85.0%) show how any recovery methodology is limited by the fact that the underlying storage medium is damaged. Such findings are in line with the forensic fact that damage at the hardware level places an upper limit to the recovery that can be achieved no matter how sophisticated the algorithm used is. The methodology had 97.1% recovery on the remaining 11 drives, excluding the 3 drives known to have hardware problems, and has demonstrated good performance under typical operating conditions.

The false positive rate of 1.8% is quite low in terms of surveillance video recovery, which is due to the dual signature validation scheme, and both the DHAV header and dhav footer must be present and identical before a frame is accepted. Single-signature systems, where the only part that is verified is the header, are more prone to false hits due to chance occurrences of the same pattern of bytes in non-video disk areas. The conventional carving instruments like Scalpel that are not aware of proprietary frame structure at all have been known to generate significantly greater false positive results on surveillance media [20,21].

5.3. Processing Speed Analysis

The negative correlation between the number of channels and the processing speed (16.7 GB/min in 4-channel vs. 12.4 GB/min in 16-channel) indicates a key feature of the methodology’s computational profile. The main performance limitation is not the raw disk I/O but instead the sequence stitching pool management: 16 active channels at the same time means that there are much more active sequences in that algorithm, necessitating more frequent lookups and timeouts. This performance difference could be reduced in the future with hash-based sequence indexing (in place of the existing linear search).

The total processing of 13.1 GB/min (218 MB/s) allows it to be effectively used in forensic processing, and a 2 TB analog DVR drive with this processing would take about 2.5 h to completely analyze. This is a significant enhancement of the 3.9 GB/min that we were able to achieve with our previous Python 3.10.6-based approach to digital systems [12] and can be explained by the native C implementation with direct disk access to the operating system.

5.4. Generalizability to Other Analog DVR Vendors

The following implementation is vendor specific for the Dahua DHAV format; the architectural pattern of the proposed methodology is deliberately not vendor specific. The pipeline can be divided into four stages that are independent of any specific proprietary frame parser: (i) Parsing the frame with a vendor-specific frame parser, (ii) demultiplexing the channels based on the embedded channel identifier, (iii) stitching a sequence of channels with temporal validation, and (iv) validating and generating output. The definition of format dependent is just Stage (i); Stages (ii)–(iv) execute on a normalized internal frame record and are re-usable across vendors.

Hikvision analog (Turbo HD / HD-TVI) DVRs. The Hikvision analog DVRs use a proprietary frame encapsulation that differs from the IP-based Hikvision file system analyzed by Han et al. [2]. As in DHAV, each frame has an explicit channel identifier, but unlike DHAV, the frame structure varies in the magic-byte signatures and the field offsets in the header. The method needs to be adjusted to the DHAV header and footer signature matchers in the parser as well as the field offsets for channel ID, frame number and time stamp in the Hikvision pattern. The demultiplexer, stitcher and validator is reusable without necessary algorithmic changes.

Samsung (SRD/SHR series). Samsung analog DVRs have a proprietary container, header signature and per-frame channel tagging. Again, the same reusing of architecture occurs: only the frame layout is to be designed again in the parser stage.

General requirement. In all cases, the minimum information required to be exposed by a vendor format that would allow for the application of the methodology is: (a) a frame boundary signature that can be reliably detected, (b) an explicit channel identifier for each frame, and (c) a per-frame timestamp or a monotonic counter. The practitioner reports of all major analog (non-Dahua) DVR manufacturers that were surveyed [13] satisfy these requirements; thus, the framework generalizes naturally beyond Dahua. Extension of Hikvision and Samsung format is marked as a follow up high-priority direction.

5.5. Limitations

The methodology has several limitations to its applicability. First, the current implementation supports only Dahua analog DVR systems using the DHAV frame format. Other analog DVR vendors (Hikvision analog/XVR, Samsung, Bosch) use different proprietary formats and would require dedicated frame parsers, as discussed in Section 5.4.

Second, encrypted disk images are not supported. Although encryption remains uncommon in low-end analog DVR installations—the primary target of this methodology—it is becoming more frequent in higher-end models. Adding decryption support is technically challenging (proprietary encryption schemes) and may also be constrained by anti-circumvention legal provisions.

Third, the approach has been tested only on DHAV-based systems using H.264 and H.265 codecs. Older analog DVRs that use MJPEG or MPEG-4 encoding may require adaptation of the frame boundary detection and video reconstruction logic.

Fourth, channel separation accuracy is degraded on drives with severe hardware damage (93.8% on Drive 5), which may result in frames being assigned to the wrong camera. For drives known to be physically damaged, forensic investigators should manually verify channel assignments before drawing evidentiary conclusions.

Finally, the present evaluation is based on 14 drives from a single manufacturer’s product line. Although the DH-XVR series spans 4–16 channels and budget-to-professional models, a broader evaluation across additional manufacturers and configurations would strengthen the methodology’s generalization claims.

5.6. Future Research Directions

Several future research directions emerge from this work. Continued reverse-engineering of vendor-specific frame formats would extend the methodology to other analog DVR manufacturers, building on the architectural decoupling described in Section 5.4. Machine learning-based frame boundary detection may improve resilience to heavily corrupted media where signature-based matching fails. Multi-threaded per-channel parallelism, combined with the hash-indexed sequence pool described in Section 3.5, would address the performance degradation observed in high-channel-count configurations. Finally, integration of the channel demultiplexing capability into established forensic workflow platforms (e.g., as an Autopsy module or EnCase plug-in) would broaden access for the forensic practitioner community.

6. Conclusions

This study introduced a forensic recovery methodology focused on the idiosyncrasies of multi-channel analog DVR systems—a type of surveillance equipment that remains widely deployed but has been largely overlooked in the forensic community. The methodology was tested on 14 analog Dahua DVR hard drives ranging from 4-, 8- and 16-channels with a total capacity of 34.5 TB.

The channel demultiplexing algorithm was able to correctly separate interleaved DHAV frames from up to 16 cameras that were recording simultaneously (with architectural support for up to 32 cameras) with an accuracy of 97.5%, which allowed for automated, per-camera video organization that was not possible in analog DVR forensics. This feature is an essential real-world need for investigators to be able to view video footage from a single camera on seized analog DVR hardware without having to manually reconstruct frame-by-frame.

The overall recovery rate of 92.3% (97.1% for the drives where there was no hardware damage) and temporal accuracy of 91.3% show successful video reconstruction from interleaved streams. With a false positive rate of only 1.8% (using dual-signature DHAV/dhav validation), recovered files can be assured of their evidentiary validity. The deleted-file detection mechanism helped to recover 20.1% of the recovered files as previously deleted recordings, providing immediate insight into possible evidence destruction.

The native C implementation was able to process data at an average of 13.1 GB/min, and for a typical 2 TB analog DVR drive, it can fully analyze the data within roughly 2.5 h. The Win32 graphical interface, the built-in MD5 hashing and automatic forensic reporting make the technology more accessible to practitioners.

The following limitations apply to choosing this tool: At this time, it only works with Dahua analog systems operating with the DHAV frame format; it is not good for encrypted disk images and has lower performance when using severely degraded drives. Commercial devices could be better suited to an encrypted system, or for other manufacturers of analog DVR devices, and the architectural separation of the methodology (Section 5.4) offers a clear avenue to extend it to other analog DVR manufacturers.