Computer Forensics Lab practice questions

During a forensic investigation, an analyst needs to acquire data from a live Windows system without altering the system's state. Which tool should the analyst use to capture the contents of RAM?

Trap 1: dd

dd is a command-line utility for converting and copying files, typically used to create bit-for-bit images of disk block devices such as /dev/sda. It is not suited for RAM capture because physical memory is not presented as a regular block device, and reading from /dev/mem is deprecated and restricted by the kernel. Without a dedicated kernel driver and careful synchronization, dd cannot consistently read the entire volatile address space and may cause a system crash or produce an incomplete, chaotic image.

Trap 2: EnCase

EnCase is a comprehensive forensic suite designed primarily for acquiring and analyzing hard drives and other persistent media, offering workflows for evidence processing, hashing, and case management. While EnCase does have memory acquisition modules, they are part of a heavier, licensed application that typically requires installation and configuration, and the resulting overhead may change the system state more than a lightweight dedicated tool. In practice, investigators prefer a purpose-built volatile memory capture utility rather than EnCase for a quick, clean RAM image.

Trap 3: WinHex

WinHex is a sophisticated hex editor with some forensic capabilities, and it can access physical memory through its 'RAM Capture' feature, but it does so by reading through Windows virtual memory or using a temporary driver that is not as robust. This approach often causes the tool to induce noticeable side effects on the host, such as forcing additional paging activity or requiring privileges that alter memory, which can contaminate the evidence. As a result, WinHex may be acceptable for general forensics but is not the recommended tool for a pristine live RAM acquisition.

A
dd
Why wrong: dd is a command-line utility for converting and copying files, typically used to create bit-for-bit images of disk block devices such as /dev/sda. It is not suited for RAM capture because physical memory is not presented as a regular block device, and reading from /dev/mem is deprecated and restricted by the kernel. Without a dedicated kernel driver and careful synchronization, dd cannot consistently read the entire volatile address space and may cause a system crash or produce an incomplete, chaotic image.
B
FTK Imager Lite
FTK Imager Lite is specifically engineered for live volatile data acquisition; it loads a signed kernel driver that maps physical memory into a readable region so the entire RAM contents can be dumped to a .mem file without rebooting or forcing a system stop. Its minimal footprint and driver-based approach ensure that the acquisition process alters the system state far less than a typical application, making it the appropriate choice for capturing RAM during a forensic investigation. The tool also creates an audit log of the acquisition, supporting chain-of-custody requirements.
C
EnCase
Why wrong: EnCase is a comprehensive forensic suite designed primarily for acquiring and analyzing hard drives and other persistent media, offering workflows for evidence processing, hashing, and case management. While EnCase does have memory acquisition modules, they are part of a heavier, licensed application that typically requires installation and configuration, and the resulting overhead may change the system state more than a lightweight dedicated tool. In practice, investigators prefer a purpose-built volatile memory capture utility rather than EnCase for a quick, clean RAM image.
D
WinHex
Why wrong: WinHex is a sophisticated hex editor with some forensic capabilities, and it can access physical memory through its 'RAM Capture' feature, but it does so by reading through Windows virtual memory or using a temporary driver that is not as robust. This approach often causes the tool to induce noticeable side effects on the host, such as forcing additional paging activity or requiring privileges that alter memory, which can contaminate the evidence. As a result, WinHex may be acceptable for general forensics but is not the recommended tool for a pristine live RAM acquisition.

Question 2hardmultiple choice

A forensic lab is designing a network architecture to ensure the integrity of evidence during acquisition. What is the most critical design consideration?

Trap 1: Deploy multiple forensic workstations to parallelize tasks

Adding more forensic workstations to parallelize evidence processing only reduces total processing time and improves resource utilization; it does not address whether the source media remains bit-for-bit unchanged during acquisition. Forensic integrity is established by write protection and cryptographic hash verification at the moment of collection, not by the number of machines available. In fact, using multiple stations creates additional device and cabling variables that require separate validation, but parallelism itself neither verifies nor preserves integrity.

Trap 2: Use a segmented network to isolate forensic tools

Network segmentation, such as VLANs and air-gapped enclaves, protects forensic tools and evidence stores from external attack, malware propagation, and unauthorized access, but it does not prevent a drive from being altered while a forensic system acquires it. The integrity requirement concerns the source evidence media, not the network perimeter; segmentation has no mechanism to intercept or block write commands issued to a storage device. Even a perfectly isolated workstation will alter the exhibit unless a write-blocker is used.

Trap 3: Encrypt all data in transit over the network

Encrypting data in transit with TLS/SSH or IPSec preserves the confidentiality and often the authenticity of files moving across the network, but it does nothing to protect the original source drive from modifications during acquisition. The forensic integrity question is about whether the source media's bits are preserved, not whether copied data is protected while traveling; encryption cannot stop the operating system from writing metadata, timestamps, or temporary files to an attached evidence drive. Moreover, if network encryption is misconfigured or keys are unavailable, it can impede evidence transfer, yet it still never enforces write-blocking at the acquisition interface.

A
Deploy multiple forensic workstations to parallelize tasks
Why wrong: Adding more forensic workstations to parallelize evidence processing only reduces total processing time and improves resource utilization; it does not address whether the source media remains bit-for-bit unchanged during acquisition. Forensic integrity is established by write protection and cryptographic hash verification at the moment of collection, not by the number of machines available. In fact, using multiple stations creates additional device and cabling variables that require separate validation, but parallelism itself neither verifies nor preserves integrity.
B
Use a segmented network to isolate forensic tools
Why wrong: Network segmentation, such as VLANs and air-gapped enclaves, protects forensic tools and evidence stores from external attack, malware propagation, and unauthorized access, but it does not prevent a drive from being altered while a forensic system acquires it. The integrity requirement concerns the source evidence media, not the network perimeter; segmentation has no mechanism to intercept or block write commands issued to a storage device. Even a perfectly isolated workstation will alter the exhibit unless a write-blocker is used.
C
Encrypt all data in transit over the network
Why wrong: Encrypting data in transit with TLS/SSH or IPSec preserves the confidentiality and often the authenticity of files moving across the network, but it does nothing to protect the original source drive from modifications during acquisition. The forensic integrity question is about whether the source media's bits are preserved, not whether copied data is protected while traveling; encryption cannot stop the operating system from writing metadata, timestamps, or temporary files to an attached evidence drive. Moreover, if network encryption is misconfigured or keys are unavailable, it can impede evidence transfer, yet it still never enforces write-blocking at the acquisition interface.
D
Implement hardware write-blockers on all acquisition stations
A hardware write-blocker is inserted between the source drive and the forensic workstation, electrically or logically blocking write commands at the SATA/USB/IDE interface, so the operating system and forensic software cannot modify the original media under any circumstances. This is the direct technical control that preserves bit-for-bit integrity and enables valid cryptographic hash matching before and after acquisition. Using a write-blocker on every acquisition station is considered best practice in digital forensics and is required for standardized forensic imaging workflows.

Question 3easymultiple choice

A forensic analyst is troubleshooting a write-blocker that is not working correctly. The analyst connected the write-blocker between the suspect drive and the forensic workstation, but the workstation still shows the drive as writable. What is the most likely cause?

Trap 1: The write-blocker does not have external power

Most hardware write-blockers are powered through their USB interface or a dedicated AC/DC adapter, so lacking a separate external power source is normal and does not imply a protection bypass. A bus-powered write-blocker can still enforce write protection as long as it receives adequate power and enumerates correctly with the forensic host. Therefore, the absence of external power is not a valid explanation for the write-blocker failing to protect the drive.

Trap 2: The suspect drive uses SATA but the write-blocker is USB-only

A SATA suspect drive is not a problem if the write-blocker supports SATA on its drive-side interface; many write-blockers natively accept SATA drives while exposing a USB interface to the forensic workstation. The interface conversion from SATA to USB is handled by the write-blocker's bridge and does not compromise write protection. This option incorrectly treats a normal SATA-to-USB write-blocker configuration as a failure, so it is not the cause.

Trap 3: The write-blocker is connected to the suspect drive's output port

The write-blocker must be positioned in the data path between the forensic workstation and the suspect drive, with the drive connected to the blocker's target port and the host connected to the forensic port. If the blocker is instead attached to the suspect drive's output port, the drive-to-host direction would be reversed, but this physical misconnection is not the same as connecting the drive before power-up. The identified issue is the power-on timing, not the port orientation.

A
The suspect drive was connected before the write-blocker was powered on
Connecting the suspect drive before the write-blocker is powered on can allow the host operating system to enumerate and possibly write to the drive before the blocker's protection firmware initializes. If the drive is already attached when power is applied, transient voltages or direct host enumeration may bypass the blocker's write-command interception, contaminating the forensic image. The correct procedure is to power on the write-blocker first, confirm its status indicators, then connect the suspect drive.
B
The write-blocker does not have external power
Why wrong: Most hardware write-blockers are powered through their USB interface or a dedicated AC/DC adapter, so lacking a separate external power source is normal and does not imply a protection bypass. A bus-powered write-blocker can still enforce write protection as long as it receives adequate power and enumerates correctly with the forensic host. Therefore, the absence of external power is not a valid explanation for the write-blocker failing to protect the drive.
C
The suspect drive uses SATA but the write-blocker is USB-only
Why wrong: A SATA suspect drive is not a problem if the write-blocker supports SATA on its drive-side interface; many write-blockers natively accept SATA drives while exposing a USB interface to the forensic workstation. The interface conversion from SATA to USB is handled by the write-blocker's bridge and does not compromise write protection. This option incorrectly treats a normal SATA-to-USB write-blocker configuration as a failure, so it is not the cause.
D
The write-blocker is connected to the suspect drive's output port
Why wrong: The write-blocker must be positioned in the data path between the forensic workstation and the suspect drive, with the drive connected to the blocker's target port and the host connected to the forensic port. If the blocker is instead attached to the suspect drive's output port, the drive-to-host direction would be reversed, but this physical misconnection is not the same as connecting the drive before power-up. The identified issue is the power-on timing, not the port orientation.

Question 4mediummultiple choice

A forensic lab is establishing a chain of custody procedure. Which practice is considered best according to CHFI guidelines?

Trap 1: Require biometric authentication for all lab personnel

Biometric authentication verifies the identity of personnel attempting to access lab systems or evidence storage, but it does not track the movement of specific evidence items. A chain of custody requires a documented chronological history of each transfer, including who released and who received the evidence, with timestamps. Biometric access logs may show who entered a room, but they do not establish custody over a particular digital exhibit or forensic image. Therefore, while useful for access control, it is not a substitute for custody documentation.

Trap 2: Store evidence in a secure room with limited access

Restricting physical access to a secure evidence room reduces the risk of unauthorized tampering, yet it fails to document the individual who handled a specific piece of evidence at any given moment. Chain-of-custody protocols mandate a written or electronic log recording each removal, transfer, and return of evidence, along with the identities and signatures of the custodians. A limited-access policy alone cannot prove that the evidence has not been altered between collection and presentation in court. Physical security is a complementary control, not a custody record.

Trap 3: Use encryption to protect evidence files

Encryption protects the confidentiality and integrity of digital evidence while at rest or in transit, but it does not generate an auditable record of human custody. The chain of custody traces possession and control of the physical or logical evidence object, requiring signatures and timestamps for every change of hands. An encrypted container might preserve the evidence's content, but it cannot show who accessed the decrypted copy or when a forensic image was transferred. Thus, crypto safeguards data, while custody documentation safeguards legal admissibility.

A
Require biometric authentication for all lab personnel
Why wrong: Biometric authentication verifies the identity of personnel attempting to access lab systems or evidence storage, but it does not track the movement of specific evidence items. A chain of custody requires a documented chronological history of each transfer, including who released and who received the evidence, with timestamps. Biometric access logs may show who entered a room, but they do not establish custody over a particular digital exhibit or forensic image. Therefore, while useful for access control, it is not a substitute for custody documentation.
B
Store evidence in a secure room with limited access
Why wrong: Restricting physical access to a secure evidence room reduces the risk of unauthorized tampering, yet it fails to document the individual who handled a specific piece of evidence at any given moment. Chain-of-custody protocols mandate a written or electronic log recording each removal, transfer, and return of evidence, along with the identities and signatures of the custodians. A limited-access policy alone cannot prove that the evidence has not been altered between collection and presentation in court. Physical security is a complementary control, not a custody record.
C
Use encryption to protect evidence files
Why wrong: Encryption protects the confidentiality and integrity of digital evidence while at rest or in transit, but it does not generate an auditable record of human custody. The chain of custody traces possession and control of the physical or logical evidence object, requiring signatures and timestamps for every change of hands. An encrypted container might preserve the evidence's content, but it cannot show who accessed the decrypted copy or when a forensic image was transferred. Thus, crypto safeguards data, while custody documentation safeguards legal admissibility.
D
Document every transfer of evidence with signatures and timestamps
Proper chain-of-custody documentation requires an unbroken chronological record that identifies every individual who had control of the evidence, the exact date and time of each transfer, and the reason for the transfer. Each exchange must be signed by both the releasing and receiving custodians to verify that the evidence was in their possession and was not unaccounted for. This documentation is pivotal in court to demonstrate that the evidence is authentic and has not been substituted, altered, or tampered with. Without signatures and timestamps, a court may deem the evidence inadmissible on the grounds of a broken custody chain.

Question 5hardmulti select

Which TWO of the following are essential components of a computer forensics lab according to CHFI best practices?

Trap 1: Server farm for data processing

A server farm for data processing is not an essential component of a digital forensics laboratory because heavy processing tasks, such as hash generation or image indexing, can be outsourced to cloud services or performed on the forensic workstations themselves. The core laboratory requirements center on evidence integrity, chain of custody, and proper analysis tools, none of which mandate a centralized server infrastructure. While a lab may choose to add servers for convenience, their absence does not impair legally sound forensic analysis.

Trap 2: Public-facing website for case management

A public-facing website for case management is not an essential lab component; forensic case management must remain confidential and internally accessible, not exposed to the internet where it risks leaking case data or violating privacy rules. Secure internal case tracking software is useful, but a public-facing portal is actually a security liability and is unrelated to the physical and procedural elements required for evidence analysis. Therefore its presence is optional and, in many contexts, undesirable.

Trap 3: Coffee machine for staff convenience

A coffee machine for staff convenience is not essential because staff amenities do not affect the scientific validity or forensic soundness of the evidence examination process. Although refreshment may improve examiner morale, it plays no role in evidence preservation, analysis, or reporting, and is therefore not a component that a laboratory audit or accreditation standard would require.

A
Server farm for data processing
Why wrong: A server farm for data processing is not an essential component of a digital forensics laboratory because heavy processing tasks, such as hash generation or image indexing, can be outsourced to cloud services or performed on the forensic workstations themselves. The core laboratory requirements center on evidence integrity, chain of custody, and proper analysis tools, none of which mandate a centralized server infrastructure. While a lab may choose to add servers for convenience, their absence does not impair legally sound forensic analysis.
B
Evidence storage area with controlled access
Evidence storage area with controlled access is essential to a forensic lab because it establishes a physically secure, restricted environment where seized media can be preserved, inventoried, and protected from tampering, environmental damage, or unauthorized access. This directly supports the chain of custody and evidentiary integrity that courts require for admissibility, and is a core component per forensic laboratory best-practice standards. Without such an area, the entire examination process loses its evidentiary foundation.
C
Public-facing website for case management
Why wrong: A public-facing website for case management is not an essential lab component; forensic case management must remain confidential and internally accessible, not exposed to the internet where it risks leaking case data or violating privacy rules. Secure internal case tracking software is useful, but a public-facing portal is actually a security liability and is unrelated to the physical and procedural elements required for evidence analysis. Therefore its presence is optional and, in many contexts, undesirable.
D
Coffee machine for staff convenience
Why wrong: A coffee machine for staff convenience is not essential because staff amenities do not affect the scientific validity or forensic soundness of the evidence examination process. Although refreshment may improve examiner morale, it plays no role in evidence preservation, analysis, or reporting, and is therefore not a component that a laboratory audit or accreditation standard would require.
E
Forensic workstation with specialized software
A forensic workstation with specialized software is required for the actual examination and analysis of digital evidence, providing the necessary platform for disk imaging, carving, keyword searches, and artifact extraction using validated tools. In addition to software, the workstation must incorporate write-blockers and follow procedures to ensure data is not altered, making it a core functional element whose capabilities directly determine what evidence can be recovered. This is why it is considered an essential component of a computer forensics lab.

Question 6mediummulti select

Which THREE of the following are recommended practices for maintaining the integrity of digital evidence in a forensics lab?

Trap 1: Perform regular backups of all evidence

Regularly backing up evidence creates additional copies of data for disaster recovery, but it does nothing to verify the integrity or authenticity of the original evidence, and it does not establish a chain of custody. In forensic practice, backups are insufficient because they lack the sealed, hashed, and documented image build that is required; worse, unmanaged backups can lead to version confusion or unauthorized access. A backup may also be taken without a write-blocker, introducing potential modifications, so the correct approach is to create a verified forensic image with a hash, rather than routine backups.

Trap 2: Run antivirus scans on evidence before analysis

Running antivirus software directly on evidence before analysis can modify the evidence because antivirus programs often quarantine, delete, or 'repair' suspicious files, change metadata, or update access timestamps, all of which alter the forensic integrity. Even if the scan finds nothing, the very act of scanning may write to the volume. Instead, forensic examiners should work on an imaged copy and use a controlled, isolated environment where the original evidence is never exposed to such automated processes.

A
Maintain a detailed chain of custody log
A chain of custody log is a contemporaneous, written record that identifies each individual who handled the evidence, along with the date, time, and location of every transfer, plus the specific purpose for the transfer. This documentation is essential to demonstrate that the evidence has not been tampered with or substituted, which is a prerequisite for the evidence to be admissible in court. Without a proper chain of custody, even otherwise authentic evidence may be excluded on the grounds of insufficient proof of integrity.
B
Generate cryptographic hashes of evidence files
Cryptographic hash functions such as SHA-256 generate a unique fixed-length digest of a file or disk image, meaning that any change to the underlying data, no matter how minor, will yield a completely different hash value. By computing an acquisition hash immediately after collection and later re-hashing the evidence, an examiner can mathematically prove that the evidence has not been altered during the investigation. This process is non-destructive, and the hash values themselves form part of the evidence file's metadata, providing a time-stamped integrity check.
C
Use hardware write-blockers during acquisition
A hardware write-blocker sits between the source drive and the forensic workstation, intercepting and blocking any write commands at the ATA, SATA, or SCSI protocol level, so the source media is completely read-only. Unlike software write-blockers, which rely on the operating system being bug-free, a hardware solution guarantees that no byte can be written to the evidence drive, regardless of any system misbehavior. This ensures that the original drive remains bit-for-bit indistinguishable from when it was seized, preserving timestamps, slack space, and unallocated clusters for later analysis.
D
Perform regular backups of all evidence
Why wrong: Regularly backing up evidence creates additional copies of data for disaster recovery, but it does nothing to verify the integrity or authenticity of the original evidence, and it does not establish a chain of custody. In forensic practice, backups are insufficient because they lack the sealed, hashed, and documented image build that is required; worse, unmanaged backups can lead to version confusion or unauthorized access. A backup may also be taken without a write-blocker, introducing potential modifications, so the correct approach is to create a verified forensic image with a hash, rather than routine backups.
E
Run antivirus scans on evidence before analysis
Why wrong: Running antivirus software directly on evidence before analysis can modify the evidence because antivirus programs often quarantine, delete, or 'repair' suspicious files, change metadata, or update access timestamps, all of which alter the forensic integrity. Even if the scan finds nothing, the very act of scanning may write to the volume. Instead, forensic examiners should work on an imaged copy and use a controlled, isolated environment where the original evidence is never exposed to such automated processes.

Question 7easymultiple choice

You are a forensic analyst in a corporate lab. A compromised server was taken offline and brought to the lab. The server runs Windows Server 2019 with a RAID 5 array of three 1TB SATA drives. The drives are hot-swappable. The server was shut down properly before removal. The lab has a forensic workstation with write-blockers, a hardware RAID controller, and imaging software. The analyst needs to acquire a forensic image of the RAID array. What is the correct course of action?

Trap 1: Send the drives to a vendor for specialized RAID recovery

Outsourcing to a commercial vendor introduces a break in chain of custody and requires a documented evidence transfer, adding logistical complexity and potential legal risk. More importantly, vendor recovery systems are designed for data recovery, not forensic acquisition; they may use non-forensic processes or modify the array during extraction. Because you already have the appropriate controller model in the lab, external involvement is unnecessary and could compromise the admissibility of the evidence.

Trap 2: Image each drive individually using a write-blocker and then…

Imaging each drive individually with a write-blocker is a common raw acquisition technique, but it captures only the physical members, not the assembled logical volume. The individual images contain RAID metadata and striped/parity data that must be reassembled out-of-band; forensic software often cannot deterministically resolve the proprietary hardware RAID layout from these images alone. Even if reconstruction were possible, you would still need to reverse-engineer the controller's geometry, making this approach more error-prone than acquiring the logical volume directly.

Trap 3: Connect all drives to the forensic workstation and use a software…

Connecting the drives directly to a forensic workstation and using a software RAID tool is risky because standard software RAID (e.g., Linux mdadm or Windows dynamic disks) cannot interpret proprietary hardware RAID metadata formats. The tool may misidentify the array structure, and the operating system might automatically attempt to write recovery or journaling data to the drives if they are not protected by a write-blocker. Additionally, a software RAID assembly on the workstation will not replicate the exact controller behavior, potentially presenting an incorrect logical volume.

A
Reconstruct the RAID array using the same controller model in the lab, then image the logical volume via a write-blocker
Reconstructing the array on an identical hardware RAID controller in the lab is the proper method because the controller's firmware natively understands the vendor-specific RAID metadata (e.g., DDF or proprietary on-disk formats) and will correctly reassemble the logical volume without modifying the member drives. Once the array is online, you must acquire the resulting logical volume through a write-blocker, ensuring the forensic image captures the filesystem exactly as the OS would have seen it while preserving evidentiary integrity. This approach keeps the drives in your custody, avoids unnecessary third-party exposure, and is the most forensically sound method for hardware RAID.
B
Send the drives to a vendor for specialized RAID recovery
Why wrong: Outsourcing to a commercial vendor introduces a break in chain of custody and requires a documented evidence transfer, adding logistical complexity and potential legal risk. More importantly, vendor recovery systems are designed for data recovery, not forensic acquisition; they may use non-forensic processes or modify the array during extraction. Because you already have the appropriate controller model in the lab, external involvement is unnecessary and could compromise the admissibility of the evidence.
C
Image each drive individually using a write-blocker and then combine the images in software
Why wrong: Imaging each drive individually with a write-blocker is a common raw acquisition technique, but it captures only the physical members, not the assembled logical volume. The individual images contain RAID metadata and striped/parity data that must be reassembled out-of-band; forensic software often cannot deterministically resolve the proprietary hardware RAID layout from these images alone. Even if reconstruction were possible, you would still need to reverse-engineer the controller's geometry, making this approach more error-prone than acquiring the logical volume directly.
D
Connect all drives to the forensic workstation and use a software RAID tool to assemble the array
Why wrong: Connecting the drives directly to a forensic workstation and using a software RAID tool is risky because standard software RAID (e.g., Linux mdadm or Windows dynamic disks) cannot interpret proprietary hardware RAID metadata formats. The tool may misidentify the array structure, and the operating system might automatically attempt to write recovery or journaling data to the drives if they are not protected by a write-blocker. Additionally, a software RAID assembly on the workstation will not replicate the exact controller behavior, potentially presenting an incorrect logical volume.

Question 8mediummultiple choice

A forensic lab manager is setting up a new lab and must decide on the physical security measures. Which of the following is the MOST important to implement first?

Trap 1: Construct Faraday cages around the evidence storage area

Faraday cages are primarily designed to attenuate electromagnetic signals, preventing wireless data exfiltration or remote tampering, but they offer no physical barrier to unauthorized human access. A forensic lab's evidence storage area needs to resist forced entry, theft, and insider misuse; a Faraday cage's conductive mesh does not address locks, door hardening, or authentication. Thus, while it may be a specialized safeguard for certain electronic evidence, it is not a core access control measure and would not be the first security investment in a new lab.

Trap 2: Deploy CCTV cameras covering all entry points

CCTV systems are detective controls that document events after they occur, capturing video of entry attempts or suspicious activity, but they lack the capability to physically prevent or authenticate access in real time. An intruder can bypass a camera entirely or disable it, and the system will not deny entry to an unauthorized person. Effective physical security requires a preventive mechanism such as a biometric or card-based access control system at the door, with CCTV serving as an ancillary monitoring and evidence-collection tool, not as the primary control.

Trap 3: Install a gas-based fire suppression system

Gas-based fire suppression protects against environmental hazards by flooding an area with inert gas or chemical agents to extinguish fires, but it is unrelated to unauthorized human access or evidence handling. It is a life-safety and asset-preservation system that operates only during a fire event, providing no authentication, intrusion detection, or barrier to entry. In a forensic lab, the most immediate threat is human compromise of evidence chain of custody, so access control must precede fire safety in priority, even though both are essential for comprehensive lab resilience.

A
Construct Faraday cages around the evidence storage area
Why wrong: Faraday cages are primarily designed to attenuate electromagnetic signals, preventing wireless data exfiltration or remote tampering, but they offer no physical barrier to unauthorized human access. A forensic lab's evidence storage area needs to resist forced entry, theft, and insider misuse; a Faraday cage's conductive mesh does not address locks, door hardening, or authentication. Thus, while it may be a specialized safeguard for certain electronic evidence, it is not a core access control measure and would not be the first security investment in a new lab.
B
Deploy CCTV cameras covering all entry points
Why wrong: CCTV systems are detective controls that document events after they occur, capturing video of entry attempts or suspicious activity, but they lack the capability to physically prevent or authenticate access in real time. An intruder can bypass a camera entirely or disable it, and the system will not deny entry to an unauthorized person. Effective physical security requires a preventive mechanism such as a biometric or card-based access control system at the door, with CCTV serving as an ancillary monitoring and evidence-collection tool, not as the primary control.
C
Install a gas-based fire suppression system
Why wrong: Gas-based fire suppression protects against environmental hazards by flooding an area with inert gas or chemical agents to extinguish fires, but it is unrelated to unauthorized human access or evidence handling. It is a life-safety and asset-preservation system that operates only during a fire event, providing no authentication, intrusion detection, or barrier to entry. In a forensic lab, the most immediate threat is human compromise of evidence chain of custody, so access control must precede fire safety in priority, even though both are essential for comprehensive lab resilience.
D
Implement a biometric access control system
Biometric access control authenticates individuals using unique physiological characteristics—such as fingerprints, iris patterns, or facial geometry—making it nearly impossible to lend, steal, or duplicate credentials. This enforces physical access as a preventive control, ensuring only pre-authorized personnel enter evidence storage areas, thereby maintaining chain of custody and legal defensibility. Unlike keys or cards, biometrics provide non-repudiation because each entry attempt is tied to a specific person and can be logged for audit. It directly addresses the foundational risk of unauthorized access, which is the first and most critical security requirement for a forensic lab.

Question 9hardmultiple choice

Refer to the exhibit. A forensic examiner is analyzing a Windows system and sees the above NTFS file metadata. The user claims the file was last accessed at 09:15. Which of the following best explains the discrepancy?

Exhibit

Refer to the exhibit.

=== File System Analysis Report ===
Drive: /dev/sda1 (NTFS)
Inode: 2345
File: critical_data.docx
Creation Time: 2024-03-10 09:15:00 UTC
Last Modified: 2024-03-10 09:20:00 UTC
Last Access: 2024-03-10 09:25:00 UTC
$LogFile Sequence Number: 123456
$UsnJrnl: Entry 7890
=== End of Report ===

Trap 1: The system has disabled last access time updates, so the reported…

If last access time updates were disabled—via the registry value NtfsDisableLastAccessUpdate or the fsutil behavior set disablelastaccess 1—NTFS would not modify the Last Access Time field when files are opened. The exhibit shows the Last Access Time advancing to 09:25, proving the mechanism was active at that moment. Therefore the reported times are not made unreliable by disabled updates; instead, they reflect genuine read activity.

Trap 2: The creation time is earlier than the last access, indicating the…

NTFS definitionally records the creation time as the moment the file is first created in the current volume; a standard copy operation from another volume would issue a fresh creation timestamp at the copy time, not preserve an earlier one. A creation time being earlier than the last access time is simply chronological order—anything created is necessarily accessed later. This pattern offers no evidence of cross-volume copying, which normally produces a creation time equal to or near the copy time.

Trap 3: The $LogFile sequence number indicates a transaction rollback that…

The $LogFile is NTFS's transactional journaling log, used for crash consistency and rollback of incomplete metadata operations, not for recording or resetting file access timestamps. The sequence numbers it contains indicate the order of journaled transactions, and replaying the journal would return metadata to a previous consistent state rather than advancing an access time. Consequently, there is no such transaction rollback that selectively changes last accessed timestamps in the manner observed.

A
The $UsnJrnl entry shows the file was modified, and the last access time was updated by the system when the file was opened for reading
The $UsnJrnl (NTFS Update Sequence Number journal) records every metadata-affecting change, so a file modification such as a data overwrite or extend appears with its own reason flag and timestamp. On Windows, opening a file for read operations can update the Last Access Time attribute independently, which is why the last access time is later than the modification time in the exhibit. This is a normal, expected pattern: a write occurred first, then a read at 09:25 caused the last access timestamp to update.
B
The system has disabled last access time updates, so the reported times are unreliable
Why wrong: If last access time updates were disabled—via the registry value NtfsDisableLastAccessUpdate or the fsutil behavior set disablelastaccess 1—NTFS would not modify the Last Access Time field when files are opened. The exhibit shows the Last Access Time advancing to 09:25, proving the mechanism was active at that moment. Therefore the reported times are not made unreliable by disabled updates; instead, they reflect genuine read activity.
C
The creation time is earlier than the last access, indicating the file was copied from another volume
Why wrong: NTFS definitionally records the creation time as the moment the file is first created in the current volume; a standard copy operation from another volume would issue a fresh creation timestamp at the copy time, not preserve an earlier one. A creation time being earlier than the last access time is simply chronological order—anything created is necessarily accessed later. This pattern offers no evidence of cross-volume copying, which normally produces a creation time equal to or near the copy time.
D
The $LogFile sequence number indicates a transaction rollback that reset the timestamps
Why wrong: The $LogFile is NTFS's transactional journaling log, used for crash consistency and rollback of incomplete metadata operations, not for recording or resetting file access timestamps. The sequence numbers it contains indicate the order of journaled transactions, and replaying the journal would return metadata to a previous consistent state rather than advancing an access time. Consequently, there is no such transaction rollback that selectively changes last accessed timestamps in the manner observed.

Question 10easymulti select

Which TWO of the following are essential requirements for a computer forensics lab according to best practices?

Trap 1: Offsite cloud storage for all case files

Offsite cloud storage for all case files is not an essential requirement for a forensic laboratory because it introduces significant confidentiality and legal risks without addressing core forensic needs. While cloud storage can be used, all case files must not be automatically replicated offsite unless end-to-end encryption, strict access controls, and compliance with data protection regulations (such as CJIS, GDPR, or HIPAA) are demonstrably enforced. Even then, cloud storage creates jurisdictional questions about discovery, subpoena, and chain of custody, so a forensic lab must rely primarily on local, access-controlled storage.

Trap 2: Shared workstations to reduce hardware costs

Shared workstations to reduce hardware costs directly undermine forensic integrity through the risk of cross-contamination between cases. Forensic examiners need dedicated, write-blocked workstations with a clean baseline image so that artifacts from one investigation cannot inadvertently appear in another case's analysis. Sharing hardware also complicates records of forensic tool usage, makes hash verification of software environments difficult, and can cause evidence to be invalidated in court because the system's provenance is not airtight.

Trap 3: Open wireless network for flexibility

An open wireless network for flexibility is categorically insecure and unacceptable in a forensic laboratory environment because it allows any nearby device to capture network traffic, intercept data, or initiate man-in-the-middle attacks. Forensic labs must use physical wired connections or at minimum WPA3-Enterprise with mutual authentication, as wireless signals can leak beyond the facility and may be sniffed without physical access. An open network also undermines the confidentiality of case data and the integrity of evidence during remote or live acquisitions, making it a major security flaw.

A
Uninterruptible power supply (UPS) and surge protectors
A UPS and surge protectors are essential in a forensic laboratory because they condition incoming power and prevent abrupt shutdowns, which can otherwise corrupt the filesystem, damage the read/write heads of evidence drives, or interrupt an ongoing forensic acquisition. A UPS also provides time for a controlled shutdown of analysis workstations, preserving the integrity of any volatile data being captured and ensuring that evidence storage arrays do not suffer from dirty power events. Surge protectors additionally clamp voltage spikes that could permanently destroy write-blockers and other specialized hardware.
B
Offsite cloud storage for all case files
Why wrong: Offsite cloud storage for all case files is not an essential requirement for a forensic laboratory because it introduces significant confidentiality and legal risks without addressing core forensic needs. While cloud storage can be used, all case files must not be automatically replicated offsite unless end-to-end encryption, strict access controls, and compliance with data protection regulations (such as CJIS, GDPR, or HIPAA) are demonstrably enforced. Even then, cloud storage creates jurisdictional questions about discovery, subpoena, and chain of custody, so a forensic lab must rely primarily on local, access-controlled storage.
C
Shared workstations to reduce hardware costs
Why wrong: Shared workstations to reduce hardware costs directly undermine forensic integrity through the risk of cross-contamination between cases. Forensic examiners need dedicated, write-blocked workstations with a clean baseline image so that artifacts from one investigation cannot inadvertently appear in another case's analysis. Sharing hardware also complicates records of forensic tool usage, makes hash verification of software environments difficult, and can cause evidence to be invalidated in court because the system's provenance is not airtight.
D
Restricted access with visitor logs and biometric authentication
Restricted access with visitor logs and biometric authentication is essential because it establishes a complete physical audit trail for evidence handling and laboratory operations. A forensic lab must be able to prove, beyond any reasonable doubt, exactly who entered the evidence storage area and when, which is critical to maintaining chain of custody. Visitor logs provide a non-repudiable record of escorted access, while biometric authentication (e.g., fingerprint or iris scanning) ensures that shared credentials, lost badges, or tailgating cannot compromise evidence security.
E
Open wireless network for flexibility
Why wrong: An open wireless network for flexibility is categorically insecure and unacceptable in a forensic laboratory environment because it allows any nearby device to capture network traffic, intercept data, or initiate man-in-the-middle attacks. Forensic labs must use physical wired connections or at minimum WPA3-Enterprise with mutual authentication, as wireless signals can leak beyond the facility and may be sniffed without physical access. An open network also undermines the confidentiality of case data and the integrity of evidence during remote or live acquisitions, making it a major security flaw.

Question 11mediummulti select

A forensic examiner is setting up a new lab. Which THREE of the following practices are essential for maintaining the integrity of digital evidence?

Trap 1: Perform regular backups of the forensic workstation’s operating…

Regularly backing up the forensic workstation's operating system is a routine administrative safeguard that protects tool availability and configuration, not the integrity of suspect evidence. A backup cannot prevent an examiner from accidentally modifying the original drive during acquisition, nor does it validate the forensic soundness of captured images. It is a resilience best practice, but it has no bearing on whether evidence will be admissible.

Trap 2: Disable write-blocking when imaging drives to improve speed.

Disabling write-blocking to speed up imaging directly risks altering the original suspect drive, as any unintended write can modify filesystem metadata, timestamps, or slack space. The minute such an alteration occurs, the device's pre-image hash will no longer match post-image verification, undermining the entire investigation and potentially rendering the evidence inadmissible. Forensic acquisition must always prioritize evidentiary integrity over throughput.

A
Perform regular backups of the forensic workstation’s operating system.
Why wrong: Regularly backing up the forensic workstation's operating system is a routine administrative safeguard that protects tool availability and configuration, not the integrity of suspect evidence. A backup cannot prevent an examiner from accidentally modifying the original drive during acquisition, nor does it validate the forensic soundness of captured images. It is a resilience best practice, but it has no bearing on whether evidence will be admissible.
B
Disable write-blocking when imaging drives to improve speed.
Why wrong: Disabling write-blocking to speed up imaging directly risks altering the original suspect drive, as any unintended write can modify filesystem metadata, timestamps, or slack space. The minute such an alteration occurs, the device's pre-image hash will no longer match post-image verification, undermining the entire investigation and potentially rendering the evidence inadmissible. Forensic acquisition must always prioritize evidentiary integrity over throughput.
C
Use write-blocking devices when acquiring data from suspect drives.
Write-blocking devices prevent any write commands from reaching a suspect drive by intercepting ATA/SCSI write operations at the hardware level, allowing the examiner to acquire a bit-for-bit image without changing the original medium. Hardware write-blockers are preferred over software-only solutions because they operate below the operating system and cannot be accidentally bypassed by a misconfigured driver or OS write cache. This preserves the original evidence for hash verification and future re-examination.
D
Implement a chain-of-custody procedure for all evidence.
A thorough chain-of-custody procedure documents each time evidence changes hands, recording who accessed it, when, why, and what was done, thereby creating a continuous accountability trail. This written history is essential to proving in court that the evidence is authentic and was not altered between seizure and presentation. Without it, even a correctly acquired image can be excluded simply because the investigative path cannot be reconstructed.
E
Store evidence in a secure, access-controlled environment.
Storing evidence in a secure, access-controlled environment combines physical locks, restricted access lists, biometric authentication, and surveillance logging to ensure that no unauthorized person can tamper with or remove evidence. Such facilities also monitor environmental conditions like temperature and humidity, protecting hardware longevity and data integrity. This control complements chain-of-custody by preventing both deliberate tampering and accidental degradation during storage.

Question 12hardmultiple choice

Refer to the exhibit. The FTK Imager output shows a disk with an NTFS partition. The examiner notes that the $MFT mirror is at cluster 2. What is the logical size of the $MFT mirror in bytes?

Exhibit

Refer to the exhibit.

FTK Imager command output:

Sector size: 512
Total sectors: 625142448
Partition start: 2048
Partition end: 625139712
Partition type: NTFS (07)

Flags: 0x80 (Bootable)

File system: NTFS
Volume label: EVIDENCE_DRIVE
Serial number: 1234-5678

$MFT mirror: cluster 2
$MFT: cluster 0
Clusters per record: 1
Bytes per cluster: 4096

Trap 1: 320 GB

320 GB is the total disk capacity reported by FTK Imager for the entire physical or logical volume, not the size of a filesystem metadata file. The $MFTMirr is a small NTFS system file used to bootstrap the MFT, and it is always allocated based on the cluster size and clusters-per-record setting, never on the total medium capacity. Selecting this value confuses a whole-disk measurement with a file-level allocation and cannot be justified by the output shown.

Trap 2: 512 bytes

512 bytes is the sector size / bytes-per-sector value found in the drive geometry information, not the allocated size of the NTFS $MFTMirr. NTFS allocates space in clusters, which are composed of multiple sectors; on this disk the cluster size is 4096 bytes, so any metadata file such as the MFT mirror is measured in clusters, not in raw sector bytes. Picking 512 bytes ignores the cluster-size calculation that the FTK Imager output explicitly provides.

Trap 3: 8192 bytes

8192 bytes would correspond to two clusters of 4096 bytes each, but the FTK Imager output reveals that clusters per record equals 1, so the MFT mirror allocation is only one cluster, not two. This incorrect value is a distractor for someone who incorrectly assumes the mirror size uses a 2-cluster allocation or misreads the output as showing 2 clusters per record. The actual file attributes clearly show a single 4096-byte cluster, making 8192 bytes unsupported.

A
320 GB
Why wrong: 320 GB is the total disk capacity reported by FTK Imager for the entire physical or logical volume, not the size of a filesystem metadata file. The $MFTMirr is a small NTFS system file used to bootstrap the MFT, and it is always allocated based on the cluster size and clusters-per-record setting, never on the total medium capacity. Selecting this value confuses a whole-disk measurement with a file-level allocation and cannot be justified by the output shown.
B
512 bytes
Why wrong: 512 bytes is the sector size / bytes-per-sector value found in the drive geometry information, not the allocated size of the NTFS $MFTMirr. NTFS allocates space in clusters, which are composed of multiple sectors; on this disk the cluster size is 4096 bytes, so any metadata file such as the MFT mirror is measured in clusters, not in raw sector bytes. Picking 512 bytes ignores the cluster-size calculation that the FTK Imager output explicitly provides.
C
4096 bytes
4096 bytes is correct because the FTK Imager output indicates a cluster size of 4096 bytes and a clusters-per-record value of 1, meaning each MFT record occupies exactly one 4-KiB cluster. The $MFTMirr, being stored as a single record-sized allocation in this configuration, therefore consumes exactly one cluster, or 4096 bytes. This matches the metadata shown and is the only option consistent with the clusters-per-record parameter.
D
8192 bytes
Why wrong: 8192 bytes would correspond to two clusters of 4096 bytes each, but the FTK Imager output reveals that clusters per record equals 1, so the MFT mirror allocation is only one cluster, not two. This incorrect value is a distractor for someone who incorrectly assumes the mirror size uses a 2-cluster allocation or misreads the output as showing 2 clusters per record. The actual file attributes clearly show a single 4096-byte cluster, making 8192 bytes unsupported.

Question 13easymultiple choice

You are a forensic examiner at a corporate security firm. You receive a laptop from the HR department that belonged to a terminated employee. The laptop was used for company business and is suspected of containing unauthorized file-sharing software. The laptop is running Windows 10 with BitLocker drive encryption enabled. Before shutdown, the employee was logged into the system. HR claims the laptop was shut down properly and then handed over within an hour. You are asked to acquire a forensic image of the hard drive for analysis. However, when you boot the laptop, you are prompted for the BitLocker recovery key. HR does not have the key, and the employee refuses to cooperate. The laptop also has a TPM chip. Which of the following is the most appropriate course of action to acquire the data?

Trap 1: Perform a cold boot attack to extract the BitLocker key from memory.

Incorrect: This is a complex and invasive technique that should only be used if normal boot fails.

Trap 2: Boot from a Linux live USB and use tools to bypass BitLocker.

Incorrect: Without the key, Linux cannot decrypt the drive.

Trap 3: Boot the laptop normally and let BitLocker unlock the drive using…

This is incorrect because the system is already prompting for a recovery key, meaning the TPM-based unlock did not work. Booting normally will re-prompt for the recovery key, not automatically unlock.

A
Contact IT to obtain the BitLocker recovery key from Active Directory.
This is the correct first step because corporate BitLocker recovery keys are often backed up to Active Directory. Retrieving it is the most straightforward method to access the drive.
B
Perform a cold boot attack to extract the BitLocker key from memory.
Why wrong: Incorrect: This is a complex and invasive technique that should only be used if normal boot fails.
C
Boot from a Linux live USB and use tools to bypass BitLocker.
Why wrong: Incorrect: Without the key, Linux cannot decrypt the drive.
D
Boot the laptop normally and let BitLocker unlock the drive using the TPM.
Why wrong: This is incorrect because the system is already prompting for a recovery key, meaning the TPM-based unlock did not work. Booting normally will re-prompt for the recovery key, not automatically unlock.

Question 14mediumdrag order

Drag and drop the steps to recover deleted files using Recuva into the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Select location, then select file type, then scan, then recover and…

This order is incorrect because selecting the location before the file type is not standard; normally Recuva asks for file type first to configure the scan appropriately, and changing order could cause confusion or miss relevant files.

Trap 2: Select file type, then scan, then select location, then recover and…

This order is functionally invalid because Recuva requires a defined scan target before any scanning operation can begin; launching a scan without first selecting the drive or folder would either default to a full system-wide deep scan (dramatically increasing scan time) or prompt for a location mid-process, breaking the expected wizard flow. Additionally, moving the location selection after the scan phase means the file-type filter is applied without a filesystem context, so Recuva cannot enumerate candidate files from the specified storage medium, making the scan phase impossible to execute meaningfully. In practice, this sequence would never complete a recovery because the recovered data has no designated source path from which to carve the deleted files.

Trap 3: Select file type, then select location, then recover and save to…

This order is incorrect because saving to the same drive before scanning is impossible (there is nothing to recover yet), and scanning after recovery makes no sense. Also, saving to the same drive risks overwriting the very data you are trying to recover.

A
Select file type, then select location, then scan, then recover and save to a different drive.
This is the correct order because Recuva first narrows down file types, then chooses the drive/location to scan, then performs a scan to find recoverable files, and finally saves recovered files to a different drive to prevent overwriting.
B
Select location, then select file type, then scan, then recover and save to a different drive.
Why wrong: This order is incorrect because selecting the location before the file type is not standard; normally Recuva asks for file type first to configure the scan appropriately, and changing order could cause confusion or miss relevant files.
C
Select file type, then scan, then select location, then recover and save to a different drive.
Why wrong: This order is functionally invalid because Recuva requires a defined scan target before any scanning operation can begin; launching a scan without first selecting the drive or folder would either default to a full system-wide deep scan (dramatically increasing scan time) or prompt for a location mid-process, breaking the expected wizard flow. Additionally, moving the location selection after the scan phase means the file-type filter is applied without a filesystem context, so Recuva cannot enumerate candidate files from the specified storage medium, making the scan phase impossible to execute meaningfully. In practice, this sequence would never complete a recovery because the recovered data has no designated source path from which to carve the deleted files.
D
Select file type, then select location, then recover and save to the same drive, then scan.
Why wrong: This order is incorrect because saving to the same drive before scanning is impossible (there is nothing to recover yet), and scanning after recovery makes no sense. Also, saving to the same drive risks overwriting the very data you are trying to recover.

Question 15mediummatching

Match each Windows Registry hive to its stored information.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

User account passwords and hashes

System configuration and device drivers

Installed software and settings

Security policies and user rights

Per-user settings and preferences

Trap 1: HKCR: Stores information about all user profiles on the system.

HKCR (HKEY_CLASSES_ROOT) does not store user profile information; it is the registry key that holds file association mappings, file extension registrations, and COM/OLE class registrations. It is a merged view of HKLM\Software\Classes and HKCU\Software\Classes, meaning changes made by a user override machine-wide defaults for that user only. User profiles themselves are stored under HKU under subkeys named by each user's SID (or the .DEFAULT subkey), so this option misattributes the profile storage role to HKCR instead of HKU.

Trap 2: HKU: Stores file associations and COM class registration…

HKU (HKEY_USERS) stores all loaded user profiles, with each user identified by a security identifier (SID) subkey containing their per-user settings, environment, desktop, and application data. It does not store file associations or COM class registration information; that function belongs to HKCR, which merges class registrations from HKLM\Software\Classes and HKCU\Software\Classes. Thus, this option incorrectly assigns HKCR's role to HKU, overlooking that HKU is the root container for profile hives, not for extension or COM mappings.

A
HKLM: Stores system-wide configuration for hardware, software, and security policies.
HKLM (HKEY_LOCAL_MACHINE) is the machine-wide registry root that stores configuration for all hardware devices, installed software, system services, and local security policies. Its persistent subkeys SAM, SECURITY, SOFTWARE, and SYSTEM correspond to hive files on disk, while the HARDWARE subkey is volatile and rebuilt at every boot. Because its contents affect every user account on the computer, forensic write access to HKLM requires elevated administrative privileges, and unauthorized modifications here are a strong indicator of system-level compromise.
B
HKCU: Stores per-user settings like desktop preferences and environment variables.
HKCU (HKEY_CURRENT_USER) is the per-user registry root that exposes settings for the currently logged-in user, such as desktop wallpaper, keyboard layout, application preferences, and user-level environment variables. Rather than being a separate on-disk file, HKCU is a mapping into the logged-on user's subkey within HKU, backed by their NTUSER.DAT hive file. It is loaded at logon and unloaded at logoff, meaning forensic analysts must locate and parse the user's NTUSER.DAT to recover the settings that were active when that user was signed in.
C
HKCC: Stores hardware profile information used during system boot.
HKCC (HKEY_CURRENT_CONFIG) stores the current hardware profile's device-specific and display configuration, including screen resolution, monitor positioning, and device assignments that differ between boot configurations. It is not an on-disk hive but a volatile link to HKLM\SYSTEM\CurrentControlSet\Hardware Profiles\Current, which is selected at boot time. Because modern plug-and-play systems typically use a single profile, HKCC appears in registry trees as a shortcut rather than a rich data store, but it can still reveal which hardware profile was active during a particular boot session.
D
HKCR: Stores information about all user profiles on the system.
Why wrong: HKCR (HKEY_CLASSES_ROOT) does not store user profile information; it is the registry key that holds file association mappings, file extension registrations, and COM/OLE class registrations. It is a merged view of HKLM\Software\Classes and HKCU\Software\Classes, meaning changes made by a user override machine-wide defaults for that user only. User profiles themselves are stored under HKU under subkeys named by each user's SID (or the .DEFAULT subkey), so this option misattributes the profile storage role to HKCR instead of HKU.
E
HKU: Stores file associations and COM class registration information.
Why wrong: HKU (HKEY_USERS) stores all loaded user profiles, with each user identified by a security identifier (SID) subkey containing their per-user settings, environment, desktop, and application data. It does not store file associations or COM class registration information; that function belongs to HKCR, which merges class registrations from HKLM\Software\Classes and HKCU\Software\Classes. Thus, this option incorrectly assigns HKCR's role to HKU, overlooking that HKU is the root container for profile hives, not for extension or COM mappings.