This message is from the T13 list server.
There is actually a fairly simple solution to this problem. The DCO command is used to disable drive capabilities. If a utility were to use DCO to remove the security capability of the drive then the issue would go away. ------------------------------------------------- Curtis E. Stevens 20511 Lake Forest Drive #C-214D Lake Forest, California 92630 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: [EMAIL PROTECTED] Ambition is a poor excuse for not having enough sense to be lazy. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pat LaVarre Sent: Tuesday, May 17, 2005 7:26 AM To: forum at t13.org Subject: Re: [t13] Back to the main problem. Please read This message is from the T13 list server. Do we have a concise, dispassionate technical nutshell of the causes of the main problem? Can we substitute a nutshell more accurate than the Three bullets: /// 1) ATA since 1997 defines passwords that break write, read, and erase, by design. If the erase password is set, then you have to know or discover it, else you can't start over. 2) ATA lets BIOS choose to disable this feature til next power cycle or pin 1 reset of the ATA drive, by "freezing" out changes. 3) Significantly many BIOS do not disable this feature, for the boot drive and/or other connected drives, in particular the ATA thru SCSI drive population that many BIOS do not even see as connected. /// Are those facts, wholly true, slanderous rumour, or something in between? Can we substitute a better nutshell, rather than tearing into my words line by line? I make that unusual request because I'm guessing we agree, we won't reach closure quickly if we digress into scenarios of who will be hurt most by what kind of attack, or a discussion of how appalling is my deep ignorance of the ATA standard and PC motherboard architecture. Curiously yours, Pat LaVarre
