05-28-2019 10:34 AM
05-28-2019 04:23 PM
06-12-2019 06:47 AM
Is there a document somewhere that lists exactly what keys are valid as Lenovo HDD password, and what aren't ?
06-12-2019 07:53 AM
I believe it is numbers, letters and spaces. Shift key is ignored. On my U.S English keyboard, the "!" is a shifted "1". That means that if I think I am putting in a "!", I am really putting in a "1".
06-12-2019 08:28 AM
Thanks a lot for your answer richk.
It's great to see collaborative communities like this to help us..
One of my colleagues set up an SSD password on a Lenovo T540P corporate laptop,
which has an azerty (french) keyboard.
The password he entered doesn't work anymore and we suspect it could be due to special characters
The consequence is that we cannot access the SSD anymore (obviously)
We have tried to remove the password (we don't care about the data on the disk, we just want to reuse the disk), there is a Lenovo
tool for that, we burnt an ISO to cdrom;
But the problem is that the Lenovo BIOS at reboot asks the SSD password *before* even trying to boot the Lenovo tool that could enable us to remove the password..
So, we're basically stuck..
Concerning the SSD password that has been set :
He (thinks he) typed this password : M@zurk@!01
From the precious information you (and others) gave, I understand that :
@ and ! are special characters and should be skipped, or their translation (az => qw) should be used
The tricky part being that on azerty, to obtain @,
we hit : AltGr+KEY_ZERO_IN_QWERTY (in the numbers series, right after the KEY_NINE)
So could it be 0 (zero) ? or could it be skipped ?
Also, to obtain !,
we hit KEY_SLASH_IN_QWERTY (tenth key in the last letter row)
The last two numbers of the password has been typed on numeric pad (numlock on). is it ok ?
If you confirm that both @ and ! are to be skipped, then the password to try could be :
or, if @ => 0 :
do you have some suggestion on what we could try to recover the disk ? (not its data - the disk was blank)
06-12-2019 09:49 AM - edited 06-12-2019 09:51 AM
I have no idea what happens with a number pad. I would need to test with a program that shows scan codes. I have no hardware to test. I think that on an azerty KB, @ is a shifted zero. If that is true, it should be entered as zero. I expect that the slash was probably ignored
06-13-2019 12:25 AM - edited 06-13-2019 12:49 AM
I found the password !
Thanks to all contributors of this thread !!
As richk and others mentioned, special characters and shifted ones are effectively to be skipped.
In our case, we had hit all these this keys on the internal azerty keyboard in the HDD password BIOS form :
-note that the two last digits were entered on the numpad (with numlock on) - and it works fine (don't forget numlock) - but it is probably a *bad* idea to use numpad for that.. sigh
-note that the first 'M' (shifted on azerty) generates an invalid character (as the bios reads the underneath qwerty scancode)
-note that the ! right before the two last digits generates an invalid character as well
To unlock the password I had to blindly hit *all these keys* as-is even if we hear Biips on invalid keys, and more importantly, press NumLock (after any reboot or password retry (there is no numlock light indicator on the TP)
In effect, I guess the BIOS scans and record these qwerty keys in our case :
But who knows.. anyway, the disk is ready for a new life now..
I think Lenovo should align the user interface of :
-the HDD password setup form where we might not hear (and see ?) any invalid characters
-the HDD password unlock prompt at boot where we actually hear spurious Biips which make us think we 'forgot' the password
=> The user should be guided the same way in both cases to :
-not be able to enter invalid characters/modifiers and
-and/or acknowledge that those invalid characters are skipped
Thanks again; hope these might help other people as well..
06-19-2019 11:59 PM - edited 06-20-2019 12:10 AM
I am having this exact same problem. I set the password with an "@" keystroke in it and it excepted it TWICE in a row... but as soon as the laptop was turned off then on again it just doesn't recognize the 2 key as being pressed while holding shift. As a matter of fact, none of the numeric keys work while holding shift. but yet it did when I was setting the password!!
I have as well tried all the possible differences that come to mind like just leaving out that key or putting a 2 in instead but to no avail!!
now I am completely locked out of my work computer and in big doo doo if I can't figure this out pronto!!
06-20-2019 03:11 AM
Don't give up !
I was exactly in the same state of frustration, and it lasted several weeks.
At the end, I found the proper key sequence to unlock, thanks to :
- the valuable information gleaned in this thread
- knowing precise information about what password has been entered, how (shift states, etc..)
I thought hard about the mapping between what physical + modifiers have been hit on the keyboard, and what logical key scan codes might have been seen and recorded by the bios
Remember about the fact that the bios ignore 'shift' (and probably alt, altgr, ctrl etc..) which means no uppercases, no second key values, etc..
Remember that when defining the password, there could be no Biips on invalid keys and the bios simply ignoring it
Which means when you enter it again to unlock, there you might hear thoses Biip bu you have to ignore this fact and continue
What kind of keyboard layout is it ? US English ? other ? did you use an external keyboard to setup the password ? layout ?
Did you use the numeric pad on the right ?
you mention holding 'shift' for 2 key ?
Are you using some azerty or similar layout ?
06-21-2019 05:24 AM
When setting up my accounts on any new computer I could have sworn it was labeled the US keyboard. Whereas you would have to hold the shift down to access the @ sign... However your mention of it ignoring the shift every time and not just for my initial hunch (ie, @) but possible that the uppercase letter I used as well... here how about I just tell you what the password is and you can maybe take a guess at what you think I should try
Because it has all the key sequences that I've ever been asked for in any and all cases when setting up any password in the past I thought this one was fail safe! guess again.