CCTV and DVR Systems: Architecture and Evidence Acquisition

Analogue CCTV cameras output a continuous composite video signal over coaxial cable. The DVR at the other end of that cable samples the signal, compresses it using a codec (H.264, MPEG-4, or an older proprietary algorithm), and writes it to disk. The camera itself has no intelligence: it sends a raw signal and the DVR makes all the encoding decisions. This centralised design means all the forensic complexity lives in the recorder, not the cameras.

IP cameras are fundamentally different. Each camera is itself a small computer. It captures the image, compresses it to H.264 or H.265, and sends the compressed bitstream over the network. The NVR's job is storage and playback management; it does not re-encode the stream. The result is that an IP camera's footage is, in principle, more portable: if the NVR stores in a standard container format, any compliant player can open it. In practice, many NVR vendors wrap the streams in proprietary containers or apply custom extensions, so the examiner still needs to verify playback before declaring the export clean.

Hybrid systems exist: an older building may have had analogue cameras installed ten years ago but a newer DVR replacing the original recorder, or the IP cameras may feed a cloud storage service rather than a local NVR. Investigators should never assume the architecture from the cameras alone. The first step is always to locate the recorder, identify its make and model, and consult the vendor's documentation.

A budget DVR rated for sixteen cameras typically records at 25 frames per second (PAL) or 30 fps (NTSC) total across all channels combined, not per channel. With sixteen cameras active, each channel gets roughly 1.5 fps. The recorder cycles through channels, writing a short burst of frames from camera 1, then camera 2, and so on. Inside the recording file the data from all channels is interleaved: a block for channel 1, then a block for channel 2, repeating continuously.

To recover individual channel timelines, the examiner must demultiplex the recording. Some forensic tools (Amped FIVE, DVR Examiner) automate this. Others require manual frame extraction. In all cases the examiner should document the effective frame rate per channel, because a court trying to understand whether an action in the footage happened before or after another action needs to know how coarse the temporal resolution is.

Acquisition method selection depends on the device state, the time available, and the risk of data loss from powering off the recorder. The three main approaches are physical disk imaging, network export, and proprietary player extraction. They form a rough hierarchy of forensic robustness.

1. Physical disk imaging
   Power off the DVR/NVR, remove the internal drive, attach it to a forensic workstation through a hardware write-blocker, image the drive sector-by-sector using a tool such as FTK Imager or dd, and verify with a SHA-256 hash. This produces the most complete copy and preserves deleted or partially overwritten footage. The disadvantage is that it requires powering off the recorder, which may disrupt live recording or trigger a tamper alarm.
2. Network export
   Connect to the recorder's web interface or proprietary client software and download the footage for the relevant time range. This keeps the recorder running and avoids physical disassembly. The limitation is that the export is controlled by the device's own software, which may transcode or re-timestamp the footage. The examiner should hash the exported file immediately and note that the copy was produced by the recorder's export function.
3. Proprietary player extraction
   When the footage format is so proprietary that even physical imaging yields an unreadable container, the vendor's player software may be the only tool that can decode it. The examiner installs the player on a controlled workstation, mounts the imaged drive or connects to the original device in a read-only way if possible, and uses the player to export to a standard format. Every version of the player software used should be recorded, along with its hash, because the player itself is part of the evidential chain.

Hardware write-blockers intercept the command interface between a drive and the host computer. For standard SATA or USB drives this works transparently. Inside a DVR, the drive connects to the recorder's main board over a SATA interface, but removing it requires opening the enclosure and, sometimes, defeating tamper seals. Once extracted, the drive is treated like any other SATA device: insert into the write-blocker, connect to the forensic workstation, image, and hash.

Some DVRs use 2.5-inch laptop drives; others use standard 3.5-inch desktop drives; a growing number of NVRs use NVMe SSDs on M.2 slots. The examiner should carry adapters that cover all three form factors. If the internal drive uses a non-standard power connector, photograph and document the connector type before any modifications.

Chain of custody for a CCTV exhibit begins at the moment the investigator decides the footage is relevant. Before touching the recorder, the scene should be photographed: the recorder in situ, its connections, any on-screen display showing date and time, and the physical labels on the device. The investigator should note the displayed time against a trusted reference (GPS time or NTP-synchronised mobile) to establish the recorder's clock offset. Clock drift is one of the most common sources of evidential dispute in CCTV cases.

• Photograph the recorder in situ, including all cabling and the displayed time.
• Record the displayed time against a trusted reference to calculate clock offset.
• Seal the original drive (or the device) in a tamper-evident evidence bag with a unique exhibit number.
• Log every person who handles the exhibit, and the reason for each transfer.
• Store the original in a cool, dry environment away from magnetic fields.
• Work from the forensic image or an export copy, never from the original.

ACPO (the UK Association of Chief Police Officers, whose digital evidence guidelines remain widely referenced internationally even after ACPO itself was restructured into the National Police Chiefs' Council) sets out four principles for digital evidence: it must not be changed; any person accessing it must be competent; a log of all actions must exist; and the investigating officer bears responsibility for ensuring the law and these principles are adhered to. SWGDE guidance in the United States echoes these principles and adds specific validation requirements for the tools used.

DVR clocks drift. A system installed years ago with no NTP synchronisation may be minutes or even hours out. Establishing the offset is essential for placing events in the correct chronological context and for correlating the footage with other evidence sources (mobile phone records, access logs, witness testimony).

The standard approach is to photograph or video the DVR's on-screen time display alongside a simultaneously captured reference: a mobile phone showing GPS-locked time, or a radio clock. The difference between the two is the clock offset. This offset, and its direction (recorder fast or slow), must be recorded in the forensic report and applied to any time reference drawn from the footage.

The on-screen time burned into a CCTV recording is not the time the event occurred. It is the time the recorder's clock said it was. Those two things are only the same if the clock has been verified.

Some DVRs embed timestamp metadata in the file header separately from the on-screen burned-in text. Both should be checked. It is possible for the on-screen display to have been manually corrected while the file metadata retains the old (drifted) value, or vice versa.