[unisog] Laptop Hard Drive Password

PaulFM paulfm at me.umn.edu
Thu Jul 7 14:02:01 GMT 2005

I remember this being an IBM laptop thing, I don't know how it is implimented 
(it may have been in the hard-drive's internal controller), but the laptop 
bios was used to set the password - and I believe just setting the password 
to blank removes it.  It might be a good idea to download the manuals for the 
laptop and see if the procedure is there.

Peter Van Epp wrote:
> On Thu, Jul 07, 2005 at 12:19:39PM +1000, Leigh Vincent wrote:
>>Hello All,
>>Does anyone know how to remove a hard drive password from a laptop?? 
>>We know the password but we want to be able to remove it.  Now, this is
>>NOT a BIOS password.  This is NOT a Windows password.  But it is a
>>security password placed on the Hard drive which you must enter before
>>the drive boots up.
>>Any suggestions would be greatly appreciated.
>>Leigh Vincent
>>Information Security Officer
>>Information Services
>>University of Ballarat
>>PO Box 663
>>BALLARAT   VIC   3353
>>Ph.: 03-5327 9386
>>Mobile: 0439 357 203 
>>l.vincent at ballarat.edu.au
> 	Since you have the password presumably the data can be (and is) backed
> up elsewhere. Next you need to figure out if this is worth doing i.e. buying
> a HD that isn't password protected and copying the data there and installing it
> in the laptop may be the most practical solution here. That may not be possible 
> however, in which case an entirely new laptop may start to look attractive.
> 	Once all these fine options have been discarded the next item is to 
> figure out if the protection is a software add on (i.e. on the disk only) or 
> embedded in ROM in either BIOS or in the option ROM of the disk controller.
> This case makes a review of the first few suggestions worth another pass 
> because its likely to be hard to impossible and thus not worth it.
> 	The preferable case is an entirely software solution that has modified 
> the boot sector of the disk to load the password processing code from (for
> instance) the 64 optional use sectors on track 0 of the HD. In this case a
> sector editor and/or debug from a DOS disk (and a fair bit of time and 
> knowledge) can likely defeat it. 
> 	The easist (if most dangerous) alternative is to have an image backup
> of the disk (from something like ghost or a program that reads the raw disk 
> sectors) so you can restore it (you should test that this works on a less 
> valuable disk first probably :-)). Then boot a DOS disk and do a fdisk /mbr 
> (which rewrites the boot sector) or use something like pfdisk to rewrite the 
> boot sector with a known bootloader. If the machine now boots without a 
> password after that, you are away to the races. If it doesn't boot at all its 
> time to restore the original disk contents with a sector writer and try again 
> (carefully going back to step 1 to see if its attractive yet :-)).
> 	The bios typically loads sector 0 off the disk in to low memory
> (7c:0000 if I remember correctly) then jumps to it (after checking that it has 
> the magic bytes at the end of the sector). Arranging to do that under DOS and 
> using debug it is possible to single step through the code while it boots 
> which should lead you to the password routine, at which point suitable nops 
> and a write back to the disk will fix the problem (this of course assumes you 
> are familiar with X86 assembler, DOS and debug). Depending how creative they 
> have been in attempting to foil this, step 1 may yet start to look more 
> attractive, but if you are up for a challange it would probably be fun (for 
> some warped definition of fun :-)) and certainly educational. 
> 	Good luck, and remember you can never have too many backups when doing 
> this kind of thing ...
> Peter Van Epp / Operations and Technical Support 
> Simon Fraser University, Burnaby, B.C. Canada
> _______________________________________________
> unisog mailing list
> unisog at lists.sans.org
> http://www.dshield.org/mailman/listinfo/unisog

The views and opinions expressed above are strictly
those of the author(s).  The content of this message has
not been reviewed nor approved by any entity whatsoever.
Paul F. Markfort   Info/Web: http://www.menet.umn.edu/~paulfm

More information about the unisog mailing list