HPA & DCO (Hidden Drive Areas)

The Forensic Focus reference summarizes the two features and their origins: “HPA was introduced with the ATA-4 standard. Its purpose is to create a place at the end of the drive for vendors to store information (recovery, security, registration, etc). DCO was introduced with ATA-6 and was initially intended as a means of limiting the apparent capacity of a drive. DCO space will also appear at the end of the drive and is also not seen by the BIOS. As neither can be seen by the BIOS and both can contain hidden data, the way to access this data is via Direct ATA access instead of BIOS access.”¹

The reported-capacity manipulation principle

Both HPA and DCO work by manipulating the drive’s reported capacity rather than by physical separation or encryption. The conceptual approach:

• The native maximum LBA: the drive’s true physical capacity, set at manufacturing.
• The reported maximum LBA: what IDENTIFY DEVICE returns to host queries.
• The hiding mechanism: SET MAX ADDRESS (HPA) or DEVICE_CONFIGURATION_SET (DCO) reduces the reported value.
• The result: sectors above the reduced value remain physically present but invisible to standard host commands.
• The retrieval: READ NATIVE MAX ADDRESS (HPA) or DEVICE_CONFIGURATION_IDENTIFY (DCO) still returns the true value, allowing aware software to access the hidden region.

Three hiding-related ATA features

The Atola Insight Forensic reference identifies three related features: “HPA (host protected area), DCO (device configuration overlay), and AMA (accessible max address) features were created by hard drive manufacturers as hidden areas reserved for storing vendor utilities or simply to make a drive appear to have a certain number of sectors (smaller than the actual drive capacity).”² The three features:

• HPA: reversible, configurable per power cycle, ATA-4 (1998).
• DCO: permanent until DEVICE_CONFIGURATION_RESET, ATA-6 (2002).
• AMA (Accessible Max Address): related capacity-limiting feature; sometimes mentioned in forensic contexts.

Common legitimate uses

HPA and DCO have several legitimate manufacturer and OEM applications:

• OEM recovery partitions: Dell MediaDirect, IBM/Lenovo ThinkPad system restore software, LG notebook recovery utilities, HP recovery images.
• BIOS/UEFI utilities: Phoenix FirstBIOS uses HPA via Boot Engineering Extension Record (BEER) and Protected Area Run Time Interface Extension Services (PARTIES).
• Diagnostic tools: drive vendor diagnostic and firmware update utilities stored in HPA.
• Theft recovery services: some monitoring services historically used HPA for persistence (LoJack for Laptops generation).
• SSD over-provisioning: setting an HPA increases the SSD’s spare area for wear leveling.
• Capacity standardization: DCO allows OEMs to ship “60GB” laptops using either 60GB or 80GB drives, normalizing the apparent capacity.
• Console compatibility: the PS3 2TB workaround uses HPA to make a 2TB drive report as ~1.7TB so the console accepts it.

Common illegitimate uses

The same hiding mechanism can be used for less legitimate purposes:

• Data concealment: hiding files from forensic investigators by storing them in HPA/DCO.
• Rootkit persistence: historical malware stored components in HPA to survive OS reinstallation.
• License circumvention: hiding activation tokens or registration data.
• Counterfeit drives: using DCO to make a smaller drive appear larger (rare but documented).
• Refurbishment fraud: hiding bad sectors via DCO rather than properly remapping them.

Modern relevance

HPA and DCO are less common on modern storage but still present:

• SATA HDDs: still routinely include HPA/DCO support per ATA spec compliance.
• SATA SSDs: may support HPA but increasingly rely on internal over-provisioning instead.
• NVMe SSDs: use NVMe-specific namespaces and over-provisioning rather than HPA/DCO.
• USB drives via SATA bridges: may not support HPA/DCO depending on the bridge controller.
• Modern OEMs: increasingly use UEFI partition flags rather than HPA for recovery image storage.

HPA’s mechanics are well-defined in the ATA-4 specification and have remained stable across subsequent revisions. Understanding the command sequence clarifies both legitimate use and forensic detection.

The three ATA commands

The HandWiki Host Protected Area reference describes the command interaction precisely: “IDENTIFY DEVICE returns the true size of the hard drive. SET MAX ADDRESS reduces the reported size of the hard drive. READ NATIVE MAX ADDRESS returns the true size of the hard drive. An HPA has been created. IDENTIFY DEVICE returns the now fake size of the hard drive. READ NATIVE MAX ADDRESS returns the true size of the hard drive, the HPA is in existence.”³ The command code is 0xF8 with subcommand selectors for the variants.

HPA-aware vs HPA-unaware software

The Wikipedia HPA reference describes the software classification: “The HPA is useful only if other software or firmware (e.g. BIOS or UEFI) is able to use it. Software and firmware that are able to use the HPA are referred to as ‘HPA aware’. The ATA command that these entities use is called READ NATIVE MAX ADDRESS. This command accesses a register that contains the true size of the hard drive.”⁴ Practical implications:

• HPA-unaware OS sees only the reduced capacity; cannot read or write to hidden sectors.
• HPA-aware BIOS/utilities can temporarily expose hidden sectors during boot operations.
• Most file system tools, partition managers, and standard imaging tools are HPA-unaware by default.
• Forensic acquisition tools must explicitly query READ NATIVE MAX ADDRESS to detect HPA presence.

The hdparm -N command

The standard Linux tool for HPA detection and manipulation is hdparm. The Linux man page for hdparm describes the -N option: “Get/set max visible number of sectors, also known as the Host Protected Area setting. Without a parameter, -N displays the current setting, which is reported as two values: the first gives the current max sectors setting, and the second shows the native (real) hardware limit for the disk. The difference between these two values indicates how many sectors of the disk are currently hidden from the operating system, in the form of a Host Protected Area (HPA).”⁵ The command output format:

• hdparm -N /dev/sdX: displays current and native sector counts.
• Output format: “max sectors = X/Y” where X is current visible, Y is native maximum.
• HPA size: the difference (Y – X) gives the number of hidden sectors.
• “HPA is enabled” message: appears when current and native values differ.
• “HPA is disabled”: values are equal; no HPA is set.

Setting and removing HPA

HPA configuration uses the -N flag with a sector count parameter:

• Set HPA temporarily (until next power cycle): hdparm -N SECTORS /dev/sdX
• Set HPA permanently: hdparm -Np SECTORS /dev/sdX --yes-i-know-what-i-am-doing
• Remove HPA: hdparm -N pNATIVE_SECTORS /dev/sdX with the native sector count.
• Linux dmesg detection: kernel logs show “Host Protected Area detected. current capacity is X sectors, native capacity is Y sectors” when an HPA is present.

The “frozen” HPA state

The HandWiki reference notes a complicating factor: “Note that the HPA feature can be hidden by DCO commands (documentation states only if the HPA is not in use), and can be ‘frozen’ (until next power-down of the hard disk) or be password protected.” This affects forensic and sanitization workflows:

• Many BIOSes issue SECURITY FREEZE LOCK at boot, preventing HPA modification.
• Frozen state persists until power cycle.
• Workaround: hot-swap the drive or use a Linux LiveCD that doesn’t issue SECURITY FREEZE.
• Some BIOSes provide a setting to disable the freeze.

Detection on different platforms

Several platforms provide HPA detection mechanisms:

Platform	Method	Limitation
Linux	dmesg (boot log), hdparm -N, Sleuth Kit disk_stat	Requires kernel 2.6.x+ for HPA support
Windows	ATATool, third-party utilities	Native Windows tools cannot detect HPA
macOS	Disk Utility doesn’t expose HPA; requires command-line tools	Limited Mac-native support
DOS/UEFI shell	HDAT2, HDDerase, vendor utilities	Direct ATA access; bypasses OS abstractions
Forensic hardware	Tableau TD1, Atola Insight Forensic, Atola TaskForce 2	Specialized equipment only

SSD over-provisioning use case

The Thomas-Krenn HPA over-provisioning guide describes a modern legitimate use: increasing SSD wear-leveling area by setting an HPA. The mechanism: reserving a portion of the drive as HPA prevents the OS from using those cells; the SSD controller can then use them as additional spare area for wear leveling and garbage collection, potentially extending drive lifespan and improving sustained write performance. The trade-off is reduced usable capacity; typical settings reserve 10-25% of the drive.

DCO is the more powerful and more permanent of the two features, with capabilities that extend beyond simple capacity hiding.

The DCO command set

The Wikipedia DCO reference describes the command interaction: “To determine the actual size and features of a disk, the DEVICE_CONFIGURATION_IDENTIFY command is used, and the output of this command can be compared to the output of IDENTIFY_DEVICE to see if a DCO is present on a given hard drive. Most major tools will remove the DCO in order to fully image a hard drive, using the DEVICE_CONFIGURATION_RESET command. This permanently alters the disk, unlike with the host protected area (HPA), which can be temporarily removed for a power cycle.”⁶ The four DCO commands:

• DEVICE_CONFIGURATION_IDENTIFY: queries the true device capabilities and capacity.
• DEVICE_CONFIGURATION_SET: applies DCO restrictions to hide capacity or features.
• DEVICE_CONFIGURATION_FREEZE_LOCK: prevents further DCO changes until power cycle.
• DEVICE_CONFIGURATION_RESET: permanently restores factory configuration.

DCO can hide more than HPA

The Forensics.wiki reference notes a key DCO capability: “Device Configuration Overlay (DCO) and Host Protected Area (HPA). DCO Revision: 0x0001 The following features can be selectively disabled via DCO: Transfer modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 udma6, Real max sectors: 1465149168, ATA command/feature sets: SMART self_test error_log security HPA 48_bit, SATA command/feature sets: NCQ SSP.”⁷ DCO can hide:

• Drive capacity: sectors above the configured limit.
• UDMA/MDMA transfer modes: forcing slower transfer rates.
• SMART feature set: hiding self-monitoring capabilities.
• Security feature set: hiding ATA Security and password capability.
• HPA feature set itself: double-layer hiding scenario.
• 48-bit addressing: limiting capacity to 28-bit LBA range.
• NCQ (Native Command Queuing): hiding SATA performance features.
• AAM (Automatic Acoustic Management): noise reduction features.

The “DCO hides HPA” scenario

One of the most forensically significant DCO capabilities is the ability to hide the HPA feature itself. When DCO disables the HPA feature set:

• The IDENTIFY DEVICE response indicates HPA is not supported.
• READ NATIVE MAX ADDRESS may return the DCO-limited value, not the true native value.
• HPA-aware tools may not detect that an HPA exists beneath the DCO.
• Resetting only HPA (without first resetting DCO) may not expose all hidden sectors.
• The proper forensic procedure requires DCO reset first, then HPA reset, then full capacity verification.

The hdparm DCO commands

Linux hdparm provides DCO manipulation through specific options:

• hdparm --dco-identify /dev/sdX: queries DCO and lists features that can be disabled.
• hdparm --dco-restore /dev/sdX: permanently resets DCO to factory state.
• Safety flags: hdparm requires –yes-i-know-what-i-am-doing for DCO operations.
• Warning text: “Use of –dco-restore is VERY DANGEROUS. You are trying to deliberately reset your drive configuration back to the factory defaults. This may change the apparent capacity and feature set of the drive, making all data on it inaccessible. You could lose everything.”

DCO reset is permanent

A crucial distinction from HPA: DCO_RESET cannot be undone. Once a drive’s DCO has been reset to factory configuration:

• The DCO settings cannot be re-applied to the same drive without re-issuing DEVICE_CONFIGURATION_SET commands.
• OEM-specific configurations are typically lost (transfer mode restrictions, capacity caps).
• Hidden recovery partitions may become visible (potentially breaking OEM recovery procedures).
• The drive returns to its full native capacity and feature set.
• Some drives may not function properly with vendor utilities expecting the original DCO configuration.

DCO detection comparison

Feature	HPA	DCO
Standard introduced	ATA-4 (1998)	ATA-6 (2002)
Detection command	READ NATIVE MAX ADDRESS	DEVICE_CONFIGURATION_IDENTIFY
Reversibility	Reversible (per power cycle)	Permanent (RESET only)
What can be hidden	Only sectors at end of drive	Sectors + features (UDMA, AAM, HPA, 48-bit)
Linux tool	hdparm -N	hdparm –dco-identify, –dco-restore
BIOS visibility	Hidden from BIOS	Hidden from BIOS
Frozen state	SECURITY FREEZE LOCK	DEVICE_CONFIGURATION_FREEZE_LOCK

HPA and DCO present specific challenges for both forensic acquisition and proper sanitization. Understanding the implications is essential for compliance contexts and complete data handling.

The forensic acquisition problem

The Atola TaskForce reference summarizes the fundamental forensic concern: “For digital forensics specialists, it means that without the ability to identify such hidden areas of a drive and image the full physical image including data in these areas, the evidence they get may be incomplete and lead to inaccurate investigative conclusions.” Specific risks:

• Drive image excludes HPA contents; subsequent analysis misses evidence.
• Chain of custody integrity questioned if HPA presence wasn’t documented.
• Defense attorneys may argue that incomplete acquisition violates evidentiary standards.
• Re-acquisition may be impossible if the drive has been modified or returned.

The 2008 NIJ FTK Imager validation

A specific historical example illustrates the problem. The Wikipedia DCO reference describes the National Institute of Justice (NIJ) findings: “AccessData’s FTK Imager 2.5.3.14 was validated by the National Institute of Justice (NIJ) in June 2008. Their findings indicated that ‘If a physical acquisition is made of a drive with hidden sectors in either a Host Protected Area or a Device Configuration Overlay, the tool does not remove either an HPA or a DCO. The tool did not acquire sectors hidden by an HPA.’ A variety of hardware imaging tools have been found to successfully detect and remove DCOs.”⁸ The lesson: even well-known commercial forensic tools may fail to capture HPA/DCO contents; tool validation is essential.

Forensic tools that handle HPA/DCO

Several forensic tools are documented to handle HPA/DCO correctly:

• OSForensics: “OSForensics will first attempt to detect and display the size of the HPA/DCO hidden areas. If successfully found, they can be removed.”
• Atola Insight Forensic: commercial forensic imager with explicit HPA/DCO unclip features.
• Atola TaskForce 2: hardware-based forensic acquisition with HPA/DCO/AMA handling.
• Tableau TD1: hardware imager that can remove both HPA and DCO.
• TAFT (The ATA Forensics Tool): claims ability to view and change HPA/DCO settings.
• SAFE-Block: claims temporary HPA removal with restoration capability.
• HDD Capacity Restore: free utility for DCO removal.
• EnCase v4.18a (DOS mode): can detect HPA but not DCO; Windows mode is HPA-unaware.
• Sleuth Kit disk_stat: Linux open-source HPA detection.

The Sanitization prerequisite

NIST SP 800-88 (Guidelines for Media Sanitization) explicitly addresses HPA/DCO. The BitRaser NIST 800-88 reference notes the requirement: “Reset the storage device’s configuration capabilities: Storage device configurations such as Host Protected Area (HPA), Device Configuration Overlay (DCO), or Accessible Mac Address may hinder the ability to access the entire address space.”⁹ The required sequence for NIST Purge:

1. Detect HPA presence via READ NATIVE MAX ADDRESS comparison with IDENTIFY DEVICE.
2. Detect DCO presence via DEVICE_CONFIGURATION_IDENTIFY comparison with IDENTIFY DEVICE.
3. If DCO is present, reset it first (DEVICE_CONFIGURATION_RESET / hdparm –dco-restore).
4. If HPA is present, reset it (SET MAX ADDRESS to native / hdparm -N to native sector count).
5. Verify the drive now reports its full native capacity.
6. Issue the chosen Secure Erase command (ATA SECURITY ERASE UNIT, NVMe Sanitize, etc.).
7. Verify post-erase that the entire native capacity has been sanitized.
8. Document HPA/DCO presence and reset in the sanitization certificate.

Without HPA/DCO reset, sanitization is incomplete

The consequence of skipping the HPA/DCO reset step:

• ATA Secure Erase only sanitizes user-accessible space; HPA/DCO regions retain their data.
• NIST Clear (overwrite) is even more limited; cannot reach hidden regions at all.
• Compliance certificates issued without HPA/DCO verification are invalid for HIPAA, GDPR, PCI-DSS purposes.
• Drives sold for refurbishment or recycling may retain confidential data in HPA/DCO.
• The NAID AAA Certification standard requires HPA/DCO handling for valid sanitization.

Documentation requirements

For NIST 800-88 compliance, sanitization documentation must address HPA/DCO:

• Record whether HPA was present before sanitization and its size.
• Record whether DCO was present and what features it disabled.
• Document the reset commands used (hdparm -N, hdparm –dco-restore, or equivalent).
• Verify post-reset that the drive reports native capacity.
• Confirm post-erase that the full native capacity reads as expected (zeros, manufacturer pattern, or random for crypto erase).

HPA and DCO regions can contain recoverable data; the hiding mechanism is reported-capacity manipulation, not encryption or physical separation. This makes HPA/DCO recovery scenarios distinct from encrypted-drive recovery.

The “data is still there” property

Unlike encryption, HPA/DCO doesn’t transform the data itself. The hidden sectors contain the same plaintext or encrypted content they had before being hidden. Recovery prospects:

• If the user-visible region is corrupted but HPA contents are intact: data in HPA may be fully recoverable.
• If the file system spans into HPA region (unusual but possible): standard data recovery tools may need HPA exposure first.
• If recovery partition stored in HPA contains user data backups: legitimate recovery scenario.
• If suspected malware persistence in HPA: forensic-style acquisition reveals the hidden content.

Common HPA recovery scenarios

Several specific recovery scenarios involve HPA regions:

• OEM recovery partition access: when the OS partition is corrupted but the OEM recovery image is intact in HPA.
• “Drive smaller than advertised” investigation: determining whether DCO has reduced visible capacity.
• Refurbished drive verification: checking whether a “new” drive has DCO masking refurbished status.
• Console-modified drives: PS3-formatted drives that used HPA to limit capacity.
• Forensic acquisition: ensuring complete drive imaging including any hidden regions.

The “stuck HPA” recovery scenario

A specific failure mode involves drives where the HPA pointer becomes corrupted:

• The drive’s firmware loses track of the proper HPA boundary.
• SET MAX ADDRESS commands may fail or produce inconsistent results.
• The drive may report incorrect capacity values.
• Standard tools may report errors or refuse to operate on the drive.
• Specialized firmware-level recovery tools (PC-3000, Atola Insight) can sometimes restore proper HPA configuration.

Recovery from the wrong-PS3-format scenario

A common consumer scenario: a drive was used in a PlayStation 3 with HPA enabled to limit capacity to PS3-compatible levels. Later, the user wants to use the drive in a PC and finds it reports reduced capacity. Recovery approach:

1. Connect drive to a Linux system via direct SATA (not USB).
2. Run hdparm -N /dev/sdX to confirm HPA presence.
3. Run hdparm -N pNATIVE_SECTORS /dev/sdX --yes-i-know-what-i-am-doing to remove HPA.
4. Verify full capacity is now visible.
5. Reformat or partition as needed for new use.

Detecting hidden data in HPA

For forensic or recovery purposes, accessing HPA contents requires specific steps:

1. Connect drive directly to SATA controller (USB bridges typically don’t support HPA commands).
2. Use a forensic write blocker if evidence integrity is required.
3. Detect HPA: run hdparm -N /dev/sdX or use forensic tools.
4. Image the full drive: use dd or forensic imager that captures via direct ATA after exposing HPA.
5. Analyze the imaged HPA region: file carving, signature analysis, or string searching.
6. Optionally restore HPA after acquisition to preserve original drive state.

When HPA/DCO recovery is impossible

Specific scenarios where data in HPA/DCO cannot be recovered:

• The drive is connected via USB/FireWire bridge that doesn’t pass ATA commands.
• The drive is on a hardware RAID controller that abstracts ATA features.
• The drive’s firmware is corrupted preventing READ NATIVE MAX ADDRESS responses.
• DCO has been reset, irreversibly destroying any DCO-specific configuration data (though sectors persist).
• NIST Purge sanitization was performed after HPA/DCO reset, destroying all data in those regions.
• Modern NVMe SSDs that don’t support legacy HPA/DCO mechanisms at all.