My laptop has died and I have taken out the hard drive and connected
it to a USB connector.
Windows recognised the hard drive and it apears in Device Manager but
does not map a drive or apper in the Disk Management wndow.
I then remembered I had set a password for the drive.
Question 1 - Is there any way to enter a HDD passowrd via a USB/IDE
connection
I then put my Hard Drive into another laptop (a HP Compaq NC4010) and
as good as gold the Bios requested the HDDDrive Bay Password.
I entered the password but no go ?
Question 2 - The computer that the Hard Drive comes from uses a US
layout keyboard and the one i am trying to use it in now is a UK
layout. I use a ~ (tilde) in my password which is in a different spot
on these keyboards (although I have tried the various corresponding
key locations) but it continually rejcts my password.
groupware@rocketmail.com wrote:
> Hi,
>
> My laptop has died and I have taken out the hard drive and connected
> it to a USB connector.
>
> Windows recognised the hard drive and it apears in Device Manager but
> does not map a drive or apper in the Disk Management wndow.
>
> I then remembered I had set a password for the drive.
>
> Question 1 - Is there any way to enter a HDD passowrd via a USB/IDE
> connection
>
> I then put my Hard Drive into another laptop (a HP Compaq NC4010) and
> as good as gold the Bios requested the HDDDrive Bay Password.
>
> I entered the password but no go ?
>
> Question 2 - The computer that the Hard Drive comes from uses a US
> layout keyboard and the one i am trying to use it in now is a UK
> layout. I use a ~ (tilde) in my password which is in a different spot
> on these keyboards (although I have tried the various corresponding
> key locations) but it continually rejcts my password.
>
> Could this cause a problem ?
>
> Or is there something else ?
>
> Jason
>
Looks like the second question answers the first one. I do not know the
British keyboard, but for some characters, I believe you must press
Alt-Gr (bottom-right of the keyboard). If the tilde is located at the
bottom right of a key, then, this is what you need to do. Try typing
your password in Word or Wordpad to make sure it gets the way you need
and then try for the hard drive.
<groupware@rocketmail.com> wrote in message
news:1170496986.767710.158150@a34g2000cwb.googlegr oups.com...
> Hi,
>
> My laptop has died and I have taken out the hard drive and connected
> it to a USB connector.
>
> Windows recognised the hard drive and it apears in Device Manager but
> does not map a drive or apper in the Disk Management wndow.
>
> I then remembered I had set a password for the drive.
>
> Question 1 - Is there any way to enter a HDD passowrd via a USB/IDE
> connection
>
> I then put my Hard Drive into another laptop (a HP Compaq NC4010) and
> as good as gold the Bios requested the HDDDrive Bay Password.
>
> I entered the password but no go ?
>
> Question 2 - The computer that the Hard Drive comes from uses a US
> layout keyboard and the one i am trying to use it in now is a UK
> layout. I use a ~ (tilde) in my password which is in a different spot
> on these keyboards (although I have tried the various corresponding
> key locations) but it continually rejcts my password.
You mention the 2nd but failed laptop where you tried using the password
but never bothered to mention the ORIGINAL laptop that was used to hash
your hard drive's contents. The other half of the hash (to decode) was
back in the original laptop. Preventing someone from getting at it,
especially by stealing the drive, is just what that security is for;
i.e., unless the drive is in the original laptop that hashed up the
drive's contents AND you know the password, you will never get at the
decoded contents of the drive. That's why you need to do backups (which
aren't hashed or you specify the password which is a software-based
password that you can use regardless of to where you restore the
password-protected backup).
I you don't have the original laptop to reinsert the hard drive, you'll
have to call the maker of the original laptop to see if they provide a
backdoor password, but I doubt it (although I have seen some lists
floating around of possible backdoor passwords). If you don't have
possession of the original laptop and it is usable, start looking for a
service bureau to do the recovery. Otherwise, you are stuck with
partitioning and formatting the drive to wipe it out, and use the
password, if wanted, for the new laptop that does whole-disk encryption.
Hardware-based security became available starting back with the ATA-3
specification.
I don't think that there is a way to get this to work over a USB connection.
I'm surprised that it didn't work on the Compaq. The keyboard could be
part of the issue, or the Compaq may just handle this "differently" than
your original computer. Or your memory of what the password was might
just be faulty.
groupware@rocketmail.com wrote:
> Hi,
>
> My laptop has died and I have taken out the hard drive and connected
> it to a USB connector.
>
> Windows recognised the hard drive and it apears in Device Manager but
> does not map a drive or apper in the Disk Management wndow.
>
> I then remembered I had set a password for the drive.
>
> Question 1 - Is there any way to enter a HDD passowrd via a USB/IDE
> connection
>
> I then put my Hard Drive into another laptop (a HP Compaq NC4010) and
> as good as gold the Bios requested the HDDDrive Bay Password.
>
> I entered the password but no go ?
>
> Question 2 - The computer that the Hard Drive comes from uses a US
> layout keyboard and the one i am trying to use it in now is a UK
> layout. I use a ~ (tilde) in my password which is in a different spot
> on these keyboards (although I have tried the various corresponding
> key locations) but it continually rejcts my password.
>
> Could this cause a problem ?
>
> Or is there something else ?
>
> Jason
>
Re: "The other half of the hash (to decode) was back in the original
laptop. Preventing someone from getting at it, especially by stealing
the drive, is just what that security is for; i.e., unless the drive is
in the original laptop that hashed up the drive's contents AND you know
the password, you will never get at the decoded contents of the drive."
I don't think that's correct. This isn't windows, this is an IDE
password. The implementation of that is supposed to prevent access, on
ANY computer, without the password. But as far as I know, it is NOT
supposed to tie the drive to the computer ... the correct password
should work on any computer. Otherwise, as has happened here, if the
computer motherboard dies, then the drive is lost, and that is beyond
secure, it is "data endangering". And I don't think that's how it works.
Vanguard wrote:
> <groupware@rocketmail.com> wrote in message
> news:1170496986.767710.158150@a34g2000cwb.googlegr oups.com...
>> Hi,
>>
>> My laptop has died and I have taken out the hard drive and connected
>> it to a USB connector.
>>
>> Windows recognised the hard drive and it apears in Device Manager but
>> does not map a drive or apper in the Disk Management wndow.
>>
>> I then remembered I had set a password for the drive.
>>
>> Question 1 - Is there any way to enter a HDD passowrd via a USB/IDE
>> connection
>>
>> I then put my Hard Drive into another laptop (a HP Compaq NC4010) and
>> as good as gold the Bios requested the HDDDrive Bay Password.
>>
>> I entered the password but no go ?
>>
>> Question 2 - The computer that the Hard Drive comes from uses a US
>> layout keyboard and the one i am trying to use it in now is a UK
>> layout. I use a ~ (tilde) in my password which is in a different spot
>> on these keyboards (although I have tried the various corresponding
>> key locations) but it continually rejcts my password.
>
>
> You mention the 2nd but failed laptop where you tried using the password
> but never bothered to mention the ORIGINAL laptop that was used to hash
> your hard drive's contents. The other half of the hash (to decode) was
> back in the original laptop. Preventing someone from getting at it,
> especially by stealing the drive, is just what that security is for;
> i.e., unless the drive is in the original laptop that hashed up the
> drive's contents AND you know the password, you will never get at the
> decoded contents of the drive. That's why you need to do backups (which
> aren't hashed or you specify the password which is a software-based
> password that you can use regardless of to where you restore the
> password-protected backup).
>
> I you don't have the original laptop to reinsert the hard drive, you'll
> have to call the maker of the original laptop to see if they provide a
> backdoor password, but I doubt it (although I have seen some lists
> floating around of possible backdoor passwords). If you don't have
> possession of the original laptop and it is usable, start looking for a
> service bureau to do the recovery. Otherwise, you are stuck with
> partitioning and formatting the drive to wipe it out, and use the
> password, if wanted, for the new laptop that does whole-disk encryption.
> Hardware-based security became available starting back with the ATA-3
> specification.
>
> http://www.pwcrack.com/bios.shtml
> http://www.rockbox.org/lock.html
> http://www.driverforum.com/harddrive3/1642.html (but sounds very hazardous)
> http://www.eevidencelabs.com/article..._Forensics.pdf
>
> http://www.velocityreviews.com/forum...-password.html
>
>
>
"Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message news:45c4b406$0$9009$4c368faf@roadrunner.com
> Re: "The other half of the hash (to decode) was back in the original
> laptop. Preventing someone from getting at it, especially by stealing
> the drive, is just what that security is for; i.e., unless the drive is
> in the original laptop that hashed up the drive's contents AND you know
> the password, you will never get at the decoded contents of the drive."
> I don't think that's correct.
It isn't. He's obviously one of those rocket scientists.
> This isn't windows, this is an IDE password. The implementation of that
> is supposed to prevent access, on ANY computer, without the password.
> But as far as I know, it is NOT supposed to tie the drive to the computer
> ... the correct password should work on any computer.
> Otherwise, as has happened here, if the computer motherboard dies,
> then the drive is lost, and that is beyond secure, it is "data endangering".
> And I don't think that's how it works.
It doesn't.
>
>
> Vanguard wrote:
> > groupware@rocketmail.com> wrote in message news:1170496986.767710.158150@a34g2000cwb.googlegr oups.com...
> > > Hi,
> > >
> > > My laptop has died and I have taken out the hard drive and connected
> > > it to a USB connector.
> > >
"Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
news:45c4b406$0$9009$4c368faf@roadrunner.com...
> Re: "The other half of the hash (to decode) was back in the original
> laptop. Preventing someone from getting at it, especially by stealing
> the drive, is just what that security is for; i.e., unless the drive
> is in the original laptop that hashed up the drive's contents AND you
> know the password, you will never get at the decoded contents of the
> drive."
>
> I don't think that's correct. This isn't windows,
I don't care what OS is on the drive, encrypted or not. The whole-disk
encryption is performed in hardware. Half of that support is on the
hard drive, the other half is back in the mobo. If the drive wanders
off from the mobo that hashed up the drive, that drive cannot be
decoded. It is very similar to e-mail encryption: the source (owner of
the certificate or the mobo) has the "private" portion and the target
(recipient or hard drive) has the "public" portion. Without both,
there's no decryption, and the source controls that.
> this is an IDE
Yep, as I said, this hardware encryption was first provided in ATA-3
specification. It is NOT solely implemented on the hard drive alone.
Unfortunately it costs to get copies of the ATA specs from http://www.t13.org/ and I really don't need them.
> Otherwise, as has happened here, if the computer motherboard dies,
> then the drive is lost, and that is beyond secure, it is "data
> endangering".
Yep, that is what happens. And that is why you MUST do data backups
since they won't depend on the private key for the encryption that the
mobo has. The backups can either be open in that anyone could restore
from them or you would password-protect them, but that password
protection is entirely within the backup file so you could use another
computer running the same backup program to restore your data because
the password was only used to encode the file (i.e., there is no
separation of private and public keys, there is just the one key used to
encode the file).
Vanguard wrote:
> "Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
> news:45c4b406$0$9009$4c368faf@roadrunner.com...
>> Re: "The other half of the hash (to decode) was back in the original
>> laptop. Preventing someone from getting at it, especially by stealing
>> the drive, is just what that security is for; i.e., unless the drive
>> is in the original laptop that hashed up the drive's contents AND you
>> know the password, you will never get at the decoded contents of the
>> drive."
>>
>> I don't think that's correct. This isn't windows,
>
> I don't care what OS is on the drive, encrypted or not. The whole-disk
> encryption is performed in hardware. Half of that support is on the
> hard drive, the other half is back in the mobo. If the drive wanders
> off from the mobo that hashed up the drive, that drive cannot be
> decoded. It is very similar to e-mail encryption: the source (owner of
> the certificate or the mobo) has the "private" portion and the target
> (recipient or hard drive) has the "public" portion. Without both,
> there's no decryption, and the source controls that.
>
>> this is an IDE
>
> Yep, as I said, this hardware encryption was first provided in ATA-3
> specification. It is NOT solely implemented on the hard drive alone.
> Unfortunately it costs to get copies of the ATA specs from
> http://www.t13.org/ and I really don't need them.
>
>> Otherwise, as has happened here, if the computer motherboard dies,
>> then the drive is lost, and that is beyond secure, it is "data
>> endangering".
>
> Yep, that is what happens. And that is why you MUST do data backups
> since they won't depend on the private key for the encryption that the
> mobo has. The backups can either be open in that anyone could restore
> from them or you would password-protect them, but that password
> protection is entirely within the backup file so you could use another
> computer running the same backup program to restore your data because
> the password was only used to encode the file (i.e., there is no
> separation of private and public keys, there is just the one key used to
> encode the file).
>
I am curious to know what the final word is on that issue. Until reading
your post, I shared Barry's opinion. If you are correct, and you seem to
know your stuff, then I would look twice before passwording a hard-drive.
John Doue <notwobe@yahoo.com> wrote:
> Vanguard wrote:
>> "Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
>> news:45c4b406$0$9009$4c368faf@roadrunner.com...
>>> Re: "The other half of the hash (to decode) was back in the original
>>> laptop. Preventing someone from getting at it, especially by
>>> stealing the drive, is just what that security is for; i.e., unless
>>> the drive is in the original laptop that hashed up the drive's
>>> contents AND you know the password, you will never get at the
>>> decoded contents of the drive."
>>>
>>> I don't think that's correct. This isn't windows,
>>
>> I don't care what OS is on the drive, encrypted or not. The
>> whole-disk encryption is performed in hardware. Half of that
>> support is on the hard drive, the other half is back in the mobo. If the drive wanders off from
>> the mobo that hashed up the drive,
>> that drive cannot be decoded. It is very similar to e-mail
>> encryption: the source (owner of the certificate or the mobo) has
>> the "private" portion and the target (recipient or hard drive) has
>> the "public" portion. Without both, there's no decryption, and the
>> source controls that.
>>> this is an IDE
>>
>> Yep, as I said, this hardware encryption was first provided in ATA-3
>> specification. It is NOT solely implemented on the hard drive alone.
>> Unfortunately it costs to get copies of the ATA specs from
>> http://www.t13.org/ and I really don't need them.
>>
>>> Otherwise, as has happened here, if the computer motherboard dies,
>>> then the drive is lost, and that is beyond secure, it is "data
>>> endangering".
>>
>> Yep, that is what happens. And that is why you MUST do data backups
>> since they won't depend on the private key for the encryption that
>> the mobo has. The backups can either be open in that anyone could
>> restore from them or you would password-protect them, but that
>> password protection is entirely within the backup file so you could
>> use another computer running the same backup program to restore your
>> data because the password was only used to encode the file (i.e.,
>> there is no separation of private and public keys, there is just the
>> one key used to encode the file).
> I am curious to know what the final word is on that issue. Until
> reading your post, I shared Barry's opinion. If you are correct, and
> you seem to know your stuff,
He doesnt, actually. Where the encryption is done is an entirely
separate issue to whether the ATA password can be reentered
for a drive that is moved from one system that supports ATA
passwords to another that also does.
> then I would look twice before passwording a hard-drive.
That should always be done, if only because you
need to be sure that you wont lose the password.
Vanguard wrote:
>
> "Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
> news:45c4b406$0$9009$4c368faf@roadrunner.com...
> > Re: "The other half of the hash (to decode) was back in the original
> > laptop. Preventing someone from getting at it, especially by stealing
> > the drive, is just what that security is for; i.e., unless the drive
> > is in the original laptop that hashed up the drive's contents AND you
> > know the password, you will never get at the decoded contents of the
> > drive."
> >
> > I don't think that's correct. This isn't windows,
>
> I don't care what OS is on the drive, encrypted or not. The whole-disk
> encryption is performed in hardware. Half of that support is on the
> hard drive, the other half is back in the mobo. If the drive wanders
> off from the mobo that hashed up the drive, that drive cannot be
> decoded. It is very similar to e-mail encryption: the source (owner of
> the certificate or the mobo) has the "private" portion and the target
> (recipient or hard drive) has the "public" portion. Without both,
> there's no decryption, and the source controls that.
Vanguard,
All the drive manufacturers have their own method of enforcing password
protection at this level.
Some of them can be overcome quite easily (for instance, a typical
resurrection for Western Digital drives is to enter, as the password,
WDC repetitively for 32 characters) whereas others (most) require
hardware intervention.
We can recover / obliterate passwords for almost all drives - using
specialist equipment - but for the lucky user of a WD-type drive, it's
fairly straightforward.
The password is rarely stored on multiple media - as far as I can tell
with up-to-date information and experience. (i.e. it's never stored as a
combination of platter-based info (system area) and hardware (BIOS / ROM
/ NVRAM.)
Re: "The whole-disk encryption is performed in hardware."
We are not talking about encryption at all. IDE drive passwords are not
encryption. The way that this works is that on startup, the drive will
one and only one command over the IDE port ... the password command.
Until that command is issued, with the correct password, the drive will
simply not respond to ANY other valid IDE commands, including the
"identify drive" command. Thus, until the password command is issued
and the drive activates itself, it's not even seen by the bios. The
system will act as if there is simply no drive installed at all. It has
nothing to do with encryption or keys.
I think that we are talking about two different things.
Vanguard wrote:
> "Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
> news:45c4b406$0$9009$4c368faf@roadrunner.com...
>> Re: "The other half of the hash (to decode) was back in the original
>> laptop. Preventing someone from getting at it, especially by stealing
>> the drive, is just what that security is for; i.e., unless the drive
>> is in the original laptop that hashed up the drive's contents AND you
>> know the password, you will never get at the decoded contents of the
>> drive."
>>
>> I don't think that's correct. This isn't windows,
>
> I don't care what OS is on the drive, encrypted or not. The whole-disk
> encryption is performed in hardware. Half of that support is on the
> hard drive, the other half is back in the mobo. If the drive wanders
> off from the mobo that hashed up the drive, that drive cannot be
> decoded. It is very similar to e-mail encryption: the source (owner of
> the certificate or the mobo) has the "private" portion and the target
> (recipient or hard drive) has the "public" portion. Without both,
> there's no decryption, and the source controls that.
>
>> this is an IDE
>
> Yep, as I said, this hardware encryption was first provided in ATA-3
> specification. It is NOT solely implemented on the hard drive alone.
> Unfortunately it costs to get copies of the ATA specs from
> http://www.t13.org/ and I really don't need them.
>
>> Otherwise, as has happened here, if the computer motherboard dies,
>> then the drive is lost, and that is beyond secure, it is "data
>> endangering".
>
> Yep, that is what happens. And that is why you MUST do data backups
> since they won't depend on the private key for the encryption that the
> mobo has. The backups can either be open in that anyone could restore
> from them or you would password-protect them, but that password
> protection is entirely within the backup file so you could use another
> computer running the same backup program to restore your data because
> the password was only used to encode the file (i.e., there is no
> separation of private and public keys, there is just the one key used to
> encode the file).
>
"Rod Speed" <rod.speed.aaa@gmail.com> wrote in message
news:52kartF1nmg1sU1@mid.individual.net...
> John Doue <notwobe@yahoo.com> wrote:
>> Vanguard wrote:
>>> "Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
>>> news:45c4b406$0$9009$4c368faf@roadrunner.com...
>>>> Re: "The other half of the hash (to decode) was back in the
>>>> original
>>>> laptop. Preventing someone from getting at it, especially by
>>>> stealing the drive, is just what that security is for; i.e., unless
>>>> the drive is in the original laptop that hashed up the drive's
>>>> contents AND you know the password, you will never get at the
>>>> decoded contents of the drive."
>>>>
>>>> I don't think that's correct. This isn't windows,
>>>
>>> I don't care what OS is on the drive, encrypted or not. The
>>> whole-disk encryption is performed in hardware. Half of that
>>> support is on the hard drive, the other half is back in the mobo. If
>>> the drive wanders off from the mobo that hashed up the drive,
>>> that drive cannot be decoded. It is very similar to e-mail
>>> encryption: the source (owner of the certificate or the mobo) has
>>> the "private" portion and the target (recipient or hard drive) has
>>> the "public" portion. Without both, there's no decryption, and the
>>> source controls that.
>>>> this is an IDE
>>>
>>> Yep, as I said, this hardware encryption was first provided in ATA-3
>>> specification. It is NOT solely implemented on the hard drive
>>> alone.
>>> Unfortunately it costs to get copies of the ATA specs from
>>> http://www.t13.org/ and I really don't need them.
>>>
>>>> Otherwise, as has happened here, if the computer motherboard dies,
>>>> then the drive is lost, and that is beyond secure, it is "data
>>>> endangering".
>>>
>>> Yep, that is what happens. And that is why you MUST do data backups
>>> since they won't depend on the private key for the encryption that
>>> the mobo has. The backups can either be open in that anyone could
>>> restore from them or you would password-protect them, but that
>>> password protection is entirely within the backup file so you could
>>> use another computer running the same backup program to restore your
>>> data because the password was only used to encode the file (i.e.,
>>> there is no separation of private and public keys, there is just the
>>> one key used to encode the file).
>
>> I am curious to know what the final word is on that issue. Until
>> reading your post, I shared Barry's opinion. If you are correct, and
>> you seem to know your stuff,
>
> He doesnt, actually. Where the encryption is done is an entirely
> separate issue to whether the ATA password can be reentered
> for a drive that is moved from one system that supports ATA
> passwords to another that also does.
The user password is normally used to unlock the hard drive. The master
password, if one exists, can also be used to unlock the hard drive.
That is why I've seen some backdoor lists floating around of what some
mobo makers have been found to commonly use for a master password. The
master password is also why you can call the maker of your mobo as they
may be able to tell you what is the master password for you to unlock
the drive. Drive locking protection is obviously degraded if such
backdoor [master] passwords are common and maybe that's why
security-conscious users and corporations rely on whole-disk encryption
instead.
Ron is correct in that I was mixing hard drive locking with whole-disk
encryption. These are separate security mechanisms. From the OP's
post, perhaps just disk locking was employed and not encryption. Since
the OP gave absolutely no details on WHAT was the original computer in
which the drive was locked (and maybe encrypted, too), guesses is all
that can be profferred.
Since the OP already tried in another computer that prompted for the
password but it did not work then it sure seems that the BIOS makers can
customize how they support the drive lock feature. That is, just
because there is an ATA standard, it could be rather vague or the BIOS
makers may even deliberately tweak it so to be almost proprietary. As
Odie alluded, drive locking may not be compatible between different
BIOSes.
I'm wondering if a replacement of the PCB on the hard drive might
"repair" or unlock the drive. That is, get another exact same drive and
use its PCB on the problematic drive. Since the replacement PCB hasn't
been password enabled yet, maybe it would permit access to the drive. I
tried this once with an old drive (so getting an exact replacement was
pricey due to rarity) because a voltage regulator component blew which
rendered the drive useless (it wouldn't spin up). The replacement PCB
got the drive to spin up.
It could even be that the translation geometry for LBA mode of the
original computer doesn't match that used in the second computer. Start
at http://www.pcguide.com/ref/hdd/bios/modesLBA-c.html. Then read http://www.pcguide.com/ref/hdd/bios/modesCaveats-c.html about the hazard
(to data) of moving hard drives between computers, especially with
different BIOSes. I have ran into this when moving drives between hosts
really old hardware hosts to new hardware hosts.
In comp.sys.ibm.pc.hardware.storage Odie Ferrous <odie_ferrous@hotmail.com> wrote:
> Vanguard wrote:
>>
>> "Barry Watzman" <WatzmanNOSPAM@neo.rr.com> wrote in message
>> news:45c4b406$0$9009$4c368faf@roadrunner.com...
>> > Re: "The other half of the hash (to decode) was back in the original
>> > laptop. Preventing someone from getting at it, especially by stealing
>> > the drive, is just what that security is for; i.e., unless the drive
>> > is in the original laptop that hashed up the drive's contents AND you
>> > know the password, you will never get at the decoded contents of the
>> > drive."
>> >
>> > I don't think that's correct. This isn't windows,
>>
>> I don't care what OS is on the drive, encrypted or not. The whole-disk
>> encryption is performed in hardware. Half of that support is on the
>> hard drive, the other half is back in the mobo. If the drive wanders
>> off from the mobo that hashed up the drive, that drive cannot be
>> decoded. It is very similar to e-mail encryption: the source (owner of
>> the certificate or the mobo) has the "private" portion and the target
>> (recipient or hard drive) has the "public" portion. Without both,
>> there's no decryption, and the source controls that.
>
> Vanguard,
> All the drive manufacturers have their own method of enforcing password
> protection at this level.
> Some of them can be overcome quite easily (for instance, a typical
> resurrection for Western Digital drives is to enter, as the password,
> WDC repetitively for 32 characters) whereas others (most) require
> hardware intervention.
> We can recover / obliterate passwords for almost all drives - using
> specialist equipment - but for the lucky user of a WD-type drive, it's
> fairly straightforward.
> The password is rarely stored on multiple media - as far as I can tell
> with up-to-date information and experience. (i.e. it's never stored as a
> combination of platter-based info (system area) and hardware (BIOS / ROM
> / NVRAM.)
So basically a HDD password is only protection angainst amateurs and
even they can get it removed for a few thousand EUR/USD?
Hmmm. If this were crypto, it would fall into the ''ridiculous''
security level class...
Vanguard <no@mail.invalid> wrote
> Rod Speed <rod.speed.aaa@gmail.com> wrote
>> John Doue <notwobe@yahoo.com> wrote
>>> Vanguard wrote
>>>> Barry Watzman <WatzmanNOSPAM@neo.rr.com> wrote
>>>>> Re: "The other half of the hash (to decode) was back in the original laptop. Preventing
>>>>> someone from getting at it, especially by stealing the drive, is just what that security is
>>>>> for; i.e., unless the drive is in the original laptop that hashed up the drive's contents AND
>>>>> you know the password, you will never get at the decoded contents of the drive."
>>>>> I don't think that's correct. This isn't windows,
>>>> I don't care what OS is on the drive, encrypted or not. The
>>>> whole-disk encryption is performed in hardware. Half of that
>>>> support is on the hard drive, the other half is back in the mobo.
>>>> If the drive wanders off from the mobo that hashed up the drive,
>>>> that drive cannot be decoded. It is very similar to e-mail
>>>> encryption: the source (owner of the certificate or the mobo) has
>>>> the "private" portion and the target (recipient or hard drive) has
>>>> the "public" portion. Without both, there's no decryption, and the
>>>> source controls that.
>>>>> this is an IDE
>>>> Yep, as I said, this hardware encryption was first provided in ATA-3 specification.
No it wasnt.
>>>> It is NOT solely implemented on the hard drive alone.
There was no hardware encryption on the hard drive with the ATA spec.
>>>> Unfortunately it costs to get copies of the ATA specs from http://www.t13.org/ and I really
>>>> don't need them.
The drafts are readily available for free and that detail didnt change.
>>>>> Otherwise, as has happened here, if the computer motherboard dies,
>>>>> then the drive is lost, and that is beyond secure, it is "data endangering".
>>>> Yep, that is what happens. And that is why you MUST do data
>>>> backups since they won't depend on the private key for the
>>>> encryption that the mobo has. The backups can either be open in
>>>> that anyone could restore from them or you would password-protect
>>>> them, but that password protection is entirely within the backup
>>>> file so you could use another computer running the same backup
>>>> program to restore your data because the password was only used to encode the file (i.e., there
>>>> is no separation of private and
>>>> public keys, there is just the one key used to encode the file).
>>> I am curious to know what the final word is on that issue. Until reading your post, I shared
>>> Barry's opinion. If you are correct, and you seem to know your stuff,
>> He doesnt, actually. Where the encryption is done is an entirely
>> separate issue to whether the ATA password can be reentered
>> for a drive that is moved from one system that supports ATA
>> passwords to another that also does.
> The user password is normally used to unlock the hard drive.
Yep, and it says absolutely NOTHING about any ATA spec encryption.
> The master password, if one exists, can also be used to unlock the hard drive.
Irrelevant to your pig ignorant claims about ENCRYPTION.
> That is why I've seen some backdoor lists floating around of what some mobo makers have been found
> to commonly use for a master password.
Pity the user is welcome to change that and obviously should do so.
> The master password is also why you can call the maker of your mobo as they may be able to tell
> you what is the master password for you to unlock the drive.
Pity that only allows you to ERASE the drive, not access the DATA.
> Drive locking protection is obviously degraded if such backdoor [master] passwords are common
No it doesnt if you actually have a clue and change that master password.
> and maybe that's why security-conscious users and corporations rely on whole-disk encryption
> instead.
Thats for a different reason entirely, because its actually possible to bypass
that password protection when you have physical access to the drive.
> Ron is correct in that I was mixing hard drive locking with whole-disk
> encryption. These are separate security mechanisms. From the OP's
> post, perhaps just disk locking was employed and not encryption.
> Since the OP gave absolutely no details on WHAT was the original computer in which the drive was
> locked (and maybe encrypted, too), guesses is all that can be profferred.
Anyone with a clue has noticed that you mangled the story completely.
> Since the OP already tried in another computer that prompted for the password but it did not work
> then it sure seems that the BIOS makers can customize how they support the drive lock feature.
You dont even know that the OP is entering the password correctly.
> That is, just because there is an ATA standard, it could be rather vague
No it isnt.
> or the BIOS makers may even deliberately tweak it so to be almost proprietary.
No they dont.
> As Odie alluded, drive locking may not be compatible between different BIOSes.
He didnt say anything like that. The ATA standard makes it very clear how it works.
> I'm wondering if a replacement of the PCB on the hard drive might "repair" or unlock the drive.
> That is, get another exact same drive and use its PCB on the problematic drive. Since the
> replacement PCB hasn't been password enabled yet, maybe it would permit access to the drive.
VERY unlikely that it would be that pathetically implemented.
Because that would defeat the whole point of the ATA security feature.
> I tried this once with an old drive (so getting an exact replacement was pricey due to rarity)
> because a voltage regulator component blew which rendered the drive useless (it wouldn't spin up).
> The replacement PCB got the drive to spin up.
Irrelevant to the ATA security feature.
> It could even be that the translation geometry for LBA mode of the
> original computer doesn't match that used in the second computer.
Wrong again. You'd get a different result if that was the problem.
Rod Speed wrote:
> Vanguard <no@mail.invalid> wrote
>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>> John Doue <notwobe@yahoo.com> wrote
>>>> Vanguard wrote
>>>>> Barry Watzman <WatzmanNOSPAM@neo.rr.com> wrote
>
>>>>>> Re: "The other half of the hash (to decode) was back in the original laptop. Preventing
>>>>>> someone from getting at it, especially by stealing the drive, is just what that security is
>>>>>> for; i.e., unless the drive is in the original laptop that hashed up the drive's contents AND
>>>>>> you know the password, you will never get at the decoded contents of the drive."
>
>>>>>> I don't think that's correct. This isn't windows,
>
>>>>> I don't care what OS is on the drive, encrypted or not. The
>>>>> whole-disk encryption is performed in hardware. Half of that
>>>>> support is on the hard drive, the other half is back in the mobo.
>>>>> If the drive wanders off from the mobo that hashed up the drive,
>>>>> that drive cannot be decoded. It is very similar to e-mail
>>>>> encryption: the source (owner of the certificate or the mobo) has
>>>>> the "private" portion and the target (recipient or hard drive) has
>>>>> the "public" portion. Without both, there's no decryption, and the
>>>>> source controls that.
>
>>>>>> this is an IDE
>
>>>>> Yep, as I said, this hardware encryption was first provided in ATA-3 specification.
>
> No it wasnt.
>
>>>>> It is NOT solely implemented on the hard drive alone.
>
> There was no hardware encryption on the hard drive with the ATA spec.
>
>>>>> Unfortunately it costs to get copies of the ATA specs from http://www.t13.org/ and I really
>>>>> don't need them.
>
> The drafts are readily available for free and that detail didnt change.
>
>>>>>> Otherwise, as has happened here, if the computer motherboard dies,
>>>>>> then the drive is lost, and that is beyond secure, it is "data endangering".
>
>>>>> Yep, that is what happens. And that is why you MUST do data
>>>>> backups since they won't depend on the private key for the
>>>>> encryption that the mobo has. The backups can either be open in
>>>>> that anyone could restore from them or you would password-protect
>>>>> them, but that password protection is entirely within the backup
>>>>> file so you could use another computer running the same backup
>>>>> program to restore your data because the password was only used to encode the file (i.e., there
>>>>> is no separation of private and
>>>>> public keys, there is just the one key used to encode the file).
>
>>>> I am curious to know what the final word is on that issue. Until reading your post, I shared
>>>> Barry's opinion. If you are correct, and you seem to know your stuff,
>
>>> He doesnt, actually. Where the encryption is done is an entirely
>>> separate issue to whether the ATA password can be reentered
>>> for a drive that is moved from one system that supports ATA
>>> passwords to another that also does.
>
>> http://www.ami.com/support/doc/AMIBI...D_Security.pdf
>
>> The user password is normally used to unlock the hard drive.
>
> Yep, and it says absolutely NOTHING about any ATA spec encryption.
>
>> The master password, if one exists, can also be used to unlock the hard drive.
>
> Irrelevant to your pig ignorant claims about ENCRYPTION.
>
>> That is why I've seen some backdoor lists floating around of what some mobo makers have been found
>> to commonly use for a master password.
>
> Pity the user is welcome to change that and obviously should do so.
>
>> The master password is also why you can call the maker of your mobo as they may be able to tell
>> you what is the master password for you to unlock the drive.
>
> Pity that only allows you to ERASE the drive, not access the DATA.
>
>> Drive locking protection is obviously degraded if such backdoor [master] passwords are common
>
> No it doesnt if you actually have a clue and change that master password.
>
>> and maybe that's why security-conscious users and corporations rely on whole-disk encryption
>> instead.
>
> Thats for a different reason entirely, because its actually possible to bypass
> that password protection when you have physical access to the drive.
>
>> Ron is correct in that I was mixing hard drive locking with whole-disk
>> encryption. These are separate security mechanisms. From the OP's
>> post, perhaps just disk locking was employed and not encryption.
>
>> Since the OP gave absolutely no details on WHAT was the original computer in which the drive was
>> locked (and maybe encrypted, too), guesses is all that can be profferred.
>
> Anyone with a clue has noticed that you mangled the story completely.
>
>> Since the OP already tried in another computer that prompted for the password but it did not work
>> then it sure seems that the BIOS makers can customize how they support the drive lock feature.
>
> You dont even know that the OP is entering the password correctly.
>
>> That is, just because there is an ATA standard, it could be rather vague
>
> No it isnt.
>
>> or the BIOS makers may even deliberately tweak it so to be almost proprietary.
>
> No they dont.
>
>> As Odie alluded, drive locking may not be compatible between different BIOSes.
>
> He didnt say anything like that. The ATA standard makes it very clear how it works.
>
>> I'm wondering if a replacement of the PCB on the hard drive might "repair" or unlock the drive.
>> That is, get another exact same drive and use its PCB on the problematic drive. Since the
>> replacement PCB hasn't been password enabled yet, maybe it would permit access to the drive.
>
> VERY unlikely that it would be that pathetically implemented.
>
> Because that would defeat the whole point of the ATA security feature.
>
>> I tried this once with an old drive (so getting an exact replacement was pricey due to rarity)
>> because a voltage regulator component blew which rendered the drive useless (it wouldn't spin up).
>> The replacement PCB got the drive to spin up.
>
> Irrelevant to the ATA security feature.
>
>> It could even be that the translation geometry for LBA mode of the
>> original computer doesn't match that used in the second computer.
>
> Wrong again. You'd get a different result if that was the problem.
>
>> Start at http://www.pcguide.com/ref/hdd/bios/modesLBA-c.html. Then
>> read http://www.pcguide.com/ref/hdd/bios/modesCaveats-c.html about
>> the hazard (to data) of moving hard drives between computers, especially with different BIOSes.
>
> Pity that is irrelevant when the AUTO drive type is used.
>
>> I have ran into this when moving drives between hosts really old hardware hosts to new hardware
>> hosts.
>
> Pity his isnt really old hardware.
>
>
Rod,
Those links are interesting but it would be nice to know when they were
written. They do not seem to relate to today's hard drive issues.
groupware@rocketmail.com wrote:
>
> Question 1 - Is there any way to enter a HDD passowrd via a USB/IDE
> connection
No, it must be connected directly to an IDE port. If your laptop has a
removable media bay whereby you can remove the optical drive and replace it
with a second HD adapter then the locked HD will be correctly accessed on
BOOT and prompt you for the password.
> Question 2 - The computer that the Hard Drive comes from uses a US
> layout keyboard and the one i am trying to use it in now is a UK
> layout. I use a ~ (tilde) in my password which is in a different spot
> on these keyboards (although I have tried the various corresponding
> key locations) but it continually rejcts my password.
>
> Could this cause a problem ?
Sebastian Gottschalk wrote:
>
> Arno Wagner wrote:
>
> > So basically a HDD password is only protection angainst amateurs and
> > even they can get it removed for a few thousand EUR/USD?
>
> A few thousands would be nice. You just need to by the same model and
> exchange the electronic board, as many hobbyists already showed. Cost: $200
That generally won't work either, as parameters to each unique drive are
stored on the ROM / EEPROM on the logic board for many manufacturers.
There are plenty of people offering password removal, myself included.
In comp.sys.ibm.pc.hardware.storage Sebastian Gottschalk <seppi@seppig.de> wrote:
> Arno Wagner wrote:
>> So basically a HDD password is only protection angainst amateurs and
>> even they can get it removed for a few thousand EUR/USD?
> A few thousands would be nice. You just need to by the same model
> and exchange the electronic board, as many hobbyists already
> showed. Cost: $200
Same cost class. Basically worthless protection if anybody
wants to remove the password. Only protects against accidental
reading of data.
That is not true. That will not bypass hard drive passwords. The
password is stored on the platters.
Sebastian Gottschalk wrote:
> Arno Wagner wrote:
>
>> So basically a HDD password is only protection angainst amateurs and
>> even they can get it removed for a few thousand EUR/USD?
>
> A few thousands would be nice. You just need to by the same model and
> exchange the electronic board, as many hobbyists already showed. Cost: $200
John Doue <notwobe@yahoo.com> wrote:
> Rod Speed wrote:
>> Vanguard <no@mail.invalid> wrote
>>> Rod Speed <rod.speed.aaa@gmail.com> wrote
>>>> John Doue <notwobe@yahoo.com> wrote
>>>>> Vanguard wrote
>>>>>> Barry Watzman <WatzmanNOSPAM@neo.rr.com> wrote
>>
>>>>>>> Re: "The other half of the hash (to decode) was back in the
>>>>>>> original laptop. Preventing someone from getting at it,
>>>>>>> especially by stealing the drive, is just what that security is
>>>>>>> for; i.e., unless the drive is in the original laptop that
>>>>>>> hashed up the drive's contents AND you know the password, you
>>>>>>> will never get at the decoded contents of the drive."
>>
>>>>>>> I don't think that's correct. This isn't windows,
>>
>>>>>> I don't care what OS is on the drive, encrypted or not. The
>>>>>> whole-disk encryption is performed in hardware. Half of that
>>>>>> support is on the hard drive, the other half is back in the mobo.
>>>>>> If the drive wanders off from the mobo that hashed up the drive,
>>>>>> that drive cannot be decoded. It is very similar to e-mail
>>>>>> encryption: the source (owner of the certificate or the mobo) has
>>>>>> the "private" portion and the target (recipient or hard drive)
>>>>>> has the "public" portion. Without both, there's no decryption, and
>>>>>> the source controls that.
>>
>>>>>>> this is an IDE
>>
>>>>>> Yep, as I said, this hardware encryption was first provided in
>>>>>> ATA-3 specification.
>>
>> No it wasnt.
>>
>>>>>> It is NOT solely implemented on the hard drive alone.
>>
>> There was no hardware encryption on the hard drive with the ATA spec.
>>
>>>>>> Unfortunately it costs to get copies of the ATA specs from
>>>>>> http://www.t13.org/ and I really don't need them.
>>
>> The drafts are readily available for free and that detail didnt
>> change.
>>>>>>> Otherwise, as has happened here, if the computer motherboard
>>>>>>> dies, then the drive is lost, and that is beyond secure, it is "data
>>>>>>> endangering".
>>
>>>>>> Yep, that is what happens. And that is why you MUST do data
>>>>>> backups since they won't depend on the private key for the
>>>>>> encryption that the mobo has. The backups can either be open in
>>>>>> that anyone could restore from them or you would password-protect
>>>>>> them, but that password protection is entirely within the backup
>>>>>> file so you could use another computer running the same backup
>>>>>> program to restore your data because the password was only used
>>>>>> to encode the file (i.e., there is no separation of private and
>>>>>> public keys, there is just the one key used to encode the file).
>>
>>>>> I am curious to know what the final word is on that issue. Until
>>>>> reading your post, I shared Barry's opinion. If you are correct,
>>>>> and you seem to know your stuff,
>>
>>>> He doesnt, actually. Where the encryption is done is an entirely
>>>> separate issue to whether the ATA password can be reentered
>>>> for a drive that is moved from one system that supports ATA
>>>> passwords to another that also does.
>>
>>> http://www.ami.com/support/doc/AMIBI...D_Security.pdf
>>
>>> The user password is normally used to unlock the hard drive.
>>
>> Yep, and it says absolutely NOTHING about any ATA spec encryption.
>>
>>> The master password, if one exists, can also be used to unlock the
>>> hard drive.
>>
>> Irrelevant to your pig ignorant claims about ENCRYPTION.
>>
>>> That is why I've seen some backdoor lists floating around of what
>>> some mobo makers have been found to commonly use for a master
>>> password.
>>
>> Pity the user is welcome to change that and obviously should do so.
>>
>>> The master password is also why you can call the maker of your mobo
>>> as they may be able to tell you what is the master password for you
>>> to unlock the drive.
>>
>> Pity that only allows you to ERASE the drive, not access the DATA.
>>
>>> Drive locking protection is obviously degraded if such backdoor
>>> [master] passwords are common
>>
>> No it doesnt if you actually have a clue and change that master
>> password.
>>> and maybe that's why security-conscious users and corporations rely
>>> on whole-disk encryption instead.
>>
>> Thats for a different reason entirely, because its actually possible
>> to bypass that password protection when you have physical access to
>> the drive.
>>> Ron is correct in that I was mixing hard drive locking with
>>> whole-disk encryption. These are separate security mechanisms. From the OP's
>>> post, perhaps just disk locking was employed and not encryption.
>>
>>> Since the OP gave absolutely no details on WHAT was the original
>>> computer in which the drive was locked (and maybe encrypted, too), guesses is all that can be
>>> profferred.
>>
>> Anyone with a clue has noticed that you mangled the story completely.
>>
>>> Since the OP already tried in another computer that prompted for
>>> the password but it did not work then it sure seems that the BIOS
>>> makers can customize how they support the drive lock feature.
>>
>> You dont even know that the OP is entering the password correctly.
>>
>>> That is, just because there is an ATA standard, it could be rather
>>> vague
>>
>> No it isnt.
>>
>>> or the BIOS makers may even deliberately tweak it so to be almost
>>> proprietary.
>>
>> No they dont.
>>
>>> As Odie alluded, drive locking may not be compatible between
>>> different BIOSes.
>>
>> He didnt say anything like that. The ATA standard makes it very
>> clear how it works.
>>> I'm wondering if a replacement of the PCB on the hard drive might
>>> "repair" or unlock the drive. That is, get another exact same drive
>>> and use its PCB on the problematic drive. Since the replacement
>>> PCB hasn't been password enabled yet, maybe it would permit access
>>> to the drive.
>>
>> VERY unlikely that it would be that pathetically implemented.
>>
>> Because that would defeat the whole point of the ATA security
>> feature.
>>> I tried this once with an old drive (so getting an exact
>>> replacement was pricey due to rarity) because a voltage regulator
>>> component blew which rendered the drive useless (it wouldn't spin
>>> up). The replacement PCB got the drive to spin up.
>>
>> Irrelevant to the ATA security feature.
>>
>>> It could even be that the translation geometry for LBA mode of the
>>> original computer doesn't match that used in the second computer.
>>
>> Wrong again. You'd get a different result if that was the problem.
>>
>>> Start at http://www.pcguide.com/ref/hdd/bios/modesLBA-c.html. Then
>>> read http://www.pcguide.com/ref/hdd/bios/modesCaveats-c.html about
>>> the hazard (to data) of moving hard drives between computers,
>>> especially with different BIOSes.
>>
>> Pity that is irrelevant when the AUTO drive type is used.
>>
>>> I have ran into this when moving drives between hosts really old
>>> hardware hosts to new hardware hosts.
>>
>> Pity his isnt really old hardware.
>>
>>
> Rod,
>
> Those links are interesting but it would be nice to know when they were written.
Yeah, thats always been one downside of pcguide, it tends to lag reality by quite a bit.
> They do not seem to relate to today's hard drive issues.
They are in the sense that its possible to use other than an AUTO drive type.
They arent when an AUTO drive type is used.
Sebastian Gottschalk <seppi@seppig.de> wrote:
> Arno Wagner wrote:
>
>> So basically a HDD password is only protection angainst amateurs and
>> even they can get it removed for a few thousand EUR/USD?
>
> A few thousands would be nice. You just need to by the same model and
> exchange the electronic board, as many hobbyists already showed.
> Cost: $200
On Feb 4, 9:41 am, John Doue <notw...@yahoo.com> wrote:
> Rod Speed wrote:
> > Vanguard <n...@mail.invalid> wrote
> >> Rod Speed <rod.speed....@gmail.com> wrote
> >>> John Doue <notw...@yahoo.com> wrote
> >>>> Vanguard wrote
> >>>>> Barry Watzman <WatzmanNOS...@neo.rr.com> wrote
>
> >>>>>> Re: "The other half of the hash (to decode) was back in the original laptop. Preventing
> >>>>>> someone from getting at it, especially by stealing the drive, is just what that security is
> >>>>>> for; i.e., unless the drive is in the original laptop that hashed up the drive's contents AND
> >>>>>> you know the password, you will never get at the decoded contents of the drive."
>
> >>>>>> I don't think that's correct. This isn't windows,
>
> >>>>> I don't care what OS is on the drive, encrypted or not. The
> >>>>> whole-disk encryption is performed in hardware. Half of that
> >>>>> support is on the hard drive, the other half is back in the mobo.
> >>>>> If the drive wanders off from the mobo that hashed up the drive,
> >>>>> that drive cannot be decoded. It is very similar to e-mail
> >>>>> encryption: the source (owner of the certificate or the mobo) has
> >>>>> the "private" portion and the target (recipient or hard drive) has
> >>>>> the "public" portion. Without both, there's no decryption, and the
> >>>>> source controls that.
>
> >>>>>> this is an IDE
>
> >>>>> Yep, as I said, this hardware encryption was first provided in ATA-3 specification.
>
> > No it wasnt.
>
> >>>>> It is NOT solely implemented on the hard drive alone.
>
> > There was no hardware encryption on the hard drive with the ATA spec.
>
> >>>>> Unfortunately it costs to get copies of the ATA specs fromhttp://www.t13.org/and I really
> >>>>> don't need them.
>
> > The drafts are readily available for free and that detail didnt change.
>
> >>>>>> Otherwise, as has happened here, if the computer motherboard dies,
> >>>>>> then the drive is lost, and that is beyond secure, it is "data endangering".
>
> >>>>> Yep, that is what happens. And that is why you MUST do data
> >>>>> backups since they won't depend on the private key for the
> >>>>> encryption that the mobo has. The backups can either be open in
> >>>>> that anyone could restore from them or you would password-protect
> >>>>> them, but that password protection is entirely within the backup
> >>>>> file so you could use another computer running the same backup
> >>>>> program to restore your data because the password was only used to encode the file (i.e., there
> >>>>> is no separation of private and
> >>>>> public keys, there is just the one key used to encode the file).
>
> >>>> I am curious to know what the final word is on that issue. Until reading your post, I shared
> >>>> Barry's opinion. If you are correct, and you seem to know your stuff,
>
> >>> He doesnt, actually. Where the encryption is done is an entirely
> >>> separate issue to whether the ATA password can be reentered
> >>> for a drive that is moved from one system that supports ATA
> >>> passwords to another that also does.
>
> >>http://www.ami.com/support/doc/AMIBI...D_Security.pdf
>
> >> The user password is normally used to unlock the hard drive.
>
> > Yep, and it says absolutely NOTHING about any ATA spec encryption.
>
> >> The master password, if one exists, can also be used to unlock the hard drive.
>
> > Irrelevant to your pig ignorant claims about ENCRYPTION.
>
> >> That is why I've seen some backdoor lists floating around of what some mobo makers have been found
> >> to commonly use for a master password.
>
> > Pity the user is welcome to change that and obviously should do so.
>
> >> The master password is also why you can call the maker of your mobo as they may be able to tell
> >> you what is the master password for you to unlock the drive.
>
> > Pity that only allows you to ERASE the drive, not access the DATA.
>
> >> Drive locking protection is obviously degraded if such backdoor [master] passwords are common
>
> > No it doesnt if you actually have a clue and change that master password.
>
> >> and maybe that's why security-conscious users and corporations rely on whole-disk encryption
> >> instead.
>
> > Thats for a different reason entirely, because its actually possible to bypass
> > that password protection when you have physical access to the drive.
>
> >> Ron is correct in that I was mixing hard drive locking with whole-disk
> >> encryption. These are separate security mechanisms. From the OP's
> >> post, perhaps just disk locking was employed and not encryption.
>
> >> Since the OP gave absolutely no details on WHAT was the original computer in which the drive was
> >> locked (and maybe encrypted, too), guesses is all that can be profferred.
>
> > Anyone with a clue has noticed that you mangled the story completely.
>
> >> Since the OP already tried in another computer that prompted for the password but it did not work
> >> then it sure seems that the BIOS makers can customize how they support the drive lock feature.
>
> > You dont even know that the OP is entering the password correctly.
>
> >> That is, just because there is an ATA standard, it could be rather vague
>
> > No it isnt.
>
> >> or the BIOS makers may even deliberately tweak it so to be almost proprietary.
>
> > No they dont.
>
> >> As Odie alluded, drive locking may not be compatible between different BIOSes.
>
> > He didnt say anything like that. The ATA standard makes it very clear how it works.
>
> >> I'm wondering if a replacement of the PCB on the hard drive might "repair" or unlock the drive.
> >> That is, get another exact same drive and use its PCB on the problematic drive. Since the
> >> replacement PCB hasn't been password enabled yet, maybe it would permit access to the drive.
>
> > VERY unlikely that it would be that pathetically implemented.
>
> > Because that would defeat the whole point of the ATA security feature.
>
> >> I tried this once with an old drive (so getting an exact replacement was pricey due to rarity)
> >> because a voltage regulator component blew which rendered the drive useless (it wouldn't spin up).
> >> The replacement PCB got the drive to spin up.
>
> > Irrelevant to the ATA security feature.
>
> >> It could even be that the translation geometry for LBA mode of the
> >> original computer doesn't match that used in the second computer.
>
> > Wrong again. You'd get a different result if that was the problem.
>
> >> Start athttp://www.pcguide.com/ref/hdd/bios/modesLBA-c.html. Then
> >> readhttp://www.pcguide.com/ref/hdd/bios/modesCaveats-c.htmlabout
> >> the hazard (to data) of moving hard drives between computers, especially with different BIOSes.
>
> > Pity that is irrelevant when the AUTO drive type is used.
>
> >> I have ran into this when moving drives between hosts really old hardware hosts to new hardware
> >> hosts.
>
> > Pity his isnt really old hardware.
>
> Rod,
>
> Those links are interesting but it would be nice to know when they were
> written. They do not seem to relate to today's hard drive issues.
>
> Regards
>
> --
> John Doue
Thanks for all the replys (and discussion)
To answer a few questions:
- the hardrive is a Seagate Momentus 7200.1
- the original laptop is an LG and uses Phoenix Bios
- the hardrive is locked using ATA Password locking and not encrypted
Any further thoughts on why the HP laptop doesn't recognise the
password are appreciated.
Prior to posting I had researched this quite a bit and have checked
most of the links for geting to the Master password and will probably
try this in due course if I can;t solve the user password issue.
groupware@rocketmail.com wrote:
> On Feb 4, 9:41 am, John Doue <notw...@yahoo.com> wrote:
>> Rod Speed wrote:
>>> Vanguard <n...@mail.invalid> wrote
>>>> Rod Speed <rod.speed....@gmail.com> wrote
>>>>> John Doue <notw...@yahoo.com> wrote
>>>>>> Vanguard wrote
>>>>>>> Barry Watzman <WatzmanNOS...@neo.rr.com> wrote
>>
>>>>>>>> Re: "The other half of the hash (to decode) was back in the
>>>>>>>> original laptop. Preventing someone from getting at it,
>>>>>>>> especially by stealing the drive, is just what that security
>>>>>>>> is for; i.e., unless the drive is in the original laptop that
>>>>>>>> hashed up the drive's contents AND you know the password, you
>>>>>>>> will never get at the decoded contents of the drive."
>>
>>>>>>>> I don't think that's correct. This isn't windows,
>>
>>>>>>> I don't care what OS is on the drive, encrypted or not. The
>>>>>>> whole-disk encryption is performed in hardware. Half of that
>>>>>>> support is on the hard drive, the other half is back in the
>>>>>>> mobo.
>>>>>>> If the drive wanders off from the mobo that hashed up the drive,
>>>>>>> that drive cannot be decoded. It is very similar to e-mail
>>>>>>> encryption: the source (owner of the certificate or the mobo)
>>>>>>> has
>>>>>>> the "private" portion and the target (recipient or hard drive)
>>>>>>> has
>>>>>>> the "public" portion. Without both, there's no decryption, and
>>>>>>> the
>>>>>>> source controls that.
>>
>>>>>>>> this is an IDE
>>
>>>>>>> Yep, as I said, this hardware encryption was first provided in
>>>>>>> ATA-3 specification.
>>
>>> No it wasnt.
>>
>>>>>>> It is NOT solely implemented on the hard drive alone.
>>
>>> There was no hardware encryption on the hard drive with the ATA
>>> spec.
>>
>>>>>>> Unfortunately it costs to get copies of the ATA specs
>>>>>>> fromhttp://www.t13.org/and I really don't need them.
>>
>>> The drafts are readily available for free and that detail didnt
>>> change.
>>
>>>>>>>> Otherwise, as has happened here, if the computer motherboard
>>>>>>>> dies,
>>>>>>>> then the drive is lost, and that is beyond secure, it is "data
>>>>>>>> endangering".
>>
>>>>>>> Yep, that is what happens. And that is why you MUST do data
>>>>>>> backups since they won't depend on the private key for the
>>>>>>> encryption that the mobo has. The backups can either be open in
>>>>>>> that anyone could restore from them or you would
>>>>>>> password-protect
>>>>>>> them, but that password protection is entirely within the backup
>>>>>>> file so you could use another computer running the same backup
>>>>>>> program to restore your data because the password was only used
>>>>>>> to encode the file (i.e., there is no separation of private and
>>>>>>> public keys, there is just the one key used to encode the file).
>>
>>>>>> I am curious to know what the final word is on that issue. Until
>>>>>> reading your post, I shared Barry's opinion. If you are correct,
>>>>>> and you seem to know your stuff,
>>
>>>>> He doesnt, actually. Where the encryption is done is an entirely
>>>>> separate issue to whether the ATA password can be reentered
>>>>> for a drive that is moved from one system that supports ATA
>>>>> passwords to another that also does.
>>
>>>> http://www.ami.com/support/doc/AMIBI...D_Security.pdf
>>
>>>> The user password is normally used to unlock the hard drive.
>>
>>> Yep, and it says absolutely NOTHING about any ATA spec encryption.
>>
>>>> The master password, if one exists, can also be used to unlock the
>>>> hard drive.
>>
>>> Irrelevant to your pig ignorant claims about ENCRYPTION.
>>
>>>> That is why I've seen some backdoor lists floating around of what
>>>> some mobo makers have been found to commonly use for a master
>>>> password.
>>
>>> Pity the user is welcome to change that and obviously should do so.
>>
>>>> The master password is also why you can call the maker of your
>>>> mobo as they may be able to tell you what is the master password
>>>> for you to unlock the drive.
>>
>>> Pity that only allows you to ERASE the drive, not access the DATA.
>>
>>>> Drive locking protection is obviously degraded if such backdoor
>>>> [master] passwords are common
>>
>>> No it doesnt if you actually have a clue and change that master
>>> password.
>>
>>>> and maybe that's why security-conscious users and corporations
>>>> rely on whole-disk encryption instead.
>>
>>> Thats for a different reason entirely, because its actually
>>> possible to bypass that password protection when you have physical
>>> access to the drive.
>>
>>>> Ron is correct in that I was mixing hard drive locking with
>>>> whole-disk
>>>> encryption. These are separate security mechanisms. From the OP's
>>>> post, perhaps just disk locking was employed and not encryption.
>>
>>>> Since the OP gave absolutely no details on WHAT was the original
>>>> computer in which the drive was locked (and maybe encrypted, too),
>>>> guesses is all that can be profferred.
>>
>>> Anyone with a clue has noticed that you mangled the story
>>> completely.
>>
>>>> Since the OP already tried in another computer that prompted for
>>>> the password but it did not work then it sure seems that the BIOS
>>>> makers can customize how they support the drive lock feature.
>>
>>> You dont even know that the OP is entering the password correctly.
>>
>>>> That is, just because there is an ATA standard, it could be rather
>>>> vague
>>
>>> No it isnt.
>>
>>>> or the BIOS makers may even deliberately tweak it so to be almost
>>>> proprietary.
>>
>>> No they dont.
>>
>>>> As Odie alluded, drive locking may not be compatible between
>>>> different BIOSes.
>>
>>> He didnt say anything like that. The ATA standard makes it very
>>> clear how it works.
>>
>>>> I'm wondering if a replacement of the PCB on the hard drive might
>>>> "repair" or unlock the drive. That is, get another exact same
>>>> drive and use its PCB on the problematic drive. Since the
>>>> replacement PCB hasn't been password enabled yet, maybe it would
>>>> permit access to the drive.
>>
>>> VERY unlikely that it would be that pathetically implemented.
>>
>>> Because that would defeat the whole point of the ATA security
>>> feature.
>>
>>>> I tried this once with an old drive (so getting an exact
>>>> replacement was pricey due to rarity) because a voltage regulator
>>>> component blew which rendered the drive useless (it wouldn't spin
>>>> up). The replacement PCB got the drive to spin up.
>>
>>> Irrelevant to the ATA security feature.
>>
>>>> It could even be that the translation geometry for LBA mode of the
>>>> original computer doesn't match that used in the second computer.
>>
>>> Wrong again. You'd get a different result if that was the problem.
>>
>>>> Start athttp://www.pcguide.com/ref/hdd/bios/modesLBA-c.html. Then
>>>> readhttp://www.pcguide.com/ref/hdd/bios/modesCaveats-c.htmlabout
>>>> the hazard (to data) of moving hard drives between computers,
>>>> especially with different BIOSes.
>>
>>> Pity that is irrelevant when the AUTO drive type is used.
>>
>>>> I have ran into this when moving drives between hosts really old
>>>> hardware hosts to new hardware hosts.
>>
>>> Pity his isnt really old hardware.
>>
>> Rod,
>>
>> Those links are interesting but it would be nice to know when they
>> were written. They do not seem to relate to today's hard drive
>> issues.
>>
>> Regards
>>
>> --
>> John Doue
>
> Thanks for all the replys (and discussion)
>
> To answer a few questions:
> - the hardrive is a Seagate Momentus 7200.1
> - the original laptop is an LG and uses Phoenix Bios
> - the hardrive is locked using ATA Password locking and not encrypted
> Any further thoughts on why the HP laptop doesn't recognise the
> password are appreciated.
You've basically got to test the two obvious possibilitys, that there
is something about the different keyboard that matters, or that you
have managed to forget the original password, or the fine detail of it.
The obvious way to try the keyboard possibility is to try
it in a laptop with the same keyboard as the original.
> Prior to posting I had researched this quite a bit and have checked
> most of the links for geting to the Master password and will probably
> try this in due course if I can;t solve the user password issue.
"Rod Speed" <rod.speed.aaa@gmail.com> wrote in news:52mudqF1po6itU1
@mid.individual.net:
>> Thanks for all the replys (and discussion)
>>
>> To answer a few questions:
>> - the hardrive is a Seagate Momentus 7200.1
>> - the original laptop is an LG and uses Phoenix Bios
>> - the hardrive is locked using ATA Password locking and not encrypted
>
>> Any further thoughts on why the HP laptop doesn't recognise the
>> password are appreciated.
>
> You've basically got to test the two obvious possibilitys, that there
> is something about the different keyboard that matters, or that you
> have managed to forget the original password, or the fine detail of it.
>
> The obvious way to try the keyboard possibility is to try
> it in a laptop with the same keyboard as the original.
>
>> Prior to posting I had researched this quite a bit and have checked
>> most of the links for geting to the Master password and will probably
>> try this in due course if I can;t solve the user password issue.
For computers in which the BIOS does not provide an interface to the ata
password, you may wish to instead try the software program ATAPWD to
attempt to revive the drive. To obtain atapwd and read a discussion of the
issues, you can visit:
"Rod Speed" wrote in message news:52lnnhF1p6r6cU1@mid.individual.net...
>
> Vanguard <no@mail.invalid> wrote
>
>> Unfortunately it costs to get copies of the ATA specs from
>> http://www.t13.org/
>
> The drafts are readily available for free and that detail didnt
> change.
They are? Got a URL for the free copy of the full specs for all ATA
revisions? What I see at http://www.t13.org/Standards/Default...ocumentStage=2
is a list (but no links for them) and the comment "Copies of published
standards may be purchased from: ANSI, ...". Where are the free copies
then? When I Google around looking for ATA specs, I end up following
links that take me back to t13.org and they redirect you to ANSI where
they charge for them ($30 apiece for each revision of the AT Attachment
spec, and ATA-7 has 3 volume where each is $30 or all 3 for $80).
> Yep, and it says absolutely NOTHING about any ATA spec encryption.
Sorry, meant ATA spec hard drive password locking. I'm sure the spec
calls it something else. According to http://www.heise.de/ct/english/05/08/172/, it's called "Security Feature
Set". It is part of the ATA spec.
Vanguard <no@mail.invalid> wrote
> Rod Speed wrote
>> Vanguard <no@mail.invalid> wrote
>>> Unfortunately it costs to get copies of the ATA specs from http://www.t13.org/
>> The drafts are readily available for free and that detail didnt change.
> They are?
Yep.
> Got a URL for the free copy of the full specs for all ATA revisions?
I never said anything about all ATA revisions.
> What I see at
> http://www.t13.org/Standards/Default...ocumentStage=2
> is a list (but no links for them) and the comment "Copies of published standards may be purchased
> from: ANSI, ...". Where are the free copies then?
> When I Google around looking for ATA specs, I end up following links that take me back to t13.org
> and they redirect you to ANSI where they charge for them ($30 apiece for each revision of the AT
> Attachment spec, and ATA-7 has 3 volume where each is $30 or all 3 for $80).
>> Yep, and it says absolutely NOTHING about any ATA spec encryption.
> Sorry, meant ATA spec hard drive password locking. I'm sure the spec calls it something else.
> According to
> http://www.heise.de/ct/english/05/08/172/, it's called "Security Feature Set". It is part of the
> ATA spec.
"Rod Speed" <rod.speed.aaa@gmail.com> wrote in message
news:52noruF1pa94kU1@mid.individual.net...
> Vanguard <no@mail.invalid> wrote
>> Rod Speed wrote
>>> Vanguard <no@mail.invalid> wrote
>
>>>> Unfortunately it costs to get copies of the ATA specs from
>>>> http://www.t13.org/
>
>>> The drafts are readily available for free and that detail didnt
>>> change.
>
>> They are?
>
> Yep.
>
>> Got a URL for the free copy of the full specs for all ATA revisions?
>
> I never said anything about all ATA revisions.
>
>> What I see at
>> http://www.t13.org/Standards/Default...ocumentStage=2
>> is a list (but no links for them) and the comment "Copies of
>> published standards may be purchased from: ANSI, ...". Where are the
>> free copies then?
>
> http://www.t13.org/Documents/Default...ocumentStage=2
> http://www.t13.org/Documents/Default...ocumentStage=1
I was asking about the actual ratified and approved specifications, not
drafts of proposals for those specs. I don't believe "drafts" are the
actual standard. I had asked about getting the standards spec. I
didn't realizer you were pointing at a list that contained some drafts
that proposed those specs. Some entries are just 2-page descriptions or
placeholders, hardly what would be called a standard specification.
Some are docs containing corrections, so hardly a specification. Some
are just entries in the table listing but with no link to an actual doc.
The specs still cost money.
Vanguard <no@mail.invalid> wrote
> Rod Speed <rod.speed.aaa@gmail.com> wrote
>> Vanguard <no@mail.invalid> wrote
>>> Rod Speed wrote
>>>> Vanguard <no@mail.invalid> wrote
>>>>> Unfortunately it costs to get copies of the ATA specs from
>>>>> http://www.t13.org/
>>>> The drafts are readily available for free and that detail didnt change.
>>> They are?
>> Yep.
>>> Got a URL for the free copy of the full specs for all ATA revisions?
>> I never said anything about all ATA revisions.
>>> What I see at
>>> http://www.t13.org/Standards/Default...ocumentStage=2
>>> is a list (but no links for them) and the comment "Copies of
>>> published standards may be purchased from: ANSI, ...". Where are the free copies then?
> I was asking about the actual ratified and approved specifications, not drafts of proposals for
> those specs.
I already told you that that detail didnt change significantly
between the draft and the ratified standard.
And the later drafts include the ratified standard too.
> I don't believe "drafts" are the actual standard.
You have always been, and always will be, completely and
utterly irrelevant. What you may or may not believe in spades.
> I had asked about getting the standards spec.
And I told you how to see those for free, most obviously when a
later draft includes the earlier ratified detail on the security mode.
Not ever a single mention of the drive doing any encryption, which
is all that is needed to prove that you have never had a clue.
> I didn't realizer you were pointing at a list that contained some drafts that proposed those
> specs. Some entries are just 2-page descriptions or placeholders, hardly what would be called a
> standard specification.
Pity about the other ones that cover that security mode completely.
> Some are docs containing corrections, so hardly a specification.
Pity about the other ones that cover that security mode completely.
> Some are just entries in the table listing but with no link to an actual doc.
Pity about the other ones that cover that security mode completely.
> The specs still cost money.
Not when a later draft includes that ratified spec they dont.
Rule of Holes, child. When you are in one STOP DIGGING.
Hard Drive Password Problems 
Linear Mode
