On 4/26/05, subscribe <subscribe (at) crazytrain (dot) com [email concealed]> wrote:
> > Nick Puetz writes:
> >
> > > Does anyone know of any good tools or methods for discovering if and
> > > ATA hard drive has a device configuration overlay (DCO) area?
>
> Sure, two ATA commands;
>
> READ_NATIVE_MAX_ADDRESS (max sectors accessible)
>
> DEVICE_CONFIGURATION_IDENTIFY (actual # sectors)
>
> These will tell you if the DCO is there. But you'll have to use the
> DCO commands to change it (DEVICE_CONFIGURATION_SET and
> DEVICE_CONFIGURATION_RESET).
>
> Some docs;
> http://www.t13.org/docs2003/e03111r1.pdf
> http://www.t13.org/technical/e01108r0.pdf
> http://www.t13.org/docs2002/d1410r3b.pdf (pg.90-102)
>
> Commercial tool;
> http://www.abcusinc.com/ICS-ImageMASSterSolo2OptionDCO.html
>
> cheers!
>
> farmerdude
>
> http://www.farmerdude.com
> <L I N U X F O R E N S I C S>
>

Can someone educate me on the issue and/or confirm the below:

The DCO itself is a 512 byte device configuration overly.

The contents of the DCO control the behavior of the drive and
specifically one of the DCO fields controls the max_sectors for the
drive and can be used to artificially restrict access to the full
drive. If present an HPA area is placed on the drive after the DCO is
configured, so a drive may have 3 kinds of storage that are laid out
one after another on the drive: Normal, HPA protected, DCO protected.

Is the question how to determine that a disk drive has an artificially
smaller size based on the content of the DCO. And if present, how to
image the sectors based on the artificial DCO limit?

If the issue is just insuring the image includes the space hidden by
the DCO configuration then I believe things work similarily to how the
HPA does. At least with my testing both Encase 3.22g from Dos and
Linux 2.6.9 with dd capture the DCO protected space. Unfortunately
neither tell you that a DCO was detected and overcome.

My Linux 2.6.9 testing shows that HPA handling is inconsistent and
Linux does not consistently make available by default the HPA
protected areas. I have not done enough testing to know if this is
also true of DCO protected areas.

Again with my limited tests, I have not found a situation where Encase
3.22g for DOS does not capture both HPA and DCO space.

FYI: Under the Linux 2.6.9 kernel the ATA identify block is available
as /proc/hdx/identify.

I assume it is relatively straight forward to parse that and get the
max size per the DCO and Native, but I'm not sure if the original
max_sectors will be represented there, or if a Linux temporarily
modified version will show up.

Also, is the DCO info itself typically stored in NVRAM, or does it a
use a dedicated sector on the disk? Somehow I doubt it could easily
be used to hold a small amount of critical data, but it might be
possible.

Greg
--
Greg Freemyer
The Norcross Group
Forensics for the 21st Century

-----------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management
and tracking system please see: http://aris.securityfocus.com

[ reply ]