Computer Forensics Fundamentals and Process practice questions

Connect a write blocker and create a forensic image immediately

Why wrong: Connecting a write blocker and immediately imaging the hard drive is a critical later step in the forensic workflow, but performing it before documenting the scene violates standard operating procedure because it modifies the system state by requiring the computer to be powered and potentially mounting devices. It also risks missing volatile data residing in RAM, such as encryption keys or active network connections, that would be lost when powering on or off. Additionally, a first responder may lack the required forensic tools, legal authority, or trained expertise to perform a sound acquisition, so scene documentation and triage must come first.

Immediately shut down the computer to prevent data alteration

Why wrong: Immediately shutting down the computer to preserve evidence is a common but flawed instinct because normal shutdown triggers the operating system to modify system files, such as clearing page files and recording clean shutdown events, and it destroys all volatile data in memory. Furthermore, modern systems with Fast Startup may not fully shut down and can flush cached data to disk, altering evidence. The correct sequence is to photograph the scene, then capture the RAM contents using a specialized memory acquisition tool, and finally choose the appropriate shutdown method based on the incident type.

Pull the power cord to ensure the system does not shut down normally

Why wrong: Pulling the power cord is a controlled, but not universally safe, action that should only be taken after volatile memory has been captured and the need to bypass the operating system's shutdown routines is justified, because an abrupt power loss can leave NTFS or ext4 filesystems inconsistent and may trigger journal replay or checkdisk on reboot. On systems with self-encrypting drives, cutting power can strip the decryption key from memory and make the drive inaccessible, while RAID arrays might enter a degraded state. This step is never the first action when a system is running, and it is only one choice among several based on the platform and evidence goals.

To speed up the data transfer rate during imaging

Why wrong: The write blocker's purpose is solely to block writes and pass reads through; it contains no mechanism to speed up data transfer. In fact, any extra hardware in the signal path can add a negligible amount of latency, though this is far outweighed by the source drive's own read speed and the host interface's throughput. Imaging speed is determined by the forensic imaging tool, the drive's transfer rate, and the interface (e.g., SATA, USB, FireWire), none of which are improved by the write blocker.

To compress the forensic image to save storage space

Why wrong: A write blocker operates at the physical command layer and has no awareness of file systems, streams, or data content, so it cannot perform compression. When a forensic image is compressed, the compression algorithm runs in software within the acquisition tool—such as FTK Imager, Guymager, or dc3dd—producing formats like E01, AFF, or compressed raw. The write blocker simply relays raw sector data unchanged, making compression entirely outside its function.

To automatically hash the drive contents for integrity verification

Why wrong: Hashing is a cryptographic computation performed by forensic acquisition software, not by a write blocker. A hardware write blocker is anelectrical/interface-level gatekeeper with no firmware for calculating MD5, SHA-1, or SHA-256; it only controls which commands pass to the drive. The imaging tool reads the drive through the blocker and computes the hash value, which is later used to verify that the acquired image matches the source—so hashing is a verification step, not a write-blocking feature.

Tableau write blocker

Why wrong: A Tableau write blocker is a hardware device placed between a forensic workstation and a suspect storage drive; it intercepts ATA/SCSI commands to prevent any writes to the disk while allowing read-only access. It operates at the storage bus level and has no capability to access or capture the contents of physical RAM, which is volatile memory managed by the operating system, not a block-addressable device. Memory acquisition requires software running on the system that can read memory addresses or invoke system APIs, something a hardware write blocker cannot do.

EnCase

Why wrong: EnCase Forensic is a comprehensive digital investigation platform whose core workflow revolves around acquiring and analyzing disk images, file systems, and logical evidence containers. While certain EnCase products, such as EnCase Enterprise or EnCase Portable, include remote memory capture capabilities, the standard EnCase Forensic tool traditionally used by investigators does not provide a direct, integrated memory acquisition function like FTK Imager. For a quick, standalone RAM acquisition on a live system, an investigator would typically use a dedicated memory-capture tool rather than EnCase, making it an inappropriate answer for this scenario.

dd

Why wrong: The dd command in Linux/Unix can technically capture raw memory by reading from special device files like /dev/mem or /dev/kmem, producing a raw memory dump. However, dd lacks built-in error checking, authentication, hashing, and metadata capture, so the resulting file may not meet forensic standards unless extra steps are taken (such as executing it after properly stabilizing the system and hashing output separately). Because memory is constantly changing, dd's sequential copy process can introduce inconsistencies and may partially capture modified data, making it a less sound method for preserving the volatile state compared to tools designed specifically for memory acquisition.

It limits the total amount of data to hash to 10 MB

Why wrong: The `hashwindow=10M` setting in dcfldd does not impose a 10 MB cap on the amount of data being hashed; rather, it partitions the input stream into 10-megabyte segments and computes a separate hash for each segment. The entire device or image file is still read and hashed in its entirety—the window only controls the 'grain size' of the individual hash computations. Confusing a partitioning granularity with a data limit is a common misinterpretation of this option.

It sets the hash algorithm to SHA-256

Why wrong: The `hashwindow` option only controls the frequency or block size at which hash values are emitted; it has no effect on which hash algorithm is selected. The algorithm is explicitly chosen by the separate `hash=sha256` parameter (or `md5`, `sha1`, etc.), while `hashwindow` merely states that a new digest should be calculated every 10 MB of input. Because SHA-256 is a cryptographic function with a fixed 256-bit output, it is not something that a windowing parameter could 'set'—the two options address different aspects of the hashing operation.

It enables error correction for every 10 MB

Why wrong: dcfldd's hashing capabilities—including per-window hashes—are purely for detecting corruption or unauthorized modification, not for repairing it. Error correction would require storing redundant information, such as Reed-Solomon parity bytes, and dcfldd does not generate or use such redundancy during acquisition. If a 10 MB segment fails its hash check, the analyst learns precisely which part is suspect but cannot reconstruct the original data from the hash alone, so 'enabling error correction' is not a valid interpretation of this option.

The file system is intact and readable

Why wrong: A matching hash between source and seized drive only proves that every bit was copied accurately; it says nothing about whether the file system metadata (boot sector, MFT, inodes, journals) is internally coherent or mounted cleanly. For example, a drive with a corrupted directory tree can still be imaged bit-for-bit and produce an identical hash, yet the file system would not be considered intact or readable in a logical sense. Thus hash equality is a necessary but not sufficient condition for file system integrity.

The drive contains malware

Why wrong: A cryptographic hash represents a unique fingerprint of the data content, but it does not perform any heuristic or signature-based analysis to detect malicious executables. Even if the image is a perfect bit-for-bit copy, it could contain malware, and conversely, a clean hash match does not exclude infection because hashes are not malware signatures. Determining malware presence requires scanning with antimalware engines, analyzing processes, or manual reverse engineering, none of which are accomplished by hash comparison.

The drive was not encrypted

Why wrong: Hash verification operates at the physical data layer and is agnostic to how the bytes are interpreted, so an encrypted drive imaged with a matching hash remains encrypted in the image. Encryption status is a property of the logical data encoding (e.g., BitLocker, FileVault, LUKS) that can be identified by examining for partition types, headers, or entropy analysis, not by comparing hashes. A bit-for-bit copy of an encrypted disk will have the same hash as the original, but that hash will not indicate whether the plaintext is accessible.

Perform a graceful shutdown to avoid data corruption

Why wrong: A graceful shutdown triggers the operating system to flush disk caches, update filesystem metadata, write event logs, and terminate processes — all of which alter stateful evidence on the medium. More importantly, it irrevocably destroys the contents of RAM, which may contain encryption keys, passwords, running processes, network connections, and recently used data. While it avoids some power-loss corruption, it actively overwrites forensic artifacts and violates the exchange principle that evidence must not be changed.

Remove the hard drive immediately while the system is running

Why wrong: Removing a hard drive from a running system without first acquiring volatile memory is both an electrical and forensic hazard. Hot-swapping can cause a surge that damages the drive or controller, leading to permanent data loss, and the drive's actuator arm may not be parked, increasing the risk of media damage. Additionally, the system continues writing to disk, logs, and swap during the process, so any data taken is not a pristine snapshot, and critical RAM evidence is lost entirely.

Immediately unplug the power cord to freeze the system state

Why wrong: Immediately unplugging the power cord causes the loss of RAM and CPU cache contents, which are often the most valuable evidence — including memory-resident malware, decrypted data, and active network sessions. It also prevents the operating system from flushing disk write caches, which can leave the filesystem in a dirty or inconsistent state and may trigger journal recovery on the next boot, altering timestamps and file metadata. This 'dead box' approach forfeits live-response evidence and is only acceptable if hostile conditions make a proper memory capture impossible.

Hearsay evidence is admissible if it is the only evidence available

Why wrong: Hearsay is an out-of-court statement offered for the truth of the matter asserted, and under FRE 802 it is inadmissible unless a specific exception or exclusion applies, such as business records or excited utterances. The mere fact that hearsay is the only available evidence does not create an exception; the rules of evidence do not contain a blanket 'necessity' exception. Therefore, this statement misapplies the hearsay doctrine and conflates it with the Best Evidence Rule, which addresses proving the content of documents, not hearsay statements.

The original digital media must be presented in court

Why wrong: The Best Evidence Rule prefers the original document, but for digital media it is not an absolute requirement to present the physical device in court. FRE 1003 permits a duplicate to be admitted to the same extent as the original unless a genuine question is raised about the original's authenticity or it would be unfair to admit the duplicate. Forensic images are routinely accepted as duplicates in digital evidence cases because the original storage media may be impractical to present or may have been lawfully seized in a different format.

Oral testimony is always better than written records

Why wrong: The Best Evidence Rule does not rank oral testimony above written records; rather, it prohibits oral testimony from proving the contents of a writing or recording when the original or a duplicate is available. In most contexts, written records are considered more reliable than oral testimony, and the rule actually discourages relying on oral recollection of a document's contents. Therefore, this option is incorrect because it reverses the rule's actual hierarchy and incorrectly generalizes to all forms of testimony rather than addressing documentary evidence.

It cannot be used with USB drives

Why wrong: Software write blockers are interface-agnostic; they operate at the logical volume or file system layer, intercepting write commands before they reach storage. With proper configuration, such as mounting volumes read-only via the OS or using a filter driver, they can be used with USB-attached media. The assertion that USB drives are unsupported is incorrect—the underlying USB mass storage device is still presented as a block device, and the same blocking mechanisms apply. The real challenge with USB is not interface incompatibility but ensuring the OS driver stack does not allow direct SCSI commands that bypass the filter.

It does not support hashing algorithms for integrity

Why wrong: Hashing algorithms are not a component of write blockers at all; they are executed by separate forensic acquisition or integrity-verification tools. Software write blockers provide read-only access to the storage medium, while the analyst uses an external utility (e.g., FTK Imager, EnCase) to compute MD5, SHA-1, or SHA-256 hashes on the acquired image. The absence of built-in hashing in a software blocker does not affect integrity verification because the hash calculation operates independently of how the underlying device is accessed. Therefore, claiming that software write blockers fail to support hashing algorithms is a misunderstanding of the forensic acquisition workflow.

It is more expensive than hardware write blockers

Why wrong: In practice, software write blockers are significantly less expensive than hardware write blockers—often free or costing only a modest licensing fee. Hardware write blockers are dedicated physical devices with specialized chipsets and firmware, which inherently carry manufacturing and R&D costs, putting them in the hundreds or thousands of dollars. Software blockers run on a standard forensic workstation and require no additional hardware investment, making them the economical choice for many labs. The cost disparity is a well-known advantage of software solutions, not a limitation.

A hard drive is encrypted and cannot be read

Why wrong: Encryption at rest is a data-protection mechanism, not a consequence of interaction between two entities. Although an encrypted hard drive may be impossible to read, the encryption itself is a pre-existing state or deliberate countermeasure, not a trace transferred during a procedure. The principle concerns trace evidence exchanged during contact, so the inability to decode data is irrelevant to establishing or refuting Locard's exchange.

A firewall blocks all incoming traffic from a specific IP address

Why wrong: A firewall rule that drops packets from a specific IP is an operational security control, not a record of any physical or digital exchange. The rule is applied based on preconfigured policy, and its action does not create or preserve trace evidence; rather, it prevents a connection from being made. Locard's principle requires actual contact and transfer of material, which is absent when traffic is blocked before any transaction occurs.

A write blocker prevents data from being written to a drive

Why wrong: A write blocker is a forensic tool intentionally interposed to maintain the integrity of a storage device; it functions by preventing any writes, but it does not itself acquire or transfer evidence. Its use is a procedure for preserving the evidentiary condition of data, not a trace left by an event. The principle would be exemplified by data transfers occurring between devices, not by the protective hardware used during examination.

A subpoena duces tecum

Why wrong: A subpoena duces tecum is a court order compelling a person or entity to produce documents, records, or other tangible items, but it does not authorize law enforcement to physically seize a computer. In criminal investigations, seizure of a computer without a warrant is only permitted under exceptions such as consent or exigent circumstances; a subpoena alone cannot justify a search or seizure, and noncompliance is typically addressed through contempt proceedings rather than immediate confiscation. Thus, it is not a valid lawful basis for seizing a computer under the Fourth Amendment.

No legal authorization is needed if the computer is in plain view

Why wrong: The plain view doctrine allows officers to seize evidence that is immediately apparent as incriminating and is observed from a lawful vantage point, but it does not automatically permit the seizure of a computer or the search of its digital contents. For the exception to apply, the incriminating nature of the object itself must be 'immediately apparent,' and a computer is a closed container of data whose content cannot be inspected without further intrusion. Even if a computer is in plain view during a lawful search, accessing its files requires a separate warrant or a recognized exception, so the claim that no legal authorization is needed is overbroad and incorrect.

Only a warrant issued by a judge

Why wrong: Requiring a warrant as the only means to seize a computer ignores the Supreme Court's repeated recognition that the Fourth Amendment's warrant clause is not absolute and that certain exceptions have long been part of criminal procedure. Officers may lawfully seize a computer with the owner's voluntary consent, or when exigent circumstances such as the imminent destruction or tampering of digital evidence necessitate immediate action to preserve the device. In the context of computer evidence, courts have consistently applied these exceptions, meaning a judge-issued warrant is not the exclusive route to lawful seizure. Consequently, the statement that only a warrant can justify seizure is overbroad and incorrect.

Immediately start the forensic imaging process

Why wrong: Immediate forensic imaging is premature because the scene and system must first be secured and documented; booting into an imaging environment alters the evidence before a baseline record exists. A proper responding officer verifies identity, secures the area, records hardware configuration, and only then performs imaging with a write-blocker to maintain evidentiary integrity. Jumping straight to imaging risks invalidating the case due to undocumented changes and lost context.

Install forensic software on the suspect's computer

Why wrong: Installing forensic software directly onto the suspect's computer is a serious error because the installation process itself writes files, modifies filesystem metadata, and can overwrite the exact artifacts needed to prove the case. This contamination violates the forensic principle that the original evidence must not be modified by the acquisition process. Any tool should be executed from a trusted, write-protected forensic boot medium, never installed onto the target system.

Interview all witnesses without documentation

Why wrong: Conducting witness interviews without contemporaneous documentation destroys the probative value of statements because memory fades and defense counsel can successfully challenge unrecorded recollections. A first responder should take written notes, record the interview, or obtain a signed statement; otherwise the information is unreliable. In addition, interviews must not displace the immediate stabilization of the scene and capture of volatile data.

Best evidence

Why wrong: The best evidence rule traditionally requires original writings, but in digital forensics, forensic images (bit-for-bit copies) are treated as functionally equivalent to originals when their integrity is verified through hash values and a documented chain of custody. Courts routinely admit these reproductions under Federal Rule of Evidence 1003, so it is a preference rather than a strict requirement for digital evidence.

Hearsay

Why wrong: Hearsay is a rule excluding out-of-court statements offered to prove the truth of the matter asserted; it does not govern the admissibility of physical or digital artifacts themselves. Computer-generated log entries, for example, are not hearsay because they are machine statements, not human declarations, though any embedded human textual content (e.g., chat messages) can implicate the hearsay rule. Thus, hearsay is an exception-based exclusionary rule, not a general gatekeeping requirement for digital evidence.

To prevent future cyber attacks

Why wrong: Prevention is a forward-looking security engineering goal, whereas computer forensics is a retrospective, evidence-centric discipline. In practice, forensic examinations begin after an incident or suspected wrongdoing, and the immediate objective is to capture volatile and persistent data in a defensible state. Findings may guide gaps in security controls, but that advisory outcome is not the discipline's primary purpose, and failure to prevent attacks does not invalidate a forensically sound investigation.

To identify and prosecute cybercriminals

Why wrong: Prosecution is one possible legal outcome from forensic findings, not the defining objective of the discipline. The primary goal is to preserve and analyze digital evidence so it remains integrity-checked, properly documented, and admissible under evidentiary rules, which also serves civil, administrative, internal and intelligence contexts. A forensic examiner can successfully establish facts that do not lead to criminal identification or conviction because the evidence may be inconclusive on actor identity; nonetheless, the forensic process can satisfy its purpose.

To recover deleted files from a hard drive

Why wrong: File recovery is a specialized technique for salvaging residual data from unallocated clusters or deleted directories, but it is only one component of the broader forensic process. A forensic examination uniquely should tie recovered data to user context through timestamps, file metadata, logs and correlation with other artifacts, all while preserving the original media and maintaining admissibility. Elevating file recovery to the primary goal ignores the equally critical tasks of live memory acquisition, timeline analysis, steganography detection and network forensics.

Chain of custody

Why wrong: Chain of custody is a procedural and legal framework that documents every seizure, transfer, possession, and disposition of evidence from collection to court presentation. It establishes the authenticity, integrity, and admissibility of evidence by maintaining a chronological record of each custodian, often requiring signatures and secure storage logs. A break in the chain can result in exclusion, but the concept addresses evidence handling and accountability, not the physical phenomenon of contact transfer.

Best evidence rule

Why wrong: The best evidence rule, codified in rules such as Federal Rule of Evidence 1002, requires that the original writing, recording, or photograph be produced to prove its content, unless an exception applies. It prioritizes originals over copies to prevent errors or misrepresentation inherent in secondary sources. This rule concerns the reliability of documentary proof, not the exchange of trace material between objects, and therefore has no bearing on the principle that every contact leaves a trace.

Hearsay rule

Why wrong: The hearsay rule is an evidentiary prohibition against admitting out-of-court statements offered to prove the truth of the matter asserted, because such statements lack the safeguards of cross-examination, oath, and demeanor observation. Numerous exceptions exist when the statement carries circumstantial guarantees of trustworthiness, but the rule fundamentally governs testimonial evidence about what someone said. It does not describe physical interactions, transfer of material, or any forensic principle about trace deposition.

Run antivirus software to check for malware

Why wrong: Running antivirus software on a live suspect system is an act that itself alters the evidentiary state: it creates new files, modifies system logs and timestamps, and may auto-quarantine or delete files that are relevant to the case. Even a read-only scan updates data structures like the NTFS $LogFile and last-accessed timestamps, contaminating every piece of digital evidence on the drive. Any malware analysis must be performed on a write-blocked forensic image in a controlled lab environment, never on the original evidence.

Immediately disconnect the power cord

Why wrong: Immediately disconnecting the power cord destroys volatile memory, which often holds the most valuable evidence such as running processes, network connections, decrypted sessions, and in-memory credentials. Such a hard power-off also risks filesystem inconsistency, forces a crash-consistency recovery on reboot, and can flush cached writes that overwrite unallocated space. The correct sequence for a live system is to first acquire RAM using a trusted forensic tool, then perform a graceful shutdown or forensically-safe power removal after gathering a memory image.

Copy all files from the hard drive

Why wrong: Copying all files from the hard drive merely reproduces the logical directory structure and active files, omitting deleted files, residual data in slack space, unallocated clusters, and the File System Metadata that are essential for recovery and audit. This file-by-file copy also updates each file's last-accessed time and modifies directory entries, further tainting evidence. A forensically sound approach is to create a bit-for-bit HDD image, utilizing a write blocker, so that every sector including free space is captured without altering the source.

To hash the output image

Why wrong: The conv=noerror,sync options in dd are unrelated to cryptographic hashing. Hashing the forensic image is a separate integrity step performed with tools like sha256sum or md5sum, often applied after the image is created. These conversion flags handle read errors and block padding, not hash computation, so this is not their purpose.

To ensure the command runs with superuser privileges

Why wrong: The conv=noerror,sync flags do not grant or modify superuser privileges. Access to raw block devices requires appropriate UID and filesystem permissions, independent of dd's conversion parameters. These flags merely instruct dd how to handle read errors and output padding; privilege escalation is not part of their function.

To compress the output image

Why wrong: conv=noerror,sync does not compress data; dd has no inherent compression capability. To produce a compressed image, one would need to pipe output through gzip or another compression utility. These flags serve to tolerate errors and preserve block alignment, not to reduce storage footprint, so this option is incorrect.

Wireshark

Why wrong: Wireshark is a network protocol analyzer that captures live packets from network interfaces using libpcap/WinPcap/Npcap. It records traffic such as TCP, UDP, and HTTP, but it cannot access or dump the contents of physical RAM. Therefore, while Wireshark is valuable for network forensic collection, it is not a memory acquisition tool and would not preserve volatile evidence from a running Windows system.

dd

Why wrong: dd is a Unix/Linux utility originally designed for low-level disk imaging and byte-for-byte copying of block devices. On Windows, available ports like GNU dd operate at the file system or volume level, not through the Windows memory manager APIs needed to capture physical RAM. Attempting to use dd on a live system would target storage media, not volatile memory, so it is inappropriate for this forensic collection task.

Tableau write blocker

Why wrong: Tableau write blockers are hardware forensic devices that sit between a suspect disk and a forensic workstation to prevent any write operations during disk imaging. They physically or electrically block write commands on SATA, IDE, or USB interfaces, ensuring the integrity of non-volatile storage. They have no mechanism to interface with RAM, and their purpose is to protect the evidence chain for disks, not to capture the volatile contents of a running machine.

FTK Imager is a valid forensic tool

Why wrong: A matching hash establishes that the acquired image is identical to the source media, but it does not validate the forensic tool's acceptability or legal standing. Tool validation is a separate process (e.g., NIST CFTT testing) that examines whether the software correctly performs acquisitions and hashing, and a hash match alone does not ensure the tool itself is court-admissible or free from software defects.

The original hard drive is free of malware

Why wrong: Hashing verifies that the image is a faithful copy of the original storage media at the moment of acquisition; it does not examine the content of that media. If the original drive was infected with malware, the hash would still match its exact copy, so matching hashes cannot support any conclusion about the presence or absence of malicious software on the source.

The image was acquired without using a write blocker

Why wrong: The hash matching process only confirms that the copied data is identical to the source data at the time of imaging; it reveals nothing about the acquisition methodology. A write blocker is used to prevent any writes to the original drive, and while its use is critical for preserving evidence integrity, a post-acquisition hash match cannot indicate whether a write blocker was in the hardware chain during acquisition.

Disconnecting the server from the network

Why wrong: Disconnecting the server from the network is a reactive containment step that halts further remote access and preserves volatile data, but it does not create the legally required documentation of evidence provenance. The act itself modifies the system state—active network connections are terminated and system processes may change—and without a contemporaneous record of that action, opposing counsel can argue the evidence is not trustworthy. Admissibility depends on demonstrating that the evidence remained unaltered from seizure onward, which requires a documented chain of custody, not merely a technical isolation event.

Running a full antivirus scan on the server

Why wrong: Running a full antivirus scan is a forensic analysis action that should be performed on a forensic copy of the original data, not the live server, because the scan itself alters evidence—file access times are updated, quarantined files are moved, logs are written, and the scan engine may modify the very artifacts it is inspecting. This alteration undermines the integrity of the original evidence and, without a documented chain of custody proving that the evidence was already in a reliable state, any conclusions drawn from the scan will be challenged. The priority during initial response is to preserve the original state and document its custody, not to perform potentially intrusive scans that could destroy the evidentiary value.

Taking screenshots of the server's screen

Why wrong: Taking screenshots of the server's screen provides a transient visual record of what was displayed at a given moment, which can be helpful for context, but it is not sufficient to ensure legal admissibility because screenshots do not establish the integrity or provenance of the underlying digital data. A screenshot can be easily manipulated, edited, or taken out of context, and it offers no verifiable metadata linking it to the original server state at the time of the incident. Chain of custody is the critical factor because it provides a forensic, verifiable trail of evidence handling, whereas a screenshot is simply a secondary representation that cannot support a legal argument on its own.

Fourth Amendment to the US Constitution

Why wrong: The Fourth Amendment protects U.S. persons against unreasonable searches and seizures by federal/state governments; it is a constitutional limitation on U.S. law enforcement, not a grant of power to U.K. police. Since the investigation is UK-based, the Fourth Amendment has no jurisdiction or application, and any challenge to the seizure would be assessed under PACE and the Human Rights Act (Article 8 ECHR), not U.S. jurisprudence.

General Data Protection Regulation (GDPR)

Why wrong: The GDPR governs the processing of personal data and grants data subject rights, but it does not contain search-and-seizure powers for law enforcement. While a seized computer will contain personal data, the lawfulness of the seizure itself is determined by PACE, and subsequent police processing is governed by the Law Enforcement Directive implemented in the UK as Part 3 of the Data Protection Act 2018. GDPR is therefore not the legal basis for the seizure.

Computer Misuse Act

Why wrong: The Computer Misuse Act 1990 creates offenses such as unauthorized access and unauthorized acts with intent to impair operation of a computer, and it does not confer any power of search or seizure on the police. When police seize a computer under a warrant, they are acting with legal authority, so their conduct is not 'unauthorized access' under the Act. The CMA is substantively different from PACE because it is a criminal statute penalizing computer misuse, not a procedural code governing evidence seizure.