Evidence Acquisition and Duplication practice questions

LiME

Why wrong: LiME (Linux Memory Extractor) is a loadable kernel module designed exclusively for capturing volatile RAM from Linux systems, exposing a /dev/lime interface for forensic acquisition. Because it requires kernel headers and root privileges on a Linux host, it cannot be used to acquire memory from a Windows machine under investigation; executing it would be irrelevant to this scenario, not merely less stable.

DumpIt

Why wrong: DumpIt is a bare command-line memory acquisition utility for Windows that reads physical memory via \Device\PhysicalMemory, but it performs a single uninterrupted pass with no built-in recovery or restart logic. On live systems with heavy I/O or incompatible hardware abstraction layers, this direct raw read can race with kernel state changes, causing a Blue Screen or frozen target and losing the very evidence it aims to capture.

FTK Imager

Why wrong: FTK Imager is primarily a disk and file forensic imaging tool whose memory capture feature requires a live system to keep running during acquisition; unlike dedicated RAM collectors, it uses a userland driver that does not synchronize with the operating system's memory manager. This can produce an inconsistent snapshot or fail to lock down pages, especially on Windows systems with active processes modifying memory, so it's stable enough for casual triage but less dependable for critical live acquisitions.

Acquire only one disk because RAID 5 can be reconstructed from a single disk

Why wrong: A RAID 5 volume distributes data and parity across every member disk in stripes, so no single disk contains a complete file system or a contiguous copy of the volume contents. With only one member disk, you can read individual stripes but cannot reconstruct the original linear block sequence or compute the missing data from the striped parity blocks. A single disk is enough to identify fragments, but it is not sufficient to recover the logical volume as a whole.

Use a hardware write blocker that supports RAID

Why wrong: A hardware write blocker is a forensic device that intercepts write commands at the ATA/SCSI command level to prevent any modification to a single attached physical drive; it has no capability to aggregate multiple drives into a RAID volume or emulate the controller's stripe and parity logic. While you should use a write blocker for each disk in its own individual acquisition, the blocker on its own cannot produce a logical RAID image. Software reconstruction is still required after the blocking writes to each disk are complete.

Connect the RAID array to a similar controller and acquire as a single drive

Why wrong: Connecting the drives to a 'similar' RAID controller is unreliable because foreign RAID metadata is often tied to the exact controller vendor, model, firmware, and configuration (such as the array's record type and disk order), and the controller may refuse to import the array or, worse, automatically rebuild or rewrite metadata. Additionally, a working controller would present the logical volume as a single block device, which means you would not capture underlying disk geometry, unallocated areas, or RAID metadata from each member disk—information that can be forensic-critical. Since the original controller is unavailable, a similar one still lacks the original configuration and cannot be trusted to produce a forensically sound image.

Nmap

Why wrong: Nmap is an active reconnaissance tool that sends crafted probes and analyzes responses to discover hosts, open ports, and running services, but it does not capture or preserve the raw frames of existing network traffic for later analysis. Its --packet-trace option only shows packets Nmap itself sends and receives, not an independent record of the wire. Using Nmap during an investigation would introduce new traffic onto the network, potentially contaminating the very evidence you need to preserve.

Netcat

Why wrong: Netcat is a generic TCP/UDP utility that connects to sockets and transfers raw byte streams, so it only sees the application-layer payload of a single connection it has initiated or accepted, never the wire-level frames that surround it. It cannot be placed into promiscuous mode, cannot read 802.3 MAC headers, VLAN tags, or IP headers, and it does not write a timestamped, structured capture file suitable for forensic integrity verification. Thus it is a data-transfer tool, not a packet-capture tool.

Tcpdump

Why wrong: Tcpdump lacks native support for full packet capture integrity checks, such as writing a hash of the capture file alongside the data, which is essential for maintaining a verifiable chain of custody in forensic work. It is tempting because it is a standard, lightweight command-line tool for real-time packet analysis and troubleshooting on Linux systems, and would be correct for ad-hoc network diagnostics where forensic soundness is not required.

Remove the drive and use a forensic bridge that supports SED

Why wrong: Removing the drive from the laptop cuts power to the SED, causing it to re-lock because the internal KEK (Key Encryption Key) is lost and the drive reverts to storing only ciphertext. A forensic bridge that 'supports SED' still requires the user's ATA or OPAL password to unlock the drive; without that credential, you cannot access the plaintext. This invasive step also risks physical damage and violates preservation best practices by changing the exhibit's state.

Power off the laptop and image the drive using a hardware write blocker

Why wrong: Powering off the laptop forces the SED into a locked state, because the in-drive memory holding the unwrapped media encryption key is cleared. A hardware write blocker only ensures read-only access at the ATA level; it does not decrypt anything. Consequently, you would image the ciphertext exactly as stored on the media, which is useless for forensic analysis unless you also possess the encryption key or can later crack the password. The correct approach is to acquire while the system is running and the drive is already decrypted.

Boot from a forensic live CD and image the drive

Why wrong: Booting from a forensic live CD requires a reboot, which terminates the running operating system and causes the SED to re-lock before the live environment can access the media. Even if the live CD is booted from an external drive, the internal SED will present encrypted data until the user manually authenticates with a password, which the investigator likely does not know. Additionally, a reboot destroys volatile memory that may contain the key material, eliminating any chance of a cold-boot key recovery and leaving only locked ciphertext.

To decrypt the drive during acquisition

Why wrong: A write blocker is a hardware or software mechanism that filters commands at the ATA/SCSI or NVMe level, rejecting any that would modify the storage medium. It does not perform cryptographic operations; decryption requires a separate key and tool, and attempting to decrypt during acquisition would inherently involve reading and potentially writing decrypted data back, which a write blocker would not allow. Therefore, decrypting the drive is outside the write blocker's function and scope.

To compress the acquired image

Why wrong: Write blockers are not designed to compress data; they simply pass read commands through while blocking write commands, without altering the data stream. Compression in forensic imaging is performed by software such as FTK Imager or dd with a compression algorithm, which creates formats like E01 or AFF. Even if a write blocker had compression capabilities, it would risk modifying the raw data and breaking the exact-for-forensic-copy standard, so it is not a function of the device.

To increase the speed of the acquisition

Why wrong: A write blocker does not increase acquisition speed; it is a passive component that may introduce slight delays due to protocol conversion or logic circuitry. The transfer rate is governed by the original drive's read speed, the acquisition interface (e.g., SATA, USB, NVMe), and the imaging software, not by the blocker itself. In some cases, a poorly designed write blocker can even bottleneck throughput, making speeds slower than a direct connection.

Use dd with a higher block size to skip bad sectors

Why wrong: Raising dd's block size merely increases the size of each read request; it does not instruct dd to skip or bypass bad sectors. dd's default behavior is to terminate immediately when a read error occurs, so a single unrecoverable sector will stop the acquisition and leave the rest of the drive unacquired. Even with conv=noerror,sync, a larger block size can amplify data loss because one bad sector poisons an entire block, making this an unreliable method for forensic imaging of failing media.

Use FTK Imager and ignore the errors

Why wrong: FTK Imager, like most GUI imaging tools, will display an error and may continue creating an image with unreadable sectors filled with placeholders, but simply ignoring these errors produces an incomplete and unreliable evidence copy. A forensic image must be a complete, bit-for-bit representation with any read failures documented, because evidence that is missing or untracked cannot be authenticated or explained in court. Ignoring errors also hides the location and extent of damaged areas, undermining the integrity of the entire acquisition.

Perform a physical acquisition by removing platters

Why wrong: Removing platters from a drive is a destructive, invasive procedure that typically requires a cleanroom and specialized equipment, and it permanently alters the original evidence. It is not a forensic acquisition method; even with platter removal, the data still must be read with specialized hardware, and the process risks head crashes or static damage that can destroy the very data being preserved. A forensic acquisition should be non-destructive, and this option should only be considered as a last resort after all logical and physical imaging attempts have failed, not as a routine response to bad sectors.

Copying the Windows registry

Why wrong: Copying the Windows registry is not a valid volatile-data acquisition method because registry hives such as SYSTEM, SAM, SOFTWARE, and NTUSER.DAT are stored as files in C:\Windows\System32\config and in each user profile on the system disk. While a registry hive may be partially cached in system cache memory, copying these files captures persistent configuration artifacts, not the transient live system state (like active connections or RAM contents) that is lost when power is removed.

Imaging the hard drive

Why wrong: Imaging the hard drive is a valid forensic preservation technique for persistent data, but it is not a method for acquiring volatile evidence because the physical disk is a non-volatile medium. Even a full disk image, complete with write-blocking and SHA-256 verification, cannot reveal data that existed only in memory at the time of incident, such as cached credentials, open network sockets, or the exact state of running processes.

Extracting the Master File Table (MFT)

Why wrong: Extracting the Master File Table (MFT) focuses on NTFS metadata that resides on the hard disk, recording file names, timestamps, sizes, and data run locations for the entire volume. The MFT is not a memory-resident structure, and copying it yields only filesystem bookkeeping from the moment of last write, failing to capture anything volatile like in-memory malware or established connections, so it is incorrect for this volatile-data question.

Power off the device immediately to preserve battery

Why wrong: Powering off the device immediately is not an acceptable best practice because the shutdown process can trigger full-disk encryption, require a passcode at next power-on, or activate hardware protection mechanisms that prevent forensic extraction. Battery preservation is unnecessary when the device can be maintained in a powered-on state within a Faraday environment. Turning off may also destroy volatile data and make it harder to establish a clean forensic image.

Only perform a physical acquisition, as it is the only forensically sound method

Why wrong: Insisting that only a physical acquisition is forensically sound is incorrect because physical acquisition may be impossible on modern devices with secure enclaves, file-based encryption, or vendor-specific hardware. Logical acquisition, when properly executed and documented, is an accepted forensic methodology and may be the only way to preserve user data from a locked or encrypted device. The forensic soundness lies in the integrity and documentation of the process, not in whether the extraction is physical or logical.

The output file already exists and is being overwritten

Why wrong: If the output file already exists and is being overwritten, the acquisition tool typically truncates and recreates the file or prompts for confirmation, neither of which produces an I/O error. Overwriting is a normal filesystem operation handled by the kernel using standard write syscalls; any conflict produces a 'file exists' warning or requires a 'clobber' option, not an EIO. An I/O error specifically indicates a problem communicating with a storage device during a read or write operation, not a file-naming or file-existence condition.

The target directory does not have write permissions

Why wrong: A lack of write permissions on the target directory causes the filesystem layer to reject the file creation request before any hardware write occurs. The kernel returns an EACCES or EPERM 'permission denied' error, not an I/O error, and the command would fail at open() or creat() time. Because the source disk reads are proceeding normally, this is an access-control problem, not a storage-device communications failure.

The target drive is full

Why wrong: When the target drive is full, the filesystem returns ENOSPC ('No space left on device') after the imaging tool has successfully read data from the source but cannot persist it. This is a capacity condition, not an I/O hardware error; the source reads succeeded and the data remains in memory until the write fails. An I/O error (EIO) instead indicates a device-level read/write failure, such as bad blocks or a detached drive, and is distinct from a quota or space exhaustion error.

The image is not forensically sound because the verification passed

Why wrong: The claim reverses cause and effect: verification is the procedural step that confirms the acquired image's hash values match the source's known hashes. Far from making the image unsound, a passing verification is the primary evidence of forensic integrity, certifying that the image has not been altered during acquisition or storage.

The source and image have different data

Why wrong: If the source and image had different data, their cryptographic hash digests would differ; a single differing bit would produce a radically different hash. Since the acquisition log shows the hash values for the source and image are identical, the data must be byte-for-byte the same, so this conclusion is factually contradicted by the evidence.

The image is corrupted because only one hash algorithm was used

Why wrong: The log actually records two hash algorithms (typically MD5 and SHA1), and both produce matching values between source and image. Corruption would manifest as a hash mismatch, not as a consequence of the number of algorithms used; matching digests from multiple algorithms actually strengthen, rather than weaken, confidence in the image's integrity.

Use a network acquisition tool like Guymager to image the drive over the network

Why wrong: Guymager is a disk-imaging tool, not a memory or triage tool; when pointed at a live SSD over a network, it copies a block device while the OS continues writing, yielding an inconsistent image that can miss recently deleted files and volatile artifacts. The network transport also makes acquisition slow enough that an attacker's live connections and in-memory indicators vanish before they are recorded. In breach response, capturing RAM and connection state must precede any disk imaging, so a purely network-imaging approach is inappropriate for preserving the most ephemeral evidence.

Immediately power off the server, remove the SSD, and image it using a hardware write blocker

Why wrong: Powering off the server before any triage destroys RAM, clears the kernel's connection tables, and eliminates any in-memory malware or decryption keys, effectively wiping out the attacker's most recent activity. Using a hardware write blocker afterward is a solid method for protecting disk integrity, but doing it in this order means self-encrypting SSDs may lock after the sudden power removal, and the missing volatile evidence cannot be recovered. The fundamental rule is to gather volatile data first and only then acquire disk media, so an immediate power-off fails the core forensic process.

Pull the power cord, remove the SSD, and use a forensic bridge to image the drive

Why wrong: Pulling the power cord is more destructive than an orderly shutdown because an abrupt power loss can corrupt the SSD's flash translation layer, trigger the controller's power-loss protection logic, and cause the drive to become temporarily unresponsive or locked. This method also forfeits all volatile data with no chance to dump RAM or snapshot network connections, and on a RAID server yanking power can mark the array degraded, adding further risk. While a forensic bridge is appropriate for offline imaging, the acquisition workflow must begin with memory capture and connection state, not by deliberately cutting power to the system.

Install FTK Imager on the server and capture memory to a network share

Why wrong: Installing FTK Imager onto the server violates forensic integrity because the installation process writes executable files, registry keys, and Windows prefetch data to the system drive, and launching the application loads DLLs and updates metadata that alter the very memory being acquired. Directing the capture to a network share also introduces network stack activity and delays, during which time transient kernel data changes, and the analyst cannot guarantee that the destination share is free of other writes. A proper live acquisition requires executing only a pre-validated tool from read-only media while preserving the original system state.

Use a remote acquisition tool over SSH to capture memory to a remote server

Why wrong: Using a remote acquisition tool over SSH requires running additional services and processes on the live target, and the resulting network connections, buffers, and cryptographic operations modify kernel memory and page caching, so the captured state is not an accurate snapshot of the original system. Many SSH-based memory capture utilities also rely on loading helper kernel modules or debuggers into the target's address space, creating artifacts that a thorough forensic examiner would later need to explain. Furthermore, streaming memory over the network is impractical and causes sustained I/O, which can trigger eviction of useful cached evidence before it is read.

Use the built-in task manager to create a memory dump and save it locally

Why wrong: The built-in Task Manager's 'Create dump file' feature is designed for application process dumps, not a complete physical memory acquisition, so it would omit kernel structures, loaded kernel drivers, and other processes critical to a full examination. It writes a large file to the local filesystem, which can overwrite unallocated disk space or the pagefile that could contain fragments of prior memory, destroying potential evidence. In addition, invoking a dump through a GUI tool changes the desktop heap and session manager state, and the resulting dump lacks the metadata and hashing needed for a defensible forensic integrity chain.

It compresses the acquired data to save storage space

Why wrong: This is incorrect because a write blocker is an I/O controller that intercepts commands at the bus level; it does not touch or transform the data payload flowing from the drive. Data compression is a feature of forensic imaging software (e.g., EWF format in EnCase or FTK Imager) that processes the data after it has been read. A write blocker simply permits read commands and discards write commands, so it has no mechanism to reduce the size of the acquired data stream. Therefore, attributing compression to a write blocker confuses the function of acquisition tools with hardware write-blocking.

It increases the speed of data acquisition

Why wrong: This is incorrect because a write blocker introduces an extra interface between the host and the source drive, which can add a tiny amount of latency due to command filtering and protocol translation; it never accelerates the acquisition process. The actual transfer throughput is determined by the source drive's interface speed, the workstation's bus, and the imaging tool's read algorithm, none of which the write blocker optimizes. In fact, certified hardware write blockers are often tested to ensure they do not alter the timing or data integrity, and they certainly do not cache or pipeline reads to make them faster. Thus, write blockers are physically incapable of increasing acquisition speed.

It creates a forensic image of the drive

Why wrong: This is incorrect because a write blocker is a pass-through device and has no storage, processing capability, or imaging logic; it cannot create any output file. Forensic imaging is performed by dedicated acquisition software (e.g., dd, dc3dd, FTK Imager, or Guymager) that reads the drive sector-by-sector through the write blocker and writes a bit-for-bit copy, often while computing a hash. A write blocker only ensures that the read operation is safe and does not modify the source; it is not an imaging tool and produces no image itself. Therefore, stating that it creates a forensic image confuses the facilitator with the actual processor.

The command preserves the partition table of the source disk.

Why wrong: The partition table (MBR/GPT) is preserved only because dd reads the entire disk as raw blocks starting at sector 0; dd has no special mechanism to protect or validate partition metadata. Any full raw-image process would copy those bytes identically, so this statement misattributes a generic result to a specific command feature. dd neither recognizes nor parses partition structures.

The command automatically computes MD5 hash of the output file.

Why wrong: dd is a low-level bitstream copier and contains no hashing engine. It simply reads from the source and writes to the destination, so no MD5, SHA-1, or other checksum is generated automatically. To verify forensic integrity, an examiner must run a separate utility such as md5sum or sha256sum, or use a variant like dc3dd that incorporates built-in hashing.

The output file will be compressed to save storage space.

Why wrong: dd does not compress output; it creates a raw, uncompressed image that is essentially the same size as the source disk. Compression would require piping through a compressor like gzip, as in 'dd if=/dev/sda | gzip > image.dd.gz', which changes the output format and demands decompression before analysis. Therefore, this option incorrectly attributes a feature to dd that it does not have.

512 MB

Why wrong: 512 MB is exactly half the real capacity and cannot be justified by the fsstat geometry values. It would result from mistakenly using 256 bytes per sector instead of the reported 512 bytes, or from dividing the correct byte total by 2 before converting to gigabytes. With 2,097,152 total sectors and 512-byte sectors, the byte count is 1,073,741,824 bytes, so halving that to 536,870,912 bytes (512 MB) is a clear arithmetic mishap rather than a legitimate filesystem figure.

1 MB

Why wrong: 1 MB is a distractor that comes from conflating file system metadata with volume capacity. The value roughly matches the MFT record count multiplied by the MFT record size (e.g., 1024 records × 1024 bytes), which yields about 1,048,576 bytes, but that only describes the size of the NTFS Master File Table or a small file, not the storage volume. The question asks for total disk space, so using MFT metadata rather than sector/geometry arithmetic is an invalid approach.

4 GB

Why wrong: 4 GB is not derivable from the values in the exhibit and likely results from misapplying the 4,096-byte cluster size. Multiplying the total sectors (2,097,152) by the cluster size (4,096) gives 8,589,934,592 bytes, i.e., 8 GB, not 4 GB; obtaining 4 GB would require using only half the sectors or a 2,048-byte sector size, neither of which appears in the fsstat output. The correct arithmetic must respect the report's sector size (512 bytes) and the fact that cluster count × cluster size also equals the same 1 GB total.

Run DumpIt as administrator on the live system, then boot from trusted media, then specify output, then verify hash.

Why wrong: Running DumpIt as administrator on the live system before booting from trusted media is fundamentally flawed because executing code within the target OS's environment will itself modify volatile memory—loading DLLs, allocating buffers, and altering kernel structures—thereby contaminating the very evidence you seek to capture. The proper procedure requires booting from a pre-validated forensic USB/CD first, so the target OS remains inert and no extraneous processes or drivers are loaded into memory. Only then can DumpIt be run with administrative privileges to acquire a pristine image, followed by output specification and hash verification.

Boot from trusted media, then specify output file path, then run DumpIt as administrator, then verify hash.

Why wrong: Selecting the output file path before launching DumpIt is out of order because DumpIt's standard interactive workflow prompts for the destination filename only after the tool has been initialized as an administrator. In forensic practice, the acquisition tool must first be executed (and, if needed, its kernel driver loaded) before the output path can be correctly specified; attempting to specify the path earlier is operationally meaningless and may cause the tool to fail or write to an unintended location. Consequently, the hash—which is computed from the resulting dump file—must also be verified only after the acquisition completes, making this sequence logically invalid.

Boot from trusted media, then run DumpIt as administrator, then verify hash, then specify output.

Why wrong: This is incorrect because verifying the hash before specifying the output file path doesn't make sense; the hash is computed after the dump is created. The output must be specified before acquisition, and verification occurs after.

HTTP: Port 443

Why wrong: Port 443 is specifically assigned to HTTPS, where TLS encryption is mandatory in practice. If an HTTP client mistakenly connects to port 443 and sends a plaintext GET request, the TLS server will reject it because the first expected bytes must form a ClientHello record. Therefore port 443 is not the default port for unencrypted HTTP; that default remains port 80.

HTTPS: Port 80

Why wrong: Port 80 is the registered default for plaintext HTTP, not HTTPS. When a client connects to port 443, the TLS handshake occurs before any HTTP data is exchanged; on port 80, the connection is unencrypted HTTP. Placing HTTPS on port 80 would break client assumptions that port 80 receives plaintext and the server's expectation of a TLS ClientHello, so port 80 is not the well-known port for HTTPS.

FTP: Port 22

Why wrong: Port 22 belongs to SSH (Secure Shell), used for encrypted remote administration, and is the default transport for SFTP (SSH File Transfer Protocol). File Transfer Protocol itself uses TCP port 21 for control commands and port 20 for active-mode data transfer. This option conflates the legacy FTP protocol with SFTP, which is not FTP but a distinct protocol running inside the SSH connection.

The dd command used a different block size

Why wrong: The dd tool's block size (bs) determines how many bytes are read and written per I/O operation, but the byte sequence read from the source drive is completely independent of this chunk size. Hash functions like MD5 or SHA-1 operate on the stream of bytes, not on I/O boundaries, so as long as the same logical sectors are read without errors, the resulting image will have an identical hash. A different block size could affect performance or cause read errors on failing media, but it cannot by itself produce a valid image with a different hash. Therefore, a block size difference would not explain a sudden hash mismatch.

The dd command compressed the output

Why wrong: The dd utility is a bit-for-bit copy tool that writes raw disk data to the output file by default; it does not apply any compression unless it is explicitly piped through a compress utility like gzip. Even if compression were used, it would be a lossless transformation, and a properly verified image would be decompressed before hashing, producing the same digest as the original. A compressed output file would have a different hash than the raw source, but that reflects a different file format, not a modification of the source data, and it would not be attributed to the dd command itself. Thus, compression cannot explain a hash mismatch between the original drive and the forensic image.

The image file was corrupted during transfer

Why wrong: A corrupt transfer usually manifests as read errors, I/O failures, or incomplete file writes that cause the acquisition tool to stop or produce a truncated image, and forensic tools typically verify block-level checksums during the copy. If the image file were corrupted in transit, the hash of the received file would be randomly different, but the comparison used in a proper forensic workflow involves hashing the source separately and hashing the image after the transfer; a bit-flip corruption would be detected as an error, not as a clean, consistent hash mismatch. Moreover, the question implies the image was successfully created and hashed, so corruption during transfer would require the corruption to occur before the image hash was computed, which is a different stage than the source-to-image transfer. Therefore, this option is not a plausible cause of the observed hash mismatch.

Use the built-in Windows backup to create a system image to an external drive

Why wrong: The built-in Windows Backup (e.g., 'Backup and Restore' or 'File History') is a backup utility, not a forensic acquisition tool. It does not create a bit-for-bit copy of the disk; instead, it copies files and system images using Windows' own file system APIs, which can alter access timestamps and fail to capture deleted data, slack space, and unallocated clusters. Running it also writes to the system drive and changes the state of the evidence before any forensic preservation, making it inherently unsound for legal proceedings.

Boot the system from a forensic live CD and create a forensic image of the hard drive while the system is running

Why wrong: Booting from a forensic live CD is a common approach for dead acquisition, but doing it *while the system is running* or as a response to a live system is problematic. The boot process itself overwrites RAM (destroying volatile data) and writes temporary files to the disk, changing timestamps and potentially overwriting evidence in unallocated space. Furthermore, if the system is compromised, the live CD may not have a trusted kernel or may be subject to rootkit interference, and imaging a mounted or in-use filesystem can result in an inconsistent, non-forensic image.

Immediately pull the power cord to perform a cold acquisition of the hard drive

Why wrong: While a hard power-off (cold acquisition) is sometimes used to preserve disk state when the system is already off or when malware might destroy evidence, it is not the initial step in a live response. Pulling the power cord instantly terminates all running processes and destroys volatile memory, losing critical evidence such as encryption keys, network connections, and active malware in RAM. It also risks filesystem journaling inconsistencies and may trigger write-caching data loss, potentially leaving the disk in an unclean state that complicates analysis and damages the integrity of the acquired image.

Shut down the server, remove the disk, connect it to a write-blocker, and acquire the disk image using FTK Imager; RAM is lost but disk acquisition is verified.

Why wrong: This approach violates the order of volatility. In live incident response, RAM must be captured first because it contains active processes, open network connections, decrypted data, and potential malware injection. Shutting down the server destroys that volatile evidence and may trigger anti-forensic mechanisms, while also causing unflushed disk caches to be lost. Disk acquisition afterward is fine, but only after memory has been collected.

Use FTK Imager over the network to acquire RAM first, then use dd to image the disk to the external drive via write-blocker.

Why wrong: Acquiring RAM over the network is inherently slow and alters the target system's state, especially with 64 GB of RAM where the transfer could take hours and risk lockups. Furthermore, using dd to image the disk to an external drive does not automatically compute cryptographic hashes, so you must run a separate hashing step that introduces an integrity gap. Proper forensic procedure requires hash verification during acquisition to prove the image is bit-for-bit identical to the source.

Use dd over netcat to acquire RAM and disk simultaneously, then compute hashes separately.

Why wrong: Using dd over netcat to acquire RAM is technically unreliable because RAM is not a block device, and dd will read through the address space in a way that may produce inconsistent or partial data while the system is running. Simultaneously acquiring disk and RAM also introduces I/O contention and potential data race conditions. Computing cryptographic hashes separately after the transfer, rather than during acquisition, creates a window where bit errors could go undetected and violates the forensic requirement for immediate verification.