Remapped sectors: Data security

ludwig

Distinguished
Mar 31, 2004
9
0
18,510
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Is a defective sector securely erased before it is remapped by the hdd
OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
erasing tool like blancco, kroll ontrack dataeraser etc. still contain
sensitive data in the remapped sectors?

How can I access (read & write) remapped sectors either on scsi and on
(e)ide hdds to check them?

Any contributions are appreciated.

Ludwig
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

In article <336e792b.0406100656.745f83d4@posting.google.com>,
Ludwig <antispam1eastcomp@gmx.de> wrote:
>Is a defective sector securely erased before it is remapped by the hdd
>OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
>erasing tool like blancco, kroll ontrack dataeraser etc. still contain
>sensitive data in the remapped sectors?
>
>How can I access (read & write) remapped sectors either on scsi and on
>(e)ide hdds to check them?
>
>Any contributions are appreciated.
>
>Ludwig


I've seen a discussion of computer forensics were this is discussed.
It seems that at the very least you need special drivers, and I'm not
sure it's possible to read remapped sectors on all disk models. It's
easier on the sever-grade SCSI disks. There may be some linux software
around to try this. (linux is being used in the forensics world.)

If you run an encrypted file system (optional in w2k/XP/Linux) the
blocks could be read but would have to be decrypted to be interesting.





--
Al Dykes
-----------
adykes at p a n i x . c o m
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Ludwig" <antispam1eastcomp@gmx.de> wrote in message
news:336e792b.0406100656.745f83d4@posting.google.com...
> Is a defective sector securely erased before it is remapped by the hdd
> OS?

Assume no.

> Or, to pinpoint it: can a hdd, which is "securely" erased by a
> erasing tool like blancco, kroll ontrack dataeraser etc. still contain
> sensitive data in the remapped sectors?

Yes.

> How can I access (read & write) remapped sectors either on scsi and on
> (e)ide hdds to check them?

Get an 'in' with the HD mfg or have access to national technical resources.

> Any contributions are appreciated.

It's a hole that isn't easily plugged. Generally HDs should be physically
shredded or burned if the data is that sensitive.
 

ludwig

Distinguished
Mar 31, 2004
9
0
18,510
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message news:<_98yc.2150$Di3.1207@bgtnsc05-news.ops.worldnet.att.net>...
> "Ludwig" <antispam1eastcomp@gmx.de> wrote in message
> news:336e792b.0406100656.745f83d4@posting.google.com...
> > Is a defective sector securely erased before it is remapped by the hdd
> > OS?
>
> Assume no.
>
> > Or, to pinpoint it: can a hdd, which is "securely" erased by a
> > erasing tool like blancco, kroll ontrack dataeraser etc. still contain
> > sensitive data in the remapped sectors?
>
> Yes.
>
> > How can I access (read & write) remapped sectors either on scsi and on
> > (e)ide hdds to check them?
>
> Get an 'in' with the HD mfg or have access to national technical resources.

Do the manufacturers' low level formatting tools re-read already
remapped sectors when running again, in other words: could "bad guys"
find out access routines to remapped sectors by disassembling those
tools (wddiag, seatools etc.)?

Ludwig
 

ludwig

Distinguished
Mar 31, 2004
9
0
18,510
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

adykes@panix.com (Al Dykes) wrote in message news:<ca9uaf$902$1@panix3.panix.com>...
> In article <336e792b.0406100656.745f83d4@posting.google.com>,
> Ludwig <antispam1eastcomp@gmx.de> wrote:
> >Is a defective sector securely erased before it is remapped by the hdd
> >OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
> >erasing tool like blancco, kroll ontrack dataeraser etc. still contain
> >sensitive data in the remapped sectors?
> >
> >How can I access (read & write) remapped sectors either on scsi and on
> >(e)ide hdds to check them?
> >
> >Any contributions are appreciated.
> >
> >Ludwig
>
>
> I've seen a discussion of computer forensics were this is discussed.
> It seems that at the very least you need special drivers, and I'm not
> sure it's possible to read remapped sectors on all disk models. It's
> easier on the sever-grade SCSI disks. There may be some linux software
> around to try this. (linux is being used in the forensics world.)

Any links and src?

>
> If you run an encrypted file system (optional in w2k/XP/Linux) the
> blocks could be read but would have to be decrypted to be interesting.

Could be only true, if the encryption algorithm "stretches" over
multiple sectors. If encryption is sector-wise, this wouldn't prevent
decryption 100%

Ludwig
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Al Dykes <adykes@panix.com> wrote:
> In article <336e792b.0406100656.745f83d4@posting.google.com>,
> Ludwig <antispam1eastcomp@gmx.de> wrote:
>>Is a defective sector securely erased before it is remapped by the hdd
>>OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
>>erasing tool like blancco, kroll ontrack dataeraser etc. still contain
>>sensitive data in the remapped sectors?
>>
>>How can I access (read & write) remapped sectors either on scsi and on
>>(e)ide hdds to check them?
>>
>>Any contributions are appreciated.
>>
>>Ludwig


> I've seen a discussion of computer forensics were this is discussed.
> It seems that at the very least you need special drivers, and I'm not
> sure it's possible to read remapped sectors on all disk models.

I am pretty sure it is possible, but it may require vendor-specific
commands that might not be documented anywere public. I would not be
surprised if this is something data-recovery companies do routinely.
However this is definitely not something a generic standard tool
can do.

> It's easier on the sever-grade SCSI disks.

You can find SCSI command information here:

http://www.t10.org/scsi-3.htm

> There may be some linux software
> around to try this. (linux is being used in the forensics world.)

> If you run an encrypted file system (optional in w2k/XP/Linux) the
> blocks could be read but would have to be decrypted to be interesting.

That depends. With the usual cipher modes, you can read up to the last
ciper block before the defect (if yo have the key). From the defect on
you can only decrypt if you know where the defect is, even if you have
the key. Of course a single-bit error will not be a problem for
that. But, e.g. an error with 32 bit uncertainity will add that much
effort to decryption.

In an extreme case, all-or-nothing encryption could be used for
sector encryption. Then you need to guess all defects correctly
to get any infromation from an encrypted disk block. Fowever as
far as I am aware this is not done today, as decrypting e.g. AES
without the key is regarded as infeasible for all practical
purposes.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

In article <2isocdFr8ig6U1@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
>Previously Al Dykes <adykes@panix.com> wrote:
>> In article <336e792b.0406100656.745f83d4@posting.google.com>,
>> Ludwig <antispam1eastcomp@gmx.de> wrote:
>>>Is a defective sector securely erased before it is remapped by the hdd
>>>OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
>>>erasing tool like blancco, kroll ontrack dataeraser etc. still contain
>>>sensitive data in the remapped sectors?
>>>
>>>How can I access (read & write) remapped sectors either on scsi and on
>>>(e)ide hdds to check them?
>>>
>>>Any contributions are appreciated.
>>>
>>>Ludwig
>
>
>> I've seen a discussion of computer forensics were this is discussed.
>> It seems that at the very least you need special drivers, and I'm not
>> sure it's possible to read remapped sectors on all disk models.
>
>I am pretty sure it is possible, but it may require vendor-specific
>commands that might not be documented anywere public. I would not be
>surprised if this is something data-recovery companies do routinely.
>However this is definitely not something a generic standard tool
>can do.

I imagine it may actually require flashing new code to the disk, and
if a mass-market IDE disk doesn't have this cabapility you can't read
the bad blocks. server grade disks have flashable code.

The people that have the capability to do this would not spend the
resources on a fishing expedition; the'd have you already identified
you as a probable bad guy. If this is the case you've got lots of
other things to worry about.

>
>> It's easier on the sever-grade SCSI disks.
>
>You can find SCSI command information here:
>
>http://www.t10.org/scsi-3.htm
>
>> There may be some linux software
>> around to try this. (linux is being used in the forensics world.)
>
>> If you run an encrypted file system (optional in w2k/XP/Linux) the
>> blocks could be read but would have to be decrypted to be interesting.
>
>That depends. With the usual cipher modes, you can read up to the last
>ciper block before the defect (if yo have the key). From the defect on
>you can only decrypt if you know where the defect is, even if you have
>the key. Of course a single-bit error will not be a problem for
>that. But, e.g. an error with 32 bit uncertainity will add that much
>effort to decryption.
>
>In an extreme case, all-or-nothing encryption could be used for
>sector encryption. Then you need to guess all defects correctly
>to get any infromation from an encrypted disk block. Fowever as
>far as I am aware this is not done today, as decrypting e.g. AES
>without the key is regarded as infeasible for all practical
>purposes.
>
>Arno
>--
>For email address: lastname AT tik DOT ee DOT ethz DOT ch
>GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
> "The more corrupt the state, the more numerous the laws" - Tacitus
>
>


--
Al Dykes
-----------
adykes at p a n i x . c o m
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Al Dykes <adykes@panix.com> wrote:
> In article <2isocdFr8ig6U1@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
>>Previously Al Dykes <adykes@panix.com> wrote:
>>> In article <336e792b.0406100656.745f83d4@posting.google.com>,
>>> Ludwig <antispam1eastcomp@gmx.de> wrote:
>>>>Is a defective sector securely erased before it is remapped by the hdd
>>>>OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
>>>>erasing tool like blancco, kroll ontrack dataeraser etc. still contain
>>>>sensitive data in the remapped sectors?
>>>>
>>>>How can I access (read & write) remapped sectors either on scsi and on
>>>>(e)ide hdds to check them?
>>>>
>>>>Any contributions are appreciated.
>>>>
>>>>Ludwig
>>
>>
>>> I've seen a discussion of computer forensics were this is discussed.
>>> It seems that at the very least you need special drivers, and I'm not
>>> sure it's possible to read remapped sectors on all disk models.
>>
>>I am pretty sure it is possible, but it may require vendor-specific
>>commands that might not be documented anywere public. I would not be
>>surprised if this is something data-recovery companies do routinely.
>>However this is definitely not something a generic standard tool
>>can do.

> I imagine it may actually require flashing new code to the disk, and
> if a mass-market IDE disk doesn't have this cabapility you can't read
> the bad blocks. server grade disks have flashable code.

I thought today the HDD firmware is actually stored on disk and loaded
on start-up?

> The people that have the capability to do this would not spend the
> resources on a fishing expedition; the'd have you already identified
> you as a probable bad guy. If this is the case you've got lots of
> other things to worry about.

Exactly. Like keyboard sniffers TEMPEST attacks, break-ins to
clone/steal the disk, bribes, etc.. In addition, even when secret
information is on a disk, most/almost all individual 512 byte
blocks will still be pretty uninteresting or completely meaningless,
which reduces the possible return-on-investment of this attack
massively, even when only HDDs are targetted that were used for
sensitive infromation.

As a result, most practical applications need not care about
reallocated defective sectors. But still people should be aware
of the mechanism and its implications. In the rare case where
it could be a problem, conventional erasure should be followed
by physical destruction.

As a further remark, encrypted disks do protect against
problems from reallocated defective sectors, but their
primary use is the protection against HDD theft.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Ludwig <antispam1eastcomp@gmx.de> wrote:
> "Ron Reaugh" <ron-reaugh@worldnet.att.net> wrote in message news:<_98yc.2150$Di3.1207@bgtnsc05-news.ops.worldnet.att.net>...
>> "Ludwig" <antispam1eastcomp@gmx.de> wrote in message
>> news:336e792b.0406100656.745f83d4@posting.google.com...
>> > Is a defective sector securely erased before it is remapped by the hdd
>> > OS?
>>
>> Assume no.
>>
>> > Or, to pinpoint it: can a hdd, which is "securely" erased by a
>> > erasing tool like blancco, kroll ontrack dataeraser etc. still contain
>> > sensitive data in the remapped sectors?
>>
>> Yes.
>>
>> > How can I access (read & write) remapped sectors either on scsi and on
>> > (e)ide hdds to check them?
>>
>> Get an 'in' with the HD mfg or have access to national technical resources.

> Do the manufacturers' low level formatting tools re-read already
> remapped sectors when running again, in other words: could "bad guys"
> find out access routines to remapped sectors by disassembling those
> tools (wddiag, seatools etc.)?

I doubt it. The tools from Seagate and Maxtor I used in the
recent past just execute a short or long SMART self-test.
The actual test is done by the HDD firmware and not the tool.

In addition, re-certifying defective sectors in a HDD is a bad idea,
since the original problem will likely not have gone away. It is
different for optical storage with defect management (e.g. MOD,
DVD-RAM, Mt.Rainier): There a lot of defects are just temporary
failures, e.g. from dust. But for this reason SCSI (and thereby
ATAPI, since it uses the SCSI command set) has a seperate class
of commands for optical storage, which includes surface
recertification.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
 

ludwig

Distinguished
Mar 31, 2004
9
0
18,510
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Arno Wagner <me@privacy.net> wrote in message news:<2itvkpFqku45U1@uni-berlin.de>...
> Previously Al Dykes <adykes@panix.com> wrote:
> > In article <2isocdFr8ig6U1@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
> >>Previously Al Dykes <adykes@panix.com> wrote:
> >>> In article <336e792b.0406100656.745f83d4@posting.google.com>,
> >>> Ludwig <antispam1eastcomp@gmx.de> wrote:
> >>>>Is a defective sector securely erased before it is remapped by the hdd
> >>>>OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
> >>>>erasing tool like blancco, kroll ontrack dataeraser etc. still contain
> >>>>sensitive data in the remapped sectors?
> >>>>
> >>>>How can I access (read & write) remapped sectors either on scsi and on
> >>>>(e)ide hdds to check them?
>
> > The people that have the capability to do this would not spend the
> > resources on a fishing expedition; the'd have you already identified
> > you as a probable bad guy. If this is the case you've got lots of
> > other things to worry about.
>
> Exactly. Like keyboard sniffers TEMPEST attacks, break-ins to
> clone/steal the disk, bribes, etc.. In addition, even when secret
> information is on a disk, most/almost all individual 512 byte
> blocks will still be pretty uninteresting or completely meaningless,

I disagree. Obviously those sectors which are heavily used have a
higher probability to get bad. Such sectors usually do not contain
static data (like program code, static media files etc.) but data
generated from user input, from intermediary data. So, these are
sectors which contain "valuable" information with a much higher
probability than all other (static) sectors on a hdd.

>
> As a result, most practical applications need not care about
> reallocated defective sectors. But still people should be aware
> of the mechanism and its implications. In the rare case where
> it could be a problem, conventional erasure should be followed
> by physical destruction.

In our daily practice as a refurbishing and remarketing company of
used pcs we are regularily confronted with our clients (those
companies, which wants to remarket their used equipment) concerns,
that ALL data on the hdds will be deleted. If there is no guarantee,
that ALL data will be securely erased, then the hdd would be
physically destroyed for security reasons. These would have massive
environmental and economical impacts, because a pc without a hdd has
almost no value and has to be physically recycled instead on being
used by other (mostly poor) people (more and more in developping
countries like Africa etc). The commercial second hand pc market could
rather break down.

To clarify the problem of remapped sectors we contacted as the
IASG/CESG as different manufacturers of CESG certified "secure"
erasing software tools. From the first we got no senseful answer, from
the others we didn't get any answer. So, we rather doubt, that
remapped sectors are erased by commercial tools.

What could be the solution?

Ludwig


>
> As a further remark, encrypted disks do protect against
> problems from reallocated defective sectors, but their
> primary use is the protection against HDD theft.
>
> Arno
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

In article <336e792b.0406120004.5e63404@posting.google.com>,
Ludwig <antispam1eastcomp@gmx.de> wrote:
>Arno Wagner <me@privacy.net> wrote in message news:<2itvkpFqku45U1@uni-berlin.de>...
>> Previously Al Dykes <adykes@panix.com> wrote:
>> > In article <2isocdFr8ig6U1@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
>> >>Previously Al Dykes <adykes@panix.com> wrote:
>> >>> In article <336e792b.0406100656.745f83d4@posting.google.com>,
>> >>> Ludwig <antispam1eastcomp@gmx.de> wrote:
>> >>>>Is a defective sector securely erased before it is remapped by the hdd
>> >>>>OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
>> >>>>erasing tool like blancco, kroll ontrack dataeraser etc. still contain
>> >>>>sensitive data in the remapped sectors?
>> >>>>
>> >>>>How can I access (read & write) remapped sectors either on scsi and on
>> >>>>(e)ide hdds to check them?
>>
>> > The people that have the capability to do this would not spend the
>> > resources on a fishing expedition; the'd have you already identified
>> > you as a probable bad guy. If this is the case you've got lots of
>> > other things to worry about.
>>
>> Exactly. Like keyboard sniffers TEMPEST attacks, break-ins to
>> clone/steal the disk, bribes, etc.. In addition, even when secret
>> information is on a disk, most/almost all individual 512 byte
>> blocks will still be pretty uninteresting or completely meaningless,
>
>I disagree. Obviously those sectors which are heavily used have a
>higher probability to get bad. Such sectors usually do not contain
>static data (like program code, static media files etc.) but data
>generated from user input, from intermediary data. So, these are
>sectors which contain "valuable" information with a much higher
>probability than all other (static) sectors on a hdd.
>

An utterly unsupportable generalization. Support this claim. Sectors
go "soft" (require ECC calculation to recover correct data) even it
they were only written one, years ago.

Also, a sector in the badblock has no idea what file it was part of,
before it went "bad". If you do for a read of a block that's been
mapped-out is just 4096 bits with no context, that probably have
failed the ECC calculation, so you can't know that ABCDEF isn't really
ABCDEG when you read it.

>>
>> As a result, most practical applications need not care about
>> reallocated defective sectors. But still people should be aware
>> of the mechanism and its implications. In the rare case where
>> it could be a problem, conventional erasure should be followed
>> by physical destruction.
>
>In our daily practice as a refurbishing and remarketing company of
>used pcs we are regularily confronted with our clients (those
>companies, which wants to remarket their used equipment) concerns,
>that ALL data on the hdds will be deleted. If there is no guarantee,
>that ALL data will be securely erased, then the hdd would be
>physically destroyed for security reasons. These would have massive
>environmental and economical impacts, because a pc without a hdd has
>almost no value and has to be physically recycled instead on being
>used by other (mostly poor) people (more and more in developping
>countries like Africa etc). The commercial second hand pc market could
>rather break down.
>

Perfect security (or any security) doesn't come cheap. You can't have
it both ways. Security generally comes down to a cost/risk decision.
I've been in jobs where we routinely smashed IDE disks from desktop
systems (with a sledge hamer on a concrete floor) because doing
_anything_ else to sanitize the disk cost more that scraping the disk.

Sorry about not being able to donate equipment. If the company
making the donation values their data as much as you do the'll
appreciate that smashing HDDs is a cost of doing business.

>To clarify the problem of remapped sectors we contacted as the
>IASG/CESG as different manufacturers of CESG certified "secure"
>erasing software tools. From the first we got no senseful answer, from
>the others we didn't get any answer. So, we rather doubt, that
>remapped sectors are erased by commercial tools.
>
>What could be the solution?

There may not be one that meets your requirements.


>
>Ludwig
>
>
>>
>> As a further remark, encrypted disks do protect against
>> problems from reallocated defective sectors, but their
>> primary use is the protection against HDD theft.
>>
>> Arno


--
Al Dykes
-----------
adykes at p a n i x . c o m
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Ludwig" <antispam1eastcomp@gmx.de> wrote in message news:336e792b.0406120004.5e63404@posting.google.com
> Arno Wagner <me@privacy.net> wrote in message news:<2itvkpFqku45U1@uni-berlin.de>...
> > Previously Al Dykes <adykes@panix.com> wrote:
> > > In article <2isocdFr8ig6U1@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
> > > > Previously Al Dykes <adykes@panix.com> wrote:
> > > > > In article <336e792b.0406100656.745f83d4@posting.google.com>,
> > > > > Ludwig <antispam1eastcomp@gmx.de> wrote:
> > > > > > Is a defective sector securely erased before it is remapped by the
> > > > > > hdd OS? Or, to pinpoint it: can a hdd, which is "securely" erased by
> > > > > > a erasing tool like blancco, kroll ontrack dataeraser etc. still contain
> > > > > > sensitive data in the remapped sectors?
> > > > > >
> > > > > > How can I access (read & write) remapped sectors either on scsi and on
> > > > > > (e)ide hdds to check them?
> >
> > > The people that have the capability to do this would not spend the
> > > resources on a fishing expedition; the'd have you already identified
> > > you as a probable bad guy. If this is the case you've got lots of
> > > other things to worry about.
> >
> > Exactly. Like keyboard sniffers TEMPEST attacks, break-ins to
> > clone/steal the disk, bribes, etc.. In addition, even when secret
> > information is on a disk, most/almost all individual 512 byte
> > blocks will still be pretty uninteresting or completely meaningless,
>
> I disagree. Obviously those sectors which are heavily used have a
> higher probability to get bad. Such sectors usually do not contain
> static data (like program code, static media files etc.) but data
> generated from user input, from intermediary data.

> So, these are sectors which contain "valuable" information with a
> much higher probability than all other (static) sectors on a hdd.

Yes, but you can't get to them unless you acquire special firmware.
Even when Low Level Formatting may get the sectors back in use
they will be overwritten when doing so.

>
> >
> > As a result, most practical applications need not care about
> > reallocated defective sectors. But still people should be aware
> > of the mechanism and its implications. In the rare case where
> > it could be a problem, conventional erasure should be followed
> > by physical destruction.
>
> In our daily practice as a refurbishing and remarketing company of
> used pcs we are regularily confronted with our clients (those
> companies, which wants to remarket their used equipment) concerns,
> that ALL data on the hdds will be deleted. If there is no guarantee,
> that ALL data will be securely erased, then the hdd would be
> physically destroyed for security reasons. These would have massive
> environmental and economical impacts, because a pc without a hdd has
> almost no value and has to be physically recycled instead on being
> used by other (mostly poor) people (more and more in developping
> countries like Africa etc). The commercial second hand pc market could
> rather break down.
>
> To clarify the problem of remapped sectors we contacted as the
> IASG/CESG as different manufacturers of CESG certified "secure"
> erasing software tools. From the first we got no senseful answer, from
> the others we didn't get any answer. So, we rather doubt, that
> remapped sectors are erased by commercial tools.
>
> What could be the solution?
>
> Ludwig
>
>
> >
> > As a further remark, encrypted disks do protect against
> > problems from reallocated defective sectors, but their
> > primary use is the protection against HDD theft.
> >
> > Arno
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Al Dykes" <adykes@panix.com> wrote in message news:ca9uaf$902$1@panix3.panix.com
> In article <336e792b.0406100656.745f83d4@posting.google.com>,
> Ludwig <antispam1eastcomp@gmx.de> wrote:
> > Is a defective sector securely erased before it is remapped by the hdd
> > OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
> > erasing tool like blancco, kroll ontrack dataeraser etc. still contain
> > sensitive data in the remapped sectors?
> >
> > How can I access (read & write) remapped sectors either on scsi and on
> > (e)ide hdds to check them?
> >
> > Any contributions are appreciated.
> >
> > Ludwig
>
>
> I've seen a discussion of computer forensics were this is discussed.
> It seems that at the very least you need special drivers, and I'm not
> sure it's possible to read remapped sectors on all disk models.

> It's easier on the sever-grade SCSI disks.

Nope.

> There may be some linux software around to try this.

Nope.

> (linux is being used in the forensics world.)
>
> If you run an encrypted file system (optional in w2k/XP/Linux) the
> blocks could be read

Nope.


> but would have to be decrypted to be interesting.
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Al Dykes <adykes@panix.com> wrote:
> In article <336e792b.0406120004.5e63404@posting.google.com>,
> Ludwig <antispam1eastcomp@gmx.de> wrote:
>>Arno Wagner <me@privacy.net> wrote in message news:<2itvkpFqku45U1@uni-berlin.de>...
>>> Previously Al Dykes <adykes@panix.com> wrote:
>>> > In article <2isocdFr8ig6U1@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
[...]
>>> Exactly. Like keyboard sniffers TEMPEST attacks, break-ins to
>>> clone/steal the disk, bribes, etc.. In addition, even when secret
>>> information is on a disk, most/almost all individual 512 byte
>>> blocks will still be pretty uninteresting or completely meaningless,
>>
>>I disagree. Obviously those sectors which are heavily used have a
>>higher probability to get bad. Such sectors usually do not contain
>>static data (like program code, static media files etc.) but data
>>generated from user input, from intermediary data. So, these are
>>sectors which contain "valuable" information with a much higher
>>probability than all other (static) sectors on a hdd.
>>

> An utterly unsupportable generalization. Support this claim. Sectors
> go "soft" (require ECC calculation to recover correct data) even it
> they were only written one, years ago.

> Also, a sector in the badblock has no idea what file it was part of,
> before it went "bad". If you do for a read of a block that's been
> mapped-out is just 4096 bits with no context, that probably have
> failed the ECC calculation, so you can't know that ABCDEF isn't really
> ABCDEG when you read it.

Actuslly HDD have 512 byte sector size and do not care about
filesystem blocks at all. Defect management is therefore done
in 512 byte units, giving even less data in the remapped sector.

>>> As a result, most practical applications need not care about
>>> reallocated defective sectors. But still people should be aware
>>> of the mechanism and its implications. In the rare case where
>>> it could be a problem, conventional erasure should be followed
>>> by physical destruction.
>>
>>In our daily practice as a refurbishing and remarketing company of
>>used pcs we are regularily confronted with our clients (those
>>companies, which wants to remarket their used equipment) concerns,
>>that ALL data on the hdds will be deleted. If there is no guarantee,
>>that ALL data will be securely erased, then the hdd would be
>>physically destroyed for security reasons. These would have massive
>>environmental and economical impacts, because a pc without a hdd has
>>almost no value and has to be physically recycled instead on being
>>used by other (mostly poor) people (more and more in developping
>>countries like Africa etc). The commercial second hand pc market could
>>rather break down.

Well, people have a tendency to make stupid demands if they do not
understand the technology they are talking about. Remapped sectors
are never a security risk in practice. HDDs with contents so sensitive
that remapped sectors could be a problem will not be given away but
be destroyed in-house.

> Perfect security (or any security) doesn't come cheap.

In fact perfect security is unavailable at this time. However
good security is a lot cheaper than marginally better security
and does the job as well in practice.

> You can't have
> it both ways. Security generally comes down to a cost/risk decision.
> I've been in jobs where we routinely smashed IDE disks from desktop
> systems (with a sledge hamer on a concrete floor) because doing
> _anything_ else to sanitize the disk cost more that scraping the disk.

> Sorry about not being able to donate equipment. If the company
> making the donation values their data as much as you do the'll
> appreciate that smashing HDDs is a cost of doing business.

>>To clarify the problem of remapped sectors we contacted as the
>>IASG/CESG as different manufacturers of CESG certified "secure"
>>erasing software tools. From the first we got no senseful answer, from
>>the others we didn't get any answer. So, we rather doubt, that
>>remapped sectors are erased by commercial tools.
>>
>>What could be the solution?

> There may not be one that meets your requirements.

Looks like it.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

In article <2j6t6eFtpa69U2@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
>Previously Al Dykes <adykes@panix.com> wrote:
>> In article <336e792b.0406120004.5e63404@posting.google.com>,
>> Ludwig <antispam1eastcomp@gmx.de> wrote:
>>>Arno Wagner <me@privacy.net> wrote in message news:<2itvkpFqku45U1@uni-berlin.de>...
>>>> Previously Al Dykes <adykes@panix.com> wrote:
>>>> > In article <2isocdFr8ig6U1@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
>[...]
>>>> Exactly. Like keyboard sniffers TEMPEST attacks, break-ins to
>>>> clone/steal the disk, bribes, etc.. In addition, even when secret
>>>> information is on a disk, most/almost all individual 512 byte
>>>> blocks will still be pretty uninteresting or completely meaningless,
>>>
>>>I disagree. Obviously those sectors which are heavily used have a
>>>higher probability to get bad. Such sectors usually do not contain
>>>static data (like program code, static media files etc.) but data
>>>generated from user input, from intermediary data. So, these are
>>>sectors which contain "valuable" information with a much higher
>>>probability than all other (static) sectors on a hdd.
>>>
>
>> An utterly unsupportable generalization. Support this claim. Sectors
>> go "soft" (require ECC calculation to recover correct data) even it
>> they were only written one, years ago.
>
>> Also, a sector in the badblock has no idea what file it was part of,
>> before it went "bad". If you do for a read of a block that's been
>> mapped-out is just 4096 bits with no context, that probably have
>> failed the ECC calculation, so you can't know that ABCDEF isn't really
>> ABCDEG when you read it.
>
>Actuslly HDD have 512 byte sector size and do not care about
>filesystem blocks at all. Defect management is therefore done
>in 512 byte units, giving even less data in the remapped sector.
>

The last time I checked 4096 bits = 512 bytes. :)


>>>> As a result, most practical applications need not care about
>>>> reallocated defective sectors. But still people should be aware
>>>> of the mechanism and its implications. In the rare case where
>>>> it could be a problem, conventional erasure should be followed
>>>> by physical destruction.
>>>
>>>In our daily practice as a refurbishing and remarketing company of
>>>used pcs we are regularily confronted with our clients (those
>>>companies, which wants to remarket their used equipment) concerns,
>>>that ALL data on the hdds will be deleted. If there is no guarantee,
>>>that ALL data will be securely erased, then the hdd would be
>>>physically destroyed for security reasons. These would have massive
>>>environmental and economical impacts, because a pc without a hdd has
>>>almost no value and has to be physically recycled instead on being
>>>used by other (mostly poor) people (more and more in developping
>>>countries like Africa etc). The commercial second hand pc market could
>>>rather break down.
>
>Well, people have a tendency to make stupid demands if they do not
>understand the technology they are talking about. Remapped sectors
>are never a security risk in practice. HDDs with contents so sensitive
>that remapped sectors could be a problem will not be given away but
>be destroyed in-house.
>
>> Perfect security (or any security) doesn't come cheap.
>
>In fact perfect security is unavailable at this time. However
>good security is a lot cheaper than marginally better security
>and does the job as well in practice.
>
>> You can't have
>> it both ways. Security generally comes down to a cost/risk decision.
>> I've been in jobs where we routinely smashed IDE disks from desktop
>> systems (with a sledge hamer on a concrete floor) because doing
>> _anything_ else to sanitize the disk cost more that scraping the disk.
>
>> Sorry about not being able to donate equipment. If the company
>> making the donation values their data as much as you do the'll
>> appreciate that smashing HDDs is a cost of doing business.
>

>>>To clarify the problem of remapped sectors we contacted as the
>>>IASG/CESG as different manufacturers of CESG certified "secure"
>>>erasing software tools. From the first we got no senseful answer, from
>>>the others we didn't get any answer. So, we rather doubt, that
>>>remapped sectors are erased by commercial tools.
>>>
>>>What could be the solution?


The US DoD specs I've seen provide for erasure by multiple passes of a
commercial erasure software package for most types of secure data, but
require destruction for the highest security level. I've always
assumed that the advantage of physical destruction was that your boss,
or the security officer could watch the disk going into the shredder.
It's not as easy to be assured that the software is really working.
It seems that degaussing is obsolete because the magnet would have to
be powerfull enough to pull your belt buckle off, and it would erase
sync data imbedded in the tracks that the electronics need to
function, effectively making it impossible to reformat the disk.

--
Al Dykes
-----------
adykes at p a n i x . c o m
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously Al Dykes <adykes@panix.com> wrote:
> In article <2j6t6eFtpa69U2@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
>>Previously Al Dykes <adykes@panix.com> wrote:
>>> In article <336e792b.0406120004.5e63404@posting.google.com>,
>>> Ludwig <antispam1eastcomp@gmx.de> wrote:
>>>>Arno Wagner <me@privacy.net> wrote in message news:<2itvkpFqku45U1@uni-berlin.de>...
>>>>> Previously Al Dykes <adykes@panix.com> wrote:
[...]

>>> An utterly unsupportable generalization. Support this claim. Sectors
>>> go "soft" (require ECC calculation to recover correct data) even it
>>> they were only written one, years ago.
>>
>>> Also, a sector in the badblock has no idea what file it was part of,
>>> before it went "bad". If you do for a read of a block that's been
>>> mapped-out is just 4096 bits with no context, that probably have
>>> failed the ECC calculation, so you can't know that ABCDEF isn't really
>>> ABCDEG when you read it.
>>
>>Actuslly HDD have 512 byte sector size and do not care about
>>filesystem blocks at all. Defect management is therefore done
>>in 512 byte units, giving even less data in the remapped sector.
>>

> The last time I checked 4096 bits = 512 bytes. :)

Oops, sorry. I was reading too hastily ;-)

[...]

> The US DoD specs I've seen provide for erasure by multiple passes of a
> commercial erasure software package for most types of secure data, but
> require destruction for the highest security level. I've always
> assumed that the advantage of physical destruction was that your boss,
> or the security officer could watch the disk going into the shredder.

Yes, that is a serious advantage. An (external) tech could easily fake
a normal erasure and then make off with the data on the disk. (More
advanced model: "I am now overwriting your disk with random data"
= "I am now encryting the disk, you will not be able to tell
the difference, but I can get all the data...")

Or if erasure is done off-site, people could lie about it, in an
extreme case just to save time.

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

"Arno Wagner" <me@privacy.net> wrote in message news:2j78l2Fub804U1@uni-berlin.de
> Previously Al Dykes <adykes@panix.com> wrote:
> > In article <2j6t6eFtpa69U2@uni-berlin.de>, Arno Wagner <me@privacy.net> wrote:
> > > Previously Al Dykes <adykes@panix.com> wrote:
> > > > In article <336e792b.0406120004.5e63404@posting.google.com>,
> > > > Ludwig <antispam1eastcomp@gmx.de> wrote:
> > > > > Arno Wagner <me@privacy.net> wrote in message news:<2itvkpFqku45U1@uni-berlin.de>...
> > > > > > Previously Al Dykes <adykes@panix.com> wrote:
> [...]
>
> > > > An utterly unsupportable generalization. Support this claim. Sectors
> > > > go "soft" (require ECC calculation to recover correct data) even it
> > > > they were only written one, years ago.
> > >
> > > > Also, a sector in the badblock has no idea what file it was part of,
> > > > before it went "bad". If you do for a read of a block that's been
> > > > mapped-out is just 4096 bits with no context, that probably have
> > > > failed the ECC calculation, so you can't know that ABCDEF isn't really
> > > > ABCDEG when you read it.

Actually, when that happens you don't get to see that data.
And using other means (reading bits) you probably will read more than
4096 bits anyway, having to find out which are data and which are not.
But then, when you are technically able to do that, you'll probably also
know "what's what".

> > >
> > > Actuslly HDD have 512 byte sector size and do not care about
> > > filesystem blocks at all. Defect management is therefore done
> > > in 512 byte units, giving even less data in the remapped sector.
> > >
>
> > The last time I checked 4096 bits = 512 bytes. :)
>
> Oops, sorry. I was reading too hastily ;-)

Nonsense. It's just your eagerness to shoot your mouth off.
Anyone else would reread that sentence more clearly and find that
it actually says something else than it appears to on first glance.
If it says anything at all, that is, as it is very poor english to begin with.

[snip]
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Ludwig wrote:
> Is a defective sector securely erased before it is remapped by the
hdd
> OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
> erasing tool like blancco, kroll ontrack dataeraser etc. still
contain
> sensitive data in the remapped sectors?
>
> How can I access (read & write) remapped sectors either on scsi and
on
> (e)ide hdds to check them?
>
> Any contributions are appreciated.
>
> Ludwig

Hello Ludwig,

Blancco allready has a working solution. Their software also erases
remapped sectors.
http://www.blancco.com

MZ
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously mzjunk@freemail.lt wrote:
> Ludwig wrote:
>> Is a defective sector securely erased before it is remapped by the
> hdd
>> OS? Or, to pinpoint it: can a hdd, which is "securely" erased by a
>> erasing tool like blancco, kroll ontrack dataeraser etc. still
> contain
>> sensitive data in the remapped sectors?
>>
>> How can I access (read & write) remapped sectors either on scsi and
> on
>> (e)ide hdds to check them?
>>
>> Any contributions are appreciated.
>>
>> Ludwig

> Hello Ludwig,

> Blancco allready has a working solution. Their software also erases
> remapped sectors.
> http://www.blancco.com

And how do they claim they do that, since there is no way for the user
to verify their claim?

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus
 
G

Guest

Guest
Archived from groups: comp.sys.ibm.pc.hardware.storage (More info?)

Previously mzilenas@gmail.com wrote:
> people trust them , that's it.

Hey, maybe I should start this type of business too!
No wait, I am to honest. Damn, another opportunity to get rich lost...

Arno
--
For email address: lastname AT tik DOT ee DOT ethz DOT ch
GnuPG: ID:1E25338F FP:0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
"The more corrupt the state, the more numerous the laws" - Tacitus